Версия для печати

Архив документации на OpenNet.ru / Раздел "Сети, протоколы, сервисы" (Многостраничная версия)

Telecommunication technologies - телекоммуникационные технологии (v2.1)

Автор: Семенов Ю.А. (ГНЦ ИТЭФ)

Оригинал: book.itep.ru

down next index index
Down: 1 Введение (общие принципы построения сетей)
    Next: 1 Введение (общие принципы построения сетей)

Оглавление
Семенов Ю.А. (ГНЦ ИТЭФ)

IP - TCP - UDP - ARP - RARP - ICMP - BOOTP - IPv6 - HTTP - SNMP - SMTP - RIP - OSPF - BGP - DNS - IGMP - PIM - DVRMP - MIB - ASN - NNTP - RSVP - RTP - RTCP - FTP - TFTP - TELNET - WWW - HTML - XML - SSL - RSA - ISDN - SET - ATM - SDH - X.25 - ETHERNET - FE - FIBRE CHANNEL - HIPPI - IOTP - TLS

Номер раздела Название раздела Объем в страницах Объем в кбайт
Предисловие

3

60

Оглавление

8

7

1 Введение (общие принципы построения сетей)

9

7

2 Преобразование, кодировка и передача информации

4

3

2.1 Передача сигналов по линиям связи

8

6

2.1.1 Влияние шумов и помех

2

2

2.2 Представление электрических сигналов в цифровой форме

10

7

2.3 Цифровые каналы T1 и Е1

2

1

2.4 Методы преобразования и передачи звуковых сигналов

6

5

2.4.1 Дельта-модуляция

1

1

2.4.2 Кодировщики голоса (Vocoder)

2

2

2.4.3 Передача голоса по каналам Интернет

4

2

2.5 Методы преобразования и передачи изображения

14

12

2.5.1 Стандарт MPEG-4

67

1000

2.5.2 Стандарт MPEG-7

59

1400

2.6 Методы сжатия информации

3

3

2.6.1 Алгоритм Зива-Лемпеля

3

3

2.6.2 Локально адаптивный алгоритм сжатия

2

2

2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

1

1

2.6.4 Метод Шеннона-Фано

1

3

2.6.5 Статический алгоритм Хафмана

1

1

2.7 Обнаружение ошибок

2

2

2.8 Коррекция ошибок

6

6

2.9 Видеоконференции по каналам Интернет и ISDN

8

97

2.9.1 Используемые стандарты

2

2

2.10 Статистическая теория каналов связи

10

145

3 Каналы передачи данных

1

1

3.1 Кабельные каналы связи

7

106

3.2 Оптоволоконные каналы

10

8

3.3 Беспроводные (радио) каналы и сети

11

8

3.4 Протокол SLIP

2

20

3.5 Протокол PPP

9

8

3.6 Протокол G.703

1

21

4 Сети передачи данных. Методы доступа

14

13

4.1 Локальные сети (обзор)

1

1

4.1.1 Ethernet (IEEE 802.3)

1

1

4.1.1.1 Архитектура сетей Ethernet

11

12

4.1.1.2 Fast Ethernet

10

9

4.1.1.3 Интернет в Ethernet

9

7

4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы

7

7

4.1.2 IEEE 802.5 (Token Ring)

12

12

4.1.3 IEEE 802.4 (Маркерная шина)

3

22

4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)

5

75

4.1.5 Локальные сети ArcNet

4

139

4.1.6 Сети FDDI

8

328

4.1.7 Параллельный сетевой интерфейс HIPPI

4

37

4.1.8 Сети IEEE 802.11

3

58

4.1.8.1 Мобильные телекоммуникации

7

168

4.1.9 Сети DQDB (двойная шина с распределенной очередью)

3

29

4.1.10 Сети с многокаскадными соединениями

1

19

4.1.11 Сети 100Base-VG

1

4

4.1.12 Канальный протокол Fibre Channel

4

35

4.1.13 Коммутируемая мультимегабитная информационная служба SMDS

2

17

4.2 Наложенные сети

1

6

4.2.1 Протоколы Novell (IPX/SPX)

1

5

4.2.1.1 IPX-протокол

4

60

4.2.1.2 SPX-протокол

2

26

4.2.1.3 Протокол ядра NetWare (NCP)

3

18

4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)

3

24

4.2.1.5 Служба каталогов NetWare (NDS)

4

52

4.2.2 AppleTalk

4

52

4.2.3 NetBIOS

5

16

4.3 Региональные сети

1

5

4.3.1 Эталонная сетевая модель ISO

5

68

4.3.2 Протоколы сетей X.25

18

213

4.3.3 Интегрированные сети ISDN

25

451

4.3.4 Протокол Frame Relay

6

77

4.3.5 Протоколы сетей ATM

21

254

4.3.6 Синхронные каналы SDH/SONET

9

165

4.3.7 Модемы

10

126

4.4 Интернет

3

2

4.4.1 IP-протокол

10

91

4.4.1.1 Адресация IPv6

45

45

4.4.1.2 IP-туннели

1

87

4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)

48

48

4.4.2 Протокол UDP

7

5

4.4.3 Протокол TCP

15

135

4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)

10

93

4.4.5 Протокол XTP

10

103

4.4.6 Протокол преобразования адресов ARP

4

141

4.4.7 Прокси-ARP

1

11

4.4.8 Протокол обратного адресного преобразования RARP

1

13

4.4.9 Протокол IGMP

3

20

4.4.9.1 Мультикастинг и MBONE

2

7

4.4.9.2 Протокол реального времени RTP

22

86

4.4.9.3 Транспортный протокол реального времени RTCP

25

157

4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP

2

12

4.4.9.5 Протокол PIM

17

154

4.4.9.6 Протокол резервирования ресурсов RSVP

53

280

4.4.9.7 Протокол COPS (Common Open Policy Service)

24

110

4.4.10 Протокол загрузки BOOTP

3

30

4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

10

86

4.4.11.1 Внутренний протокол маршрутизации RIP

5

5

4.4.11.2 Протокол OSPF (алгоритм Дикстры)

16

164

4.4.11.3 Протокол IGRP

7

28

4.4.11.4 Внешний протокол BGP

10

89

4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)

1

4

4.4.11.6 Автономные системы

1

4

4.4.11.7 Маршрутная политика

5

17

4.4.11.8 Язык описания маршрутной политики RPSL

46

196

4.4.12 DNS (структура, обработка запросов, ресурсные записи)

15

100

4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP

53

235

4.4.13 Протокол управления SNMP

6

52

4.4.13.1 Управляющая база данных MIB

25

118

4.4.13.2 Нотация ASN.1

16

63

4.4.14 Протокол электронной почты SMTP

5

39

4.4.14.1 Протокол обмена UUCP

12

80

4.4.14.2 Почтовый протокол POP3

5

15

4.4.14.3 Протокол Интернет для работы с сообщениями IMAP

44

177

4.4.14.4 Многоцелевое расширение почты Интернет (MIME)

60

272

4.4.14.5 Программа Sendmail

3

8

4.4.15 Сетевой протокол времени NTP

47

190

4.4.16 Протокол SNTP

11

68

4.4.17 Введение в MPLS, TE и QoS

15

150

4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

40

250

4.4.19 Кодирование меток в MPLS

12

67

4.4.20 Требования для управления трафиком

18

92

4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)

17

200

4.4.21 BGP/MPLS VPN

18

78

4.5 Процедуры Интернет

1

9

4.5.1 Ping и Traceroute

4

27

4.5.2 Finger

3

46

4.5.3 Удаленный доступ (Telnet)

8

48

4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS

30

134

4.5.4 Протокол пересылки файлов FTP

10

79

4.5.4.1 Протокол TFTP

3

21

4.5.5 Протокол X-Windows

2

33

4.5.6 WWW

12

82

4.5.6.1 Гипертекстный протокол HTTP

110

127

4.5.6.2 Язык HTML

130

727

4.5.7 Протокол новостей NNTP

10

45

4.5.7.1 Работа с сервером новостей

6

36

4.5.8 Поиск узлов и людей

1

3

4.5.8.1 Whois

5

31

4.5.8.2 FRED

4

22

4.5.8.3 X500

5

20

4.5.8.4 Система поиска NETFIND

5

22

4.5.9 Серверы подписки (LISTSERV)

12

38

4.5.10 Электронная почта

12

200

4.5.11 Gopher

4

27

4.5.12 WAIS

7

49

4.5.13 Система поиска файлов Archie

7

34

4.5.14 Современные поисковые системы

16

186

4.5.15 Диалог в локальных сетях и в Интернет

5

46

4.5.16 Некоторые другие процедуры Интернет

3

46

4.5.17 Сетевое моделирование

8

66

4.6 Электронная торговля в Интернет

7

60

4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0

189

2200

4.6.2 SET и другие системы осуществления платежей

180

1250

4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8

38

194

4.6.4 Смарт-карты EMV

37

368

5 Диагностика локальных сетей и Интернет

15

91

5.1 Сетевая диагностика с применением протокола SNMP

14

209

5.2 Диагностика на базе ICMP

4

23

5.3 Применение 6-го режима сетевого адаптера для целей диагностики

2

12

5.4 Причины циклов пакетов и осцилляции маршрутов

2

14

5.5 Конфигурирование сетевых систем

3

15

6 Сетевая безопасность

20

219

6.1 Технические средства сетевой безопасности

3

21

6.2 Виртуальные локальные сети VLAN, Интранет

4

26

6.3 Система Firewall

2

69

6.3.1 Список видов атак, зарегистрированных Network ICE

35

150

6.4 Системы шифрования

4

38

6.4.1 Алгоритм DES

5

47

6.4.2 Алгоритм шифрования RSA

6

9

6.4.3 Электронная подпись

4

28

6.4.4 Безопасная почта PGP

3

10

6.4.5 Алгоритм Эль Гамаля

1

4

6.4.6 Алгоритм Диффи-Хелмана

1

3

6.4.7 IDEA - международный алгоритм шифрования данных

5

51

6.4.8 Алгоритм шифрования SAFER

4

6

6.4.9 Аутентификация в Интернет

9

13

6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования

4

58

6.5 Протокол SSL. Безопасный уровень соединителей

21

37

6.6 Безопасное ядро (SSH)

2

9

6.7 Безопасность WEB-серверов

2

10

6.8 Протокол TLS версия 1.0

49

250

6.9 Квантовая криптография

6

54

6.10 Идентификатор доступа к сети

32

11

7 Программирование для сетей (новые идеи, принципы и возможности)

1

7

7.1 Winsock (для UNIX, Windows-95 и -NT)

48

712

7.2 Сетевые драйверы

16

134

8 Заключение

2

20

8.1 Вопросы по данному курсу

20

90

9 Литература

2

231

10 Приложения

1

8

10.1 Рекомендации CCITT по телекоммуникациям

10

88

10.2 Коды протоколов в Ethernet II

2

11

10.3 Стандартные мультикастинг-адреса Интернет

2

2

10.4 Таблица операций и субопераций NCP

8

8

10.5 Таблица операций службы каталогов Netware

2

9

10.6 Таблица типов кадров управления доступом для сети Token Ring

2

13

10.7 Типы субвекторов кадров управления доступом

2

11

10.8 Управляющие регистры модемов и их функции

6

38

10.9 Набор AT-команд модемов

4

25

10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)

210

1826

10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций

5

25

10.12 Национальные коды доменов в Интернет

7

7

10.13 Список кодов и откликов на почтовые команды и сообщения

1

7

10.14 Принципы формирования кода отклика в системе SMTP

1

5

10.15 Базовые протоколы Internet

2

15

10.16 Разъем AUI

1

5

10.17 Разводка разъемов

3

93

10.18 Краткий справочник по командам UNIX

27

80

10.19 Символьный набор HTML

8

131

10.20 Справочные данные по математике

10

122

10.21 Элементы теории графов

6

69

10.22 Имена временных зон

1

3

10.23 Модель машины конечных состояний

1

3

10.24 Сети Петри

2

33

10.25 Интернет вчера, сегодня и завтра

8

250

10.26 Таблица цветов, их имен и кодов

3

38

10.27 Законы Мерфи для программистов

1

1

11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

13

40


Down: 1 Введение (общие принципы построения сетей)    Next: 1 Введение (общие принципы построения сетей)


down next index index
Down: 1 Введение (общие принципы построения сетей)
    Next: 1 Введение (общие принципы построения сетей)

Предисловие
Семенов Ю.А. (ГНЦ ИТЭФ)

Rambler's Top100

Telecommunication technologies - телекоммуникационные технологии (v2.1)

Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001, 1100 стр.) и "Протоколы Internet для электронной торговли" ("Горячая линия - Телеком", М. 2003, 730стр.), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".



В последней из книг содержится раздел, где выпускник кафедры ТСС МФТИ С.Джужа, рассказывает о своем опыте разработок в данной сфере. В сумме эти книги содержат около 2550 страниц, а на данном сервере размещается более 2800 стандартных книжных страниц (формат A4, times-12, следует заметить, что содержимое книг частично перекрывается). Причин здесь несколько.

Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные описания протоколов (конспективность здесь неизбежна) и представить необходимые справочные материалы. Сервер, включая рисунки и формулы, содержит более 1000 файлов.

Во-вторых, данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий. Ускорение, которое достижимо в этом случае очевидно. Но у этого метода есть и несомненные недостатки - в книжном издательстве за ошибки отвечает редактор и корректор, а здесь автору это свалить не на кого. Практически невозможно избежать и некорректности сетевых ссылок, в Интернет все меняется слишком быстро. То что ещё вчера было доступно, сегодня может более не существовать. Зато вместо этого появляется несколько новых, чаще всего более емких ссылок. По этой причине я заранее прошу извинения за ошибки, содержащиеся в текстах, размещенных на сервере. Эта работа заняла несколько лет, сейчас мне очень трудно обнаружить даже некоторые очевидные описки и ошибки, ведь я вижу не тот текст, что читаете вы, а тот, который я намеревался написать, а это не одно и то же. Буду весьма признателен читателям, обнаружившим любые ошибки и приславшим замечания. Это позволит мало-помалу привести материалы в должный порядок, сделать их более полными (общими силами это будет сделать легче). Надеюсь, что неизбежные ошибки не слишком испортят настроение читателей. Будут приниматься и пожелания по размещению новых материалов. Предполагается размещение новых материалов и других авторов. Окончательное решение по вопросу постановки таких статей будет приниматься мной. Авторские права в таких случаях будут неукоснительно соблюдаться.

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

Помимо стандартных гиперссылок каждая из статей содержит в верхней части кнопки управления. <previous> - для перехода к предыдущей статье; <up> - к предыдущему разделу; <down> - к следующему разделу; <next> - для перехода к следующей статье; а также кнопка <index>, которая служит для обращения к оглавлению. Объем статей (в килобайтах) указан с учетом рисунков, хранящихся в виде отдельных файлов. Самая правая клавиша <ПОИСК> осуществляет переход на страницу, где размещена форма, позволяющая выполнить поиск в пределах данного сервера. При этом выдаются ссылки на все статьи (и позиции), где имеются представленные ключевые слова.

Надеюсь, что данный сервер окажется для вас полезным.

В дальнейшем предполагается предложить версию сервера на CD со встроенной поисковой системой. Для студентов и всех желающих создан тренажер для проверки знаний по отдельным разделам (saturn.itep.ru и http://knowtest.itep.ru). Для просмотра сервера желательно использовать версии Netscape communicator v4+ и MS Internet Explorer с версией 5+. Тренажер и многие программы из http:/saturn.itep.ru работают исключительно с MS Internet Explorer.

Для некоммерческих целей читатели могут использовать данные тексты без ограничений. Размещение полных текстов или фрагментов на других серверах без согласия автора не допускается. ╘

Данная версия сервера сформирована с использованием базы данных MySQL, куда были помещены все статьи. Дизайн страниц и формирование индексов определяется шаблонами, что облегчает любые изменения. Программы для этого были подготовлены сотрудником ИТЭФ Михаилом Крикуном (admin@ol.ru). Им же была поставлена поисковая система. Сервер размещен на ЭВМ saturn.itep.ru, администратор - Роман Нилов (Roman@itep.ru).

По вопросам приобретения книг "Протоколы Интернет. Энциклопедия" и "Протоколы Internet для электронной торговли" ("Горячая линия - Телеком", Москва, 2003г) следует обращаться к Занину Евгению Александровичу по телефону 287-49-56 (radios_hl@mtu-net.ru)

Зам. зав. кафедры "Телекоммуникационные сети и системы" МФТИ
Нач. лаб. Института Теоретической и Экспериментальной Физики (semenov@itep.ru)

Семенов Юрий Алексеевич


Down: 1 Введение (общие принципы построения сетей)    Next: 1 Введение (общие принципы построения сетей)


previous up down next index index
Previous: Предисловие    UP: Предисловие
Down: 2 Преобразование, кодировка и передача информации
    Next: 2 Преобразование, кодировка и передача информации

1 Введение (общие принципы построения сетей)
Семенов Ю.А. (ГНЦ ИТЭФ)

Интернет является сетью виртуальных сетей. В 1991 году у нас (тогда еще в СССР) о нем знали несколько десятков человек, которые только что освоили электронную почту (через RELCOM) и попробовали, что такое FidoNet. Первое сообщение по электронной почте было послано президентом США Биллом Клинтоном 2 марта 1993 года. Первая новелла Стивена Кинга была опубликована по каналам Интернет 19 сентября 1993 года (до появления печатной копии), к тому же году относится начало синхронной передачи радио-программ по сетям Интернет. В конце 1993 года заработала первая очередь оптоволоконной опорной сети Москвы, полностью профинансированная Джорджем Соросом. В 1994 году НАТО организовало первую конференцию по Интернет в России (в Голицыно под Москвой). С помощью DFN (Deutsche Forschung Naetze), а затем Дж. Сороса и RELARN круг любителей Интернет расширился до сотен и тысяч, а после включения программ Минвуза и Министерства науки РФ счет пошел на десятки тысяч. Это произошло прежде всего потому, что созрели условия - в различных учреждениях (сначала научных, а затем коммерческих и государственных) и у частных лиц оказались сотни тысяч персональных ЭВМ. К этому же времени (1992-93 годы) в мире стала формироваться сеть депозитариев, доступных через анонимный доступ (FTP), а несколько позднее и WWW-серверов. На рис. 1.1 показан рост числа ЭВМ, подключенных к Интернет по годам с 1989 по 1998 годы. Видно, что рост числа узлов сети имеет экспоненциальный характер. Можно смело утверждать, что протоколы Интернет, созданные для осуществления связи в случае нанесения десятков ядерных ударов по США со стороны СССР, явились одним из немногих (возможно единственным) положительным результатом холодной войны.


Рис. 1.1. Рост числа ЭВМ, подключенных к Интернет в период 1989-98 годы (по вертикальной оси отложено число ЭВМ в миллионах)

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

Современные сети Интернет объединяют в единое целое многие десятки (а может быть уже и сотни) тысяч локальных сетей по всему миру, построенных на базе самых разных физических и логических протоколов (ethernet, Token Ring, ISDN, X.25, Frame Relay, Arcnet и т.д.). Эти сети объединяются друг с другом с помощью последовательных каналов (протоколы SLIP, PPP), сетей типа FDDI(часто используется и в локальных сетях), ATM, SDH(Sonet) и многих других. В самих сетях используются протоколы TCP/IP (Интернет), IPX/SPX (Novell), Appletalk, Decnet, Netbios и бесконечное множество других, признанных международными, являющихся фирменными и т.д. Картина будет неполной, если не отметить многообразие сетевых программных продуктов. На следующем уровне представлены разнообразные внутренние (RIP, IGRP, OSPF) и внешние (BGP и т.д.) протоколы маршрутизации и маршрутной политики, конфигурация сети и задание огромного числа параметров, проблемы диагностики и сетевой безопасности. Немалую трудность может вызвать и выбор прикладных программных средств (Netscape, MS Internet Explorer и пр.). В последнее время сети внедряются в управление (CAN), сферу развлечений, торговлю, происходит соединение сетей Интернет и кабельного телевидения.

Что явилось причиной стремительного роста сети Интернет? Создатели базовых протоколов (TCP/IP) заложили в них несколько простых и эффективных принципов: инкапсуляцию пакетов, фрагментацию/дефрагментацию сообщений и динамическую маршрутизацию путей доставки. Именно эти идеи позволили объединить сети, базирующиеся на самых разных операционных системах (Windows, Unix, Sunos и пр.), использующих различное оборудование (Ethernet, Token Ring, FDDI, ISDN, ATM, SDH и т.д.) и сделать сеть нечувствительной к локальным отказам аппаратуры. Огромный размер современной сети порождает ряд серьезных проблем. Любое усовершенствование протоколов должно проводиться так, чтобы это не приводило к замене оборудования или программ во всей или даже части сети. Достигается это за счет того, что при установлении связи стороны автоматически выясняют сначала, какие протоколы они поддерживают, и связь реализуется на общем для обеих сторон наиболее современном протоколе (примером может служить использование расширения протокола smtp - MIME). В кабельном сегменте современной локальной сети можно обнаружить пакеты TCP/IP, IPX/SPX (Novell), Appletalk, которые успешно сосуществуют.

Проектировщикам и создателям сетей приходится учитывать многие десятки факторов при выборе того или иного типа сети, сетевого оборудования, операционной системы (UNIX, MS-DOS, IRIS, Windows-NT, SOLARIS или что-то еще), программного обеспечения, внешних каналов связи (выделенный канал, коммутируемая телефонная сеть, цифровая сеть, радио или спутниковый канал) и в конце концов сервис-провайдера. За всем этим стоят как технологические проблемы, так и финансовые трудности, тяжелый выбор между дешевой и хорошей сетью.

Если вас интересуют оригинальные тексты протоколов Интернет, вы можете получить их, например, через анонимное FTP по адресу ds.internic.net (в каталоге RFC) или на нашем сервере store.in.ru/rfcs (зеркало). Эти документы можно найти и в других депозитариях.

Документы RFC делятся на стандарты, проекты стандартов, временные (экспериментальные) регламентации и предложения. Чем больше номер RFC, тем более поздней дате этот документ соответствует. О статусе тех или иных RFCможно узнать из RFC-1500 и -1780 (см. также файл std-inde.txt из того же депозитария, что и rfc-index.txt). Если вы хотите найти какой-то RFC-документ, начните с просмотра индексного файла (напр. rfc-index.txt). Первый документ RFC был выпущен в 1969 году более 30 лет тому назад. Далее темп публикаций варьировался в довольно широких пределах, в 1997-99 годах наблюдается заметный всплеск активности, связанный с потребностями мультимедиа (RTP, RSVP, PIM и т.д.), безопасностью и IPv6. Вариация публикаций документов RFC по годам представлена на рис 1.2.

Рис. 1.2. Распределение публикаций документов RFC по годам с 1969 по 1999

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

Но все по порядку. Начнем с того, как устроен Интернет. На рис. 1.3 показана общая схема, которая облегчит дальнейшее обсуждение данной проблематики (буквами R отмечены маршрутизаторы-порты локальных сетей).

Каждая из сетей, составляющих Интернет, может быть реализована на разных принципах, это может быть Ethernet (наиболее популярное оборудование), Token Ring (вторая по популярности сеть), ISDN, X.25, FDDI или Arcnet. Все внешние связи локальной сети осуществляются через порты-маршрутизаторы (R). Если в локальной сети использованы сети с разными протоколами на физическом уровне, они объединяются через специальные шлюзы (например, Ethernet-Fast_Ethernet, Ethernet-Arcnet, Ethernet-FDDI и т.д.). Выбор топологии связей определяется многими факторами, не последнюю роль играет надежность. Использование современных динамических внешних протоколов маршрутизации, например BGP-4, позволяет автоматически переключаться на один из альтернативных маршрутов, если основной внешний канал отказал. Поэтому для обеспечения надежности желательно иметь не менее двух внешних связей. Сеть LAN-6 (см. рис. 1.3) при выходе из строя канала R2-R6 окажется изолированной, а узел LAN-7 останется в сети Интернет даже после отказа трех внешних каналов.

Широкому распространению Интернет способствует возможность интегрировать самые разные сети, при построении которых использованы разные аппаратные и программные принципы. Достигается это за счет того, что для подключения к Интернет не требуется какого-либо специального оборудования (маршрутизаторы не в счет, ведь это ЭВМ, где программа маршрутизации реализована аппаратно). Некоторые протоколы из набора TCP/IP (ARP, SNMP) стали универсальными и используются в сетях, построенных по совершенно иным принципам.

Рис. 1.3. Схема построения сети Интернет

В некотором смысле Интернет возник эволюционно - в начале был Bitnet, fidonet, usenet и т.д. Со временем стало ясно, что конкуренция сетей должна быть заменена их объединением, так как от этого выигрывают все и пользователи и сервис-провайдеры. Ведь объединенная сеть имеет большие информационные ресурсы, может предложить более широкий список услуг и становится по этой причине привлекательной для еще большего числа клиентов.

Технология WWW-серверов сделала Интернет важной средой для целевой рекламы, приближенной к конечному потребителю. Стремительный рост числа узлов www продемонстрирован на рис. 1.4. Здесь также наблюдается экспоненциальный рост. Сам факт использования Интернет для обливания грязью кандидатов во время предвыборной компании, говорит о том, что эта технология освоена и признана эффективной нашими политиками. Наше общество с удивительным упорством сначала осваивают все негативное, оставляя, очевидно, позитивное на десерт.

Рис. 1.4. Рост числа узлов WWW в период 1994-99 годы

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

Современные системы мультимедиа позволяют совместить телевизор, видеомагнитофон, факс и видеотелефон, причем это не фантазия на тему далекого будущего - это услуги доступные уже сегодня (при наличии широкополосного канала связи (64-512 Кбит/с)). Если вы имеете доступ к Интернет, вам уже не нужно платить за международные телефонные переговоры, вы можете сделать это с помощью ip-phone или другого аналогичного продукта, при условии что ваш партнер также имеет доступ к Интернет (данное требование в ближайшем будущем перестанет быть обязательным). Все более широкий круг услуг предлагает Интернет и в сфере развлечений. Здесь имеются игровые серверы, аренда обычных и сетевых компьютерных игр, различные конкурсы и соревнования.

Теперь рассмотрим, как строятся каналы связи (стрелки на рис. 1.5). В простейшем случае связь можно организовать через городскую коммутируемую телефонную сеть, для этого нужны модемы - по одному на каждой из сторон канала (Рис. 1.5a). Традиционные модемы могут обеспечить при хорошем качестве коммутируемой аналоговой телефонной сети пропускную способность до 56 Кбит/с (кабельные широкополосные модемы при длине соединения порядка 2км могут обеспечить 2 Мбит/с). Привлекательность такого решения заключается в возможности подключения к любому узлу, имеющему модемный вход. Наиболее широко указанный метод связи используется для подключения к узлам Интернет домашних ЭВМ. Недостатком такого решения является низкая надежность канала (особенно в России), малая пропускная способность и необходимость большого числа входных телефонных каналов и модемов.

Использование выделенной 2- или 4-проводной линии (рис. 1.5Б) обеспечивает большую надежность и пропускную способность (до 256 кбит/с при длинах канала < 10 км). Но и здесь на каждый вход требуется отдельный модем, да и скоростные модемы, работающие на выделенную линию, относительно дороги. Выделенные линии чаще служат для межсетевого соединения (рис. 1.5В). Функциональным аналогом выделенных линий являются оптоволоконные, спутниковые и радио-релейные каналы. Этот вариант позволяет строить сети с пропускной способностью в несколько 1-100 Мбит/с и более.

Привлекательные возможности предлагают цифровые сети ISDN. Здесь можно использовать групповые телефонные номера, когда пара модемов обслуживает 10 и более пользователей (ведь они работают, как правило, не все одновременно). Кроме того, ISDN предлагает пользователям каналы с пропускной способностью не ниже 64кбит/c, а при необходимости возможно формирование и более широкополосных каналов. ISDN позволяет делить один и тот же канал между многими пользователями для передачи данных, факсов и телефонных переговоров. isdn органично стыкуется с внешними каналами X.25. К недостаткам системы следует отнести ограниченность ширины окна (число переданных пакетов без получения подтверждения приема), что делает неэффективным использование широкополосных и особенно спутниковых каналов. В области межсетевых связей свою нишу занимает Frame Relay. Этот протокол имеет контроль перегрузок, работающий на аппаратном уровне

Рис. 1.5. Схемы каналов, использующих городскую телефонную сеть

На рис. 1.5 показана схема построения сети с использованием исключительно соединений типа точка-точка. Это наиболее часто встречающийся, но не единственный вариант. Дорога 'от околицы до околицы' прокладывается там, где она нужна и теми, кому она нужна непосредственно, но, согласитесь, построить так магистраль Москва Санкт-Петербург нельзя. При построении крупных общенациональных и интернациональных сетей применяются сверхширокополосные каналы и схемы типа опорной сети (backbone). Узлы такой сети могут располагаться в каких-то крупных организациях или быть самостоятельными (принадлежать государственным PTT). Такие сети обычно базируются на протоколах SDH (Sonet). Информация в этих сетях передается в виде больших блоков (виртуальных контейнеров). Использование опорной сети обычно оправдано при организации интернациональных связей, но бывают и исключения. Примером такого исключения является Московская опорная сеть, построенная на основе FDDI (100Мбит/с) и объединяющая более десяти научных организаций (длина первой очереди около 30 км). Московская сеть выполнена по схеме с 'прозрачными' IP-мостами, обычно же более мощные опорные сети маршрутизируемы, то есть блоки данных адресуются конкретным узлам, где они разбираются и сортируются. Контейнер может содержать сообщения, адресованные разным получателям, что несколько противоречит идеологии протоколов TCP/IP. IP-пакеты могут вкладываться в эти контейнеры и транспортироваться до заданного узла опорной сети. Классическим примером опорной сети является E-bone (Европейская опорная сеть). Эта сеть объединяет 27 стран (России в этом списке нет) и более 60 сервис-провайдеров, пропускная способность для различных участков лежит в пределах 2-34Мбит/с. Опорная сеть подобна международной автомагистрали, по ней добираются до ближайшего к точке назначения узла, а далее по 'проселочным' каналам до конечного адресата.

Резкое увеличение передаваемых объемов информации в локальных и региональных сетях привело к исчерпанию имеющихся ресурсов, а реальные прогнозы потребностей указывают на продолжение роста потоков в десятки и сотни раз. Единственной технологией, которая способна удовлетворить эти потребности, являются оптоволоконные сети (Sonet, SDH, ATM, FDDI, Fiber Channel). Каналы этих сетей уже сегодня способны обеспечить пропускную способность 155-622 Мбит/с, ведутся разработки и испытания каналов с пропускной способностью в 2-20 раз больше, например, гигабитного ethernet. Осваивается техника мультиплексирования частот в оптоволокне (WDM), что позволяет поднять его широкополосность в 32 раза и в перспективе довести быстродействие каналов до 80 Гбит/с и более. По мере роста пропускной способности возрастают проблемы управления, синхронизации и надежности. Практически все сети строятся сегодня с использованием последовательных каналов. Это связано прежде всего со стоимостью кабелей, хотя и здесь существуют исключения (например, HIPPI). Разные сетевые услуги предъявляют разные требования к широкополосности канала. На рис. 1.6 представлены частотные диапазоны для основных видов телекоммуникационных услуг. В Интернет практически все перечисленные услуги доступны уже сегодня (кроме ТВ высокого разрешения). Стремительно развиваются распределенные системы вычислений (например, проект GREED), управления и информационного обслуживания. Современная технология микропроцессоров предполагает достижение быстродействия в 5 Гбит/с к 2003-4 годам (технология с характеристическим размером объектов на кристалле 80-130 нм).

Рис. 1.6. Требования к пропускной способности канала для различных видов сервиса.

Рассмотрев диаграмму, можно сделать определенные прогнозы на ближайшее будущее сетей. Через несколько лет можно ожидать слияния функций телевизора и ЭВМ, а это потребует пропускных способностей от магистральных каналов на уровне 0,1-10 Гбит/с. Широкополосность каналов, приходящих в каждый семейный дом составит 1-10 Мбит/с, что позволит реализовать видео-телефонию, цифровое телевидение высокого разрешения, доступ к централизованным информационным службам и многое другое. Уже существующие оптоволоконные системы обеспечивают и в 10 раз большую пропускную способность. Можно предположить и появление локальных сетей внутри жилища. Такие сети способны взять под контроль кондиционирование воздуха, безопасность дома в самом широком смысле этого слова, например, оповещение о нежелательном вторжении, пожаре или возможном землетрясении (в сейсмически опасных районах), появление вредных примесей в воздухе. Такая система разбудит хозяина в указанное время, подогреет завтрак, напомнит о предстоящих делах на день, запросит и предоставит хозяину свежий прогноз погоды и справку о состоянии дорог, своевременно сделает заказ на авиабилет и т.д. Все это технологически возможно уже сегодня, пока относительно дорого, но цены весьма быстро падают. Примером может служить сеть CAN, разработанная для сбора данных и управления автомобилем. Стремительное расширение сети Интернет не имеет аналогов в истории, так что любой самый фантастический прогноз в этой области может сбыться.

Протоколы Интернет (TCP/IP) существуют уже около 30 лет. Требования к телекоммуникационным каналам и услугам выросли, и этот набор протоколов не удовлетворяет современным требованиям. Появляются новые протоколы Delta-t (для управления соединением), NetBLT (для передачи больших объемов данных), VMTP (для транзакций; RFC-1045) и XTP для повышения эффективности передачи данных (замена TCP), блоки протоколов для работы с мультимедиа (RTP, RSVP, PIM, ST-II и пр.), но, безусловно, наиболее революционные преобразования вызовет внедрение IPv6.

Previous: Предисловие    UP: Предисловие
Down: 2 Преобразование, кодировка и передача информации    Next: 2 Преобразование, кодировка и передача информации


down next index index
Down: 1 Введение (общие принципы построения сетей)
    Next: 1 Введение (общие принципы построения сетей)

Оглавление
Семенов Ю.А. (ГНЦ ИТЭФ)

IP - TCP - UDP - ARP - RARP - ICMP - BOOTP - IPv6 - HTTP - SNMP - SMTP - RIP - OSPF - BGP - DNS - IGMP - PIM - DVRMP - MIB - ASN - NNTP - RSVP - RTP - RTCP - FTP - TFTP - TELNET - WWW - HTML - XML - SSL - RSA - ISDN - SET - ATM - SDH - X.25 - ETHERNET - FE - FIBRE CHANNEL - HIPPI - IOTP - TLS

Номер раздела Название раздела Объем в страницах Объем в кбайт
Предисловие

3

60

Оглавление

8

7

1 Введение (общие принципы построения сетей)

9

7

2 Преобразование, кодировка и передача информации

4

3

2.1 Передача сигналов по линиям связи

8

6

2.1.1 Влияние шумов и помех

2

2

2.2 Представление электрических сигналов в цифровой форме

10

7

2.3 Цифровые каналы T1 и Е1

2

1

2.4 Методы преобразования и передачи звуковых сигналов

6

5

2.4.1 Дельта-модуляция

1

1

2.4.2 Кодировщики голоса (Vocoder)

2

2

2.4.3 Передача голоса по каналам Интернет

4

2

2.5 Методы преобразования и передачи изображения

14

12

2.5.1 Стандарт MPEG-4

67

1000

2.5.2 Стандарт MPEG-7

59

1400

2.6 Методы сжатия информации

3

3

2.6.1 Алгоритм Зива-Лемпеля

3

3

2.6.2 Локально адаптивный алгоритм сжатия

2

2

2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

1

1

2.6.4 Метод Шеннона-Фано

1

3

2.6.5 Статический алгоритм Хафмана

1

1

2.7 Обнаружение ошибок

2

2

2.8 Коррекция ошибок

6

6

2.9 Видеоконференции по каналам Интернет и ISDN

8

97

2.9.1 Используемые стандарты

2

2

2.10 Статистическая теория каналов связи

10

145

3 Каналы передачи данных

1

1

3.1 Кабельные каналы связи

7

106

3.2 Оптоволоконные каналы

10

8

3.3 Беспроводные (радио) каналы и сети

11

8

3.4 Протокол SLIP

2

20

3.5 Протокол PPP

9

8

3.6 Протокол G.703

1

21

4 Сети передачи данных. Методы доступа

14

13

4.1 Локальные сети (обзор)

1

1

4.1.1 Ethernet (IEEE 802.3)

1

1

4.1.1.1 Архитектура сетей Ethernet

11

12

4.1.1.2 Fast Ethernet

10

9

4.1.1.3 Интернет в Ethernet

9

7

4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы

7

7

4.1.2 IEEE 802.5 (Token Ring)

12

12

4.1.3 IEEE 802.4 (Маркерная шина)

3

22

4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)

5

75

4.1.5 Локальные сети ArcNet

4

139

4.1.6 Сети FDDI

8

328

4.1.7 Параллельный сетевой интерфейс HIPPI

4

37

4.1.8 Сети IEEE 802.11

3

58

4.1.8.1 Мобильные телекоммуникации

7

168

4.1.9 Сети DQDB (двойная шина с распределенной очередью)

3

29

4.1.10 Сети с многокаскадными соединениями

1

19

4.1.11 Сети 100Base-VG

1

4

4.1.12 Канальный протокол Fibre Channel

4

35

4.1.13 Коммутируемая мультимегабитная информационная служба SMDS

2

17

4.2 Наложенные сети

1

6

4.2.1 Протоколы Novell (IPX/SPX)

1

5

4.2.1.1 IPX-протокол

4

60

4.2.1.2 SPX-протокол

2

26

4.2.1.3 Протокол ядра NetWare (NCP)

3

18

4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)

3

24

4.2.1.5 Служба каталогов NetWare (NDS)

4

52

4.2.2 AppleTalk

4

52

4.2.3 NetBIOS

5

16

4.3 Региональные сети

1

5

4.3.1 Эталонная сетевая модель ISO

5

68

4.3.2 Протоколы сетей X.25

18

213

4.3.3 Интегрированные сети ISDN

25

451

4.3.4 Протокол Frame Relay

6

77

4.3.5 Протоколы сетей ATM

21

254

4.3.6 Синхронные каналы SDH/SONET

9

165

4.3.7 Модемы

10

126

4.4 Интернет

3

2

4.4.1 IP-протокол

10

91

4.4.1.1 Адресация IPv6

45

45

4.4.1.2 IP-туннели

1

87

4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)

48

48

4.4.2 Протокол UDP

7

5

4.4.3 Протокол TCP

15

135

4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)

10

93

4.4.5 Протокол XTP

10

103

4.4.6 Протокол преобразования адресов ARP

4

141

4.4.7 Прокси-ARP

1

11

4.4.8 Протокол обратного адресного преобразования RARP

1

13

4.4.9 Протокол IGMP

3

20

4.4.9.1 Мультикастинг и MBONE

2

7

4.4.9.2 Протокол реального времени RTP

22

86

4.4.9.3 Транспортный протокол реального времени RTCP

25

157

4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP

2

12

4.4.9.5 Протокол PIM

17

154

4.4.9.6 Протокол резервирования ресурсов RSVP

53

280

4.4.9.7 Протокол COPS (Common Open Policy Service)

24

110

4.4.10 Протокол загрузки BOOTP

3

30

4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

10

86

4.4.11.1 Внутренний протокол маршрутизации RIP

5

5

4.4.11.2 Протокол OSPF (алгоритм Дикстры)

16

164

4.4.11.3 Протокол IGRP

7

28

4.4.11.4 Внешний протокол BGP

10

89

4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)

1

4

4.4.11.6 Автономные системы

1

4

4.4.11.7 Маршрутная политика

5

17

4.4.11.8 Язык описания маршрутной политики RPSL

46

196

4.4.12 DNS (структура, обработка запросов, ресурсные записи)

15

100

4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP

53

235

4.4.13 Протокол управления SNMP

6

52

4.4.13.1 Управляющая база данных MIB

25

118

4.4.13.2 Нотация ASN.1

16

63

4.4.14 Протокол электронной почты SMTP

5

39

4.4.14.1 Протокол обмена UUCP

12

80

4.4.14.2 Почтовый протокол POP3

5

15

4.4.14.3 Протокол Интернет для работы с сообщениями IMAP

44

177

4.4.14.4 Многоцелевое расширение почты Интернет (MIME)

60

272

4.4.14.5 Программа Sendmail

3

8

4.4.15 Сетевой протокол времени NTP

47

190

4.4.16 Протокол SNTP

11

68

4.4.17 Введение в MPLS, TE и QoS

15

150

4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

40

250

4.4.19 Кодирование меток в MPLS

12

67

4.4.20 Требования для управления трафиком

18

92

4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)

17

200

4.4.21 BGP/MPLS VPN

18

78

4.5 Процедуры Интернет

1

9

4.5.1 Ping и Traceroute

4

27

4.5.2 Finger

3

46

4.5.3 Удаленный доступ (Telnet)

8

48

4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS

30

134

4.5.4 Протокол пересылки файлов FTP

10

79

4.5.4.1 Протокол TFTP

3

21

4.5.5 Протокол X-Windows

2

33

4.5.6 WWW

12

82

4.5.6.1 Гипертекстный протокол HTTP

110

127

4.5.6.2 Язык HTML

130

727

4.5.7 Протокол новостей NNTP

10

45

4.5.7.1 Работа с сервером новостей

6

36

4.5.8 Поиск узлов и людей

1

3

4.5.8.1 Whois

5

31

4.5.8.2 FRED

4

22

4.5.8.3 X500

5

20

4.5.8.4 Система поиска NETFIND

5

22

4.5.9 Серверы подписки (LISTSERV)

12

38

4.5.10 Электронная почта

12

200

4.5.11 Gopher

4

27

4.5.12 WAIS

7

49

4.5.13 Система поиска файлов Archie

7

34

4.5.14 Современные поисковые системы

16

186

4.5.15 Диалог в локальных сетях и в Интернет

5

46

4.5.16 Некоторые другие процедуры Интернет

3

46

4.5.17 Сетевое моделирование

8

66

4.6 Электронная торговля в Интернет

7

60

4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0

189

2200

4.6.2 SET и другие системы осуществления платежей

180

1250

4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8

38

194

4.6.4 Смарт-карты EMV

37

368

5 Диагностика локальных сетей и Интернет

15

91

5.1 Сетевая диагностика с применением протокола SNMP

14

209

5.2 Диагностика на базе ICMP

4

23

5.3 Применение 6-го режима сетевого адаптера для целей диагностики

2

12

5.4 Причины циклов пакетов и осцилляции маршрутов

2

14

5.5 Конфигурирование сетевых систем

3

15

6 Сетевая безопасность

20

219

6.1 Технические средства сетевой безопасности

3

21

6.2 Виртуальные локальные сети VLAN, Интранет

4

26

6.3 Система Firewall

2

69

6.3.1 Список видов атак, зарегистрированных Network ICE

35

150

6.4 Системы шифрования

4

38

6.4.1 Алгоритм DES

5

47

6.4.2 Алгоритм шифрования RSA

6

9

6.4.3 Электронная подпись

4

28

6.4.4 Безопасная почта PGP

3

10

6.4.5 Алгоритм Эль Гамаля

1

4

6.4.6 Алгоритм Диффи-Хелмана

1

3

6.4.7 IDEA - международный алгоритм шифрования данных

5

51

6.4.8 Алгоритм шифрования SAFER

4

6

6.4.9 Аутентификация в Интернет

9

13

6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования

4

58

6.5 Протокол SSL. Безопасный уровень соединителей

21

37

6.6 Безопасное ядро (SSH)

2

9

6.7 Безопасность WEB-серверов

2

10

6.8 Протокол TLS версия 1.0

49

250

6.9 Квантовая криптография

6

54

6.10 Идентификатор доступа к сети

32

11

7 Программирование для сетей (новые идеи, принципы и возможности)

1

7

7.1 Winsock (для UNIX, Windows-95 и -NT)

48

712

7.2 Сетевые драйверы

16

134

8 Заключение

2

20

8.1 Вопросы по данному курсу

20

90

9 Литература

2

231

10 Приложения

1

8

10.1 Рекомендации CCITT по телекоммуникациям

10

88

10.2 Коды протоколов в Ethernet II

2

11

10.3 Стандартные мультикастинг-адреса Интернет

2

2

10.4 Таблица операций и субопераций NCP

8

8

10.5 Таблица операций службы каталогов Netware

2

9

10.6 Таблица типов кадров управления доступом для сети Token Ring

2

13

10.7 Типы субвекторов кадров управления доступом

2

11

10.8 Управляющие регистры модемов и их функции

6

38

10.9 Набор AT-команд модемов

4

25

10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)

210

1826

10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций

5

25

10.12 Национальные коды доменов в Интернет

7

7

10.13 Список кодов и откликов на почтовые команды и сообщения

1

7

10.14 Принципы формирования кода отклика в системе SMTP

1

5

10.15 Базовые протоколы Internet

2

15

10.16 Разъем AUI

1

5

10.17 Разводка разъемов

3

93

10.18 Краткий справочник по командам UNIX

27

80

10.19 Символьный набор HTML

8

131

10.20 Справочные данные по математике

10

122

10.21 Элементы теории графов

6

69

10.22 Имена временных зон

1

3

10.23 Модель машины конечных состояний

1

3

10.24 Сети Петри

2

33

10.25 Интернет вчера, сегодня и завтра

8

250

10.26 Таблица цветов, их имен и кодов

3

38

10.27 Законы Мерфи для программистов

1

1

11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

13

40


Down: 1 Введение (общие принципы построения сетей)    Next: 1 Введение (общие принципы построения сетей)


previous up down next index index
Previous: 10 Приложения    UP: 10 Приложения
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.2 Коды протоколов в Ethernet II

10.1 Рекомендации CCITT по телекоммуникациям
Семенов Ю.А. (ГНЦ ИТЭФ)

Коды названий документов ITU, CCITT, ANSI и ECMA по телекоммуникационной тематике начинаются с латинской прописной буквы, за которой следует точка и номер документа. Ниже приведен список кодировок документов и перечень наиболее важных рекомендаций.

E

Операции, нумерация и маршрутизация.

G

Телекоммуникационные системы передачи.

H

Линии передачи для нетелефонных сигналов.

I

Общие материалы по ISDN.

Q

Сигнальные системы.

T

Терминальное оборудование и протоколы телекоммуникационных услуг.

V

Передача данных по коммутируемым телефонным сетям.

X

Сети передачи данных.

Код рекомендации

Содержание

ANSI T1.102

Цифровая иерархия - электрические интерфейсы;

ANSI T1.111-116

Сигнальная система N7;

ANSI T1.403

Конструкция интерфейса DS1

ANSI T1.408

Спецификация связи пользователя с первым уровнем первичного канала;

ANSI T1.602

Интерфейс базового канала, процедура доступа к первичному каналу, D-канал (LAP1); связной протокол BRI/PRI;

ANSI T1.603

Минимальный набор услуг для интерфейса первичного канала ISDN;

ANSI T1.604

Минимальный набор услуг базового канального интерфейса ISDN;

ANSI T1.605

Спецификация интерфейса базового канала для связи пользователя с сетью; спецификация интерфейса BRA S/T;

ANSI T1.606

Описание услуг Frame Relay;

ANSI T1.607

Основные управляющие процедуры для BRI и PRI;

ANSI T1.608

Пакетные режимы канала. Управляющие процедуры BRI и PRI;

ANSI T1.609

Цифровая система подписки N1 ISDN для межсетевых связей в рамках сигнальной системы N7;

ANSI T1.610

Базовые процедуры для управления вспомогательными услугами ISDN;

ANSI T1.617

Сигнальные спецификации для канальных услуг Frame Relay;

ANSI T1.618

Базовые аспекты протокола Frame Relay;

CCIR 601-1

Параметры кодировки студийного цифрового телевидения;

ECMA-104

Физический уровень интерфейса для доступа к первичному каналу в частных телекоммуникационных сетях;

ECMA-105

Протокол уровня канала данных для D-канала интерфейса в эталонной точке между терминальным оборудованием и частной телекоммуникационной сетью;

ECMA-106

Протокол третьего уровня для управления переадресацией вызовов через интерфейс D-канала в эталонной точке S между терминальным оборудованием и частной телекоммуникационной сетью

ECMA-123

Обмен параметрами в частных ISDN-сетях на базе стандарта ECMA-102;

ECMA-133

Эталонная конфигурация для вызовов через коммутатор частной телекоммуникационной сети;

ECMA-134

Метод спецификации базовых и дополнительных видов сервиса в частных телекоммуникационных сетях.

ECMA-135

Алгоритмы связи коммутаторов частных телекоммуникационных сетей;

ECMA-141

Протокол уровня канала данных для эталонной точки Q сигнального канала между коммутаторами частных телекоммуникационных сетей;

ECMA-142

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

ECMA-143

Протокол третьего уровня для управления переадресацией вызовов между коммутаторами частных телекоммуникационных сетей;

ECMA148

Идентификация дополнительных услуг в частных телекоммуникационных сетях; спецификация, функциональные модели и информационные потоки;

ECMA-155

Адресация в частных телекоммуникационных сетях;

ECMA-156

Основные процедуры для управления дополнительными услугами, используя протокол keypad в эталонной точке S.

ECMA-157

Протокол управления по D-каналу в эталонной точке S интерфейсами между терминальным оборудованием и частной телекоммуникационной сетью для поддержки идентификации дополнительных услуг.

F.60

Стандарт телексной связи

F.69

Стандарт для телексных адресов

F.160

Стандарт на международную общественную факсную связь

F.200

Стандарт телетекстной связи

F.201

Стандарт для служб межсетевого обмена для телетекста и телекса

F.300

Набор рекомендаций для систем видеотекста

F.401

Стандарт на имена и адреса при передаче сообщений

F.410

Стандарт службы передачи сообщений

F.420

Стандарт для частного обмена сообщениями

F.421

Стандарт для коммуникаций между системами X.400 для обмена частными и телексными сообщениями

F.500

Стандарт международной службы каталогов

G.702

Иерархия цифровых скоростей обмена

G.703

Физические и электрические характеристики цифровых интерфейсов.

G.707

Иерархия частот синхронной передачи двоичной цифровой информации

G.708

Синхронный интерфейс сетевого узла для цифровой передачи данных в широком диапазоне частот следования.

G.709

Структура синхронного мультиплексирования.

G.711

Импульсно-кодовая модуляция (PCM) голосовых частот.

G.721

Адаптивная дифференциальная кодово-импульсная модуляция (ADPCM) для частоты 32 Кбит/с.

G.722

Аудио кодирование в частотном диапазоне 7 кГц для скоростей передачи 64 Кбит/с.

G.725

Системные аспекты использования 7 килогерцного аудио кодека на скоростях передачи 64 Кбит/с.

G.728

CCITT рекомендация для ADPCM при16 Кбит/с (3.1 кГц)

H.221

Структура кадра канала на 64 Кбит/с для аудио и видео приложений.

H.231

Многоточечный контроль для скоростей 64-2048 Кбит/с

H.242

Коммуникационные процедуры, 64-2048 Кбит/с.

H.243

Многоточечные коммуникационные процедуры, 64-2048 Кбит/с.

H.261

Видео кодек для аудио-видео сервиса при p*64 Кбит/с (p=1-30).

H.320

CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC.

I.110

Введение и общая структура серии документов "I" для интегрированных цифровых сетей ISDN

I.111

Взаимоотношения с другими рекомендациями, относящимися к ISDN

I.112

Словарь терминов ISDN

I.113

Словарь терминов для широкополосной ISDN

I.120

Интегрированные цифровые сети ISDN

I.121

Широкополосные аспекты ISDN

I.122

Рамки для предоставления услуг в канале, работающем в пакетном режиме

I.130

Метод описания телекоммуникационных услуг, поддерживаемых ISDN и сетевые возможности ISDN

I.140

Методика атрибутов для описания телекоммуникационных услуг ISDN сетевых возможностей ISDN

I.141

Атрибуты сети ISDN

I.150

Характеристики ATM B-ISDN

I.200

Указатель по серии рекомендаций I.200

I.210

Принципы предоставления телекоммуникационных услуг ISDN и методы их описания

I.211

Аспекты услуг B-ISDN

I.220

Общее динамическое описание базовых телекоммуникационных услуг

I.221

Общие характеристики услуг

I.327

Функциональная архитектура сетей B-ISDN.

I.230

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

Коммутация каналов

I.231

Категории схемных услуг, предоставляемых каналом

I.231.1

64 Кбит/с (структура по 8кбит/с)

I.231.2

64 Кбит/с (структура по 8кбит/с) с возможностью передачи звуковой информации

I.231.3

64 Кбит/с (структура по 8кбит/с) для аудио-передачи с полосой 3.1 кГц

I.231.4

64 Кбит/с (структура по 8кбит/с) попеременный разговор

I.231.5

2* 64 Кбит/с (структура по 8кбит/с)

I.231.6

384 Кбит/с (структура по 8кбит/с)

I.231.7

1536 Кбит/с (структура по 8кбит/с)

I.231.8

1090 Кбит/с (структура по 8кбит/с)

Коммутация пакетов

I.232

Категории пакетных услуг, предоставляемых каналом

I.232.1

Виртуальный вызов и постоянная виртуальная схема

I.232.2

Бессвязная схема

I.232.3

Пользовательская сигнальная система

I.233.1

Услуги передачи кадров (frame relay) в ISDN - передача кадров

I.233.2

Услуги передачи кадров (frame relay) в ISDN - коммутация кадров

I.240

Определение удаленных услуг

I.241

Удаленные услуги, поддерживаемые ISDN

I.250

Определение дополнительных услуг

I.251

Идентификационные коды вспомогательных услуг

I.252

Запрос вспомогательных услуг

I.253

Завершение выполнения вспомогательных услуг

I.253.1

Ожидание запроса вспомогательных услуг

I.254

Вспомогательные услуги для нескольких клиентов

I.255.4

Приоритетное обслуживание

I.257

Передача дополнительной информации

I.310

Принципы работы сети ISDN

I.311

Общие аспекты сети B-ISDN

I.312(Q.1201)

Принципы архитектуры интеллектуальных сетей

I.320

Эталонная модель протоколов ISDN

I.321

Эталонная модель протоколов B-ISDN и ее применение

I.324

Архитектура сети ISDN

I.325

Типы эталонных конфигураций соединений в ISDN

I.326

Относительные требования к ресурсам сети

I.327

Функциональная архитектура сети B-ISDN

I.328 (Q.1202)

Интеллектуальная сеть - архитектура плоскости услуг

I.329 (Q.1203)

Интеллектуальная сеть - архитектура глобальных функций

I.330

Принципы нумерации и адресации в ISDN

I.331 (E.164)

Схема нумерации в ISDN

I.332

Принципы нумерации для межсетевых соединений ISDN и сетей с различными схемами нумерации

I.333

Выбор терминала в ISDN

I.334

Принципы связи чисел/субадресов ISDN и сетевых адресов эталонной модели OSI

I.335

Принципы маршрутизации ISDN

I.351 (G.821/2)

Рекомендации других серий, связанные c работой сети, для эталонной точки T ISDN

I.352

Объективные характеристики сети, связанные с задержками соединений в ISDN

I.361

Спецификация слоя ATM B-ISDN

I.362

Функциональное описание адаптационного уровня для B-ISDN (AAL).

I.363

Спецификация уровня адаптации (AAL) ATM B-ISDN

I.370

Управление перегрузкой для каналов фрейм-релей ISDN

I.410

Общие аспекты и принципы, связанные с рекомендациями для пользовательского интерфейса ISDN

I.411

Сетевой интерфейс пользователя ISDN - эталонная конфигурация

I.412

Интерфейс пользователя сети ISDN - структура интерфейса возможности доступа

I.413

Интерфейс пользовательской сети B-ISDN

I.420

Базовый сетевой интерфейс пользователя

I.421

Сетевой интерфейс пользователя первичного быстродействия

I.430

Базовый сетевой интерфейс пользователя - спецификация слоя 1

I.431

Сетевой интерфейс пользователя первичного быстродействия - спецификация уровня 1

I.432

Сетевой интерфейс пользователя B-ISDN - спецификация физического уровня

I.440 (Q.920)

Связной информационный уровень сетевого интерфейса пользователя ISDN общие аспекты

I.441 (Q.921)

Сетевой интерфейс пользователя ISDN - спецификация связного информационного уровня

I.450 (Q.930)

Сетевой интерфейс пользователя ISDN - уровень 3, общие аспекты

I.451 (Q.931)

Спецификация уровня 3 для сетевого интерфейса пользователя ISDN для управления базовыми запросами

I.452 (Q.932)

Общие процедуры для управления дополнительными услугами ISDN

I.460

Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов

I.461 (X.30)

Поддержка терминального оборудования (DTE) базирующегося на X.21, X.21бис и X.20бис интегрированными цифровыми сетями (ISDN)

I.462 (X.31)

Базовые процедуры для управления дополнительными услугами ISDN

I.463 (V.110)

Поддержка ISDN терминального оборудования в пакетном режиме

I.464

Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов для передачи на скоростях 64 Кбит/с

I.465 (V.120)

Поддержка ISDN терминального оборудования с интерфейсами типа V при статистическом мультиплексировании

I.470

Взаимодействие терминальных функций и ISDN

I.500

Общая структура рекомендаций для взаимодействия ISDN

I.510

Определения и общие принципы взаимодействия в ISDN

I.511

Интерфейс уровня 1 для системы ISDN-ISDN

I.515

Обмен параметрами при взаимодействии систем ISDN

I.520

Общие принципы организации для межсетевых взаимодействий в ISDN

I.530

Взаимодействие сетей ISDN и публичных коммутируемых телефонных сетей

I.540 (X.321)

Общие приспособления для взаимодействия между сетями ISDN и коммутируемыми публичными телефонными сетями (CSPDN)

I.550 (X.325)

Общие приспособления для взаимодействия между сетями ISDN и публичными сетями с пакетным переключением (PSPDN) для целей передачи информации

I.560 (U.202)

Требования, предъявляемые к системе ISDN для обеспечения телексных услуг

I.601

Общие принципы работы системы доступа для клиента ISDN и инсталляция клиента

I.602

Использование принципов ISDN при инсталляции клиентов

I.603

Использование принципов работы ISDN для обеспечения доступа

I.604

Использование принципов работы ISDN для обеспечения доступа на первичных скоростях обмена

I.605

Применение принципов статического мультиплексирования при реализации базового доступа к ISDN

I.610

OAM-принципы доступа в B-ISDN

ISO 2110

Передача данных 25-контактный соединитель интерфейса DTE-DCE и распределение его контактов.

ISO 2593

Распределение контактов разъема для высокоскоростного терминального оборудования.

ISO 3166

Коды стран (DCC - Data Country Code).

ISO 4902

Передача данных. 37- и 9-контактные разъемы интерфейса DTE-DCE и распределение контактов.

ISO 4903

Передача данных. 15-контактный разъем интерфейса DTE-DCE и распределение контактов.

ISO 8473

Протокол доступа к сети без непосредственной связи (CLNAP ConnectionLess Network Access Protocol)

ISO 8877

Интерфейсный разъем и назначение контактов для эталонных точек доступа ISDN S и T.

ISO 9282-2

Метод сжатия стационарного изображения

ISO 11172-3

Кодировка движущегося изображения и сопровождающего звука для цифровых систем записи при скоростях передачи 1,5 Мбит/с - Часть 3. Звук.

Q.500

Введение и область применения ISDN

Q.512

Интерфейс коммутатора для доступа клиентов ISDN

Q.513

Интерфейс коммутатора для операций, администрирования и обслуживания

Q.521

Функции интерфейса

Q.522

Цифровой коммутатор. Связи, управление, вспомогательные функции

Q.541

Общая конструкция

Q.542

Конструкция, операции и обслуживание

Q.543

Рабочие характеристики систем ISDN

Q.544

Измерения на коммутаторе ISDN

Q.551

Передающие характеристики цифровых коммутаторов

Q.552

Передающие характеристики 2-х проводных аналоговых интерфейсов

Q.553

Передающие характеристики 4-х проводных аналоговых интерфейсов

Q.554

Передающие характеристики цифровых интерфейсов

Q.700-795

Спецификация сигнальной системы N7.

Q.920

Интерфейс пользователя в сети ISDN, общие аспекты связного уровня.

Q.921

Интерфейс пользователя в сети ISDN, спецификация связного уровня.

Q.922

Спецификация ISDN связного уровня для пакетной передачи данных.

Q.930

Интерфейс пользователя в сети ISDN, слой 3, общие принципы.

Q.931

Интерфейс пользователя в сети ISDN, спецификация слоя 3, базовые процедуры управления.

Q.932

Базовые операции управления дополнительными процедурами в ISDN.

Q.933

Цифровая сигнальная подписная система N1 (DSS1), сигнальные модификации для режима передачи кадров

T.4

Стандарт на факсимильное оборудование группы 3 для передачи документации.

T.6

Схемы кодирования изображения и кодирование функций управления для факсимильного оборудования группы 3.

T.81

Кодирование фотографического изображения.

T.411-418

Открытая архитектура документации (ODA)

T.431-433

Манипуляция документами и протокол передачи DTAM.

T.503

Профайл BTO для передачи факсимильных документов группы 4.

T.521

Коммуникационный профайл BTO для пересылки документов большого объема, базирующейся на методике сессий.

T.563

Терминальные характеристики факсимильного оборудования группы 4.

V.24

Перечень определений цепей связи DTE и DCE (для DTE, работающих с модемами). Этой спецификации соответствуют RS-232-C, RS-449-A.

V.28

Электрические характеристики несимметричных цепей интерфейса, работающего с биполярными токовыми сигналами.

X.3

Спецификация ПАД для общественных сетей (X.25)

X.20

DTE-DCE интерфейс старт-стопной передачи данных по сетям общего пользования

X.21

DTE-DCE интерфейс для синхронной передачи данных по сетям общего пользования. Определяет физические характеристики и процедуры управления.

X.21бис

Использование DTE, рассчитанного на сопряжение с синхронными модемами, удовлетворяющими рекомендациям серии V в сетях обмена данными общего пользования

X.22

Мультиплексный интерфейс DTE-DCE для классов обслуживания абонентов 3-6;

X.24

Перечень определений цепей интерфейса DTE-DCE. Определяет функции цепей передачи данных, управления и синхронизации.

X.25

Протокол пакетного уровня для интерфейса DTE-DCE и терминалов, подключенных к общественным сетям.

X.26

Электрические характеристики несимметричных двухполюсных цепей, предназначенных для общего использования в устройствах передачи данных (V.10).

X.27

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

X.28

Интерфейс DTE-DCE для старт-стопного режима работы терминального оборудования, работающего в общественных сетях с использованием ПАД.

X.29

Процедуры обмена управляющей информацией и данными между ПАД и DTE или другим ПАД (пакетный ассемблер-дизассемблер).

X.31

Поддержка терминального оборудования, работающего в пакетном режиме (ISDN).

X.32

Интерфейс DTE-DCE для терминалов, работающих в пакетном режиме и связанных с коммутируемой телефонной сетью общего пользования.

X.75

Терминальные управляющие процедуры и системы передачи данных для международных межсетевых обменов.

X.121

Схема нумерации для общественных информационных сетей

X.150

Испытательные шлейфы DTE и DCE для сетей обмена данными общего пользования.

X.200

Эталонная модель соединения открытых систем для приложений.

X.208

CCITT-версия OSI ASN.1

X.209

Версия OSI ASN.1 базовых правил кодирования (BER)

X.210

Рекомендации по сервису в открытых системах на связном уровне.

X.211

Физическое определение услуг в OSI для CCITT-приложений

X.212

Определения услуг информационных каналов в OSI для CCITT-приложений

X.213

Определения сетевых услуг для связей между открытыми системами.

X.214

Определение транспортных услуг связи открытых систем для приложений CCITT.

X.215

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

X.216

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

X.217

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

X.218

CCITT-эквивалент ISO 9066-1: Надежная пересылка текстов

X.219

Удаленные операции: модель, нотация и описание услуг.

X.223

Использование X.25 для обеспечения сетевой связи в режиме OSI

X.224

Спецификация транспортного протокола связи открытых систем для приложений CCITT.

X.225

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

X.226

Протокол презентаций для связанных открытых систем.

X.227

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

X.228

Надежная передача данных, спецификация протокола.

X.229

Удаленные операции: спецификация протокола.

X.237

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

X.247

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

X.400

Система обработки сообщений: системная модель, элементы сервиса.

X.401

Система обработки сообщений: базовые элементы сервиса и опционные пользовательские возможности.

X.402

Стандарт для пересылки сообщений

X.403

CCITT-система работы с сообщениями: Проверка сохранности

X.407

Абстрактные описания услуг

X.408

Система обработки сообщений: правила преобразования кодированной информации.

X.409

Система обработки сообщений: синтаксис и нотация презентационных пересылок.

X.410

Система обработки сообщений: удаленные операции и надежный сервер пересылок.

X.411

Система обработки сообщений: уровень передачи сообщений.

X.413

Запоминание сообщений: абстрактные определения услуг

X.419

Спецификации протоколов

X.420

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

X.430

Система обработки сообщений: протокол доступа для терминалов телетекста.

X.500

Стандарт на каталоги, базирующийся на OSI (RFC 1279, 1275, 1274)

X.509

CCITT-каталоги: Система идентификации

X.511

Абстрактные описания услуг

X.519

Спецификации протоколов

X.520

Некоторые типы атрибутов

X.521

Для определенных классов объектов

Z.100-104

SDL (Specification and Description Language) язык описания и спецификаций

Previous: 10 Приложения    UP: 10 Приложения
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.2 Коды протоколов в Ethernet II


previous up down next index index
Previous: 10.3 Стандартные мультикастинг-адреса Интернет    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.5 Таблица операций службы каталогов Netware

10.4 Таблица операций и субопераций NCP
Семенов Ю.А. (ГНЦ ИТЭФ)

Код операции

Код субоперации

Описание

23 1

50

Get Current Account Status

23 1

51

Submit Account Change

23 1

52

Submit Account Hold

23 1

53

Submit Account Note

Обслуживание файловой системы Apple

35

01

AFP Create Directory

35

02

AFP Create File

35

03

AFP Delete

35

04

AFP Get Entry ID from Name

35

05

AFP Get File Information

35

06

AFP Get Entry ID from NetWare Handle

35

07

AFP Rename

35

08

AFP Get Open File Fork

35

09

AFP Set File Information

35

10

AFP Scan File Information

35

11

AFP 2.0 Alloc Temporary Directory Handle

35

12

AFP Get Entry ID from Name Path

35

13

AFP 2.0 Create Directory

35

14

AFP 2.0 Create file

35

16

AFP 2.0 Set File Information

35

17

AFP 2.0Scan file Information

35

18

AFP Get DOS Name from Entry ID

35

19

AFP Get Macintosh Info on Deleted File

Аудиторские услуги

88

01

Query Volume Audit Status

88

02

Add Audit Property

88

03

Add Audit Access

88

04

Change Audit Password

88

05

Check Auditor Access

88

06

Delete Audit Property

88

07

Disable Volume Auditing

88

08

Enable Volume Auditing

88

09

Is User Audited

88

10

Read Audit Bit Map

88

11

Read Audit Config Header

88

12

Read Auditing File

88

13

Remove Auditor Access

88

14

Reset Audit File

88

15

Reset History File

88

16

Write Audit Bit Map

88

17

Write Audit Config Header

Работа с базой данных Bindery и операции доступа

23

50

Create Bindery Object

23

51

Delete Bindery Object

23

52

Rename Object

23

53

Get Bindery Object ID

23

54

Get Bindery Object in Set

23

55

Scan Bindery Object

23

56

Change Bindery Object Security

23

57

Create Property

23

58

Delete Property

23

59

Change Bindery Security

23

60

Scan Property

23

61

Read Property Value

23

62

Write Property Value

23

63

Verify Bindery Object Password

23

64

Change Bindery Object Password

23

65

Add Bindery Object to Set

23

66

Delete Bindery Object from Set

23

67

Is Bindery Object in Set?

23

68

Close Bindery

23

69

Open Bindery

23

70

Get Bindery Access Level

23

71

Scan Bindery Object Trustee Paths

23

72

Get Bindery Object Access Level

23

73

Is Calling Station a Manager?

23

74

Keyed Verify Password

23

75

Keyed Change Password

23

76

List Relations of an Object

Обслуживание каналов

19

-

Get Station Number

23

20

Login Object

23

23

Get Login Key

23

24

Keyed Object Login

23

26

Get Internet Address

23

27

Get Object Connection List

23

28

Get Station's Logged Information

23

29

Change Connection State

23

30

Watchdog Interval

23

31

Get Connection List from Object

24

-

End of Job

25

-

Logout

33

-

Negotiate Buffer Size

88

01

Clear Connection Number List

97

-

Get Big Packet NCP Max Packet Size

Работа с расширенными атрибутами

86

01

Close Extended Attribute Handle

86

02

Write Extended Attribute

86

03

Read Extended Attribute

86

04

Enumerate Extended Attribute

86

05

Duplicate Extended Attribute

Работа с каталогами и файлами

18

-

Get Volume Info with Number

22

00

Set Directory Handle

22

01

Get Directory Path

22

02

Scan Directory Information

22

04

Modify Maximum Rights Mask

22

05

Get Volume Number

22

06

Get Volume Name

22

10

Create Directory

22

11

Delete Directory

22

12

Scan Directory for Trustee

22

13

Add Trustee to Directory

22

14

Delete Trustee from Directory

22

15

Rename Directory

22

18

Allocate Permanent Directory Handle

22

19

Allocate Temporary Directory Handle

22

20

Deallocate Directory Handle

22

21

Get Volume Info with Handle

22

22

Allocate Special Temporary Directory Handle

22

23

Map Directory Number to Path

22

25

Set Directory Information

22

26

Get Path Name of a Volume-Directory Number Pair

22

29

Get Effective Directory Rights

22

30

Scan a Directory

22

31

Get Directory Entry

22

32

Scan Volume's User Disk Restrictions

22

33

Add User Disk Space Restriction

22

34

Remove User Disk Space Restrictions

22

35

Get Directory Disk Space Restriction

22

36

Set Directory Disk Space Restrictions

22

37

Set Directory Entry Information

22

38

Scan File or Directory for Extended Trustee

22

39

Add Extended Trustee to Directory or File

22

40

Scan Directory Disk Space

22

41

Get Object Disk Usage and Restrictions

22

42

Get Effective Rights for Directory Entry

22

43

Remove Extended Trustee to Directory or File

22

44

Get Volume and Purge Information

22

45

Get Directory Information

22

46

Rename or Move

22

48

Get Name Space Directory Entry

22

49

Open Data Stream

22

50

Get Object Effective Rights for Directory Entry

22

51

Get Extended Volume Information

23

15

Scan File Information

23

16

Set File Information

23

26

Purge All Erased Files

61

-

Commit File

62

-

File Search Initialize

63

-

File Search Continue

64

-

Search for a File

66

-

Close File

67

-

Create File

68

-

Erase File

69

-

Rename File

70

-

Set File Attributes

71

-

Get Current Size of File

72

-

Read from a File

73

-

Write to a File

74

-

Copy from One File to Another

75

-

Set File Time Date Stamp

78

-

Allow Task to Access File

79

-

Set File Extended Attributes

84

-

Open/Create File

85

-

Get Sparse File Data Block Bit Map

87

01

Open/Create File or Subdirectory

87

03

Search for a File or Subdirectory

87

04

Rename or Move a File or Subdirectory

87

05

Scan File or Directory for Trustee

87

08

Delete a File or Subdirectory

87

09

Set Short Directory Handle

87

10

Add Trustee Set to File or Subdirectory

87

11

Delete Trustee Set from File or Subdirectory

87

12

Allocate Short Directory Handle

87

17

Recover Salvageable File

87

18

Purge Salvageable File

87

19

Get Name Space Information

87

20

Search for a File or Subdirectory Set

87

21

Get Path String from Short Directory Handle

87

22

Generate Directory Base and Volume Number

87

23

Query Name Space Information Format

87

24

Get Name Space Loaded List from Volume Number

87

25

Set Name Space Information

87

26

Get Huge Name Space Information

87

27

Set Huge Name Space Information

87

28

Get Full Path String

90

00

Parse Tree

90

150

File Migration Request

Среда файл-сервера

15

-

Locate a Resource

16

-

Deallocate a Resource

20

-

Get File Server Data and Time

23

05

Get File Server Login Status

23

12

Verify Serialization

23

14

Get Disk Utilization

23

17

Get File Server Information

23

18

Get Network Serial Number

23

23

Get File Server LAN I/O Statistics

23

200

Check Console Privileges

23

201

Get File Server Description String

23

202

Set File Server Date and Time

23

203

Disable File Server Login

23

204

Enable File Server Login

23

207

Disable Transaction Tracking

23

208

Enable Transaction Tracking

23

211

Down File Server

23

212

Get File System Statistics

23

213

Get Transaction Tracking Statistics

23

214

Read Disk Cache Statistics

23

215

Get Drive Mapping Table

23

216

Read Physical Disk Statistics

23

217

Get Disk Channel Statistics

23

221

Get Physical Record Locks by Connection and File

23

227

Get LAN Driver

23

229

Get Connection Usage Statistics

23

230

Get Object's Remaining Disk Space

23

232

Get File Server Misc Information

23

233

Get Volume Information

23

234

Get Connection's Task Information

23

235

Get Connection's Open Files

23

236

Get Connections Using a File

23

237

Get Physical Record Locks by Connection and File

23

238

Get Physical Record Locks by File

23

239

Get Logical Records by Connection

23

240

Get Logical Record Information

23

241

Get Connection's Semaphores

23

242

Get Semaphore Information

23

245

Get File Server Extended Misc Information

23

246

Get Volume Extended Miscellaneous Information

23

252

Release a Resource

23

253

Send Console Broadcast

23

254

Clear Connection Number

Работа с сообщениями

21

01

Get Broadcast Message

21

02

Disable Broadcasts

21

03

Enable Broadcasts

21

04

Send Personal Message

21

05

Get Personal Message

21

06

Open Message Pipe

21

07

Close Message Pipe

21

08

Check Pipe Status

21

09

Broadcast to Console

21

10

Send Broadcast Message

23

13

Log Network Message

Работа с принтером и очередями

17

00

Write to Spool File

17

01

Close Spool File

17

02

Set Spool File Flags

17

03

Spool a Disk File

17

04

Scan Spool File Queue

17

05

Delete Spool File

17

06

Get Printer Status

17

09

Create Spool File

17

10

Get Printer's Queue

23

137

Get Queue Jobs from Form List

Работа с очередями

23

100

Create Queue

23

101

Destroy Queue

23

110

Change Queue Job Position

23

111

Attach Queue Server to Queue

23

112

Detach Queue Server from Queue

23

116

Change to Client's Rights

23

117

Restore Queue Server Rights

23

119

Set Queue Server Current Status

23

121

Create Queue Job and File

23

122

Read Queue Job Entry

23

123

Change Queue Job Entry

23

124

Service Queue Job

23

125

Read Queue Current Status

23

126

Set Queue Current Status

23

127

Close a File and Start Queue Job

23

128

Remove Job from Queue

23

129

Get Queue Job List

23

130

Change Jobiority

23

131

Finish Servicing Queue Job

23

132

Abort Servicing Queue Job

23

134

Read Queue Server Current Status

23

135

Get Queue Job File Size

Синхронизация

01

-

File Set Lock

02

-

File Release Lock

05

-

Release File

06

-

Release File Set

07

-

Clear File

08

-

Clear File Set

11

-

Clear Logical Record

12

-

Release Logical Record

13

-

Release Logical Record Set

14

-

Clear Logical Record Set

28

-

Release Physical Record

29

-

Release Physical Record Set

30

-

Clear Physical Record

31

-

Clear Physical Record Set

105

-

Log File

106

-

Lock File Set

107

-

Log Logical Record

108

-

Lock Logical Record Set

109

-

Log Physical Record

110

-

Lock Physical Record Set

111

00

Open/Create Semaphore

111

01

Close Semaphore

111

02

Wait on Semaphore

111

03

Signal Semaphore

111

04

Examine Semaphore

Отслеживание транзакций

34

00

TTS Is Available

34

01

TTS Begin Transaction

34

02

TTS End Transaction

34

03

TTS Abort Transaction

34

04

TTS Transaction Status

34

05

TTS Get Application Thresholds

34

06

TTS Set Application Thresholds

34

07

TTS Get Workstation Thresholds

34

08

TTS Set Workstation Thresholds

34

09

TTS Get Transaction Bits

34

10

TTS Set Transaction Bits

Служба каталогов NetWare

104

01

Ping for NDS NCP

104

02

Send NDS Fragmented Request/Reply

104

03

Close NDS Fragment

104

04

Return Bindery Context

104

05

Monitor NDS Connection

Работа со статистикой

123

01

Get Cache Information

123

02

Get File Server Information

123

03

NetWare File Systems Information

123

04

User Information

123

05

Packet Burst Information

123

06

IPX/SPX Information

123

07

Garbage Collection Information

123

08

CPU Information

123

09

Volume switch Information

123

10

Get NLM Loaded List

123

11

NLM Information

123

12

Get Directory Cache Information

123

13

Get Operating System Version Information

123

14

Get Active Connection List by Type

123

15

Get NLM Resource Tag List

123

20

Active LAN Board List

123

21

LAN Configuration Information

123

22

LAN Common Counters Information

123

23

LAN Custom Counters Information

123

25

LSL Information

123

26

LSL Logical Board Information

123

30

Get Media Manager Object Information

123

31

Get Media Manager Objects List

123

32

Get Media Manager Children's List

123

33

Get Volume Segment List

123

40

Active Protocol Stacks

123

41

Get Protocol Stack Configuration Information

123

42

Get Protocol Stack Statistics Information

123

43

Get Protocol Stack Custom Information

123

44

Get Protocol Stack Numbers by Media Number

123

45

Get Protocol Stack Numbers by LAN Board Number

123

46

Get Media Name by Media Number

123

47

Get Loaded Media Number List

123

50

Get General Router and SAP Information

123

51

Get Network Router Information

123

52

Get Network Routers Information

123

53

Get Known Networks Information

123

54

Get Server Information

123

55

Get Server Sources Information

123

56

Get Known Servers Information

123

60

Get Server Set Commands Information

123

61

Get Server Set Categories

Previous: 10.3 Стандартные мультикастинг-адреса Интернет    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.5 Таблица операций службы каталогов Netware


previous up down next index index
Previous: 10.5 Таблица операций службы каталогов Netware    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.7 Типы субвекторов кадров управления доступом

10.6 Таблица типов кадров управления доступом для сети Token Ring
Семенов Ю.А. (ГНЦ ИТЭФ)

Код команды

Наименование

Класс адресата

Класс отправителя

0x0

Отклик (является реакцией на команды управления доступом)

Источник запроса

Рабочая станция

0x2

Аварийный сигнал (используется станциями для восстановления работоспособности после устойчивой ошибки)

Рабочая станция кольца

Рабочая станция кольца

0x3

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

Рабочая станция

Рабочая станция

0x4

Очистка кольца (посылается активным монитором для повторного запуска маркерного доступа)

Рабочая станция

Рабочая станция

0x5

Активное мониторирование (используется активным монитором для опроса кольца)

Рабочая станция

Рабочая станция

0x6

Резервное мониторировние (используется дополнительным монитором для опроса кольца)

Рабочая станция

Рабочая станция

0x7

Проверка дублирования адреса (посылается станцией самой себе после подключения к кольцу)

Рабочая станция

Рабочая станция

0x8

Проверка среды ответвителя (проверяется целостность адаптера станции и ответвителя)

Рабочая станция

Рабочая станция

0x9

Пересылка вперед (служит для проверки наличия пути между станциями)

Рабочая станция

Сервер конфигурации

0xB

Удаление станции из кольца (если станция получает кадр с таким кодом и своим адресом получателя, она должна отключиться от сети)

Рабочая станция

Сервер конфигурации

0xC

Изменение параметров (используется сервером конфигурации для информирования станций об изменении параметров адаптера)

Рабочая станция

Сервер конфигурации

0xD

Инициализация станции (используется сервером параметров для пересылки данных в адаптер станции при ее инициализации)

Рабочая станция

Сервер параметров кольца

0xE

Запрос адреса станции (посылается серверу конфигурации в ответ на запрос)

Рабочая станция

Сервер конфигурации

0xF

Запрос состояния станции (Посылается сервером конфигурации для получения данных о состоянии станции)

Рабочая станция

Сервер конфигурации

0x10

Запрос подключения станции (используется станцией в ответ на запрос сервера конфигурации о подключении)

Рабочая станция

Сервер конфигурации

0x20

Запрос инициализации (используется для получения данных от сервера параметров)

Сервер параметров кольца

Рабочая станция

0x22

Запрос об адресе станции (посылается сервером конфигурации стации с целью определения ее адреса)

Сервер конфигурации

Рабочая станция

0x23

Запрос о состоянии станции (запрос о состоянии станции, посылаемый сервером конфигурации)

Сервер конфигурации

Рабочая станция

0x24

Запрос о подключении станции (используется сервером конфигурации для получения данных об адаптере станции)

Сервер конфигурации

Рабочая станция

0x25

Сообщение нового активного монитора (используется новым активным монитором для информирования о себе сервера конфигурации)

Сервер конфигурации

Рабочая станция

0x26

Сообщение об изменении адреса предшественника (используется станцией для сообщения серверу конфигурации об изменении ближайшего активного предшественника)

Сервер конфигурации

Рабочая станция

0x27

Сообщение о незавершенном опросе кольца (используется активным монитором для передачи монитору ошибок сообщений о нарушении порядка опроса)

Монитор ошибок

Рабочая станция

0x28

Сообщение об ошибке монитора (используется станцией для оповещения монитора ошибок о сбоях)

Монитор ошибок

Рабочая станция

0x29

Сообщение об ошибке (используется станциями для передачи серверу ошибок содержимого счетчиков нестабильных ошибок)

Монитор ошибок

Рабочая станция

0x2A

Отклик на передачу вперед (используется станцией для передачи серверу конфигурации результата передачи вперед)

Сервер конфигурации

Рабочая станция

Previous: 10.5 Таблица операций службы каталогов Netware    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.7 Типы субвекторов кадров управления доступом


previous up down next index index
Previous: 10.7 Типы субвекторов кадров управления доступом    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.9 Набор AT-команд модемов

10.8 Управляющие регистры модемов и их функции
Семенов Ю.А. (ГНЦ ИТЭФ)

Таблица 10.8.1. Управляющие регистры модема

Регистр

Содержимое по умолчанию

Назначение

S0

0 1)

Управляет режимом отклика модема на телефонный вызов. Устанавливает число звонков, после которых модем снимает трубку. Диапазон допустимых значений 0-255. Если S0=0, режим автоответа выключен. Для снятия трубки надо выполнить команду ATA.

S1

0

Считает поступающие звонки и запоминает их число. Пользователь может прочесть регистр, но не должен менять содержимое. После 8 секунд с момента последнего звонка содержимое регистра сбрасывается в ноль.

S2

43

Хранит ASCII значение символа ESC, используемого для управления переходом в командный режим и обратно в режим данных. По умолчанию это символ "+". Значение 128-255 блокирует ESC-код. Содержимое регистра не сохраняется.

S3

13

Хранит ASCII символ Carriage Return. Содержимое регистра не сохраняется.

S4

10

Хранит ASCII символ Line Feed. Содержимое регистра не сохраняется.

S5

8

Хранит ASCII символ Backspace. Содержимое регистра не сохраняется. Значение 128-255 блокирует функцию стирания символа Backspace.

S6

3

Устанавливает число секунд, в течение которых модем ждет набора номера, если выбраны X0 или X1. Если выбраны X2, X3, X4, X5, X6 или X7, модем начинает набор, как только обнаружит гудок. Этот регистр устанавливает также величину таймаута для W-модификатора набора (диапазон 1-255 сек). Содержимое регистра не сохраняется.

S7

60

Устанавливает число секунд, в течение которых модем ждет несущую после завершения набора номера. Если модем в течение этого времени не обнаружит несущую, он вешает трубку и переходит в режим NO CARRIER. Содержимое регистра не сохраняется.

S8

2

Устанавливает длительность задержки, генерируемой модификатором набора запятая (,) команды ATD. Содержимое регистра не сохраняется.

S9

6

Устанавливает время (в десятых секунды), в течение которого должна присутствовать несущая удаленного модема, прежде чем она будет опознана и модем передаст в ЭВМ сигнал DCD. Содержимое регистра не сохраняется.

S10

7

Устанавливает время (в десятых секунды), в течение которого модем ждет после потери несущей прежде чем повесить трубку (разорвать связь). Код S10 должен быть всегда больше кода S9. Содержимое регистра не сохраняется.

S11

70

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

S12

 

Определяет задержку, которую следует выждать до и после передачи модему ESC-последовательности (+++). Пауза между символами ESC-последовательности должна быть меньше кода в S12.

S13

 

Зарезервировано

S14 2)

 

Битовый регистр, определяющий состояние модема

&Mn (7,6) =0

асинхронный, буферизованный

=1

асинхронные команды, синхронные данные

=2

прямой асинхронный без буфера

=3

синхронный

&Xn (5,4) =0

внутренние часы

=1

внешние часы

=2

удаленные часы

&Ln (3,2) =0

линия с набором номера

=1

2-проводная выделенная линия

=2

4-проводная выделенная линия

&T4 (1) =0

предоставление возможности запросов цифрового тестирования с удаленной замкнутой петлей

&T5 =1

запрещает запросы тестов с удаленной петлей

* 3) Mn (0) =0

Автоматический диалог в исходном режиме при работе на выделенную линию

=1

Автоматический диалог в режиме отклика при работе на выделенную линию

S15

 

Битовый регистр

Zn (7,6,5)=0-4

Профайл используется для установки режима при включении питания

*Сn (4,3) =0

10-битовая длина кодов символов

=1

11-битовая длина кодов символов

=2

9-битовая длина кодов символов

=3

8-битовая длина кодов символов 4)

(2)=0

1 стоп-бит

=1

2 стоп-бита

(1,0)=0

четная четность

=1

нечетная четность

=2

четность не используется.

S16

 

Тест-статусный регистр

=0

Не идет никаких тестов (по умолчанию);

=1

Идет тест с аналоговой петлей

=2

Зарезервировано

=3

Работает локальный цифровой тест

=6

Работает цифровой тест с удаленной петлей

=7

Выполняется цифровое самотестирование с удаленной петлей

=8

Выполняется аналоговое самотестирование

S17

 

Битовый регистр

*In (6) =0

AT-набор команд

=1

V.25bis-набор команд

*Pn (4,3,2,1)=0-15

Уровень сигналов для выделенной линии

*Sn (0) =0

Запрет вторичного канала

=1

Разрешение вторичного канала.

S18

 

Задает длительность теста в секундах. Если код S18=0, модем будет находиться в режиме теста до прихода команды &T0.

S19

 

Режим соединения модема

&Nn =0

Multi-auto, автоматический выбор наибольшей возможной скорости (V.32 9600T/9600/7200T/ 4800, V.22bis 2400/1200, V.22 1200, BELL 212A 1200, V17FAX 14400/12000/9600/7200, V.29FAX 9600/7200, V.27terFAX 4800/2400)

=1

V.33 14400/12000

=2

V.33 12000

=3

V.32 9600T/9600/7200T/4800

=4

V.32 9600/7200T/4800

=5

V.32 4800

=6

V.29 9600

=7

V.29 7200

=8

V.29 4800

=9

V.27ter 4800

=10

V.27ter 2400

=11

V.26bis 2400

=12

V.23 1200/75

=13

V.23 600/75

=14

V22bis 2400/1200

=15

V.22 1200

=16

V.21 300

=17

V.32bis 14400/12000/9600/7200/4800

=18

V.32bis 7200/4800

=19

V.32bis 7200/4800

=24

Bell 212A 1200

=25

Bell 103 300

=32

V.17FAX 14400/12000/9600/7200

=34

Зарезервировано

=35

Зарезервировано для 16800

=36

Зарезервировано для 19200

S20

 

Скорость DTE (определяется автоматически AT-командами)

=0

76,8 кбит/c

=1

57,6 кбит/c

=2

38,4 кбит/c

=3

19,2 кбит/c

=4

16,8 кбит/c

=5

14,4 кбит/c

=6

12,0 кбит/c

=7

9,6 кбит/c

=8

7,2 кбит/c

=9

4,8 кбит/c

=10

3,6 кбит/c

=11

2,4 кбит/c

=12

1,8 кбит/c

=13

1,2 кбит/c

=14

600 бит/c

=15

300 бит/c

S21

 

Битовый регистр

&Dn (7,6) =0

Модем игнорирует DTR-сигнал, предполагая, что он всегда присутствует

=1

108.1, переключение DTE-сигнала из OFF в ON приводит к набору номера по умолчанию. Переход DTE в состояние OFF приводит к вешанью трубки

=2

108.2, переход DTR в состояние OFF приводит к вешанию трубки и переключению в командный режим

&Rn (5) =0

CTS следует за RTS

=1

Игнорирует RTS (CTS всегда в состоянии ON).

&Cn (4) =0

CD всегда ON

=1

CD следит за несущей

$Sn (3) =0

Модем делает DSR всегда ON

=1

В соответствии с CCITT

Mn (2,1)=0

Громкоговоритель выключен

=1

Громкоговоритель включен, пока не появится несущая

=2

Громкоговоритель всегда включен

=3

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

*En (0) =0

Не поддерживает контроля ошибок, если не удалось об этом договориться

=1

Разрывается связь, если не удается договориться о контроле ошибок

S22

 

Зарезервировано

S23

 

Битовый регистр

Qn (7) =0

Модем возвращает код результата

=1

Модем не возвращает код результата

Vn (6) =0

Отображает код результата в цифровой форме

=1

Отображает код результата в полной форме

Xn (5,4,3) =0

Основной код результата (0-4).

=1

Код результата (0-5, 10-21).

=2

Код результата (0-6, 10-21).

=3

Код результата (0-5, 7-21).

=4

Код результата (0-21).

=5

Управление кодом ошибки включено

=6

Управление кодом ошибки включено

=7

Управление кодом ошибки включено

&Pn (2) =0

При импульсном наборе отношение make/break=39%/61%.

=1

При импульсном наборе отношение make/break=33%/67%.

T/P (1) =0

Тоновый набор

=1

Импульсный набор

En (0) =0

Отклик на команду блокирован

=1

Отклик на команду разрешен

S24

 

Битовый регистр

Ln (7,6,5)=0-7

Управление громкостью громкоговорителя

Nn (3,2,1)=0-7

Управление громкостью звонка

S25

 

Зарезервировано

S26

По умолчанию=0

RTS/CTS дисплей. Устанавливает задержку (в десятках миллисекунд) между RTS и откликом модема CTS в синхронном режиме

S27

 

Битовый регистр

*Qn (7,6) =0

Никакого отклика на плохое качество сигнала

=1

Запускает повторную попытку при плохом качестве сигнала

=2

Адаптивный алгоритм настройки скорости при изменении качества сигнала

=3

Разрывает связь при плохом качестве сигнала

&Hn (5,4,3)=0

Управление потоком отключено

=1

Зарезервировано

=2

Зарезервировано

=3

Аппаратный контроль потока CTS/RTS

=4

Программный контроль потока XON/XOFF

=5

Зарезервировано

&Kn (2,1,0)=0

Никакого контроля ошибок

=1

MNP4 (включая MNP3).

=2

MNP4 + MNP5

=3

V.42 + MNP4

=4

V.42 + V42bis (совместимо с &K2).

S28

 

Битовый регистр

Bn (7) =0

Выбирает V.22 для связи при скорости 1200 бит/с

=1

Выбирает Bell 212A для скорости 1200 бит/с

&Bn (6) =0

Быстродействие DTE/DCE следует за возможностями канала

=1

Быстродействие DTE/DCE фиксировано и определяется установкой DTE в диапазоне (300-76800)бит/с

&Gn (5,4) =0

Ведущий тон отсутствует

=1

Зарезервировано

=2

Ведущий тон имеет частоту 1800 Гц

S29

 

Указатель на номер телефона по умолчанию

*Dn =n

Устанавливает указатель в EEPROM на номер телефона по умолчанию (n=0-9).

S30

 

Указатель на запасной номер телефона

*Bn =0

Блокирует резервный номер телефона

=n

Разрешает наличие резервного номера и устанавливает указатель на его позицию в EEPROM (n=1-9).

1) Значения по умолчанию приведены для модема Zyxel U-1496
2) Функции битов для разных типов модемов варьируются
3) Опционная характеристика, присутствует не во всех модемах
4) Длина символа включает в себя стартовый бит, биты данных, бит четности и стоп-бит

Содержимое битовых регистров модема сохраняется в энергонезависимой памяти.

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

Previous: 10.7 Типы субвекторов кадров управления доступом    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.9 Набор AT-команд модемов


previous up down next index index
Previous: 10.8 Управляющие регистры модемов и их функции    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)

10.9 Набор AT-команд модемов
Семенов Ю.А. (ГНЦ ИТЭФ)

AT-команды посылаются ЭВМ или терминалом модему через последовательный интерфейс RS-232 (модем должен быть при этом в командном режиме). Все эти команды начинаются с префикса AT, за исключением A/, A> и +++. Код A/ вызывает выполнение модемом предыдущей команды, A> заставляет модем выполнять предыдущую команду до 9 раз или пока не будет нажата какая-либо клавиша терминала или управляющей панели модема, или пока не будет установлена связь с удаленным модемом. Команда +++ (ESC-последовательность) переводит модем в командный режим или возвращает его в режим передачи данных.

Таблица 10.9.1. Стандартные AT-команды

Обозначение команды

Описание функции команды

A

Включает режим отклика (снимается трубка, выполняется подключение к линии)

+ B0

Выбирает режим CCITT V.22 (1200бит/с, по умолчанию)

B1

Выбирает для коммуникации стандарт Bell 212A (1200 бит/с)

D

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

Числа и модификаторы, применимые с командой D:
0-9,#,* - цифры набора номера. Ниже следуют модификаторы набора.
P - Импульсный набор.
T - Тоновый набор.
R - Начинает вызов в режиме отклика. Вводится как последняя цифра.
S - Набирается номер, записанный в памяти.
W - Ожидание длинного гудка перед набором (длительность ожидания определяется S7, по умолчанию 30сек).
, - Пауза на время, заданное S8 (по умолчанию 2сек).
; - Возврат в командный режим после набора номера.
@ - Ожидание 5 сек. молчания прежде чем продолжить, в противном случае возврат (NO ANSWER).

DL

Набор номера, использованного последним.

DSn

Набор номера, записанного в EEPROM в позиции n(0-9).

E0

Запрет символьного отклика в командном режиме.

+ E1

Разрешает символьный отклик в командном режиме.

Fn

Переключение между дуплексным и полудуплексным режимами (n=0 - полудуплексный; n=1 - дуплексный).

H0

Вешание трубки и отключение от линии

H1

Снятие трубки и подключение к линии

I0

Отображение информации о модеме (идентификационный код)

I1

Отображение результата проверки контрольной суммы ROM (EPRROM).

I2

Проверяется состояние внутренней памяти ROM и возвращается сообщение OK или CHECKSUM ERROR.

I3

Выдается версия модема

I4

Модем передает ЭВМ строку, заданную производителем модема.

I5

Выдается код страны производителя.

I6

Выдается код модели модема

L0-7

Управление громкостью динамика (по умолчанию L4).

M0

Громкоговоритель всегда выключен.

+ M1

Громкоговоритель включен пока не обнаружена несущая.

M2

Громкоговоритель всегда включен.

M3

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

N0-7

Управление громкостью звонка. N0 запретит звонок при приходе сигнала вызова.

O

Возвращение в состояние on line.

P

Импульсный набор

+ Q0

Модем возвращает код результата (по умолчанию)

Q1

Модем не возвращает код результата

Q2

Модем возвращает код результата, но отключается после ответа на звонок.

Sr=n

Записывает в S-регистр r код n, n должно быть десятичным числом в интервале 0-255.

Sr ?

Отображает код, записанный в регистре r.

+ T

Тоновый набор (по умолчанию)

V0

Отображает код результата в сжатой цифровой форме.

+ V1

Отображает код результата в символьной форме (по умолчанию)

Xn

Опции отображения работы и кодов результата (по умолчанию X5). Определяет набор сообщений, управляет определением сигнала "занято" и проверкой наличия гудка.

Yn

Определяет способ отключения модема от линии. Команда Y1 заставляет модем повесить трубку, если от удаленного модема получен сигнал BREAK. Команда Y0 запрещает прерывать связь при получении длительного сигнала BREAK

Wn

Записывает текущую конфигурацию модема в профайл n.

Zn

Устанавливает конфигурацию модема из профайла n (n=0-3). Z4 устанавливает заводской набор параметров модема.

Символ "+" указывает на то, что данный режим является режимом по умолчанию.

Команда X0 заставляет модем посылать сообщения в короткой форме. Номер набирается после паузы вне зависимости от наличия гудка. Состояние "занято" не распознается. После команды X1 модем посылает сообщения в полной форме. Команда X2 отличается от X1 и X0 тем, что набор номера выполняется лишь при наличии гудка. Команда X3 требует полной формы сообщений, номер набирается после паузы вне зависимости от наличия гудка, сигнал занято идентифицируется. Команда X4 сходна с X3, но требует для набора наличия гудка. При получении команд X2 или X4 модем разрывает связь и кладет трубку, если удаленный модем переведет линию в состояние BREAK на 1,6 секунды.

Существует несколько команд вывода справочной информации (работают не на всех модемах):

$

справочная информация по базовому набору команд;

&$

справочная информация по расширенному набору команд (названия команд начинаются с символа &);

*$

справочная информация по улучшенному набору команд.

Таблица 10.9.2. Команды модема из расширенного набора (различие для разных типов модемов здесь может быть значительным).

Команда

Описание

&B0

DTE/DCE скорость следует за быстродействием линии.

+ &B1

DTE/DCE скорость зафиксирована на уровне заданном DTE (300-76800 бит/с, режим по умолчанию)

&C0

Предполагает, что несущая всегда присутствует (делает CD=ON)

+ &C1

CD отслеживает наличие несущей (по умолчанию.)

&D0

Игнорируется DTR сигнал, предполагает DTR=ON.

&D1

Переключение DTR OFF->ON вызывает набор номера по умолчанию.

&D2

DTR OFF вызывает отключение от линии и переход модема в командный режим.

&D3

Аналогична &D2, но вызывает также загрузку профайла 0.

&F

Загружает в RAM заводской набор параметров модема.

&K0

Никакого контроля ошибок.

&K1

MNP4 (включая MNP3)

&K2

MNP4 + MNP5

&K3

V.42 (эквивалентно &K1)

+ &K4

V.42 + V.42bis (эквивалентно &K2)

+ &L0

Выход в обычную городскую телефонную сеть (по умолчанию)

&L1

2-проводная выделенная линия.

&L2

4-проводная выделенная линия

Пример записи AT-команды: ATDnnnnnnnnn, где последовательность символов n включает номер телефона и модификаторы набора (к модификаторам можно отнести P и T, указывающие на импульсный и тоновый тип набора соответственно. Допускается и более удобная для восприятия запись: ATD 8, (095) 123-94-42.

Таблица 10.9.3. Сообщения модема (коды результата Xn)

Код

Название

Описание

0

OK

Команда выполнена без ошибок

1

Connect

Установлена связь на скорости 300 бит/с (после реализации команд X1, X2, X3, X4) или на скорости 600, 1200, 2400 бит/с (после команды X0)

2

Ring

Обнаружен сигнал звонка. Этот код модем передает ЭВМ каждый раз, когда поступает сигнал вызова.

3

No Carrier

Потеряна или не получена несущая от удаленного модема.

4

Error

Обнаружена ошибка в командной строке, переполнен командный буфер или обнаружена ошибка контрольной суммы.

5

Connect 1200

Установлена связь на скорости 1200 бит/с (см. команды X1, X2, X3, X4).

6

No Dial Tone

Нет сигнала (гудка) при снятии трубки (см. команды X2, X4)

7

Busy

Обнаружен сигнал <занято> после набора номера.

8

No Answer

Отклик может быть получен при использовании в командной строке символа @, если не выполнено условие - 5-сек тишины.

9

Ringing

Пришел вызов (звонок)

10

Connect 2400

Установлена связь на скорости 2400бит/с (см. команды X1, X2, X3, X4).

11

Connect 4800

Установлена связь на скорости 4800бит/с

12

Connect 9600

Установлена связь на скорости 9600бит/с

14

Connect 19200

Установлена связь на скорости 19200бит/с

15

Connect 7200

Установлена связь на скорости 7200бит/с

16

Connect 12000

Установлена связь на скорости 12000бит/с

17

Connect 14400

Установлена связь на скорости 14400бит/с

18

Connect 16800

Установлена связь на скорости 16800бит/с

19

Connect 38400

Установлена связь на скорости 38400бит/с

20

Connect 57600

Установлена связь на скорости 57600бит/с

21

Connect 76800

Установлена связь на скорости 76800бит/с

Previous: 10.8 Управляющие регистры модемов и их функции    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)


previous up next index index
Previous: 10.10.26 [Z]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
    Next: 10.12 Национальные коды доменов в Интернет

10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
Семенов Ю.А. (ГНЦ ИТЭФ)

Фирма

Продукт

URL

ACTERNA

GSM, PCN, PCS

www.acterna.com

Adak

Терминальные адаптеры, ISDN

adtran.com, www.adtran.com

ADTECH

622.08 Mbps ATM

www.adtech-inc.com

Alcatel

Телекоммуникационное оборудование и системы

www.alcatel.com

AltaVista

Поисковый сервер

www.altavista.com

APC

UPS

www2.planet.apc.org

API DELEVAN

Электронные компоненты

www.delevan.com

ArelNet

Факс-серверы

www.arelnet.com

Ascend

Маршрутизаторы

www.ascend.com

AT&T

Телекоммуникационное оборудование, модемы

www.att.com

Bay

Сетевое оборудование и модемы

www.baynetworks.com

Best Power Technology

UPS

www.euroele.com

Bosch

Электронное оборудование

www.bosch.de

Breeze Link

Радио модемы и мосты

www.breezecom.com

Cabletron

Оборудование локальных и региональных сетей, ATM

www.cabletron.com

CellWare

Оборудование ATM

www.cellware.de

CISCO

Маршрутизаторы

www.cisco-ps.com

3COM

Сетевое оборудование

www.3com.com

Combinet

Маршрутизаторы

www.combinet.com

COM one worldwide communication

Видео безопасность для Интернет, Surf TV

www.com1.fr

Compuserve

Программное обеспечение

www.compuserve.com

Consumer Microcircuits

Интегрированное коммуникационное оборудование

www.cmlmicro.co.uk

CPClare

Звуковая почта и цифровая телефония

www.cpclare.com

Creative Labs

Мультимедиа, CD-драйвы

www.creative.com

Cylink

Радио модемы

www.sylink.com

Dataline

Радио модемы

www.dataline.ch & 194.79.73.91

DEC

ЭВМ, программное обеспечение и т.д. и пр.

www.digital.com

Digiboard

Маршрутизаторы

www.digibd.com

ELSA

Телекоммуникационное оборудование и графика

www.nusaweb.com

Epson

Принтеры, сканнеры и пр.

www.epson-europe.com

ERICSSON

Мощные ИС

www.ericsson.se

Fiber Options

RS-232, RS422, ST оптические порты

www.fiberoptions.com

Frederick Engineering

ISDN, анализаторы протоколов

www.fe-engr.com

FTP Software

Сетевое программное обеспечение

www.ftp.com

GN Nettest (ELMI)

Измерительное оборудование

www.gnnettest.com

Hewlett Packard

ЭВМ и измерительное оборудование

www2.hp.com

HotLine

56kbps модемы

www.hotline.se

Hughes

Спутниковое коммуникационное оборудование

www.hcisat.com

IBM

ЭВМ и все, все, все...

www.ibm.com

IMC networks

Сетевое оборудование

www.imcnetworks.com

Intec

ISDN-тестеры

www.intec-isdn.de

Integrated Device Technology

ATM

www.idt.com

Intel

ИС, модемы, и пр.

www.intel.com

ISDN*tek

ISDN

www.isdntek.com

ITU telecom

 

www.itu.int

Kingston

ЭВМ и телекоммуникационное оборудование

www.kingston.com

KNX

Телекоммуникационное оборудование

www.fleet.britain.eu.net

Kommunikations Elektronik

X.21, G.703, ISDN

www.ke-online.de

Marcini Instruments

Измерительное оборудование

www.marconi-instruments.com

Maxwell Technologies/I-BUS

 

www.ibus.com

MCI

Телекоммуникационное оборудование

www.mci.com

MetalLink

Оптоволоконная техника

www.metalink.co.il

METLaboratories

Belcore NEBS, EMI/EMC

www.metlabs.com

MFS

Телекоммуникационное оборудование

www.mfsdatanet.com

MICOM

Голос через IP

www.micom.com

Microchip

ИС

www.microchip2.com

Microsoft

Универсальное программное обеспечение

www.microsoft.com

Motorola

Телекоммуникационное оборудование

www.mot.com

National Instruments

VXI System CD-ROMs, Виртуальные приборы

www.natinst.com

Nbase communications

IP-переключатели

www.nbase.com

NEXUS

Услуги Интернет

www.halcyon.com

Nokia

Телекоммуникационное оборудование

www.nokia.com

Nothern Telecom

Телекоммуникационное оборудование

www.nortel.com

Novell

Сетевое программное обеспечение

www.novell.com

Olivetti

ЭВМ и телекоммуникационное оборудование

www.olivettipc.com

OPTIMA

Телекоммуникационное оборудование и программы

www.optima-systems.com

OPTION International

GSM, модемы

www.option.com

Oracle

Распределенные базы данных и прикладное программное обеспечение

www.oracle.com.sg

ORCKIT

Широкополосный Интернет

www.orckit.com

Patton Electronics

rs-232->V.35; Оптоволоконные модемы, скоростные модемы

www.patton.com

Philips

Телекоммуникационное оборудование и пр.

www-us.philips.com

Proteon inc.

Маршрутизаторы и программное обеспечение

www3.techstocks.com

Racal

Модемы

www.racal.com

RAD data communications

Модемы, мультиплексоры

www.rad.com

Ricoh

Модемы, телекоммуникационное оборудование

www.ricohcorp.com

Rittal-Werk

Мобильные телекоммуникации

www.rittal.de

Rockwell

Маршрутизаторы

www.rns.rockwell.com

Silicon Graphics

ЭВМ и программное обеспечение

www.sgi.com

Siemens

Все

www.siemens.de

Sipex

Телекоммуникационные ИС

www.sipex.com

Sony

Видеотерминалы и пр.

www.sony.de or www.sony.be

Specialized Products

Телекоммуникационное измерительное и тестовое оборудование

www.specializedproducts.com

Stallmann E+V

Коммуникационное программное обесп.

www.stallmann.de

ST2E-Groupe TEKELEC TEMEX

Радио модемы

www.tekelec-temex.com

STL Solarcrest Technologies

Оборудование ISDN

www.indigo.com

SUN

Компьютерное оборудование и программы

www.sun.com

Telebit

Модемы и телекоммуникационное оборудование

www.tbit.dk

Telebyte Technology

G.703 в RS-232/V.35

telebyteusa.com

Telecom Product News

 

www.pepco.be

Telecom Science Corporation

Оборудование и программы для ISDN

www.telsci.co.uk

Telect

Оптоволоконное оборудование

www.telect.com

TELELINK

ISDN, модемы V.34

www.telelink.ch

Tektronix

Диагностическое оборудование (да кто не знает эту фирму?)

www.tek.com

TENET Computer group

Оборудование локальных сетей, оптоэлектроника

www.tenet.com

TESTEL

Диагностическое оборудование

www.diagnosys.com

TRANSTECTOR

Защита телекоммуникаций

www.transtector.com

TREND communications

Тестеры ISDN

www.trendcomms.com

US Robotics

Модемы

www.usr.com

VIKING telecom

IP для PC, факс/модемные переключатели

www.viking-telecom.se

VIMCOM

Телекоммуникационное оборудование и оптоэлектроника

www.vimcom.ru

VistaCom

Видео кодеки

www.vistacom.fi

VOXTRON

Голосовая почта, программы

www.voxtron.com

Wandel & Goltermann

Тестовое оборудование

www.wg.com

WAVACCESS wireless communications

Радиомодемы и беспроводные сети

www.waveaccess.com

Zenith Data Systems

Компьютерное оборудование, модемы

www.netware.com

Zoom Telephonics

Модемы

www.zoomtel.com

Zyxel

Модемы

www.zyxel.com

Previous: 10.10.26 [Z]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
   Next: 10.12 Национальные коды доменов в Интернет


previous up down next index index
Previous: 10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.2 [B]

10.10.1 [A]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

AA

Auto Answer

Автоответ

Area Address

Адрес области (NSAP)

Administrative Athority

Административное субполе (ATM)

AAA

Authentication, Authorization, Accounting

Аутентификация, авторизация, акаунтинг

AAB

All-to-All Broadcast

Широковещательный режим все-со-всеми

AACDI

Asynchronous Communications Device Interface

Асинхронный коммуникационный интерфейс

AAL

ATM Adaptation Layer

Адаптивный уровень ATM

AAP

Applications Access Point [DEC]

Точка доступа для приложений

A&R

Academic and Research

Академический и исследовательский

AARP

AppleTalk Address Resolution Protocol

Протокол преобразования адресов (ARP) для AppleTalk

AAS

All-to-All Scatter

Режим выборочного доступа все-со-всеми

AASP

ASCII Asynchronous Support Package

Пакет асинхронной поддержки работы с кодами ASCII

AAT

Average Access Time

Среднее время доступа

ABC

Atanasoff-Berry Computer

ЭВМ Атанасова-Берри (первая цифровая вычислительная машина на электронных лампах)

ABI

Application Binary Interface (PowerPC)

Прикладной двоичный интерфейс

ABIOS

Advanced BIOS

Продвинутая версия BIOS

ABM

Asynchronous Balanced Mode

Асинхронный симметричный режим

ABR

AUNTHOOD Rate detection

Метод регистрации потока

Available Bit Rate

Доступная скорость передачи

Area Border Router

Пограничный маршрутизатор области

ABS

Absolute

Абсолютный

ABT

Abort

Прервать и выгрузить

AC

Automatic Computer

Автоматическая ЭВМ

Alternating Current

Переменный ток

ACC

ACCumulator

Аккумулятор

Accept Link Service

Позитивный отклик на запрос установления связи

ACCM

Asynchronous Control Character Map

Карта символов асинхронного управления

ACD

Automated Call Distribution

Автоматическое распределение запросов

ACDI

Asynchronous Communications Device Interface

Асинхронный интерфейс коммуникационного оборудования

ACE

Advanced Computing Environment [SCO]

Продвинутая компьютерная среда

Adverse Channel Enhancements

Улучшение плохого канала [Microcom]

Automatic Computing Engine

Автоматический вычислительный прибор

ACF

Advanced Communications Function

Продвинутые коммуникационные функции

Access Control Field

Поле управления доступом

ACIAS

Automated Calibration Internal Analysis System

Система анализа с автоматической внутренней калибровкой

ACIS

American Committee for Interoperable Systems

Американский комитет по интероперабильным системам

ACK

Acknowledge (TCP header)

Подтверждение (TCP-заголовок)

Acknowledgment

Подтверждение

ACL

Access Control List

Список управления доступом

ACM

Association for Computing Machinery

Ассоциация по вычислительной технике

Address Complete Message

Подтверждение получения всей маршрутной информации (ISDN)

ACMS

Application Control Management System (DEC)

Система контроля управления приложением

ACP

Ancillary Control Program

Вспомогательная управляющая программа

Auxiliary Control Process

Вспомогательный процесс управления

ACR

Attenuation-to-Crosstalk Ratio

Отношение значения ослабления к перекрестным наводкам

Allowed Cell Rate

Разрешенные частоты следования ячеек (ATM)

ACS

ACceSs

Доступ

Access Control System

Система управления доступом

Asynchronous Communication Server

Асинхронный коммуникационный сервер

Application Control Service

Служба управления приложением

Access Control Set

Набор параметров управления доступом

ACSE

Association Control Service Element

Элемент системы ассоциативного управления

ACT

Application Configurable Technology

Технология конфигурирования приложения

ACTLU

Active Logical Unit

Активный логический блок

ACTPU

Active Physical Unit

Активный физический блок

ACTS

Advaneced Communication Technology Satellite

Продвинутая спутниковая телекоммуникационная технология

ACTT

Advanced Communication and Timekeeping Technology [Seiko]

Продвинутая технология реализации службы времени и коммуникаций

ACU

Automatic Calling Unit

Блок автоматического вызова

A/D

Analog to Digital

Аналого-цифровой

AD

Active Directory

Активный каталог

ADA

Automatic Data Acquisitions

Автоматический сбор данных (язык программирования, названный в честь Августы Ады Лоуренс)

ADALINE

ADAptive LINear Element

Адаптивный линейный элемент

ADAPT

Advanced Dynamic Access Partitioning Technology

Улучшенная технология динамического доступа (Microcom)

ADB

Analog Delay & Buffer

Аналоговая задержка и буфер

ADC

Adaptive Data Compression (protocol)

Адаптивный протокол сжатия данных [Hayes]

Advanced Data Connector

Усовершенствованный доступ к данным

Add with Carry

Сложение с переносом

Analog to Digital Converter

Аналого-цифровой преобразователь

ADCCP

Advanced Data Communication Control Protocol

Улучшенный протокол управления передачей данных (бит-ориентированный протокол ANSI)

ADD

Automatic Document Detection [WordPerfect]

Автоматическая регистрация документов

ADE

Automatic Design Engineering

Автоматическое проектирование

ADF

Automatic Document Feed adapter Description File (file name extension) [IBM]

Расширение имени файла описания системы автоматической обработки документов

ADI

AutoCad Device Interface (driver)

Аппаратный интерфейс AutoCad

Alternate Digit Inversion

Код с поразрядно-чередующейся инверсией

Autodesk Device Interface

Аппаратный интерфейс Autodesk

ADL

Address Data Latch

Триггер адресных данных

ADLAT

Adaptive Lattice Filter

Адаптивный решетчатый фильтр

ADM

Add/Drop Multiplexer

Мультиплексор ввода/вывода

ADMD

Administrative Management Domain [X.400]

Административное управление областью

ADP

Automatic Data Processing

Автоматическая обработка данных

Answer Detection Pattern

Сигнатура для распознавания отклика

ADMD

ADministration Management Domain name

Административное управление именами доменов

ADPCM

Adaptive Differential (Delta) pulse Code Modulation

Адаптивный дифференциальный метод импульсно-кодовой модуляции

ADR

Address

Адрес

ADS

AutoCAD Development System

Система разработки для AutoCAD

Application Development Solutions/System [AT&T]

Решения/система для разработки приложений

Automatic Distribution System

Автоматическая система распределения

ADSC

Automatic Data Service Center

Автоматизированный центр сбора и обработки данных

Address Status Changed

Состояние адреса изменилось

ADSL

Asymmetrical Digital Subscriber Line

Асимметричный цифровой телекоммуникационный канал (до 7 Мбит/c)

ADSP

AppleTalk Data Stream Protocol

Протокол управления потоком данных в AppleTalk

ADT

Application Data Types

Типы прикладных данных

ADU

Automatic Dialing Unit

Автоматический блок набора телефонного номера

AE

Above or Equal

Больше или равно

AEB

Analog Expansion Bus [Dialogic]

Шина аналогового расширения

AEP

AppleTalk Echo Protocol

Протокол откликов AppleTalk

AES

Advanced Encryption Standard

Продвинутый стандарт шифрования(приемник DES)

AF

Auxiliary carry Flag

Вспомогательный флаг переноса

AFC

Automatic Font Change

Автоматическая замена шрифта

Automatic Frequency Control

Автоматическое управление частотой

AFD

Automatic File Distribution

Автоматическое распределение файлов

AFI

Authority and Format Identifier

Идентификатор полномочий и формата

AFII

Association for Font Information Interchange

Ассоциация для обмена информации о шрифтах

AFM

Adobe Font Metrics [Adobe Systems]

Метрики шрифтов Adoba (расширение имени файла)

AFP

AppleTalk Filing Protocol [Macintosh]

Файловый протокол AppleTalk

AFPM

Asymmetric Fabry-Perrot Modulator

Асимметрический модулятор Фабри-Перро

AFS

Andrew File System

Файловая система Эндрю

Acer fast File System

Быстродействующая файловая система Acer

AHDL

Altera Hardware Description Language

Язык описания оборудования Altera

AGC

Automatic Gain Control

Автоматическая регулировка усиления

AGP

Accelerated Graphics Port

Быстродействующий графический порт

AI

Analog Input

Аналоговый вход

Artificial Intelligence

Искусственный интеллект

AIA

Applications Integration Architecture [DEC]

Архитектура интеграции приложений

AIС

Automatic Information Center

Автоматизированный информационный центр

AID

Automatic Internet Datagram

Дейтограмма Интернет

AIN

Advanced Intelligent Network [Bell Atlantic]

Улучшенная интеллектуальная сеть

AIF

Audio Interchange Format

Формат передачи звука

AIFF

Audio Interchange File Format

Формат файлов для передачи звука

AIIM

Association for Information and Image Management

Ассоциация по управлению передачей информации и изображения

AIO

Asynchronous Input/Output

Асинхронный ввод/вывод

AIOD

Automatic Identification of Outward Dialing

Автоматическая идентификация внешнего набора номера

AIP

ATM Interface Processor

Процессор интерфейса ATM

AIS

Alarm Indication Signal

Сигнал индикации аварийной ситуации (Т1)

AISB

Association of Imaging Service Bureaus

Ассоциация бюро, работающих с изображением

AISP

Association of Information Systems Professionals

Ассоциация профессионалов информационных систем

AITS

Acknowledged Information Transfer Service

Передача информации с подтверждением получения

AIX

Advanced Interactive eXecutive (RFC 1177, IBM UNIX)

Продвинутая система интерактивного исполнения задач

ALB

ALarm Board (disk)

Плата оповещения об отказе

ALC

Arithmetic and Logic Circuits

Арифметические и логические схемы

Automatic Level Control

Автоматическое управление уровнем

ALE

Address Latch Enable

Активация триггера адреса

ALGOL

Algorithmic Oriented Language (see IAL)

Алгоритмически ориентированный язык

ALL

ATM Adaptation Layer

Уровень адаптации ATM

ALR

Advanced Logic Research (company)

Продвинутые логические исследования (название компании)

ALT

Alternate (mode)

Альтернативный (режим)

ALU

Arithmetic Logic Unit

Арифметический логический блок

AM

Amplitude Modulation

Амплитудная модуляция

AMA

Automatic Messaging Accounting

Автоматический акаунтинг сообщений

AMADNS

AMA Data Networking System

Информационная сетевая система AMA

AMANDDA

Automated Messaging and Directory Assistance

Автоматическая работа с сообщениями и каталогами

AMATSP

AMA Teleprocessing System

Система телеобработки AMA

AMD

Active Matrix Display

Активный матричный дисплей

Advanced Micro Devices

Продвинутые микроприборы (название электронной фирмы, США)

AME

Advanced Modeling Extension

Расширение для продвинутого моделирования

AMI

Alternate Mark Inversion

Последовательная инверсия маркера (биполярное кодирование)

AMM

Asynchronous Mapping Mode

Асинхронный режим отображения

AMMA

Advanced Memory Management Architecture [Everex Systems]

Продвинутая архитектура управления памятью

AMPS

Advanced Mobile Phone Service

Продвинутые услуги мобильной телефонии

AMR

Advanced Micro Research

Продвинутые микро исследования (название фирмы)

AMS

Applied Mathematical Science program in OER

Прикладная математическая научная программа в OER

AMT

Address Mapping Table

Таблица соответствия адресов

ANCOVA

Analysis of Covariance

Анализ корреляций

ANI

Automatic Number Identification

Автоматическая идентификация чисел

ANM

Answer Message

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

ANN

Artificial Neural Network

Искусственные нейронные сети

ANNotations [IBM]

Аннотации (расширение названия файла)

ANNT

Artificial Neural Network Technology (DARPA)

Технология искусственных нейронных сетей

ANO

Automated Network Operation

Автоматическая работа сети

ANOVA

Analysis Of Variance

Анализ вариации

ANP

Analog Parallel Network

Аналоговая параллельная сеть

Automatic Numbering Plan

Автоматическая система нумерации

ANS

Advanced Networks and Services

Продвинутые сети и услуги (название фирмы)

ANSI

American National Standard Institute

Американский Национальный институт стандартов

AO

Analog Output

Аналоговый выход

AOCE

Apple Open Collaboration Environment

Открытая среда для совместной работы фирмы Apple

AOE

Application Operating Environment [AT&T]

Операционная среда приложений

AOL

America Online

Название сети в США

AOS

Add Or Subtract

Сложить или вычесть

AOT

Active Object Table

Таблица активных объектов

AP

Adjunct Processor

Соседний процессор

Application Processor

Прикладной процессор

AP

Attached Processor

Дополнительный процессор

A/P

Accounts Payable

Платные аккоунты

APA

Adaptive Packet Assembly

Адаптивная сборка пакетов

All Points Addressable

Адресуемый всем

Arithmetic Processing Accelerator

Ускоритель арифметических операций

APAR

Authorized Program Analysis Report [IBM]

Сообщение о результате анализа работы авторизованной программы

APAREN

Address Parity Enable [IBM]

Разрешения контроля четности

APC

Adjacent Point Code

Код смежной точки

Angled Physical Contact

Угловой физический контакт (оптоволоконный разъем с обратным отражением менее -60 Дб)

APCUG

Association of PC User Groups

Ассоциация групп пользователей персональных ЭВМ

APDU

Application Protocol Data Unit

Блок данных прикладного протокола

APE

Application Programming Element

Элемент прикладного программирования

API

Application Program Interface (WINDOWS)

Прикладной программный интерфейс

APIC

Advanced Programmable Interrupt Controller [Intel]

Продвинутый программируемый контроллер прерываний

APIN

American Registry for Internet Numbers

Американский регистр чисел в Интернет

APL

Язык математического программирования

APM

Advanced Power Management [IBM OS2]

Продвинутое управление энергоснабжением

APM

Advanced Power Management [IBM OS2]

Продвинутое управление энергоснабжением

APNIC

Asia Pacific Network Information Center

Тихоокеанский азиатский сетевой информационный центр

APPC

Advanced Program-to-Program Communication (IBM)

Улучшенная система обмена программа-программа

APPI

Advanced Peer-to-Peer Internetworking

Улучшенная система межсетевого доступа

APPN

Advanced Peer-to-Peer Networking (IBM)

Продвинутая одноранговая сеть

APRP

Adaptive Pattern Recognition Processing

Адаптивное распознавание образов

APS

Asynchronous Protocol Specification

Спецификация для асинхронного протокола

Automatic Protection Switch

Автоматический защитный переключатель

American Physical Society

Американское Физическое общество

APSE

ADA Programming Support Environment

Среда поддержки программирования на языке ADA

APSP

Analog Pulse Shape Processor

Аналоговый процессор формы импульса

APT

Address Pass Through

Передача адреса

Automatically Programmed Tools

Средства автоматизации программирования

AQL

Acceptable Quality Level

Приемлемый уровень качества

A/R

Accounts Receivable

ARA

Applied (AppleTalk) Remote Access

Прикладной удаленный доступ

ARC

Advanced RISC Computing

Продвинутые вычисления с использованием RISC-технологии

Archive

архив (расширение имени файла)

ARCA

Advanced RISC Computing Architecture

Продвинутая вычислительная архитектура для RISC-процессоров

ARCnet

Attached Resource Computer network

Сеть с маркерным доступом ArcNet

ARD

Automatic Relevance Determination

Автоматическое определение совместимости

ARL

Adjusted Ring Length

Настраиваемая длина кольца

ARLL

Advanced Run Length Limited

ARM

Asynchronous Response Mode

Режим асинхронного отклика

Advanced RISC Machine

Продвинутый RISC-процессор

Application Resource Manager

Менеджер прикладных ресурсов

Annotated Reference Manual

Аннотированное справочное руководство

Asynchronous Response Mode

Асинхронный режим отклика

ARMA

Association of Records Managers and Administrators

Ассоциация менеджеров и администраторов

ARP

Address Resolution Protocol (RFC 826)

Протокол определения адреса

Associative Reward Penalty (SL)

ARPA

Advanced Research Project Agency of Defense Department

Агентство министерства оборона по ОКР, спонсор первой сети с пакетным переключением

ARPL

Adjust Requested Privilege Level

Настройка запрашиваемого уровня привилегий

ARQ

Automatic Repetition reQuest

Автоматическое повторение запроса

ARTIC

A Real-Time Interface Copressor [IBM]

Сопроцессор интерфейса реального времени

ARRE

Auto Read Reallocation

Реаллокация автоматического чтения

ARS

Automatic Route Selection

Автоматический выбор маршрута

ART

Adaptive Resonance Theory

Теория адаптивных резонансов

ARTA

Apple Real Time Architecture

Архитектура реального времени фирмы Apple

ARTS

Asynchronous Remote Takeover Server

Асинхронный управляющий сервер удаленного доступа

ARTT

Asynchronous Remote Takeover Terminal

Асинхронный удаленный терминал

ARU

Audio Response Unit

Блок звукового отклика

AS

Autonomous System

Автономная система

ASA

Adaptive Simulated Annealing [Internet]

Адаптивный симулируемый отжиг (нейронные сети)

ASAP

As Soon As Possible

Как можно быстрее

Automatic Switching And Processing

Автоматическое переключение и обработка

ASBR

Аutonomous System Boundary Router

Пограничный маршрутизатор автономной системы

AS3AP

ANSI SQL Standard Scalable and Portable

Стандарт ANSI SQL, масштабируемый и компактный

.ASC

ASCII text - ASCII-текст (расширение имени файла)

ASC

American Society for Cybernetics

Американское общество кибернетики

ASCII

American Standard Code for Information Interchange

Стандарт на кодировку символов

ASCOCR

American Standard Cherecter-set for Optical Character Recognition

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

ASE

Application Service Element

Элемент прикладных услуг

Amplified Spontaneous Emission

Усиленная спонтанная эмиссия

ASI

Adapter Support Interface

Интерфейс поддержки адаптера

ATM Service Interface

Интерфейс услуг ATM

ASIC

Application-Specific Integrated Circuit

Интегральные схемы, ориентированные на приложение

ASIT

Advanced Security and Identification Technology

Технология идентификации и улучшенной безопасности

ASL

Adaptive Speed Leveling

Адаптивное задание скорости

.ASM

Расширение названия файла исходных текстов на ассемблере

ASN

Abstract Syntax Notation

Нотация абстрактного синтаксиса, проект стандарта ISO для представления данных на прикладном уровне

Аuxiliary Signal Network

Вспомогательная сигнальная сеть

ASP

AppleTalk Session Protocol

Протокол сессий в AppleTalk

Associative String Processors

Ассоциативный процессор строк

Association of Shareware Professionals

Ассоциация профессионалов общедоступного программного обеспечения

Association Service Provisioning

Предоставление ассоциативных услуг

ASPI

Advanced SCSI Programming Interface [Adaptec]

Продвинутый интерфейс для программирования SCSI

ASPS

Advanced Signal Processing System

Продвинутая система обработки сигналов

ASQC

American Society for Quality Control

Американское общество по контролю качества

ASR

Automatic Send-Receive

Автоматическая посылка-получение

Automatic Speech Recognition

Автоматическое распознавание голоса

ASSP

Application Specific Standard Product

Стандартный продукт, ориентированный на приложение

AST

AST Research, Inc. (named from first initials of the founders: Albert Wong, Safi Qureshey, Thomas Yuen)

Название корпорации (по инициалам Альберт, Сафи и Томас)

Automatic Spanning Tree

Автоматически расширяющееся дерево

ASTA

Advanced Software Technology and Algorithms

Продвинутые программные технологии и алгоритмы

ASV

Automatic Self-Verification

Автоматический самоконтроль

Arithmetic Simple Variable

Простая арифметическая переменная

ASW

Apple Server Workgroup

Рабочая группа сервера Apple

ASYNC

Asynchronous

Асинхронный

AT

Advanced Technology

Продвинутая технология

Attention

Внимание

ATA

AT Attachment interface (IDE)

Интерфейс подключения

ATB

All Trunks Busy

Все каналы заняты

ATC

Address Translation Cache

Буферная память преобразования адреса

ATCP

AppleTalk Control Protocol (RFC1378)

Протокол управления сетью AppleTalk

ATD

Asynchronous Transfer Division

Асинхронный режим временного уплотнения

ATDP

Attention Dial Pulse

Импульсный сигнал набора

ATDT

Attention Dial Tone

Тоновый сигнал набора

ATDM

Asynchronous Time Division Multiplexing

Асинхронное мультиплексирование с разделением времени

ATE

Automated Test Equipment

Автоматическое тестовое оборудование

ATG

Address Translation Gateway

Сервер трансляции адресов

Advanced Technology Group

Группа продвинутых технологий

ATH

Attention Hang-Up

Сигнал "трубка повешена"

ATM

Adobe Typeface Manager

Менеджер типа шрифта

Asynchronous Transfer Mode

Режим асинхронной передачи

Automated Teller Machine

Автоматическая машина Теллера

ATP

AppleTalk Transaction Protocol

Операционный протокол AppleTalk

ATR

Automatic Terminal Recognition

Автоматическое распознавание терминала

ATS

Administrative Terminal System

Система административных терминалов

Automatic Test System

Автоматическая система проверки

Apple Terminal Services

Терминальные услуги Apple

AT&T

American Telephone and Telegraph

Название фирмы "Америкэн телефон энд телеграф"

ATTN

Attention

Внимание

ATTRIB

Attribute

Атрибут

AU

Administrative Unit

Административный блок (SDH)

AUDIT

Automated Data Input Terminal

Терминал автоматического ввода данных

AUG

Administrative Unit Group

Группа административных блоков

AUI

Attachment Unit Interface

Интерфейс подключения блока (трансивер-интерфейс в Ethernet)

AUP

Acceptable Use Policy [Internet]

Приемлемая политика использования

AURP

AppleTalk Update Routing Protocol

Протокол актуализации маршрутов в AppleTalk

AUTO

Automatic

Автоматический

AUTOEXEC

Automatic Execution

Автоматическое исполнение

AUX

Auxiliary

Вспомогательный (первый последовательный порт)

AVA

Audio Visual Authoring [IBM]

AVC

Audio Visual Connection [IBM]

Аудио-визуальное соединение

Audio-visual Control

Система управления изображением и звуком

AVD

Alternate Voice Data

Альтернативные голосовые данные

AVG

Average

Средний

AVI

Audio Visual Interleaved [Microsoft]

Совмещение аудио и видео сигналов

AVM

ATM voice multiplexer

ATM-мультиплексор голоса

AVR

Automatic Voice Recognition

Автоматическое распознавание голоса

AVVID

Architecture for Voice, Video and Integrated Data

Архитектура для видео, аудио и интегрированных данных

AWG

American Wire Gauge system (wire size)

Американский сортамент проволоки и проводов

AWK

(Unix language named after its authors Al Aho, Peter Weinberger and Brian Kernighan)

Язык программирования, названный по инициалам авторов

AWRE

Auto Write Reallocation

Автоматическая реалокация записи

AWS

Advanced Workstations and Systems [IBM]

Продвинутые рабочие станции и системы

AX

Architecture Extended

Расширенная архитектура

Automatic Transmission

Автоматическая передача


Previous: 10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.2 [B]


previous up down next index index
Previous: 10.10.1 [A]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.3 [C]

10.10.2 [B]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

2B1Q

2 Binary into 1 Quatery

Метод кодирования сигналов, в котором 2 бита отображаются с использованием 4-х уровней

10BASE2

IEEE стандарт на Ethernet с тонким коаксиальным кабелем (10Мбит/с, <200м)

10BASE5

IEEE стандарт на Ethernet с толстым коаксиальным кабелем (10Мбит/с, <500м)

10BASET

IEEE стандарт на Ethernet для скрученной пары

100BASE-4T

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

100BASE-FX

Ethernet, базирующийся на оптоволоконном кабеле

100BASE-TX

Ethernet, базирующийся на скрученной паре 5-ой категории

BAK

Binary Adaptation Kit [Microsoft]

Двоичное адаптивное средство

.BAK

Расширение имени файла Backup

BAL

Basic Assembly Language

Язык-ассемблер

BAM

Bidirectional Associative Memory (USL)

Двунаправленная ассоциативная память

Boyan Action Module

Рабочий модуль Boyan

BARRNet

Bay Area Regional Research Network

Региональная исследовательская сеть

BARTS

Bell Atlantic Regional Timesharing

Региональное разделение по времени в Bell Atlantic

BAS

Bit Allocation Signal

Байт, характеризующий возможности канала и передаваемую звуковую информацию

.BAS

Расширение имени файла исходного текста Бейсик

BASIC

Beginner All-purpose Symbolic Instruction Code

Название языка Бейсик

BASM

Built-In Assembler

Встроенный ассемблер

.BAT

Расширение имени файла обработки исправлений

BBS

Bulletin Board System

Электронная доска объявлений

BBU

Bus Bridge Unit

Блок связи с внутренней шиной

BC

Bearer Capability

Возможности канала (ISDN Setup)

Binary Code

Двоичный код

BCC

Blind Carbon Copy

Слепая копия из под копирки

Block Check Character

Контрольный символ блока

BCD

Binary Coded Digital

Двоично закодированное десятичное число

BCL

Batch Command Language

Язык команд исправления

BCP

Bulk Copy Program

Программа полного копирования

Best Current Practices

Наилучшая существующая практика (субсерия RFC-документов)

BCPL

Basic Computer Programming Language

Базовый язык программирования ЭВМ

BCR

Byte Count Register

Регистр-счетчик байтов

BCW

Bounds Checker for Windows

Программа проверки границ окна

Buffer Control Word

Слово управления буфером

BDC

Binary-Decimal Counter

Двоично-десятичный счетчик

BDCS

Broadband Digital Cross-Connect System

Ширококполосная цифровая коммутационная система (SONET)

BDOS

Basic Disk Operating System

Базовая дисковая операционная система

BDR

Bayes Decision Rule

Правило выбора Bayes'а

BDU

Basic Display Unit

Основной дисплей

BE

Below or Equal

Меньше или равно

Block Error

Блочная ошибка

BECN

Backward Explicit Congestion Notification

Бит пакета Frame Relay, сигнализирующий о перегрузке в канале

BEL

Bell

Звуковой сигнал

BELLCORE

Bell Communications Research

Коммуникационные исследования фирмы Bell

BER

Bit Error Rate

Частота ошибок в двоичных разрядах

Basic Encoding Rules

Основные правила кодирования (ASN.1)

BERT

Bit Error Rate Tester

Тестер частоты ошибок в двоичных разрядах

BFSK

Binary Frequency-Shift Keying

Двоичная частотная модуляция

BETEL

Broadband Exchange over Trans-European Links

Широковещательный обмен через трансевропейские каналы связи

BEU

Bus Extender Unit

Блок расширения шины

BF

Bad Flag

Плохой флаг

B/F

Background/Foreground

Программы переднего и фонового плана

BFNN

Binary Feedforward Neural Network

Двоичные нейронные сети с прямым распространением

BFT

Binary File Transfer

Двоичная пересылка файлов

BFTP

Background File Transfer Program (RFC 1068)

Программа фоновой передачи файлов

BGE

Branch if Greater or Equal

Передача управления, если больше или равно

.BGI

Borland Graphic Interface (file name extension)

Расширение имени файла для графического интерфейса Borland

BGP

Border Gateway Protocol (RFC 1265-1268)

Протокол для граничных маршрутизаторов

BGT

Branch if Greater Than

Передача управления, если больше чем

BHI

Branch if Higher

Передача управления при превышении

BHIS

Branch if Higher or Same

Передача управления, если выше или тоже самое

BI

Binary Input

Двоичный ввод

BIA

Burned-in MAC address

Прожженный MAC-адрес

.BIB

Bibliography

Расширение имени файла библиографии

BICI

Broadband Inter-Carrier Interface

Широкополосный межсетевой интерфейс (ITU-T)

BID

Bulletin Identifier

Идентификатор бюллетеня

BIDEC

Binary-to-Decimal Conversion

Двоично-десятичное преобразование

BiDi

Bidirectional

Двунаправленный

BIGA

Bus Interface Gate Array

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

BIM

Beginning of Information Marker

Начало информационного маркера

.BIN

Binary

Расширение имени двоичного файла

BINAC

Binary Automatic Computer

Двоичная автоматическая ЭВМ

BIND

Berkeley Internet Name Domain

Интернетовское имя домена Беркли (сервер имен)

BIOS

Basic Input Output System

Базовая система ввода/вывода

BIP

Bit Interleaved Parity

Проверка на четность при мультиплексировании с чередованием бит

BIPS

Billion Instructions per Second

Миллиард операций в секунду

BIS

Business Information System

Деловая информационная система

BISDN

Broadband Integrated Services Digital Networks

Широкополосные цифровые сети с интегрированными услугами (ATM)

BISYNC

BInary SYNchronous Communication

Двоичные синхронные коммуникации

BIT

Binary Digit

Двоичная цифра

BITNET

"Because It's Time" Network, (academic and research), coupled to EARN and NET-NORTH

Название сети

BITNIC

BITNET Network Information Center

Сетевой информационный центр BITNET

BIU

Bus Interface Unit

Блок интерфейса магистрали

BIX

Byte Information Exchange (BBS)

Побайтовый информационный обмен

.BK!

Backup (file name extension) [WordPerfect]

Расширение имени резервного файла

BKSP

Backspace

Клавиша стирания предшествующего символа

BL

Backlit

BLAST

Blocked Asynchronous Transmission (protocol) [Communications Research Group]

Протокол блочной асинхронной передачи

BLE

Branch if Less or Equal

Передача управления, если меньше или равно

BLK

Block

Блок

BLOB

Binary Large Object

Большой двоичный объект

BLTA

Boolen-Like Training Algorithm

Булеподобный алгоритм обучения

BLSR

Bidirectional Line Switch Ring

Кольцо с двунаправленными линиями (SONET)

BMC

Block Multiplexer Channels

Каналы мультиплексора блоков

BMON

Batch MONitor (VM)

Монитор исправлений

BMP

Bit Map Pattern

Сигнатура двоичных битов

Bitmap Format

Побитовый графический формат

Basic Multilingual Plane

BNC

Bayonet-Nut-Connector

Байонетный коаксиальный разъем

BNF

Backus-Naur Form

Форма Бакуса-Наура

BNI

Broadband Network Interface

Широкополосный сетевой интерфейс

BNM

Broadband Network Module

Широкополосный сетевой модуль

BNN

Boundary Network Node

Пограничный сетевой узел

BO

Binary Output

Двоичный вывод

BoB

Break-out Box

BOC

Bell Operating Company

Название компании

BOCA

BORLAND Object Component Architecture

Архитектура объектных компонентов Borland

BOOTP

BOOTstrap Protocol [Internet]

Протокол загрузки

BOM

Beginning Of Message

Начало сообщения

BORPQU

Borland Pro Quattro

Электронные таблицы

BORQU

Borland Quattro

Электронные таблицы

BOS

Basic Operating System

Базовая операционная система

BOT

Beginning Of Table

Начало таблицы

Beginning of Tape

Начало ленты

BP

Back Propagation

Обратное распространение (нейронные сети)

BPA

Business Process Automation

Автоматизация бизнес-процесса

BPB

BIOS Parameter Block

Блок параметров BIOS

BPDU

Bridge Protocol Data Units

Блок данных протокола моста

BPF

Berkley Packet Filter

Фильтр пакетов Беркли

BPI

Bits Per Inch

Бит на дюйм

BPL

Back Propagation Learning

Обучение по методу обратного распространения (нейронные сети)

Branch if Plus

Передача управления, если знак плюс

BPNN

Back Propagation Neural Network

Обратное распространение в нейронных сетях

bps

bit per second

Число бит в секунду

Bytes Per Second

Число байт в секунду

BPSK

Binary Phase-Shift Keying

Метод модуляции, где фаза синусоидального сигнала переключается скачкообразно на p при неизменной амплитуде. Фазе 0 ставится в соответствие логический нуль, а p - логическая единица

BR

Bad Register

Плохой регистр

BRB

Be Right Back (*)

Сейчас вернусь

BRD

Baud Rate Generator

Генератор частоты бод

BRF

Bridge Relay Function

Передающая функция моста

BRGC

Binary Reflected Gray Code

Двоичный код Грея

BRI

Basic Rate Interface

Интерфейс базовой скорости обмена (ISDN)

Brain Response Interface

Интерфейс отклика мозга

BS

BackSpace

Клавиша/cимвол стирания предшествующего символа

BSAM

Basic Sequential Access Method

Базовый метод последовательного доступа

BSC

Binary Synchronous Communication

Двоичный синхронный обмен

Basic Switching Center

Главный центр коммутации сообщений

.BSC

Boyan Script (file name extension) [Boyan Communications]

Расширение имени файла скриптов Boyan

BSCS

Bachelor of Science (Degree) in Computer Science

Бакалавр в области вычислительной техники

BSD

Berkeley Software Distribution

Программное обеспечение университета Беркли

BSF

Bit Scan Forward

Сканирование бит в прямом направлении

BSI

British Standards Institute

Британский институт стандартов

BSMN

Byte-Synchronous Mapping Mode

Байт-синхронный режим отображения

BSR

Bit Scan Reverse

Сканирование бит в обратном направлении

BSS

Block Started by Symbol

Блок, начинающийся с символа

BT

Bit Time

Бит тайм (100нс для обычного Ethernet)

BTT

Bad Track Table

Таблица плохих треков (для диска)

BSU

Bus Supply Unit

Блок питания магистрали

BSY

Busy

Занято

BSYNC

Binary Synchronous Communications (protocol)

Протокол для двоичного синхронного обмена

BT

Bit Test

Тест бита

BTAM

Basic Telecommunications Access Method

Базовый метод доступа к телекоммуникационным услугам [IBM]

BTB

Branch Target Buffer

Буфер ветвления

BTC

Bit Test and Complement

Проверка бита и установка дополнения

BTP

Batch Transfer Program

Программа передачи batch-файлов

BTR

Bit Test and Reset

Проверка бита и сброс

BTS

Bit Test and Set

Проверка бита и установка

BTW

By The Way (*)

Кстати

BU

Branch Unit

Блок передачи управления

BUF

Buffer

Буфер

BUNI

Broadband User Network Interface

Интерфейс широкополосной пользовательской сети

BUS

Broadcast/Unknown Server

Широковещательный сервер для поиска неизвестных узлов (ATM)

BVI

Bridge Group Virtual Interface

Виртуальный интерфейс группы мостов

BWM

Block-Write Mode

Режим записи блоков

BWT

Burrows-Wheeler Transform

Преобразование Буровcа-Вилера (сжатие данных)

B2X

Binary To Hexadecimal [REXX]

Двоично-шестнадцатеричное преобразование

BXA

Bureau of Export Administration

Бюро экспортной администрации

BYTE

Binary Element String

Строка двоичных элементов


Previous: 10.10.1 [A]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.3 [C]


previous up down next index index
Previous: 10.10.2 [B]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.4 [D]

10.10.3 [C]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

C

C Programming Language

Язык программирования СИ

.C

 

Расширение имени файла исходного текста программы на языке СИ

CA

Common Application (SAA)

Общее применение

Certification Authority

Сертификационная служба

Call Appearance

Приход вызова

Cellular Automata

Клеточный автомат

Collision Avoidance

Избежание столкновений

CAC

Carrier Access Code

Программа доступа к каналу

Connection Admission Control

Контроль доступа в сеть

CAD

Computer Aided Design

Применение ЭВМ для автоматизации проектирования

CADD

Computer Aided Design and Drafting

Применение ЭВМ для проектирования и рисования

CAE

Computer Aided Engineering

Применение ЭВМ для автоматизации инженерного труда

Computer Application Environment

Среда применения ЭВМ

CAF

Controllable ATM Fabric

Управляемая структура АTM (Fabric)

CAFS

Content Addressable File Store

Ассоциативная файловая память

CAG

Column Address Generator

Генератор адреса колонки

CAI

Computer Aided Instruction

Инструкции, выполняемые ЭВМ

CAL

Calendar

Календарь

Computer Aided Learning

Обучение с помощью ЭВМ

CALC

Customer Access Line Charge

Оплата доступа клиента к каналу

CALS

Computer Aided Acquisition and Logistics Support

Использование ЭВМ для сбора данных и принятия решений

CAM

Common Access Method

Метод общего доступа

Computer Aided Manufacturing

Применение ЭВМ для автоматизации производства

Contents Addressable Memory

Память с адресацией по содержанию (ассоциативная)

CAN

Campus Area Network

Сеть университета (между LAN и WAN)

CANcel

Аннулировать

Controller Area Network [Bosch]

Управляющая сеть реального времени

CAP

Central Arbitration Point

Точка централизованного арбитража

Communication Application Platform

Платформа коммуникационных приложений

Competitive Access Provider

Сервис-провайдер конкурент

Carrierless Amplitude/Phase modulation

Амплитудно-фазовая модуляция без несущей (используется в ADSL)

Computer Aided Publishing

Применение ЭВМ для автоматизации издательской деятельности

.CAP

Capture (file name extension)

Расширение имени файла

CAPD

Computing To Assist Persons With Disabilities [Johns Hopkins University]

Применение ЭВМ для помощи инвалидам

CAPS

Capitals

Заглавные буквы

Cassette Programming System

Кассетная система программирования

CAR

Committed Access Rate Согласованная скорость доступа (управление очередями)

CARAM

Content Addressable Random Access Memory

Ассоциативная память с произвольной выборкой

CARL

Colorado Alliance of Research Libraries (Internet)

Альянс исследовательских библиотек Колорадо

CART

Classification and Regression Tree

Дерево классификации и регрессии

CAS

Column Address Select

Выбор адреса колонки

Communications Application Specification

Спецификация коммуникационного приложения

Computer Aided Styling

Управление стилями с помощью ЭВМ

Channel-Associated Signaling

Внутриканальная сигнализация

Column Address Strobe

Строб адреса колонки

CasCor

Cascade Correlation (SL)

Каскадная корреляция

CASE

Computer Aided Software Engineering

Применение ЭВМ для автоматизации программирования

Common Application Service Elements

Сервисные элементы общего приложения

CASL

Crosstalk Application Scripting Language [DCA]

Язык программирования

CASS

Computer Assisted Search Service

Служба поиска с помощью ЭВМ

CASSIS

Classified and Search Support Information System

Информационная система для классификации и поиска

CAT

Computer Aided Testing

Испытания с помощью ЭВМ

Computer Aided Tomography

Томография с применением ЭВМ

Computer Aided Transcription

Транскрипция с применением ЭВМ

Concatenate

Объединить

.CAT

Catalog

Расширение имени файла каталог

CATS

Committee Analyzing Transport Service

Комитет анализа транспортных услуг

CATV

CAble TeleVision

Кабельное телевидение

Community Antenna TeleVision

Телевидение с общей антенной

CAV

Constant Angular Velocity

Постоянная угловая скорость

CAW

Channel Address Word

Адресное слово канала

CB

Control Board

Пульт управления

CBAC

Context-based Access Control

Контекстно-ориентированное управление доступом

CBC

Cipher Block Chaining

Цепной шифр

CBCR

Channel Byte Count Register

Регистр-счетчик числа байт в канале

CBDS

Connectionless Broadband Data Service

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

CBEMA

Computer and Business Equipment Manufacturers Association

Вычислительное и деловое оборудование

CBL

Computer Based Learning

Обучение, базирующееся на ЭВМ

.CBL

COBOL source code

Расширение имени файла исходного текста программы (COBOL)

CBMS

Computer-Based Mail System

Почтовая система, базирующаяся на ЭВМ

CBNN

Cascade Backpropagation Neural Network

Каскадная нейронная сеть с обратным распространением

CВR

Constant Bit Rate

Постоянная частота бит (ATM)

CBS

Colored Book Software (JANET protocols)

Программы из цветной книги (протоколы JANET)

CBT

Computer Based Training

Обучение, базирующееся на ЭВМ

CBWFQ

Class Based WFQ

Технология WFQ, предназначенная для нескольких классов трафика (управление очередями)

CBW

Convert Byte to Word

Преобразовать байт в слово

CBX

Computer-Controlled Branch Exchange

Обмен по магистрали, контролируемый ЭВМ

CC

Cascade Correlation

Каскадная корреляция

Country Code

Код страны

Cluster Controller

Контроллер кластера

CCB

Call Control Block

Блок управления вызовом

CCD

Charge Coupled Device

Прибор с зарядовой связью (ПЗС)

CCFT

Cold Cathode Fluorescent Tube

Флуоресцентная лампа с холодным катодом

CCH

Channel Check Handler

Хандлер управления каналом

CCIR

Consultative Committee on International Radio communications

Международный консультативный комитет по радио и телевидению

CCIS

Common Channel Interoffice Signaling

Межофисная сигнальная система с общим каналом

CCITT

Comite Consultatif Internacionale pour la Telephonie et la Telegraphie

Международный консультативный комитет по телефонии и телеграфии

CCK

Complementary Code Keying

Кодирование с использованием дополняющих кодов

CCL

Cyber Control Language

Управляющий язык Cyber

CCLC

Carrier Common Line Charge

 

CCM

Conventional Command Mode

Обычный командный режим

CCNN

Cascade Correlation Neural Network

Каскадная корреляционная нейронная сеть

CCOT

Cross Office Transfer Time

Время передачи в пределах офиса

CCP

Console Command Processor

Процессор команд консоли

CCR

Commitment, Concurrence and Recovery

Передача, согласованность, восстановление

Customer Controlled Reconfiguration

Реконфигурация, контролируемая клиентом

CCS

Common Communication Support (SAA)

Общая поддержка коммуникаций

Common Channel Signaling

Сигнальная система общего канала

CCSA

Common Control Switching Arrangement

Система переключения с общим управлением

CCTLD

Country Code Top Level Domain

Национальный домен верхнего уровня

CCU

Central Clock Unit

Блок центрального синхросигнала

CCW

Channel Command Word

Управляющее слово канала

CD

Carrier Detected

Несущая принята

Change Directory

Изменить каталог

Collision Detection

Зафиксировано столкновение

Color Display

Цветной дисплей

Compact Disk

Компактный диск

Clock Driver

Формирователь тактовых импульсов

C/D

Control Data

Управляющие данные

C2D

Character To Decimal [REXX]

Преобразование символа в десятичный код

CDA

Compound Document Architecture [DEC]

Архитектура составных документов

CDB

Common Data Bus

Общая шина данных

CDC

Control Data Corporation

Название корпорации

CD_CHRDY

Card Channel Ready [IBM]

Канал карты готов

CDD

Clarion Database Developer

Разработчик баз данных Clarion

CDDI

Copper Distributed Data Interface

100Мбит/с интерфейс на основе медного кабеля

CDE

Cooperative Development Environment (Oracle)

Среда кооперативной разработки

Common Desktop Environment

Общая рабочая среда

Complex Data Entry

Комплексный ввод данных

CDF

Custom Defined Function

Заказная функция

Channel Definition Format

Формат описания канала (Microsoft)

.CDF

Comma Delimited Format

Расширение имени файла с запятой в качестве разделителя

CD-I

Compact Disk - Interactive

Компактный диск - интерактивный

CDL

Computer Design Language

Язык проектирования на ЭВМ

CDM

Code Division Multiplex

Мультиплексная передача с кодовым уплотнением каналов

CDMA

Code Division Multiple Access

Множественный доступ с распределением кодов

CD-MO

Compact Disk - Magneto Optical

Магнитооптический компактный диск

CDOS

Concurrent Disk Operating System

Совмещенная операционная дисковая система

CDP

Conditional Di-Phase

Условное ди-фазное цифровое кодирование

Cheops Data Protocol

Протокол данных Cheops

CDPD

Cellular Digital Packet Data

Сотовые цифровые пакетные данные

CDR

Call Detail Record

Запись параметров вызова

Committed Delivery Rate

Согласованная скорость доставки данных

CD-R

Compact Disk - Recordable

Компактный перезаписываемый диск

CD-RDx

Compact Disk - Read Only Memory Data Exchange Standard

Компактный диск - стандарт на информационный обмен для систем памяти, ориентированных только на чтение

CDRL

Contract Data Requirements List

Список требований к контрактным данным

CDROM

Compact Disk Read Only Memory

Система памяти на лазерном компактном диске (только для чтения)

CD-RTOS

Compact Disk - Real Time Operating System

Операционная система реального времени на компактном диске

CD-RW

Compact Disc Read-Writable

Компакт-диск с возможностью записи

CDS

Current Directory Structure (DOS, 88-bytes/DIR)

Текущая структура каталогов

CDT

Central Daylight Time

Центральное дневное время

CDU

Central Display Unit

Центальный дисплей

CDV

Cell Delay Variation

Вариация задержки ячейки (ATM)

CD-V

Compact Disk - Video

Компактный видеодиск

CDVT

Cell Delay Variation Tolerance

Допустимое отклонение задержки ячейки

CD-WO

Compact Disk - Write Once

Компактный диск с одноразовой записью

.CDX

Compound Index

Расширение имени файла комбинированного индекса [Fox Pro]

CD-XA

Compact Disk - Extended Architecture

Компактный диск - расширенная архитектура

CE

Cache Enable

Активация буферной памяти

Chip Enable

Выбор кристалла

Collision Elimination

Исключение столкновений

Convert Enable

Разрешение преобразования

CEDAR

Center Of Excellence for Document Analysis and Recognition

Центр высокого качества для анализа и распознавания документов

CEG

Continuous Edge Graphics

Графика с непрерывным контуром

CEI

Conducted Electromagnetic Interference

Кондуктивная электромагнитная интерференция

CELP

Code Excited Linear Prediction

Линейное предсказание по коду

CEPT

Committee European de Post et Telegraph

Европейский комитет по почте и телеграфу

Conference of European Post and Telegraph

Европейская конференция по почте и телеграфу

CER

Cell Error Ratio

Отношение числа ячеек с ошибкой к общему числу ошибок

CERT

Computer Emergency Response Team

Европейская организация по стандартизации в области почты и телекоммуникаций

CES

Circuit Emulation Service

Эмуляция схемы (мультиплексирование в ATM)

CFB

Cipher Feedback

Цифровая обратная связь

CFD

Control Flow Diagram

Диаграмма управления потоками

.CFG

Configuration Конфигурация (расширение имени файла) Канонический

CFI

Canonic Format Identifier Канонический идентификатор формата

CFL

Context-Free Language

Бесконтекстный язык

CFV

Call For Votes [Bitnet]

Запрос в сети BITNET

CG

Categorial Grammer

Категориальная грамматика

Character Generator

Генератор символов

CGA

Color Graphics Adapter

Цветной графический адаптер

CGI

Computer Generated Images

Изображения, генерируемые ЭВМ

Common Gateway Interface

Интерфейс общего внешнего порта

Computer Graphics Interface

Графический интерфейс ЭВМ

CGM

Computer Graphics Metafile

Графический метафайл

.CGM

Computer Graphics Metafile

Графический метафайл (расширение имени файла)

CGS

Configurer Graphics Service

Служба графической конфигурации

Compact Gateway Server

Компактный сервер сетевого порта

CHAOSnet

 

Сетевой протокол, разработанный MIT

CHAP

Challenge (Handshake) Authentication Protocol

Протокол идентификации

CHAR

Character

Символ

CHAT

Conversational Hypertext Access Technology [Internet]

Разговорная гипертекстная технология доступа

CHCK

Channel Check

Проверка канала

CHCP

Change Code Page

Изменить страницу программы

CHS

Cylinder, Head, Sector

Система адресации на диске (цилинр-головка-сектор)

CIA

Classical IP over ATM

Классическое IP поверх ATM

CIC

Certificate Integrity Check

Проверка корректности идентификации

Carrier Identification Code

Код идентификации несущей

CICS

Customer Information Control System (IBM)

Система контроля информации пользователя

CICS/VS

Customer Information Control System/Virtual Storage

Система управления информацией клиента/Виртуальная память [IBM]

CID

Configuration/Installation/Distribution

Конфигурация/инсталяция/распределение

Craft Interface Device

Интерфейс на основе терминала или PC для локального управления

Channel ID

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

CIDR

Classless Inter Domain Routing

Бесклассовая интердоменная маршрутизация

CIF

Common Intermediate (Interchange) Format (TV) Format

Стандарт представления цветного изображения (352*288)

CIM

Computer Integrated Manufacture

Производство, интегрированное с помощью ЭВМ

CompuServe Information Manager

Информационный менеджер CompuServe

CIO

Chief Information Officer

Главный специалист по информации

CIOCS

Communication Input/Output Control System

Система управления коммуникацией ввода/вывода

CIP

Command Interface Port

Порт командного интерфейса

Channel Interface Processor

Процессор канального интерфейса

CIR

Committed Information Rates

Оговоренные (согласованные) скорости передачи (Frame Relay)

Communication Industry Research

Исследования в области коммуникационной промышленности

CIS

Card Information Structure

Информационная структура карты

CompuServe Information Service

Информационный сервис CompuServe

Computer Information Systems

Компьютерные информационные системы

CISC

Complex Instruction Set Computer

ЭВМ с комплексным набором команд (противоположность RISC)

CISPR

Special International Committee on Radio

Специальный международный комитет по радио

CIX

Commercial Internet eXchange

Коммерческий обмен в Интернет

CJLI

Compulink Information Exchange

Информационный обмен Compulink

Command Job Language Interpreter

Интерпретатор командного языка управления заданиями

CKD

Count Key Data (device)

 

CL

Connectionless

Без связи

Compilar Language

Язык компилятора

CLAI

Connectionless Access Interface

Интерфейс доступа без установления соединения

CLAR

Channel Local Address Register

Регистр адреса локального канала

CLASS

Custom Local-Area Signaling Service

Заказные локальные сигнальные услуги

CLient Access to Systems and Services

Доступ клиента к системе и сервису

Cooperative Library Agency for Systems and Services

Кооперативное библиотечное агентство для систем и сервиса

CLAW

Common Link Access for Workstations

Общий доступ к каналу для рабочих станций

CLC

Clear Carry Flag

Флаг сброса переноса

CLD

Clear Direction Flag

Сброс флага направления

CLDS

ConnectionLess Data Service

Информационная служба без установления связи

CLEC

Competitive Local Exchange Carrier

Местный сервис-провайдер

СLFS

Connectionless Function Service

Функции служб без установления соединения

CLI

Call-Level Interface

Интерфейс уровня вызова

Command Language Interpreter

Инткрпретатор команд

Clear Interrupt Flag

Сброс флага прерываний

Command Line Interface

Интерфейс командных строк

CLIST

Command List

Список команд

CLK

Clock

Часы

CLM

ConnectionLess Mode

Режим без установления соединения

CLNAP

ConnectionLess Network Access Protocol

Протокол доступа к сети без установления соединения

CLNI

Connectionless Network Interface

Сетевой интерфейс без установления соединений

CLNIP

Connectionless Network Interface Protocol

Протокол интерфейса без установления соединения

CLNP

Connection Less Network Protocol

Сетевой протокол без установления соединения

CLNS

Connection Less Network Service

Сетевой сервис без установления соединения

CLP

Cell-Loss Priority field

Поле приоритета потери ячейки (ATM)

.CLP

Clipboard [Windows]

Расширение имени файла Clipboard

CLR

Cell Loss Ratio

Вероятность потери ячейки (ATM)

CLS

Clear Screen

Очистка экрана

CLT

Communication Line Terminal

Терминал линии связи

Computer Language Translator

Транслятор на машинный язык

CLTP

Connectionless Transport Protocol

Транспортный протокол не требующий соединения

CLTS

Clear Task Switch Flag

Сброс флага задания

CLUI

Command Line User Interface

Пользовательский интерфейс командной строки

CLUT

Color Look-Up Table [Macintosh]

Таблицы просмотра для управления цветом

CLV

Constant Linear Velocity Interference

Интерфейс постоянной линейной скорости

CM

Connection Mode

Режим с установлением соединения

CMB

CRC Message Block

Поле CRC сообщения

CMC

Computer Mediated Communications

Межкомпьютерные коммуникации

Call Modification Completed message

Сообщение-отклик на запрос (CMR), подтверждающее его исполнение

CMI

Coded Mark Inversion

Двухуровневый двоичный код без возвращения к нулю с изменением полярности для каждой логической 1 и с изменением полярности в середине передачи 0 (ATM)

CMIP

Common Management Information Protocols

Общие протоколы управления для сетей ISO (RFC-1189)

CMIS

Common Management Information Service

Служба общей управляющей информации

CMISE

Common Management Information Service

Сервис общей управляющей информации

CML

Computer Managed Learning

Обучение под управлением ЭВМ

Current Mode Logic

Логика текущего режима

CMMS

Computerized Maintenance Management Software

Программное обеспечение контроля работы

CMMU

Cache/Memory Management Unit [Motorola]

Блок управления памятью

CMNS

Connection Mode Network Service

Сетевые услуги в режиме соединения

CMOS

Complementary Metal-Oxide Semiconductor

КМОП-полупроводник (типа метал-оксид)

CMOT

CMIP Over TCP

CMIP через TCP (RFC1095)

CMP

Compare

Сравнение

Computer

ЭВМ

CMPS

Compare word String

Сравнение строк из слов

CMR

Call Modification Request Message

Сообщение, которое может быть послано в любом направлении, для модификации сессии, например, для перехода от передачи данных к передаче голоса (ISDN)

Cell Misinsersion Rate

Частота ошибочных доставок ячеек (ATM)

CMRJ

Call Modification Reject Message

Сообщение-отклик на запрос CMR, оповещающее об отклонении этого запроса (ISDN).

CMS

Conversational Monitor System (IBM interactive OS)

Разговорная мониторная система

Code Management System

Система управления программой

Compiler Monitor System

Система мониторирования компилятора

CMT

Connection Management

Управление связью

CMTS

Cable Modem Termination System

Оконечная система для кабельного модема (например, маршрутизатор)

CMU

Connection Matrix Unit

Блок коммутирующей матицы

CMY

Cyan-Magenta-Yellow

Цветовой код (альтернатива RGB - голубой-красный-желтый)

CMYK

Cyan-Magenta-Yellow-Black (color model)

Цветовая модель "голубой-красный-желтый-черный"

CN

Common Name Abbreviation (X.400)

Сокращение общего имени

Customer Network

Абонентская сеть

CNA

Certified NetWare Administrator [Novell]

Сертифицированный администратор NetWare

CNC

Computerized Numerical Control

Цифровое управление с помощью ЭВМ

CND

Caller Number delivery (caller ID)

Получение вызывающего номера

CNE

Certified NetWare Engineer

Сертифицированный инженер NetWare

.CNF

Configuration

Расширение имени файла конфигурации

CNG

Calling

Тоновый вызов

CNN

Cellular Neural Network

Ячеечная нейронная сеть

CNR

Carrier to Noise Ratio

Отношение несущей к шуму

CNRI

Corporation for National Research Initiatives

Корпорация национальных исследовательских инициатив

CNS

Central Neural System

Центральная нейронная система

CNSS

Core Nodal Switching Subsystem

Узловая субсистема переключения [Internet]

CNV

Conventional

Обычная (относится к памяти)

CNVT

Convert

Преобразовать

CNX

Certified Network Expert

Сертифицированный сетевой эксперт

CO

Central Office

Центральный офис

Command Output

Выход команд

Convert Out

Выход преобразования

COAM

Customer Owned And Maintained

Управляемый и принадлежащий пользователю

.COB

COBOL source code (file name extension)

Расширение имени файла исходного текста

COBOL

Common Business-Oriented Language

Язык программирования, ориентированный на бизнес

.COD

Code List

Расширение имени файла списка программ

CODASYL

Conference on Data System Languages

Конференция по информационно-системным языкам (группа создателей COBOL)

CODEC

Coder/Decoder

Кодировщик/декодировщик

Compression/Decompression

Сжатие (архивация) - восстановление

CODS

Connection Oriented Data Service

Информационные услуги, ориентированные на соединение

COEM

Commercial Original Equipment Manufacturer

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

COFF

Common Object File Format

Общий формат объектных файлов [Unix]

COGO

Coordinate Geometry

Язык программирования

COL

Collision

Столкновение

Computer Oriented Language

Язык, ориентированный на ЭВМ

COLD

Computer Output to Laser Disk

Вывод данных из ЭВМ на лазерный диск

COM

Commercial

Коммерческий (секция имени домена в Интернет)

Component Object Model

Компонентно-объектная модель

Continuation of Message

Продолжение сообщения

.COM

Command

Расширение имени командного файла

COM1, 2, 3, 4

First serial Port

Первый (второй, третий и четвертый) последовательный (асинхронный) порт

COMDEX

Computer Dealers Exposition

Экспозиция дилера ЭВМ

COMET

Cornell Macintosh Terminal Emulator

Корнельский терминальный эмулятор Макинтоша

COMP

Compare

Сравнить

Communications

Коммуникации

COMPASS

Communications Program for Advanced Switching Service

Коммуникационная программа для продвинутой системы коммутации

COMSAT

Communications Satellite Corporation

Корпорация коммуникационных спутников

CON

Console

Консоль (клавиатура и дисплей)

CONFIG

Configuration

Конфигурация

CONF

Configuration Failure

Ошибка конфигурации

CONNECT

Computational Neural Network Centre

Вычислительный центр нейронных сетей

CONP

Connection-Oriented Network Protocol

Сетевой протокол, ориентированный на соединение

CONS

Connection Oriented Network Service

Сетевая услуга, ориентированная на соединение

CONTONE

Continuous Tone

Длинный гудок

COOS

Commanded OOS

Ресурс не доступен, так как введен в виде команды

COPS

Computer Oracle Password and Security

Пароль в ЭВМ и безопасность (Oracle)

CORBA

Common Object Request Broker Architecture

Единая архитектура программы-посредника, обрабатывающая запросы

CORE

Centrally Operated RISC Environment

Центральная часть RISC-среды

CoREN

Corporation for Research and Enterprise Network

Корпорация исследовательских и коммерческих сетей

COS

Corporation for Open Systems

Корпорация открытых систем

Class Of Service

Класс услуг (QoS)

Compatible Operating System

Совместимые операционные системы

Corporation of Operating System

Корпорация открытых систем (наименование фирмы)

COSE

Combined Office Standard Environment

Комбинированная стандартная среда для офиса

Common Open Software Environment

Общая открытая среда программирования

COSINE

Cooperation for OSI Networking in Europe (RFC1274)

Сотрудничество в Европе в области сетей OSI

COSMIC

Computer Software Management and Information Center

Центр компьютерного программного управления и информации [NASA]

COSMOS

Computer System for Mainframe Operations

Компьютерная система для работы с базовой ЭВМ

COT

Continuity Test

Контроль несущей. Требование протокола SS7.

COTS

Commercial Off-The-Shelf

Коммерческий продукт, поставляемый немедленно

CP

Copy Protected

Защищенный от копирования

Clock Pulse

Тактовый импульс

Control Point

Контрольная точка

Control Processor

Управляющий процессор

CPC

Calling Party Category

Категория источника вызова

CPCS

Common Part Convergence Sublayer

Общая часть подуровня конвергенции

Call Processing Control System

Система управления обработкой вызовов

CPE

Customer Premises Equipment

Терминальное оборудование клиента

Central Processing Element

Центральный процессорный элемент

CPG

Call Progress Message

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

CPI

Characters Per Inch

Число символов на дюйм

Clock Per Instruction

Число тактов на команду

Common Programming Interface [IBM]

Общий программный интерфейс

Common Part Indicator

Однооктетный индикатор общей части (ATM)

.CPI

Code Page Information

Расширение имени файла программной страницы [MS-DOS]

CPI-C

Common Programming Interface for С

Общий интерфейс программирования для СИ

CPL

Current Privilege Level

Текущий уровень привилегий

CPM

Command Processing Module

Модуль обработки команд

Critical Pass Method

Метод критического пути

CP/M

Control Program for Microcomputer

Программа управления для микро-ЭВМ (операционная система Digital Research)

CPN

Customer Premises Network

Собственная сеть клиента

Computer Product News

Новости о компьютерных товарах

CPNIE

Called Party Number Information Element

Информационный элемент номера адресата

CPP

C++

СИ++

CPS

Characters Per Second

Число символов в секунду

Cycles Per Second

Число циклов в секунду

CPT

Cisco Protocol Translator

Транслятор протокола CISCO

Command Pass Through

Прохождение команды

CPU

Central Processing Unit

Центральный блок процессора

CR

Carriage Return

Возврат каретки

Call Request

Запрос

Command Register

Регистр команд

C/R

Command/Response

Команда/отклик

CRC

Cyclic Redundancy Check (Control)

Циклическая контрольная сумма

Cyclic Redundancy Code

Циклический избыточный код

CREN

Corporation for Research and Education Networking

Корпорация сетей для исследований и образования

CRF

Cable Retransmission Facility

Устройство для ретрансмиссии по кабелю

Cross Reference File

Файл перекрестных ссылок

Concentrator Relay Function

Передающая функция концентратора (атрибут, характеризующий имеющиеся ресурсы сети ATM)

CR/LF

Carriage Return/Line Feed

Возврат каретки/перевод строки

CRL

Core Routine Library

Библиотека базовых программ

Certificate Revocation List

Список аннулирования сертификатов

CRMA

Cyclic-Reservation Multiple Access protocol

Протокол множественного доступа с циклическим резервированием

CROM

Control Read Only Memory

Управляющая память, рассчитанная только на чтение

CRT

Cathode Ray Tube

Катодная лампа

CRTC

CRT Controller

Контроллер ЭЛТ

CRV

Call Reference Value

Идентификатор ISDN-вызова (Q.931, I.451)

CS

Cognitive Science

Наука познания

Chip Select

Выбор микросхемы

Clear to Send

Готовность к посылке

Code Segment

Сегмент программы

Convergence Sublayer

Подуровень конвергенции (объединения) (ATM)

C/S

Client/Server

Клиент/сервер

CSA

Canadian Standard Association

Канадская ассоциация по стандартам

CSAR

Channel System Address Register

Регистр адреса системного канала

CSC-MC

CiSCo Memory Card

Карта памяти Cisco

CSD

Corrective Service Diskette [IBM]

Дискета коррекции

CSDS

Packet Switched Data Service

Информационная служба с пакетной коммутацией

CSE

Computing Support for Engineering

Применение ЭВМ в инженерной работе

Certified System Engineer

Сертифицированный системный инженер

CSECSG

Constructive Solid Geometry

Конструктивная объемная геометрия

Consulting Services Group

Консультационная группа поддержки [Lotus]

CSI

Convergence Sublayer Indicator

Индикатор подуровня конвергенции (ATM)

CSF

Central Simulation Facility

Центральное устройство моделирования

CSI

Cannel Status Indicator

Указатель состояния канала

CSL

Computer Sensitive Language

Язык, зависящий от ЭВМ

CSLIP

Compressed SLIP

Протокол SLIP со сжатием (RFC-1144, 19200бит/с или меньше)

CSM

Communications Services Manager

Менеджер служб коммуникации

Call Switching Module

Модуль переключения вызовов

CSMA/CD

Carrier Sense Multiple Access/Collision Detection

Способ множественного доступа с регистрацией столкновений (Ethernet)

CSNet

Computer+Science Network

Сеть для ЭВМ и науки

CSNP

Complete Sequence Number PDU

PDU посылаемый специяльным маршрутизатором OSPF c целью синхронизации баз данных

CSP

Constraint Satisfaction Problem

Проблема удовлетворения требованиям

Commercial Subroutine Package

Коммерческий пакет подпрограмм

Communicating Sequential Processes

Взаимодействующие последовательные процессы

CompuCom Speed Protocol

Протокол управления скоростью CompuCom

CSPCSPDN

Circuit Switched Public Data Network

Коммутируемая общедоступная информационная сеть

CSPDN

Circuit Switching Public Data Networks

Общественные коммутируемые сети передачи данных

CSR

Continuous Speech Recognition

Непрерывное распознавание голоса

Control/Status Register

Регистр управления и состояния (внешние устройства ЭВМ)

CSRC

Contributing Source

Источник составлящей потока

CSS

Continuous System Simulator

Язык программирования

Cascading Style Sheets

Каскадируемые стилевые листы (HTML)

CST

Central Standard Time

Центральное стандартное время

CSTA

Computer-Supported Telephony Applications

Применения ЭВМ в телефонии

CSU

Channel Service Unit (User DSU -> DDS lines)

Блок обслуживания канала

CSV

Comma-Separated Variables

Переменные, разделенные запятыми

Common Services Verbs (interface) [Microsoft]

 

C&T

Chips and Technologies

ИС и технология

CTA

Computer Intelligence Access

Доступ к ресурсам ЭВМ

CTB

Cipher Type Byte

Байт типа шифра

CTC

Conditional Transfer of Control

Условная передача управления

CTD

Cell Transfer Delay

Задержка передачи ячейки

CTE

Content-Transfer-Encoding

Транспортное кодирование содержимого (MIME)

CTERM

Command Terminal Protocol

Протокол терминальных команд (слой 6, служба виртуального терминала)

CTD

Cell Transfer Delay

Задержка передачи ячейки (ATM)

CTI

Computer-Telephone Integration

Объединение ЭВМ и телефонии

CTM

Communication Terminal Module

Оконечный коммуникационный терминал

CTOS

Computerized Tomography Operating System

Операционная система для компьютерной томографии

CTPA

Coax-to-Twisted-Pair Adapter

Адаптер коаксиальный кабель - скрученная пара

CTR

Common Technical Regulation

Общие технические условия

CTRBF

Constructive Tree RBF

Конструктивное дерево RBF

CTRL

Control

Управление

CTS

Clear To Send

Готовность к посылке

Common Transport Semantic

Общая транспортная семантика (базовая стратегия IBM, нацеленная на сокращение числа сетевых протоколов)

CTSS

Compatible Time Sharing System

Совместимая система разделения времени

CU

See You (*)

Пока

Control Unit

Устройство управления

CUA

Common User Access (SAA)

Общий доступ пользователей

CUB

Cursor Backward

Курсор назад

CUD

Cursor Down

Курсор вниз

CUE

Custom Updates and Extras (card) [Egghead Software]

Обычная актуализация и дополнения

CUF

Cursor Forward

Курсор вперед

CUG

Closed User Group

Замкнутая группа пользователей

CUL

See You Later (*)

Увидимся позже

CUI

Character-Oriented User Interface

Пользовательский интерфейс, ориентированный на символы

Common User Interface [IBM]

Общий пользовательский интерфейс

CUP

Cursor Position

Положение курсора

CUPID

Completely Universal Processor I/O Design

Конструкция полностью универсального ввода/вывода процессора [AST]

.CUR

Cursor

Расширение имени файла курсора

CUTE

Clarkston University Terminal Emulator

Терминальный эмулятор университета Clarkston

CUU

Cursor Up

Курсор вверх

СV

Code Violation

Нарушение регулярной кодовой последовательности

CVDT

Cell Variation Delay Tolerance

Допустимое отклонение вариации задержки ячейки (ATM)

CVF

Compressed Volume File

Файл, подвергнутый сжатию (double-space)

CVGA

Color Video Graphics Array

Матрица (массив) цветной видеографики

CVIA

Computer Virus Industry Association

Промышленная ассоциация по компьютерным вирусам

CVT

Convert

Преобразовать

CVW

CodeView for Windows

Просмотр программы

CW

Continuous Wave

Непрерывный режим (для лазеров)

Computer World

Мир ЭВМ

CWD

Convert Word to Double Word

Преобразовать обычный код в слово двойной длины

Change Working Directory

Изменить текущий каталог

CWI

Campus Wide Information Service/System [Internet]

Информационная служба/система кампуса (университетского городка)

C2X

Character To Hexadecimal [REXX]

Преобразование символа в шестнадцатеричный код

CYL

Cylinder

Цилиндр


Previous: 10.10.2 [B]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.4 [D]


previous up down next index index
Previous: 10.10.3 [C]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.5 [E]

10.10.4 [D]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

D1

 

24-канальная система с потоком Т1=1544 Кбит/с (Bell)

D2

 

24-канальная система, модификация D1 в соответствии с G.733

D4

Framing standard for 1.544Mbps

Стандарт на пакетную передачу со скоростью 1,544 Мбит/с

DA

Document Administrator

Администратор документов

D/A

Digital to Analog

Цифро-аналоговый

DAA

Data Access Arrangement

Организация доступа к данным

Decimal Adjust for Addition

Десятичное выравнивание для сложения

DAC

Data Acquisition and Control

Сбор данных и управление

Digital to Analog Converter

Цифро-аналоговый преобразователь

Dual-Attached Concentrator

Концентратор для подключения к двойному кольцу (FDDI или CDDI)

DAB

Dynamically Allocated Bandwidth

Динамически выделяемая полоса

DACS

Digital Access and Cross connect System

Система цифрового доступа и перекрестных связей

DAD

Desktop Application Director

Программа управления приложениями [Borland]

Draft ADdendum

Предложение по расширению стандарта

DAL

Data Access Language

Язык доступа к данным [Apple Computer]

Disk Access Lockout

Запрет доступа к диску

Dedicated Access Line

Специальный доступ к каналу

DAM

Data Acquisition and Monitoring

Сбор информации и мониторинг

Data Addressed Memory

Ассоциативная память

DANN

Dynamic Artificial Neural Network

Динамическая искусственная нейронная сеть

DANTE

Delivery of Advanced Network Technology to Europe

Привлечение продвинутых телекоммуникационных технологий в Европу

DAO

Data Access Objects [Microsoft]

Объекты доступа к данным

DAP

Data Access Protocol (DEC)

Протокол доступа к информации

Directory Access Protocol

Протокол доступа к каталогу

DAQ

Data AQuisition

Сбор данных

DAR

Damage Assessment Routine

Программа поиска и анализа неисправностей

DARI

Database Application Remote Interface

Удаленный доступ к базам данных [IBM]

DAS

Dual Attachment Station [FDDI]

Станция с двойной связью в сетях FDDI

Decimal Adjust for Subtraction

Десятичное выравнивание для вычитания

Data Acquisition System

Система сбора данных

Direct Attached Storage

Непосредственно подключенная память (PC)

Dynamically Assigned Socket

Соединители (сокеты) с динамическим доступом

DASS

Digital Access Signaling System

Цифровая сигнальная система доступа

DASD

Direct Access Storage Device

Прибор с прямым доступом к памяти

DAT

Digital Audio Tape

Цифровая магнитная лента для записи звука

Disk Array Technology

Технология, использующая массив дисков

DARPA

Defense Advanced Research Project Agency

Агентство по проекту продвинутых исследований в области обороны

.DAT

Data

Расширение имени файла данных

DATACOM

Data Communications

Передача данных

dB

Decibel

Децибел

DB

Data Base

База данных

Data Buffer

Буфер данных

DBA

DataBase Administrator

Администратор базы данных

DBCL

DataBase Control Language

Язык управления базой данных

DBCS

Double-Byte Character Set

Набор двухбайтовых символов

.DBF

Database

Расширение имени файла базы данных

DBM

Data Base Manager

Менеджер базы данных

DBMS

Data Base Management System

Система управления базой данных

DBP

Deutche BundesPost

Немецкая объединенная почта

DBS

Data Base Server

Сервер базы данных

Debug Service

Средства отладки

DC

Data Collection

Сбор данных

Data Channel

Канал данных

Data Communication

Передача данных

Data Control

Контроль данных

Device Control

Аппаратный контроль

Direct Current

Постоянный ток

D2C

Decimal To Character [REXX]

Преобразование десятичного кода в символ

DCA

Defense Communication Agency

Оборонное коммуникационное агентство

Digital Communications Associates

Участник цифровых коммуникаций

Document Content Architecture [IBM]

Архитектура структуры документов

DCAF

Distributed Console Access Facility [IBM]

Распределенная система консольного доступа

DCB

Disk Coprocessor Board [Novell]

Карта дискового сопроцессора

Device Control Block

Управляющий блок прибора

DCC

Data Country Code

Коды стран, определенные стандартом ISO 3166

Data Communication Channel

Канал передачи данных

Digital Compact Cassette

Цифровая компактная кассета

Display Combination Code

Код комбинации дисплея

DCCM

Data Communication Channel for Multiplex section

Канал передачи данных для регенераторной секции SDH

DCCR

Data Communication Channel for Regenerator section

Канал передачи данных для регенераторной секции SDH

DCD

Data Carrier Detected

Несущая данных детектирована

DCE

Data Communication Equipment

Оборудование для передачи данных

Data Circuit Equipment

Информационное оборудование

Distributed Computing Environment

Распределенная вычислительная среда [компания Open Software Foundation; продукт включает в себя систему безопасности]

DCF

Data Communication Facility [IBM]

Устройство передачи данных

Data Compression Facility

Устройство сжатия данных

Data Communication Function

Функция передачи данных

Data Count Field [IBM]

Поле счетчика данных

Driver Configuration File [Lotus]

Файл конфигурации драйвера

DCI

Desktop Computer Infrastructure

Инфраструктура настольной ЭВМ

DCL

Declaration

Декларация

DEC Command Language

Командный язык DEC

Device Clear

Сброс прибора в исходное состояние

Digital Control Logic

Цифровая логика управления

Digital Command Language

Цифровой командный язык [Digital]

DCME

Digital Circuit Multiplication Equipment

Оборудование для сжатия информации при телефонных переговорах

DCN

Data Communication Network

Сеть передачи данных

Didtributed Computer Network

Рапределенная сеть ЭВМ

DCOM

Distributed Component Object Model

Объектная модель распределенных компонентов (Microsoft)

DCS

Data Collection System

Система сбора данных

Data Control System

Система управления данными

Desktop Color Separation

Настольная система разделения цветов

DCT

Discrete Cosine Transform

Дискретное косинусное преобразование (сжатие графической информации)

.DCT

Dictionary

Расширение имени файла каталога

DD

Digital Display

Цифровой дисплей

Double Density

Двойная плотность

Data Demand

Запрос информации

Digital Data

Цифровые данные

DDA

Domain-Defined Attribute

Атрибут, определяемый доменом

Dynamic Document Assembly

Динамическая сборка документов

DDB

Digital Delay & Buffer

Цифровая задержка и буфер

Device Dependent Bitmap

Побитовая карта, зависящая от оборудования

DDC

Display Data Channel

Канал информационного дисплея

DDCMP

Digital Data Communications Message Protocol

Протокол для передачи цифровых сообщений [DEC]

DDCS

Distributed Database Connection Services

Услуги доступа к распределенной базе данных [IBM]

DDD

Direct Distance Dialing

Прямой автоматический телефонный набор номера

DDE

Dynamic Data Exchange (WINDOWS)

Динамический обмен данными

Direct Data Entry

Прямой ввод данных

DDEML

Dynamic Data Exchange Manager Library [Microsoft]

Библиотека менеджера динамического обмена данными

DDI

Direct Dialling-In

Прямой набор номера (ISDN)

DDK

Device Driver Kit [Microsoft Windows]

Система разработки драйверов

DDL

Data Definition Language

Язык определения данных

Data Description Language

Язык описания данных

DDLCN

Distributed Double Loop Computer Network

Двухкольцевая распределенная компьютерная сеть

DDM

Distributed Data Management

Распределенное управление данными

DDN

Defense Data Network

Оборонная информационная сеть

DDNS

Dynamic DNS

Динамическая служба имен

DDP

Datagram Delivery Protocol

Протокол доставки дейтограмм (AppleTalk)

DDS

Digital Dataphone Service

Цифровая служба Dataphone [AT&T]

Digital Data Storage

Цифровое запоминание данных

Digital Data System

Цифровая информационная система

Digital Data Service (56kbps)

Цифровая информационная служба (56 кбит/c)

DDSA

Digital Data Special Access

Специальный доступ к цифровым данным

DEA

Data Encryption Algorithm

Алгоритм шифрования данных

DEC

Digital Equipment Corporation

Название компании

Decrement

Декремент

Device Clear

Сброс прибора в исходное состояние

DECOM

Distributed Component Object Model

Модель Microsoft для формирования объектов и работы с ними в распределенной среде

DECT

Digital European Cordless Telecommunications

Европейский цифровой стандарт на беспроводные системы связи

DED

Double Error Detection

Детектирование двойных ошибок

DEF

Desktop Functional Equivalent [Compaq]

Функциональный эквивалент настольному варианту

.DEF

Definitions / Defaults

Расширение имени файла описаний (значений по умолчанию)

DEFRAG

Defragment

Дефрагментация

DEK

Data Encrypting Keys

Ключи шифрования данных

DEL

Delete

Стереть

DELSTR

Delete String [REXX]

Стереть строку

.DEM

Demonstration

Расширение имени файла демонстрации

DEPSK

Differentially Encoded PSK (Phase-Shift Keying)

Фазовая модуляция с дифференциальным кодированием

DER

Distinguished Encoding Rules

Продвинутые правила кодирования (ASN.1)

DES

Data Encrypting Standard

Федеральный стандарт шифрования документов

Data Entry Sheet

Лист ввода данных

Destination End Station

Станция назначения

.DES

Description

Расширение имени файла описания

DET

Device Execute Trigger

Триггер исполнения

DEV

Device

Прибор

DEW

Data Entry Workshop

Система ввода данных (библиотека Windows)

DF

Don't fragment Flag

Флаг запрета фрагментации (IP заголовок)

Data Field

Поле данных

Destination Field

Поле места назначения

Device Flag

Флаг прибора

Double Flag

Двойной флаг

DFC

Data Flow Control

Управление потоком данных

DFD

Data Flow Diagram

Блок-схема информационных потоков

DFE

Decision Feedback Equalizer

Эквилайзер с решающей обратной связью

DFI

DSP Format Identifier

Идентификатор формата DSP (ATM)

DFM

Division of Financial Management

Отдел управления финансами

DFN

Deutschen Forschungs Netze

Немецкие Исследовательские сети

DFS

Distributed File Service

Обслуживание распределенных файлов

Dynamic Frequency Selection

Динамический выбор частоты

DFT

Diagnostic Function Test

Тест диагностических функций

Discrete Fourier Transform

Цифровое Фурье преобразование

Distributed Function Terminal

Терминал с распределенными функциями

DFU

Data File Utility

Средство работы с информационным файлом

DGIS

Direct Graphics Interface Standard

Стандарт на графический интерфейс

DHCP

Dynamic Host Configuration Protocol

Протокол динамической реконфигурации ЭВМ

.DHP

Dr. Halo PIC

Расширение имени графического файла

DIA

Document Interchange Architecture

Архитектура документооборота

DIANE

Dynamic Installation and Network Enhancement

Динамическая инсталяция и сетевое усовершенствование (для PC)

DIB

Device Independent Bitmap

Битовая карта, не зависящая от оборудования (Windows)

Directory Information Base

Информационная база каталогов (X.500)

DICC

Drop/Insert and Cross-Connect

Система коммуникаций (Philips)

DID

Direct Inward dial (Fax)

Прямой внутренний набор номера

DIIP

Direct Interrupt Identification Port

Прямая идентификация порта прерывания

DIME

Direct Internet Messaging Encapsulation

Прямая инкапсуляция сообщений в Интернет

DIN

Deutsche Industrie Norm

Немецкий набор стандартов (эквивалент EIA)

DIO

Data Input-Output

Ввод/вывод данных

DIOS

DIstributed Operating System

Распределенная операционная система

DIP

Dual In line Package

Двухрядный корпус

Digital Imaging Processing

Цифровая обработка изображения

Dual In-line Package

Двухрядный корпус ИС

DIS

Draft Information Standard

Проект информационного стандарта

Dynamic Impedance Stabilization

Динамически независимая стабилизация [CompuCom]

DISA

Defense Information Systems Agency

Агенство оборонных информационных систем (США)

DISOSS

DIStributed Office Support System

Распределенная система поддержки офиса

DIT

Directory Information Tree

Информационное дерево каталога (X.500)

DIVON

Demonstration of Interworking Via Optical Network

Демонстрация взаимодействия через оптическую сеть

DIVOT

Digital-to-Voice Translation

Преобразователь цифрового кода в речь

DIX

DEC/Intel/Xerox

Компании-разработчики сети Ethernet

DHS

Data Handling System

Система обработки данных

DLAL

Dual Letter Acronym Listing

Список двухбуквенных акронимов

DLC

Data Link Control (protocol)

Протокол управления информационным каналом [IBM]

Digital Loop Carrier

Система для подключения абонентов к сети (напр. телефонной)

DLCI

Data Link Control Interface (Identifier)

Адрес управляющего интерфейса информационного канала (Управляющий идентификатор канала).

Data Link Connection Identifier

Идентификатор соединения канала данных

DLE

Data Latch Enable

Разрешение доступа к триггеру данных

Data Link Escape

Символ ESC

DLL

Dynamically Linked (loaded) Library

Динамически загружаемая библиотека

Data Link Layer

Канальный уровень

DLM

Dynamic Link Module

Модуль динамической связи

DLPI

Data Link Provider Interface

Интерфейс провайдера информационного канала

DLR

DOS LAN Requester

Источник сетевого запроса DOS

DLS

Digital Library System

Система цифровой библиотеки

Data Link Switching

Переключение информационного канала (SNA и NetBIOS через TCP/IP)

DLT

Digital Linear Tape

Цифровая линейная лента

DLU

Dependent LU

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

DLUR

Dependent LU Requester

Источник запроса к логическому блоку (SNA-архитектура)

DLUS

Dependent LU Server

Серверная часть улучшенного сетевого взамодействия партнеров

DM

Distributed Memory

Распределенная память

Disconnect Mode

Режим отключения

DMA

Direct Memory Access/Addressing

Прямой доступ к памяти

Document Management Alliance

Объединение по делопроизводству

DMAC

DMA Controller

Контроллер прямого доступа к памяти

Destination MAC

MAC-адрес места назначения

DME

Distributed Management Environment

Распределенная среда управления

DMF-MAIL

Digest Message Format for Mail

Формат краткого содержания почтовых сообщений (RFC-1153)

DMI

Desktop Management Interface

Управляющий интерфейс настольной системы

DML

Data Manipulation Language

Язык манипуляции данными

DMM

Digital Multimeter

Цифровой мультиметр

DMMS

Dynamic Memory Management System

Система управления динамической памятью

DMOS

Double-diffused Metal-Oxide Semiconductor

Дважды диффузионный метал-оксидный полупроводник

Document Management Objects and Services

Объекты и услуги при управлении документами

DMP

Dot Matrix Printer

Матричный принтер

DMPC

Distributed Memory Parallel Computer

Параллельный компьютер с распределенной памятью

DMQS

Display Mode Query and Set

Запрос и установка режима дисплея [IBM]

DMS

Data Management Software

Программа управления данными

Data Management System

Система управления данными/документами (СУД)

Dynamic Mapping System

Система динамического отображения

DMSD

Digital Multistandard Decoding

Цифровое многостандартное декодирование

DMT

Discrete MultiTone

Дискретная многотональная модуляция

DMTF

Desktop Management Task Force

Комитет по системам управления настольными системами

DMY

Day Month Year

День, месяц, год

DN

Destination Name

Имя места назначения (X.500)

DNA

Digital Networking Architecture

Архитектура цифровых сетей

DNANS

DNA Naming Service

Служба имен DNA

DNCP

DEC Net Control Protocol

Управляющий протокол DECnet

DNF

Disjunctive Normal Form

Дизюнктивная нормальная форма

DNIC

Data Network Identification Code

Код идентификации информационной сети

DNC

Direct Numerical Control

Прямой цифровой контроль

DNIS

Dialed Number Identification Service

Служба идентификации набранного номера

DNM

Distributed Node Management

Управление распределенными узлами

DNS

Domain Name System

База данных имен доменов (RFC-1034, -1035)

DO

Data Out

Вывод данных

DOCSIS

Data-over-Cable Service Interface Specifications

Спецификации подключения клиента через кабель

DoD

Department of Defense

Министерство обороны США

DOE

Department of Energy

Министерство энергетики США

Distributed Objects Everywhere

Распределенные всюду объекты

DOMF

Distributed Object Management Facility

Система управления распределенными объектами

DOMS

Distributed Object Management System

Распределенная система управления объектами

DOS

Disk Operating System

Дисковая операционная система

Denial of Service

Отказ в обслуживании (вид сетевых атак)

DOSEM

DOS Emulation

Эмуляция DOS

DOV

Data Over Voice (data & voice)

Данные через голос

DOW

Day Of Week

День недели

DP

Dynamic Programming

Динамическое программирование

Data Processing

Обработка данных

DPA

Demand Protocol Architecture

Архитектура протокольного запроса [3Com]

Dynamic Page Assembler

Динамический сборщик страниц

DPAREN

Data Parity Enable

Активация контроля четности [IBM]

DPB

Drive Parameter Block

Блок параметров драйвера

DPC

Direct Program Control

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

DPF

Division of Particles and Fields of the APS

Отдел частиц и полей APS

DPI

Distributed Program Interface

Распределенный программный интерфейс (RFC-1228)

Dots Per Inch

Число точек на дюйм

DPL

Descriptor Privilege Level

Уровень привилегии описателя

DPLL

Digital Phase locked Loop

Цифровая фазировка

DPM

Double Port Memory

Двухпортовая память

Documents per Minute

Документов в минуту

Digital Panel Meter

Цифровой панельный измеритель

DPMA

Data Processing Management Association

Ассоциация управления обработкой данных

DPMI

DOS Protected Mode Interface

Интерфейс защищенного режима DOS [Microsoft]

DPNSS

Digital Private Network Signaling System

Цифровая сигнальная система частных сетей (ISDN)

DPO

Data Phase Optimization

Оптимизация фазы данных

DPR

Data Processing Rate

Скорость обработки данных

DPRS

Distributed Primary Reference Source

Распределенный первичный эталонный источник

DPS

Document Processing System

Система обработки документов

DPSK

Differential Phase Shift Keying

Метод модуляции, при котором изменяется фаза несущей частоты при постоянной амплитуде и частоте, в отличие от метода BPSK фазовый сдвиг может принимать несколько значений, например, 0, π/2, π и 3π/2, что позволяет кодировать 2-х битовые символы

DPSS

Diode Pumped Solid State

Твердотельный диод с подкачкой (лазер ND:YAG)

DQDB

Distributed Queue Dual Bus

Двойная шина с распределенной очередью (802.6)

DQL

DataEase Query Language [DataEase International]

Интернациональный язык запросов

DRAM

Dynamic Random Access Memory

Динамическая память с произвольным доступом

DR

Resignated Router

Специально выделенный маршрутизатор (протокол PIM)

Data Received

Данные получены

D/R

Direct or Reverse

Прямо или наоборот

DRAM

Dynamic Random Access Memory

Динамическая память с произвольным доступом

DRAW

Direct Read After Write

Прямое чтение после записи

DR.BOND

Dial-up Router Bandwidth On Demand [NEC]

Маршрутизатор с полосой пропускания по требованию

DRDA

Distributed Relational Database Architecture [IBM]

Архитектура распределенных реляционных баз данных

DRDW

Direct Read During Write

Прямое чтение во время записи

DRG

Division of Research Grants

Отдел исследовательских грантов

DRI

Digital Research Incorporated

Название корпорации

DRO

Data Request Output

Выход запроса информации

Destructive Read-Out

Чтение с разрушением

Data Receive Only

Только прием данных

DRS

Digital Reconfiguration Service

Система цифровой реконфигурации

DS0

Digital Signal of level 0

Канал с пропускной способностью 64 Кбит/с

DS-1

1.544 Mbps (or 2.108 Mbps for Europe) channel

Канал с пропускной способностью 1544 Кбит/с (2108 Кбит/с для Европы)

DS-2

Digital Signal of level 3

Канал с пропускной способностью 44,756 Мбит/с

DS-3

45 Mbps channel (T3)

Канал с пропускной способностью 45 Мбит/с

DS-4

Digital Signal of level 4

Канал с пропускной способностью 274,176 Мбит/с

DS

Data Segment

Сегмент данных

Data Send

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

Data Server

Сервер данных

Double Sided

Двухсторонний

DSA

Directory System Agent

Агент системного каталога

Digital Signature Algorithm

Алгоритм цифровой подписи

Distributed Systems Architecture

Архитектура распределенных систем

DSAB

Distributed Systems Architecture Board

Совет по архитектуре распределенных систем

DSAP

Destination Service Access Point

Точка доступа для обслуживания получателя

DSB

Double Side Band

Две боковые полосы

DSС

Document Structuring Convention

Соглашение о структуре документов PostScript

DSDD

Double Sided, Double Density

Двухсторонний с двойной плотностью (о гибком диске)

DSE

Data Storage Equipment

Оборудование памяти

Data switching Exchange

Коммутируемый обмен данными

DSEA

Display Station Emulation Adapter

Эмуляционный адаптер дисплейной станции

DSF

Dispersion Shifted Fiber

Дисперсионно смещенное волокно

DSECT

Dummy Control Section

Пустая контрольная секция

DSHD

Double Sided, High Density

Двухсторонний с высокой плотностью (о гибком диске)

DSIS

Distributed Support Information Standard

Информационный стандарт для распределенных систем

DSJ

Digital Signal of Japan hierarchy

Цифровой канал японской иерархии PDH

DSL

Dynamic Simulation Language

Язык динамического моделирования

Digital Subscriber Line

Канал ISDN Basic Rate Interface.

DSOM

Distributed System Object Model

Объектная модель распределенной системы

DSM

Distributed System Manager

Распределенный системный менеджер (IBM)

DSMA

Digital Sense Multiple Access

Множественный доступ с цифровым управлением

DSP

Digital Signal Processor

Цифровой сигнальный процессор

Domain Specific Part

Специфическая часть домена

DSPU

DownStream Physical Unit

Нижерасположенный физический модуль (SNA)

DSQD

Double Sided, Quad Density

Двухсторонний, четверной плотности (о гибком диске)

DSR

Data Set Ready (RS-232-C signal)

Данные готовы

Device Status Register

Статусный регистр устройства

Device Status Report

Статусное сообщение устройства

DSS

Decision Support System

Система поддержки решения

Digital Signature Standard

Стандарт на цифровую подпись

DST

Data Summary Tape

Лента с результирующими данными

Dispersion Supported Transmission

 

DSTN

Double Supertwisted Nematic

 

DSU

Data Service Unit

Блок информационных услуг

Digital Service Unit

Блок цифровых услуг

DSW

Data Status Word

Слово состояния данных

Device Status Word

Слово состояния прибора (внешнего устройства)

DSX

Digital Service X

 

DTA

Disk Transfer Area

 

DTD

Document Type Definition

Описание структуры SGML-документа (HTML)

DTE

Data Terminal Equipment

Информационное терминальное оборудование

Dumb Terminal Emulator

 

DTIN

DOE Technology Information Network

Технологическая информационная сеть департамента энергетики США

DTL

Diode-Transistor Logic

Диодно-транзисторная логика (ИС)

Designated Transit List

Список узлов и каналов, полностью описывющий маршрут

DTMF

Dual Tone Multi-Frequency

Двухтоновый многочастотный

Desktop Management Task force

Группа по управлению настольными системами

DTP

DeskTop Publishing

Настольное издательство

DTR

Data Terminal Ready

Терминал готов (RS-232-C сигнал)

Data Transfer Rate

Скорость передачи данных

DTS

Distributed Time Service

Услуги, распределенные во времени

DTV

Desktop Video

Настольное видео

DTVC

Desktop Video Conferencing

Настольная видеоконференция

DU

Disk Usage

Использование диска

DUA

Directory User Agent

Агент каталога пользователя

DUAL

Diffusing Update Algorithm

Алгоритм конвергенции, используемый в протоколе маршрутизации IGRP

DUAT

Direct User Access Terminal

Терминал прямого доступа пользователя

DUP

Diagnostics & Utilities Protocol

Протокол диагностики и рабочих средств (DEC)

DVD

Digital Versatile/Visual Disc

Универсальный цифровой диск (пригоден и для видео)

DVE

Digital Video Effect

Эффект цифрового видео

DVI

Digital Video Interactive

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

DVM

Digital Voltmeter

Цифровой вольтметр

DVMRP

Distance Vector Multicast Routing Protocol (RFC1112,988)

Протокол маршрутизации мультикастинга с вектором расстояния в качестве метрики

DWDM

Dense Wavelength Division Multiplexing

Высокоплотное мультиплексирование с разделением по длине волны

DWH

Data Warehouse

Хранилище данных

DWHM

Data Warehouse Management

Управление хранилищем данных

DWI

Descriptor Word Index

Словарь дескрипторов

D2X

Decimal To Hexadecimal [REXX]

Десятично-шестнадцатеричное преобразование

DXC

Data Exchange Control

Управление обменом данных

Data Exchange Connect

Цифровой коммутатор

DXF

Drawing Exchange Format

Формат передачи рисунков

DXI

Data Exchange Interface

Интерфейс обмена данными (ATM)


Previous: 10.10.3 [C]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.5 [E]


previous up down next index index
Previous: 10.10.4 [D]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.6 [F]

10.10.5 [E]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

E1

2.048 Mbps digital carrier system (CEPT)

Система передачи данных на скорости 2048 Кбит/с

E.163

CCITT numbering scheme for public switched telephone networks

Схема нумерации CCITT для общественных коммутируемых телефонных сетей

E.164

CCITT standard for numbering in an ISDN environment

Стандарт CCITT нумерации в среде ISDN

E-Channel

64 Kbps (ISDN)

Канал 64 кбит/с ISDN

EA

Extended Address (ISDN)

Бит расширения адресного поля

EACK

Extended ACKnowlegement

Расширенное подтверждение

EAI

Enterprise Application-Integration

Интеграция приложений предприятия

EAP

Extensible Authentication Protocol

Расширяемый протокол аутентификации

EARN

European Academic Research Network

Европейская академическая исследовательская сеть, связанная с BITNET и NETNORTH

EAROM

Electrically Alterable Read Only Memory

Электрически перезаписываемая база данных

EARS

Electronic Access to Reference Services

Электронный доступ базовым услугам

EAS

Extended Area Service

Услуга с расширенной обсластью доступа

EasyNet

DEC internal communication network

Внутренняя коммуникационная сеть DEC

EAT

Ebone Action Team

Рабочая группа Европейской опорной сети

EATA

Enhanced AT Bus Attachment

Улучшенное подключение к AT-шине

EAU

Ebone Administration Unit

Блок администрирования Европейской опорной сетью

EB

Errored Block

Блок с ошибками

EBC

EISA Bus Controller

Контроллер шины EISA

EBCB

European Bank of Computer Programs in Biotechnology

Европейский банк программ ЭВМ по биотехнологии

EBCDIC

Extended Binary Coded Decimal Interchange Code (IBM)

Расширенная система двоично-десятичного кодирования, используемая при пересылке данных

EBI

Equivalent Background Input

Эквивалентный фоновый ввод

Extended Background Investigation

 

EBONE

European IP BackBONE

Европейская опорная сеть IP

EBS

Ebone Boundary System

Пограничная система Ebone

EBT

Electronic Benefits Transfer

 

EC

Error Correction

Коррекция ошибок

Echo Cancellation

Эхо подавление

European Community

Европейское сообщество

ECAL

Enjoy Computing And Learn

Обучение и развлечение с использованием ЭВМ

ECB

Electronic Code Book

Электронная книга кодов

Event Control Block

Блок контроля событий

ECC

Error Check Code

Программа контроля ошибок

Error Checking and Correction

Проверка и исправление ошибок

Extension Control Block

Управляющий блок

Error Correction Code

Программа коррекции ошибок

Embedded Control Channel

Встроенный канал управления

Electronic Communication Commission

Комиссия по электронным коммуникациям

ECE

Excessive Collision Error

Ошибка из-за слишком большого числа столкновений (Ethernet)

ECD

Enhanced Color Display

Улучшенный цветной дисплей

ECHO

European Commission Host Organization

Организация ЭВМ европейской комиссии [Internet]

ECL

Emitter Coupled Logic

Эмиттерно-связанная логика

ECM

Enhanced Command Mode

Улучшенный командный режим

ECMA

European Computer Manufacturers Association

Европейская ассоциация производителей ЭВМ

ECNE

Enterprise Certified NetWare Engineer [Novell]

Сетевой инженер сертифицированный фирмой

ECP

Enhanced Capabilities Port [Microsoft]

Порт улучшенных возможностей

ECTL

Electronic Communal Temporal Lobe

 

ED

Error Detection

Детектирование ошибок

Erase Display

Стереть изображение

End Delimitor

Оконечный разграничитель

EDA

Embedded Document Architecture [Go Corporation]

Архитектура встроенной документации

EDC

Enhanced Data Correction

Улучшенная коррекция данных

Enhanced Data Connector

2-парный разъем Token Ring

Error Detection and Correction (or Code)

Детектирование и исправление ошибок (или программа для .)

EDDC

Extended Distance Data Cable

Кабель данных повышенной длины

EDFA

Erbium Doped Optical Fiber Amplifier

Усилитель для оптического волокна с допированием ербием

EDGAR

Electronic Data Gathering, Analysis and Retrieval

Электронный сбор данных, анализ

EDH

Electronic Document Handling (CERN, invoices)

Электронная обработка документов

EDI

Electronic Data Interchange

Электронный обмен данными

Electronic Document Interchange

Электронный обмен документами [DEC]

EDIFACT

Electronic Data Interchange For Administration, Commerce And Transport

Электронный обмен данными для управления, торговли и транспорта

EDM

Engineering Document Management

Управление техническими данными и документами

Enterprise Document Management

Управление документами учреждения

EDMS

Enterprise Document Management Services

Услуги, управления документами учреждения

EDNA

European Data Network Agency

Европейское агентство по информационным сетям

EDI

Electronic Data Interchange

Электронный обмен информацией

EDIFACT

Electronic Data Interchange for Administration, Commerce and Transport

Электронный обмен данными для администрации, коммерции и транспорта

EDL

Edit Decision List

 

EDLC

Ethernet Data Link Control

Управление каналом Ethernet

EDO

Extended Data Output

Расширенный вывод данных (вид памяти)

EDOS

Enhanced DOS for Windows

Улучшенная DOS для Windows

EDP

Electronic Data Processing

Электронная обработка информации

EDPM

Electronic Data Processing Machine

Машина электронной обработки данных

EDSI

Enhanced Small Device Interface

Улучшенный интерфейс малых периферийных устройств

EDT

Eastern Daylight Time

Восточное дневное время

EDU

Education (organization Domain name)

Фрагмент имени домена, указывающий на принадлежность к сфере образования [Internet]

EDVAC

Electronic Discrete Variable Automatic Computer

Первая цифровая ЭВМ с запоминанием программы

EEC

European Economic Community

Европейское Экономическое сообщество

Extended Error Correction

Расширенная коррекция ошибок

EECM

End-to-End Call Manager

Менеджер вызовов точка-точка

EEG

Electroencephalogram

Электроэнцифалограмма

EEHO

Either End Hop Off

 

EEM

Extended Memory Management

Управление расширенной памяти

EEMS

Enhanced Expanded Memory Specification

Спецификация улучшенной расширенной памяти

EEPROM

Electrically Erasable Programmable Read-Only Memory

Электрически стираемая программируемая память, рассчитанная только на чтение

EES

Escrow Encryption Standard

Стандарт шифрования

EET

Edge Enhancement Technology

Технология улучшения края

EFA

Extended File Attribute

Расширенный атрибут файла

EFCI

Explicit Forward Congestion Indication

Явное указание перегрузки

EFD

End Frame Delimiter

Оконечный разделитель кадра

EFF

Electronic Frontier Foundation

 

EFI

Electromechanical Frequency Interference

Электромеханическая частотная интерференция

Electronics For Imaging

Электроника для работы с изображением

EFL

Emitter Follower Logic

Логика на эмиттерных повторителях

EFM

Ethernet First Mile

Первая миля Ethernet (название комитета по развитию Ethernet-технологии)

EFS

Electronic Filing Software

Электронная система документооборота (Excalibur)

EFTS

Electronic Funds Transfer System

Электронная система перевода средств

EGA

Enhanced Graphics Adapter

Улучшенный графический адаптер

EGP

Exterior Gateway Protocol

Протокол внешних портов (внешний протокол маршрутизации; RFC-827, -904)

EHF-MAIL

Encoding Header Field for Mail

Закодированный заголовок для почты (RFC-1154)

EHLLAPI

Emulator High Level Language Application Programming Interface [IBM]

Эмулирующий язык высокого уровня интерфейса прикладного программирования

EIA

Electronic Industries Association

Ассоциация электронной промышленности

EIP

Extended Internet Protocol

Расширенный протокол Интернет (RFC-1385)

Ethernet Interface Processor

Процессор интерфейса Ethernet

EIS

Executive Information System

Исполнительная информационная система

EISA

Extended Industry Standard Architecture

Расширенная промышленная стандартная архитектура (шина IBM/PC)

EKF

Extended Kalman Filtering

Расширенная фильтрация Кальмана

EKTS

Electronic Key Telephone Sets

Телефон с клавишным набором

EL

Electroluminescent

Электролюминисцентный (дисплей)

Erase Line

Стереть строку

ELAP

EtherTalk Link Access Protocol

Протокол доступа к каналу EtherTalk

ELF

Extremely Low Frequency

Крайне низкая частота

ELMI

Enhanced Local Management Interface

Улучшенный интерфейс локального управления

ELMS

Extended Lan Management Software

Программное обеспечение для управления большими локальными сетями

ELS

Entry Level System

Система входного уровня

EM

Expectation Maximization

Максимизация ожидания

Electronic Mail

Электронная почта

ElectroMagnetic

Электромагнитный

Element Manager

Менеджер сетевого элемента

Expanded Memory

Расширенная память

EMA

Electronic Mail Association

Ассоциация электронной почты

Enterprise Management Architecture

Архитектура управления коммерческим предприятием

EMACS

Editing Macros

Редактирующие макро [Unix]

EMB

Extended Memory Block [LIM/AST]

Блок расширенной памяти

EMBARC

Electronic Mail Broadcast to a Roaming Computer

Электронная широковещательная рассылка почты [Motorola]

EMC

Electromagnetic Compatibility

Электромагнитная совместимость

Extended Math Coprocessor

Расширенный математический процессор

EMF

Enhanced Metafile Format

Улучшенный формат метафайла

EMI

Electromagnetic Interference

Электромагнитная интерференция (наводки/помехи)

EMM

Expanded Memory Manager

Менеджер расширенной памяти

EMP

Enhanced Memory Product

Улучшенный образец памяти

ElectroMagnetic Pulse

Электро-магнитный импульс

EMPP

European 2 Mb MultiProtocol Pilot

 

EMR

Electro-Magnetic Radiation

Электромагнитное излучение

EMS

Electronic Mail System

Электронная почтовая система

Electronic Message Service

Электронная служба сообщений

Expanded Memory Specification [LIM]

Спецификация расширенной памяти

EN

End Node

Оконечный узел

ENFIA

Exchange Network Facilities For Interstate Access

Системы сетевого обмена для межгосударственного доступа

ENIAC

Electronic Numerical Integrator Analyzer and Computer

Первая полностью электронная цифровая машина

ENM

ECI Network Manager

Сетевой менеджер компании ECI

ENNS

European Neural Network Society

Европейское общество нейронных сетей

ENQ

Enquiry

Запрос

ENS

Enterprise Network Service (Banyan)

Сетевая система предприятия

ENSS

Exterior Nodal Switching Subsystem [Internet]

Внешняя узловая субсистема переключения

EOA

End of Address

Конец адреса

EOB

End of Block

Конец блока

EOC

End of Conversion

Конец преобразования

Embedded Operations Channel

Встроенный канал управления

EOD

End of Data

Конец данных

EOF

End of File

Конец файла

EOI

End or Identify

Конец идентификации

EOJ

End of Job

Конец задачи

EOL

End Of Line

Конец строки

End of Option List

Конец списка опций

EOM

End of Message

Конец сообщения

EOR

End Of Record

Конец записи

Exclusive OR (Also XOR)

Исключительное ИЛИ

EOS

Earth Observing System

Система наблюдения Земли [NASA]

Element Operations System

Система управления элементом сети

End Of String

Конец строки символов

EOSDIS

Earth Observing System Data and Information System

Информационная система для наблюдения Земли [NASA]

EOT

End of Transmission

Конец передачи

Ebone Operations Team

Оперативный персонал EBONE

End Of Table

Конец таблицы

End of Tape (marker)

Маркер "конец ленты"

End of Text

Конец текста

EOW

Engineering Order Wire/Wiring

Служебный канал

EPA

Enhanced Performance Architecture

Архитектура с улучшенными рабочими характеристиками

EPB

EXEC Parameter Block

Блок параметров EXEC

EPD

Early Packet Discard

Преждевременное отбрасывание пакета (управление очередями)

EPI

Electronic Payment Instruments

Средства для электронных платежей

EPIC

Electronic Privacy Information Center

Центр безопасности электронной информации

EPIP

Easy Product Installation Procedure

Простая процедура инсталляции продукта

EPL

Effective Privilege Level

Эффективный уровень привилегий

EPLD

Electrically Programmable Logic Device

Электрически программируемый логический прибор

EPM

Enhanced Editor for Presentation Manager

Улучшенный редактор для менеджера презентаций [IBM]

Enterprise Process Management

Управление процессами на предприятии [IBM]

EPP

Enhanced Parallel Port

Улучшенный параллельный порт

EPPI

 

Физический интерфейс PDH (140 или 2 Мбит/с)

EPROM

Electrically Programmable Read Only Memory

Электрически перепрограммируемая память, рассчитанная только на чтение

EPS

Encapsulated PostScript

Инкапсулированный PostScript

EPSF

Encapsulated PostScript Files

Файлы в стандарте EPS

EPSI

Encapsulated PostScript Interchange

Формат обмена встроенными файлами PostScript

EPSCS

Enhanced Private Switching Communication Service

Улучшенная частная коммутируемая система коммуникаций

ERA

Embedded Remote Access

Встроенная система удаленного доступа

ERAS

Electronic Routing and Approval System

Система электронной маршрутизации и одобрения [Hughes Aircraft]

ERIC

Educational Resources Information Center [Internet]

Информационный центр образовательных ресурсов

ERL

Echo Return Loss

 

ERLL

Enhanced Run Length Limited

 

EROM

Erasable Read Only Memory

Стираемая память рассчитанная только на чтение

ERR

Error

Ошибка

ERVN

Energy Research Videoconferencing Network

Сеть видеоконференций для исследований в области энергетики

ES

End System (OSI RFC1070)

Оконечная система

Extra Segment

Дополнительный сегмент

ESA

European Space Agency

Европейское Космическое Агентство

Enterprise Systems Architecture [IBM]

Архитектура корпоративных систем

ESC

Engineering Services Channel/Circuit (satellite)

Канал/схема для инженерного обслуживания

Escape

Управляющий символ

ESCM

Extended Services Communications Manager [IBM]

Коммуникационный менеджер расширенных услуг

ESCON

Enterprise System Connection (Architecture)

Корпоративная система связи [IBM]

ESC/P

Epson Standard Code for Printers

Стандартная программа фирмы Epson для принтеров

ESD

ElectroStatic Discharge

Электростатический разряд

Electronic Software Distribution

Распространение программного обеспечения

End of Stream Delimiter

Разграничитель конца потока

ESDI

Enhanced Small Device Interface

Интерфейс для подключения периферийных устройств

ESF

Extended Superframe Format

Расширенный формат суперкадров

ESI

Enhanced Serial Interface (specification) [Hayes]

Улучшенный последовательный интерфейс

End System Identifier

Конечный системный идентификатор (ATM)

ES-IS

End System to Intermediate System (protocol)

Протокол связи оконечной и промежуточной систем

ESMTP

Extended Simple Mail Transfer Protocol

Расширенный простой протокол пересылки почты (RFC-1869)

ESNET

Energy Sciences Network, computer network of DOE/OER

Компьютерная сеть для атомной энергетики США

ESP

Emulation Sensing Processor

Процессор, чувствительный к эмуляции

Encapsulating Security Payload

Поле данных со встроенными средствами безопасности (IPv6)

Enhanced Serial Port [Hayes]

Улучшенный последовательный порт

Extended Services Processor

Процессор услуг с расширенными возможностями

ESR

Errored Second Ratio

Процент секунд с ошибками

ESS

Electronic Switching System

Электронная система переключения

Electronic System Service

Электронная система обслуживания

ESSID

Extended Service Set Identifier

Идентификатор расширенного набора услуг

EST

Eastern Standard Time

Восточное стандартное время

ESU

Electro-Static Unit

Электростатический блок

ETANN

Electrically Trainable Analog Neural Network

Электрически обучаемая аналоговая нейронная сеть (ИС, INTEL)

ETB

End of Transmission Block

Блок конца передачи

ETC

Enhanced Throughput Cellular

Протокол модема (сотовая система с улучшенной пропускной способностью) [AT&T]

ETCP

Extended TCP

Расширенный протокол TCP

ETPL

Endorsed Tempest Products List

 

ETN

Electronic Tandem Network

Электронная сеть Tandem

ETS

Econometric Time Series

Эконометрические временные ряды

ETSI

European Telecommunication Standards Institute

Европейский институт стандартов в области телекоммуникаций

ETX

End of Text

Конец текста (управляющий символ)

EU

Execution Unit

Блок исполнения

EUnet

European UNIX Network (based on UUCP)

Европейская UNIX-сеть, базируется на UUCP

EUTELSAT

European Telecommunication Satellite Organization

Европейская организация по телекоммуникационным спутникам

EUUG

European UNIX system User Group

Европейская группа пользователей UNIX

EVE

Extensible VAX Editor

Расширяемый редактор VAX

EVGA

Extended Video Graphics Array

Расширенная видеографическая матрица

Extended Video Graphics Adapter

Видеоадаптер расширенной графики

EWAN

Emulator Without A Good Name

Эмулятор без хорошего имени (Telnet; Internet)

EWS

Employee Written Software [IBM]

Программы, написанные сотрудниками

EXC

Excessive errors

Слишком много ошибок

ExCA

Exchangeable Card Architecture [Intel]

Архитектура со сменными картами

EXE2BIN

Program used to convert an (.EXE) file to binary format (.COM) file

Программа преобразования файла EXE-типа в COM-тип

exabyte

one billion gigabytes

Один миллиард гигабайт (?)

EXP

Exponent

Экспонента

EXT

External

Внешний

EXTRN

External Reference

Внешняя ссылка


Previous: 10.10.4 [D]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.6 [F]


previous up down next index index
Previous: 10.10.5 [E]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.7 [G]

10.10.6 [F]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

F.60

CCITT standard for telex service

CCITT стандарт для телексной связи

F.69

CCITT standard for telex addresses

Стандарт CCITT для адресов телекс

F.110

CCITT standard for maritime mobile service

Стандарт CCITT для приморской мобильной связи

F.160

CCITT standard for international public fax service

Стандарт CCITT для международной общедоступной факсимильной службы

F.200

CCITT standard for teletext service

Стандарт CCITT для службы телетекста

F.201

CCITT standard for internetwork teletext & telex service

Стандарт CCITT для межсетевой службы телетекста и телекса

F.300

A set of CCITT recommendations for Videotext systems

Набор CCITT рекомендаций для систем видеотекста

F.401

CCITT standard for naming & addressing for public message-handling service

Стандарт CCITT для адресов и имен общедоступных систем обработки сообщений

F.410

CCITT standard for public message transfer service public physical delivery service

Стандарт CCITT для общедоступных систем передачи сообщений на физическом уровне

F.420

CCITT standard for public interpersonal message service

Стандарт CCITT для межперсонального обмена сообщениями

F.421

CCITT standard for communication between X.400 interpersonal messaging and telex service

Стандарт CCITT для коммуникаций между X.400 и телексом

F.422

CCITT standard for communication between X.400 interpersonal messaging and teletext service

Стандарт CCITT для коммуникаций между межперсональной системы обмена X.400 и телетекстом

F.500

CCITT standard for international public directory service

Стандарт CCITT для интернациональной системы каталогов

FAA

Facility Accepted Message

Позитивный отклик на запрос FAR

FAB

Computer-Chip Fabrication Plant

Завод, производящий компьютерные чипы

FAC

File Access Code

Программа доступа к файлу

FAM

Fuzzy Associative Memory (USL)

Ассоциативная память типа фази

Fast Auxilary Memory

Быстрая вспомогательная память

FAMOS

Floating Gate Avalanche MOS

Лавинный MOS с плавающим затвором

FAP

File Access Protocol

Протокол доступа к файлам

FAPI

Family Application Program Interface

Программный интерфейс семейства приложений

FAQ

Frequently Asked Question

Часто задаваемые вопросы

FAR

Facility Request Message

Посылается одним коммутатором другому для активации его состояния (ISDN).

FARNET

Federation of American Research Networks [Internet]

Федерация американских исследовательских сетей

FAS

Frame Alignment Signal

Сигнал синхронизации кадра

FAT

File Allocation Table

Таблица, определяющая размещение файла

FAX

Facsimile

Факс

FC

Fiber optic Connector

Оптоволоконный разъем

Frame Control

Управление кадром (IEEE 802.4)

FC-AL

Fibre Channel Arbitration Loop

Петля арбитража сети Fibre Channel

FCB

File Control Block

Блок управления файла

FCC

Federal Communication Commission

Федеральная телекоммуникационная комиссия

FCCSET

Federal Coordination Council for Science, Engineering and Technology

Федеральный координационный совет по науке, технике и технологии

FCE

False Carrier Event

Ложная несущая

FCFS

First Come First Served

Первым пришел, первым обслужен

FCI

Flux Changes per Inch

Число смен направления потока на дюйм

Frame Copying Indicator

Индикатор копирования кадра (IEEE 802.5)

FCIP

Fibre Channel with IP-protocol

Fibre Channel c IP

FCS

Fiber Channel Standard

Стандарт на волоконные каналы

Fast Circuit Switching

Переключение быстродействующей схемы (быстрая коммутация каналов)

Frame Check Sequence

Контрольная сумма кадра (пакета)

FD

Floppy Disk

Гибкий диск

Floppy Drive

Драйвер гибкого диска

Full Duplex

Полный двунаправленный обмен

FDC

Floppy Disk Controller

Контроллер гибкого диска

FDD

Frequency Division Duplex

Дуплексная связь с мультиплексированием по частоте

FDDI

Fiber Data Distribution Interface (100Mb/s)

Волоконный интерфейс для передачи данных с кольцевой структурой

Fiber Digital Device Interface

Цифровой оптоволоконный интерфейс

FDISK

Fixed Disk

Жесткий диск

FDM

Frequency Division Multiplexing

Мультиплексирование с частотным уплотнением

FDMA

Frequency Division Multiple Access

Множественный доступ с частотным уплотнением

FDPP

Fast Digital Parallel Processing

Параллельная быстрая цифровая обработка данных

FDS

Fuzzy Decision System

Фази система принятия решений (нейронные сети)

FDX

Full Duplex

Полный дуплекс (двунаправленный обмен)

FE

Fast Ethernet

Быстрый Ethernet (100Мбит/с)

FEAL

Fast Data Encypherment Algorithm

Быстродействующий алгоритм шифрования данных

FEBE

Far-End Block Error

Блок с ошибками на удаленном конце канала

FEC

Forward Error Correction

 

Forwarding Equivalence Class

Класс эквивалентности переадресации (MPLS)

FECN

Forward Explicit Congestion Notification

Бит идентификации перегрузки

FEFO

First-Ended, First-Out

Первым завершился, первым выведен

FEIP

Fast Ethernet Interface Processor

Просессор интерфейса Fast Ethernet

FEND

Frame End

Конец кадра

FEP

Front End Processor

Препроцессор

FERF

Far End Reporting Failure

Сообщение удаленного терминала об отказе

FESC

Frame Escape

 

FESDK

Far East Software Development Kit [Microsoft]

Дальневосточная система разработки программного обеспечения

FET

Field Effect Transistor

Полевой транзистор

FEXT

Far End CrossTalk

Перекрестные наводки от дальнего конца канала

FF

Flip-Flop

Триггер с двумя устойчивыми состояниями

Form Feed

Перевод страницы

Fixed-Filter

Стиль резервирования "фиксированный фильтр" (RSVP)

FFST

First Failure Support Technology

Технология помощи при первом отказе [IBM]

FFT

Fast Fourier Transform

Быстрое Фурье-преобразование

Final Form Text [IBM]

Текст оконечного формата

FGK

Faller Gallager Knuth

Алгоритм сжатия информации (Фаллера, Галлагера, Кнута)

FIB

Forwarding Information Base (BGP)

Информационная база переадресации

FID

Format Indicator

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

FIF

Fractal Image Format

Формат фрактального изображения

FIFO

First In First Out (memory)

Первым введен - первым выведен (память)

FIGS

Fingerprint Image Groups

Группы отпечатков пальцев

FILO

First-In, Last-Out

Первым введен - последним выведен

FIN

FINish flag (TCP header)

Флаг завершения (заголовок пакета TCP)

FINGER

A way of finding out information about the users at a host

Средство поиска информации о пользователях и ЭВМ (RFC-742)

FIP

File (FDDI) Processor

Файловый (FDDI) процессор

Fluorescent Indicator Panel

Флуорисцентная индикаторная панель

FIPS

Federal Information Processing Standard

Стандарт обработки федеральной информации

Fuzzy Inferences Per Second

 

FIR

Finite Impulse Response

Окончательный отклик на импульс

FIRO

first-in-random-out

Схема буферизации <первым пришел><в произвольном порядке вышел>

FIRST

Forum of Independent Response and Security Teams

Независимый форум по сетевой безопасности

FIX

Federal Information (Internet) eXchange

Федеральный информационный (Интернет) обмен

FL

Fuzzy Logics

Логика нейронных сетей

FLAG

Fiber-Optic Link Around the Globe

Оптоволоконная связь вокруг земного шара

FLC

Ferro-electric Liquid Crystal

Ферроэлектрический жидкий кристалл

Fiber Loop Converter

Преобразователь для абонентной линии

Frame Layer Control

Управление на уровне кадра (X.25)

FLD

Field

Поле

FLL

FoxPro Link Library

Библиотека связей FoxPro [Microsoft Fox Pro]

FLOPS

FLoating Operations per Second

Число плавающих операций в секунду

FLT

Full Line Terminal

Терминальный мультиплексор в SONET

FM

Frequency Modulation

Частотная модуляция

FMS

Forms Management System

Система управлениями формами

FMT

Format

Формат

FNC

Federal Networking Council

Федеральный совет по сетям

FNT

Font

Шрифт

FOCUS

Forum of Control Data Users

Форум пользователей управляющей информацией

FOG

First Osborne Group

 

FOIRL

Fiber Optic Inter Repeater Link

Оптоволоконная связь между повторителями [IEEE]

FOM

Figure Of Merit

Значение выигрыша

FORTH

Foundation Of Research and Technology, Hellas

Фонд исследований и технологии

FORTRAN

Formula Translator

Язык программирования

FOSE

Federal Office Systems Exposition

Федеральная экспозиция офисных систем

FOSSIL

Fido/Opus/Seadog Standard Interface Layer

Стандарт интерфейсного уровня

FOTS

Fiber Optics Transmission Systems

Оптоволоконные системы передачи

FP

Format Prefix

Префикс формата (поле в пакете Интернет)

FPB

Frame Pointer Buffer

Буфер указателя кадра

FPGA

Field Programmable Gate-Array

Программируемая матрица ключей

FPLA

Field Programmable Logic-Array

Программируемая логическая матрица

FPM

Fast Page Mode

Быстродействующий страничный режим (памяти)

FPMH

Failures per Million Hours

Число отказов на миллион часов

FPP

Fixed Path Protocol

Протокол фиксированного пути

Floating Point Processor

Процессор для работы с числами с плавающей запятой

FPS

Favorite Picture Selection

Выбор любимой картинки

Frames Per Second

Число кадров в секунду

Fast Packet Switching

Быстрая коммутация пакетов

FPU

Floating Point Unit

Блок работы с числами с плавающей точкой

FQDN

Fully Qualified Domain Name [Internet]

Комбинация имени ЭВМ и домена, объединенных через точку

FR

Frame Relay

Служба передачи кадров

FRAD

Frame Relay Access Device

Устройство доступа Frame Relay

FRAG

Fragment

Фрагмент

Fragmentation

Фрагментация

FRAM

Ferroelectric Random-Access Memory

Ферроэлектрическая память с произвольным доступом

FRAS

Frame Relay Access Support

Поддержка доступа к Frame Relay

FRASM

Frame Relay Access Service Module

Сервисный модуль доступа к Frame Relay

FR-BAI

Frame Relay B-ISDN Access Interface

Интерфейс доступа службы ретрансляции кадров

FR-BNNI

Frame Relay B-ISDN Network-to-Network Interface

Интерфейс "сеть-сеть" службы ретрансляции кадров

FRED

Frame Editor

Редактор кадров

Front-End to Dish

Оборудование, непосредственно связанное с антенной

FRF

Frame Relay Forum

Форум Frame Relay

FRI

Frame Relay Interface

Интерфейс сети Frame Relay

FRICC

Federal Research Internet Coordinating Committee

Федеральный координирующий комитет по исследованиям в Интернет

FRJ

Facility Reject Message

Отклик на запрос FAR, если он не может быть выполнен (ISDN)

FRM

Fast Resource Management

Быстрое управление ресурсами

FRMR

Frame Reject

Кадр отвергнут

FRPI

Flux Reversals Per Inch

Число смен направления поля на дюйм

FRTC

Frame Relay Traffic Shaping

Система управления трафиком (TE) в сетях Frame Relay

FD-SSCS

Frame Relay Service-Specific Convergence Sublayer

Служебно-ориентированный подуровень конвергенции службы ретрансляции кадров

FS

File Separator

Разделитель файлов

Fixed Stuff

Фиксированный заполнитель (в кадре)

Frame Switch

Коммутатор кадров

FSA

Final State Automate

Автомат конечных состояний

FSD

File System Driver [OS/2]

Драйвер файловой системы

FSE

Full Screen Editor

Полноэкранный редактор

FSF

Free Software Foundation [Internet]

Фонд бесплатного программного обеспечения

FSFIP

Fast Serial Interface Processor

Процессор быстродействующего последовательного интерфейса

FSFM

Full Screen Full Motion

Полноэкранное движущееся изображение

FSK

Frequency Shift Keying

Ступенчатое переключение частоты синусоидального сигнала с f1 на f2 при неизменной амплитуде. Частоте f1 ставится в соответствие логический нуль, а f2 - логическая единица

FSM

Finite State Machine

Машина конечных состояний

FSN

Full Service Network

Сеть с полным списком услуг

FSR

Free System Resources

Свободные системные ресурсы

Financial Status Report

Доклад о финансовом состоянии

FSRN

Forced Simple Recurrent Network

 

FST

Fast Sequenced Transport

Быстродействующая последовательная передача

FTAM

File Transfer, Access and Management (application service) protocol

Протокол управления доступом при файловом обмене

File Transfer and Access Method

Метод доступа и передачи файлов

FTE

Full Time Equivalent

Полный временной эквивалент

FTP

File Transfer Protocol (DARPA)

Протокол пересылки файлов (RFC-959,765)

FTPD

File Transfer Protocol Daemon

Демон протокола пересылки файлов

FTTC

Fiber To The Curb

Модель оптоволоконной сети, где кабель прокладывается от сервис-провайдера до точки неподолеку от клиента

FTTH

Fiber To The Home

Модель оптоволоконной сети, где кабель прокладывается непосредственно до дома клиента

FTS

Federal Telecommunication System

Федеральная телекоммуникационная система

FTSC

Fidonet Technical Standards Committee

Технический комитет стандартов FIDONET

FTTС

Fiber To The Curb

"Волокно до двери"

FTTH

Fiber To The Home

"Волокно в дом"

FU

Function Unit

Функциональный блок

FUI

File Upgrade/Update Information

Информация для актуализации файла

FUNI

Frame User Network Interface

Сетевой интерфейс пользователя кадров

FUNET

Finnish University Network

Университетская сеть Финляндии

FVT

Full Video Translation

Полное видео преобразование

FXO

Foreign Exchange Office

Офис для внешнего обмена (голосовой интерфейс)

FXS

Foreign eXchange Subscriber (Station)

Внешний подписчик обмена (интерфейс подключения обычного телефона)

FYI

For Your Information

Для вашего сведения

FWIW

For What It's Worth (*)

Ради всего святого.

FWTK

Firewall Tool Kit

Средства для работы с системой защиты Firewall


Previous: 10.10.5 [E]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.7 [G]


previous up down next index index
Previous: 10.10.6 [F]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.8 [H]

10.10.7 [G]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

GA

General Availability

Общая доступность

Go Ahead and type, I will wait (*)

Давай, жми на клавиши, я подожду

Generic Algorithm

Базовый алгоритм

GAAP

Generally Accepted Accounting Principles

Общепринятые правила доступа

GAL

Generic Array Logic

Базовая матричная логика

GAL

Global Area Network

Глобальная сеть

GAPI

Gateway Application Programming Interface

Программный интерфейс приложений внешнего порта

GAT

Generic Application Template

Общий шаблон приложения

GB

Gain-bandwidth

Добротность, произведение усиления на ширину полосы пропускания

Gigabyte

Гигабайт - примерно 1 миллиард байт

Garanteed Bandwidth Гарантированная полоса пропускания
GBIC GigaBit Interface Converter Гигабитный интерфейсный преобразователь

GBps

Gigabbytes per second

Гигабайт в секунду

GCAC

Generic Connection Admission Control

Базовое управление разрешением соединения (ATM)

GCC

Generic Conference Control

Общее управление конференцией

GCN

Geometric Constraint Network

Сеть с геометрическими ограничениями

GCPS

Giga Connections Per Second

Число миллиардов соединений в секунду

GCR

Group Code Recording

Запись групповой программы

GCRA

Generic Cell Rate Algorithm

Алгоритм контроля базовой скорости передачи ячеек (ATM)

GCS

Gigacycle per second

Гигагерц в секунду

GDA

Global Data Area

Глобальная информационная область

GDDM

Graphics Data Display Manager

Менеджер дисплея для графических данных

GDI

Graphics Device Interface

Графический интерфейс (Windows)

GDM

Geometrically Deformable Model

Геометрически изменяемая модель

GDP

Gateway Discovery Protocol

Протокол выявления внешнего порта (CISCO)

Graphic Draw Primitive

Графические примитивы для рисования

GDT

Geometric Dimensioning and Tolerancing

Определение геометрических размеров и допусков

Global Descriptor Table

Глобальная таблица описателей

GDS

Guarded Discrete Stochastic network

Защищенная дискретная стохастическая сеть

GEA

GPRS Encryption Algorithm

Алгоритм шифрования GPRS

GECOS

General Electric Comprehensive Operating System

Универсальная операционная система фирмы Дженерал Электрик

GEIS

General Electric Information Service (company)

Информационная система фирмы Дженерал Электрик

GEM

Graphics Environment Manager (DRI Program)

Менеджер графической среды

GENESIS

GEneral NEural SImulation System (SW)

Название программы для работы с нейронными сетями

GENIE

General Electric Network for Information Exchange

Сеть информационного обмена фирмы Дженерал Электрик

GEOS

Graphic Environment Operating System [Geoworks]

Операционная система графической среды

GET

Get Execute Trigger

 

GFC

Generic Flow Control

Общее управление потоком (поле заголовка пакета ATM)

GFI

General Format Identifier

Идентификатор общего формата

GGP

Gateway to Gateway Protocol

Протокол маршрутизации Gateway-Gateway

.GIF

Graphics Interchange Format

Расширение имени графического файла

GIFT

General Internet File Transfer

Обобщенная передача файлов в Интернет

GIGO

Garbage In, Garbage Out

Загрузка/выгрузка "мусора"

GIPS

Giga Instructions Per Second

Число миллиардов инструкций в секунду

GIS

Geographic Information System

Географическая информационная система

GIX

Global Internet Exchange [Internet]

Глобальный обмен в Интернет

GK

Gate Keeper

Привратник (программа управления шлюзом)

GKS

Graphical Kernel System

Система графического ядра

G/L

General Ledger

Общий регистрационный журнал

GLB

Greatest Lower Bound

Наибольший нижний предел (RSVP)

GLBP

Gateway Load Balancing Protocol

Протокол балансировки загрузки сетевого шлюза

GLIS

Global Land Information System [US Geological Survey]

Глобальная информационная система

GLM

General Linear Models

Общие линейные модели

Gigabit Link Modules

Модули гигабитных каналов

GLOBE

Global Learning by Observations to Benefit the Environment [Internet]

Глобальное обучение путем наблюдений на пользу среды

GLX

General License for eXport

Общая лицензия на экспорт

GMDS

Global Managed Data Service

Информационная служба с глобальным управлением

GMPLS

Generalysed MultiProtocol Label Switching

Обобщенный мультипротокольная система коммутации пакетов по меткам

GMT

Greenwich Mean Time

Среднее время по Гринвичу

GMS

Global Messaging Service [Novell]

Глобальная система сообщений

GMT

Greenwich Mean Time

Среднее время по Гринвичу

GND

System Ground

Системная земля

GNE

Gateway Network Element

Шлюзовой элемент сети

GNN

Global Network Navigator

Навигатор глобальной сети [Internet]

GNS

Get Nearest Server

Найти ближайший сервер (запрос IPX)

GNU

GNU's Not UNIX (operating system)

Общедоступная операционная система

GOB

Group of Blocks

Группа блоков при передаче изображения

GOS

Global Operating System

Глобальная операционная система

GOSIP

Governmental OSI Protocols

Управляющие OSI-протоколы

Government Open Systems Interconnection Profile

Конфигурация правительственных открытых коммуникационных системы

GOV

Government

Фрагмент имени домена, указывающий на принадлежность узла правительству (США) [Internet]

GP

Gas Plasma

Газовая плазма

General Purpose

Общее назначение

GPC

General Perpose Computer

Универсальная ЭВМ

GPF

General Protection Fault

Общая система защиты от сбоев

GPI

Graphics Programming Interface

Графический программный интерфейс

GPIB

General Purpose Interface Bus

Интерфейс шины общего назначения

GPL

General Public License

Общая общественной доступности (бесплатное программное обеспечение)

GPMIMD

General Purpose Multiple Instruction Multiple Data

Схема процессора - "много инструкций + много данных"

GPOF

General Purpose Optical Fiber

Оптическое волокно общего назначения

GPRS

General Packet Radio Service

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

GPS

Global Positioning System

Глобальная система позиционирования (определения координаты)

Generalized Processor Sharing

Общая система разделения ресурсов процессора

GPSS

General Purpose Systems Simulator (language)

Название языка программирования

GRASP

Graphic Animation System for Professionals

Графическая система анимации для профессионалов (стандарт)

GRE

Graphics Engine

Графический процессор

General Route Encapsulation

Инкапсуляция базового маршрута

GREP

Global Regular Expression Print

Выдача общих регулярных выражений (из файлов)

GRI

Graphic Device Interface

Интерфейс графического устройства

GRIP

Globally Recilient IP

Глобально адаптируемый IP (CISCO)

GROF

General Purpose Optical Fiber

Оптическое волокно общего назначения

GQ

Generation Qualifier

 

GS

Group Separator

Групповой сепаратор

GSA

General Service Administration

Администрация общих услуг

GSM

Global System for Mobile

Глобальная система мобильной связи (стандарт)

Groupe Special Mobile

Группа мобильной связи

GSMP

General Switch Management Protocol

Общий протокол управления переключателем

GSS

Generic Service State

Состояние базовых услуг

GSTN

General Switched Telephony Network (вместо PSTN)

Общая коммутируемая телефонная сеть

GT

Game Theory

Теория игр

GTS

Generic Traffic Shaping

Общее формирование трафика

GUI

Graphical User Interface

Графический интерфейс пользователя

GUID

Globally Unique Identifier

Глобально уникальный идентификатор

GW

Gateway

Сетевой шлюз

G.703

CCITT standard digital interface 64 kbps-2.048 Mbps

Стандарт CCITT для цифрового интерфейса с быстродействием 64-2048 Кбит/с

G.711

CCITT standard for 64-kbps PCM voice coding technique

Стандарт CCITT для кодово-импульсной модуляции голоса на скорости 64 Кбит/с

G.723.1

CCITT standard compression technique that can be used for compressing speech or audio signal components at a very low bit rate as part of the H.324 family of standards

Стандарт CCITT для сжатия информации при передаче голоса или звука при ниских скоростях, соответствующих семейству стандартов H.324

G.726

CCITT standard for ADPCM coding at 40, 32, 24, and 16 kbps

Стандарт CCITT для кодово-импульсного кодирования при скоростях 40, 32, 24 и 16 Кбит/с

G.728

CCITT standard for 16-kbps low-delay variation of CELP voice compression

Стандарт CCITT для сжатия голоса при скорости 16 Кбит/с

G.729

CCITT standard for compression where voice is coded into 8-kbps streams

Стандарт CCITT для сжатия голоса при кодовых потоках в 8 Кбит/с

G.804

ITU-T framing standard that defines the mapping of ATM cells into the physical medium

Стандарт ITU-T, который устанавливает связь между пакетами ATM и реальной физической средой


Previous: 10.10.6 [F]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.8 [H]


previous up down next index index
Previous: 10.10.7 [G]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.9 [I]

10.10.8 [H]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

H

Hub

Концентратор

H0

 

Канал ISDN на скорость передачи 384 Кбит/с

H4

 

Канал ISDN на скорость передачи 135 Мбит/с (=Е4)

H11

 

Канал ISDN на скорость передачи 1544 Кбит/с (=Т1, США и Япония)

H12

 

Канал ISDN на скорость передачи 1920 Кбит/с (=E1, Европа)

H21

 

Канал ISDN на скорость передачи 34 Мбит/с (=Е3 для Европы)

H22

 

Канал ISDN на скорость передачи 45 Мбит/с (=Т3 для США)

H.221

 

Канальный уровень, который устанавливает привязку кадров видеосигнала для синхронных каналов n*64 Кбит/с

H.225

An ITU standard that governs H.245 endpoint control

Стандарт ITU, который отвечает за оконечное управление в рамках H.245

H.320

ITU-T standard specifications for videoconferencing over circuit-switched media such as ISDN

Стандарты видеоконференций: видео (H.261); звук (G.711, G.722 [ADPCM], G.278) и протокол связи H.221 [ISDN], H.323 [IP]; H.324 [GSTN]

H.323

ITU-T standard H.320 that enables videoconferencing over LANs and other packet-switched networks

Набор стандартов для передачи видео, аудио и обычной цифровой информации по каналам Интернет

HACMP

High Availability Cluster Multi-Processing

Использование высокопроизводительного мультипроцессорного кластера [IBM]

HAL

Hard Array Logic

Аппаратная логическая матрица

HAM

Hierarchal Access Method

Иерархический метод доступа

HAP

Host Access Protocol

Протокол доступа к ЭВМ (RFC1221)

HASP

Houston Automatic Spooling Priority (System)

Приоритетная система буферизации Хьюстона

HBA

Host Bus Adapter

Адаптер шины ЭВМ

HCS

Higher order Connection Supervision

Контроль соединения на уровне виртуальных контейнеров верхнего уровня

HCSS

High Capacity Storage System

Система памяти с высокой емкостью

HCV

High Capacity Voice

Метод кодирования голоса

HD

Hard Disk

Жесткий диск

High Density

Высокая плотность

HDA

Head Disk Assembly

Блок головок диска

HDB2

High-Density Bipolar code of order 2

Двухполярный код высокой плотности порядка 2

HDCD

High Definition Compatible Digital

 

HDF

Hierarchical Data Format [NCSA]

Иерархический формат данных

HDH

HDLC Distinct Host

Отдельная ЭВМ в рамках протокола HDLC

HDI

Head to Disk Interference

Интерфейс головка-диск

HDL

Hardware Description Language

Язык описания оборудования

HDLC

High-Level Data Link Control (Communication)

Протокол высокого уровня для управления информационным каналом (RFC-1662)

HDR

Header

Заголовок

HDSC

High Density Signal Carrier [DEC]

 

HDS

Half-Duplex

Полудуплексный (передача в прямом и обратном направлении по очереди)

HDSL

High-rate Digital Subscriber Link/Loop

Высокоскоростной цифровой канал (1,544 Мбит/с)

HDTV

High Definition TV

Телевидение высокого разрешения

HDW

Hardware

Оборудование

HDWDM

High-Density Wavelength Division Multiplexer

Мультиплексор по длине волны с высокой плотностью каналов

HDX

Half Duplex

Полудуплексный

HEC

Header Error Control (ATM)

Поле управление ошибками

HEHO

Head End Hop Off

 

HEMP

High-level Entity Management Protocol

Протокол высокого уровня для управления объектом

HEMS

High-level Entity Management System

Система управления объектами высокого уровня (RFC-1021)

HEPnet

High Energy Physics network

Сеть для физики высоких энергий

HEX

Hexadecimal

Шестнадцатеричный

HFC

Hybrid Fiber-Coaxial

Гибридный, волоконно-коаксиальный (TV)

HFOX

HIPPI Fiber Optic eXtention

Оптоволоконное расширение HIPPI

HFS

Hierarchical File System [Macintosh]

Иерархическая файловая система

HG

Harvard Graphics

Пакет графических программ

HGA

Hercules Graphics Adapter

Графический адаптер Hercules

HGC

Hercules Graphics Card

Графическая карта Геркулес

HGCP

Hercules Graphics Card Plus

Улучшенная графическая карта типа Геркулес

HH

Hour

Час

HIDAM

Hierarchial Indexed Direct Access Method

Иерархический индексно-прямой метод доступа

HIFD

High-Density Floppy Disk

Гибкий диск высокой плотности

HIL

Human Interface Link [HP]

Канал интерфейса с человеком

HINFO

Host INFOmation FOrmat

Формат информации ЭВМ

HIP

HSSI Interface Processor

Процессор интерфейса HSSI

HIPPI

High Performance Parallel Interface

Параллельный интерфейс с улучшенными характеристикам

HLC

High Layer Compatibility

Совместимость верхнего уровня (ISDN Setup-параметр)

HLCO

High Low Close Open

Высокий-Низкий-Закрыто-Открыто

HLL

High Level Language

Язык высокого уровня

HLLAPI

High Level Language Application Programming Interface

Прикладной интерфейс программирования для языка высокого уровня

HLPI

Higher Layer Protocol Identifier

Идентификатор протокола высшего уровня

HLQ

High Level Qualifier

Высокоуровневый квалификатор

HLR

High Level Qualifier

Высокоуровневый квалификатор

HLS

Home Location Register (GPRS)

Регистр положения базового сайта

HLT

Halt

Стоп

HMA

High Memory Area

Область памяти после 1Мбайт длиной 64к, использует шину A20

Human-Machine Adaptation

Адаптация интерфейса человек-машина

Hub Management Architecture

Архитектура управления концентратором

HMI

Hub Management Interface (Novell)

Интерфейс управления концентратором

Horizontal Motion Index

Индекс горизонтального перемещения (HP LJ)

HMM

Hidden Markov Model

Скрытая модель Маркова

HMOS

High Density Metal Oxide Semiconductor

Метал-оксидный полупроводник высокой плотности

High Speed Metal Oxide Semiconductor

Быстродействующий полупроводник метал-оксид

HMP

Host Monitoring Protocol

Протокол мониторирования ЭВМ (RFC-869)

HNS

Hughes Network System

Система сети Hughes

HOA

Higher Order Assembler

Сборка VC верхнего уровня

HOI

Higher Order Interface

Интерфейс сборки VC верхнего уровня

HOL

Head-of-Line

Начало строки

HOTT

Hot Off The Tree (electronic newsletter)

Название электронного журнала

HP

Hewlett-Packard

Название компании

HPA

Higher order Path Adaptation

Адаптация к маршруту VC верхнего уровня

HPC

HEPNET Policy Committee

Комитет HEPNET по политике

Higher order Path Connection

Соединение нескольких VC верхнего уровня

High Performance Computing

Высокопроизводительные вычисления

HPAL

House Programmed Array Logic

Программируемая логическая матрица

Heuristically Programmed Algorithmic

Эвристически программируемый алгоритмический компьютер (использован в 1968 году для съемки фильма "2001: A Space Odyssey")

HPCC

High Performance Computing and Communications

Высококачественные вычисления и коммуникации

HPCS

High Performance Computing System

Высокопроизводительная вычислительная система

HPDJ

Hewlett-Packard Desk Jet

Струйный принтер фирмы HP

HPFS

High Performance File System

Высокопроизводительная файловая система

HPG

Hewlett-Packard Graphics

Графика Hewlett-Packard

HPGL

Hewlett-Packard Graphics Language

Графический язык Hewlett-Packard

HPIB

Hewlett-Packard Interface Bus

Шина интерфейса Hewlett-Packard

HPLJ

Hewlett-Packard Laser Jet

Лазерный принтер Hewlett-Packard

HPOM

Higher order Path Overhead Monitor

Мониторинг POH VC верхнего уровня

HPPA

Hewlett-Packard Precision Architecture

Прецизионная архитектура Hewlett-Packard

HPPI

High Performance Parallel Interface

Высокопроизводительный параллельный интерфейс

HPR

High Performance Routing

Высокопроизводительная маршрутизация (протоколы второго поколения)

HPSN

High Performance Scalable Networks

Высокопроизводительная масштабируемая сеть (3com)

HPT

Higher order Path overhead Termination

Начало/окончание маршрута VC верхнего уровня

HPUX

Hewlett-Packard Unix

ОС UNIX фирмы Hewlett-Packard

HPW

High Performance Workstation [Sun]

Высокопроизводительная рабочая станция

HRC

HEPNET Review Committee

Комитет по наблюдению за HEPNET

HRIS

Human Resource Information System

Информационная система по людским ресурсам

HRG

High Resolution Graphics

Графика высокого разрешения

HRMS

Human Resource Management System

Система управления людскими ресурсами

HRPT

High Resolution Picture Transmission

Передача изображений высокого разрешения

HRS

High Rate Segment

Высокоскоростной сегмент

HSC

High Speed Channel

Высокоскоростной канал

HSCI

High-Speed Communication Interface

Высокоскоростной коммуникационный интерфейс

HSI

High Speed Interconnect

Высокоскоростное соединение

Hue Saturation Intensity

Цвет-Насыщенность-Интенсивность

HSM

Hierarchical Storage Management

Иерархическое управление памятью

High Speed Memory

Быстродействующая память

HSRP

Hot Standby Router Protocol

Протокол маршрутизатора CISCO

HSP

High Speed Printer

Высокоскоростной принтер

HSSI

High Speed Serial Interface

Последовательный высокоскоростной интерфейс на (34-52)Mбит/c

HST

High Speed Technology

Высокоскоростная технология (метод модуляции) U.S. Robotics

HSV

Hue Saturation Value

Значение насыщенности цвета

HT

Horizontal Tab

Горизонтальный табулятор

HTCC

HEPNET Technical Coordinating Committee

Технический координационный комитет HEPNET

HTML

HyperText Markup Language

Язык разметки для работы с гипертекстом

HT

Horizontal Tabulation

Горизонтальная табуляция

HTTP

HyperText Transfer Protocol

Протокол для пересылки гипертекстов

HUG

Higher order Unequipped Generator

Генератор незагруженного VC верхнего уровня

HUT

Hopkins Ultraviolet Telescope

Ультрафиолетовый телескоп Гопкинса

H/V

Horizontal/Vertical

Горизонтальный/вертикальный

HVP

Horizontal & Vertical Position

Горизонтальная и вертикальная позиция

HW

HardWare

Оборудование

HWCP

Hardware Code Page

Страница аппаратной программы

HWD

Height-Width-Depth

Высота-Ширина-Глубина

HWSC

HandWriting Segmented Characters

Рукописные сегментированные символы

HXDP

Honeywell Experimental Distributed Processing System

Экспериментальная распределенная система обработки фирмы Honeywell


Previous: 10.10.7 [G]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.9 [I]


previous up down next index index
Previous: 10.10.8 [H]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.10 [J]

10.10.9 [I]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

I.120

CCITT description of ISDN

Описание ISDN

IA

 

Посылающая сторона (почта)

IAB

Internet Activities (Architecture) Board

Комитет по архитектуре Интернет (RFC-1177)

IAC

Interpret As Command (TELNET ESC-sequences)

Интерпретировать как команду (код=0xff)

Interactive Activation and Competition

Интерактивная активация и соревнование

Interapplication Communication

Обмен данными между приложениями

IAES

Intelligent Array Expansion System

Интеллигентная система расширения массива (матрицы)

IAHC

Internet International Ad Hoc Committee

Международный специальный комитет по Интернет

IAL

International Algebraic Language

Международный алгебраический язык (первым таким языком был ALGOL)

IAM

Initial Address Message

Сообщение, используемое для инициализации канала, передачи маршрутной информации и параметров запроса

IAONA

Industrial Automation Open Networking Alliance

Промышленный альянс автоматизации открытых сетей

IANA

Internet Assigned Numbers Authority [Internet]

Комиссия по константам Интернет

IAP

Internet Access Provider

Провайдер доступа к Интернет

IAS

Intermediate Address Space

Промежуточное адресное пространство

IAT

Import Address Table

Таблица адресов импорта

IAUP

Internet User Account Provider

Провайдер пользовательских аккоунтов Интернет

IBC

Integrated Broadband Communications

Интегрированные широкополосные коммуникации

Instrument Bus Computer

ЭВМ инструментальной шины

IBM

International Business Machine

Название корпорации.

IBM-GL

IBM Graphics Language

Графический язык IBM

IBWM

Intelligent BandWidth Management

Интеллигентное управление пропускной способностью (полосой)

IC

Input Circuit

Входная схема

Integrated Circuit

Интегральная схема

Interrupt Controller

Контроллер прерываний

ICA

Intra-application Communications Area

Область коммуникаций для приложений

ICAI

Intelligent Computer Assisted Instruction

Интеллектуальная команда, обслуживаемая ЭВМ

ICAS

Intel Communicating Applications Specifications

Спецификации коммуникационных приложений Intel

ICB

Individual Case Basis

На индивидуальной основе

ICCB

Internet Control and Configuration Board

Совет конфигурации и управления Интернет

ICCP

Institute for the Certification of Computer Professionals

Институт сертификации профессионалов ЭВМ

ICD

Institute, Center, Division

Институт, центр, отдел

International Code Designator

Международный указатель кода

ICE

In-Circuit Emulator

Встроенный эмулятор [Intel]

ICF

Information Conversion Function

Функция преобразования информации

ICFA

International Computer Facsimile Association

Международная ассоциация компьютерной факсимильной связи

ICI

Image Component Information

Информация фрагмента изображения

ICL

Interface Clear

Сброс интерфейса

Incoming Line

Входящая линия

ICLID

Incoming-Call Line Identification

Идентификация входной вызывающей линии

ICM

InComing Message

Входящее сообщение

ICMP

Internet Control Message Protocol

Протокол Интернет для пересылки управляющих сообщений (TCP/IP, RFC792)

ICOMP

Intel Compatible Microprocessor Performance

Совместимость с процессором Intel

ICN

Integrated Computer Network

Интегрированная сеть ЭВМ

ICP

Integrated Channel Processor

Интегрированный канальный процессор

ICR

Intelligent Character Recognition

Интеллектуальное распознавание символов

Initial Cell Rate

Исходная скорость передачи ячеек

ICS

Interim Cut-through Switch

Быстродействующий переключатель, отфильтровывающий кадры короче 512 бит

Intuitive Command Structure

Интуитивная структура команд

ICSA

International Computer Security Association

Международная ассоциация по компьютерной безопасности

ID

Identification

Идентификация

Identifier

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

I-D

Internet-Draft

Проект документа Интернет

IDA

Integrated Digital Access

Интегрированный цифровой доступ

Intelligent Disk Array

Интеллектуальный массив дисков

Intelligent Drive Array

Интеллектуальный массив драйвов

IDAPI

Integrated Database Application Programming Interface

Программный интерфейс интегрированных приложений баз данных

IDC

Insulation Displacement Connector

Разъем с контактами, разрезающими изоляцию проводов

IDDE

Integrated Development and Debugging Environment

Интегрированная среда разработки и отладки

IDE

Integrated Drive Electronics

Электроника интегрированного драйва

Integrated Development Environment

Интегрированная среда разработки

Imbedded Drive Electronics

Электроника встроенного драйва

Interactive Design and Engineering

Интерактивное проектирование и инженерные работы

Interface Design Enhancement

Улучшение конструкции интерфейса

IDEA

International Data Encryption Algorithm

Алгоритм шифрования данных

IDF

Intermediate Distribution Frame

Кадр промежуточной рассылки

IDI

Initial Domain Identifier

Исходный идентификатор домена

IDL

Interface Description Language

Язык описания интерфейса

IDMS

Integrated Data Base Management System

Система управления интегрированными базами данных

IDN

International Data Number

Система адресации в X.25 (X.121)

Integrated Digital Network

Интегрированная цифровая сеть

IDNX

Integrated Digital Network eXchange (IBM)

Интегрированный сетевой цифровой обмен

IDP

Integrated Data Processing

Интегрированная обработка данных

Initial Domain Part

Исходная часть домена

IDPR

Interdomain Policy Routing

Междоменная маршрутизация

IDRP

InterDomain Routing Policy/Protocol

Протокол/политика междоменной маршрутизации

IDS

Intrusion Detection System

Система детектирования вторжения (сетевая)

IDSN

Integrated Digital Service Network

Цифровая сеть интегрированного обслуживания

IDT

Interrupt Descriptor Table

Таблица описателей прерываний

IDU

Interface Data Unit

Интерфейсный блок данных

IE

Interrupt Enable

Разрешение прерываний

Internet Explorer

Программа Microsoft (WWW)

Information Element

Информационный элемент

IEC

International Electrotechnical Commission

Международная Электротехническая комиссия (МЭК)

IEEE

Institute of Electrical and Electronic Engineers

Институт инженеров электриков и электронщиков

IEEE 802.1

 

IEEE стандарт на протоколы мостов в Ethernet (расширяющееся дерево)

IEEE 802.2

 

IEEE стандарт для управления логическими связями (LLC)

IEEE 802.3

A bus using Carrier Sense Multiple Access with Collision Detection (CSMA/CD)

IEEE стандарт на способ доступа к Ethernet с детектированием столкновений

IEEE 802.4

A bus using token passing (token bus)

IEEE стандарт на маркерную шину

IEEE 802.5

A ring using token passing (token ring, PRONET)

Сеть типа маркерное кольцо

IEEE 802.6

A metropolitan area network

Широкая региональная сеть

IEEE 802.7

 

Регламентации для широкополосных сетей

IEEE 802.8

 

Стандарты для оптоволоконных сетей, включающих в себя пассивные приборы с подключением по схеме звезда

IEEE 802.9

 

Регламентации для интегрированных сетей для голоса и данных по стандарту ISDN 2B+ супер D

IEEE 802.11

 

Стандарты для беспроводных сетей

IEEE 802.12

IEEE LAN standard that specifies the physical layer and the MAC sublayer of the data link layer

Стандарты физического уровня и MAC-субуровня

IEF

Information Engineering Facility

Информационная инженерная система

IEMSI

Interactive Electronic Mail Standard Identification

Описание стандарта интерактивной электронной почты

IEN

Internet Engineering (Experiment) Note

Инженерные заметки по Интернет

IESG

Internet Engineering task force Steering Group

Координационная группа инженерных разработок в Интернет

IETF

Internet Engineering Task Force

Инженерная служба Интернет

I/F

Interface

Интерфейс

IFD

Image File Directory

Каталог файлов изображения

IFF

Interchangeable File Format

Изменяемый файловый формат [Amiga]

IFG

Incoming Fax Gateway

Входной факс-сервер

IFIP

Internet Federation for Information Processing

Ассоциация для обработки информации в Интернет

IFMP

Ipsilon Flow Management Protocol

Протокол управления потоками данных фирмы Ipsilon

IFRB

International Frequency Restriction Board

Международный совет по выделению частот

IFS

Installable File System

Устанавливаемая файловая система

IFSM

Information Systems Management

Управление информационными системами

IFU

Interworking Functional Unit

Функциональный блок взаимодействия

IGA

Integrated Graphics Array

Интегрированный графический массив

Idealized Generic Algorithm

Идеализированный базовый алгоритм

IGC

Integrated Graphics Controller

Интегрированный графический контроллер

IGBT

Isolated Gate Bipolar Transistor

Биполярный транзистор с изолированным затвором

IGES

Initial Graphics Exchange Specification/Standard

Стандарт/спецификация обмена графическими данными

IGMP

Internet Group Multicast (Management) Protocol

Протокол управления для работы с группами (RFC1112)

IGP

Interior Gateway Protocol

Протокол внутреннего порта (напр. RIP)

IGRP

Interior Gateway Routing Protocol (CISCO)

Внутренний протокол маршрутизации

IGS

Internet Go Server [Internet]

Интернет-сервер GO (компания)

IIF

Immediate IF

Промежуточный интерфейс

IIH

IS-IS Hello

Запрос HELLO в системе IS-IS

IINREN

Interagency Interim National Research and Education Network

Международное агенство национальных сетей для науки и образования

IIO

Intellegent Input/Output

Ввод/вывод со встроенным интеллектом (I2O)

IIOP

Internet Inter-ORB Protocol

Протокол, используемый в рамках CORBA для доступа к объектам через Интернет

IIR

Immediate Impulse Response

Немедленная реакция на импульс

IIS

Internet Information Server

Информационный сервер Интернет

IISP

Interim-Interswitch Signaling Protocol

Промежуточный межкоммутаторный сигнальный протокол

IISSP

Interim Inter-Switch Signaling Protocol

Сигнальный протокол взаимодействия коммутаторов

IITA

Information Infrastructure Technology and Applications

Технология и приложения информационной инфраструктуры

IITF

Information Infrastructure Task Force

Комитет по информационной инфраструктуре

IJCNN

International Joint Conference on Neural Networks

Международная объединенная конференция по нейронным сетям

IKE

Internet Key Exchange

Обмен ключами в Интернет

IKIS

Knowbot Information Service (to find mail address)

Система поиска электронных почтовых адресов

ILMI

Interim Local Management Interface

Промежуточный интерфейс локального управления

IMA

Inverse Multiplexing over ATM

Обратное мультиплексирование через ATM (стандартный протокол)

IMAP

Interactive Mail Access Protocol

Протокол доступа к интерактивной почте (RFC-1064)

IMC

Internet Message Center

Центр сообщений Интернет

IMDS

Image Data Stream

Поток графических данных (формат) [IBM]

IMG

Image

Изображение

IMHO

In My Humble Opinion (*)

По моему скромному мнению

IMIB

Internet Management Information Base

Управляющая информационная база Интернет

IMO

In My Opinion (*)

По моему мнению

IMP

Information/Interface Message Processor

Процессор информационных/интерфейсных сообщений

IMPA

Intelligent Multi-Port Adapter [DCA]

Интеллигентный мультипортовый адаптер

IMR

Internet Monthly Report

Ежемесячный доклад Интернет

IMS

Information Management System

Система управления информацией

Intermediate Maintenance Standards

Промежуточные стандарты поддержки

IMSI

International Mobile Subscriber Identity

Международная идентификация мобильных объектов

IMT

Inter-Machine Trunk

Межмашинная магистраль

IMTC

International Multimedia Teleconferencing Consortium

Международный консорциум по мультимедийным конференциям

IMTV

Interactive Multimedia Television

Интерактивное мультимедийное телевидение

IN

Input

Вход

INA

Information Networking Architecture

Архитектура информационных сетей (ATM и SONET)

INB

Install Busy

Объект создан, но ещё не переведен в активное состояние

INC

Increment

Приращение

INE

Intelligent Network Element

Интеллектуальный сетевой элемент

INF

Information Message

Информационное сообщение, запрошенное INR

.INF

Information

Расширение имени информационного файла

.INI

Initialize

Расширение имени инициализирующего файла

INIT

Initialize

Инициализация

INM

Integrated Network Management

Управление интегрированными сетями

INMARSAT

International Maritime Satellite Organization

Международная организация по спутникам для морских коммуникаций

INFN

National Nuclear Physics Research Institutes of Italy

Национальный институт ядерных исследований Италии

INNS

International Neural Network Society

Международное общество нейронных сетей

INOC

Internet Network Operation Center

Сетевой операционный центр Интернет

INP

Internetwork Nodal Processor

Межсетевой узловой процессор (FDDI)

INR

Information Request Message

Посылается коммутатором для получения информации по текущей сессии

INS

Input String

Входная строка

INT

Integer

Целый

Internal

Внутренний

Interrupt

Прерывание

International (organization Domain name)

Фрагмент имени домена Интернет, принадлежащего международной организации

INTA

Interrupt Acknowledge

Подтверждение прерывания

INTAP

Interoperability Technology Association for information Processing

Ассоциация по технологии взаимодействия в области обработки информации

InterNIC

Internet Network Information Center

Сетевой информационный центр Интернет

INTELSAT

International Telecommunication Satellite Organization

Международная ассоциация по телекоммуникационным спутникам

Internet

Coupled networks using Internet Protocol

Связанные сети, использующие IP-протокол

INTO

Interrupt if Overflow occurs

Прерывание при переполнении

IO

Input/Output

Ввод/вывод

Interpretive operation

Работа в интерпретивном режиме

I/O

Input/Output

Ввод/вывод

IOC

Input/Output Channel

Канал ввода/вывода

Input/Output Controller

Контроллер ввода/вывода

IOCC

Input/Output Channel Controller

Канальный контроллер ввода вывода

IOCS

Input/Output Control System

Система управления вводом/выводом

IOCTL

Input/Output ConTroL

Управление вводом/выводом

IONL

Internal Organization of the Network Layer

Уровень сети в пределах организации

IOP

In/Out Processor

Процессор ввода/вывода

IOPL

Input/Output Privilege Level

Уровень привилегий ввода/вывода

IOS

Internetwork Operating System

Межсетевая операционная система (CISCO)

IOSGA

Input/Output Support Gate Array

Поддержка набора портов ввода/вывода

IOT

Inter-Office Trunk

Межофисная магистраль

IP

Internet Protocol, low level network protocol used in ARPANET and others

Сетевой протокол низкого уровня, использованный в TCP/IP сетях (RFC-791, -950, -919, -922)

Instruction Pointer

Указатель команды

IP-ARC

IP on ArcNet

IP поверх ARCNET (RFC-1051)

IPC

InterProcess Communication

Межпроцессный обмен

Instructions Per Clock

Число команд в единицу времени

IPCP

Internet Protocol Control Protocol

Управляющий протокол для Интернет (RFC-1332)

IPCS

Integrated Product Configurating Service

Интегрированная служба конфигурирования

IPDS

IBM Personal Dictation System

Персональная система диктовки фирмы IBM

Intelligent Printer Data Stream

Поток данных интеллигентного принтера [IBM]

IP-E

IP on Ethernet

IP поверх Ethernet (RFC-895)

IPF

Information Presentation Facility

Устройство сохранения информации

IPG

InterPacket Gap

Межпакетный зазор

IP-HC

IP on HyperChannel

IP поверх HyperChannel (RFC-1051)

IPI

Intelligent Peripheral Interface

Интеллектуальный интерфейс внешнего устройства

IP-IEEE

Internet Protocol on IEEE

IP поверх IEEE (RFC-1042)

IP-IPX

Transmission of 802.2 over IPX Net

Передача 802.2 поверх IPX-сети (RFC-1132)

IPL

Initial Program Load/Loader

Стартовая программа загрузки

Ion Projection Lithography

Ионная проекционная литография

Information Programming Language

Информационный язык программирования

IPM

Independent Peripheral Manufacturer

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

Interpersonal Message

Сообщение человек-человек

IPMA

Internet Performance Measurement and Analyses

Организация, производящая исследования характеристик сетей Интернет

IPMS

InterPersonal Messaging System

Межперсональная система обмена сообщениями

IPRMM

Intelligent Pattern Recognition Memory Module

Блок памяти интеллектуального распознавания образов

IPS

Federal Information Processing Standard

Федеральный стандарт по обработке информации

IPSE

Integrated Project Support Environment

Интегрированная среда поддержки проектов

IPSEC

IP Security

IP безопасность

IP-SLIP

IP over serial line

IP по последовательному каналу (RFC-1055)

IPSO

IP Security Option

Рекомендации безопасности в Internet

IPX

Internetwork Packet Exchange

Пакетный обмен в Internet [Novell]

IPv6

IP version 6

Стек протоколов IP со 128-битными адресами

IPXCP

IPX Control Protocol

Управляющий протокол для IPX

IPXWAN

IPX Wide-Area Network

IPX для региональных сетей

IQL

Interactive Query Language

Язык интерактивных запросов

IR

Infrared

Инфракрасный

Information Retrieval

Извлечение информации

Internal Resistance

Внутреннее сопротивление

IRB

Integrated Routing and Bridging

Интегрированное переключение и маршрутизация

IRC

International Record Carrier

Международный носитель записей

Internet Relay Chat

Переговоры клиентов Internet в реальном времени

IRD

Integrated Receiver/Descrambler

Интегрированный приемник/дескрэмблер

IRDP

ICMP Router Discovery Protocol

Протокол поиска маршрутизатора с помощью ICMP

IRDS

Information Resource Dictionary System

Система каталогов информационных ресурсов

IRET

Interrupt Return

Возврат после прерывания

IREX

International Research and EXchange board

Международный совет по исследованиям и обмену

IRL

Interactive Reader Language

Интерактивный язык читающего устройства

Inter-Repeater Link

Связь между повторителями

IRLED

Infrared Light Emitting Diode

Инфракрасный диод-излучатель

IRM

Information Resource Management

Управление информационными ресурсами

Inherent Rights Mask

Маска базовых привилегий

IRN

Intermediate Routing Node

Промежуточный узел маршрута

IRQ

Interrupt ReQest

Запрос прерывания

IRR

Internet Routing Registry

Регистр маршрутов Интернет

IRS

Information Retrieval System

Система поиска информации

IRSG

Internet Research Steering Group

Координирующая группа по исследованиям для Интернет

IRTF

Internet Research Task Force

Группа исследования сетей Интернет

IRTP

Internet Reliable Transaction Protocol

Протокол Интернет, обеспечивающий повышенную надежность выполнения операций (RFC-938)

IRV

International Reference Version

Международная эталонная версия

IRX

Information Retrieval Experiment

Эксперимент по получению информации

IS

Information System

Информационная система

Intermediate System

Промежуточная система

In-Service

Внутренняя услуга

Interrupt Status

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

ISA

Industry Standard Architecture

Промышленный стандарт архитектуры (шина PC/AT)

Internet Server Application

Прикладная программа Интернет-сервера

ISAC

ISDN Subscriber Access Controller

Контроллер доступа подписчиков ISDN

ISAM

Indexed Sequential-Access Management/Method

Индексный(ое) метод/управление последовательным доступом

ISAPI

Internet Server Application Programming Interface

Прикладной программный интерфейс для сервера Интернет

ISBN

Integrated Satellite Business Network

Интегрированная коммерческая спутниковая сеть (Hughes)

International Standard Book Number

Международный стандарт на кодировку книг

ISC

Instruction Set Computer

Процессор набора команд

ISCI

Integrated SNMP and CMIP Implementation

Совместная реализация протоколов SNMP и CMIP

ISD

Image Section Descriptor

Описатель раздела изображений

Instructional Systems Design

Конструирование командных систем

ISDN

Integrated Services Digital Network

Интегрированная цифровая сеть

ISE

Integrated Switching Element

Интегрированный переключающий элемент

ISF

International Scientific Foundation

Международный научный фонд (фонд Дж. Сороса)

ISH

Information Super Highway

Информационная супермагистраль

ISI

Internally Specified Index

Внутренне заданный индекс

InterSymbol Interference

Межсимвольная интерференция

ISIS

Integrated Systems and Information Services

Интегрированные системы и информационные услуги

IS-IS

Intermediate System to Intermediate System

Протокол маршрутизации "Промежуточная система - промежуточная система" (OSI)

ISL

Interactive System Language

Интерактивный системный язык

Intermediate Sequential Language

Промежуточный последовательный язык

InterSwitch Link

Межкоммутаторный канал

ISM

In-Service Monitoring

Мониторинг в процессе обслуживания

Industrial, Scientific, Medical

Промышленность, наука, медицина(приложения)

ISMF

Interactive Storage Management Facility

Устройство управления интерактивной памятью

ISN

Initial Sequence Number

Начальный порядковый номер (TCP-соединитель)

Integrated Services Network

Сеть с интегрированными услугами

Internet Shopping Network

Сеть для покупок через Интернет

Impedance Stabilization Network

Сетевая стабилизация импеданса

ISO/OSI

International Standards Organization/Open Systems Interconnection

Международная организация стандартизации/ Объединение открытых систем (модель)

ISO

International Standard Organization

Международная организация по стандартам

ISO 3309

HDLC procedures developed by ISO

Стандарт на формат кадров HDLC для синхронных каналов

ISO 9000

Set of international quality-management standards defined by ISO

Набор международных стандартов ISO для управления качеством

ISOC

Internet Society

Общество Интернет

ISODE

ISO Development Environment

Среда разработки программ ISO

ISP

Internet Service Provider

Сервис-провайдер Интернет

Interrupt Stack Pointer

Указатель стека прерываний

Interrupt Status Port

Порт состояния прерывания

ISPF

Interactive System Programming Facility

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

ISR

Information Storage and Retrieval

Запись и извлечение информации

Interrupt Service Routine

Программа обработки прерывания

Intermediate Session Routing

Маршрутизация в пределах сессии (hop-by-hop; в последнее время вытеснена HPR)

ISS

Initial Send Sequence

Стартовая сигнатура

Internet Security Scanner

Средство безопасности для Интернет

ISSI

Inter-System Switching Interface

Интерфейс межсистемных переключений

ISSN

International Standard Serial Number

Серийные номера международных стандартов

IST

Information Society Technologies

Технологии информационного общества

ISUP

Integrated Services User Part

Пользовательская часть интегрированных услуг (ISDN)

ISV

Independent Software Vendor

Независимый поставщик программного обеспечения

IT

Information Type

Тип информации

Information Theory

Тeория информации

ITAR

International Traffic in Arms Regulations

Международный контроль за распространением оружия (США)

ITB

Information Technology Branch

Область информационных технологий

Intermediate Text Block

Промежуточный текстовый блок

ITC

International Typeface Corporation

Название корпорации

ITE

Information Technology Equipment

Оборудование для информационных технологий

ITN

Identification Tasking and Networking

Задачи идентификации и построения сетей

ITS

Intelligent Tutorial System

Интеллигентная обучающая система

ITU

International Telecommunication Union

Международный телекоммуникационный союз (ITU TS = CCITT)

ITUG

International Telecommunications User Group

Международная группа пользователей телекоммуникаций

ITV

Interactive Television

Интерактивное телевидение

ITX

Intermediate Text Block

Промежуточный текстовый блок

IU

Interface Unit

Блок интерфейса

Integer Unit

Целочисленный блок

IUAP

Internet User Account Provider

Провайдер пользовательских аккоунтов Интернет

IVD

Integrated Voice/Data

Интегрирование голоса и данных

IVIS

Interactive Video Information System

Интерактивная система видеоинформации

IVL

Intel Verification Lab

Верификационная лаборатория фирмы Интел

IVR

Interactive Voice Response

Голосовой интерактивный отклик

IVS

Interactive Videodisk System

Интерактивная система видеодисков

IVT

Interrupt Vector Table

Таблица векторов прерывания

IV&V

Independent Verification & Validation

Независимая верификация и сертификация

IXC

Inter-eXChange mileage

Расстояние в милях при внешнем обмене

IntereXchange Carrier

Носитель для внешнего обмена

IXI

International X.25 Infrastructure

Международная структура X.25

I-WAY

Information Highway

Информационная магистраль

IWU

Internet Working Unit

Рабочий блок Интернет


Previous: 10.10.8 [H]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.10 [J]


previous up down next index index
Previous: 10.10.9 [I]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.11 [K]

10.10.10 [J]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

JAD

Joint Application Design

Проектирование объединенного приложения

JAIR

Journal of Artificial Intelligence Research

Журнал исследований по искусственному интеллекту

JAM

Just A Minute (*)

Подождите минутку

JANET

Joint Academic and research Network in the UK

Объединенная академическая исследовательская сеть Великобритании

JCB

Justification Control Bit

Бит управления выравниванием (субкадра)

JCL

Job Control Language

Язык управления заданиями

JDBC

Java Database Connectivity

Доступность базы данных JAVA

JDN

Julian Days Numbering

Юлианская система нумерации дней в календаре

JEDEC

Joint Electronic Devices Engineering Council

Объединенный Инженерный совет по электронным приборам

JEIDA

Japan Electronic Industry Developments Association

Ассоциация разработок для электронной промышленности Японии

JES

Job Entry System

Система ввода заданий

JFET

Junction Field Effect Transistor

Полевой транзистор

JFIF

JPEG File Interchange Format

Формат обмена файлами JPEG

JIT

Just-In-Time

Точно во время

JNT

Joint Network Team

Группа объединенных сетей (группа JANET)

JOB

Justification Opportunity Bit

Бит возможного выравнивания (субкадра)

JPEG

Joint Photographic Expert Group

Объединенная группа экспертов по графике (стандарт представления графических объектов)

JTM

Job Transfer Manipulation

Манипуляции по передаче заданий

JUGHEAD

Jonzy's Universal Gopher Hierarchy

Иерархия серверов Gopher университета Jonzy

Excavation and Display

Обнаружение и отображение [Internet]

JUNET

Japan Unix Network

Японская юниксовская сеть

Previous: 10.10.9 [I]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.11 [K]


previous up down next index index
Previous: 10.10.10 [J]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.12 [L]

10.10.11 [K]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

K12net

Decentralized network of bulletin board systems

Децентрализованная сеть систем электронных досок объявлений

KDC

Key Distribution Center

Центр распределения ключей

KDT

Key Definition Table

Таблица определения ключей

KIS

Knowbot Information Service

Информационная служба (Интернет)

KISS

Keep It Simple, Stupid

Сохраняй это предельно простым

KMS

Knowledge Management System

Система управления знаниями

KMV

Keyboard-Video-Mouse

Переключатель для дистанционного управления клавиатурой видео-терминалом и мышью удаленных ЭВМ

KPI

Kernel Programming Interface

Центральный программный интерфейс

KSPH

Keystrokes Per Hour

Число нажатий клавиш в час

KSR

Keyboard Send Receive

Клавиатурный обмен

KRS

Knowledge Retrieval System

Система извлечения знаний


Previous: 10.10.10 [J]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.12 [L]


previous up down next index index
Previous: 10.10.11 [K]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.13 [M]

10.10.12 [L]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

LAA

LAN Administration Architecture

Административная архитектура локальных сетей (Saber)

LADDA

Layered Device Driver Architecture

Архитектура драйверов уровневых устройств

LADDR

Layered Device Driver Architecture

Архитектура драйверов оборудования для определенного слоя [Microsoft]

LALL

Longest Allowed Lobe Length

Максимально допустимая длина

LAM

Linear Associative Memory

Линейная ассоциативная память (USL)

LAN

Local Area Network

Локальная сеть

LANACS

Local Area Network Asynchronous Connection Server

Асинхронный связной сервер локальной сети

LANE

LAN Emulation

Моделирование сети

LAP

Link Access Procedure

Процедура доступа к каналу

LAPB

Link Access Procedure Balanced

Сбалансированная процедура доступа к каналу

LAPD

Link Access Protocol D

Протокол доступа к каналу (ISDN)

LAPF

Link Access Procedures for Frame Mode Bearer Services

Протокол доступа к каналу при работе в пакетном режиме (Q.922)

LAP-M

Link Access Protocol for Modems

Протокол доступа к каналу для модемов (V-42)

LASTport

Local Area Storage Transport

Протокол локального переноса содержимого памяти [DEC]

LAT

Local Area Transport

Локальный транспорт

LATA

Local Access and Transport Area

Локальный доступ и транспортная область

LAVC

Local Area VAX Cluster

Локальный VAX-кластер

LAWN

Local Area Wireless Network

Беспроводная локальная сеть

LBA

Lightwave Booster Amplifier

Оптический усилитель

LBT

Listen Before Talk

Слушать до того как говорить

LBX

Low Bandwidth X

 

LCC

Leadless Chip Carrier

Безсвинцовый носитель кристаллов

LCD

Liquid Crystal Display

Жидкокристаллический дисплей

LCI

Logical Channel Indicator

Индикатор логического канала

LCK

Library Construction Kit

Средство формирования библиотек [Microsoft FoxPro]

LCN

Logical Channel Number

Номер логического канала

Local Communications Network

Локальная коммуникационная сеть

LCP

Link Control Protocol

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

LCR

Least Cost Routing

Маршрутизация с учетом минимума цены

LCS

Lower order Connection Supervision

Контроль соединений VC нижнего уровня

LCU

Last Cluster Used

Последний использованный кластер

LCV

Line Code Vialation

Наличие BPV или EXZ ошибок

LDA

Linear Discriminant Analysis

Линейный дискриминантный анализ (USL)

Logical Device Address

Адрес логического устройства

LDAP

Lightweight Directory Access Protocol

Протокол доступа к каталогу

LDC

Linguistic Data Consortium

Консорциум лингвистических данных

Lotus Development Corporation

Название корпорации

LD-CELP

Low-Delay Code-Excited Linear Prediction

Метод кодирования аналогового сигнала

LDP

Loader Debugger Protocol

Протокол загрузчика отладчика (RFC-909)

Language Data Processing

Обработка лингвистической информации

Label Distribution Protocol

Протокол рассылки меток (MPLS)

LDM

Long Distance Modem

Модем для работы на длинные линии

LDT

Local Descriptor Table

Таблица локальных дескрипторов

LEA

Load Effective Address

Эффективный адрес загрузки

LEAF

Law Enforcement Access Field

 

LEC

LAN Emulation Client

Клиент эмуляции локальной сети

LECS

LAN Emulation Configuration Server

Конфигурирующий сервер эмуляции LAN

LED

Light Emitting Diode

Светоизлучающий диод

LEL

Link, Embed and Launch-to-edit

Связать, загрузить и запустить редактор [Lotus]

LEO

Low Earth Orbit

Низкая спутниковая орбита

LEM

Language Extension Module

Модуль языкового расширения

LEN

Low Entry Networking

 

LER

Label Edge Router

Пограничный маршрутизатор зоны MPLS

LES

LAN Emulation Server

Сервер эмуляции LAN (ATM)

LF

Line Feed

Перевод строки

LFA

Loss of Frame

Потеря кадра

LFI

Last File Indicator

Индикатор последнего файла

LFN

Long, Fat pipe Network (pronounced as "elephant")

Протяженная сеть с высокой пропускной способностью (сеть с большим произведением полосы на RTT)

LFU

Least Frequently Used

Наиболее редко используемый

LGDT

Load Global Descriptor Table

Загрузка таблицы глобальных описателей

LGN

Logical Groupe Node

Узел логической группы

LI

Length Indicator

Индикатор длины

.LIB

Library

Расширение имени библиотечного файла

LIB

Label Information Base

База данных меток маршрутизатора, осуществляющую коммутацию пакетов по меткам (MPLS)

LICS

Lotus International Character Set

Интернациональный набор символов [LDC]

LIDT

Load Interrupt Descriptor Table

Загрузить таблицу описателей прерываний

LIEP

Large Internet Exchange Packet

Большой пакет обмена для Интернет [Novell]

LIF

Low Insertion Force

Малое усилие вставления

LIFA

Loop Initialization Fabric Assigned

Процедура присвоения адресов при инициализации структуры (Fibre Channel)

LIFO

Last In First OUT

Последний вошедший выходит первым (память)

LIH

Logical Interface Handle

Дескриптор логического интерфейса

LILO

Last In, Last Out

Последний пришедший выходит последним

LIM

Lotus/Intel/Microsoft

 

LIMA

Lotus/Intel/Microsoft/AST

 

LIMEMS

Lotus/Intel/Microsoft EMS

 

LIMS

Library Information Management System

Библиотечная система управления информацией

LION

Local Integrated Optical Network

Локально интегрированная оптическая сеть

LIP

Large Internet Packet Protocol (Novell)

Протокол передачи больших информационных пакетов

Loop Initialization Procedure

Процедура инициализации кольца (Fibre Channel)

LIPS

Logical Inferences Per Second

Число логических операций в секунду

LIS

Logical IP Subnet

Логическая IP-субсеть

LISM

Loop Initialization Select Master

Сигнал выбора сервера инициализации кольца (Fibre Channel)

LISP

List Processing

Язык для работы со списками

LLAP

LocalTalk Link Access Protocol

Протокол доступа к каналу ArcNet для AppleTalk

LLC

Low Layer Compatibility

Совместимость на нижнем уровне (ISDN Setup-параметр)

Logical Link Control

Логическое управление каналом (FDDI; 802.2)

LLDT

Load Local Descriptor Table

Загрузка таблицы локальных дискрипторов

LLF

Low Level Format

Формат низкого уровня

LLNL

Lawrence Livermore National Laboratory

Ливерморская национальная лаборатория имени Лоуренса

LLRC

Length/Longitudinal Redundancy Checkword

Продольная контрольная сумма

LMBCS

Lotus Multibyte Character Set

Мультибайтовый набор символов [Lotus]

LME

Layer Management Entity

Объект уровня управления

LMI

Local Management Interface

Интерфейс локального управления

Layer Management Interface

Интерфейс управления уровнем

LMSW

Load Machine Status Word

Загрузить слово состояния

LM/X

LAN Manager for Unix

Менеджер управления локальной сетью для UNIX

LNC

Local Node Clock

Таймер локального узла

LNDI

Lotus Notes: Document Imaging

Заметки Lotus: отображение документов

LNM

LAN Network Manager

Менеджер локальной сети (IBM)

LNNI

LAN Emulation Network-to-Network Interface

Межсетевой интерфейс эмуляции LAN

LOC

Loop On-Line Control

Контроль в реальном масштабе времени

Line of Communication

Линия связи

LOCIS

Library of Congress Information System

Информационная система библиотеки конгресса

LODSB

Load String Byte

Байт загрузки строки

LOF

Loss of Frame

Потеря кадра

LOI

Lower Order Interface

Интерфейс сборки VC нижнего уровня

LOM

Loss Of Multiframe

Потеря мультифрейма

LOP

Loss Of Pointer

Потеря указателя (в VC SDH)

LORE

Line Oriented Editor

Строчный редактор

LOS

Loss Of Signal

Потеря сигнала

LPA

Lower order Path Adaptation

Адаптация к маршруту VC нижнего уровня

LPC

Local Procedure Call

Локальный вызов процедуры

Lower order Path Connection

Соединение нескольких VC нижнего уровня

LPD

Line Printer Daemon protocol

Протокол демона для принтера (UNIX-TCP/IP; RFC 1179)

LPDA

Line Problem Determination Application

Приложение, выявляющее проблемы на линии

LPF

League for Programming Freedom

Название организации, выступающей против патентов на программное обеспечение

LPI

Lines Per Inch

Линий на дюйм

LPM

Lines Per Minute

Строк в минуту

LPN

Logical Page Number

Логический номер страницы

LPOM

Lower order Path Overhead Monitor

Мониторинг POH VC нижнего уровня

LPP

Lightweight Presentation Protocol

Простой протокол презентаций

LPR

Local Primary Reference

Локальный первичный эталон

LPS

Low-Power Schottky

Шоттки прибор с малым потреблением

LPT

Line Printer

Печатающее устройство

Lower order Path Termination

Начало/конец маршрута VC нижнего уровня

LQ

Letter Quality

Полиграфическое качество

LQM

Link Quality Monitoring

Мониторирование качества канала (протокол)

LR

Line Regenerator

Линейный регенератор

LRAAM

Labeling RAAM

 

LRC

Longitudinal Redundancy Check

Проверка продольной контрольной суммы

Local Register Cache

Регистровый локальный буфер

Local Routing Center

Локальный центр маршрутизации

LRE

Linguistic Research and Engineering

Лингвистические исследования и инженерия

LRL

Least Recently Loaded

Загруженный последним

LRM

Language Reference Manual

Руководство для словаря

LRU

Least Recently Used (memory)

Использовался последним (блок памяти)

LS

Least Significant

Самый младший

LSA

Line Sharing Adapter

Адаптер для совместного использования линии

Link State Adverticement

Оповещение о состоянии канала

Link Subnetwork Access

Доступ к каналу субсети

LSAP

Link Service Access Point

Точка доступа к каналу (IEEE 802)

LSAPI

License Services Application Program Interface

Программный интерфейс для лицензионных приложений

LSB

Least Significant Bit (Byte)

Младший бит (байт)

LSC

Least Significant Character

Младший символ

LSL

Link Support Layer

Уровень поддержки канала

Link Service Layer

Уровень обслуживания канала

Load Segment Limit

Граница загрузки сегмента

LSP

Link State Packet

Пакет состояния канала

Label Switching Pass

Путь при коммутации по метке (MPLS-VPN)

LSR

Label Switching Router

Маршрутизатор, коммутирующий пакеты по меткам (MPLS)

LSRR

Loose Source and Record Route

 

LTE

Line Terminal Equipment

Линейное терминальное оборудование

LTI

Loss of Timing Inputs

Потеря синхронизации на входе

LTR

Left-To-Right

Слева направо

Letter

Буква

Load Task Register

Регистр загрузки задания

LU

Logical Unit

Логический блок

LUA

Logical Unit Application (interface)

Применение логического блока

LUB

Least Upper Bound

Наименьший верхний предел (RSVP)

LUG

Lower order Unequipped Generator

Формирование незагруженного VC нижнего уровня (SDH)

LUI

Local User Input

Локальный пользовательский ввод

LUN

Logical Unit

Логический блок

LUNI

LAN-User Network Interface

Интерфейс "Пользователь-локальная сеть"

LUT

Lookup Table

Таблица просмотра

LVQ

Learning Vector Quantization

Дискретизация вектора обучения (нейронные сети)

LVQTC

Learning Vector Quantization with Training Count

Дискретизация вектора обучения со счетом предъявляемых объектов (нейронные сети)

LWC

Leave Word Calling

 

LWS

Lint White Space

Строчный пробел (SP, TAB, CR)

LXC

Local Cross-Connect

Локальный кросс-коммутатор

LZW

Lempel-Ziv-Walsh

Название алгоритма сжатия информации

Previous: 10.10.11 [K]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.13 [M]


previous up down next index index
Previous: 10.10.12 [L]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.14 [N]

10.10.13 [M]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

MAC

Medium Access Control

Управление доступом к среде (Ethernet, FDDI, Token Ring)

MACA

Multiple Access with Collision Avoidance

Множественный доступ с исключением столкновений (IEEE 802.11)

Message Authentication Code/Check

Код идентификации сообщения

Mashine-Aided Cognition

Машинное обучение

MADCAP

Multicast Address Dynamic Client Allocation Protocol

Протокол динамического выделения мультикастного адреса клиента (RFC-2730)

MAE

Metropolitan Access Exchange

Точка доступа к региональному информационному обмену

MAF

Management Application Function

Функция управляющего приложения

MAN

Metropolitan Area Network

Региональная или муниципальная сеть

MANOP

Manual Operation

Ручная операция, ручная работа

MANS

Metropolitan Area Networks

Широкие региональные сети

MAP

Manufacturing Automation Protocol

Протокол автоматизации производства

Multicast Adaptation Protocol

Мультикастный адаптационный протокол

Maintenance Analysis Procedures

Процедуры анализа работы

Memory Allocation Map

Карта распределения памяти

Mobile Application Part

Секция мобильного приложения

MAPI

Messaging Applications Program Interface

Программный интерфейс для приложений, работающих с сообщениями

MAPICS

Manufacturing, Accounting and Production Information Control System

Система управления информацией по производству и отчетности [IBM]

MARS

Message Archiving and Retrieval Service

Служба архивации и извлечения сообщений (RFC744)

Multicast Address Resolution Server

Сервер для преобразования мультикастинг адресов

MARVEL

Machine-Assisted Realization of the Virtual Electronic Library

Реализация виртуальной электронной библиотеки на базе вычислительной системы (библиотека конгресса США)

MASM

Macro Assembler

Макро Ассемблер [Microsoft]

MASS

Maximum Availability and Support Subsystem

Субсистема максимальной доступности и поддержки [Parallan]

MAU

Multistation Access Unit

Блок доступа к большому числу станций

Medium Attachment Unit

Блок подключения к среде

MAX

Multiple Array matriX

Матрица с большим числом массивов

Matrix Animation Xpress

 

MB

MegaByte

Мегабайт

MBA

Macroblock Address

Адрес макроблока (передача изображения)

MBB

Moscow BackBone

Московская опорная сеть

MBONE

Multicast BackbONE (Internet)

Канал группового доступа

MBP

Matrix Back Prop

Матричное обратное распространение

Mbps

MegaBit Per Second

Мегабит в секунду

MBR

Master Boot Record

Базовая запись загрузки (системы)

MBS

Maximum Burst Size

Максимальный размер пачки

MC

Multipoint Controller

Многоточечный контроллер (MCU)

MCA

Micro Channel Architecture

Архитектура микро канала [IBM]

MCAV

Modified Constant Angular Velocity

Модифицированная постоянная угловая скорость (WORM)

MCB

Memory Control Block

Блок управления памятью

Message Control Block

Блок управления сообщением

MCDV

Maximum Cell Delay Variation

Максимальная вариация задержки ячейки

MCF

Meta Content File

Файл метаинформации (NetScape)

MCI

Multiport Communication Interface

Многопортовый коммуникационный интерфейс

Media Control Interface

Интерфейс управления средой [Microsoft]

MCU Connection Interface

Интерфейс связи с MCU

MCLR

Maximum Cell Loss Ratio

Максимальное значение отношения потерянных ячеек к их полному числу

MCM

Multi-Chip Module

Многочиповый модуль

MCNS

Multimedia Cable Network System

Система мультимедийных кабельных сетей (название консорциума)

MCR

Modem Control Register

Регистр управления модемом

Minimum Cell Rate

Минимальная частота следования ячеек

MCS

Multipoint Communication Service

Многоточечные коммуникационные услуги (T.122, T.125)

Master Control Station

Управляющая наземная спутниковая станция

MCTD

Maximum Cell Transfer Delay

Максимальная задержка передачи ячейки

MCU

Multi-Chip Unit

Многочиповый блок [DEC]

Multipoint Conference Unit

Объединение нескольких видео и аудио каналов в один

Multipoint Control Unit

Многоточечный блок управления (видеоконференции)

MD

Make Directory

Создать каталог (команда)

Mediation Device

Устройство сопряжения

Message Digest

Дайджест сообщения (служит для проверки целостности)

MDA

Monochrome Display Adapter

Адаптер монохромного дисплея

MDC

Mini Disk Cashing

Буферизация для мини диска

MDF

Main Distribution Frame

 

MDI

Multiple Document Interface

Многодокументный интерфейс

Medium Dependent Interface

Интерфейс, зависящий от среды

Micro Design International (WORM company)

Название компании

MDIC

Manchester Decoder and Interface Chip

ИС интерфейса и декодера манчестерского кода [AT&T]

MDK

Multimedia Developers Kit [Microsoft]

Система разработки мультимедийных приложений

MDL

Minimum Description Length principle

Принцип минимальной длины описания

Message Definition Language

Язык описания сообщений

MDN

Message Disposition Notification

Оповещение об открытии сообщения (RFC-2298)

MDNS

Managed Data Network Services

Сетевые услуги информационного управления

MDR

Minimum Design Requirement

Минимальные конструктивные требования

MDRAM

Multibank DRAM

Многобанковая память

MDY

Month Day Year

Месяц/день/год

MEB

Memory Expansion Board

Карта расширения памяти

MERS

Most Economic Route Selection

Наиболее экономный выбор маршрута

MESI

Modified Exclusive Shared and Invalid (protocol)

 

METAL

Machine Translation and Analysis of Natural Language

Машинный перевод и анализ естественного языка

MF

Mediation Function

Функция устройства сопряжения

MFAS

Multiframe Alignment Signal

Сигнал синхронизации мультикадра

MFB

MultiFunction Board

Мультифункциональная карта

MFC

Microsoft Foundataion Class

Класс фонда Microsoft

Membership Function Circuit

Схема функции участия

MFENET

Magnetic Fusion Energy Network

 

MFFS

Microsoft Flash File System

Система флэш файлов Microsoft

MFLOPS

Millions Floating Operations Per Second

Миллионы операций с плавающей запятой в секунду

MFJ

Modified Final Judgement

Модифицированное окончательное мнение

MFLOPS

Million FLoating point Operations per Second

Миллион операций с плавающей запятой в секунду

MFM

Modified Frequency Modulation

Модифицированная частотная модуляция

MFP

Multifunction Peripheral

Многофункциональное периферийное устройство

MFR

Multi-Port Fiberoptic Repeater

Многопортовый оптоволоконный адаптер

MFS

Macintosh File System

Файловая система Macintosh

Magnetic tape Field Search

Поиск поля магнитной ленты

MuliFrame Synchronization

Синхронизация мультикадра (SDH)

Modified Filing System [Revelation Technologies]

Модифицированная файловая система

MFT

Multiprogramming with a Fixed number of Tasks

Мультипрограммирование с фиксированным числом задач

MultiFlex Trunk module

Модуль многошлейфового канала

MG

Master Group

Мастер-группа

MGA

Monochrome Graphics Adapter

Монохромный графический адаптер

Multicolor Graphics Array

Многоцветный графический массив

MGCP

Media Gateway Control Protocol

Протокол управления шлюзом сетевой среды (RFC-2705)

MGE

Modular GIS Environment

Модульная среда GIS

MGR

Manager

Менеджер

MGS

Mid-size Gateway Server

Сервер внешнего порта среднего размера

Media-Gateway-Controller

Контроллер медийного порта

MHI

Model Human Interface

Модель интерфейса с человеком

MHS

Message Handling Service

Служба обработки сообщений

Message Handling System (System)

Система обработки сообщений

MI

MicroInstruction

Микрокоманда

MIB

Management Information Base

База данных, используемых для управления сетью через протоколы SNMP и CMIP

MIC

Message Integrity Check

Проверка целостности сообщения

Media Interface Connector

Разъем сетевого интерфейса

MICA

Modem ISDN Channel Aggregation

Модем для связи I/O-кнала с ISDN

MICS

Macro Interpretive Commands

Интерпретивные макро-команды

MID

Multiplexing Identifier

Идентификатор мультиплексирования

Message IDentifier

Идентификатор cообщения

MIDAS

Multilayer Distributed Application Services

Службы многоуровневых распределенных приложений

MIDI

Musical Instrument Digital Interface

Цифровой интерфейс музыкального инструмента

MIF

Management Information Format

Формат управляющей информации

MII

Microsoft/IBM/Intel

 

Media Independent Interface

Интерфейс, независящий от физической среды

MIL

Machine Interface Layer [Go Corporation]

Уровень машинного интерфейса

Military (organization Domain name)

Фрагмент имени домена, указывающий на военное назначение сети [Internet]

MILNET

Military Network

Оборонная сеть

MIMD

Multi Instruction Multiple data

Схема ЭВМ "много команд - много данных"

MIME

Multipurpose Internet Mail Extensions

Многоцелевые расширения электронной почты Интернет (стандарт RFC-821, -822)

MIN

Multistage Interconection Network

Сеть с многокаскадными соединениями

MINFO

Mail INformation FOrmat

Информационный формат почты

MINT

Mail Interchange

Почтовый обмен

MIP

Multichannel Interface Processor

Процессор многоканального интерфейса

MIPS

Million Instructions Per Second

Миллион операций в секунду

MIR

Maximum Information Rate

Максимальная скорость передачи данных

MIS

Management Information System

Система управления информацией

Multimedia Information Sources [Internet]

Источники мультимедийной информации

MISC

Miscellaneous

Разное

MISD

Maultiple-Instruction, Single-Data

С одним потоком данных и несколькими потоками команд

MIT

Massachusetts Institute of Technology

Массачусетский технологический институт

MITTR

Mean Time to Repair

Среднее время ремонта

MIX

Member Information Exchange

Обмен информацией об участниках

Multiservice Interchange

Обмен информацией с предоставлением множественных услуг

MJPEG

Motion JPEG

Стандарт для движущихся картинок (но не кино)

MKDIR

Make Directory

Создать каталог

ML

Machine Language

Машинный язык

MLAL

MultiLetter Acronym Listing

Список многобуквенных акронимов

MLAPI

Multilingual Application Programming Interface

Программный интерфейс для многоязыковых приложений

MLB

Muli-Layer Board

Многослойная карта

MLD

Multicast Listener Discovery

Выявление мультикастных слушателей (RFC-2710)

MLE

Maximum Likehood Estimate

Оценка с использованием критетрия максимума равдоподобия

MLID

Multiple Link Interface Driver

Драйвер многоканального интерфейса

MLP

MultiLayer Perceptron

Многослойный персептрон

MultiLink PPP

Многоканальный PPP

MLPCB

MultiLayer Printed Circuit Board

Многослойная печатная плата

MLSE

Maximum-Likelihood Sequence Estimation

Последовательные апроксимации по методу максимума правдоподобия

MM

Minutes/ Month

Минуты/Месяцы

MMA

Microcomputer Managers Association

Ассоциация менеджеров микроЭВМ

MMC

Matched Memory Cycle

Согласованный цикл памяти

Microsoft Management Console

Управляющий терминал Microsoft

Microcomputer Marketing Council

Совет маркетинга микроЭВМ

MMF

MultiMode Fiber

Мультимодовое оптическое волокно

MMIS

Materials Manager Information System

Система управления для информации о материалах

MML

Man-Machine Language

Язык для системы человек-машина

MMPM

Multi Media Presentation Manager

Менеджер мультимедийных презентаций

MMoIP

Multi Media over IP

Передача мультимедийных данных через Интернет

MMP

Multichassis Multilink PPP

Расширение MLP для групп маршрутизаторов и серверов

MMU

Memory Management Unit

Блок управления памятью

MNOS

Metal Nitride Oxide Semiconductor

Полупроводник метал-нитрид-оксид

MM

Multi Mode

Многомодовый (оптоволокно)

MMDF

Multi(channel) Memorandum Distribution Facility

Многоканальная система рассылки меморандумов

MMF

Multi Mode Fiber

Многомодовое волокно

MMFS

Manufacturing Message Format Standard

Стандартный формат промышленных сообщений

MMS

Matra Marconi Space

Название компании

Multimedia Message Service

Мультимедийные услуги передачи сообщений

MMU

Memory Management Unit

Блок управления памятью

MNP

Microcom Networking Protocol [Microcom]

Сетевой протокол фирмы Микроком, используется для коррекции ошибок и сжатия данных

MO

Managed Object

Управляемый объект

MOC

Maintenance Operations Console

Консоль управления параметрами

Managed Object Class

Класс управляемых объектов

MOE

Measure of Effictiveness

Критерий эффективности

MODEM

MOdulator/DEModulator

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

MOHLL

Machine Oriented High Level Language

Язык высокого уровня, ориентированный на машину

MOM

Microsoft Office Manager

Офисный менеджер Microsoft

Message-Oriented Middleware

Интерфейсные программы, ориентированные на обмен сообщениями

MOMA

Message-Oriented Middleware Association

Ассоциация интерфесного программного обеспечения, ориентированного на обмен сообщениями

MOP

Maintenance Operation Protocol

Протокол задания рабочих параметров

MOS

Metal Oxide Semiconductor

Метал-оксидный полупроводник

MOSFET

Metal Oxide Semiconductor Field Effect Transistor

Метал-оксидный полевой транзистор

MOSPF

Multicasting OSPF

Протокол OSPF для междоменного мультикастинг-обмена

MOST

Maximum One Step Throughput

Проход максимум на один шаг (маршрутизация)

MOTIS

Message Oriented Text Interchange System

Система передачи текстов, ориентированная на обмен сообщениями (почта)

MOV

Metal Oxide Varistor

Метал-оксидный варистор

Move

Перенести

MOVS

Move String

Перенести строку

MP

Multipoint Processor

Многоточечный процессор

MicroProcessor

Микропроцессор

Maintenance Point

Контрольная точка

MPC

Multimedia Personal Computer

Мультимедийный персональный компьютер

MPCS

Mission Planning and Control Station

Станция управления и планирования (программа)

MPEG

Motion Picture Expert Group

Экспертная группа по движущимся изображениям (стандарт ISO 11172)

MPI

Multiprecision Integer

Целое большой точности

MPLS

Multiprotocol Label Switching

Промышленный многопротокольный стандарт для коммутации пакетов с помощью меток

MPOA

Multiprotocol Over ATM

Стандарт транспортировки пакетов разных протоколов через ATM

MPP

Message Posting Protocol

Протокол передачи сообщений (RFC 1204)

Massively Parallel Processing

Интенсивная параллельная обработка

Message Processing Program

Программа обработки сообщений

MPPE

Microsoft Point-to-Point Encryption

Алгоритм Майкрософт для шифрования обмена по схеме точка-точка

MPR

MultiPort Repeater

Многопортовый повторитель

Multi Protocol Router

Многопротокольный маршрутизатор [Novell]

MPS

MultiProcessor Specification

Мультипроцессорная спецификация

MPSR

Multi-Pass Self-Routing

Многопроходная само-маршрутизация

MPT

Ministry of Telephone & Telegraph

Министерство телефона и телеграфа (Япония)

MPU

Microprocessor Unit

Блок микропроцессора

MQI

Message Queuing Interface

Интерфейс для работы с очередями сообщений

MQW

Multiple-Quantum-Well

Мульти-квантовый колодец (оптический модулятор)

MR

Modem Ready

Модем готов

MRCS

MultiRate Circuit Switching

Переключающая схема, рассчитанная на большое число скоростей

MRCF

Microsoft Realtime Compression Format

Формат сжатия информации в реальном масштабе времени Microsoft

MRCI

Microsoft Realtime Compression Interface

Интерфейс для сжатия информации в реальном масштабе времени (Microsoft)

MRFCS

Multirate Fast Circuit Switching

Быстрая многоскоростная схема коммутации каналов

MRI

Magnetic Resonance Imaging

Отображение магнитного резонанса

MRO

Multi-Region Operation

Многодиапазонная работа

MR

Memory Register

Регистр памяти

MRO

Maintenance, Repair, Operating

Профилактика, ремонт, эксплуатация

MRP

Materials Requirement Planning

Планирование требований к материалам

MRPL

Main Ring Path Length

Длина пути по главному кольцу

MRS

Medium Rate Segment

Сегмент скорости обмена среды

Media Recognition System

Система распознавания среды

Microwave Radio System

Радиорелейная система

MRT

Mean Repair Time

Среднее время восстановления (ремонта)

MRU

Maximum Receive Unit

 

MS

Memory System

Система памяти

Message

Сообщение

Multiplex Section

Мультиплексная секция

Microsoft Corporation

Корпорация Microsoft

Millisecond

Миллисекунда

MSA

Multiplex Section Adaptation

Адаптация на уровне мультиплексной секции

MSACM

Microsoft Audio Compression Manager

Менеджер сжатия аудиоинформации [Microsoft]

MSAU

Multi-Station Access Unit

Блок доступа для нескольких станций

MSAV

Microsoft Anti Virus

Антивирусная программа Microsoft

MSB

Most Significant Bit

Старший бит

MSC

Most Significant Character

Старший символ

MSD

Most Significant Digit

Самая значащая цифра числа

MSCDEX

Microsoft Compact Disc Extensions [Microsoft]

Расширения компактного диска Microsoft

MSD

Mass Storage Device

Устройство массовой памяти

Most Significant Digit

Старшая цифра

Microsoft System Diagnostics

Системная диагностика Microsoft

MSE

Mean-Square Error

Среднеквадратичная ошибка

MSL

Maximum Segment Lifetime

Максимальное время жизни сегмента (TCP)

MS

MicroSoft (company)

Название компании

MSAU

MuliStation Access Unit

Блок доступа к большому числу станций

MSC

Multi-Slot Cell (routing)

Многогнездная ячейка

MicroSoft C-compiler

СИ компилятор Microsoft

Mobile-Service switching Centre

Центр коммутации мобильной связи

MSDN

MicroSoft Developer Network

Сеть разработчика MicroSoft

MSDR

Multiplexed Streaming Data Request

Запрос мультиплексированного поточного обмена данными

Microsoft Developer Support

Поддержка разработчика Microsoft

MSDTP

Message Services Data Transmission Protocol

Протокол передачи данных для системы работы с сообщениями

.MSG

Program Message

Расширение имени файла сообщений

MSE

Mean Squared Error

Среднеквадратичная ошибка

MSI

Medium Scale Integration

Средний уровень интеграции

MSL

Map Specification Library

Библиотека спецификации карты

Maximum Segment Lifetime

Максимальное время жизни сегмента (протокол TCP)

MSN

Monitoring Sequence Number

Порядковый номер мониторинга

Multiple Subscriber Number

Код локальной субсети в ISDN

MSO

Multiple-Systems(service) Operator

Многосистемный оператор

MSOH

Multiplexer Section Overhead

Заголовок мультиплексной секции

MSP

Multiplex Section Protection

Защита мультиплексной секции

MSP

Multiplex Section Protection

Защита мультиплексной секции

MSR

Molecular Sequence Reduction

Метод построения памяти (редактирование порядка молекул)

MSS

Maximum Segment Size

Максимальный размер сегмента (TCP)

Mass Storage System

Массовое запоминающее устройство (диск или магнитная лента)

MST

Mountain Standard Time

 

Multiplex Section Termination

Начало/конец мультиплексной секции

MSW

Machine Status Word

Статусное слово машины

MTA

Message Transfer Agent

Субъект передачи сообщения

Multiple Terminal Access

Многотерминальный доступ

Mail Transfer Agent

Посредник для передачи почтовых сообщений

MTBB

Mean Time Between Breakdowns

Среднее время между пробоями

MTBE

Mean Time Between Errors

Среднее время между ошибками

MTBF

Mean Time Between Failures

Среднее время между отказами, время наработки на отказ

MTBJ

Mean Time Between Jams

Среднее время между перегрузками

MTF

Microsoft Tape Format

Формат лент Microsoft

Modulation Transfer Function

Передающая функция модуляции

MTP

Message Transfer Part

Сигнальное сообщение (SS7)

MTS

Message Transfer Service/System

Служба/система передачи сообщений

Multichannel Television Sound

Многоканальный телевизионный звук

Message Telephone Service

Телефонная служба сообщений

MTTC

Mean Time To Crash

Среднее время до отказа

MTTF

Mean Time To Failure

Среднее время до выхода из строя

MTTR

Mean Time to Repair

Среднее время ремонта

MTU

Maximum Transfer Unit (datagram)

Максимальная длина пересылаемого блока данных

MUD

Multi-User Domain

Многопользовательский домен [Internet]

Multi-User Dungeon [Internet]

Многопользовательская башня-темница (игра в Интернет)

MUI

Mode independent Unnumbered Information

Не нумерованная информация, независящая от режима (RFC-713)

MUME

MUlti-Module neural computing Environment

Многомодульная среда для нейронных вычислений

MUMPS

Massachusetts General Hospital Utility

Система общей больницы Массачусетса

Multi-Programming System (Programming Language)

Мультипрограммная система (язык программирования)

MUSE

Multi-User Shared Environment

Многопользовательская среда с распределением ресурсов

Musicam

Masking pattern Universal Sub-band Integrated Coding And Multiplexing

Стандарт представления высококачественного звукового сопровождения

MUX

MUltipleXor

Множественное исключающее ИЛИ

MV

Mean Value

Среднее значение

MVB

Multimedia Viewer Book

Книга мультимедийных просмотрщиков

MVC

Multimedia Viewer Compiler

Мультимедийный компилятор просмотрщика

Monitor View Control

Управление изображением на мониторе

MVDM

Multiple Virtual DOS Machines

Множественные виртуальные DOS-машины

MVE

Modular Visualization Environment

Модульная среда визуализации

MVGA

Monochrome Video Graphics Array

Массив монохромной видеографики

MVP

Multimedia Video Processor

Мультимедийный видеопроцессор

Most Valuable Product

Наиболее ценный продукт

MVS

Multiple Virtual Storage (IBM)

Множественная (многосегментная) виртуальная память

MVT

Multiprogramming with a Variable number of Tasks

Мультипрограммирование с переменным числом задач

MW

Message Waiting

Ожидание сообщения

MWI

Message Waiting Indicator

Индикатор ожидания сообщения

MX

Mail eXchange

Почтовый обмен

MZM

Mach-Zehnder Modulator

Модулятор Маха-Цандера (оптоволокно)


Previous: 10.10.12 [L]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.14 [N]


previous up down next index index
Previous: 10.10.13 [M]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.15 [O]

10.10.14 [N]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

NA

Numeric Aperture

Цифровая апертура

NAC

Network Adapter Card

Карта сетевого адаптера

NACD

National Association of Computer Dealers

Национальная ассоциация компьютерных дилеров

NACS

NetWare Asynchronous Communications Server

Асинхронный сетевой коммуникационный сервер

National Advisory Committee on Semiconductors

Национальный консультативный комитет по полупроводникам

NACSIS

NAtional Center for Science Information Systems

Национальный центр по научным информационным системам

NADF

North American Directory Forum

Северо-американская форум по каталогам

NADH

North American Digital Hierarchy

Северо-американская цифровая иерархия (каналов)

NADN

Nearest Active Downstream Neighbor

Ближайший активный нижележащий сосед

NAK

Negative AcKnowledgment

Отрицательное подтверждение

NAL

Novell Application Launcher

Система запуска заданий

NANOG

North American Network Operator's Group

Cевероамериканская группа сетевых операторов

NANP

North American Numbering Plan

Североамериканский план нумерации

NAP

Network Access Point

Точка доступа к сети

NAPLPS

North American Presentation Level Protocol Syntax

Североамериканский синтаксис протокола уровня презентаций (графика)

NARP

NBMA Address Resolution Protocol

Протокол преобразования адресов NBMA

NAS

Network Application Support

Поддержка сетевых приложений (DEC)

Network Access Server

Сервер доступа к сети

NASA

National Aeronautics and Space Administration

Национальная администрация аэронавтики и космоса

NASI

NetWare Asynchronous Interface

Асинхронный сетевой интерфейс [Novell]

NAT

Network Address Translation

Трансляция сетевых адресов

NAU

Network Addressable Unit

Сетевой адресуемый модуль

Network Access Unit

Блок сетевого доступа

NAUN

Nearest Active Upstream Neighbor (Token Ring)

Ближайший активный сосед-предшественник (вышестоящий)

NBFCP

NetBIOS Frames Control Protocol

Протокол управления кадрами в NetBIOS (конфигурация NetBIOS через PPP)

NBI

Nothing But Initials

Ничего кроме инициалов

NBDD

NetBios Datagram Distribution

Рассылка дейтограмм NetBios

NBFCP

NetBios Frame Control Protocol

Протокол управления пересылкой кадров NetBios

NBMA

NonBroadcast MultiAccess

Нешироковещательный множественный доступ

NBNS

NetBios Name Server

Сервер имен NetBios

NBP

Name Binding Protocol

Протокол привязки имен

NBS

National Bureau of Standards

Национальное бюро стандартов

NC

No Carry

Нет переноса

Numerical Control

Числовое управление

Network Controller

Сетевой контроллер

NCA

Network Communications Adapter

Адаптер сетевых коммуникаций

NCC

Network Coordination (Control) Center

Координационный (управляющий) центр сети

NCCF

Network Communication Control Facility

Система управления коммуникациями в сети

NCGA

National Computer Graphics Association

Национальная ассоциация компьютерной графики

NCIA

Native Client Interface Architecture

Архитектура клиентского интерфейса

NCIC

National Crime Information Center

Национальный информационный криминалистический центр

NCL

Network Command Language

Сетевой командный язык

NCMT

Numerical Control for Machine Tools

Цифровой контроль для машинных средств

NCL

Network Command Language

Сетевой командный язык

NCP

Network Control Program/Processor

Сетевая программа/процессор управления

Not Copy Protected

Не защищено от копирования

Network Core Protocol (Novell)

Протокол ядра NetWare

Network Control Protocol

Сетевой протокол управления

NCR

National Cash Register

Название компании

NCS

Network Computing System

Сетевая вычислительная система

NCSA

National Center for Supercomputing Applications

Национальный центр по суперкомпьютерным приложениям

NCSI

Network Communications Services Interface

Интерфейс коммуникационных сетевых услуг [Novell]

ND

No Date

Без даты

NDE

Nonlinear Differencial Equation

Нелинейное дифференциальное уравнение

NDIS

Network Driver Interface Specification

Спецификация драйвера сетевого интерфейса

NDDK

Network Device Development Kit [Microsoft]

Средства разработки сетевого оборудования

NE

Network Element

Сетевой элемент

NES

National Education Supercomputer

Суперкомпьютер системы национального образования

NDF

New Data Flag

Флаг новой информации

NDFA

Neodymium Doped Fiber Amplifier

Оптоволоконный усилитель с неодимовым допированием

NDIS

Network Driver Interface Specification

Спецификация драйвера сетевого интерфейса

Network Device Interface Specification

Спецификация устройства сетевого интерфейса

NDP

Numerical Data Processor

Цифровой процессор данных (IBM)

NDPS

Novell Distributed Print Services

Распределенная система печати фирмы Новел

NDRO

Non-Destructive Read Out

Считывание без разрушения

NDS

NetWare Directory Service

Служба сетевых каталогов [Novell]

NDT

NonDistructive Testing

Неразрушающее испытание

NE

Network Element

Сетевой элемент

NEBS

Network Equipment Building System

Система построения сетевого оборудования

NEC

Nippon Electric Company

Название компании

NED

NASA Extragalactic Database

Экстрагалактическая база данных [NASA]

NEF

Network Element Function

Функция сетевого элемента

NEMS

Network Element Management Server

Сервер управления сетевым элементом

NES

Not Elsewhere Specified

Не определено где-либо еще (о переменных в программе)

NET

Normes Europeennes de Telecommunication

Европейские нормы для телекоммуникаций

Network Entity Title

Сетевое имя объекта

NetBIOS

Network Adapter Basic In/Out System (protocol to find server process & communicate with it)

Протокол поиска сервера процесса и связь с ним, RFC-1001, -1002

NetBEUI

NetBIOS Extended User Interface

Расширенный пользовательский интерфейс NetBIOS [IBM]

NETBLT

Bulk Data Transfer Protocol

Протокол передачи больших потоков данных с большой скоростью

NETED

Network Standard Text Editor

Стандартный сетевой текстовый редактор (RFC-569)

NETNORTH

Canadian academic and research network, closely coupled to BITNET and EARN

Канадская академическая исследовательская сеть, тесно связанная с BITNET и EARN

NETRJS

Remote Job Service

Служба управления удаленными задачами (RFC-740)

NEWS

NetWare Early Warning System [Frye Computer]

Система раннего оповещения NetWare

NEXT

Near-End Crosstalk

Перекрестные наводки от ближней части канала

NFF

No Fault Found

Никакой ошибки не найдено

NEWS

Network Extensible Window System

Сетевая система для масштабируемых окон

NFDS

Neural FDS

Нейронный FDS

NFS

Network File System

Сетевая файловая система (UNIX)

NFT

Name Forms Tree

Дерево имен

NGM

Netware Global Messaging

Глобальная сетевая система передачи сообщений

NHRP

Next Hop Resolution (Routing) Protocol

Протокол поиска следующего шага (CISCO)

NHS

Next Hop Server

Сервер следующего шага

NIA

Network Interoperability Alliance

Альянс сетевого взаимодействия

NIC

Network Information Center

Сетевой информационный центр

Network Interface Card

Карта сетевого интерфейса

NICAD

Nickel Cadmium

Никель-кадмиевый

NIC

Network Information Center

Сетевой информационный центр [Internet]

Network Interface Card

Сетевая интерфейсная карта

Numeric Intensive Computing

Интенсивные вычисления на ЭВМ

NICE

Novell Integration, Coordination and Evolution

Система интеграции, координации и адаптации фирмы NOVEL

NICOLAS

Network Information Center OnLine Aid System

Система помощи в реальном времени сетевого информационного центра [NASA]

NID

New Interactive Display

Новый интерактивный дисплей [NEC]

Next ID

Следующий ID

NII

National Information Infrastructure

Национальная информационная инфраструктура

NIDL

Network Interface Definition Language

Язык описания сетевых интерфейсов

NII

National Information Infrastructure

Национальная информационная инфраструктура

NIMH

Nickel-Metal Hydride

Никель-метал гидрид

NIPS

Neural Information Processing System

Система обработки нейронной информации

Network I/Os Per Second

Число входных/выходных сетевых операций в секунду

NIR

Network Information Retrieval

Получение сетевой информации

NIS

Network Information Service

Сетевая информационная служба [Unix]

NIST

National Institute for Standards and Technology

Национальный институт стандартов и технологий (США)

NIIT

National Information Infrastructure Testbed

Система тестирования национальной информационной инфраструктуры

NIT

Network Interface Tap

Интерфейс сетевого ответвления

NITC

National Information Technology Center

Национальный центр информационной технологии

NL

New Line

Новая строка

NLDM

Network Logical Data Manager

Менеджер сетевой логической информации

NLM

Network Loading Modules (UNIX-server/Netware)

Модули, загружаемые через сеть

NLR

Network Layer Relay

Ретрансляция на сетевом уровне

NLSFUNC

National Language Support Function

Функции поддержки национального языка

NLP

Natural Language Processing

Работа с естественным языком

NLPI

Network Layer Protocol Identifier

Идентификатор протокола сетевого уровня

NLPID

Network Layer Protocol IDentifier

Идентификатор протокола сетевого уровня (Frame Relay)

NLQ

Near Letter Quality

Почти полиграфическое качество

NLRI

Network Layer Reachibility Information

Информация о достижимости сетевого уровня (BGP)

NLS

National Language Support

Поддержка национальных языков

NLSP

NetWare Link Services Protocol

Протокол межсетевого обмена (Novell)

NM

Network (Node) Manager

Менеджер сети (узла)

NMA

Network Management Architecture

Архитектура сетевого управления

Network Management and Analysis

Сетевое управление и анализ

NMC

Network Management Control

Контроль сетевого менеджмента

NMDS

Nonmetric Multidimensional Scaling

Неметрическое многомерное масштабирование

NMFECC

National Magnetic Fusion Energy Computer

Центр в LLNL (супер ЭВМ, MFENET и ESNET)

NMI

Non-Maskable Interrupt

Немаскируемое прерывание

NMM

NetWare Management Map

Карта управления NetWare

NMOS

Negative Channel Metal-Oxide Semiconductor

Метал-оксидный полупроводник с отрицательным каналом

NMP

Network Management Processor

Процессор сетевого управления

NMPF

Network Management Productivity Facility

Система контроля пропускной способности сети

NMS

Netware (Network) Management System [Novell]

Система управления NetWare (сети)

NMVT

Network Management Vector Transport

Передача сетевого управляющего вектора

NN

National Number

Национальный код

Neural Network

Нейронная сеть

Network Node

Сетевой узел

NNE

Non-SDH Network Element

Элемент, не являющийся частью сети SDH

NNI

Network Node Interface

Интерфейс узла сети

Network-Network Interface

Интерфейс сеть-сеть

NNN

Noisy Neural Network

Нейронная сеть с шумом

NNS

NetWare Name Service

Служба имен NetWare

NNT

National Network Testbed

Испытательный стенд национальной сети

NNTP

NetNews Transfer Protocol

Протокол пересылки новостей (RFC-977)

NNX

Network Numbering eXchange (NXX)

Сетевой обмен номерами

NO

Normally Open

Нормально разомкнутый

NOA

Nature Of Address

Природа адреса

NOAO

National Optical Astronomy Observatories

Национальные обсерватории оптической астрономии

NOC

Network Operation Center

Центр управления сетью

NOIT

Name Object ID Tree

Дерево идентификаторов имен объектов

NOLM

Nonlinear Optical Loop Mirror

Нелинейное зеркало оптической петли

NOP

No OPeration

Никаких команд

NORDUNET

Nordic (R&D) University Network

Северная исследовательская университетская сеть

NOS

Network Operating System

Сетевая операционная система

NPA

Network Printer Alliance

Альянс сетевых принтеров

NPC

Network Parameter Control

Контроль параметров сети

NonPrintable Character

Непечатаемый символ

NPDA

Network Problem Determination Application

Приложение для определения сетевых проблем

NPDU

Network Protocol Data Unit

Сетевой протокольный блок данных

NPI

Network Printer Interface

Сетевой интерфейс принтера

Null Pointer Indicator

Поле индикации нулевого указателя

Number Plan Identification

Идентификация плана номеров

NPL

Nonprocedural Language

Непроцедурный язык

NPM

Network Processor Module

Модуль сетевого процессора

NPSI

NCP Packet Switching Interface

Интерфейс переключения пакетов NCP

NPTN

National Public Telecomputing Network

Национальная общедоступная сеть для удаленных вычислений

NPU

Natural Processing Unit

Блок естественной обработки

NPX

Numeric Processor Extension

Расширение цифрового процессора

NQS

Network Queuing System

Сетевая система очередей

NREN

National Research and Education Network

Национальная сеть для целей исследований и образования

NRM

Normal Response Mode

Режим нормального отклика

NRZ

Non-Return to Zero

Без возврата к нулю (схема двоичного кодирования)

NRZI

Non Return to Zero Inverted

Кодирование без возврата к нулю с инверсией

NS

Name Server

Сервер имен

Not Specified

Не определенный техническими условиями

Nanosecond

Наносекунда

Network Service

Сетевое обслуживание

Network Supervisor

Супервизор сети

Non Stop

Безостановочный

NSA

National Security Agency

Агентство национальной безопасности США

NSAP

Network Service Access Point

Точка доступа к сетевым услугам

NSEL

Network SELection

Выбор сети (поле адреса NSAP)

NSF

U.S. National Science Foundation

Национальный научный фонд США

Network Supervisory Function

Сетевая супервизорная функция

Network File System

Сетевая файловая система

Nonstop Forwarding

Непрерывная переадресация (CISCO)

NSI

NASA Science Internet

Научная сеть Интернет NASA

NSN

NASA Science Network

Научная сеть NASA

NSP

Network Service Protocol

Протокол сетевых услуг

Network Service Provider

Организация, предоставляющая сетевые услуги

NSS

Nodal Switching System

Узловая система переключения

Novell Storage Services

Служба памяти Novell

NT

Network Termination

Согласование сети

Network Terminal

Сетевой терминал

No Transmition

Отсутствие передачи

New Technology (WINDOWS new modification)

Новая технология (версия MS-Windows)

NTA

Norwegian Telecommunication Administration

Норвежская администрация телекоммуникаций

NTAS

New Technology Advanced Server

Улучшенный NT-сервер (NT-Windows)

NTFS

New Technology File System

Файловая система новой технологии (Windows NT)

NTIA

National Telecommunications and Information Administration

Национальная администрация телекоммуникаций и информации

NTN

Network Terminal Number

Номер сетевого терминала

NTP

Network Time Protocol

Сетевой протокол службы времени (RFC-1305)

NTRAS

NT Remote Access Services

Службы удаленного доступа NT [Microsoft]

NTRI

NCP/Token Ring Interconnection

Подключение к NCP/Token Ring

NTSA

NetWare Telephony Services Architecture

Архитектура служб услуг телефонии [Novell]

NTSC

National Television System Committee

Национальный комитет телевизионных стандартов (телевизионный стандарт США)

NUI

Network User Identification

Идентификация сетевого пользователя

Network User Interface

Сетевой интерфейс пользователя

Notebook User Interface

Пользовательский интерфейс ноутбука (Go Corporation)

NVE

Network-Visible Entity

Видимый сетевой объект

NVM

Non-Volatile Memory

Память с неразрушаемой информацией

NVNG

Non-Voice Non-Geostationary

Не голосовая не геостационарная (спутниковая коммуникационная система)

NVP

Nominal Velocity/Value of Propagation

Номинальная скорость/значение распространения

NVRAM

Non-Volatile Random Access Memory

Память с произвольным доступом и возможностью долговременного хранения

NVT

Network Virtual Terminal

Сетевой виртуальный терминал [Novell]

NXX

Network Numbering eXchange

Сетевой обмен номерами


Previous: 10.10.13 [M]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.15 [O]


previous up down next index index
Previous: 10.10.14 [N]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.16 [P]

10.10.15 [O]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

OAB

One-to-All Broadcast

Широковещательное обращение одного ко всем

OADM

Optical Add Drop Multiplexer

Технология оптического мультиплексирования

OAI

Open Applications Interface

Интерфейс открытых приложений

Overhead Access Interface

Интерфейс доступа к секционному заголовку SOH (SDH)

OAM

Operations Administration and Maintenance

Эксплуатация и техническое обслуживание

OAS

One-to-All Scatter

Обращение одного ко всем по списку

OAU

Overhead Access Unit

Блок доступа к секционному заголовку SOH (SDH)

OBA

Optical Booster Amplifier

Выходной оптический усилитель

OBEX

Object Exchange

Объектный обмен [Borland]

OC

Optical Carrier

Оптическая несущая

Operating Characteristic

Рабочая характеристика

Open Circuit

Разомкнутая цепь

OC-1

Optical Carrier of level 1. 51.840 Mbps

Канал на скорость 51840 Кбит/с (SONET)

OC-3

OC-3=155.52 Mbps,

Канал на скорость 155520 Кбит/с

OC-9

OC-9=466.56 Mbps,

Канал на скорость 466.56 Мбит/с

OC-12

OC-12=622.08 Mbps

Канал на скорость 622.08 Мбит/с

OC-18

OC-18=933.12 Mbps

Канал на скорость 933.12 Мбит/с

OC-24

OC-24=1244.16 Mbps

Канал на скорость 1244.16 Мбит/с

OC-36

OC-36=1866.24 Mbps

Канал на скорость 1866.24 Мбит/с

OC-48

OC-48= 2488.32 Mbps

Канал на скорость 2488.32 Мбит/с (=STM-16 для SDH)

OC-240

OC-240=12.4416Gbps

Канал на скорость 12.44116 Гбит/с

OCA

Open Communication Architecture

Открытая коммуникационная архитектура

OCC

Operating Call Control

Операционое управление вызовами

OCCF

Operator Communication Control Facility

Система управления оператора коммуникаций

OCE

Open Collaborative Environment [Apple]

Открытая среда совместной работы

OCL

Operation Control Language

Язык управления операциями

Operator Control Language

Язык управления оператора

OCLC

Online Computer Library Catalog

Каталог библиотеки реального времени

OCR

Optical Character Recognition / Reading

Распознавание/чтение видеосимволов

ODA

Office Document Architecture

Стандарт на передачу и преобразование документов

Open Document Architecture

Открытая архитектура документооборота

ODAPI

Open Database Application Programming Interface [Borland]

Программный интерфейс приложений открытых баз данных

ODBC

Open DataBase Connectivity (Windows)

Доступ к открытой базе данных

ODBMS

Object-Oriented Database Management System

Система управления объектно-ориентированных баз данных (см. также OODMS)

ODI

Open Data-link Interface

Интерфейс открытого канала [Novell]

ODIF

Office Document Interchange Format

Формат передачи документов

ODL

Optical Delay Line

Оптическая линия задержки

ODMA

Open Document Management API

Интерфейс делопроизводства

ODMR

On-Demand Mail Relay

SMTP с динамическими IP-адресами

ODP

Open Distributed Processing

Открытая распределенная обработка (ISO 10746)

Originator Detection Pattern

Сигнатура для распознавания отправителя

ODS

Open Data Services

Открытые информационные услуги [Microsoft]

ODSA

Open Distributed System Architecture

Архитектура открытых распределенных систем

OEIC

OptoElectric Integrated Circuit

Оптоэлектронная интегральная схема

OEM

Original Equipment Manufacturer

Основной производитель оборудования

OER

Open Fiber Control

Контроль разомкнутости разъемов оптических волокон

OFC

Output Format for Numbers

Выходной формат для чисел

OFDM

Orthogonal Frequency Division Multiplexing

Ортогональный метод мультиплексирования по частоте

OFMT

Output Format for Numbers

Выходной формат для чисел

OFS

Output Field Separator

Разграничитель выходных полей

Out of Frame Second

Секунда, содержащая сигнал OOF (выход за границы кадра)

OGM

OutGoing Message

Исходящее сообщение (FAX)

OH

Over Head

Заголовок (кадра)

OHA

Overhead Access/ Overhead Access function

Доступ к заголовку или функция доступа к заголовку

OHC

Overhead Channel

Канал связи заголовка

OIDL

Object Interface Definition Language

Язык описания объектного интерфейса

OIM

OSI Internet Management

OSI-управление Интернет

OIR

Online Insertion and Removal

Ввод и удаление в реальном времени

OIS

Office Information System

Офисная информационная система

OLAP

OnLine Analytic Processing

Аналитическая обработка в реальном масштабе времени

OLC

Optimal Linear Combination

Оптимальная линейная комбинация

OLE

Object Linking & Embedding [Microsoft]

Объектные связи и реализация

OLI

Optical Line Interface

Интерфейс оптического канала [AT&T]

OLMC

Output Logic Macrocell

 

OLO

Other Local Operator

Другой местный оператор

OLTP

OnLine Transaction Processing

Обработка транзакций реального времени

OM

Object Manager

Менеджер объектов

OMA

Object Manager

Менеджер объектов

OME

Object Management Architecture

Архитектура управления объектами

OMF

Object Module Format

Формат объектного модуля [Microsoft]

Open Message Format

Открытый формат сообщений

OMG

Object Management Group

Группа управления объектами

OMI

Open Messaging Interface

Открытый интерфейс для работы с сообщениями [Lotus]

OMIN

Optic Multistage Interconnection Network

Оптическая многосекционная сеть

OMNS

Open Network Management System

Открытая система сетевого управления

OMR

Optical Mark Recognition

Распознавание оптической метки

OMS

Optoelectronic Multiplex Switch

Оптоэлектронный мультиплексор

ONAL

Off-Network Access Line

Канал внесетевого доступа

ONC

Open Network Computing

Вычисления в рамках открытой сети [Sun]

ONU

Optical Network Unit

Оптический сетевой блок

OO

Over and OUT (goodbye, *)

До свидания и выходим

OODB

Object-Oriented Database

Объектно-ориентированная база данных

OODBMS

Object-Oriented Database Management System

Система управления объектно-ориентированными базами данных

OOF

Out Of Frame

Выход за границы заголовка

OOL

Object-Oriented Language

Объектно-ориентированный язык

OOP

Object Oriented Programming

Объектно-ориентированное программирование

OOPL

Object-Oriented Programming Language

Язык объектно-ориентированного программирования

OOPS

Object Oriented Programming and Systems

Объектно-ориентированное программирование и системы

OOS

Object-Oriented Systems

Объектно-ориентированные системы

Off-line Operating Simulator

Выполнение моделирования вне реального масштаба времени

Out-Off-Service

Услуга сейчас не предоставляется

OOSD

Object-Oriented Structured Design

Объектно-ориентированное структурное проектирование

OOUI

Object Oriented User Interface

Объектно-ориентированный интерфейс пользователя

OPA

Optical Preamplifier

Оптический предусилитель

OPAC

Online Public Access Catalog

Общедоступный через сеть каталог [Internet]

OPC

Optical Photoconductor

Оптическое фотосопротивление

Own Point Code

Собственный код точки (CISCO)

OPI

Open Prepress Interface

 

OPM

Operations Per Minute

Число операций в секунду

Operator Programming Method

Операторный метод программирования

OPS

Open Profiling Standard

Открытый стандарт для профайлов

OPT

Open Protocol Technology

Технология открытых протоколов

OPUS

Octal Program Updating System

Система актуализации восьмеричной программы

OPWA

One Pass With Advertising

Однопроходная процедура резервирования (протокол RSVP)

ORB

Object Request Broker (SUN)

Программа, определяющая взаимодействие в системе клиент-сервер (CORBA)

OR

Operating Range

Рабочий диапазон

O/R

Originator/recipient address

Адрес отправителя/получателя

On request

По запросу

ORS

Output Record Separator

Сепаратор выходного рекорда

OS

Operating System

Операционная система

OSA

Open System Architecture

Архитектура открытых систем

OSF

Open Software Foundation

Фонд открытого программного обеспечения

Operations System Function

Функция управляющей системы

OSI

Open Systems Interconnection

Набор протоколов, образующих международный стандарт (OSI, RFC-1177) для соединения разнородных ЭВМ и сетей

OSINLCP

OSI Network Layer Control Protocol (RFC1377)

Управляющий протокол сетевого уровня OSI

OSM

Off-Screen Model

Внеэкранная модель

OSP

Optical Storage Processor

Процессор оптической памяти

OSPF

Open Shortest Path First

Открытый протокол "наикратчайший путь - первый" (RFC-1245-48)

OS/E

Operating System/Environment

Операционная система/среда

OSQL

Object Structured Query Language

Объектно-структурированный язык запросов

OSTP

White House Office of Scientific and Technical Policy

Офис белого дома по науке и технической политике

OT

Object Technology

Объектная технология

Operate Time

Время работы

OTDR

Optic Time Domain Reflectometry

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

OTF

Open Token Foundation

 

OTI

Open Transport Interface

Интерфейс открытой передачи

OTP

One-Time Programmable

Однократно программируемый

OU

Organization Unit

Блок организации (атрибут адреса X.400)

OUA

Organizationally unique address

Часть адреса, идентифицирующая производителя

OUI

Organization Unique Identifier

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

OURS

Open Users Recommended Solutions

Object Vision (объектное приложение для Windows)

OWI

Order Wire Interface

Интерфейс служебного канала

OWL

Object Windows Library

Объектная библиотека Windows [Borland]


Previous: 10.10.14 [N]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.16 [P]


previous up down next index index
Previous: 10.10.15 [O]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.17 [Q]

10.10.16 [P]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

PA

Program Address

Адрес программы

PABX

Private Automatic Branch Exchange

Частный автоматический обмен по магистрали

PACE

Priority Access Control Enabled

Протокол для передачи мультимедиа данных через Ethernet или Fast Ethernet (приоритетный доступ)

PACS-L

Public Access Computer Systems List [Internet]

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

PAD

Packet Assembler/Disassembler

Протокольный адаптер для сборки/разборки пакетов - ПАД (X.25)

Protocol Adapter

Протокольный адаптер

PADLE

Padding Length

Длина заполнения (ATM)

PADS

Pen Application Development System [Slate Corporation]

 

PAIH

Public-Access Internet Host [Internet]

ЭВМ со свободным доступом из Интернет

PAIS

Public-Access Internet Site [Internet]

Узел Интернет со свободным доступом

PAL

Paradox Applications Language

Прикладной язык Paradox [Borland]

Phase Alternate Line (TV-system)

Система цветного телевидения ПАЛ

Programmed Array Logic

Программируемая логическая матрица

Programming Assembly Language

Язык-ассемблер

PALC

Plasma-Addressed Liquid Crystal (display)

Жидкокристаллический дисплей с плазменной адресацией

PALS

Principles of the Alphabet Literacy System

Принципы построения системы алфавитной грамотности

PAM

Pulse Amplitude Modulation

Амплитудно-импульсная модуляция

Partitioned Access Method

Библиотечный метод доступа

PAP

Printer Access Protocol

Протокол доступа к принтеру

Password Authentication Protocol

Протокол проверки пароля

PARC

Palo Alto Research Center

Исследовательский центр в Пало Альто [XEROX]

PAW

Physics Analysis Workstation

Рабочая станция для физического анализа

PAWS

Protection Against Wrapped Sequence Numbers

Защита против нарушения порядка номеров сегментов (TCP)

PAX

Portable Archive Exchange

Обмен переносимыми архивами [Unix]

Pravate Automatic Exchange

Частная автоматическая телефонная станция для выхода в общую сеть

PB

Printed Board

Печатная плата

PBC

Peripheral Board Controller

Контроллер периферийной карты

Philips Branch Cross-connect system

Система перекрестных соединений магистралей Philips

PBE

Prompt By Example

 

PBM

Portable BitMap

Формат для черно-белых изображений

PBX

Private Branch Exchange

Частная телефонная сеть

PC

Personal Computer

Персональная ЭВМ

Physical Contact

Физический контакт (оптоволоконные разъемы)

Parameter Checkout

Контроль параметров

Parameter Checkout

Контроль параметров

PCCA

Portable Computer and Communications Association

Ассоциация портативных ЭВМ и коммуникаций

PCA

Principal Component Analysis neural network

Главный компонентный анализ нейронной сети

PCB

Printed Circuit Board

Плата, выполненная методом печатного монтажа

Program Control Block

Блок программного контроля

PCD

Photo Compact Disk

Фото компактный диск

PCI

Peripheral Component Interconnect

Подключение периферийных устройств (BUS, Intel)

Protocol Control Information

Протокольная управляющая информация

PC-I/O

Program Controlled I/O

Программно управляемый ввод/вывод

PCL

Printer Command Language

Командный язык принтера [HP]

Process Control Language

Язык управления процессом

Programmable Logical Controllers

Программируемые логические контроллеры

Printer Command Language

Язык команд принтера

PCM

Pulsed Code Modulation

Импульсно-кодовая модуляция (ИКМ)

Personal Computer Manufacturer

Производитель персональных ЭВМ

PCMCIA

Personal Computer Memory Card International Association

Международная ассоциация по картам памяти для персональных ЭВМ (стандарт на разъем)

PCMG

PCI Industrial Computers Manufacturer's Group

Группа производителей промышленных ЭВМ на базе PCI

PCN

Personal Computer Network

Сеть персональных ЭВМ

PCNFS

Personal Computer Network File System

Файловая система сети персональных ЭВМ

PCMIM

Personal Computer Media Interface Module

Модуль интерфейса среды персональной ЭВМ

PCR

Peak Cell Rate

Пиковая частота следования ячеек (ATM)

PCS

Patchable Control Store

Перезаписываемая память управления

Personal Communication Services/System

Персональные коммуникационные услуги/системы

Planning Control Sheet

Управляющий список планирования

Print Contrast Signal

Сигнал контраста печати

Port Concentrator Switch

Переключатель портов

Process Control Systems

Системы управления процессом

Program Counter Store

Память программного счетчика

Project Control System

Система управления проектом

PCTE

Portable Common Tool Environment

Среда портативных средств общего назначения

PD

Public Domain

Общедоступный домен

Projected Display

Проекционный дисплей

PDA

Personal Digital Assistant

Персональный цифровой помощник

PDES

Product Data Exchange Standard

Стандарт на обмен информацией

PDD

Personal Digital Device

Персональный цифровой прибор

Physical Device Driver

Драйвер физического устройства

PDF

Portable Document Format

Формат переносимых документов (электронная почта)

Portable Document File

Переносимый файл документа

Processor Defined Function

Команда, заданная процессором

Probability Distribution Function

Функция распределения вероятностей

Program Development Facility

Система разработки программ

PDH

Plesiochronous Digital Hierarchy

Плезеохронная цифровая иерархия

PDIAL

Public Dialup Internet Access List

Список свободного доступа к Интернет через коммутируемые каналы

PDL

Page Description Language

Язык описания страницы

Program Description Language

Язык описания программы

Program Design Language

Язык конструирования программы

PDM

Physical Medium Dependant

Зависящий от физической среды

PDN

Public Data Network

Общедоступная информационная сеть (X.25)

PDP

Physics Data Processing

Обработка физических данных

Plasma Display Panel

Плазменная индикаторная панель

Programmable Data Processor

Программируемый процессор данных (DEC)

Packet Data Protocol

Протокол пакетных данных

PDS

Packet Driver Specification

Спецификация пакетного драйвера

Partitioned Data Set

Структурированный набор данных

Planetary Data System

Планетарная информационная система

Processor Direct Slot

Гнездо процессора [Macintosh]

Premises Distribution System

Первичная система распределения

PDSS

Post Development and Software Support

Почтовые разработки и поддержка программного обеспечения

PDT

Pacific Daylight Time

Тихоокеанское дневное время

Programmable Drive Table

Таблица программируемого драйва

PDU

Protocol Data Unit

Протокольный блок данных

Plug Distribution Unit

Вставной блок распределения

PE

Program Element

Элемент программы

Processing Element

Обрабатывающий элемент

PhotoElement

Фотоэлемент

PEA

Pocket Ethernet Adapter

Карманный адаптер Ethernet

PEL

Picture Element [IBM]

Элемент изображения (пиксель)

PEM

Privacy Enhanced Mail

Почта с улучшенной защитой [Internet]

PEN SDK

Pen Computing Software Development Kit

PEP

Packetized Ensemble Protocol

Протокол сборки пакетов [Telebit]

Packet Encoding Protocol

Протокол кодирования пакетов

Pascal Execution Profiler

Конфигурационный файл исполнения Pascal

PER

Packet Error Rate

Частота ошибок при передаче пакетов

PERL

Practical Extraction and Report Language

Язык программирования [Unix]

PERT

Program Evaluation and Review Technique

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

PES

Personal Earth Station

Персональная наземная станция

Performance Enhancement Socket

Соединитель для улучшения характеристик

Positioning Error Signal

Сигнал ошибки позиционирования

Processor Enhancement Socket

Улучшенный соединитель процессора

Packetized Elementary Stream

Первичный пакетный поток (MPEG-2)

PET

Pascal Execution Timer

Таймер исполнения Pascal

Positron emission Thomograph

Позитронно-эмиссионный томограф

Print Enhancement Technology

Технология улучшения печати [Compaq]

PF

Presentation Function

Функция представления

Page Formatter

Средство форматирования страниц

P/F

Poll/Final bit

Бит запроса или завершения

PFB

PostScript Font-Binary

Файл с данными о шрифте в исходном двоичном формате

PFM

PostScript Font MetyricsBinary

Метрическая информация о шрифте PostScript

PFR

Power-Fail Restart

Перезапуск при сбое питания

PGA

Pin Grid Array

Массив ножек корпуса

Professional Graphics Adapter

Профессиональный графический адаптер [IBM]

PGDN

Page Down

На страницу вниз

PGL

Peer Group Leader

Член группы в ATM, который выполняет функции LGN

PGM

Portable GrayMap

Формат для полутоновых графических файлов

PGP

Pretty Good Privacy

Безопасная система электронной почты (Название программы шифрования)

PHIGS

Programmer's Hierarchical Interactive Graphics System

Иерархическая интерактивная графическая система для программистов

PHY

PHysical Layer Protocol

Протокол физического уровня

PI

Protocol Identifier

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

Program Interrupt

Программное прерывание

PIA

Programmable Interconnect Array

Программируемая матрица связи

Peripheral Interface Adapter

Адаптер периферийного интерфейса

PIB

Policy Information Base

База данных маршрутной политики (BGP)

PIC

Personal Intelligent Communicator

Персональный интеллигентный коммуникатор

Priority Interrupt Controller

Контроллер приоритета прерываний

Program Interrupt Controller

Контроллер программных прерываний

Programmable Interface Controller

Контроллер программируемого интерфейса

Position Independent Code

Программа, независящая от места загрузки

Primary Interchange Carrier

Первичная несущая

PICS

Platform for Internet Content Selection

Средство для отбора информации в Интернет (для WWW, например, отбор страниц непригодных для детей)

PID

Process Identifier

Идентификатор процесса

Process Identification Number

Идентификационный номер процесса

PIF

Picture Information File

Информационный файл картинки (DOS из Windows)

PILOT

Programmed Inquiry Learning Or Teaching

Программное дистанционное обучение или тестирование

PIM

Protocol of Independent Multicasting

Протокол независимого мультикастинга

Personal Information Manager

Персональный информационный менеджер

PIMB

PCTE Interface Management Board

Управляющий совет по интерфейсам PCTE

PIM-SM

Protocol of Independent Multicasting-Sparse Mode

Протокол независимого мультикастинга - распределенный режим

PIN

Personal Identification Number

Персональный идентификационный номер

Process Identification Number [Unix]

Идентификационный номер процесса

PINE

Pine Is Not Elm [Unix]

"Сосна не вяз" (почтовая система)

PING

Packet InterNet Groper

Пакетное зондирование в Интернет

PINX

Private Integrated Network Exchange

Местный сетевой коммутатор (ISDN)

PIO

Parallel Input/Output

Параллельный ввод/вывод

Processor Input/Output

Ввод/вывод процессора

Programmed Input/Output

Программируемый ввод/вывод

PIP

Picture In Picture

Картинка в картинке

Problem Isolation Procedure

Процедура вычленения проблемы

Programmable Interconnect Point

Программируемая точка подключения

PIPO

Parallel In, Parallel Out

Параллельный ввод, параллельный вывод

PIR

Packet Insertion Rate

Частота ввода пакетов

PIT

Programmable Interval Timer

Программируемый таймер интервала

PIU

Programmable Interface Unit

Программируемый интерфейс

PJE

Pointer Justification Event

Факт выравнивания указателя

PK

Public Key

Общедоступный ключ (в системах шифрования)

PKC

Public Key Center

Центр общедоступных ключей

PKCS

Public-Key Cryptography Standard

Криптографический стандарт для метода с открытым ключом

PKI

Public Key Infrastructure

Инфраструктура общедоступных ключей

PL

Physical Layer (in Net hierarchy)

Физический уровень (в иерархии сетей)

Private Line

Частная линия

PayLoad

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

PLA

Programmable Logical Array

Программируемая логическая матрица

PLAR

Private Line, Automatic Ring-down

Частная линия, автоматический дозвон

PLATO

Programmed Logic for Automatic Teaching Operations

Программируемая логика для автоматических операций обучения

PLC

Programmable Logic Controller

Программируемый логический контроллер

PLCC

Plastic Leadless Chip Carrier

Пластиковый безсвинцовый носитель кристаллов

PLCP

Physical Layer Convergence Protocol

Протокол конвергенции физического уровня

PLD

Programmable Logic Device

Программируемый логический прибор

PLDS

Pilot Land Data System [NASA]

 

PLIM

Physical Layer Interface Module

Интерфейсный модуль физического уровня

PLL

Phase Locked Loop

Система фазовой стабилизации (синхронизации)

PLMN

Public Land Mobile Network Общедоступная сеть для мобильных клиентов

PLP

Packet Layer Procedure

Процедура пакетного уровня

Packet Layer Protocol

Протокол пакетного уровня (X.25)

PLR

Packet Loss Rate

Частота потери пакетов

PLS

Personal Library System

Система персональной библиотеки

Primary Link Station

Первичная станция канала

PLSP

PNNI Link State Packets

Пакеты состояния канала PNNI

PLU

Primary Logical Unit

Первичный логический блок

PLV

Production Level Video

Производственный уровень видео

PM

Presentation Manager

Менеджер презентаций [IBM]

Preventative Maintenance

Профилактическая работа

Performance Management

Управление рабочими характеристиками

Phase Modulation

Фазовая модуляция

Process Manager

Менеджер процесса

PMA

Physical Medium Attachment

Физическое подключение к среде

PMD

Physical layer Media Dependent

Физический уровень, зависящий от среды

Polarization Mode Dispersion

Поляризационный режим дисперсии

Post Mortem Dump

Распечатка после гибели процесса

PMMU

Paged Memory Management Unit

Блок управления страничной памятью

PMOS

Positive Channel Metal Oxide Semiconductor

Метал-оксидный транзистор с положительным каналом

PMS

Policy Management System

Система управления политикой

Physical Medium Sublayer

Субуровень, зависящий от физической среды

PNG

Portable Network Graphics

Формат графического файла

PNNI

Private Network-to-Network Interface

Частный сетевой интерфейс

Private Network Node Interface

Частный сетевой интерфейс узла

PNO

Public Network Operator

Общедоступный сетевой оператор

PNP

Plug And Play

Вставляй и работай

POC

Point Of Contact

Точка контакта

POET

Packet Over E3/T3

Передача паетов по каналам E3/T3

POH

Path Overhead

Маршрутный заголовок

POL

Problem Oriented Language

Язык, ориентированный на проблему

Procedure-Oriented Language

Процедурно-ориентированный язык

Provisioning Object Library

Объектная библиотека

POM

Provisioning Object Manager

Менеджер объектов

POP

Point Of Presence [MCI]

Точка присутствия

Pop from Stack

Извлечь из стека

Post Office Protocol

Почтовый протокол

POPA

Pop All Registers

Извлечь все регистры

POS

Point Of Sale

Точка торговли

Positive

Положительный

Programmable Object Select

Программируемый выбор объекта

POSIX

Portable Operating System Interface for Computer Environment

Переносимый интерфейс операционной среды для компьютерной среды (стандарт IEEE)

POST

Power On Self Test and initialization

Самотестирование питания и инициализация (PC)

POSTNET

Postal Numeric Encoding Technique

Техника кодирования почтовых номеров

POTS

Plain Old Telephone Service

Традиционные телефонные услуги

POWER

Performance Optimization with Enhanced RISC

Оптимизация рабочих характеристик для улучшенного RISC [IBM]

PPD

Postscript Printer Description

Описание постскриптовского принтера

Partial Packet Discard

Частичное отбрасывание пакетов (управление очередями)

PPDS

Personal Printer Data Stream

Поток данных персонального принтера [IBM]

PPI

PDH Physical Interface

Физический интерфейс сигнала PDH

PPM

Pages Per Minute

Число страниц в минуту

Part Per Million

Частей на миллион

Part Per Mile

Частей на тысячу

PPP

Point-to-Point Protocol

Протокол для связи точка-точка - традиционные телефонные услуги (RFC-1331-34; 77-78)

PPCS

Parallel Processing-Computer Server

Сервер параллельного процессора

PPL

Projection Pursuit Learning

 

PPS

Packets/pulses Per Second

Число пакетов/импульсов в секунду

Power Personal Systems

Персональные системы питания [IBM]

PPSN

Public Packet Switched Network

Общественная сеть с коммутацией пакетов

PPU

Pointer Processing Unit

Блок обработки указателей

PQ

Priority Queuing

Приоритетные очереди

PQFP

Plastic Quad Flatpack Package (chip housing)

Тип пластмассового корпуса микросхемы

PR

Pattern Recognition

Распознавание образов

PRACSA

Public Remote Access Computer Standards Association

Ассоциация по стандартам на удаленный общий доступ к ЭВМ

PRAM

Parallel Random-Access Machine

Машина с произвольным параллельным доступом

Parameter Random Access Memory

Параметрическая память с произвольным доступом

PRC

Primary Reference Clock

Первичный эталонный тактовый генератор

PREP

PowerPC Reference Platform

Эталонная платформа PowerPC

PRI

Primary Rate Interface

Интерфейс первичной скорости передачи (ISDN)

PRL

Process Resource List

Список ресурсов процесса

PRMD

PRivate Management Domain name

Частное имя управляющего домена [X.400]

PROFS

Professional Office System

Профессиональная офисная система (IBM)

PROLOG

Programming In Logic (Programming Language)

Название языка программирования

PROM

Programmable Read Only Memory

Программируемая память, рассчитанная только на чтение

PRR

Pulse Repetition Rate

Частота повторения импульсов

PRS

Primary Reference Source

Первичный эталонный источник

PS

Post Script

Формат текста

Permutation Symmetric

Симметричная перестановка

Planning and Scheduling

Планирование и составление графика

PSA

Program Structure Analyzer

Анализатор программной структуры (Borland Pascal)

Pascal Structure Analyzer

Анализатор структуры Паскаля

PSC

Print Server Command

Команда принт-сервера

Product Service Center

Сервисный центр

Protection Switch Count

Число защитных переключений

Picture Start Code

Стартовый код при передаче изображения

PSD

Protection Switch Duration

Длительность защитного переключения

PSDN

Packet-Switched Data Network

Сети с коммутацией информационных пакетов

PSD

Printer Sequence Description

Описание последовательности принтера

Power Spectral Density

Спектральная плотность

PSDN

Packet Switch Data Networks

Информационные сети с переключением пакетов

PSDS

Packet-Switched Data Service

Информационные услуги с коммутацией пакетов

PSE

Packet Switch Exchange

Коммутатор пакетов

PSF

Permanent Swap File

Постоянный файл подгрузки

PSH

Push flag

Флаг push (TCP-заголовок)

PSI

DEC's X.25 interface software

Программное обеспечение интерфейса X.25 DEC

Packet-Switch Interface

Интерфейс с переключением пакетов

PSID

PostScript Image Data

Графические данные PostScript

PSM

PDH-to-SDH Mediator

Устройство сопряжения PDH с SDH

PSN

Packet-Switch Network (Nodes)

Сеть с коммутацией пакетов

PSP

Program Segment Prefix

Префикс сегмента программы

Packet Switching Processor

Процессор переключения программы

Personal Software Products (group)

Персональный программный продукт [IBM]

PSPDN

Packet Switching Public Data Network

Общественная информационная сеть с пакетным переключением (X.25)

P-SRAM

Pseudo-Static Random Access Memory

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

PSS

Packet Switch Stream

Поток с переключением пакетов

Physical Signaling Sublayer

Физический сигнальный субуровень

Private Signaling System

Частная сигнальная система (ISDN)

PSTN

Public Switched Telephone Network

Общественная коммутируемая телефонная сеть

PST

Pacific Standard Time

Тихоокеанское стандартное время

PSW

Program Status Word

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

PT

Payload Type

Тип поля данных

PTD

Parallel Transfer Disk Drive

Диск-драйв с параллельной передачей

PTI

Payload Type Identifier

Идентификатор тип данных в пакете (ATM)

PTO

Public Telecommunication Operator (e.g. PTT)

Оператор общественных телекоммуникаций (например, PTT)

PTNX

Private Telecom Network Exchange

Местная цифровая АТС (ISDN)

PTSE

PNNI Topology State Element

Элемент состояния топологии PNNI

PTSЗ

PNNI Topology State Packet

Пакет состояния топологии PNNI

PTT

Post, Telephone, Telegraph service

Почта, телефон, телеграф (министерство связи)

PU

Physical Unit

Физический блок

PUP

PARC Universal Packet

Универсальный пакет PARC (Xerox)

PUS

Processor Upgrade Socket

Панель для замены процессора

Processor Upgrade Socket

Соединитель актуализации процессора

PVC

Permanent Virtual Circuit (Connection)

Постоянная виртуальная схема (соединение)

Polyvinyl Chloride

Поливинил хлорид

PVM

Parallel Virtual Machine

Параллельная виртуальная машина

Pass-through Virtual Machine (protocol)

Протокол виртуальной машины [IBM]

PVP

Packet Video Protocol

Пакетный видео-протокол

Permanent Virtual Path

Постоянный виртуальный маршрут

PW

Pass Word

Слово-пароль

Pulse Width

Ширина импульса

PWB

Printed Wiring Board

Карта с печатной разводкой проводов

Programmer's Workbench

Рабочая станция программиста [Microsoft]

PWD

Print Working Directory

Отобразить рабочий каталог [Unix]

PWSCS

Programmable Workstation Communication Services

Программируемая рабочая станция для коммуникационных услуг [IBM]


Previous: 10.10.15 [O]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.17 [Q]


previous up down next index index
Previous: 10.10.16 [P]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.18 [R]

10.10.17 [Q]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

Q.93B

ITU-T specification for signaling to establish, maintain, and clear BISDN network connections. An evolution of ITU-T recommendation Q.931

Спецификация сигналов ITU-T для установления и поддержки BISDN-соединений. Эволюция рекомендаций Q.931

Q.700

Introduction to CCITT SS No. 7

Введение в сигнальную систему N 7

Q.701

The message transfer part of Signaling System N7

Передача сообщений в сигнальной системе N 7

Q.711

Signaling connection control part of Signaling System N7

Управление связями в сигнальной системе N7

Q.721

Telephone user part of Signaling System N7

Пользовательская телефонная часть сигнальной системы N7

Q.761

The ISDN user part of Signaling System N7

Пользовательская часть ISDN сигнальной системы N7

Q.920/921

ITU-T specifications for the ISDN UNI data link layer

Спецификация ITU-T для связного уровня ISDN

Q.922A

ITU-T specification for Frame Relay encapsulation

Спецификация ITU-T инкапсуляции в Frame Relay

Q.931

ITU-T specification for signaling to establish, maintain, and clear ISDN network connections

Спецификация сигналов ITU-T для установления и поддержки ISDN-соединений

Q.2931

ITU-T specification, based on Q.931, for establishing, maintaining, and clearing network connections at the B-ISDN user-network interface.

Спецификация ITU-T, базирующаяся на Q.931, для установления и поддержки сетевых соединений для широкополосных сетей ISDN

QA

Q-Adapter

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

Q&A

Question and Answer

Вопрос-ответ; запрос-отклик

QAF

Q-Adapter Function

Функция Q-адаптера

QAM

Quadratural-Amplitude Modulation

Квадратурно-амплитудная модуляция (1 импульс = 4 бит)

Queued Access Method

Метод доступа с очередями

QASK

Quadrature Amplitude Shift Keying

Квадратурная амплитудная модуляция

QBE

Query By Example

Запрос по образцу

QBF

Query by Form

Запрос по форме

QDOS

Quick and Dirty Operating System

Грубая операционная система

QEMM

Quarterdeck Expanded Memory Manager [Quarterdeck Corp.]

Менеджер расширенной памяти комапании Quarterdeck

QF

Quality Factor

Добротность

QFA

Quick File Access

Быстрый доступ к файлам

QIC

Quality Information Using Cycle Time [Hewlett-Packard]

 

Quarter-Inch Cartridge

Четверть дюймовый картридж

QICDS

Quarter Inch Cartridge Drive Standards

Стандарты на драйв с четвертьдюймовым картриджем

QFP

Quad Flat Pack (Multiplan)

 

QFT

Queued File Transfer

Поочередная пересылка файлов (UUCP)

QLLC

Qualified Logical Link Control

Сертифицированное управление логической связью

QMF

Quadratural Mirror Filter

Квадратурный зеркальный фильтр

QOS

Quality Of Service

Качество обслуживания (ISO 8348)

QPPB

QoS Policy Propagation using BGP

Распространение полоитики QoS c помощью протокола маршрутизации BGP

QPSK

Quadrature Phase Shift Keying

Квадратурная фазовая модуляция

QPSX

Queued-Packet Distributed-Switch

Распределенный переключатель для пакетов из очереди

QRA

Quality-Reliability Assurance

Гарантия качества и надежности

QRSS

Quasi-Random Signal Sequence

Квази-случайная сигнальная последовательность

QSIG

Q (point of the ISDN model) Signaling

Сигнальная точка Q (модель ISDN)

QT

Queueing Theory

Теория массового обслуживания

QTAM

Queued Telecommunication Access Method

Телекоммуникационный метод доступа с очередями

QWP

Query With Permition

Запрос с разрешением

Previous: 10.10.16 [P]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.18 [R]


previous up down next index index
Previous: 10.10.17 [Q]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.19 [S]

10.10.18 [R]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

RA

Return Authorization

Обратная идентификация

RAAM

Recursive Auto Associative Memory

Рекурсивная автоассоциативная память

RACE

Research on Advanced Communication in Europe

Исследования в области продвинутых коммуникаций в Европе

RACF

Resource Access Control Facility

Система управления доступом к ресурсам

RAD

Rapid Application Development

Быстрая разработка приложения

RADIUS

Remote Dial-In User Service

Удаленный доступ пользователей через телефонные линии

RAG

Row Address Generator

Генератор адреса строки

RAID

Redundant Array of Intelligent/Independent Drives

Избыточный блок интеллектуальных/независимых драйвов (с резервированием)

Redundant Arrays of Independent/Inexpensive Disks

Избыточный набор независимых/недорогих дисков

RAL

Rutherford Appleton Laboratory in UK

 

RALU

Register Arithmetic Logic Unit

Регистровое арифметико-логическое устройство

RAM

Random Access Memory

Память с произвольным доступом

RAMDAC

Random Access Memory Digital-to-Analog Converter [Sierra]

Цифро-аналоговый преобразователь с произвольным доступом к памяти

RAND

Random

Случайный

RANN

Resource Allocation Neural Network

Нейронная сеть для поиска ресурсов

RAP

Rapid Application Prototyping

Быстрое макетирование приложения

Router-Access Protocol

Портокол доступа к маршрутизатору

RARE

European Association of Research Networks (Reseaux Associes pour la Recherche Europeenne)

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

RARP

Reverse Address Resolution Protocol

Протокол обратного адресного разрешения (определение IP-адреса по МАС; RFC-903)

RAS

Random Access Storage

Память с произвольной записью

Remote Access Service

Служба удаленного доступа

Reliability, Availability and Serviceability

Надежность, доступность и обслуживаемость

Registration, Admission, and Status protocol

Протокол регистрации, разрешения и состояния

Row Address Select

Выбор адреса строки

RASAPI

Remote Access Service Application Programming Interface [Microsoft]

Удаленный доступ к услугам интерфейса прикладного программирования

RAS

Row Address Strobe

Строб адреса строки

RATP

Reliable Asynchronous Transfer Protocol

Надежный асинхронный протокол передачи данных (RFC-916)

RB

Right Button (of 2 or 3 button Mouse)

Правая кнопка (2-х или 3-х кнопочной мышки)

RBBS

Remote Bulletin Board System

Система удаленной электронной доски объявлений

RBF

Radial Basis Function network

Сеть с радиальной топологией

RBOC

Regional Bell Operating Company

Региональная компания обслуживания сети Bell

RBS

Regional Boundary System

Региональная пограничная система (Ebone)

RC

Remote Control

Дистанционное управление

RCA

Root Certificate Authority

Базовый (центральный) сертификационный центр (протокол SET)

RCB

Reception Control Buffer

Буфер управления приемом

RCC

Recurrent Cascade Correlation (SL)

Рекурсивная каскадная корреляция

Routing Control Center

Центр управления маршрутизацией

Radio Common Carrier

Общая радио-несущая

RCL

Rotate Carry Left

Циклический сдвиг влево с переносом

RCM

Radial Contour Model

Модель с радиальным контуром (сотовые сети)

RCO

Representative Calculating Operation

Типичная вычислительная операция

RCP

Remote Copy [Internet]

Удаленное копирование

Routing and Control Processor

Процессор управления и маршрутизации

Restore Cursor Position

Восстановить положение курсора

RCR

Rotate Carry Right

Циклический сдвиг вправо с переносом

RCS

Records Communications Switching System

Переключающая система передачи записей

Revision Control System

Система управления пересмотром [Unix]

RD

Receive Data

Получить данные

Request Disconnect

Отключение запроса

Remove Directory

Удалить каталог

R&D

Research and Development

Научно-исследовательская работа

RDA

Remote Data Access

Доступ к удаленным данным

Remote Database Access

Доступ к удаленной базе данных

RDB

Receive Data Buffer

Входной буфер данных

Relational Database

Реляционная база данных

RDBMS

Relational Data Base Management System

Система управления реляционной базой данных

RDC

Remote Data Collection

Дистанционный сбор информации

RDCLK

Received Timing Clock

Такты синхронизации приема

RDD

Requirements Driven Design

Конструирование согласно требованиям

RDF

Resource Description Language

Язык описания ресурса (HTML)

RDI

Remote Defect Indication

Удаленное обнаружение неисправностей

RDN

Relative Distinguished name

Относительное уникальное имя

RDP

Reliable Data Protocol

Надежный информационный протокол (RFC-1151)

RDSR

Receiver Data Service Request

Запрос приемника на информационное обслуживание

READI

Rights for the Electronic Access to and Dissemination of Information

Права для электронного доступа и распространения информации

REGAL

Rigid Epoxy Glass Acrylic Laminate

Твердое стекло-акриловое эпоксидное покрытие

REJ

Reject

Отказ

REL

Release Message

Сообщение, посылаемое в любом направлении и оповещающее о том, что система свободна, готова перейти в пассивное состояние при получении сообщения о завершении процедуры Release

RELARN

Russian Electronic Academic Research Network

Российская академическая исследовательская сеть

RELSECT

Relative Sector

Относительный номер сектора

REM

Remark

Замечание

Remote

Удаленный

Ring Error Monitor

Кольцевой монитор ошибок

REN

Rename

Переименовать

REP

Repeat

Повторить

REPE

Repeat while Equal

Повторять пока равно

REPNE

Repeat while Not Equal

Повторять пока не равно

REPNZ

Repeat while Not Zero

Повторять пока не нуль

REPZ

Repeat while Zero

Повторять пока нуль

REQ

Request

Запрос

RER

Residual Error Rate

Остаточная частота ошибок

RES

Remote Execution Service

Служба удаленного исполнения

Reset

Сброс

Resolution

Разрешение

.RES

Resource

Расширение имени ресурсного файла

RESQ

RESearch Queuing

Программный пакет (IBM) для моделирования

RET

Resolution Enhancement Technology

Технология улучшения разрешения [HP]

Return

Возврат

REX

Relocatable Executable

Переносимый исполняемый

REXECD

Remote EXEC Daemon

Демон удаленного исполнения

REXX

Restructured Extended Executor

Язык программирования [IBM]

RF

Radio Frequency

Радио частота

RFA

Request for Applications

Запрос на получение гранта

RFC

Request for Comments

Официальные документы Интернет

RFI

Radio Frequency Interference

Радиочастотная интерференция

Request for Information

Информационный запрос

RFNM

Ready For Next Message (from PSN)

Готов к следующему сообщению

RFP

Request for Proposal

Запрос предложение

RFQ

Request for Quote

Запрос квоты

RFS

Remote File Sharing

Совместное использование удаленного файла

Remote File System

Удаленная файловая система

RFT

Revisable Form Text

Текст с переменным форматом

Rich Format Text

Обогащенный формат текста

RFU

Reserved For Future Use

Зарезервировано для будущего использования

RG

Randge

Диапазон

Register

Регистр

RGB

Red/Green/Blue (video standard)

Стандартное представление данных при выводе на цветной дисплей

RGIN

Russian Government Internet Network

Государственный домен сети Интернет в России

RHC

Rigional Holding Company

Региональная холдинговая компания

RHW

Right Half Word

Правое полуслово

RI

Referential Integrity

 

Ring Indicator

Кольцевой индикатор

Reliability Index

Показатель надежности

RIB

Routing Information Base

Маршрутная база данных (протокол BGP)

RIF

Routing Information Field

Поле маршрутной информации

Reliability Improvment Factor

Коэффициент повышения надежности

RII

Routing Information Identifier

Идентификатор маршрутной информации

RIFF

Resource Interchange File Format

Формат файла ресурсного обмена [Microsoft]

RIM

Remote Installation and Maintenance

Удаленная загрузка и исполнение [Microsoft]

Request Initialization Mode

Режим инициализации запроса

RIME

RelayNet International Message Exchange

Международный обмен сообщениями RelayNet

RIN

Relative Intensity Noise

Относительная интенсивность шума

RIO

RISC Input/Output

Ввод/вывод RISC

RIP

Raster Image Processor

Процессор растрового изображения

Remote Imaging Protocol

Протокол удаленного отображения

Routing Information Protocol [Novell/Internet]

Протокол для передачи маршрутной информации (внутренний)

RIPE

Reseaux IP Europeenne

Европейские IP-сети

RISC

Reduced Instruction Set Computer

ЭВМ с сокращенным набором инструкций

RIU

Ring Interface Unit

Блок кольцевого интерфейса (Token ring, 802.4)

RJ-11

Standard 4-wire connector for phone lines

Стандартный 4-проводный разъем для телефонных линий

RJE

Remote Job Entry

Запуск удаленной задачи (RFC-407)

RJF

Remote Job Facility

Система выполнения удаленных задач

RLC

Release Complete Message

Сообщение, посылаемое в ответ на REL

RLE

Run Length Encoded

Простейший метод сжатия информации, учитывающие повторяющиеся последовательности импульсов

RLL

Run Length Limited (disk coding)

Система кодирования данных на диске

RLM

Redundant Link Manager

Менеджер избыточных связей

RLN

Remote LAN Node

Удаленный узел локальной сети [DCA]

RLOGIN

Remote Login

Удаленный вход в систему

RLP

Resource Location Protocol (RFC887)

Протокол поиска ресурсов

RLS

Recursive Least Square

Рекурсивный метод наименьших квадратов

RLSD

Received Line Signal Detected

Обнаружен сигнал на входе

RLSI

Ridiculously Large-Scale Integration

Нелепо большая степень интеграции

RM

Reset Mode

Режим сброса

Regional Manager

Региональный менеджер (SDH)

Resource Management

Управление ресурсами

RMA

Return Material Authorization

 

Return to Manufacturer Authorization

Возврат к авторизации производителя

RMDIR

Remove Directory

Ликвидировать каталог

RMF

Remote Management Facility (NetWare)

Устройство удаленного управления

RMON

Remote Monitor/Monitoring

Удаленный монитор/мониторирование

RMS

Record Management Services

Услуги управления записями

Root Mean Square

Средне-квадратичное значение

RMSE

Root-Mean-Squere Error

Средне-квадратичная ошибка

RN

Read News

Чтение новостей [Internet]

RND

Random

Случайный

RNG

Random Number Generator

Генератор случайных чисел

RNN

Recurrent Neural Network

Рекурентная нейронная сеть

RNR

Receiver Not Ready

Приемник не готов

R-O

Read Only

Только для чтения

ROER

Remote Operation Error APDU

Ошибка удаленной операции APDU

ROLC

Routing Over Large Clouds

Маршрутизация через большие области (облака)

ROM

Read Only Memory

Память, рассчитанная только на чтение

RORJ

Remote Operation Reject APDU

Отклонение удаленной операции APDU

ROSE

Remote Operations Service Element

Протокол поддержки удаленных услуг (ISDN)

ROT

Rate of Turn

Скорость вращения

ROWS

Read Often, Write Seldom

Чтение часто, запись редко (диски на основе флэш-памяти EPROM)

RP

Rendezvous Point

Точка встречи (промежуточный маршрутизатор в протоколе PIM)

Reliability Program

Программа обеспечения надежности

Route Processor

Процессор маршрута (CISCO)

RPC

Remote Procedure Call

Вызов удаленной процедуры (RFC-1050, 1057)

RPC

Real Procedure Call

Вызов реальной процедуры

Remote Procedure Call

Удаленный вызов процедуры

RPF

Reverse Path Forwarding

Переадресация по обратному маршруту (мультикастинг)

RPG

Report Program Generator

Название языка программирования

Research Project Grant

Грант на исследовательский проект

RPI

Rockwell Protocol Interface

Интерфейс протокола Rockwell

RPL

Resident Programming Language

Резидентный язык программирования

Requested Privilege Level

Запрашиваемый уровень приоритета

RPM

Revolutions per Minute

Число оборотов в минуту

RPQ

Request for Price Quotation

Запрос о цене

RPPROM

Reprogrammable PROM

Перепрограммируемый PROM

RPRINTER

Remote Printer [NetWare]

Удаленный принтер

RPS

Revolutions per Second

Число оборотов в секунду

RPSL

Routing Policy Specification Language

Язык спецификации маршрутной политики RFC-2622)

RPT

Repeat

Повторить

RQBE

Relational Query By Example

Реляционный запрос по образцу [Fox Pro]

RR

Resource Record

Ресурсный рекорд

Real Reality

Истинная реальность

Relative Rate

Относительная загрузка

Repetition Rate

Частота повторения

RRAS

Routing and Remote Access Service

Маршрутизация и обслуживание удаленного доступа

RS Record Separator Сепаратор рекордов
Regenerator Section Регенераторная секция
Remote Station Удаленная станция
Request to Send Запрос посылки

RSA

Rivest-Shamir-Adelman

Алгоритм шифрования информации с использованием двух ключей

RSCS

Remote Spooling Communications System

Коммуникационная система с удаленной буферизацией

RSH

Remote Shell

Удаленное ядро

RSL

Request-and-Status Link

Канал запроса и статуса

Requirement Statement Language

Язык формулирования требований

RSM

Route Switch Module

Модуль переключения маршрута

RSN

Release Sequence Number

Номер версии

RSOH

Regenerator Section Overhead

Заголовок регенераторной секции

RSP

Required Space Character

Необходимый символ пробела

Regional Service Provider

Региональный сервис-провайдер

Route/Switch Processor

Процессор маршрутов

RSPF

Radio Shortest Path First Routing Protocol

Радио протокол маршрутизации, выбирающий наикратчайший маршрут

RSRB

Remote Source-Remote Bridging

Система локальной маршрутизации

RST ReSeT flag Флаг сброса (заголовок TCP)
Regenerator Section Termination Начало/конец регенераторной секции
Reset Сброс

Restart

Повторный запуск

RSTS

Real Time Resource Sharing Executive

Система разделения ресурсов в реальном времени

RS-232

V.24 specification

Спецификация V.24, популярный последовательный интерфейс

RS-422

balanced implementation of RS449 for high speed

Симметричная реализация RS-449 для высоких скоростей передачи

RS-432

unbalanced implementation of RS-449 for RS-232 compatibility

Несимметричная реализация RS-449 для совместимости с RS-232

RS-449 up to 2Mbps version of RS-232C Версия RS-232C на скорости вплоть до 2 Мб/с

RSUP

Reliable SAP Update Protocol

Надежный протокол актуализации для SAP

RSVP

Resource ReSerVation Protocol

Протокол резервирования ресурсов

RT Real Time Истинное время
RISC Technology RISC-технология
Run Time Время работы
R/T Receive/Transmit Получить/отправить
RTA RunTime Analysis Анализ данных в процессе работы
RTAM Remote Terminal Access Method Метод доступа через удаленный терминал
RTC Real Time Clock Часы реального времени
RTCOPY Remote Tape COPY Удаленное копирование ленты
RTCP Real-Time Control Protocol Управляющий протокол реального времени (часть RTP)

RTDM

Real-Time Data Migration

Перенос данных в реальном масштабе времени

RTEE

Real Time Engineering Environment

Инженерная среда реального времени

RTEL

Reverse Telnet

Реверсивный Telnet [Internet]

RTELNET

Remote Telnet Service

Служба удаленного доступа (RFC-818)

RTF

Rich Text Format (WORD)

RTF-формат WORD

RTFM

Read The Fantastic Manual

Предложение, когда кто-то задает простой или банальный вопрос

RTL

Register Transfer Language

 

Resistor Transistor Logic

Резистор-транзисторная логика

Right-To-Left

Справа налево

Run Time Library

Рабочая библиотека

RTM

Response Time Monitor

Монитор времени отклика

RunTime Manager

Менеджер исполнения [Borland]

RTMP

Routing Table Management Protocol (Apple Talk)

Протокол работы с маршрутными таблицами

RTO

Retranslating Time Out

Значение времени тайм-аута для ретрансмиссии сегмента (TCP)

RTOS

Real-Time Operating System

Операционная система реального времени

RTP

Real-Time Protocol

Протокол для пересылки информации в реальном масштабе времени

Reliable Transport Protocol

Надежный транспортный протокол (доставка пакетов IGRP)

Rapid Transport Protocol

Быстродействующий транспортный протокол

Routing Table Protocol

Протокол маршрутных таблиц

Real-Time Processing

Обработка в реальном масштабе времени

RTRL

Real Time Recurrent Learning

Рекуррентное обучение в реальном времени

RTS

Remote Takeover System

Удаленная система управления

Request To Send (RS-232-C signal)

Запрос посылки (RS-232 управляющий сигнал)

Reactive Tabu Search

 

RTSC

Read The Source Code

Читай исходный текст (программы)

RTSP

Real Time Streaming Protocol

Поточный протокол реального времени

RTT

Round Trip Transmission (delay in network)

Циклическая задержка в сети

Round Trip Time (задержка в сети)

Время распространения пакета до адресата и обратно

RTTY

Radio Teletypewriter (Communications)

Радиотелетайп

RTU

Remote Terminal Unit

Удаленный терминал

RTV

Real Time Video

Видео реального времени

RU

Request/response Unit

Блок запросов/откликов

RUB

Router Hub

Блок маршрутизатора

RUDL

Reliable User Data Protocol

Надежный информационный протокол пользователя

RUIP

Remote User Information Program

Программа для получения информации об удаленном пользователе (напр., Finger)

RUNNet

Russian UNiversity's Network

Сеть российских университетов

RVA

Relative Virtual Address

Относительный виртуальный адрес

RVI

Reverse Interrupt

Обратное прерывание

Required Visual Inspection

Необходимый внешний осмотр

R/W

Read/Write

Чтение/запись

RWM

Read-Write Memory

Память с возможностью чтения и записи

RX

Receiver

Приемник

RXD

Received Data

Полученные данные

RZ

Return to Zero

Двуполярный код с возвращением к нулю


Previous: 10.10.17 [Q]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.19 [S]


previous up down next index index
Previous: 10.10.18 [R]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.20 [T]

10.10.19 [S]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

S

Space

Пробел

SA

Simulated Annealing

Симулированный отжиг

SAA

System Application Architecture

Архитектура системного приложения (IBM)

Standard Application Architecture

Архитектура стандартного приложения

S-ALL

Signaling AAL

Уровень адаптации ATM для сигнальных целей

SAB

Service Access Point

Точка доступа

SABME

Set Asynchronous Balanced Mode Extended

Установка расширенного асинхронного сбалансированного режима

SAC

Single Access Control

Управление одноканальным доступом

Single Attach Conсentrator

Концентратор с одной связью (FDDI или СDDI)

SACK

Selective ACKnowelement

Селективный отклик

SADL

Synchronous Data Link Control [Racal-Vadic]

Управление синхронным информационным каналом

SAF

Store And Forward

Запоминание и переадресация

SAFER

Secure And Fast Encryption Routine

Надежная и быстрая программа шифрования (название алгоритма)

SAG

SQL Access Group

Группа доступа SQL

SAH

Start of Header

Начало заголовка

SAINT

Symbolic Automatic Integrator

Символический автоматический интегратор

SAL

Shift Arithmetic Left

Арифметический сдвиг влево

SAM

Subsequent Address Message

Посылается вслед за IAM, когда необходимо передать дополнительную информацию о предстоящей сессии

Serial Access Memory

Память с последовательным доступом

Sequential Access Method

Метод последовательного доступа

SAN

Storage Area Network

Сети хранения данных

SAP

Second Audio Program Protocol

Второй аудио программный протокол

Service Access Point (Application)

Точка доступа к услугам (приложению) [DEC]

Service Advertising Protocol

Протокол оповещения об услугах (Novell)

Symbolic Assembly Program

Символьная ассемблерная программа

Symbolic Address Program

Программа в символьных адресах

SAPI

Service Access Point Identifier

Идентификатор точки доступа

SAR

Segmentation And Reassemble

Сегментация и сборка

Shift Arithmetic Right

Арифметический сдвиг вправо

Successive Approximation Register

Регистр последовательных приближений

SARM

Set Asynchronous Regime Mode

Установка асинхронного режима (X.25)

SAS

Sales Accounting System

Система акоунтингов продаж

Single Audio System

Одиночная аудиосистема

Statically Assigned Socket

Статистически подключаемый соединитель

Single Attachment Station

Станции с одинарной связью (FDDI)

SASE

Special Application Service Elements (ISO)

Сервисные элементы специального назначения

.SAV

Saved

Расширения имени файла спасения

SAVDM

Single Application VDM

 

SAW

Session AWareness

 

SB

Sound Board

Звуковая карта

SBA

Scene Balance Algorithms [Kodak]

Алгоритм балансировки изображения

SBB

Subtract With Borrow

Вычитание с заимствованием

SBCCS

Single Byte Command Code Sets

Наборы кодов однобайтовых команд

SBNM

Standards-Based Network Management

Сетевое управление базирующееся на стандартах

SBC

Single-Board Computer

Одноплатный компьютер

SBCS

Single-Byte Character Set

Однобайтовый набор символов

SC

System Code (MCB)

Системная программа

Subscriber Connector

Абонентский разъем

Supervisory Control

Диспетчерское управление

SCA

Serial Communication Interface

Последовательный коммуникационный интерфейс

SCAS

Scan String

Строка сканирования

SCB

Subsystem Control Block [IBM]

Управляющий блок субсистемы

SCC

Specialized Common Carrier

Специализированный общий носитель

Serial Communications Controllers

Последовательные коммуникационные контроллеры

Serial Controller Chip

Чип последовательного контроллера

Synchronous Channel Check

Проверка синхронного канала [IBM]

SCCP

Signaling Connection Control Part

Управляющая часть сигнального соединения (Q.711)

SCCS

Source Code Control System

Система управления исходным текстом

SCD

Standard Color Display

Стандартный цветной дисплей

SCF

System Control Facility

Устройство управления системы

SCG

SNMP/CMIP Gateway

Внешний порт SNMP/CMIP

SCI

Scalable Coherent Interface

Масштабируемый когерентный интерфейс

Serial-port Communication Interface

Последовательный порт коммуникационного интерфейса

SIP Connection Interface

Интерфейс связи с SIU

Switch Communication Interface

Коммуникационный интерфейс переключателя

SCP

Session (service) Control Protocol

Протокол управления сессией (услугами)

SCM

Software Configuration Management

Управление конфигурацией программного обеспечения

SCO

Santa Cruz Operation

Название компании - разработчика программ

SCOPE

Simple Communications Programming Environment

Простая среда для коммуникационного программирования [Hayes]

SCP

Signal Control Point

Точка контроля сигнала

Save Cursor Position

Спасти положения курсора

Subsystem Control Port

Управляющий порт субсистемы

System Control Program

Программа управления системы

SCR

Silicon Controlled Rectifier

Кремниевый управляемый выпрямитель

Sustainable Cell Rate

Поддерживаемая частота следования ячеек (ATM)

SCRI

SuperComputations Research Institute at Florida State University

Исследовательский институт суперЭВМ Государственного университета Флориды

SCRN

Screen

Экран (дисплея)

SCS

Scientific Computing Stuff in OER

Научный компьютерный персонал OER

SCSA

Signal Computing System Architecture [Dialogic]

Архитектура системы обработки сигнала

SCSI

Small Computer System Interface

Системный интерфейс малых ЭВМ

SCTE

Serial Clock Transmit External

Внешний синхронизующий сигнал

SD

System Data (MCB)

Системные данные

Signal Degrade

Ухудшение качества сигнала

Standard Diviation

Стандартное отклонение

SDA

Software Disk Array

Блок программных дисков

Source Data Automation

Автоматизация источника информации

System Display Architecture

Архитектура системного дисплея [Digital]

SDB

Symbolic Debugger

Символьный отладчик [Unix]

SDC

Synchronous Data Compression

Синхронное сжатие информации

SDE

Secure Data Exchange (VLAN)

Безопасный информационный обмен

SDF

Space Delimited File

Файл с пробелами в качестве разделителя

Space Delimited Format

Формат с разделителями в виде пробелов

.SDF

Standard Data Format

Расширение имени файла стандартного информационного формата

SDH

Synchronous (Signaling) Digital Hierarchy

Стандарт на семейство сверхскоростных магистралей

SDI

Selective Dissemination of Information

Выборочное распространение информации

SDK

Software Development Kit

Средство разработки программ (MS WINDOWS)

SDL

Supplemental Driver's Library

Дополнительная библиотека драйверов

SDLC

Synchronous Dial-up Connection (data link communication)

Синхронный коммутируемый канал связи

Synchronous Data Link Control

Управление синхронным информационным каналом

SDM

Sparse Distributed associative Memory

Рассредоточенная ассоциативная память (USL)

Synchronous Digital Multiplexer

Синхронный цифровой мультиплексор

Subrate Data Multiplexing

Мультиплексирование данных

SDN

Software Defined Network

Сеть, определяемая программным обеспечением [AT&T]

SDNS

Secure Data Network Service

Безопасная сетевая информационная услуга

SDR

Streaming Data Request

Запрос данных (при установлении связи)

SDS

Sysops Distribution System

Система распределения системных операций

Storage Domain Server

Доменный сервер памяти

SDSC

San Diego Supercomputer Center

Центр суперЭВМ Сан Диего

SDSL

Single line Digital Subscriber Line

Стандарт на широкополосный кабельный модем, работающий на одинарную скрученную пару

SD_STB

Streaming Data Strobe [IBM]

Строб данных при поточной передаче

SDU

Service Data Unit

Сервисный блок данных

SDXC

Synchronous Digital Cross-Connect system

Цифровая система синхронной коммутации SDH-потоков

SEA

Standard Extended Attribute [OS/2]

Стандартный расширенный атрибут

.SEA

Self Extracting Archive

Расширение имени файла самоизвлекаемого архива [Macintosh]

SEAC

Name of first computer to use transistors, built by Standard Eastern Automating Computing

Имя первой ЭВМ, использовавшей транзисторы и созданной фирмой SEAC

SEAL

Simple and Efficient AAL

Простой и эффективный AAL (ATM адаптационный уровень)

SEC

Single Error Correction

Исправление одиночной ошибки

SECAM

Sequentiel Couleur Avec Memoire (Sequential Color With Memory)

Система цветного телевидения (Франция)

SECB

Severely Errored Cell Block

Блок ячеек с серьезными ошибками

SED

Stream Editor

Редактор потока

SEG

Segment

Сегмент

SEL

Select

Выбрать

SEM

Scanning Electron Microscope

Сканирующий электронный микроскоп

Standard Electronic Module

Стандартный электронный модуль

SEMF

Synchronous Equipment Management Function

Функция управления синхронным оборудованием

SER

Serial

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

SERDES

Serializer/Deserializer

Преобразователь из последовательного кода в параллельный и наоборот

SES

Severely Errored Second

Секунда с серьезными ошибками

Scientific and Engineering Software

Программные средства для науки и техники

SESR

Severely Errored Second Ratio

Коэффициент ошибок по секундам с серьезными ошибками

SET

Software Engineering Technology

Программно-инженерная технология

Secure Electronic Transaction

Безопасные электронные операции (магнитные кредитные карты)

.SET

Driver Set

Расширение имени установочного файла драйвера [Lotus 1-2-3] [LDC]

Image Settings

Расширение имени файла, задающего параметры изображения [Paradox]

SERPI

Synchronous Equipment Timing Physical Interface

Физический интерфейс синхронизации синхронного оборудования

SET

Secure Electronic Transactions

Безопасные электронные операции (протокол, разработанный VISA, Mastercard, Netscape и Microsoft)

SETS

Synchronous Equipment Timing Source

Синхронизирующий источник синхронного оборудования

SEU

Smallest Executable Unit

Наименьший исполняемый блок

SF

Sign Flag

Флаг знака

SubFrame

Субкадр

Safety Factor

Коэффициент безопасности

SFBI

Shared Frame Buffer Interconnect

Организация канала с совместным использованием буфера кадров

SFD

Start Frame Delimiter

Начальный разграничитель кадров

SFDU

Standard Formatted Data Units

Стандартно форматированные блоки данных

SFQL

Structured Full-text Query Language

Структурированный полнотекстовый язык запросов

SFRS

Structured Forms Reference Set

Эталонный набор структурных форм

SFS

Start Frame Sequence

Начало кадра

SFT

System Fault Tolerance

Устойчивость к сбоям системы

SFTP

Simple File Transfer Protocol

Простой протокол передачи файлов (RFC-913)

SFVN

SecureFast Virtual Network

Виртуальная сеть с быстродействующей защитой

SFX

Sound Effect(s)

Звуковые эффекты

Self Extracting Zip Archive

Само разворачиваемый архивный файл

SGCP

Simple Gateway Control Protocol

Простой протокол управления шлюзами (маршрутизация в ATM)

SGEN

Signal Generator

Сигнальный генератор

System Generator

Системный генератор

SGDT

Store Global Descriptor Table

Запоминание таблицы глобальных описателей

SGI

Silicon Graphics, Incorporated

Название компании

SGML

Standard Generalized Markup Language

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

SGMP

Simple Gateway Monitoring Protocol

Простой протокол мониторирования маршрутизатора (RFC1028)

SGR

Set Graphics Rendition

Задать режим графического отображения

SGRAM

Synchronous Graphics RAM

Синхронная графическая память

S/H

Sample and Hold

Стробирование и запоминание

SHAR

Shell Archive

Архив оболочки

SHL

Shift Logical Left

Логический сдвиг влево

SHR

Shift Logical Right

Логический сдвиг вправо

SHS

Secure Hash Standard

Стандарт для хэш-функций (безопасность передачи сообщений)

SI

Source Index

Исходный индекс

System Information

Системная информация

Sampling Interval

Период стробирования (выборки)

SID

Station/System/service Identification

Идентификация станции/системы/услуги [AT&T]

Security IDentifier

Идентификатор безопасности

Symbolic Interactive Debugger

Интерактивный символьный отладчик

SIDT

Store Interrupt Descriptor Table

Таблица для запоминания описателей прерывания

SIG

Special Interest Group

Специальная заинтересованная группа

SIGCAT

Special Interest Group on CD-ROM Applications and Technology

Специальная группа по применению CD-ROM и технологии

SIGMA

System for Interactive Graphical Mathematical Applications

Система интерактивных графических математических приложений

SIM

Simulator

Симулятор

Switch In Module

Модуль включения

Set Initialization Mode

Установить режим инициализации

SIMD

Single Instruction Multiple Data

Одна команда - много данных (тип процессора)

SIMM

Single In line Memory Module

Модуль памяти с линейным разъемом

SIM/RIM

Set Initialization Mode/Request Initialization Mode

Установка режима инициализации (X.23; HDLC)

SIMULA

Simulation language

Язык моделирования

SIO

Serial Input/Output (communications driver)

Последовательный ввод/вывод (коммуникационный драйвер)

SIP

Single In line Package

Модуль с односторонней контактной группой

Simple Internet Protocol

Простой сетевой протокол

Serial Interface Processor

Процессор последовательного интерфейса

Session Initiation Protocol

Протокол инициализации сессии

SMDS Interface Protocol

Протокол интерфейса SMDS

SIPO

Serial In, Parallel Out

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

SIPP

Single In-line Pin Package

Корпус ИС с односторонним разъемом

Simple Internet Protocol Plus

Простой протокол Интернет (IPv6)

SIR

Serial Infrared [Hewlett-Packard]

Последовательный инфракрасный

Sustained Information Rate

Поддерживаемая скорость обмена данными

SISD

Serial In/Serial Out

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

SI/SO

Single Instruction, Multiple Data

Один поток команд и несколько потоков данных

Shift In/Shift Out

Сдвиг на входе/сдвиг на выходе

SIT

Special Information Tones

Специальный информационные тоны

.SIT

Stuff-It

Расширение имени сжатого файла [Macintosh]

SIU

Synchronous Interface Unit

Блок синхронного интерфейса

SKIP

Simple Key Management of Internet

Простой протокол управления ключами в Интернет

SL

Supervised Learning

Управляемое обучение

Synchronous Line link

Синхронный канал (SDH)

SLA

Service Level Agreement

Соглашение об уровне обслуживания

SLC

Signaling link code

Код сигнального канала

SLDT

Store Local Descriptor Table

Запоминание локальной таблицы дескрипторов

SLIP

Serial Line Interface Protocol

Протокол интерфейса последовательного канала (IP)

Serial Line IP

IP-протокол для последовательных линий (RFC-1055)

SLM

Signal Label Mismatch

Несовпадение сигных меток

Service Level Management

Управление уровнем обслуживания

SLMR

Silly Little Modem Reader

Маленькое модемное читающее устройство

SLOSH

Sea, Lake and Overland Surge from Hurricane

Море, озеро и волны на суше от урагана (программа)

SLR

Synchronous Line Regenerator

Синхронный линейный регенератор

SLRNN

Single Layer Recurrent Neural Network

Однослойная рекуррентная нейронная сеть

SLSI

Super Large-Scale Integration

Сверхбольшая степень интеграции

SLSS

Systems Library Subscription Service

Услуга подписки на системные библиотеки [IBM]

SLX

Synchronous Line Multiplexer

Синхронный канальный мультиплексор

SM

Set Mode

Установить режим

Synchronous Multiplexer

Синхронный мультиплексор

Shared Memory

Разделяемая память

Single Mode

Одномодовый

SMA

Synchronous Multiplexer, Add-drop

SDH-мультиплексор ввода-вывода

SMAC

Source MAC

MAC-адрес отправителя

SMAP

System Management Application Process

Прикладной процесс системы управления

SMB

Server Message Block [MII]

Блок сообщения сервера (протокол)

SMC

Service Management Centres

Центры управления услугами

SMD

Surface Mounted Device

Прибор смонтированный на поверхность

SMDR

Station Message Detail Recording

Детальная запись сообщения станции

SMDS

Switched Multi-megabit Data Service

Коммутирующая система для передачи мульти-мегабитных данных

SMF

Standard Message Format

Стандартный формат сообщений

Single Mode Fiber

Одномодовое оптическое волокно

System Manager Facility

Устройство управления системой [Compaq]

SMG

Super-Master-Group

Группа супер-сервера

SMI

System Management Interface/Interrupt

Система управления интерфейсом/прерываниями

System (Structure of) Management Information

Системная управляющая информация (RFC-1155)

SMIB

Security Management Information Base

База данных управления безопасностью (VLAN)

SMIF

Standard Mechanical Interface

Стандартное механическое устройство сопряжения

SMIT

System Management Interface Tool

Интерфейсное устройство системы управления [IBM]

SML

Symbolic Machine Language

Символический машинный язык

SMK

Software Migration Kit

Система переноса программного обеспечения [Microsoft]

SMM

System Management Mode

Режим системы управления [Intel]

SMN

SDH Management Network

Управляющая сеть SDH

SMO

State Machine Object

Объект машины состояний

SMP

Simple Management Protocol

Простой протокол управления

Symbolic Manipulation Program

Программа манипулирования символами

Symmetrical Multiprocessor

Симметричный мультипроцессор

.SMP

Sample

Расширение имени файла (образец)

SMPC

Shared Memory Parallel Computer

Параллельный компьютер с совместным использованием памяти

SMPS

Switching Mode Power Supply

Источник питания, использующий ключевой режим

SMRAM

System Management Random Access Memory

Память с произвольным доступом системы управления

SMRP

Simple Multicast Routing Protocol

Простой протокол мультикаст-маршрутизации

SMS

Storage Management Services

Услуги управления памятью [NetWare]

SDH Management Sub-network

Подсеть SMS сети управления SMN

Synchronous Multiplex System

Синхронная мультиплексная система

Storage Management Subsystem

Субсистема управления памятью

Short Message Service

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

SMSW

Store Machine Status Word

Статусное слово системы запоминания

SMT

Surface-Mount Technology

Технология монтажа на поверхность

Station Management

Управление станцией (стандарт)

SMTP

Simple Mail Transfer Protocol

Простой протокол пересылки почтовых сообщений (RFC1351,1352)

SMU

System Management Utility

Программа управления системой

SMUX

SDH Multiplexer

Мультиплексор SDH

Synchronous Multiplexer

Синхронный мультиплексор

SN

Serial Number

Серийный номер

Sequence Number

Номер по порядку

Segment Number

Номер сегмента

S/N

Signal-to-Noise (Ratio)

Отношение сигнал/шум

SNA

System Networking Architecture [IBM]

Системная архитектура сети

SNADS

SNA Distribution Service

Система распределения SNA

SNAP

Sub Network Address (Access) Protocol

Протокол для адресации к субсетям

SNCC

System/Network Control Center

Системный центр управления сетью

SND

Sound

Звук

SNDCF

Subnetwork Dependent Convergence Function

Функция конвергенции, зависящая от субсети

SNDCP

Sub Network Dependent Convergence Protocol

Протокол согласования, зависящий от субсети

SNI

Subscriber Network Interface

Сетевой интерфейс подписки

Siemens Nixdorf Informationsysteme

Информационная система фирмы Siemens

SNA Network Interconnection

SNA подключение к сети

SNMP

Simple Network Management Protocol

Простой сетевой протокол управления (RFC1381-82)

SNOBOL

String Oriented Symbolic Language (Programming Language)

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

SNP

Subnetwork Access Protocol

Протокол доступа к субсетям

Sequence Number Protection

Защита номера последовательности

Serial Number/Password [Omen Technology]

Серийный номер/пароль

SNPA

SubNetwork Point of Attachment

Точка подключения субсети

SNR

Signal-to-Noise Ratio

Отношение сигнал-шум

SNRM

Set Normal Regime Mode

Установка нормального режима (HDLC)

SNTP

Simple Network Time Protocol

Простой сетевой протокол синхронизации (задания временной шкалы)(RFC 1361)

SOA

Start of Authority

Запись в файле named.local

SOC

System On a Chip

Система на одном кристалле

Serial Optical Channel

Последовательный оптический канал

SOCC

Serial Optical Channel Connection

Последовательны оптический канал связи

SOD

Spear Of Density

 

SOE

Standard Operating Environment

Стандартная операционная среда

SOH

Start of Header

Начало заголовка

Section OH

Секционный заголовок

SOHO

Small office, Home office

Малый офис, домашний офис

SOL

Simulation Oriented Language

Язык, ориентированный на моделирование

SOM

Start of Message

Начало сообщения

System Object Model

Системная объектная модель [IBM]

Self_Organizing Map algorithm

Самоорганизующийся алгоритм

SONET

Synchronous Optical NETwork

Стандарт на оптоволоконный канал, работающий в диапазоне 51,84Мбит/с - 48 Гбит/с

SOP

Standard Operating Procedures

Стандартные операционные процедуры

SOS

Silicon On Sapphire

Кремний на сапфире

Sophisticated Operating System

Сложная операционная система

Service Operating System

Система управления сервисом сети

Standards and Open Systems

Стандарты и открытые системы

SOTA

State Of The Art

Современный уровень

SOX

Sound Exchange

Обмен звуковыми сигналами

SP

Stack Pointer

Указатель стека

Shift Pulse

Импульс сдвига

Signaling Processor

Сигнальный процессор

Switch Processor

Процессор переключателя

System Product

Системный продукт

SPA

Software Publishing Association

Ассоциация публикаций программного обеспечения

Symbolic Pattern Associator

Ассоциирующее устройство для символьных образов

SPAG

Standards Promotion and Application Group

Группа продвижения и применения стандартов

SPAN

Space Physics Analysis Network

Аналитическая сеть космической физики

Switched Port ANalyzer

Анализатор переключателя портов

SPARC

Scalable Processor Architecture

Масштабируемая архитектура процессора

SPC

Small Peripheral Controller

Небольшой контроллер периферийного устройства

Statistical Process Control

Управление статистическим процессом

Stored Program Control exchanges

Коммутаторы, управляемые встроенной программой

SPCF

Service Point Command Facility

Командное устройство точки обслуживания (IBM)

SPCL

Spectrum Cellular Corporation

Название компании

SPE

Synchronous Payload Envelope

Синхронный пакет

SPEC

Systems Performance Evaluation Cooperative

Кооператив для измерения рабочих характеристик сети

SPF

Shortest Path First

Кратчайший путь - первый (OSPF)

System Programming Facility

Устройство системного программирования

SPI

Service Provider Interface

Интерфейс сервис-провайдера

SDH Physical Interface

Физический интерфейс SDH

SPID

Service Profile Identifier

Идентификатор сервисного профайла

SPIKE

Science Planning Intelligent Knowledge-Based Environment [STScI]

Экспертная среда для планирования научных проектов

SPIU

Subrack Power Interface Unit

Интерфейс блока питания каркаса

SPL

Spooler

Буферная память

.SPL

Spell Checker (file name extension)

Расширение имени файла контроля правописания

SPM

System Performance Monitor

Монитор рабочих характеристик системы [IBM]

SPN

Subscriber Premises Network

Первичная абонентская сеть

SPOOL

Simultaneous Peripheral Operations On Line

Одновременные операции с периферийным оборудования в реальном времени

SPP

Sequential Packet Protocol

Протокол для последовательной передачи пакетов

SPS

Standby Power System

Резервная система питания

SPSS

Statistical Package for the Social Sciences

Статистический пакет программ для социальной науки

SPT

Sectors Per Track

Число секторов на трек

SPTN

Single Protocol Transport Network

Однопротокольная транспортная сеть

SPW

Signal Processing Worksystem

Рабочая система обработки сигналов

SPX

Sequenced Packet Exchange

Последовательная передача пакетов (аналог TCP для Novell)

SQ

Squeezed

Сжатый (о файле)

SQC

Statistical Quality Control

Статистический контроль качества

SQE

Signal Quality Error

Ошибка качества сигнала

SQL

Structured Query Language

Структурированный язык запросов

SQL/DS

Structured Query Language/Data System

Структурированный язык запросов/система данных [IBM]

SQRT

Square Root

Квадратный корень

SR

Shift Register

Сдвиговый регистр

Synchronous Radio link

Синхронная радиорелейная линия

SRAM

Shadow Random Access Memory

Теневая память с произвольным доступом

Static Random Access Memory

Статическая память с произвольным доступом

SRB

Source-Route Bridging

Использование моста с переадресацией, заданной отправителем

.SRC

Source

Расширение имени файла исходных текстов

SRC

Secondary Reference Clock

Вторичный тактовый генератор

System Resource Controller

Системный контроллер ресурсов

SRD

Screen Reader System

Система считывания с экрана

SRIN

Self- Routing Neural Network

Нейронная сеть с самомаршрутизацией

SRM

Short Range Modem

Модем для малых расстояний (микромодем)

Security Reference Monitor

Монитор безопасности

SRN

Simple Recurrent Network

Простая рекуррентная сеть

SRO

Sharable and Read Only

Совместно использованный и предназначенный только для чтения

SRP

Spatial Reuse Protocol

Протокол повторного использования пространства

SRPI

Server-Requester Programming Interface

Программный интерфейс сервера запросов

SRQ

Service Request

Запрос обслуживания

SRR

Serially Reusable Resource

Последовательно используемый ресурс

Substitute Remote Request

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

SRT

Source-Route Transparent bridging

Применение прозрачного моста с маршрутами, заданными отправителем

Synchronous Radio Trunk

Синхронный радиотранк

SRTP

Sequenced Routing update Protocol

Протокол последовательной актуализации маршрутов

SS

Stack Segment

Сегмент стека

Single Sided

Односторонний

Sum of Squares

Сумма квадратов

Seconds

Число секунд

SS7

Signaling System N7

Сигнальная система N7

SSA

Serial Storage Architecture

Последовательный интерфейс для подключения большого числа дисков (IBM)

SSAP

Source Service Access Point

Точка доступа к обслуживанию отправителя

SSB

Single SideBand radio

Одиночный радиоканал, использующий боковую частоту

SSCF

Service-Specific Coordination Function

Служебно-ориентированные функции координации

SSCOP

Service Specific Connection Oriented Protocol

Протокол, ориентированный на подключение к специфическим услугам (AAL)

SSCP

System Services Control Point

Точка управления системными услугами

SSCS

Service Specific Convergence Sublayer

Служебно-ориентированный субуровень конвергенции

SSD

Start of Stream Delimiter

Разграничитель начала потока

Software Solutions Division

Отдел программных решений

SSE

Silicon Switching Engine

Кремниевое переключающее устройство (CISCO)

SSFN

Session Setup Failure Notification

Оповещение о неудаче конфигурирования сессии

SSGA

System Support Gate Array

Матрица ключей системной поддержки

SSH

Secure SHell

Безопасное ядро (UNIX)

SSI

SubSystem Interface

Интерфейс субсистемы

Small Scale Integration

Малая степень интеграции

SSIS

Socket Services Interface Specification (cards)

Спецификация интерфейса соединителей

SSL

Secure Sockets Layer

Уровень безопасности соединителей

SSM

Single Segment Message

Односегментное сообщение

Synchronous Status Message

Сообщение о статусе синхронизации

SSN

Subsystem number

Номер субсети

SSP

SWIFT Service Partner

Сервис-партнер SWIFT

Switch-to-Switch Protocol

Протокол переключатель-переключатель

Silicon Switch Processor

Кремниевый процессор переключателя

SSRC

Synchronization Source

Источник синхронизации (RTP)

SSRR

Strict Source and Record Route

 

SSS

Spread-Spectrum Technology

Шумоподобная технология

SST

Solid State Software

Твердотельные программные средства

SS-TDMA

Satellite switched Time Division multiple Access

Множественный доступ к спутниковому каналу с делением по времени

SSU

Satellite Supervisory Unit

Блок спутникового супервизора

SSW

System SWitch unit

Блок системного кросс-коммутатора

ST

Segment Type

Тип сегмента

STA

Spanning Tree Algorithm

Алгоритм расширяющегося дерева

STB

Strobe

Строб

Statmux

Statistical Multiplexer

Статистический мультиплексор

STC

SHARE Technical Network

Техническая сеть SHARE

Set Carry flag

Установить флаг переноса

STD

Set Direction Flag

Установить флаг направления

Standard

Стандарт

STDA

StreetTalk Directory Assistance [Banyan]

 

Signal Switching Point

Точка переключения сигнала

STDAUX

Standard Auxiliary

Вспомогательный стандарт

STDERR

Standard Error

Стандартная ошибка

STDIN

Standard Input

Стандартный ввод

STDIO.H

Standard Input/Output Header [C]

Стандартный заголовок ввода/вывода

STDM

Statistical Time Division Multiplexing

Статистическое мультиплексирование с делением по времени

STDOUT

Standard Output

Стандартный вывод

STDPRN

Standard Printer

Стандартный принтер

STEP

STandard for the Exchange of Product model data

Стандарт для передачи данных о моделях продуктов

.STF

Structured File

Расширение имени структурированного файла [Lotus Agenda]

STI

Set Interrupt Flag

Установить флаг прерывания

STM

Synchronous Transfer Mode

Синхронный режим передачи

Synchronous Transport Module

Синхронный транспортный модуль (SDH)

Synchronous Time division Multiplexer

Синхронный мультиплексор с разделением по времени

Short Term Memory

Память с малым временем хранения

STM-1

Synchronous Transport Module of level 1

Синхронный транспортный модуль первого уровня (SDH; 155,520 Мбит/c)

STM-4

Synchronous Transport Module of level 4

Синхронный транспортный модуль уровня 4 (SDH; 622,080 Мбит/c)

STM-16

Synchronous Transport Module of level 16

Синхронный транспортный модуль уровня 16 (SDH; 2488,320 Мбит/c)

STM-64

Synchronous Transport Module of level 64

Синхронный транспортный модуль уровня 64 (SDH; 9953,280 Мбит/c)

STM-256

Synchronous Transport Module of level 256

Синхронный транспортный модуль уровня 256 (SDH; 39813,120 Мбит/c)

STOS

Store String

Запомнить строку

STP

Spanning Tree Protocol

Протокол "расширяющееся дерево" системы мостов и переключателей

Shielded Twisted Pair (cable)

Кабель с экранированными скрученными парами проводов

Signal Transfer Point

Точка передачи сигнала

STR

Store Task Register

Запомнить регистр задачи

Synchronous Transmitter Receiver

Синхронный приемопередатчик

STRESS

Structural Engineering System Solver

Язык программирования

STRUDL

Structural Design Language

Структурированный язык проектирования

STS

Synchronous Transport Signal

Синхронный транспортный сигнал (SONET)

SWIFT Terminal Service

Терминальная служба SWIFT

STS-1

Synchronous Transport Signal of level 1

Синхронный транспортный сигнал уровня 1 (SONET; 51,84 Мбит/c)

STS-3

Synchronous Transport Signal of level 3

Синхронный транспортный сигнал уровня 3 (SONET; 155,52 Мбит/c = STM-1 в SDH)

STS-12

Synchronous Transport Signal of level 12

Синхронный транспортный сигнал уровня 3 (SONET; 622,08 Мбит/c = STM-4 в SDH)

STS-48

Synchronous Transport Signal of level 48

Синхронный транспортный сигнал уровня 48 (SONET; 2488,32 Мбит/c = STM-16 в SDH)

STS-192

Synchronous Transport Signal of level 192

Синхронный транспортный сигнал уровня 192 (SONET; 9953,28 Мбит/c = STM-64 в SDH)

STScI

Space Telescope Science Institute

Научный институт космической телескопии

STX

Start of Text

Символ начала текста

STUN

Serial Tunneling (CISCO)

Последовательное туннелирование

STX

Start of Text

Начало текста

.STY

Style

Расширение имени стилевого файла [Ventura, Word, WordPerfect]

SU

Service Unit

Блок обслуживания интерфейсов

Signaling Unit

Сигнальный блок

SUB

Subroutine

Подпрограмма

Substitute

Подстановка

Subtract

Вычесть

SUM

Smart Uplink Module

Интеллектуальный модуль связи (Fast Ethernet)

SUNET

Swedish University Network

Сеть Шведского университета

SUN-NFS

Network File System Protocol

Сетевой протокол для файловой системы фирмы SUN (RFC-1094)

SUN-RPC

Remote Procedure Call protocol

Протокол для удаленного доступа SUN (RFC-1057)

.SUP

Supplemental Dictionary [WordPerfect]

Расширение имени файла дополнительного словаря

SURAnet

Southeasten Universities Research Association Network

Сеть ассоциации исследовательских университетов Юго-востока

SV

Sound Vision

Мультимедиа (карта)

SVC

Switched Virtual Circuit

Схема виртуального переключения

Signaling Virtual Channel

Сигнальный виртуальный канал

SVGA

Super Video Graphic Adapter

Супер видео-графический адаптер

S-VHS

Super VHS

Супер VHS

SVR#

System V Release Number

Номер версии [AT&T]

SVID

System V Interface Definition

Описание интерфейса System V (AT&T)

SW

SoftWare

Программа

Switch

Переключатель

S/W

Software

Программное обеспечение

SWAN

Sun's Wide Area Network

Региональная сеть корпорации SUN

SWAP

Shared Wireless Access Protocol

Протокол беспроводного совместного доступа (IEEE 802.11)

SWIFT

Society for Worldwide Financial Telecommunication

Всемирное общество финансовых коммуникаций

SWIPP

Switched Interconnection of Parallel Processors

Параллельный процессор для коммутируемых связей

SWITCH

Swiss Telecommunication System for high Education and Research

Швейцарская система телекоммуникаций для высшего образования и исследований

.SWP

Swap

Расширение имени файла подкачки

SWS

Silly Window Syndrome

Синдром узкого окна (window=0, RFC-813)

SXC

Synchronous Cross-Connect

Синхронный кросс-коммутатор

SYLK

Symbolic Link

Символьная связь

.SYM

Symbols

Расширение имени символьного файла

SYN

Synchronous Idle (control signal) Synchronize sequence numbers flag (TCP header)

Флаг синхронизации в TCP-заголовке

.SYN

Synonym

Расширение имени файла синонимов

SYNC

Synchronous

Синхронный

SYS

System

Система

.SYS

System Configuration

Расширение имени файла системной конфигурации

System Device Driver

Расширение имени системного драйвера

SYSGEN

System Generator

Системный генератор

SYSLOG

System Log

Системный дневник

SYSMOD

System Modification

Модификация системы

SYSOP

System Operator

Системный оператор

SYSREQ

System Request

Системный запрос


Previous: 10.10.18 [R]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.20 [T]


previous up down next index index
Previous: 10.10.19 [S]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.21 [U]

10.10.20 [T]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

T1

 

Первичный цифровой канал со скоростью передачи 1544 Кбит/с (PDH)

T2

 

Вторичный цифровой канал со скоростью передачи 6312 Кбит/с (PDH)

T3

 

Стандарт цифровых сигналов DS-3 для скорости передачи 44,746 Мбит/с (RFC-1177) (PDH)

T4

 

Цифровой канал с быстродействием 274176 Кбит/с (PDH)

T.4

 

Стандарт CCITT для факсимильной передачи группы 3

T.6

CCITT standard for group 4 facsimile Transmission

Стандарт CCITT для факсимильной передачи группы 4

T.120

 

Управление конференциями: управление камерой (H.281); многоточечное управление (H.243, T.122-T.125); передача файлов (T.126); аудиовизуальное управление (T.128).

TA

Terminal Adapter

Терминальный адаптер

TABS

Telemetry Asynchronous Block Serial

Асинхронный последовательный блок телеметрии

TAC

Terminal Access Controller (dial-up)

Терминальный контроллер доступа

Technical Assistance Center

Центр технической помощи

TACACS

Terminal Access Controller Access System

Система доступа терминального контроллера доступа

TAD

Telephone Answering Device

Телефонный автоответчик

TAF

Terminal Access Facility

Устройство терминального доступа

TAG

Terminal Access Gateway

Порт доступа к терминалу

TAGS

Technology for Automated Generation of Systems

Технология для автоматической генерации систем

TAM

Temporal Associative Memory (USL)

Временная ассоциативная память

TAPCIS

The Access Program for the CompuServe Information Service

Программа доступа для информационных услуг CompuServe

TAPI

Telephony Applications Programming Interface

Программный интерфейс для приложений телефонии

TAR

Tape Archive

Архив на ленте

TARA

Threshold Analysis and Remote Access

Анализ порога и удаленный доступ

TARP

TID Address Resolution Protocol

Протокол выявления адреса TID

TASM

Turbo Assembler

Турбо ассемблер [Borland]

TAXI

Transparent Asynchronous Transceiver Interface

Прозрачный асинхронный интерфейс трансивера

TB

Terabyte (1,000 gigabytes)

Терабайт (1000 гигабайт)

T/B

Top and Bottom

Верх и низ

TBBS

The Bread Board System (BBS)

 

.TBK

Toolbook

Расширение имени файла вспомогательных средств

TBOS

Telemetry Byte Oriented Serial protocol

Последовательный байт-ориентированный протокол передачи телеметрии

TC

Test Control

Управление испытаниями

Transmission Control

Управление передачей

Transmission convergence

Конвергенция передачи

TCAL

Thermal reCALibration

Тепловая перекалибровка

TCAP

Transaction Capabilities Application Part

Протокольная часть прикладных возможностей

TCB

Transmission Control Block

Блок управления передачей

Transmission Control Buffer

Буфер управления передачей

TCC

Terminating Call Control.

Управление терминирующим вызовом

TCF

Technical Construction File

Файл технической конструкции

TCI

TIU Connection Interface

Интерфейс связи с TIU

TCL

Tool Command Line

Командная строка отладочного средства

TCM

Trellis-coded Modulation

Метод снижение числа ошибок при передаче данных за счет избыточности

TCN

TeleCommunication Network

Телекоммуникационная сеть

Threshold Crossing Notification

Уведомление о пересечении порога (границы)

TCP

Transport Control Protocol, higher level network protocol runs on top of IP

Транспортный сетевой протокол высокого уровня работает поверх IP (RFC-793)

TCP/IP

Transmission Control Protocol/Internet Protocol

Протокол управления передачей/протокол Интернет

TCP-ACO

TCP Alternate Checksum Option

Альтернативная опция контрольной суммы TCP (RFC-1146)

TCU

Trunk Coupling Unit

Блок связи с магистралью

TD

Transmit Data

Передать данные

TDBS

The Data Base System

Система базы данных (eSoft Database)

TDtoDP

Tablet Coordinates to Display Coordinates

Преобразование координат таблички в координаты на дисплее

TDD

Time Division Duplex

Дуплексная связь с мультиплексированием по времени

Telecommunication Device for Deaf

Телекоммуникационный прибор для глухих

TDE

Terminal Display Editor

Редактор терминального дисплея

.TDF

Typeface Definition File

Расширение имени файла описания разновидности шрифтов

TDI

Transport Driver Interface

Интерфейс транспортного драйвера (Windows)

TDM

Time Division Multiplexing

Мультиплексирование с делением по времени

TDMA

Time Division Multiple Access

Множественный доступ с разделением по времени

TDMoIP

Time Division Multiplexinf over IP

Множественный доступ с разделением по времени через IP

TDMS

Terminal Display Management System

Система управления терминальным дисплеем

TDNN

Time Delay Neural Network (SL)

Нейронная сеть с задержкой

TDR

Time Domain Reflectometer

Тайм-доменный рефлектометр

TDSR

Transmitter Data Service Request

Запрос данных передатчиком

TDR

Time Domain Reflectometry

Рефлектометрия по методу временного домена

TDS

Transputer Development System

Система разработки для транспьютеров

TDW

Turbo Debugger for Window

Турбоотладчик для Windows

TDX

Time Division eXchange

Обмен с мультиплексированием по времени (HDTV)

TE

Terminal Equipment

Терминальное оборудование

Traffic Engineering

Проектирование трафика, управление трафиком

TEHO

Tail End Hop Off

 

TEB

Thread Environment Block

Блок среды процесса

TEC

Tokyo Electronics Corporation

Название компании

TEI

Terminal Endpoint Identifier

Идентификатор точки подключения терминала

TEL

Trans European Line (140 Mbit/s, optofiber)

Транс-европейская магистраль (140 Мбит/с, оптоволокно)

TELAPI

Telnet Application Programming Interface

Прикладной программный интерфейс для Telnet (RFC-854)

TEML

Turbo Editor Macro Language

Турбо редактор для языка макро [Borland]

TER

Thermal Eclipse Reading

Чтение с тепловым затенением [Sony]

terabyte

one trillion bytes

Триллион байт

TERENA

Trans-European Research and Education Network Association

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

TERMPWR

Terminator Power

Мощность терминатора

TES

Terminal Emulation Service

Система эмуляции терминала (Int 14)

Telephone Earth Station

Телефонная наземная станция (Hughes)

TERMPWR

Terminator Power

Мощность терминатора

TF

Transmition Fail

Сбой при передаче

TFEL

Thin-Film Electroluminiscent

Тонкопленочный электро-люминисцентный

FL

Transmission Fail

Сбой при передаче

.TFM

Tagged Font Metric

Расширение имени файла метрики шрифта

TFEND

Transposed Frame End

Конец кадра

TFT

Thin-Film Transistor (screens)

Тонкопленочный транзистор

TFTP

Trivial File Transfer Protocol

Тривиальный протокол передачи файлов (RFC-783)

TH

Transmission Header

Транспортный заголовок

THD

Total Harmonic Distortion

Общее гармоническое искажение

THEnet

Texas Higher Education Network

Сеть высшего образования в Техасе (60 институтов)

THOR

Tandy High-Performance Optical Recording

Высококачественная оптическая запись

THT

Token Holding Timer

Таймер удержания маркера (FDDI & Token ring)

Transmit Holding Register

Запоминающий регистр передачи

.THS

Thesaurus

Расширение имени файла тезауруса

TI

Texas Instruments, Inc

Название фирмы

TIA

Telecommunications Industry Association

Промышленная ассоциация телекоммуникаций

TIC

Token Ring Interface Coupler

Интерфейс Token Ring

TID

Terminal IDentification (ISDN)

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

Target ID

Идентификатор места назначения

TIES

Time Independent Escape Sequence

ESC-последовательность, не зависящая от времени

.TIF

Tagged Image File

Расширение имени графического файла

TIFF

Tagged Image File Format

Формат графического файла

TIGA

Texas Instruments Graphics Architecture

Архитектура графики компании Texas Instruments

TIGER

Topologically Integrated Geographic Encoding and Referencing

Топологически интегрированное географическое кодирование и привязка

TIM

Trace Identifier Mismatch

Несовпадение идентификатора трассировки (SDH)

TIMS

The Integrated Mail System

Интегрированная почтовая система

TINA

Telecommunications Information Networking Architecture

Архитектура телекоммуникационных информационных сетей

TIP

Terminal Interface Processor

Процессор терминального интерфейса

TIPS

Trillion Instructions per Second

1012 операций в секунду

TIRKS

Trunk Information Record Keeping System

Информационная система поддержания канала

TIU

Tributary Interface Unit

Блок трибного интерфейса (SDH)

TKIP

Temporary Key Integrity Protocol

Протокол целостности временного ключа

TLAP

TokenTalk Link Access Protocol

Маркерный протокол доступа к каналу

TLB

Translation Lookaside Buffer

Буфер преобразования

TLC

Transport Layer Security

Безопасность сетевого уровня (протокол)

TLI

Transport Layer Interface

Интерфейс транспортного уровня

TLU

Table Lookup

Таблица просмотра

.TLX

Telex

Расширение имени файла телекса

TM

Trademark

Торговая марка

Terminal Multiplexer

Терминальный мультиплексор

Traffic Management

Управление трафиком

TMM

Total MultiMedia

Общая среда мультимедиа

TMN

Telecommunication Management Network

Телекоммуникационная управляющая сеть

TMP

Temporary

Временный

TMRS

Traffic Measurement and Recording Systems

Системы записи и измерения трафика

TMS

Terminal Management Suite (TV)/ Subsystem

Терминальная управляющая субсистема (ТВ)

TNC

Terminal Node Controller

Узловой терминальный контроллер

Transit Node Clock

Задающий генератор транзитного узла

ToC

Table Of Contents

Таблица содержания

TOE

TCP/IP Offload Engine

TOP

Technical Office Protocol

Технический протокол для офисов

TOS

Type of Service

Тип сервиса (Ethernet, RFC-1340)

TP

Transmission Path

Маршрут передачи

TPC

Transmission Power Control

Управление мощностью переадачи

TP0

Transport Protocol class 0

Транспортный протокол класса 0

TPC

Transaction Processing Performance Council

Совет по анализу выполнения транзакций

TPDU

Transport Protocol Data Unit

Транспортный протокольный блок данных (поле данных)

TPPMD

Twisted-Pair Physical Medium Dependent

Зависящий от физической среды и использующий скрученную пару

TPW

Turbo Pascal for Window

Турбо Паскаль для Windows

TNM

Transmission Network Manager

Менеджер сетевого обмена (IBM)

TPI

Tracks Per Inch

Число дорожек на дюйм

TPL

Table Producing Language

Язык генерации таблиц

TPM

Transactions Per Minute

Число транзакций в минуту

TPORT

Twisted Pair Port Transceiver

Трансивер порта, рассчитанный на скрученную пару [AT&T]

TP-PDM

Twisted Pair Physical Medium Dependant

(Устройство, рассчитанное на работу) со скрученной парой, зависящее от физической среды

TPS

Transactions Per Second

Число транзакций в секунду

Transaction Processing System

Система обработки транзакций

TQM

Total Quality Management

Общее управление качеством

TR

Terminal Ready

Терминал готов

Talking Ring

Сетевой стандарт "маркерное кольцо"

T/R

Transmit/Receive

Передать/принять

TRADIC

Transistorized Airborne Digital Computer

Название первой ЭВМ, полностью выполненной на транзисторах

TRAM

TRAnsputer Module

Транспьютерный модуль

TRIP

Token Ring Interface Processor

Процессор интерфейса Token Ring

TRISL

Token Ring Inter-Switch Link

Межкоммутаторный канал Token Ring

.TRM

Terminal

Расширение имени файла, имеющего отношение к терминалу

TRN

Threaded Read News [Internet]

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

TRON

The Real-Time Operating System Nucleus

Ядро операционной системы реального времени

TRT

Token Rotation Timer

Таймер обращения маркера

TS

Top Secret

Совершенно секретно

Transport Services

Транспортные услуги

TSA

Technical Support Alliance

Альянс технической поддержки

TSAP

Transport Service Access Point

Точка доступа к обслуживанию на транспортном уровне

TSAPI

Telephony Services Application Program Interface

Прикладной программный интерфейс услуг телефонии [AT&T + Novell]

TSB

Termination Status Block

Блок состояния завершения

TSE

Transputer Software Environment

Программная среда транспьютера

TSESC

Transposed Frame Escape

Транспонированный ESC кадра

TSIG

Transaction SIGnature

Транзакционная подпись (средство безопасности DNS)

TSO

Time Sharing Option

Опция разделения времени

TSOP

Thin Small Outline Package (8x20x1.2 mm)

Небольшой тонкий корпус

TSPS

Traffic Service Position System

Система службы трафика

TSR

Terminate and Stay Resident

Завершить и остаться резидентной (о программе демоне)

TSS

Text Search System

Система поиска текста

Task State Segment

Сегмент состояния задания

Time Sharing System

Система разделения времени

TS/SI

Top Secret/Sensitive Information

Секретная/важная информация

.TST

Test

Расширение имени тестового файла

TSTN

Triple Supertwisted Nematic

 

TSU

Telnet Session Utility

Программа для Telnet-сессий (LAN-Work Place)

TSW

Terminal System sWitch

Коммутатор терминальной системы

TT

Trunk Type

Тип магистрали

TTE

Telecom Terminal Equipment Directive

Аппаратная директива терминала telecom

TTF

True Type Font

Шрифт "истинного" типа

Transport Terminal Function

Функция начала/завершения транспортировки VC

.TTF

TrueType Font (file name extension)

Расширение имени файла, содержащего TTF-шрифт

TTI

Trail Trace Identifier

Идентификатор трассировки текущего маршрута

TTL

Time To Live (datagram in Internet)

Время жизни дейтограммы в сети Интернет

Transistor-Transistor Logic

Транзистор транзисторная логика

TTR

Transparent Translation Registers

Регистры прозрачного преобразования

TTRT

Target Token Rotation Time

Время обращения маркера

Timed Target Rotation Time

Время обращения (FDDI)

TTS

Text-To-Speech

Преобразование текста в речь

Transaction Tracking System

Система отслеживания транзакций

TTTN

Tandem Tie Trunk Network

Сеть связанных магистралей фирмы Tandem

TTY

Teletype

Телетайп

TU

Tributary Unit

Трибный блок (субблок SDH)

TUAP

Tributary Unit Access Point

Точка доступа трибного блока

TUBA

TCP and UDP with Bigger Addresses

TCP и UDP с длинными адресами

TUC

Total User Cell

Общее число ячеек пользователя (ATM)

TUI

Text-Based User Interface

Пользовательский интерфейс, базирующийся на текстах [WordPerfect]

TUP

Telephony User Part

Сообщение, используемое при установлении телефонного канала

TUR

Trunk Utilization Report

Отчет об использовании магистрали

.TUT

Tutorial

Расширение имени обучающего файла

TVI

Television Interference

Телевизионная интерференция

TWX

Teletypewriter Exchange Service

Услуга телетайпного обмена

TXD

Transmitted Data

Переданные данные

TXT

Text

Текст

TXT2STF

Text To Structured File [Lotus Agenda]

Преобразование текста в структурированный файл

TZD

Time Zone Designator

Идентификатор временной зоны


Previous: 10.10.19 [S]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.21 [U]


previous up down next index index
Previous: 10.10.20 [T]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.22 [V]

10.10.21 [U]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

UA

Unnumbered Acknowledgment

Ненумерованное подтверждение

User Agent

Пользовательский агент

User Area

Область пользователя

UAA

Universally Administered Address

Универсально управляемый адрес

UAE

Unrecoverable Application Errors

Неисправимые ошибки приложения

UART

Universal Asynchronous Receiver Transmitter

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

UAS

UnAvailable Seconds

Недоступные секунды

UBR

Unspecified Bit Rate

Неопределенная скорость передачи (ATM)

.UC2

Compressed File

Расширение имени сжатого файла [UltraCompressor]

UCD

Uniform Call Distributor

Распределитель запросов

UCL

Universal Communications Language

Универсальный коммуникационный язык

UCM

Universal Call Model

Модель универсального вызова

UCO

User Consultancy Office

Консультационное бюро для пользователей

UCS

Universal multiple-octet coded Character Set

Универсальный многооктетный набор символов

UCT

UnConditional Transfer

Безусловная передача

UDC

User Defined Commands

Команды, заданные пользователем

UDE

Universal Data Exchange

Универсальный обмен данными

UDF

User Defined Functions

Функции, заданные пользователем

UDLP

UniDirectional Link Protocol

Протокол для каналов с однонаправленным обменом

UDP

User Datagram Protocol

Протокол для передачи дейтограмм пользователя (RFC-768)

UFO

User Familiar Objects

Объекты, известные пользователю

UFS

Ultimate File System

Первичная файловая система

Unix File System

Файловая система UNIX

UG

User Group

Группа пользователей

UI

Unnumbered information

Ненумерованная информация

Unix International

Международный UNIX

User Interface

Пользовательский интерфейс

UID

User IDentifier

Идентификатор пользователя

Universal IDentifier

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

UIDL

Unique-ID Listing

Уникальный идентификатор сообщения

UIO

Universal I/O serial port (Cisco router)

Уникальный порт ввода/вывода

UIMS

User Interface Management System

Система управления интерфейсом пользователя

UITS

Unacknowledged Information Transfer Service

Передача информации без подтверждения получения

UKERNA

UK Education and Research Networking Association

Английская ассоциация сетей для науки и образования

UL

Underwriters Laboratories

Лаборатории страховщиков

Upload

Выгрузить

ULA

Uncommitted Logic Array

Неиспользованная логическая матрица

ULH

Ultra Low Haul

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

ULN

Universal Link Negotiation

Универсальный диалог доступа к каналу

ULP

Upper Layer Protocol

Протокол верхнего уровня

ULSI

Ultra Large Scale Integration

Сверх высокая степень интеграции

UltraNet

125 Mbps network (Ultra Network Technology)

Сети на 125 Mбит/с, технология супер-сетей

UMB

Upper Memory Blocks

Блоки верхней памяти [LIM/AST]

UME

UNI Management Entity

Объект управления интерфейса "пользователь-сеть"

UMTS

Universal Mobile Telecommunication Services

Универсальные мобильные телекоммуникационные услуги

UN

United Nations

Объединенные Нации

UNC

Universal Naming Convention

Универсальное соглашение об именах

Uuencoded Netnews Collator [Unix]

Система сравнения для закодированных сетевых новостей

UNCOL

Universal Computed Oriented Language

Универсальный язык, ориентированный на расчеты

UNI

User Network Interface

Сетевой интерфейс пользователя

UNICOM

Universal Integrated Communication (System)

Система универсальных интегрированных коммуникаций

UNICOS

Universal Compiler FORTRAN compatible

Универсальный компилятор, совместимый с FORTRAN

UNMA

Unified Network Management Architecture (AT&T)

Унифицированная архитектура сетевого управления

UNI

User Network Interface

Пользовательский сетевой интерфейс

UNIVAC

Universal Automatic Computer

Универсальная автоматическая ЭВМ

UNIX

(AT&T Bell Laboratories Operating System)

Операционная система

UNMA

Unified Network Management Architecture

Архитектура однородного сетевого управления

UP

Unnumbered Poll

Ненумерованный запрос (ISDN)

UPC

Universal Product Code

Универсальный код продукта

Usage Parameter Control

Контроль параметров пользователя

UPAP

User Password Authentication Protocol

Протокол идентификации паролей пользователей

UPL

User Program Language

Язык пользовательской программы

UPM

Unix Programmer's Manual

Справочное руководство по UNIX для программиста

User Profile Management

Управление конфигурационным файлом пользователя [IBM]

UPS

Uninterrupted Power System

Источник питания с защитой от кратковременных пропаданий напряжения сети

UREP

Unix RSCS Emulation Protocol

Протокол эмуляции Unix RSCS

URG

URGent pointer flag

Флаг указателя срочности (поле заголовка сегмента TCP)

URL

Universal Resource Locator

Универсальный указатель ресурса (WWW)

URN

Universal Resource Name

Универсальное имя ресурса

US

Unit Separator

Разделитель блоков

USART

Universal Synchronous-Asynchronous Receiver/Transmitter

Универсальный синхронный/асинхронный приемопередатчик

USB

Universal Serial Bus

Универсальная последовательная шина

USENET

User Net

Сеть пользователей (сеть содержит 10000 ЭВМ и 250000 пользователей и службу новостей) [Internet]

USERID

User Identification

Идентификация пользователя

USL

UnSupervised Learning

Неуправляемое обучение

USOC

Uniform Service Order Code

Однородный код службы заказов

USQ

Unsqueezed

Несжатый (о файле)

USR

User-to-User information message

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

US Robotics

Название корпорации

USRT

Universal Synchronous Receiver/Transmitter

Универсальный синхронный приемник/передатчик

USSA

User Supported Software Association

Ассоциация программной поддержки пользователей (Великобритания)

UT

Universal Time

Универсальное время (временные метки)

User Terminal

Терминал пользователя

UTC

Coordinated Universal Time

Координированное универсальное время

UTF

Unicode Transformation Format

Стандарт на преобразование Unicode

UTI

Universal Text Interchange

Универсальный текстовый обмен

UTP

Unshielded Twisted-Pair (cable)

Неэкранированные скрученные пары

UU

Uuencode/Uudecode

UNIX-кодирование/декодирование

UUCP

Unix-to-Unix Copy Program

Программа (протокол) для обмена сообщениями между UNIX- системами

UUD

UUDecoding [Unix]

UNIX-дешифровка

UUE

UUEncoding [Unix]

UNIX-кодировка

UUI

User-To-User Information

Информация от пользователя к пользователю [AT&T]

UV

Ultraviolet

Ультрафиолет

UVM

Universal Voice Module

Универсальный модуль для кодирования и передачи голоса


Previous: 10.10.20 [T]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.22 [V]


previous up down next index index
Previous: 10.10.21 [U]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.23 [W]

10.10.22 [V]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

VA

Virtual Address

Виртуальный адрес

VAC

Volts Altarnating Сurrent

Переменный ток

VAD

Value Added Dealer

 

Voice Activity Detection

Детектирование голоса (в цифровой телефонии молчание не кодируется и не передается)

VADD

Value Added Disk Driver

Более высококачественный дисковый драйвер

VAL

Value

Значение

Voice Application Language

Язык голосовых приложений

.VAL

Validity Checks

Расширение имени контрольного файла [Paradox]

VAM

Virtual Access Method

Метод виртуального доступа

VAN

Value Added Network

Более высококачественная сеть

VANS

Value-Added Network Service

Сетевая услуга существенно более высокого качества

VAP

Value Added Process

Услучшающий процесс

VAR

Variable

Переменная

VAT

Visual Audio Tool

Пакет программ для проведения видеоконференций

VAX

Virtual Address eXtension

Расширение виртуального адреса (DEC)

VAX/VMS

Virtual Address Extension/Virtual Memory System [DEC]

Операционная система ЭВМ VAX

VB

Variable Block

Переменный блок, блок переменных

Visual Basic [Microsoft]

Язык программирования графических приложений

VBA

Visual Basic for Applications

Визуальный бейсик для приложений [Microsoft]

VBE/AI

Vesa Bios Extension/Audio Interface

Расширение BIOS VESA/аудио интерфейс

VBR

Variable Bit Rate

Переменная частота бит

.VBX

Visual Basic Extension

Расширение имени файла для визуального бейсика

VC

Virtual Channel

Виртуальный канал

Virtual Container

Виртуальный контейнер

Video Conference

Видео конференция

VCC

Virtual Channel Connection

Соединение через виртуальный канал

VCD

Virtual Circuit Descritror

Дескриптор виртуального соединения

VCI

Virtual Call Identifier (ATM)

Идентификатор виртуального запроса

Virtual Channel/Circuit Identifier

Идентификатор виртуального канала/схемы

VCL

Virtual Channel Link

Виртуальный канал

VCS

Video Conference Service

Служба видеоконференций

VCD

Virtual Communications Driver

Драйвер виртуального обмена

VCDK

Video Conference Developers Kit

Система для разработчиков в сфере видеоконференций

VCPI

Virtual Control Program Interface

Программный интерфейс виртуального управления

VCR

Video Cassette Recorder

Видео магнитофон

VCSEL

Vertical Cavity Surface Emitting Laser

Поверхостно излучающий лазер с вертикальным резонатором

VDC

Volts Direct Current

Вольты постоянного тока

VDS

Virtual Disk Service

Система виртуальных дисков

VDSL

Very high data rate Digital Subscriber Line

Сверхскоростной цифровой телекоммуникационный канал (технология кабельных модемов)

VDD

Virtual Device Driver

Драйвер виртуального устройства

VDDM

Virtual Device Driver Manager

Менеджер драйвера виртуального устройства

VDE

Video Display Editor

Редактор видео дисплея

VERONICA

Very Easy Rodent-Oriented Net-wide Indexed Computerized Archives

Поисковая система GOPHER

VERR

Verify Read Access

Изменить доступ для чтения

VERW

Verify Write Access

Изменить доступ для записи

VESA

Video Electronics Standards Association

Ассоциация по стандартам в области видео электроники

VF

Variance Factor

Параметр вариации

VFAT

Virtual File Allocation Table

Таблица размещения виртуальных файлов [Microsoft]

VFD

Vacuum Fluorescent Display

Вакуумный люминисцентный дисплей

VFIP

Voice File Interchange Protocol

Протокол обмена голосовыми файлами (RFC-978)

VFSR

Very Fast Simulated Reannealing

Очень быстрый симулированный повторный отжиг

VFW

Video For Windows

Видео для Windows

VGA

Video Graphics Array

Видео графическая матрица (тип дисплея)

VGC

Video Graphics Controller

Видеографический контроллер

VGF

Voice Grade Facility

Устройство голосового качества

VGSA

Voice Grade Special Access

Специальный доступ голосового качества

VGSW

Voice Grade Switched Access

Коммутируемый доступ голосового качества

VHD

Very High Density

Очень высокая плотность

VHDL

VHSIC Hardware Description Language

Язык описания оборудования VHSIC

VHS

Very High Speed

Очень высокая скорость

Video Home System

Домашняя видео система

Virtual Host Storage

Виртуальная память ЭВМ

VHSIC

Very High Speed Integrated Circuit

Быстродействующая интегральная схема

VI

Visual Interactive

Визуальный интерактивный (редактор, UNIX)

VICP

VINES Interprocess Communication Protocol

Протокол межпроцессной коммуникации VINES

VID

Visual Interactive Debuger

Визуальный интерактивный отладчик

VILAN ID

Идентификатор виртуальной сети

VIE

Virtual Information Environment

Виртуальная информационная среда

VIF

Virtual Interface

Виртуальный интерфейс

VIM

Vendor Independent Messaging (interface)

Интерфейс обмена сообщениями, независящий от поставщика

Vendor Independent Mail

Почта, независящая от поставщика

VINES

VIrtual NEtwork operating System

Операционная система виртуальных сетей [Banyan]

Virtual Integrated NEtwork Service

Протокол виртуальных сетей (Cisco)

VIO

Video Input/Output

Видео ввод/вывод

Virtual Input/Output

Виртуальный ввод/вывод

VIP

Variable Information Processing

Обработка переменной информации

Visual Information Projection

Проекция визуальной информации

Video Information Provider

Провайдер видеоинформации

Versatile Interface Processor

Универсальный процессор интерфейса

VIPER

Verifiable Integrated Processor for Enhanced Reliability

Интегрированный процессор для улучшенной надежности

VIS

Video Information System [Tandy]

Видео информационная система

Voice Information System

Голосовая информационная система

VIU

Video Interface Unit

Блок видео интерфейса

VLAN

Virtual Local Area Network

Виртуальная локальная сеть

VL-BUS

Vesa Local-Bus

Локальная шина VESA

VLF

Very Low Frequency

Очень низкая частота

VLI

Virtual LAN Internetwork

Межсетевое взаимодействие VLAN

VLIM

Very Long Instruction Memory

Программная память с очень большой длиной команды

VLIW

Very Long Instruction Word

Очень длинный код инструкции

VLM

Virtual Loadable Modules

Виртуальные загружаемые модули

VLSI

Very Large Scale Integration

Очень большая степень интеграции

VLSM

Variable-Length Subnet Mask

Субсетевая маска переменной длины

VLT

Variable List Table

Таблица изменяемого списка

VM

Virtual Machine

Виртуальная машина

Virtual Memory

Виртуальная память

VMA

Virtual Memory Address

Адрес виртуальной памяти

VMAC

Virtual Media Access Control

Доступ к виртуальной среде

VMB

Virtual Machine Boot

Загрузка виртуальной машины

VMF

Virtual Memory File

Файл виртуальной памяти

VMI

Vertical Motion Index (HP LJ)

Индекс вертикального перемещения

VMM

Virtual Machine/Memory Manager

Менеджер виртуальной машины/памяти

VMS

Virtual Memory System

Система виртуальной памяти

Voice Message System

Система голосовых сообщений

VMT

Virtual Method Table

Таблица виртуального метода

Virtual Memory Technique

Техника виртуальной памяти

VMTP

Versatile Message Transaction Protocol

Универсальный протокол для передачи сообщений (RFC-1045)

VMOS

Vertical MOS

MOS с вертикальной структурой

VN

Version Number

Номер версии (протокол NTP)

VNA

Virtual Network Architecture

Архитектура виртуальной сети

VNCA

VTAM Node Control Application

Приложение управления узлом VTAM

VNL

Via Net Loss

 

VNS

Virtual Networking Services

Услуги виртуальной сети

VOATM

Voiсe over ATM

Передача голосовой информации через ATM

VOD

Video On Demand

Видео по запросу

VoFR

Voice over Frame Relay

Передача голоса по каналам Frame Relay

VOL

Volume

Объем (громкость)

VOHDLС

Voice over HDLC

Передача голосовой информации через HDLC

VOIP

Voice over IP

Передача голосовой информации через Интернет

VOM

Volt Ohm Meter

Вольт-омметр

VOS

Verbal Operating System

Голосовая операционная система

VOSIM

Voice Simulator

Устройство для имитации речи

VP

Virtual Pass

Виртуальный проход

VPC

Virtual Pass Connection

Соединение по виртуальному пути

VPCRF

Virtual Path Cell Relaying Function

Функция ретрансляции ячеек по виртуальному маршруту

VPD

Virtual Printer Device

Виртуальный принтер

VPDN

Virtual Private Dial-up Network

Частная виртуальная сеть с соединением черз коммутируемую телефонную сеть

VPDS

Virtual Private Data Service

Виртуальная частная информационная служба [MCI]

VPI

Virtual Pass Identifier (ATM)

Идентификатор виртуального маршрута

VPL

Virtual Path Link

Участок виртуального маршрута

VPN

Virtual Private Network

Частная виртуальная сеть

VR

Virtual Reality

Виртуальная реальность

Voltage Regulator

Регулятор напряжения

VRAM

Visual Random Access Memory

Визуальная память с произвольным доступом

VRF

VPN Routing and Forwarding

Маршрутизация и переадресация в VPN

VRML

Virtual Reality Markup Language

Язык для виртуальной реальности

VROOMM

Virtual Real-time Object Oriented Memory Manager [Borlund]

Менеджер объектно-ориентированной памяти для виртуального реального времени

VRS

Virtual Routing Service

Виртуальная маршрутизация

.VRS

WordPerfect Graphics Driver (file name extension)

Графический драйвер WordPerfect (расширение имени файла)

VRU

Voice Response Unit

Блок отклика на голос

VS

Virtual Storage

Виртуальная память

VSAM

Virtual Storage Access Method

Метод доступа к виртуальной памяти

VSAT

Very Small Aperture Terminals

Терминал с очень узкой апертурой (спутниковый канал)

VSC

Virtual Switch Controller

Контроллер виртуального коммутатора

VSE

Virtual Storage Extended

Расширенная виртуальная память

VSF

Vertical Scanning Frequency

Частота вертикального сканирования

VSI

Virtual Switch Interface

Интерфейс виртуального переключателя

VSIO

Virtual Serial Input Output

Виртуальный последовательный ввод/вывод

VSM

Virtual Shared Memory

Виртуальная память с совместным доступом

Virtual Storage Management

Управление виртуальной памятью

VSP

Video Signal Processor

Процессор видео сигнала

VSOS

Virtual Storage Operating System

Операционная система виртуальной памяти

VSR

Very Short Reach Optics

Оптический канал для передачи данных на короткие расстояния

VSYNC

Vertical Sync

Вертикальная синхронизация

VT

Vertical Tab

Вертикальный табулятор

VTAM

Virtual Telecommunication Access Method

Метод доступа к виртуальным телекоммуникациям [IBM]

VTOA

Voice and Telephone Over ATM

Голосовая и телефонная связь через ATM

VTP

Virtual Terminal Protocol

Протокол виртуального терминала

VTR

Video Tape Recorder

Видеомагнитофон

VUI

Video User Interface

Видео интерфейс пользователя

VUP

VAX Unit of Performance

Модуль мониторинга VAX

VVM

Virtual Machine Manager

Менеджер виртуальной машины

VWB

Visual WorkBench

Визуальная рабочая станция [Microsoft]

VxD

Virtual Extended Driver

Драйвер виртуального расширения [Microsoft]

V.21

CCITT standard for 300bps duplex modem over the general switched telephone network

CCITT стандарт для дуплексного модема на 300 бит/с, работающего на обычную коммутируемую телефонную сеть

V.22

CCITT standard for 1200bps duplex operation

CCITT стандарт для дуплексного модема на 1200 бит/с

V.22bis

CCITT standard for 2400bps duplex operation

CCITT стандарт для дуплексного модема на 2400 бит/с

V.23

CCITT standard for 600/1200bps modem

CCITT стандарт для модема на 600/1200 бит/с

V.24

CCITT standard for definition of circuits between a DTE and DCE

CCITT стандарт, описывающий схемы связи DTE и DCE

V.26

2400/1200 bps leased line modem

Модем на скорость 2400/1200 бит/с для выделенных линий

V.27

CCITT standard for 4800bps modem

CCITT стандарт для модема на 4800 бит/с

V.27bis

2400/4800bps leased line modem with equalizer

Модем на частоту 2400/4800 бит/с, снабженный эквилизатором и работающий на выделенную линию

V.27ter

2400/4800bps dial modem

Модем на скорость 2400/4800 бит/с с набором номера

V.29

CCITT standard for 9600bps modem over 4-wire leased line

Модем на скорость 9600 бит/с для 4-проводных выделенных линий

V.32

CCITT standard for a family of 2-wire modems operating up to 9600bps

CCITT стандарт для семейства 2-проводных модемов на частоту 9600 бит/с

V.33

CCITT standard for 14.4kbps modems over leased line

CCITT стандарт для модема на скорость 14.4 кбит/с для выделенных линий

V.34

CCITT standard for 28.2kbps modem

CCITT стандарт для модема на скорость 28.8 кбит/с

V.35

High speed 9600bps leased line modem

Высокоскоростной модем для выделенных линий на скорость 9600 бит/с

V.32bis

14400bps leased line modem

Модем для выделенных линий на скорость 14400 бит/с

V.42bis

Data compression standard

Стандарт на сжатие информации (4:1)

Previous: 10.10.21 [U]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.23 [W]


previous up down next index index
Previous: 10.10.22 [V]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.24 [X]

10.10.23 [W]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

W4

What-Works-With-What

Что работает с чем

WABI

Windows Application Binary Interface [Sun]

Двоичный интерфейс приложения Windows

WAIS

Wide Area Information Server

Информационный сервер (базы данных) региональной сети

WAITS

Wide Area Information Transfer System

Региональная система передачи информации

WAN

Wide Area Network

Региональная сеть

WAP

Wireless Application Protocol

Протокол для работы с радио приложениями (для Интернет)

WASL

Windows Aspect Script Language

Язык скриптов для Windows

WATS

Wide Area Telecommunication Service

Региональная служба телекоммуникаций

.WAV

Waveform Audio

Расширение имени звукового файла

WBC

WideBand Channel (FDDI-2)

Широкополосный канал

WBEM

Web-Base Enterprise Management

Управление предприятием на базе Web

WC

Word Count

Число слов

W-DCS

Wideband Digital Crossconnect System

Широкополосная цифровая коммутирующая система (SONET)

WDM

Wave Division Multiplexing

Мультиплексирование с делением по длине волны

Windows Driver Model

Модель драйвера для Windows

WECA

Wireless Ethernet Compatibility Alliance

Альянс совместимости беспроводных версий Ethernet

WEP

Wired Equivalent Privacy

Конфиденциальность, эквивалентная проводной связи (для беспроводных каналов)

WF

Wildcard-Filter

Стиль резервирования с произвольным выбором отправителя (RSVP)

WFQ

Weighted Fair Queue

Механизм взвешенного сокращения очередей

WFW

Windows For Workgroups

Операционная среда [Microsoft]

WGS

Work Group System

Система рабочей группы

WHOIS

Internet program-database for user address finding

База данных для нахождения адресов пользователей в Интернет

WHAM

Waveform Hold and Modify

Запоминание и модификация формы сигнала [Microsoft]

WIN

Wissenschafts Netz

Научная сеть (Германия)

WINE

Windows Emulator

Эмулятор Windows

WINForum

Wireless Information Networks Forum

Форум беспроводных информационных сетей

WINS

Windows Internet Naming Service

Служба имен Интернет для Windows

WINSOCK

Windows Open Systems Architecture

Архитектура открытых систем Windows [Microsoft]

Windows Sockets

Соединители Windows

WINWORD

Word For Windows [Microsoft]

Текстовый редактор

WISE

WordPerfect Information System Environment

Среда информационной системы WordPerfect

WISP

Wireless Internet Service Provider

Интернет провайдер беспроводной связи

.WKB

Workbook

Расширение имени файла рабочей книги [WordPerfect]

.WKE

Worksheet

Расширение имени файла рабочей страницы [Lotus 1-2-3] [LDC]

.WKQ

Spreadsheet (file name extension) [BORQU]

Расширение имени файла

WKS

Well Known Service (TCP or UDP)

Хорошо известные (стандартные) услуги

.WKS

Worksheet

Расширение имени файла рабочей страницы [Lotus 1-2-3] [LDC]

.WKZ

Compressed Spreadsheet [BORQU]

Расширение имени файла сжатой рабочей страницы (электронные таблицы)

.WK1

Worksheet

Расширение имени файла рабочей страницы [Lotus 1-2-3] [LDC]

WLL

Word Loadable Library

 

WMF

Windows Metafile Format

Формат метафайла Windows

.WMF

Windows Metafile Format

Расширение имени метафайла для Windows [Microsoft]

WML

Wireless Description Language

Язык описания беспроводного канала

WNIC

Wide-Area Network Interface Co-Processor

Сопроцессор интерфейса региональной сети

WNIM

Wide-Area Network Interface Module

Интерфейсный модуль региональной сети

WORM

Write Once Read Multiple

Однократная запись - многократное чтение (память на компактном диске)

WOS

Workstation Operating System

Операционная система рабочей станции

WOSA

Windows Open Services/Systems Architecture

Архитектура открытых систем (услуг) для Windows [Microsoft]

WP

WordPerfect

Текстовый редактор

Word Processing

Обработка слов

Write Protected

Защищено от записи

Weight Perturbation algorithm

Алгоритм возмущения весов

.WPG

Graphics

Расширение имени графического файла [WordPerfect]

WPHD

Write-Protect Hard Disk

Жесткий диск с защитой от записи

.WPK

Keyboard (file name extension)

Расширение имени файла клавиатуры [WordPerfect]

WPM

Words Per Minute

Число слов в минуту

.WPM

Macro

Расширение имени файла макро [WordPerfect]

WPOS

Workplace Operating System

Операционная система рабочего места

WPS

Windows Printing System

Система печати Windows [Microsoft]

Workplace Shell [OS2]

Ядро рабочего места

WRAM

Window RAM

Память для видеосистем

WRED

Weighted Random Early Detection

Алгоритм управления очередями

WRI

World Resources Institute

Институт всемирных исследований

WS

WordStar

 

Workstation

Рабочая станция

WSDL

WEB Services Description Language

Язык описания WEB-услуг

WSF

Work Station Function

Функция рабочей станции

WSH

Windows Scripting Host

ЭВМ подготовки сценариев

WT

Write Through

Сквозная запись

WTDM

Wavelength & time division Multiplexing

Мультиплексирование с деление по времени и частоте

WUPO

Wad Up Printer Output. Assembly language opcode

Программа управления выводом на принтер, написанная на ассемблере

WWIS

World Wide Information System [Internet]

Всемирная информационная система

WWW

World Wide Web

Всемирная сеть (распределенная информационная система)

W3

WWW - World Wide Web

"Всемирная паутина"

WYSBYGI

What You See Before You Get It

То, что вы видите, перед тем как получите

WYSIWYG

What You See Is What You Get

Что видите, то и получите


Previous: 10.10.22 [V]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.24 [X]


previous up down next index index
Previous: 10.10.23 [W]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.25 [Y]

10.10.24 [X]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

XAB

eXternal Attribute Buffers (CMS)

Буферы внешних атрибутов

XALS

EXtended Application Layer Structure

Структура слоя расширенных приложений

XAPIA

X.400 Application Program Interface Association

Ассоциация программного интерфейса приложений X.400

X2B

Hexadecimal to Binary [REXX]

Преобразование шестнадцатеричного кода в двоичный

XBM

X BitMap

Формат графического файла

X2C

Hexadecimal to Character [REXX]

Преобразование шестнадцатеричного кода в символ

XCMD

External Command

Внешняя команда

XCOPY

Extended Copy

Расширенная копия

X2D

Hexadecimal to Decimal [REXX]

Преобразование шестнадцатеричного кода в десятичный

XDR

eXternal Data Representation standard (RFC 1014)

Стандарт представления внешней информации

XDMCP

X Display Network Manager Control Protocol

Протокол управления для сетевого менеджера Х-терминала

XFCN

External Function

Внешняя функция

XGA

Extended Graphics Array [IBM]

Массив расширенной графики

XID

EXchange IDentification (used by HDLC/FDDI)

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

XIO

EXecute Input/output

Выполнить ввод/вывод

XIP

eXecute In Place

Выполнить на месте (в памяти)

XIOS

Extended Input/Output System

Система расширенного ввода/вывода

XLINK

EXtended Lokales Informatik Netz Karlsruhe

Расширенная локальная информационная сеть Карлсруэ

XLM

Excel Macro Language [Microsoft]

Язык макро Exel

XML

eXtensible Markup Language

Расширенный язык разметки (для применения SGML)

XMM

Extended Memory Manager [LIM/AST]

Менеджер расширенной памяти

XMS

EXtended Memory Specification [LIM/AST]

Спецификация расширенной памяти

XNS

Xerox Network System

Сетевой протокол Xerox

XOR

Exclusive OR (Also EOR)

Исключающее ИЛИ

XOT

X.25 over TCP/IP

X.25 поверх TCP/IP

XPM

X PixMap

Формат графических файлов

XSL

Extensible Stylesheet Language

Язык масштабируемых стилевых листов

XSMD

Extended Storage Module Drive (interface)

Интерфейс модуля расширенной памяти

XTCLK

External Transmit Clock

Внешние часы для синхронизации передачи

XTI

X/open Transport Layer Interface

Интерфейс транспортного уровня X/open

XTP

Xpress Transport Protocol

Транспортный протокол Xpress

XUI

X User Interface

Интерфейс пользователя для X-Windows

XXX

X.3, X.28, X.29

Комплект протоколов, обеспечивающих работу в сети X.25

X.3

CCITT standard for a pocket assembler/disassembler (PAD)

CCITT стандарт для пакетного ассемблера/дизассемблера (ПАД)

X.12

ANSI committee for Electronic Data Interchange

Комитет ANSI по электронному информационному обмену

X.21

CCITT standard for circuit-switched networks, DTE/DCE 15-pin interface

CCITT стандарт для сетей со схемами переключения, стандарт на 15-штырьковый разъем интерфейса DTE/DCE

X.25

Low level packet switch. CCITT protocol up to 64kB

CCITT протокол для скоростей обмена до 64 Кбит/с

X.28

CCITT protocol for asynchronous terminal to communicate with an X.3 PAD networks

Протокол CCITT для асинхронного терминала, предназначенного для работы с сетями X.3 PAD

X.29

CCITT protocol for synchronous DTE (Host) to control & communicate with an X.3 PAD

CCITT протокол синхронного DTE для управления и обмена с X.3 PAD

X.75

CCITT protocol for interconnecting separate X.25

CCITT протокол для связи отдельных X.25 сетей

X.81

Internetworking between ISDN and public (e.g., X.21) circuit-switched networks

Межсетевая связь ISDN и общедоступными сетями с коммутируемыми каналами (напр. X.21)

X.110

CCITT standard for routing principles on public data networks

CCITT стандарт для принципов маршрутизации общедоступных информационных сетей

X.121

CCITT numbering plan for public data networks

Схема нумерации CCITT для общедоступных информационных сетей

X.200

CCITT version of the OSI reference model

Версия CCITT эталонной модели OSI

X.208

CCITT version of the OSI ASN.1

CCITT-версия OSI ASN.1

X.209

CCITT version of the OSI ASN.1 Basic Encoding Rules

Версия CCITT OSI базовых правил кодирования (BER) ASN.1

X.211

Physical service definition for OSI for CCITT applications

Описание физического уровня для приложений OSI для CCITT

X.212

Data link service definitions for OSI for CCITT applications

Определения канальных услуг для приложений CCITT

X.213

Network layer service definition for OSI for CCITT applications

Описание услуг сетевого уровня для приложений OSI CCITT

X.214

Transport service definition for OSI for CCITT applications

Описание транспортных услуг для приложений CCITT

X.215

Session service definition for OSI for CCITT applications

Определение сессий для приложений OSI CCITT

X.216

Presentation service definition for OSI for CCITT applications

Определение презентаций для OSI CCITT приложений

X.217

ACSE definition for OSI for CCITT applications

Определение ACSE для OSI CCITT приложений

X.218

CCITT equivalent of ISO 9066-1: Text communication reliable transfer

Эквивалент ISO 9066. Надежная передача текстовой информации.

X.219

CCITT equivalent of the ISO Remote Operations Service Element (ROSE)

Эквивалент элемента удаленных операционных услуг ISO

X.220

CCITT specification of the use of X.200-series protocols in CCITT applications

Спецификация использования протоколов X.200 в CCITT приложениях

X.223

Use of X.25 to provide the OSI connection mode network service

Использование X.25 для обеспечения сетевой услуги в режиме OSI связи

X.400

CCITT E-mail standard

Стандарт электронной почты

X.402

CCITT message-handling services

Стандарт CCITT на систему обработки сообщений

X.403

CCITT message-handling system: Conformance testing

Система обработки сообщений; проверка соответствия

X.407

CCITT message-handling system: Abstract service definitions conventions

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

X.408

CCITT message-handling system: Encoded information type conversion rules.

Система обработки сообщений; правила преобразования закодированных типов информации

X.411

CCITT message-handling system: Message transfer system: Abstract service definitions procedures

Система обработки сообщений; система передачи сообщений; процедуры определения абстрактных услуг

X.413

CCITT message-handling system: Message store: Abstract service definitions

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

X.419

CCITT message-handling system: Protocol specifications

Система обработки сообщений; спецификации протокола

X.420

CCITT message-handling system: Interpersonal messaging system

Система обработки сообщений; система обмена сообщениями между людьми

X.500

OSI based directory standard

Стандарт на каталог, базирующийся на OSI (RFC 1279, 1275, 1274)

X.509

CCITT directory: Authentication framework

Каталог CCITT: рамки авторизации

X.511

CCITT directory: Abstract service definition

Каталог CCITT: абстрактные определения услуг

X.519

CCITT directory: Protocol specification

Каталог CCITT: спецификация протокола

X.520

CCITT directory: Selected attribute types

Каталог CCITT: выбранные типы атрибутов

X.521

CCITT directory: Selected object classes

Каталог CCITT: выбранные классы объектов


Previous: 10.10.23 [W]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.25 [Y]


previous up down next index index
Previous: 10.10.24 [X]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.26 [Z]

10.10.25 [Y]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

YAM

Yet Another Modem [Omen Technology]

 

YAPT

Yet Another Patch Tape (SLIP for SUN)

 

YP

Yellow Pages

"Желтые страницы", телефонный справочник


Previous: 10.10.24 [X]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.26 [Z]


previous up down next index index
Previous: 10.10.25 [Y]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций

10.10.26 [Z]
Семенов Ю.А. (ГНЦ ИТЭФ)

Сокращение Английская расшифровка Русская расшифровка

ZAW

Zero Administration for Windows

Нуль-администрирование для Windows

ZBR

Zone-Bit Recording

Запись бита зоны

ZDL

Zero Delay Lockout

Запирание с нулевой задержкой

ZDS

Zenith Data Systems

Информационная система Zenith

ZEN

Zero Effort Networking

Продукт Novell

ZIF

Zero Insertion Force (connector)

Разъем с нулевым усилием сочленения

ZIP

Zone Information Protocol (AppleTalk)

Протокол информационной зоны

Zigzag In-Line Package

Корпус с зигзагообразно расположенными контактами

Zone Improvement Plan (ZIPcode)

Улучшенная схема штриховых кодов

ZIPP

Zigzag In-line Pin Package

Корпус ИС с зигзагообразным расположением контактов

ZMH

Zone Mail Hour

Зонный час почты

ZSL

Zero Slot LAN

Локальная сеть


Previous: 10.10.25 [Y]    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций


previous up down next index index
Previous: 10.9 Набор AT-команд модемов    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.10.1 [A]

10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)
Семенов Ю.А. (ГНЦ ИТЭФ)

Обширный файл английских сокращений по данной тематике можно найти по адресу ftp.temple.edu /pub/info/help-net/babel95c.txt. Возможен доступ к этому файлу и через listserv@vm.temple.edu или с помощью gopher.temple.edu, существуют и другие источники аналогичной информации, например, http://acm.org/~jochen _hayek/jochan_hayer_18.html#sec291 или www.srl.rmit.edu.au /pg/general/diction.html. Там же можно найти много и других справочных данных.

a b c d e f g h i j k l m

n o p q r s t u v w x y z

Previous: 10.9 Набор AT-команд модемов    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.10.1 [A]


previous up next index index
Previous: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.13 Список кодов и откликов на почтовые команды и сообщения

10.12 Национальные коды доменов в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ)

Обычно завершающий код Internet-адреса определяет государственную принадлежность узла, сервера или ЭВМ (информация взята на сервере RIPE Network Coordination Center (X.500 в ISO 3166)). Информация упорядочена согласно англоязычным названиям стран.

Страна

Английское название

Двухбуквенный код

Трехбуквенный код

Числовой код

Афганистан

AFGHANISTAN

AF

AFG

004

Албания

ALBANIA

AL

ALB

008

Алжир

ALGERIA

DZ

DZA

012

Американское Самоа

AMERICAN SAMOA

AS

ASM

016

Андорра

ANDORRA

AD

AND

020

Ангола

ANGOLA

AO

AGO

024

ANGUILLA

AI

AIA

660

Антарктика

ANTARCTICA

AQ

ATA

010

Антигуа и Барбуда

ANTIGUA AND BARBUDA

AG

ATG

028

Аргентина

ARGENTINA

AR

ARG

032

Армения

ARMENIA

AM

ARM

051

Аруба

ARUBA

AW

ABW

533

Австралия

AUSTRALIA

AU

AUS

036

Австрия

AUSTRIA

AT

AUT

040

Азербайджан

AZERBAIJAN

AZ

AZE

031

Багамские острова

BAHAMAS

BS

BHS

044

Бахрейн

BAHRAIN

BH

BHR

048

Бангладеш

BANGLADESH

BD

BGD

050

Барбадос

BARBADOS

BB

BRB

052

Беларусь

BELARUS

BY

BLR

112

Бельгия

BELGIUM

BE

BEL

056

Белиз

BELIZE

BZ

BLZ

084

Бенин

BENIN

BJ

BEN

204

Бермудские острова

BERMUDA

BM

BMU

060

Бутан

BHUTAN

BT

BTN

064

Боливия

BOLIVIA

BO

BOL

068

Босния и Герцеговина

BOSNIA AND HERZEGOWINA

BA

BIH

070

Ботсвана

BOTSWANA

BW

BWA

072

BOUVET ISLAND

BV

BVT

074

Бразилия

BRAZIL

BR

BRA

076

Британская территория в Индийском океане

BRITISH INDIAN OCEAN TERRITORY

IO

IOT

086

Бруней

BRUNEI DARUSSALAM

BN

BRN

096

Болгария

BULGARIA

BG

BGR

100

Буркина Фасо

BURKINA FASO

BF

BFA

854

Бурунди

BURUNDI

BI

BDI

108

Камбоджа

CAMBODIA

KH

KHM

116

Камерун

CAMEROON

CM

CMR

120

Канада

CANADA

CA

CAN

124

CAPE VERDE

CV

CPV

132

Каймановы острова

CAYMAN ISLANDS

KY

CYM

136

Центрально Африканская Республика

CENTRAL AFRICAN REPUBLIC

CF

CAF

140

Чад

CHAD

TD

TCD

148

Чили

CHILE

CL

CHL

152

Китай

CHINA

CN

CHN

156

Остров Рождества

CHRISTMAS ISLAND

CX

CXR

162

Кокосовые острова

COCOS (KEELING) ISLANDS

CC

CCK

166

Колумбия

COLOMBIA

CO

COL

170

Каморы

COMOROS

KM

COM

174

Конго

CONGO

CG

COG

178

Острова Кука

COOK ISLANDS

CK

COK

184

Коста-Рика

COSTA RICA

CR

CRI

188

Кот де Вуар

COTE D'IVOIRE

CI

CIV

384

Хорватия

CROATIA

HR

HRV

191

Куба

CUBA

CU

CUB

192

Кипр

CYPRUS

CY

CYP

196

Чешская республика

CZECH REPUBLIC

CZ

CZE

203

Дания

DENMARK

DK

DNK

208

Джибути

DJIBOUTI

DJ

DJI

262

Доминика

DOMINICA

DM

DMA

212

Доминиканская республика

DOMINICAN REPUBLIC

DO

DOM

214

Восточный Тимор

EAST TIMOR

TP

TMP

626

Эквадор

ECUADOR

EC

ECU

218

Египет

EGYPT

EG

EGY

818

Сальвадор

EL SALVADOR

SV

SLV

222

Экваториальная Гвинея

EQUATORIAL GUINEA

GQ

GNQ

226

Эритрея

ERITREA

ER

ERI

232

Эстония

ESTONIA

EE

EST

233

Эфиопия

ETHIOPIA

ET

ETH

231

Фолклендские острова

FALKLAND ISLANDS

FK

FLK

238

Острова Фаро

FAROE ISLANDS

FO

FRO

234

Фиджи

FIJI

FJ

FJI

242

Финляндия

FINLAND

FI

FIN

246

Франция

FRANCE

FR

FRA

250

Франция, метрополия

FRANCE, METROPOLITAN

FX

FXX

249

Французская Гвинея

FRENCH GUIANA

GF

GUF

254

Французская Полинезия

FRENCH POLYNESIA

PF

PYF

258

Французские Южные территории

FRENCH SOUTHERN TERRITORIES

TF

ATF

260

Габон

GABON

GA

GAB

266

Гамбия

GAMBIA

GM

GMB

270

Грузия

GEORGIA

GE

GEO

268

Германия

GERMANY

DE

DEU

276

Гана

GHANA

GH

GHA

288

Гибралтар

GIBRALTAR

GI

GIB

292

Греция

GREECE

GR

GRC

300

Гренландия

GREENLAND

GL

GRL

304

Гренада

GRENADA

GD

GRD

308

Гваделупа

GUADELOUPE

GP

GLP

312

Гуам

GUAM

GU

GUM

316

Гватемала

GUATEMALA

GT

GTM

320

Гвинея

GUINEA

GN

GIN

324

Гвинея-Биссау

GUINEA-BISSAU

GW

GNB

624

Гайана

GUYANA

GY

GUY

328

Гаити

HAITI

HT

HTI

332

HEARD AND MC DONALD ISLANDS

HM

HMD

334

Гондурас

HONDURAS

HN

HND

340

Гонконг

HONG KONG

HK

HKG

344

Венгрия

HUNGARY

HU

HUN

348

Исландия

ICELAND

IS

ISL

352

Индия

INDIA

IN

IND

356

Индонезия

INDONESIA

ID

IDN

360

Иран

IRAN

IR

IRN

364

Ирак

IRAQ

IQ

IRQ

368

Ирландия

IRELAND

IE

IRL

372

Израиль

ISRAEL

IL

ISR

376

Италия

ITALY

IT

ITA

380

Ямайка

JAMAICA

JM

JAM

388

Япония

JAPAN

JP

JPN

392

Иордания

JORDAN

JO

JOR

400

Казахстан

KAZAKHSTAN

KZ

KAZ

398

Кения

KENYA

KE

KEN

404

Кирибати

KIRIBATI

KI

KIR

296

КНДР

KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF

KP

PRK

408

Корея

KOREA

KR

KOR

410

Кувейт

KUWAIT

KW

KWT

414

Киргизстан

KYRGYZSTAN

KG

KGZ

417

Лаос

LAO PEOPLE'S DEMOCRATIC REPUBLIC

LA

LAO

418

Латвия

LATVIA

LV

LVA

428

Леван

LEBANON

LB

LBN

422

Лесото

LESOTHO

LS

LSO

426

Либерия

LIBERIA

LR

LBR

430

Ливия

LIBYAN ARAB JAMAHIRIYA

LY

LBY

434

Лихтенштейн

LIECHTENSTEIN

LI

LIE

438

Литва

LITHUANIA

LT

LTU

440

Люксембург

LUXEMBOURG

LU

LUX

442

Макао

MACAU

MO

MAC

446

Македония

MACEDONIA,

MK

MKD

807

Мадагаскар

MADAGASCAR

MG

MDG

450

Малави

MALAWI

MW

MWI

454

Малайзия

MALAYSIA

MY

MYS

458

Мальдивские острова

MALDIVES

MV

MDV

462

Мали

MALI

ML

MLI

466

Мальта

MALTA

MT

MLT

470

Маршалловы острова

MARSHALL ISLANDS

MH

MHL

584

Мартиника

MARTINIQUE

MQ

MTQ

474

Мавритания

MAURITANIA

MR

MRT

478

Маврикий

MAURITIUS

MU

MUS

480

MAYOTTE

YT

MYT

175

Мексика

MEXICO

MX

MEX

484

Микронезия

MICRONESIA

FM

FSM

583

Молдова

MOLDOVA

MD

MDA

498

Монако

MONACO

MC

MCO

492

Монголия

MONGOLIA

MN

MNG

496

MONTSERRAT

MS

MSR

500

Марокко

MOROCCO

MA

MAR

504

Мозамбик

MOZAMBIQUE

MZ

MOZ

508

MYANMAR

MM

MMR

104

Намибия

NAMIBIA

NA

NAM

516

Остров Науру

NAURU

NR

NRU

520

Непал

NEPAL

NP

NPL

524

Нидерланды

NETHERLANDS

NL

NLD

528

Нидерландские Антиллы

NETHERLANDS ANTILLES

AN

ANT

530

Новая Каледония

NEW CALEDONIA

NC

NCL

540

Новая Зеландия

NEW ZEALAND

NZ

NZL

554

Никарагуа

NICARAGUA

NI

NIC

558

Нигер

NIGER

NE

NER

562

Нигерия

NIGERIA

NG

NGA

566

NIUE

NU

NIU

570

Остров Норфолк

NORFOLK ISLAND

NF

NFK

574

Северные Марианские острова

NORTHERN MARIANA ISLANDS

MP

MNP

580

Норвегия

NORWAY

NO

NOR

578

Оман

OMAN

OM

OMN

512

Пакистан

PAKISTAN

PK

PAK

586

Остров Палау

PALAU

PW

PLW

585

Панама

PANAMA

PA

PAN

591

Папуа Новая Гвинея

PAPUA NEW GUINEA

PG

PNG

598

Парагвай

PARAGUAY

PY

PRY

600

Перу

PERU

PE

PER

604

Филиппины

PHILIPPINES

PH

PHL

608

Остров Питкэрн

PITCAIRN

PN

PCN

612

Польша

POLAND

PL

POL

616

Португалия

PORTUGAL

PT

PRT

620

Пуэрто-Рико

PUERTO RICO

PR

PRI

630

Катар

QATAR

QA

QAT

634

Реюньон

REUNION

RE

REU

638

Румыния

ROMANIA

RO

ROM

642

Россия

RUSSIAN FEDERATION

RU

RUS

643

Руанда

RWANDA

RW

RWA

646

Сант Китс и Невис

SAINT KITTS AND NEVIS

KN

KNA

659

Сент-Люсия

SAINT LUCIA

LC

LCA

662

Сент-Винсент и Гренадины

SAINT VINCENT AND THE GRENADINES

VC

VCT

670

Самоа

SAMOA

WS

WSM

882

Сан-Марино

SAN MARINO

SM

SMR

674

Сан Томе и Принсипи

SAO TOME AND PRINCIPE

ST

STP

678

Саудовская Аравия

SAUDI ARABIA

SA

SAU

682

Сенегал

SENEGAL

SN

SEN

686

Сейшельские острова

SEYCHELLES

SC

SYC

690

Сиерра-Леоне

SIERRA LEONE

SL

SLE

694

Сингапур

SINGAPORE

SG

SGP

702

Словакия

SLOVAKIA

SK

SVK

703

Словения

SLOVENIA

SI

SVN

705

Соломоновы острова

SOLOMON ISLANDS

SB

SLB

090

Сомали

SOMALIA

SO

SOM

706

Южная Африка

SOUTH AFRICA

ZA

ZAF

710

Южная Георгия и Южные Сэндвичевы острова

SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS

GS

SGS

239

Испания

SPAIN

ES

ESP

724

Шри-Ланка

SRI LANKA

LK

LKA

144

Св. Елена

ST. HELENA

SH

SHN

654

Сен-Пьер и Микелон

ST. PIERRE AND MIQUELON

PM

SPM

666

Судан

SUDAN

SD

SDN

736

Суринам

SURINAME

SR

SUR

740

Острова Свалбард и Ян-Майена

SVALBARD AND JAN MAYEN ISLANDS

SJ

SJM

744

Свазиленд

SWAZILAND

SZ

SWZ

748

Швеция

SWEDEN

SE

SWE

752

Швейцария

SWITZERLAND

CH

CHE

756

Сирия

SYRIAN ARAB REPUBLIC

SY

SYR

760

Тайвань

TAIWAN, PROVINCE OF CHINA

TW

TWN

158

Таджикистан

TAJIKISTAN

TJ

TJK

762

Танзания

TANZANIA

TZ

TZA

834

Таиланд

THAILAND

TH

THA

764

Того

TOGO

TG

TGO

768

Острова Токелау

TOKELAU

TK

TKL

772

Тонга

TONGA

TO

TON

776

Тринидад и Тобаго

TRINIDAD AND TOBAGO

TT

TTO

780

Тунис

TUNISIA

TN

TUN

788

Турция

TURKEY

TR

TUR

792

Туркменистан

TURKMENISTAN

TM

TKM

795

TURKS AND CAICOS ISLANDS

TC

TCA

796

Тувалу

TUVALU

TV

TUV

798

Уганда

UGANDA

UG

UGA

800

Украина

UKRAINE

UA

UKR

804

Объединенные арабские Эмираты

UNITED ARAB EMIRATES

AE

ARE

784

Великобритания

UNITED KINGDOM

GB

GBR

826

Соединенные Штаты

UNITED STATES

US

USA

840

UNITED STATES MINOR OUTLYING ISLANDS

UM

UMI

581

Уругвай

URUGUAY

UY

URY

858

Узбекистан

UZBEKISTAN

UZ

UZB

860

Вануату

VANUATU

VU

VUT

548

Ватикан

VATICAN CITY STATE (HOLY SEE)

VA

VAT

336

Венесуэла

VENEZUELA

VE

VEN

862

Вьетнам

VIET NAM

VN

VNM

704

Виргинские острова (ВБ)

VIRGIN ISLANDS (BRITISH)

VG

VGB

092

Виргинские острова (США)

VIRGIN ISLANDS (U.S.)

VI

VIR

850

Острова Эллис и Футуна

WALLIS AND FUTUNA ISLANDS

WF

WLF

876

Западная Сахара

WESTERN SAHARA

EH

ESH

732

Йемен

YEMEN

YE

YEM

887

Югославия

YUGOSLAVIA

YU

YUG

891

Заир

ZAIRE

ZR

ZAR

180

Замбия

ZAMBIA

ZM

ZMB

894

Зимбабве

ZIMBABWE

ZW

ZWE

716

Previous: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.13 Список кодов и откликов на почтовые команды и сообщения


previous up next index index
Previous: 10.12 Национальные коды доменов в Интернет    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.14 Принципы формирования кода отклика в системе SMTP

10.13 Список кодов и откликов на почтовые команды и сообщения
Семенов Ю.А. (ГНЦ ИТЭФ)

Код Назначение

211

Сообщение о состоянии системы или справочный отклик (help).

214

Help message - сообщение для сведения. [Информация о том, как использовать приемник или значение конкретной нестандартной команды; этот отклик полезен только для пользователей-людей].

220

<domain> Service ready - сервер готов к обслуживанию.

221

<domain> Service closing transmission channel - сервер закрывает канал;

250

Requested mail action okay, completed - процедура успешно завершена;

251

User not local; will forward to <forward-path> - адресат не местный, сообщение ему будет переадресовано.

354

Start mail input; end with <CRLF>.<CRLF> - начало ввода сообщения, завершение символьной последовательностью <CRLF>.<CRLF>.

421

<domain> Service not available, closing transmission channel - сервер не доступен, процедура прерывается. [Это может быть ответом на любую команду, если сервер знает, что он должен прервать обслуживание]

450

Requested mail action not taken: mailbox unavailable - запрошенная процедура не выполнена [Напр., из-за отсутствия доступа к почтовому ящику].

451

Requested action aborted: error in processing - выполнение процедуры прервано из-за ошибки.

452

Requested action not taken: insufficient system storage - операция не выполнена из-за недостатка системной памяти.

500

Syntax error, команда не узнана. [Среди прочего, это может указывать на то, что командная строка имеет слишком большую длину].

501

Syntax error in parameters or arguments - синтаксическая ошибка в параметрах или аргументах.

502

Command not implemented - нелегальная команда.

503

Bad sequence of commands - неудачная последовательность команд.

504

Command parameter not implemented - ошибка в параметрах команды.

550

Requested action not taken: mailbox unavailable - Запрошенная операция не выполнена [Напр., почтовый ящик не найден или доступ к нему невозможен].

551

User not local; please try <forward-path> - адресат не местный, рекомендуется переадресовать сообщение по адресу <forward-path>.

552

Requested mail action aborted: exceeded storage allocation - операция прервана из-за превышения лимитов памяти (слишком много адресатов или слишком длинное сообщение).

553

Requested action not taken: mailbox name not allowed - операция не выполнена [Например, ошибка в записи адреса почтового ящика].

554

Transaction failed - процедура не выполнена.

Previous: 10.12 Национальные коды доменов в Интернет    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.14 Принципы формирования кода отклика в системе SMTP


previous up next index index
Previous: 10.13 Список кодов и откликов на почтовые команды и сообщения    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.15 Базовые протоколы Internet

10.14 Принципы формирования кода отклика в системе SMTP
Семенов Ю.А. (ГНЦ ИТЭФ)

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

Код Назначение

1yz

Промежуточный позитивный отклик. Команда воспринята. Отправитель должен послать следующую команду.

2yz

Позитивное подтверждение завершения операции. Можно посылать следующий запрос.

3yz

Позитивный промежуточный отклик, сходный с 1yz, используется в случае групповых команд.

4yz

Временный негативный отклик. Команда не исполнена, но характер ошибки временный и выполнение процедуры может быть позже повторено.

5yz

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

Вторая цифра кода может иметь следующие значения:

x0z

Синтаксис - эти отклики относятся к синтаксическим ошибкам или к командам синтаксически корректным но примененным неправильно.

x1z

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

x2z

Соединения - относится к телекоммуникационному каналу.

x3z

Пока не определен.

x4z

Пока не определен.

x5z

Почтовая система - эти отклики индицируют статус получателя или отправителя почты.

Третья цифра уточняет смысл второй.

Previous: 10.13 Список кодов и откликов на почтовые команды и сообщения    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.15 Базовые протоколы Internet


previous up next index index
Previous: 10.14 Принципы формирования кода отклика в системе SMTP    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.16 Разъем AUI

10.15 Базовые протоколы Internet
Семенов Ю.А. (ГНЦ ИТЭФ)

Протокол

Описание

RFC

ARP

Address Resolution Protocol

826

BFTP

Background File Transfer Protocol

1068

BGP

Border Gateway Protocol (внешний протокол маршрутизации)

1105,1265-68, 1397, 1654-56

BOOTP

Bootstrap Protocol (протокол загрузки)

951,1048,1084

CIDR

Classless Inter-Domain Routing protocol

1519,1520

CLNP

ConnectionLess Network Protocol (ISO-8474)

1526,1561,1575

CLOCK

DCNET Time Server Protocol

778

CMOT

Common Management Information Service and Protocol over TCP/IP

1095

DNS

Domain Name Service (система распознавания имен доменов)

1713, 1712, 1612, 1611, 1383

DOMAIN

Domain Name System (DNS)

1034, 1035, 1032, 974

DVMRP

Distance Vector Multicast Routing Protocol

1075

ECHO

Эхо протокол

862

EGP

Exterior Gateway Protocol

904, 911, 1092, 1093

FINGER

Finger-протокол

1288,724

FTP

File Transfer Protocol (протокол пересылки файлов)

959

HEMP

High level Entity Management Protocol

1022

HEMS

High level Entity Management System

1021

HMP

Host Monitoring Protocol

869

GGP

Gateway to Gateway Protocol

823

ICMP

Internet Control Message Protocol

792,1256

IDRP

Inter-Domain Routing Protocol

1477,1479

IGMP

Internet Group Multicast Protocol

1112

IGP

Interior Gateway Protocol

1074,1371

IP

Internet протокол

791

IP субсети

950

IP широковещательные дейтограммы

919

то же для субсетей

922

IP-ARC

Internet протокол для Arcnet

1051

IP-E

Internet протокол для Ethernet

895

IP-FDDI

Передача IP через FDDI

1103

IP-SLIP

Передача IP по последовательным линиям

1055

IPM

Internet-протокол для сообщений

759

IRC

Internet Relay Chat

1459

IS-IS

OSI-междоменный протокол маршрутизации

1195,1142

MAIL

Формат сообщений электронной почты

822, 821, 1351, 1352

MIB-II

Management Information Base-II

1213

MIME

Multipurpose Internet Mail Extensions

1521,1522

NETBIOS

NetBIOS Service Protocols

1001,1002

NETRJE

Network Remote Job Entry Program

740,725

NETRJS

Network Remote Job Service

477,436

NFS

Network File System (файловая система)

1094

NNTP

Network News Transfer Protocol

977

NTP

Network Time Protocol

1119,1128-29

NUMBERS

Assigned Numbers

1700

OSPF

Open Shortest Pass First Protocol (маршрутный протокол "кратчайший путь лучше")

1131, 1245 -48, 1253, 1370, 1583-87

PCMAIL

PVmail Transport Protocol

1056

POP

Post Office Protocol

937, 1081, 1082, 1460

RAP

Router-Access Protocol

1476

PPP

Point-to-Point Protocol

1134

RARP

Reverse Address Resolution Protocol

903

RDP

Reliable Data Protocol

908

RIP

Routing Information Protocol (внутренний протокол маршрутизации)

1058, 1387, 1389, 1581, 1582,1388

RLP

Resource Location Protocol

887

RPC

Remote Procedure Call Protocol

1057,1050

SFTP

Simple File Transfer Protocol

913

SLIP

Serial Line IP (Интернет по послед. линии)

1055

SMI

Structure of Management Information

1155

SMTP

Simple Mail Transfer Protocol SMTP через X.25

821, 1090

SNMP

Simple Network Management Protocol SNMP в Ethernet

1157, 1089

TCP

Transmission Control Protocol

793

TELNET

Протокол удаленного доступа

854,856-861, 885, 927, 933, 946, 1041, 1043, 1053, 1073, 1079, 1093, 1096, 1097, 1143, 1184, 1205, 1372, 1411, 1412, 1416, 1571, 1572

TFTP

Trivial File Transfer Protocol

1350

UDP

User Datagram Protocol

768

USERS

Протокол активных пользователей

866

UUCP

Электронная почта под UNIX

976

VFIP

Voice File Interchange Protocol

978

VMTP

Versatile Message Transfer Protocol

1045

XDR

EXternal Data Representation

1014

X-Windows

Системный протокол X-Windows

1198,1013

Previous: 10.14 Принципы формирования кода отклика в системе SMTP    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.16 Разъем AUI


previous up next index index
Previous: 10.15 Базовые протоколы Internet    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.17 Разводка разъемов

10.16 Разъем AUI
Семенов Ю.А. (ГНЦ ИТЭФ)

Номер контакта

Название

Назначение

1

CI-S

Вход управления, экран

2

CI-A

Вход управления, схема А

3

DO-A

Выход данных, схема А

4

DI-S

Вход данных, экран

5

DI-A

Вход данных, схема А

6

VC

Общая шина питания

7

CO-A

Выход управления, схема А

8

CO-S

Выход управления, экран

9

CI-B

Вход управления, схема В

10

DO-B

Выход данных, схема В

11

DO-S

Выход данных, экран

12

DI-B

Вход данных, схема В

13

VP

Напряжение плюс

14

VS

Напряжение экран

Оплетка

PG

Защитная земля (проводящая оплетка)

Previous: 10.15 Базовые протоколы Internet    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.17 Разводка разъемов


previous up next index index
Previous: 10.16 Разъем AUI    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.18 Краткий справочник по командам UNIX

10.17 Разводка разъемов
Семенов Ю.А. (ГНЦ ИТЭФ)

RJ-11 (6 контактов)

Контакт

Назначение

1

Не используется (иногда земля)

2

Прием +

3

Передача +

4

Передача -

5

Прием -

6

Не используется (иногда земля)

Телефонный разъем

Применение неэкранированных скрученных пар

Использование

Ножки разъема

1-2

3-6

4-5

7-8

Аналоговая передача голоса

-

-

TR/RX

-

10BASE-T

TX

RX

-

-

100BASE-TX

TX

RX

-

-

100BASE-T4

TX

RX

-

-

100BASE-VG

BI

BI

BI

BI

ISDN

Питание

TX

RX

Питание

Token Ring

-

TX

RX

-

ATM-пользователь

TX

   

RX

ATM-разветвитель

RX

   

TX

TX - передача; RX - прием; BI - двунаправленная передача/прием.

Интерфейс RS-530

Разводка разъема интерфейса RS-232

Номер контакта

Сторона ЭВМ (DTE) Разъем DB25M

Устройство передачи данных (DCE) Разъем DB25F

1

Экран

Экран

2

Выход передачи данных (TD)

Вход приема данных (RD)

3

Вход приема данных (RD)

Выход передачи данных (TD)

4

Запрос передачи данных (RTS)

Запрос приема данных (CTS)

5

Запрос приема данных (CTS)

Запрос передачи данных (RTS)

6

Вход готовности (DSR)

Выход готовности (DTR)

7

Земля сигнала

Земля сигнала

8

Вход CD (Carrier Detect)

Выход CD (Carrier Detect)

20

DTE готов (DTR)

DCE готов (DSR)

22

Индикатор вызова (RI)

Индикатор вызова (RI)

Интерфейс V.24/RS-232 (9-контактный)

Интерфейс V.35

Интерфейс X.21

Интерфейс V.36/RS-449

Previous: 10.16 Разъем AUI    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.18 Краткий справочник по командам UNIX


previous up next index index
Previous: 10.17 Разводка разъемов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.19 Символьный набор HTML

10.18 Краткий справочник по командам UNIX
Семенов Ю.А. (ГНЦ ИТЭФ)

Первая версия UNIX была создана в 1971 году, в 1979 году была подготовлена 7-я редакция (Bourne Shell и компилятор С, разработанная Керниганом и Ритчи; тогда же фирма Microsoft купила права и разработала свою версию для РС - XENIX). Первая версия BSD (Беркли) была подготовлена в 1978 году. В 1981 году закончена версия, поддерживающая стек протоколов TCP/IP (4.2BSD). В 1990 году в UNIX была встроена система NFS. Несколько лет назад в университете Хельсинки (Линусом Торвальдсом) была разработана версия UNIX, известная под названием LINUX.

UNIX имеет двухуровневую структуру: ядро, где сконцентрированы базовые услуги и оболочка, куда входят редакторы, интерпретаторы, например СС, а также lp, routed, inetd, init и т.д.

Код UNIX написан на Си (на 30% больше по объему и на 20% ниже по производительности, чем версия на ассемблере). Система открытая, рассчитанная на многозадачность и большое число пользователей.

Интерфейс системных вызовов предоставляет набор услуг ядра и определяет формат запросов. Ядро состоит из трех частей:

  1. Файловая система
  2. Система управления процессами и памятью
  3. Система ввода/вывода.

Файловая система обеспечивает интерфейс доступа к данным на дисковых накопителях и в периферийных устройствах ввода/вывода. Одни и те же функции open(), read(0, write() могут использоваться при чтении/записи на диске и при выводе данных на принтер или терминал. Файловая система управляет правами доступа и привилегиями. Она обеспечивает перенаправление запросов, адресованных периферийным устройствам.

Система управления процессами ЭВМ, причем их число обычно превышает число ЦПУ. Специальной задачей ядра является планирование выполнением процессов (scheduler). Сюда входит управление ресурсами системы (временем ЦПУ, дисковым пространством, распределением памяти и т.д.). Данная система занимается созданием и удалением процессов, синхронизацией их работы и взаимодействием процессов (например, обменом данными).

Система ввода/вывода обслуживает запросы файловой системы и системы управления процессами для доступа к периферийным устройствам (дискам, лентам, печати, терминалам). Эта система организует взаимодействие с драйверами этих устройств.

Файловая система UNIX представляет собой древовидную структуру. Каждый файл имеет имя, которое определяет его место на дереве файловой системы. Корнем этой системы является корневой каталог с именем /.

В этом каталоге обычно содержатся каталоги:

/bin

Каталог наиболее популярных системных команд и утилит.

/dev

Каталог файлов для периферийных устройств, например дисковых накопителей (/dev/cdrom, /dev/mem, /dev/null или /dev/ttyp10).

/etc

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

/lib

Каталог библиотечных файлов языка Си и других языков.

/lost+found

Каталог "потерянных" файлов. Ошибки при неправильном выключении ЭВМ могут привести к появлению безымянных файлов (содержимое корректно, но нет ссылок на этот файл ни в одном из каталогов).

/mnt

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

/home

Служит для размещения каталогов пользователей (в прежних версиях для этого служил каталог /usr.

/var

Предназначен для размещения сервисных подкаталогов, например, электронной почты (/usr/spool), утилит UNIX (/usr/bin), программ, исполняемых на данной ЭВМ (/usr/local), файлов заголовков (/usr/include), системы справочника (/usr/man).

/tmp

Служит для записи временных файлов.

Полные имена остальных файлов содержат путь - список каталогов, размещенных между / и данным файлом. По этой причине полное имя любого файла начинается с символа / (не содержит в отличие от Windows имени диска (например, CD), другого внешнего устройства или удаленной ЭВМ).

UNIX, тем не менее, не предполагает наличия лишь одной файловой системы. Число таких файловых систем в этой ОС не лимитировано, они могут располагаться на одном дисковом накопителе, на разных устройствах или даже на разных ЭВМ.

Каждый файл имеет сопряженные с ним метаданные, записанные в индексных дескрипторах - inode. Имя файла является указателем на его метаданные (метаданные не содержат указателя на имя файла). Существует 6 типов файлов:

  1. Обычный файл (regular)
  2. Каталог (directory)
  3. Файл внешнего устройства
  4. Канал с именем (FIFO)
  5. Связь (link)
  6. socket

Обычный файл является наиболее распространенным типом. Для операционной системы такой файл представляется простой последовательностью байтов. Интерпретация содержимого такого файла находится в зоне ответственности прикладной программы, которая с ним работает.

Каталог - это файл, содержащий имена находящихся в нем файлов и указатели на информацию, позволяющую ОС производить операции над этими файлами. Запись в каталог имеет право только ядро. Каталог представляет собой таблицу, каждая запись в которой соответствует некоторому файлу.

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

Каналы с именем (FIFO) - это файлы, служащие для связи между процессами.

Файловая система допускает наличие нескольких имен у одного файла. Связь имени файла с его метаданными называется жесткой связью. С помощью команды ln можно создать еще одно имя для файла. Особым типом файла является символическая связь, позволяющей косвенно обращаться к файлу. Символическая связь является особым типом файла.

Socket служит для взаимодействия между процессами. Интерфейс socket используется, например, для доступа к сети TCP/IP.

Любой файл имеет двух владельцев - собственно создателя и группу (chown, chgrp и chmod). Файл создается не пользователем, а процессом, им запущенным. Атрибуты этого процесс присваиваются и файлу (r, w и x). Имеется также несколько дополнительных атрибутов, среди них sticky bit , который требует сохранения образа \исполняемого файла в памяти после завершения его работы. Атрибуты SUID и GUID позволяют изменить права пользователя в направлении расширения (до уровня создателя файла) на время исполнения данной программы (это используется, например, в случае работы с файлом /etc/passwd) . В случае каталогов sticky bit позволяет стереть только файлы, которыми владеет пользователь.

Различается несколько типов процессов.

  1. Системные процессы являются частью ядра и резидентно размещены в оперативной памяти. Они запускаются при инициализации ядра системы. Системными процессами являются, например, kmadaemon (диспетчер памяти ядра), shed (диспетчер свопинга), bdfflush (диспетчер кэша), init (прародитель всех остальных процессов).
  2. Демоны - не интерактивные процессы, запускаемые путем загрузки в память соответствующих программ и выполняемые в фоновом режиме. Демоны не ассоциируются ни с одним из пользователей (они служат, например, для организации терминального ввода, печатающего устройства, сетевого доступа).
  3. Прикладные процессы - это остальные процессы принадлежащие, как правило, пользователям.

Процессы создаются процедурой fork и характеризуются набором атрибутов:

PID

(Process ID) представляет собой уникальное имя процесса (идентификатор нового процесса характеризуется большим кодом, чем идентификатор предыдущего). После уничтожения процесса ликвидируется и его PID и этот идентификатор может быть присвоен новому процессу.

PPID

(Parent Process ID) - идентификатор процесса, породившего данный процесс.

Приоритет процесса

(Nice Number) учитывается планировщиком при определении очередности запуска процессов.

TTY

псевдотерминал, ассоциированный с процессом. Демоны не имеют псевдотерминала.

RID (Real ID)

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

Для запуска задачи процесс должен выполнить системный вызов exec. При этом не порождается новый процесс, а код процесса замещается полностью кодом запускаемой программы.

Так, когда пользователь вводит команду ls, текущий процесс shell осуществляет вызов fork, порождая новый процесс - копию shell. Порожденный процесс осуществит вызов exec, указав в качестве параметра имя исполняемого файла (ls). Ls замещает shell, а по завершении работы процесс уничтожается.

Сигналы

Сигналы служат для того, чтобы передавать от одного процесса к другому или от ядра к какому-то процессу, уведомление о происхождении некоторого события. Примером такого события может быть нажатие клавиши мышки или нажатие клавиш <Ctrl><C> (SIGINIT)или <Ctrl><Alt><Del>.

Для отправления сигнала служит команда kill pid, где sig_no - номер или символическое название сигнала, pid - идентификатор процесса, которому адресован сигнал. Для остановки процесса, выполняемого в фоновом режиме можно послать сигнал SIGTERM. Например, kill $!, где $! - переменная, где хранится идентификатор процесса (PID), запущенного последним.

Таблица 1. Сигналы

Имя сигнала

Функция по умолчанию

Описание

SIGABRT

Завершение + ядро

Результат системного вызова abort

SIGALRM

Завершение

Результат срабатывания таймера, установленного системными вызовом alarm или setitimer

SIGBUS

Завершение + ядро

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

SIGCHLD

Игнорирование

Сообщает родительскому процессу о завершении исполнения дочернего

SIGEGV

Завершение + ядро

Формируется при попытке обращения к неверному адресу или области памяти, для которой у процесса нет привилегий.

SIGFPE

Завершение + ядро

Сигнал возникает в случае деления на нуль или при переполнении в операциях с плавающей запятой.

SIGHUP

Завершение

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

SIGILL

Завершение + ядро

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

SIGINT

Завершение

Посылается ядром всем процессам при нажатии комбинации клавиш <Del> или <Crtl><C>.

SIGKILL

Завершение

Сигнал прерывает выполнение процесса. Перехват или игнорирование этого сигнала невозможно.

SIGPIPE

Завершение

Результат попытки записи в канал или сокет, когда получатель данных закрыл соответствующий дескриптор.

SIGPOLL

Завершение

Результат реализации определенного события для устройства, которое опрашивается.

SIGPWR

Игнорирование

Результат угрозы потери питания (при переключении на UPS).

SIGQUIT

Завершение + ядро

Посылается ядром всем процессам текущей группы при нажатии клавиш <Crtl><\>.

SIGSTOP

Стоп

Посылается всем процессам текущей группы при нажатии пользователем комбинации клавиш <Crtl><Z>. Процесс останавливается.

SIGSYS

Завершение + ядро

Посылается ядром при попытке некорректного системного вызова

SIGTERM

Завершение

Предупреждение о скорой ликвидации процесса (ликвидировать временные файлы, прервать текущие обмены) Команда kill посылает именно этот сигнал.

SIGTTIN

Стоп

Формируется ядром при попытке фонового процесса выполнить чтение с консоли.

SIGTTOU

Стоп

Формируется ядром при попытке фонового процесса выполнить запись в консоль

SIGUSR1

Завершение

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

SIGUSR2

Завершение

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

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

kill -9 pid

Иногда и это может не помочь, например, в случае процессов зомби (процесса нет а запись о нем имеется), операции в NFS или с ленточным ЗУ.

Атрибуты пользователя в файле /etc/passwd (одна строка - одна запись):

имя:passwd-encod:UID:GID:комментарии:home-dir:shell

имя уникальное регистрационное имя пользователя (вводится при login)

passwd-encod закодированный пароль пользователя. Часто пароль хранится в отдельном файле, а здесь вместо него проставляется символ х. Если в этом поле стоит символ *, то данный пользователь в систему войти не может (используется для псевдопользователей)

UID Идентификатор пользователя, который наследуется порожденными им процессами. ROOT имеет UID=0.

GID Идентификатор первичной группы пользователя, который соответствует идентификатору в файле /etc/group, где содержится список имен пользователей-членов группы.

Комментарии Обычно здесь записывается истинное имя пользователя, здесь может быть записана дополнительная информация, например, телефон или e-mail пользователя, считываемые программой finger.

home-dir Базовый каталог пользователя, где он оказывается после входа в систему.

Shell Название программы, используемой системой в качестве командного интерпретатора (например, /bin/sh). Разные интерпретаторы используют разные скрипты инициализации (.profole, .login и т.д.).

В первой строке скрипта помещается строка #! /bin/sh, указывающая на тип и размещения интерпретатора. Поскольку скрипт исполняется интерпретатором, работает он медленно. Значение PID сохраняется в переменной $$, что можно использовать при формировании имен временных файлов, гарантируя их уникальность. Переменные $1, $2 и т.д. несут в себе значения параметров, переданных скрипту. Число таких параметров записывается в переменной $#. Результат работы скрипта заносится в переменную $?. Ненулевое значение $? свидетельствует об ошибке. В переменной $! Хранится PID последнего процесса, запущенного в фоновом режиме. Переменная $* хранит в себе все переменные, переданные скрипту в виде единой строки вида: "$1 $2 $3 .". Другое представление переданных параметров предлагает переменная $@= "$1" "$2" "$3" .

Таблица 2. Перенаправление потоков ввода/вывода

Обозначение

Выполняемая операция

>файл

Стандартный вывод перенаправляется в файл

>>файл

Данные из стандартного вывода добавляются в файл

<файл

Стандартный ввод перенаправляется в файл

p1|p2

Вывод программы p1 направляется на вход программы p2

n>файл

Перенаправление вывода из файла с идентификатором n в файл

n>>файл

Тоже, что и в предыдущей строке, но данные добавляются к содержимому файла

n>&m

Объединение потоков с идентификаторами n и m

<<str

"Ввод здесь" - используется стандартный ввод до подстроки str. При этом осуществляется подстановка метасимволов интерпретатора

<<\str

То же, что и в предшествующей строке, но без подстановки.

Символ | иногда называется конвейером. Например, команда:

ps - ef | grep proс

осуществляет вывод данных о конкретном процессе proс. Несколько более корректна команда:

ps - ef | grep proс grep -v grep

так как в потоке, формируемом командой ps , присутствуют две строки, содержащие proс - строка процесса proс и строка процесса grep с параметром proс.

Для запуска выполнения команды в фоновом режиме достаточно завершить ее символов &.

Виртуальная память процесса состоит из сегментов памяти. Размер, содержимое и размещение сегментов определяется самой программой (например, применением библиотек). Исполняемые файлы могут иметь формат COFF (Common Object File Format) и ELF (Executable and Linking Format).

Функция main() является первой, определенной пользователем. Именное ей будет передано управление после формирования соответствующего окружения запускаемой программы. Функция main определяется следующим образом.

main(int argc, char *argv[], char *envp[]);

Аргумент argc определяет число параметров, переданных программе. Указатели на эти параметры передаются с помощью массива argv[], так через argv[0] передается имя программы, argv[1] - несет в себе первый параметр и т.д. до argv[argc-1]. Массив envp[] несет в себе список указателей на переменные окружения, передаваемые программе. Переменные представляют собой строки имя=значение_переменной.

В среде UNIX существует два базовых интерфейса для файлового ввода/вывода.

  1. Интерфейс системных вызовов, непосредственно взаимодействующих с ядром ОС.
  2. Стандартная библиотека ввода-вывода.

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

Процессы

Процесс характеризуется набором атрибутов и идентификаторов. Важнейшим из них является идентификатор процесса PID и идентификатор родительского процесса PPID. PID является именем процесса в ОС. Существует еще 4 идентификатора, которые определяют доступ к системным ресурсам.

  1. Идентификатор пользователя - UID.
  2. Эффективный идентификатор пользователя - ЕUID
  3. Идентификатор группы GID
  4. Эффективный идентификатор группы ЕGID.

Процессы с идентификаторами SUID и SGID ни при каких обстоятельствах не должны порождать других процессов .

Процесс при реализации использует разные системные ресурсы - память, процессор, возможности файловой системы и ввод/вывод. ОС создает иллюзию одновременного исполнения нескольких процессов (предполагается, что имеется только один процессор), распределяя ресурсы между ними и препятствуя злоупотреблениям.

Выполнение процесса может происходить в двух режимах - в режиме ядра (kernel mode) и в режиме пользователя (user mode). В режиме пользователя процесс исполняет команды прикладной программы, доступные на непривилегированном уровне. Для получения каких-либо услуг ядра процесс делает системный вызов. При этом могут исполняться инструкции ядра, но от имени процесса, реализующего системный вызов. Выполнение процесса переходит в режим ядра, что защищает адресное пространство ядра. Следует иметь в виду, что некоторые инструкции, например, изменение содержимого регистров управления памятью, возможно только в режиме ядра.

По этой причине образ процесса состоит из двух частей: данных режима ядра и режима пользователя. Каждый процесс представляется в системе двумя основными структурами данных - proc и user, описанными в файлах <sys/proc.h> и <say/user.h>, соответственно. Структура proc является записью системной таблицы процессов, которая всегда находится в оперативной памяти. Запись этой таблицы для активного в данный момент процесса адресуется системной переменной curproc. Каждый раз при переключении контекста, когда ресурсы процессора передаются другому процессу, соответственно изменяется содержимое переменной curproc, которая теперь будет указывать на proc активного процесса.

Структура user, называемая также u-area или u block, содержит данные о процессе, которые нужны ядру при выполнении процесса. В отличие от структуры proc, адресуемой с помощью указателя curproc, данные user размещаются в определенном месте виртуальной памяти ядра и адресуются через переменную u. u area также содержит стек фиксированного размера - системный стек или стек ядра (kernel stack). При выполнении процесса в режиме ядра операционная система использует стек, а не стек процесса.

Современные процессоры поддерживают разбивку адресного пространства на области переменного размера - сегменты, и области фиксированного объема - страницы.

Процессоры Intel позволяют разделить память на несколько логических сегментов. Виртуальный адрес при этом состоит из двух частей - селектора сегмента и смещения в пределах сегмента. Поле селектора INDEX указывает на дескриптор сегмента, где записано его положение, размер и права доступа RPL (Descriptor Privilege Level).

При запуске программы командный интерпретатор порождает процесс, который наследует все 4 идентификатора и имеет те же права, что и shell.Так как в сеансе пользователя прародителем всех процессов является login shell, то их идентификаторы будут идентичны. При запуске программы сначала порождается новый процесс, а затем загружается программа.

Процесс порождается с помощью системного вызова fork :

#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);

Порожденный процесс (дочерний) является точной копией родительского процесса. Дочерний процесс наследует следующие атрибуты:

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

Конфигурация виртуальной памяти также сохраняется (те же сегменты программ, данных, стека и пр.). После завершения вызова fork оба процесса будут выполнять одну и ту же инструкцию. Отличаются эти процессы PID, PPID (идентификатор родительского процесса), дочерний процесс не имеет сигналов, ждущих доставки, отличаются и код, возвращаемый системным вызовом fork (родителю возвращается PID дочернего процесса, а дочернему - 0). Если код =0, то возврат осуществляется только в родительский процесс.

Для загрузки исполняемого файла используется вызов exec (аргумент - запускаемая программа). При этом существующий процесс замещается новым, соответствующим исполняемому файлу.

  • идентификаторы PID и PPID
  • все указатели и дескрипторы файлов, для которых не установлен флаг FD_CLOEXEC
  • идентификаторы пользователя и группы
  • текущий и корневой каталог
  • переменные окружения
  • маску файлов
  • ограничения, налагаемые на процесс
  • управляющий терминал

Процессы могут уведомлять друг друга о произошедших событиях с помощью сигналов, каждый из которых имеет символьное имя и номер. Сигнал может инициировать попытка деления на 0 или обращение по недопустимому адресу.

ОС UNIX создает иллюзию одновременного исполнения процессов, стараясь эффективно распределять между ними имеющиеся ресурсы. Выполнение процесса возможно в режиме ядра (kernel mode) и в режиме задачи (user mode). В последнем случае процесс реализует инструкции прикладной программы, допустимые на непривилегированном уровне защиты процессора. При этом системные структуры данных недоступны. Для получения таких данных процесс делает системный вызов (на время происходит переход процесса в режим ядра).

Каждый процесс представляется в системе двумя основными структурами данных - proc и user, описанными в файлах <sys/proc.h> и <sys/user.h>. Структура proc представляет собой системную таблицу процессов, которая находится в оперативной памяти резидентно. Текущий процесс адресуется системной переменной curproc . Структура user размещается в виртуальной памяти. Область user содержит также системный стек и стек ядра.

Распределение оперативной памяти всегда бывает динамическим. Процессы выполняются в своем виртуальном адресном пространстве. Виртуальные адреса преобразуются в физические на аппаратном уровне при активном участии ОС. Объем виртуальной памяти может значительно превышать объем физической. Процессоры обычно поддерживают разделение адресного пространства области переменного размера - сегменты и фиксированного размера - страницы. Для каждой страницы может быть задано собственная схема преобразования виртуальных адресов в физические. Intel поддерживает работу с сегментами (сегментные регистры), где задается селектор сегмента (дескриптор) и смещение в пределах сегмента.

Распределение ресурсов процессора осуществляется планировщиком, который выделяет кванты времени каждому из активных процессов. Здесь приложения делятся на три класса:

  1. Интерактивные
  2. Фоновые
  3. Реального времени

Каждый процесс в UNIX имеет свой контекст (контекст сохраняется при прерывании процесса). Контекст определяется следующими составляющими:

  • Адресное пространство процесса в режиме user
  • Управляющая информация (proc и user).
  • Окружение процесса (в виде пар переменная=значение).
  • Аппаратный контекст (регистры процессора)

Работа планировщика UNIX основана на использовании приоритетов процессов. Если процесс имеет наивысший приоритет и готов к работе, планировщик прервет работу текущего процесса, если у него более низкий приоритет, даже при условии, что он не выбрал до конца свой квант времени. Работа программы ядра обычно не прерывается. Это касается и процессов user, если они в данный момент осуществляют системный вызов.

Каждый процесс имеет два атрибута приоритета - текущий и относительный (nice) . Первый служит для реализации планирования, второй присваивается при порождении процесса и воздействует на значение текущего приоритета. Текущий приоритет может характеризоваться кодами 0 (низший) - 127 (высший). Для режима user используются коды приоритета 0-65, а для ядра - 66-94 (системный диапазон).

Процессы с кодами 96-127 имеют фиксированный приоритет, который не может изменить ОС (обычно служат для процессов реального времени).

Процессу, ожидающему освобождения какого-то ресурса, система присваивает значение кода приоритета сна, выбираемое из диапазона системных приоритетов (в версии BSD большему коду соответствует меньший приоритет). Процессы типа "ожидание ввода с клавиатуры" имеют высокий приоритет сна и им сразу предоставляется ресурс процессора. Фоновые же процессы, забирающие много времени ЦПУ, получают относительно низкий приоритет.

Каждую секунду ядро пересчитывает текущие значения кодов приоритета для процессов, ожидающих запуска (коды<65), повышая вероятность получения ими требуемого ресурса. Так 4.3BSD использует для расчета приоритета процесса следующую формулу:

p_cpu = p_cpu*(2*load)/(2*load+1), где load - среднее число процессов в очереди за последнюю секунду. В результате после долгого ожидания даже низкоприоритетный процесс имеет определенный шанс получить требуемый ресурс.

Ядро генерирует и посылает процессу сигнал в ответ на определенные события, вызванные самим процессом, другим процессом, прерыванием (например, терминальным) или внешним событием. Это могут быть Alarm, нарушение по выделенным квотам, особые ситуации, например деление на нуль и т.д. Некоторые сигналы можно заблокировать, отложить их обработку, или проигнорировать, для других (например, SIGKILL и SIGSTOP) это невозможно.

Взаимное влияние процессов в UNIX минимизировано (многозадачность!), но система была бы неэффективной, если бы она не позволяла процессам обмениваться данными и сигналами (IPC - Inter Process Communications). Для реализации этой задачи в UNIX предусмотрены:

  • каналы
  • сигналы
  • FIFO (First-In-First-Out - именованные каналы)
  • очереди сообщений
  • семафоры
  • совместно используемые области памяти
  • сокеты
  • >

Для создания канала используется системный вызов pipe int pipe(int *filedes); который возвращает два дескриптора файла filedes[0] - для записи в канал и filedes[1] для чтения из канала. Когда один процесс записывает данные в filedes[0], другой получает их из filedes[1]. Здесь уместен вопрос, как этот другой процесс узнает дескриптор filedes[1]?

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

cat file.txt | wc

Здесь символ | олицетворяет создание канала между выводом из файла file.txt и программой wc, подсчитывающей число символов в словах. Процессы эти не являются независимыми, так как оба порождены процессом shell.

Метод FIFO (в BSD не реализован) сходен с канальным обменом, так как также организует лишь однонаправленный обмен. Такие каналы имеют имена, что позволяет их применять при обмене между независимыми процессами. FIFO - это отдельный тип файла в файловой системе UNIX. Для формирования FIFO используется системный вызов mknod.

int mknod(char *pathname, int mode, int dev);

где pathname - имя файла (FIFO),
mode - флаги владения и прав доступа,
dev - при создании FIFO игнорируется.

Допускается создание FIFO и из командной строки: mknod name p.
FIFO также как и обычные канала работают с соблюдением следующих правил.

  • Если из канала берется меньше байтов, чем там содержится, остальные остаются там для последующего чтения.
  • При попытке прочесть больше байт, чем имеется в канале, читающий процесс должен соответствующим образом обработать возникшую ситуацию.
  • Если в канале ничего нет и ни один процесс не открыл его на запись, при чтении будет получено нуль байтов. Если один или более процессов открыло канал на запись, вызов read будет заблокирован до появления данных.
  • В случае записи в канал несколькими процессами, эти данные не перемешиваются.
  • При попытке записать большее число байтов, чем это позволено каналом или FIFO, вызов write блокируется до освобождения нужного места. Если процесс предпринимает попытку записи в канал, не открытый ни одним из процессов для чтения, процессу посылается сигнал SIGPIPE, а вызов write присылает 0 с кодом ошибки errno=EPIPE.

Сообщения

Очереди сообщения являются составной частью UNIX System V. Процесс, заносящий сообщение в очередь, может не ожидать чтения этого сообщения каким-либо другим процессом. Сообщения имеют следующие атрибуты:

  • Тип сообщения
  • Длина данных в байтах
  • Данные (если длина ненулевая)

Очередь сообщений имеет вид списка в адресном пространстве ядра. Для каждой очереди ядро формирует заголовок(msqid_ds), где размещаются данные о правах доступа к очереди (msg_perm), о текущем состоянии очереди (msg_cbytes - число байтов msg_qnum - число сообщений в очереди), а также указатели на первое и последнее сообщение. Создание новой очереди сообщений осуществляется посредством системного вызова msgget:

#include <sys/types.h>
#include <sys/ipc.h>
#include e <sys/ipc.h>
int msgget( key_t key, int msgflag );

Эта функция выдает дескриптор элемента очереди, или -1 - в случае ошибки. Процесс может с помощью оператора msgsnd поместить сообщение в очередь, получить сообщение из очереди посредством msgrcv и манипулировать сообщениями с помощью msgctl.

Семафоры

Для управления доступом нескольких процессов к разделяемым ресурсам используются семафоры. Семафоры являются одной из форм IPC (Inter-Process Communication). Для обеспечения работы нужно обеспечить выполнение следующих условий:

  • Семафор должен быть доступен разным процессам и, по этой причине, находиться в адресной среде ядра.
  • Операция проверки и изменения семафора должна быть реализована в режиме ядра.

Помимо значения семафора в структуре sem записывается идентификатор процесса, вызвавшего последнюю операцию над семафором, число процессов, ожидающих увеличения значения семафора.

Разделяемая память

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

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

Файловая система

В настоящее время UNIX использует виртуальную файловую систему, которая допускает работу с несколькими физическими файловыми системами самых разных типов. Система S5FS занимает раздел диска и состоит из трех компонентов.

  • Суперблока, где хранится общая информация о файловой системе, о ее архитектуре, числе блоков, и индексных дескрипторов (inode).
  • Массива индексных дескрипторов (ilist), где записаны метаданные всех файлов системы. Индексный дескриптор содержит статусные данные о файле и информацию о расположении этих данных на диске. Ядро обращается к inode по индексу массива ilist. Один inode является корневым, через него происходит доступ к структуре каталогов и файлов после монтирования файловой системы.
  • Блоки данных файлов и каталогов. Размер блока кратен 512 байтам.

Индексный дескриптор (inode) несет в себе информацию о файле, необходимую для обработки метаданных файла. Каждый файл ассоциируется с одним inode. При открытии файла ядро записывает копию inode в таблицу in-core inode.

Слабой точкой файловой системы F5FS является суперблок. Он записан на диске в одном экземпляре и по этой причине уязвим. Низкая производительность этой файловой системы связана с тем, что метаданные файлов размещены в начале диска, а данные на относительном расстоянии от них. Это вызывает постоянные перемещения считывающих головок, снижая быстродействие системы.

Имена файлов хранятся в специальных файлах, называемых каталогами. По этой причине любой реальный файл данных может иметь любое число имен. Каталог файловой системы представляет собой таблицу, каждый элемент которой имеет длину 16 байтов: 2 байта номер индексного дескриптора, 14 - его имя. Число inode не может превышать 65535. Имя файла в этой системе (S5FS) не должно превышать 14 символов.

имеет имя "..".

При удалении имени файла из каталога номер соответствующего inode устанавливается равным 0. Ядро не удаляет свободные элементы, по этой причине размер каталога при удалении файлов не уменьшается.

Новая файловая система FFS (Berkeley Fast File System) использует те же структуры длинные имена файлов (до 255 символов). Записи каталога имеют следующую структуру:

d_namlen - Длина имени файла
d_name[] - Имя файла

Имя файла имеет переменную длину, дополняемую нулями до 4-байтовой границы. Метаданные активных файлов, на которые ссылаются один или более процессов, представлены в памяти в виде in-core inode. В виртуальной файловой системе в качестве in-core inode выступает vnode. Структура vnode одинакова для всех файлов и не зависит от типа файловой системы. vnode содержит данные, необходимые для работы виртуальной файловой системы, а также характеристики файла, такие как его тип.


Получение описания инструкций (Help): man <имя объекта>

Уход из UNIX Ctrl-d или logout.

passwd

Смена пароля пользователя

Вызов редактора

ed - строчный редактор; sed - потоковый редактор

pwd

Выдача полного имени текущего каталога

clear

Очистка экрана терминала.

ls [-флаги...] имя... Распечатка каталога

Флаги:

-a

печатает все имена файлов в каталоге;

-c

сортирует список файлов по времени последней модификации;

-d

печатает информацию только о каталогах (эквивалентно -l);

-f

для каждого подкаталога выводит его содержимое, этот флаг выключает все другие флаги;

-g

вместо идентификатора владельца печатается идентификатор группы;

-l

печатает полную информацию о файлах;

-r

сортирует список в обратном порядке;

-s

выводит размер файлов в блоках;

-t

сортировка по времени;

-u

сортирует список файлов по времени последнего доступа.

lc

Вывод содержимого каталога по столбцам (аналогична ls, но присутствует не во всех системах);

 

Образование нового каталога

mkdir

Например: mkdir A B (образует 2 каталога)

Переход из каталога в каталог

cd

Возвращение в предыдущий каталог

cd ..

Переход в параллельный каталог b

cd ../b

Возврат в базовый каталог

cd ../../

Удаление каталога

rmdir <имя_каталога>

Доступ к каталогу. Проверка существования файлов и каталогов, а также установленных для них возможностей.

test <параметр> <файл>

Команда test позволяет также сравнивать целые числа (напр., test "$X" -eq "$Y"). <параметр> возвращает значение true, если файл существует и:

-b

является блочным специальным файлом;

-c

символьным специальным файлом;

-d

каталогом;

-f

обычным файлом (не каталогом);

-g

установлен бит идентификатора группы;

-k

второй промежуточный бит округления;

-r

доступен для чтения;

-s

имеет ненулевой размер;

-t[fds]

открытый файл с дескриптором fsd связан с терминалом (по умолчанию fsd=1);

-u

установлен бит идентификатора пользователя;

-w

доступен для записи;

-x

для исполнения.

cat [файл1 файл2 ...]

Слияние файлов (если указано одно имя команда выводит содержимое на терминал, эквивалентно команде page)

Копирование файлов (файла в файл или файлов в каталог)

cp файл1 файл2 или cp файл1 файл2 .... файлN каталог.

uucp

делает то же, что и cp, но между двумя UNIX машинами в сети.

uucp [флаги] файл1 имя_ЭВМ!файл2

имя ЭВМ отделяется от имени файла с помощью "!". Перед именем файл2 необходимо указать также имя каталога или поставить "~", если оно неизвестно.

Например:

/usr/ivanov/news или ~ivanov/news.

Флаги:

-m

посылает сообщение отправителю о доставке файла1;

-n

посылает аналогичное сообщение получателю.

Переименование файлов или каталогов

mv файл1 файл2 или mv каталог1 каталог2

Печать файлов

Печать содержимого одного или нескольких файлов c автоматическим разбиением на страницы и с заголовком на каждой странице;

pr [флаги]...[файл]...

Флаги:

-h

задает заголовок;

-ln

задает длину страницы в n строк (по умолчанию - 60);

-m

Печатать все файлы одновременно в своих колонках;

-n

в n колонок;

+n

начиная со страницы n;

-t

не печатать 5 строк заголовка и 5 последних строк страницы;

-wn

задает ширину стр. в n символов (по умолчанию - 72);

 

more [файл]

Отображает файл поэкранно.

Печать файлов одновременно с выполнением других операций

lpr [флаги]...[файл]...

Флаги:

-c

cкопировать файл перед печатью;

-m

отправить почтовое сообщение по завершении печати;

-n

не сообщать по почте о завершении печати (по умолчанию);

-r

удалить файл после печати.

lp [флаги] [файл_1, файл_2,....файл_N]

Флаги:

-d

задает имя принтера;

-o

служит для задания субпараметров печати;

-n[число]

задает число копий печати;

-m

выводит на терминал сообщение по завершении печати;

-q[приоритет]

определяет уровень приоритета для запросов печати (максимальный - 0, минимальный -39);

-s

блокирует сообщение "request идентификатор";

-R

удаляет напечатанные файлы;

-L

использует подключенный к вашему терминалу локальный принтер;

lprint

эквивалент команды pr -L;

lpstat

выдает сообщение о статусе принтера;

cancel

отменяет запрос вывода на печать.

Сравнение файлов

Сравнение файлов и выдача отчета о различиях;

cmp [-l][-s] файл1 файл2

Флаги:

-l

выдача полного списка различий;

-s

выдача кода результата; (если равны - 0; неравны - 1; хотя бы один недоступен - 2);

Удаление файлов

rm [флаги] файл

Флаги:

-f

если для файла запрещена запись/чтение;

-i

удаление в интерактивном режиме; ( * означает - все файлы каталога);

-r

* удаление всех файлов и подкаталогов;

Поиск файлов

find каталог ... аргументы ...

Просматриваются рекурсивно все подкаталоги для каждого указанного каталога и ищутся файлы отвечающие условиям, заданным в аргументах. Числовые аргументы со знаком "+" означают "больше чем", а числовой аргумент со знаком "-" "меньше чем". Аргументы - это условия поиска; любому аргументу предшествует знак "-", все аргументы считаются соединенными знаком "И". -o соединитель ИЛИ, перед каждым символом "ИЛИ" должен ставиться знак "\";

Допускаются аргументы:

-name имя файла

имя файла совпадает с заданным;

-type c

тип файла совпадает с с;

-links n

файл имеет n связей;

-user имя

файл принадлежит пользователю с данным именем;

-group имя

файл принадлежит группе с именем;

-size n

длина файла равна n блокам;

-inum n

индекс файла равен n;

-mtime n

последняя модификация файла была n дней назад;

-exec команда

выполняется команда UNIX;

-ok команда

то же, что и -exec, но печатается на терминале;

-print

печатается имя текущего файла;

-newer файл

текущий файл был модифицирован позже заданного

Очистка индексного дескриптора

clri файл-система индекс...

Удаляет индексный дескриптор для файла, отсутствующего в каталогах.

Библиотекарь

ar флаги [имя] библиотека [файл...]

Флаги:

a

указывает (совместно с r или m) на то, что файлы следует помещать после заданного файла;

b

то же, что и a, но файлы размещаются перед заданным файлом;

c

создание библиотечного файла;

d

удалить файлы из библиотеки;

l

поместить временные файлы библиотекаря в текущем каталоге;

m

переместить файлы в конец библиотеки или вслед за указанным файлом;

p

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

q

добавить файлы в конец библиотеки;

r

заменить файлы в библиотеке на новые. Если файлов нет, они просто добавляются;

t

перечислить файлы, входящие в библиотеку;

u

совместно с r указывает, что будет заменяться только те файлы библиотеки, которые были модифицированы раньше заданных файлов.

v

печать дополнительной информации (вид действия, имя файла) применяется совместно с d, m, r, x;

x

скопировать файлы в текущий каталог;

Построение таблицы с содержанием библиотеки

ranlib [библиотека]

Служит для подготовки работы редактора связей.

Установка кода защиты файла

chmod код

chmod код_защиты файл ...

4000 разрешение смены идентификатора пользователя;
2000 разрешение смены идентификатора группы;
1000 сохранение образа файла после отсоединения всех процессов;
0400 разрешение чтения владельцу файла;
0200 разрешение записи владельцу файла;
0100 разрешение записи, чтения и выполнения владельцу;
0070 разрешение записи, чтения и выполнения группе;
0007 разрешение чтения, записи, исполнения всем.

Символьная форма позволяет установить биты кода защиты индивидуально и имеет вид:

[ugoa][+-=][rwxstugo], где

u

владелец,

g

группа,

o

прочие,

a

все категории пользователей (по умолчанию),

+

разрешить доступ,

-

запретить доступ,

r

чтение,

w

запись,

x

исполнение,

s

смена идентификатора пользователя или группы,

t

сохранение образа файла в области выгрузки,

ugo

оставить текущее значение бита доступа.

Проверка корректности каталогов

dcheck [индексы][файловая система]

Сравнивает счетчик числа связей в индексном дескрипторе с числом записей в каталогах, ссылающихся на данный дескриптор. Индексы генерируются командой icheck. Проверка распределения памяти в файловой системе

icheck [-s][-b блок...][файловая система]

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

Флаги:

-b выдача диагностических сообщений для заданных

блоков.

-s создание списка свободных блоков;

Генерация имен файлов по заданным индексам

nchek [-i индексы] [-a][-s][файловая система]

Генерирует полные имена файлов для заданного списка индексов файловой системы, осуществляет поиск имен поврежденных файлов.

Флаги:

-a

печатает тот же список, что и для флага -i и дополнительно все файлы, имена которых начинаются с "." и "..".

-i

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

-s

печатаются только специальные файлы и файлы с установленным режимом смены идентификатора пользователя.

Создание файловой системы

/etc/mkfs [файловая система][размер]

Создает новую файловую систему на диске или части диска согласно числу блоков, заданному аргументом размер. Такая система может быть присоединена к основной файловой системе с помощью команды mount.

Создание специальных файлов

/etc/mknod имя [c][b] тип устройство

Создание специальных файлов, располагающихся в каталоге /dev, где описываются характеристики драйверов устройств и файловых систем. Аргументы тип и устройство относятся к драйверу и к специальному входу в драйвер.

Монтирование файловой системы

/etc/mount файловая-система [-r] имя файла

Демонтирование файловой системы

/etc/umount файловая-система

Временная смена идентификатора пользователя

su [идентификатор]

Изменяет идентификатор пользователя, и выполняет операции, которые возможно было бы нельзя выполнить с другим идентификатором из-за отсутствия права доступа. Для возврата к исходной среде следует нажать ctrl-d.

Модификация суперблока - sync

Освобождаются буферы и модифицируется файловая система на диске. Sync автоматически выполняется через заданный промежуток времени, задаваемый администратором.

Библиотекарь магнитной ленты (или дискеты)

tar [флаги][имя]

Сохраняет и восстанавливает файлы и каталоги с использованием магнитной ленты (или дискет).

Флаги:

c

создает новую ленту для записи на нее файлов;

r

заданные файлы записываются в конец ленты;

t

печатает список файлов и каталогов, имеющихся на ленте, из числа заданных в команде;

x

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

u

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

b

коэффициент блокирования при чтении и записи, по умолчанию = 1, максимальное значение = 20;

f

следующий за f аргумент рассматривается как имя устройства вместо принятого по умолчанию /dev/mt?.

l

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

m

сообщает программе tar, что не следует изменять время модификации при записи файлов на ленту;

v

печать имен всех файлов и каталогов, при выполнении данной операции;

w

печатает наименование заданного действия и имя файла, после чего ожидается ответ пользователя. При "y" действие выполняется.

0,...,7

определяет номер устройства, на котором установлена лента, по умолчанию 1.

Смена владельца файла chown

chown имя файл

Смена группы chgrp

chgrp группа файл

Изменение направления ввода/вывода

< >

задает направление ввода/вывода;

<< >>

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

|

служит для передачи данных от одной команды к другой.

tr [-cds][строка_1][строка_1]

Считывает данные из стандартного ввода. Символы, не совпадающие с символом в аргументе "строка_1", передается на стандартный вывод без изменения. Символы же, совпадающие с символом в аргументе "строка_1", заменяются на соответствующие символы из аргумента "строка_2".

Асинхронное выполнение команд

&

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

wait вводится, когда нужно подождать завершения какого-то процесса.

Появление приглашения после ввода команды wait указывает на завершение всех запущенных ранее процессов.

at время [дата_и_время][приращение] список_команд

Команда планирования выполнения заданий.

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

at -r идентификатор_задания

Отменяет запрос.

batch планирует задания на то время, когда это будет позволять система.

Системные команды

mail имя файла или mail [-r] [-q] [-p] [-f файл]

Обращение к почтовому серверу.

Флаги:

-f

файл используется в качестве почтового ящика;

-p

печать почты;

-q

QUIT (прерывание процедуры);

-r

упорядочение - раньше посланное сообщение читается раньше; без флага - обратный порядок.

При чтении почты можно пользоваться командами:

d

удаление данного почтового сообщения;

m [имя]

переслать сообщение указанному пользователю;

p

напечатать сообщение еще раз и вернуться к предшествующему сообщению;

_

вернуться к предыдущему сообщению;

s [файл]

записать сообщение в файл;

ctrl/d

вернуть сообщение в почтовый ящик и завершить выполнение команды mail (= q).

x

выход без изменения почтового ящика;

!

временный выход в SHELL;

?

напечатать список команд mail.

Сообщение всем работающим пользователям

wall администратор что-то сообщает всем.

Конец сообщения по ctrl/d.

Посылка сообщения другому пользователю

write имя [терминал]

Разрешение или отмена сообщений

mesg [y] [n] (флаги - "y" и "n") присылаемых другими пользователями.

Команды обработки файлов

comm [-[123]] файл1 файл2

поиск одинаковых и разных строк в файлах, флаги "123" обозначают номера колонок. Результат печатается в трех колонках:

1 - строки встречаются только в файле1;
2 - строки встречаются только в файле2;
3 - строки встречаются в обоих файлах.

Преобразование файла

dd [аргументы]

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

Аргументы:

if=имя

имя входного файла;

of=имя

имя выходного файла;

ibs=n

размер входного блока в байтах (512 по умолчанию);

obs=n

размер выходного блока (512 по умолчанию);

bs=n

размер входного и выходного блоков;

cbs=n

размер буфера преобразования в байтах;

skip=n

перед копированием пропустить n входных записей;

files=n

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

seek=n

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

count=n

скопировать n входных записей.

Поиск строк с заданным шаблоном

grep [флаг] ... выражение [файл]

Служит для поиска соответствующих выражений (строк) в одном или нескольких файлах.

Флаги:

-b

перед каждой обнаруженной строкой печатается номер блока, где она содержится;

-c

печатается только число строк, содержащих шаблон;

-e

используется перед шаблоном, который начинается с символа "-";

-h

не печатаются имена файлов перед строками;

-l

печатаются имена файлов, содержащие искомые строки;

-n

перед каждой обнаруженной строкой печатается ее порядковый номер в файле;

-s

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

-v

печатаются все строки, не содержащие шаблона;

-y

строчные буквы в шаблоне считаются совпадающими как со строчными, так и прописными в файле.

egrep

модифицированная версия grep.

fgrep

упрощенная версия команды grep. Ищет только фиксированные строки, но работает быстрее чем grep.

Восьмеричный дамп файла

od[-флаги] файл[[+] смещение [.][b]].

Флаги:

-b

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

-c

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

 

нулевой байт

\0

  возврат на шаг \b
  перевод формата \f
  перевод строки \n
  возврат каретки \r
  горизонтальный TAB \t
  остальные ddd

-d

каждое слово интерпретируется как десятичное число;

-o

слова интерпретируются как восьмеричные числа;

-x

слова интерпретируются как шестнадцатеричные числа.

Сохранение (зашита) файловой системы

dump [флаги[аргумент...] файловая система]

Используется администратором для обеспечения сохранности всех данных в файловой системе.

Флаги:

d

задание плотности записи на ленту.

f

задает устройство для защиты;

s

задание размера ленты;

u

запись времени защиты;

0-9

уровень защиты;

Восстановление файловой системы

restor флаги [аргументы]

Чтение магнитных лент, записанных командой dump.

Разбиение файла на части

split [-n][файл[имя]]

разбивает файл на части по n строк (по умолчанию n=1000).

Если задано имя выходного файла, то генерируется последовательность файлов с данным именем и буквами aa, ab, ac,... в конце. Если имя выходного файла не задано, используется имя "x".

Подсчет числа слов

wc[-lwc] [файл]

Определяет число строк, слов и символов в одном или более файлов. Строки в файле разделяются символом "\n", слова - пробелами, горизонтальной табуляцией или переводом строки.

Флаги:

l

подсчет числа строк в файле;

w

подсчет числа слов в файле;

c

подсчет числа символов в файле;

Вывод одинаковых строк файла

uniq [-флаги[+n][-n]][вход][выход]

Находит одинаковые соседние строки файла. По умолчанию все одинаковые строки кроме одной удаляются.

Флаги:

c

одинаковые строки удаляются, но в начале строки ставится их исходное число;

d

выводятся только одинаковые строки;

-n

первые n полей при сравнении пропускаются;

+n

перед сравнением пропускаются первые n символов;

u

выводятся только разные строки.

Обнаружение различий в файлах

diff[-флаги]файл1 файл2

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

Позволяет экономить место при хранении ряда версий файла.

Флаги:

-b

игнорируются все пробелы и символы табуляции в конце строки, любые комбинации таких символов считаются эквивалентными;

-e

выдает последовательность команд редактора ed, с помощью которых первый файл может быть сделан эквивалентным второму.

-f

вырабатывает список изменений;

-h

быстро обнаруживает различия, но не всегда корректно.

Сортировка и слияние файлов

sort[-флаги...][+поз1[-поз2]]...[-o имя][-T каталог][имя]...

соединяет и сортирует файлы, помещает результат в заданный файл. Если ключ сортировки не задан, при сравнении используется вся строка.

Флаги:

b

при сравнении полей игнорируются пробелы и табуляции в начале строки;

c

проверяется, отсортирован ли входной файл в соответствии с заданными правилами;

d

"словарная сортировка": в сравнении участвуют только буквы, цифры и пробелы;

f

прописные буквы воспринимаются как строчные;

i

при нечисловых сравнениях игнорируются символы, не входящие в диапазон ASCII 040-0176;

m

слияние файлов, которые предполагаются отсортированными;

n

сортировка по арифметическому значению;

o

имя, идущее после воспринимается как имя выходного файла;

r

задается обратный порядок сортировки;

tx

буква t указывает на то, что вместо принятого по умолчанию пробела в качестве разделителя используется горизонтальная табуляция;

T

задает имя каталога, где размещаются временные файлы;

u

если одному ключу соответствует несколько строк, выводится только одна из них.

Управление выполнением программы

Вывод аргументов

echo[-n][аргумент]

Выводит в стандартный файл заданные ей аргументы, разделяя их пробелами и завершая вывод переводом строки. Служит для сообщения о выполнении последовательности команд. Флаг -n предоставляет возможность отменить перевод строки после вывода аргументов.

Уничтожение процесса

kill [-флаг] процесс...

единственный флаг, допустимый в команде kill, - номер сигнала, например флаг -9 безусловно ликвидирует процесс.

Задержка выполнения команды

sleep время

Задерживает выполнение команды на время, заданное в секундах.

Понижение приоритета команды

nice [-число]команда[аргументы]

Позволяет выполнить другую команду, с более низким приоритетом. Аргумент-число определяет степень понижения приоритета. Чем больше число, тем меньше приоритет.

Дублирование стандартного вывода

tee [флаг]...[флаг]...

команда читает информацию из стандартного ввода и выводит ее одновременно на терминал и в заданные файлы.

Флаги:

-i

игнорировать прерывания;

-a

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

Печать и установка времени

date [ггммддччмм][.сс]]

гг

год

мм

месяц

дд

день

чч

час

мм

минуты

сс

секунды

Кто работает в системе?

who [файл] [am I]

выдает список всех пользователей, работающих в данный момент, и имена их терминалов. [файл] - имя файла, где хранится информация о текущих пользователях. По умолчанию /etc/utmp. [am I] - дает возможность сообщить под каким именем вы вошли в систему.

Получение имени терминала

tty печатает имя терминала, за которым вы работаете.

Состояние процессов

ps [флаг...][файл]

предоставляет информацию об активных процессах в системе.

Флаги:

a

выдается информация обо всех процессах, управляемых терминалами.

x

выдается информация обо всех процессах, не управляемых терминалами (системных).

l

выдается полная информация с указанием состояния каждого процесса.

PID

идентификатор процесса;

TTY

номер терминала;

CMD

команда, выполняемая процессом.

UID

идентификатор пользователя;

PPID

идентификатор процесса, породившего данный процесс;

CPU

системная составляющая приоритета процесса;

PRI

приоритет процесса, чем больше, тем ниже;

NICE

пользовательская составляющая приоритета процесса;

ADDR

для резидентного процесса адрес в памяти, в противном случае на диске;

SZ

размер образа процесса в блоках;

WCHAN

событие, которого ожидает процесс с состоянием S или W; пустое поле означает, что процесс работает.


pstat

сообщает о статусе системы.

Сведения об использовании диска

du[-s][-a][имя...]

Флаги:

-s

выводит только общее количество блоков для всех файлов.

-a

печатает информацию для каждого файла.

Сведения о свободных блоках на диске

df [файловая система]

выводит количество блоков, доступных в заданной файловой системе.
Определение типа файла
file имя...
Определяется тип файла: .OBJ, .C, ASCII и т.д.

Печать календаря

cal [месяц]год

Установка функций терминала

stty [аргументы...]

позволяет узнать состояние любого терминала и настроить его на требуемый режим работы.

Аргументы:

even

включить контроль по четности;

-even

выключить контроль по четности;

odd

включить контроль на нечетность;

raw

включить прозрачный режим ввода;

nl

концом строки считать символ "перевода строки";

-nl

концом строки считать символ "возврат каретки";

echo

отображать на экране каждый вводимый символ;

-echo

не отображать вводимые символы;

lcase

преобразовывать прописные символы в строчные;

tabs

заменить символы табуляции на пробелы при выводе;

erase

установит следующий за erase символ в качестве символа стирания;

kill

установит следующий за kill символ в качестве символа отмены;

Установка табуляции

tabs [аргументы]

Устанавливает параметры табуляции для любого терминала.

Аргументы:

-n

используется, когда левое поле текста не выравнивается;

терминал

описывает тип рабочего терминала.


uncompress

разархивирует файлы, имеющие расширение .Z;

uncompress имя_файла

работает для файлов без расширения .Z.

uuencode файл указатель

используется для передачи двоичных (иногда и русских) файлов по электронной почте. Преобразует двоичный файл в ASCII-формат. Параметр указатель используется при декодировании и служит для указания маршрута и имени файла для команды uudecode. Результат кодировки можно положить в другой файл или непосредственно переслать по электронной почте.

uudecode файл

используется для передачи двоичных (иногда и русских) файлов по электронной почте. Преобразует двоичный файл в ASCII-формат. Параметр указатель используется при декодировании и служит для указания маршрута и имени файла для команды uudecode. Результат кодировки можно положить в другой файл или непосредственно переслать по электронной почте.

nslookup

выводит IP-информацию о домене;

crypt

кодирует файл по заданному пользователем ключу

uuname

выводит список узлов, известных данному узлу;

uux

выполняет команды на удаленной машине UNIX.

Previous: 10.17 Разводка разъемов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.19 Символьный набор HTML


previous up next index index
Previous: 10.18 Краткий справочник по командам UNIX    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.20 Справочные данные по математике

10.19 Символьный набор HTML
Семенов Ю.А. (ГНЦ ИТЭФ)

Символьный набор документов HTML, заданный "SGML Declaration for HTML". Этот набор базируется на документе [ISO-8859-1].

Кодовое представление

Символ

Описание

&#00; - &#08;

 

Не используется

&#09;

 

Символ горизонтальной табуляции

&#10

 

Перевод строки

&#13;

 

Возврат каретки

&#14; - &#31;

 

Не используется

&#32;

 

Пробел

&#33;

!

Восклицательный знак

&#34;

"

Кавычки

&#35;

 

Знак числа ()

&#36;

$

Знак доллара

&#37;

%

Знак процента

&#38;

&

Ampersand

&#39;

'

Апостроф

&#40;

(

Левая скобка

&#41;

)

Правая скобка

&#42;

*

Звездочка

&#43;

+

Знак плюс

&#44;

,

запятая

&#45;

-

Дефис

&#46;

.

Точка (полная остановка)

&#47;

/

Косая черта (slash)

&#48; - &#57;

0-9

Цифры 0-9

&#58;

:

Двоеточие

&#59;

;

Точка с запятой

&#60;

<

Знак меньше чем

&#61;

=

Знак равенства

&#62;

>

Знак больше чем

&#63;

?

Знак вопроса

&#64;

@

Символ @

&#65; - &#90;

A-Z

Буквы A-Z

&#91;

[

Левая квадратная скобка

&#92;

\

Обратная косая черта (backslash)

&#93

]

Правая квадратная скобка

&#94;

^

Знак вставки (^ caret)

&#95;

_

Горизонтальная черта (underscore)

&#96;

 

Ударение

&#97; - &#122;

a-z

Буквы a-z

&#123;

{

Левая фигурная скобка

&#124;

|

Вертикальная черта

&#125;

}

Правая фигурная скобка

&#126;

~

Тильда (~)

&#127; - &#159;

 

Не используется

&#160;

 

Неразрывный пробел

&#161;

¡

Инвертированный восклицательный знак

&#162;

¢

Знак центов

&#163;

£

Знак фунтов стерлингов

&#164;

¤

Обобщенный знак валюты

&#165;

¥

Знак иены

&#166;

¦

Разорванный знак вертикальной черты

&#167;

§

Знак раздела (Section sign)

&#168;

¨

Умляут (горизонтальное двоеточие над буквой)

&#169;

©

Знак авторского права (Copyright)

&#170;

ª

Feminine ordinal

&#171;

«

Левая угловая кавычка (guillemotleft)

&#172;

¬

Знак отрицания (Not sign)

&#173;

­

Мягкий дефис (Soft hyphen)

&#174;

®

Зарегистрированная торговая марка

&#175;

¯

Macron accent

&#176;

°

Знак градуса (Degree sign)

&#177;

±

Знак плюс или минус ( )

&#178;

²

Верхний индекс 2 (Superscript two)

&#179;

³

Верхний индекс 3 (Superscript three)

&#180;

´

Знак ударения (Acute accent)

&#181;

µ

Знак долготы над гласным (горизонтальная черта - Micro sign)

&#182;

Знак параграфа

&#183;

·

Центральная точка

&#184;

¸

Орфографический знак седиль (Cedilla)

&#185;

¹

Верхний индекс 1 (Superscript one)

&#186;

º

Masculine ordinal

&#187;

»

Правая угловая кавычка (guillemotright)

&#188;

¼

Дробь ╪

&#189;

½

Дробь 1/2

&#190;

¾

Дробь ╬

&#191;

¿

Инвертированный знак вопроса

&#192;

À

Прописное A, grave accent

&#193;

Á

Прописное A, acute accent

&#194;

Â

Прописное A, circumflex accent

&#195;

Ã

Прописное A, tilde

&#196;

Ä

Прописное A, dieresis or umlaut mark

&#197;

Å

Прописное A, ring

&#198;

Æ

Прописное AE dipthong (ligature)

&#199;

Ç

Прописное C, cedilla

&#200;

È

Прописное E, grave accent

&#201;

É

Прописное E, acute accent

&#202;

Ê

Прописное E, circumflex accent

&#203;

Ë

Прописное E, dieresis or umlaut mark

&#204;

Ì

Прописное I, grave accent

&#205;

Í

Прописное I, acute accent

&#206;

Î

Прописное I, circumflex accent

&#207;

Ï

Прописное I, dieresis or umlaut mark

&#208;

Ð

Прописное Eth, исландское

&#209;

Ñ

Прописное N, tilde

&#210;

Ò

Прописное O, grave accent

&#211;

Ó

Прописное O, acute accent

&#212;

Ô

Прописное O, circumflex accent

&#213;

Õ

Прописное O, tilde

&#214;

Ö

Прописное O, dieresis or umlaut mark

&#215;

×

Знак умножения

&#216;

Ø

Прописное O, slash

&#217;

Ù

Прописное U, grave accent

&#218;

Ú

Прописное U, acute accent

&#219;

Û

Прописное U, circumflex accent

&#220;

Ü

Прописное U, dieresis or umlaut mark

&#221;

Ý

Прописное Y, acute accent

&#222;

Þ

Прописное THORN, Icelandic

&#223;

ß

Строчное sharp s, German (sz ligature)

&#224;

à

Строчное a, grave accent

&#225;

á

Строчное a, acute accent

&#226;

â

Строчное a, circumflex accent

&#227;

ã

Строчное a, tilde

&#228;

ä

Строчное a, dieresis or umlaut mark

&#229;

å

Строчное a, ring

&#230;

æ

Строчный дифтонг ae (ligature)

&#231;

ç

Строчное c, cedilla

&#232;

è

Строчное e, grave accent

&#233;

é

Строчное e, acute accent

&#234;

ê

Строчное e, circumflex accent

&#235;

ë

Строчное e, dieresis or umlaut mark

&#236;

ì

Строчное i, grave accent

&#237;

í

Строчное i, acute accent

&#238;

î

Строчное i, circumflex accent

&#239;

ï

Строчное i, dieresis or umlaut mark

&#240;

ð

Строчное eth, Icelandic

&#241;

ñ

Строчное n, tilde

&#242;

ò

Строчное o, grave accent

&#243;

ó

Строчное o, acute accent

&#244;

ô

Строчное o, circumflex accent

&#245;

õ

Строчное o, tilde

&#246;

ö

Строчное o, dieresis or umlaut mark

&#247;

÷

Строчное ion sign

&#248;

ø

Строчное o, slash

&#249;

ù

Строчное u, grave accent

&#250;

ú

Строчное u, acute accent

&#251;

û

Строчное u, circumflex accent

&#252;

ü

Строчное u, dieresis or umlaut mark

&#253;

ý

Строчное y, acute accent

&#254;

þ

Строчное thorn, исландское

&#255;

ÿ

Строчное y с умляутом (dieresis or umlaut mark)

<!-- Набор символьных объектов. Типичное обращение:

<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1//EN//HTML">
%HTMLlat1; -->

Описание

Название символа

Уникод

Название набора

<!ENTITY nbsp CDATA "&#160;" >

Неразрывный пробел

U+00A0

ISOnum

<!ENTITY iexcl CDATA "&#161;" >

Инвертированный !

U+00A1

ISOnum

<!ENTITY cent CDATA "&#162;" >

Знак цента

U+00A2

ISOnum

<!ENTITY pound CDATA "&#163;" >

Знак фунта

U+00A3

ISOnum

<!ENTITY curren CDATA "&#164;" >

Знак валюты

U+00A4

ISOnum

<!ENTITY yen CDATA "&#165;" >

Знак иены

U+00A5

ISOnum

<!ENTITY brvbar CDATA "&#166;" >

Разорванная вертикальная черта

U+00A6

ISOnum

<!ENTITY sect CDATA "&#167;" >

Знак секции

U+00A7

ISOnum

<!ENTITY uml CDATA "&#168;" >

Диэреза = двоеточие над гласной

U+00A8

ISOdia

<!ENTITY copy CDATA "&#169;" >

Знак авторского права

U+00A9

ISOnum

<!ENTITY ordf CDATA "&#170;" >

Указатель женского начала

U+00AA

ISOnum

<!ENTITY laquo CDATA "&#171;" >

Левая двойная угловая кавычка

U+00AB

ISOnum

<!ENTITY not CDATA "&#172;" >

Знак отрицания

U+00AC

ISOnum

<!ENTITY shy CDATA "&#173;" >

Мягкий дефис

U+00AD

ISOnum

<!ENTITY reg CDATA "&#174;">

Знак зарегистрированной торговой марки

U+00AE

ISOnum

<!ENTITY macr CDATA "&#175;" >

Знак долготы над гласным = черта над

U+00AF

ISOdia

<!ENTITY deg CDATA "&#176;" >

Знак градуса

U+00B0

ISOnum

<!ENTITY plusmn CDATA "&#177;" >

Знак плюс-минус

U+00B1

ISOnum

<!ENTITY sup2 CDATA "&#178;" >

2 в верхнем индексе = знак квадрата

U+00B2

ISOnum

<!ENTITY sup3 CDATA "&#179;" >

3 в верхнем индексе = знак куба

U+00B3

ISOnum

<!ENTITY acute CDATA "&#180;" >

Резкое ударение

U+00B4

ISOdia

<!ENTITY micro CDATA "&#181;" >

Знак микро

U+00B5

ISOnum

<!ENTITY a CDATA "&#182;" >

Знак параграфа

U+00B6

ISOnum

<!ENTITY middot CDATA "&#183;" >

Центральная точка

U+00B7

ISOnum

<!ENTITY cedil CDATA "&#184;" >

Седиль

U+00B8

ISOdia

<!ENTITY sup1 CDATA "&#185;" >

1 в верхнем индексе

U+00B9

ISOnum

<!ENTITY ordm CDATA "&#186;" >

Индикатор мужского начала

U+00BA

ISOnum

<!ENTITY raquo CDATA "&#187;" >

Правая двойная угловая кавычка

U+00BB

ISOnum

<!ENTITY frac14 CDATA "&#188;" >

Символ 1/4

U+00BC

ISOnum

<!ENTITY frac12 CDATA "&#189;" >

Символ 1/2

U+00BD

ISOnum

<!ENTITY frac34 CDATA "&#190;" >

Символ 3/4

U+00BE

ISOnum

<!ENTITY iquest CDATA "&#191;"" >

Перевернутый знак вопроса

U+00BF

ISOnum

<!ENTITY Agrave CDATA "&#192;" >

Латинская прописная буква A с глухим ударением

U+00C0

ISOlat1

<!ENTITY Aacute CDATA "&#193;" >

Латинская прописная буква A с ударением

U+00C1

ISOlat1

<!ENTITY Acirc CDATA "&#194;" >

Латинская прописная буква A центральным ударением

U+00C2

ISOlat1

<!ENTITY Atilde CDATA "&#195;" >

Латинская прописная буква A с тильдой

U+00C3

ISOlat1

<!ENTITY Auml CDATA "&#196;" >

Латинская прописная буква A с умляутом, (диэрезой)

U+00C4

ISOlat1

<!ENTITY Aring CDATA "&#197;" >

Латинская прописная буква A с кружочком сверху

U+00C5

ISOlat1

<!ENTITY Aelig CDATA "&#198;" >

Латинская прописная буква AE

U+00C6

ISOlat1

<!ENTITY Ccedil CDATA "&#199;" >

Латинская прописная буква C с седилью

U+00C7

ISOlat1

<!ENTITY Egrave CDATA "&#200;" >

Латинская прописная буква E с глухим ударением

U+00C8

ISOlat1

<!ENTITY Eacute CDATA "&#201;" >

Латинская прописная буква E с ударением

U+00C9

ISOlat1

<!ENTITY Ecirc CDATA "&#202;"

Латинская прописная буква E с циркумфлексом

U+00CA

ISOlat1

<!ENTITY Euml CDATA "&#203;" >

Латинская прописная буква E с диэрезой

U+00CB

ISOlat1

<!ENTITY Igrave CDATA "&#204;" >

Латинская прописная буква I с глухим ударением

U+00CC

ISOlat1

<!ENTITY Iacute CDATA "&#205;" >

Латинская прописная буква I с ударением

U+00CD

ISOlat1

<!ENTITY Icirc CDATA "&#206;" >

Латинская прописная буква I с циркумфлексом сверху

U+00CE

ISOlat1

<!ENTITY Iuml CDATA "&#207;" >

Латинская прописная буква I с диэрезой (умляутом)

U+00CF

ISOlat1

<!ENTITY ETH CDATA "&#208;" >

Латинская прописная буква ETH

U+00D0

ISOlat1

<!ENTITY Ntilde CDATA "&#209;" >

Латинская прописная буква N с тильдой

U+00D1

ISOlat1

<!ENTITY Ograve CDATA "&#210;" >

Латинская прописная буква O с тупым ударением

U+00D2

ISOlat1

<!ENTITY Oacute CDATA "&#211;" >

Латинская прописная буква O с ударением

U+00D3

ISOlat1

<!ENTITY Ocirc CDATA "&#212;" >

Латинская прописная буква O с кружочком сверху

U+00D4

ISOlat1

<!ENTITY Otilde CDATA "&#213;" >

Латинская прописная буква O с тильдой

U+00D5

ISOlat1

<!ENTITY Ouml CDATA "&#214;" >

Латинская прописная буква O с диэрезой (умляутом)

U+00D6

ISOlat1

<!ENTITY times CDATA "&#215;" >

Знак умножения

U+00D7

ISOnum

<!ENTITY Oslash CDATA "&#216;" >

Латинская прописная буква O с косой чертой

U+00D8

ISOlat1

<!ENTITY Ugrave CDATA "&#217;" >

Латинская прописная буква U с глухим ударением

U+00D9

ISOlat1

<!ENTITY Uacute CDATA "&#218;" >

Латинская прописная буква U с ударением

U+00DA

ISOlat1

<!ENTITY Ucirc CDATA "&#219;" >

Латинская прописная буква U с циркумфлексом сверху

U+00DB

ISOlat1

<!ENTITY Uuml CDATA "&#220;" >

Латинская прописная буква U с тремой (умляутом)

U+00DC

ISOlat1

<!ENTITY Yacute CDATA "&#221;" >

Латинская прописная буква Y с ударением

U+00DD

ISOlat1

<!ENTITY THORN CDATA "&#222;" >

Латинская прописная буква THORN

U+00DE

ISOlat1

<!ENTITY szlig CDATA "&#223;" >

Латинская строчная буква sharp s = ess-zed

U+00DF

ISOlat1

<!ENTITY agrave CDATA "&#224;" >

Латинская строчная буква a с глухим ударением

U+00E0

ISOlat1

<!ENTITY aacute CDATA "&#225;" >

Латинская строчная буква a с ударением

U+00E1

ISOlat1

<!ENTITY acirc CDATA "&#226;">

Латинская строчная буква a с кружочком сверху

U+00E2

ISOlat1

<!ENTITY atilde CDATA "&#227;">

Латинская строчная буква a с тильдой

U+00E3

ISOlat1

<!ENTITY auml CDATA "&#228;">

Латинская строчная буква a с тремой (умляутом)

U+00E4

ISOlat1

<!ENTITY aring CDATA "&#229;">

Латинская строчная буква a с кружочком сверху

U+00E5

ISOlat1

<!ENTITY aelig CDATA "&#230;">

Латинская строчная буква ae = латинская строчная лигатура ae

U+00E6

ISOlat1

<!ENTITY ccedil CDATA "&#231;">

Латинская строчная буква c с седилью

U+00E7

ISOlat1

<!ENTITY egrave CDATA "&#232;">

Латинская строчная буква e с глухим ударением

U+00E8

ISOlat1

<!ENTITY eacute CDATA "&#233;">

Латинская строчная буква e с ударением

U+00E9

ISOlat1

<!ENTITY ecirc CDATA "&#234;">

Латинская строчная буква e с циркумфлексом сверху

U+00EA

ISOlat1

<!ENTITY euml CDATA "&#235;">

Латинская строчная буква e с тремой (умляутом)

U+00EB

ISOlat1

<!ENTITY igrave CDATA "&#236;">

Латинская строчная буква i с глухим ударением

U+00EC

ISOlat1

<!ENTITY iacute CDATA "&#237;">

Латинская строчная буква i с ударением

U+00ED

ISOlat1

<!ENTITY icirc CDATA "&#238;">

Латинская строчная буква i с циркумфлексом сверху

U+00EE

ISOlat1

<!ENTITY iuml CDATA "&#239;">

Латинская строчная буква i с тремой (умляутом)

U+00EF

ISOlat1

<!ENTITY eth CDATA "&#240;">

Латинская строчная буква eth

U+00F0

ISOlat1

<!ENTITY ntilde CDATA "&#241;">

Латинская строчная буква n с тильдой

U+00F1

ISOlat1

<!ENTITY ograve CDATA "&#242;">

Латинская строчная буква o с глухим ударением

U+00F2

ISOlat1

<!ENTITY oacute CDATA "&#243;">

Латинская строчная буква o с ударением

U+00F3

ISOlat1

<!ENTITY ocirc CDATA "&#244;">

Латинская строчная буква o с циркумфлексом сверху

U+00F4

ISOlat1

<!ENTITY otilde CDATA "&#245;">

Латинская строчная буква o с тильдой

U+00F5

ISOlat1

<!ENTITY ouml CDATA "&#246;">

Латинская строчная буква o с тремой (умляутом)

U+00F6

ISOlat1

<!ENTITY divide CDATA "&#247;">

Знак деления

U+00F7

ISOnum

<!ENTITY oslash CDATA "&#248;">

Латинская строчная буква o с косой чертой

U+00F8

ISOlat1

<!ENTITY ugrave CDATA "&#249;">

Латинская строчная буква u с глухим ударением

U+00F9

ISOlat1

<!ENTITY uacute CDATA "&#250;">

Латинская строчная буква u с ударением

U+00FA

ISOlat1

<!ENTITY ucirc CDATA "&#251;">

Латинская строчная буква u с циркумфлексом сверху

U+00FB

ISOlat1

<!ENTITY uuml CDATA "&#252;">

Латинская строчная буква u с тремой (умляутом)

U+00FC

ISOlat1

<!ENTITY yacute CDATA "&#253;">

Латинская строчная буква y с ударением

U+00FD

ISOlat1

<!ENTITY thorn CDATA "&#254;">

Латинская строчная буква thorn

U+00FE

ISOlat1

<!ENTITY yuml CDATA "&#255;">

Латинская строчная буква y с тремой (умляутом)

U+00FF

ISOlat1

Эталонные символьные объекты для символов, математических символов и греческих букв

Эталонные символьные объекты в этом разделе производят символы, которые могут быть представлены глифами из широко известного шрифта Adobe Symbol, включая греческие буквы, различные скобки, а также секцией математических операторов (+ . - и т.д.).

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

Использование греческих символов. Этот символьный набор содержит все буквы, используемые в современном греческом алфавите. Однако, он не включает в себя греческую пунктуацию, символы со знаками ударения или безпробельные акценты (tonos, dialytika), необходимые для их формирования. Здесь нет архаичных букв, уникальных коптских букв или комбинированных букв политонического греческого языка. Определенные здесь объекты предназначены не для представления современного греческого текста, а для применения в технических математических текстах.

Список символов

<!-- Математические, греческие и другие символы HTML -->
<!-- Character entity set. Typical invocation:
<!ENTITY % HTMLsymbol PUBLIC
"-//W3C//ENTITIES Symbols//EN//HTML">
%HTMLsymbol; -->

<!-- Ниже приводится набор соответствующих объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не противоречат другим существующим именам объектов ISO 8879. Коды символов ISO 10646 даны для каждого символа в шестнадцатеричной нотации. Значения CDATA приведены в десятичном виде ISO 10646 и относятся к символьному набору документа. Имена соответствуют Unicode 2.0. -->

Греческие символы (ISOgrk3)

Определение

Название символа

Уникод

<!ENTITY Alpha CDATA "&#913;">

Греческая прописная альфа (A)

U+0391

<!ENTITY Beta CDATA "&#914;">

Греческая прописная бета (B)

U+0392

<!ENTITY Gamma CDATA "&#915;">

Греческая прописная гамма (G)

U+0393

<!ENTITY Delta CDATA "&#916;">

Греческая прописная дельта (D)

U+0394

<!ENTITY Epsilon CDATA "&#917;">

Греческая прописная эпсилон (E)

U+0395

<!ENTITY Zeta CDATA "&#918;">

Греческая прописная зета (Z)

U+0396

<!ENTITY Eta CDATA "&#919;">

Греческая прописная эта (H)

U+0397

<!ENTITY Theta CDATA "&#920;">

Греческая прописная тэта (Q)

U+0398

<!ENTITY Iota CDATA "&#921;">

Греческая прописная иота (I)

U+0399

<!ENTITY Kappa CDATA "&#922;">

Греческая прописная каппа (K)

U+039A

<!ENTITY Lambda CDATA "&#923;">

Греческая прописная лямбда (L)

U+039B

<!ENTITY Mu CDATA "&#924;">

Греческая прописная мю (M)

U+039C

<!ENTITY Nu CDATA "&#925;">

Греческая прописная ню (N)

U+039D

<!ENTITY Xi CDATA "&#926;">

Греческая прописная кси (X)

U+039E

<!ENTITY Omicron CDATA "&#927;">

Греческая прописная омикрон (O)

U+039F

<!ENTITY Pi CDATA "&#928;">

Греческая прописная пи (P)

U+03A0

<!ENTITY Rho CDATA "&#929;">

Греческая прописная ро (R)

U+03A1

<!ENTITY Sigma CDATA "&#931;">*)

Греческая прописная сигма (S)

U+03A3

<!ENTITY Tau CDATA "&#932;">

Греческая прописная тау (T)

U+03A4

<!ENTITY Upsilon CDATA "&#933;">

Греческая прописная ипсилон (U)

U+03A5

<!ENTITY Phi CDATA "&#934;">

Греческая прописная фи (F)

U+03A6

<!ENTITY Chi CDATA "&#935;">

Греческая прописная хи (C)

U+03A7

<!ENTITY Psi CDATA "&#936;">

Греческая прописная пси (Y)

U+03A8

<!ENTITY Omega CDATA "&#937;">

Греческая прописная омега (W)

U+03A9

<!ENTITY alpha CDATA "&#945;">

Греческая строчная альфа (a)

U+03B1

<!ENTITY beta CDATA "&#946;">

Греческая строчная бета (b)

U+03B2

<!ENTITY gamma CDATA "&#947;">

Греческая строчная гамма (g)

U+03B3

<!ENTITY delta CDATA "&#948;">

Греческая строчная дельта (d)

U+03B4

<!ENTITY epsilon CDATA "&#949;">

Греческая строчная эпислон (e)

U+03B5

<!ENTITY zeta CDATA "&#950;">

Греческая строчная зета (z)

U+03B6

<!ENTITY eta CDATA "&#951;">

Греческая строчная эта (h)

U+03B7

<!ENTITY theta CDATA "&#952;">

Греческая строчная тета (q)

U+03B8

<!ENTITY iota CDATA "&#953;">

Греческая строчная иота (i)

U+03B9

<!ENTITY kappa CDATA "&#954;">

Греческая строчная каппа (k)

U+03BA

<!ENTITY lambda CDATA "&#955;">

Греческая строчная лямбда (l)

U+03BB

<!ENTITY mu CDATA "&#956;"

Греческая строчная мю (m)

U+03BC

<!ENTITY nu CDATA "&#957;">

Греческая строчная ню (n)

U+03BD

<!ENTITY xi CDATA "&#958;">

Греческая строчная кси (x)

U+03BE

<!ENTITY omicron CDATA "&#959;">

Греческий строчный омикрон (o)

U+03BF

<!ENTITY pi CDATA "&#960;">

Греческая строчная пи (p)

U+03C0

<!ENTITY rho CDATA "&#961;">

Греческая строчная ро (r)

U+03C1

<!ENTITY sigmaf CDATA "&#962;">

Греческая строчная финальная сигма

U+03C2

<!ENTITY sigma CDATA "&#963;">

Греческая строчная сигма (s)

U+03C3

<!ENTITY tau CDATA "&#964;">

Греческая строчная тау

U+03C4

<!ENTITY upsilon CDATA "&#965;">

Греческий строчный ипсилон (u)

U+03C5

<!ENTITY phi CDATA "&#966;">

Греческая строчная фи (j)

U+03C6

<!ENTITY chi CDATA "&#967;">

Греческая строчная хи (c)

U+03C7

<!ENTITY psi CDATA "&#968;">

Греческая строчная пси (y)

U+03C8

<!ENTITY omega CDATA "&#969;">

Греческая строчная омега (w)

U+03C9

<!ENTITY thetasym CDATA "&#977;">

Греческий тета символ

U+03D1

<!ENTITY upsih CDATA "&#978;">

Греческий ипсилон с крючком

U+03D2

<!ENTITY piv CDATA "&#982;">

Греческий символ пи

U+03D6

*) Не существует Sigmaf, и нет также символа U+03A2

Общая пунктуация

Определение

Название символа

Уникод

Название набора

<!ENTITY ensp CDATA "&#8194;">

en пробел

U+2002

ISOpub

<!ENTITY emsp CDATA "&#8195;">

em пробел

U+2003

ISOpub

<!ENTITY thinsp CDATA "&#8201;">

Узкий пробел

U+2009

ISOpub

<!ENTITY zwnj CDATA "&#8204;">

Разрываемый соединитель нулевой ширины

U+200C

NEW RFC 2070

<!ENTITY zwj CDATA "&#8205;">

Соединитель нулевой ширины

U+200D

NEW RFC 2070

<!ENTITY lrm CDATA "&#8206;">

Знак слево-направо

U+200E

NEW RFC 2070

<!ENTITY rlm CDATA "&#8207;">

Знак справа-налево

U+200F

NEW RFC 2070

<!ENTITY ndash CDATA "&#8211;">

en дефис

U+2013

ISOpub

<!ENTITY mdash CDATA "&#8212;">

em дефис

U+2014

ISOpub

<!ENTITY lsquo CDATA "&#8216;">

Левая кавычка

U+2018

ISOnum

<!ENTITY rsquo CDATA "&#8217;">

Правая кавычка

U+2019

ISOnum

<!ENTITY sbquo CDATA "&#8218;">

Single low-9 quotation mark

U+201A

NEW

<!ENTITY ldquo CDATA "&#8220;">

Левая двойная кавычка

U+201C

ISOnum

<!ENTITY rdquo CDATA "&#8221;">

Правая двойная кавычка

U+201D

ISOnum

<!ENTITY bdquo CDATA "&#8222;">

double low-9 quotation mark

U+201E

NEW

<!ENTITY dagger CDATA "&#8224;"

Кинжал †

U+2020

ISOpub

<!ENTITY Dagger CDATA "&#8225;">

Двойной кинжал ‡

U+2021

ISOpub

<!ENTITY bull CDATA "&#8226;">

Маленький черный кружочек (bullet) • **)

U+2022

ISOpub

<!ENTITY hellip CDATA "&#8230;">

Многоточие = трехточечный пунктир …

U+2026

ISOpub

<!ENTITY permil CDATA "&#8240;"

Знак промиль ‰

U+2030

ISOtech

<!ENTITY prime CDATA "&#8242;">

Прайм = минуты = фут

U+2032

ISOtech

<!ENTITY Prime CDATA "&#8243;">

Дубль прайм = секунды = дюймы

U+2033

ISOtech

<!ENTITY lsaquo CDATA "&#8249;">

Одиночная, угловая левая кавычка

U+2039

Предложено ISO

<!ENTITY rsaquo CDATA "&#8250;">

Одиночная, угловая правая кавычка

U+203A

Предложено ISO

<!ENTITY oline CDATA "&#8254;">

Верхняя черта

U+203E

NEW

<!ENTITY frasl CDATA "&#8260;">

Косая черта дроби

U+2044

NEW

<!ENTITY euro CDATA "&#8364;">

Знак евро €

U+20AC

NEW

**) bullet не тождественен оператору bullet, U+2219

Буквоподобные символы

Определение

Название символа

Уникод

Название набора

<!ENTITY weierp CDATA "&#8472;">

Прописная письменная P

U+2118

ISOamso

<!ENTITY image CDATA "&#8465;">

Прописная жирная буква I = мнимая часть

U+2111

ISOamso

<!ENTITY real CDATA "&#8476;">

Прописная жирная буква R = символ действительной части

U+211C

ISOamso

<!ENTITY trade CDATA "&#8482;">

Символ торговой марки

U+2122

ISOnum

<!ENTITY alefsym CDATA "&#8501;">

Символ alef ***)

U+2135

NEW

***) Cимвол alef не тождественен букве иврита alef, U+05D0 хотя тот же самый глиф может быть использован для отображения обоих символов

Стрелки

Определение

Название символа

Уникод

Название набора

<!ENTITY larr CDATA "&#8592;">

Стрелка влево

U+2190

ISOnum

<!ENTITY uarr CDATA "&#8593;">

Стрелка вверх

U+2191

ISOnum

<!ENTITY rarr CDATA "&#8594;">

Стрелка вправо

U+2192

ISOnum

<!ENTITY darr CDATA "&#8595;">

Стрелка вниз

U+2193

ISOnum

<!ENTITY harr CDATA "&#8596;">

Двухсторонняя горизонтальная стрелка

U+2194

ISOamsa

<!ENTITY crarr CDATA "&#8629;">

Стрелка вниз с поворотом налево = возврат каретки

U+21B5

NEW

<!ENTITY lArr CDATA "&#8656;">

Двойная стрелка влево +)

U+21D0

ISOtech

<!ENTITY uArr CDATA "&#8657;">

Двойная стрелка вверх

U+21D1

ISOamsa

<!ENTITY rArr CDATA "&#8658;">

Двойная стрелка вправо ++)

U+21D2

ISOtech

<!ENTITY dArr CDATA "&#8659;">

Двойная стрелка вниз

U+21D3

ISOamsa

<!ENTITY hArr CDATA "&#8660;">

Двойная двухсторонняя стрелка

U+21D4

ISOamsa

+) Уникод не утверждает, что lArr тождественно 'implied by' но не имеет какого-либо другого символа для этих целей. Так ? lArr может использоваться для 'is implied by' как это рекомендует ISOtech

++) Уникод не утверждает, что это 'implies' символ, но не имеет другого символа для этих целей, таким образом, ? rArr может использоваться для 'implies' как это рекомендует ISOtech

Математические операторы

Определение

Название символа

Уникод

Название набора

<!ENTITY forall CDATA "&#8704;">

Для всех ∀

U+2200

ISOtech

<!ENTITY part CDATA "&#8706;">

Частный дифференциал ∂

U+2202

ISOtech

<!ENTITY exist CDATA "&#8707;">

Существует ∃

U+2203

ISOtech

<!ENTITY empty CDATA "&#8709;">

Пустой набор = диаметр ∅

U+2205

ISOamso

<!ENTITY nabla CDATA "&#8711;">

Набла = обратная разница

U+2207

ISOtech

<!ENTITY isin CDATA "&#8712;">

Элемент чего-то ∈

U+2208

ISOtech

<!ENTITY notin CDATA "&#8713;">

Не элемент чего-то ∉

U+2209

ISOtech

<!ENTITY ni CDATA "&#8715;">

Содержит, как член ∋

U+220B

ISOtech

<!ENTITY prod CDATA "&#8719;">

n-кратное произведение= знак произведения ∏#)

U+220F

ISOamsb

<!ENTITY sum CDATA "&#8721;">

n-кратная сумма ∑##)

U+2211

ISOamsb

<!ENTITY minus CDATA "&#8722;">

Знак минус −

U+2212

ISOtech

<!ENTITY lowast CDATA "&#8727;">

Оператор звездочка ∗

U+2217

ISOtech

<!ENTITY radic CDATA "&#8730;">

Квадратный корень = знак радикала √

U+221A

ISOtech

<!ENTITY prop CDATA "&#8733;">

пропорционально ∝

U+221D

ISOtech

<!ENTITY infin CDATA "&#8734;">

Бесконечность ( )

U+221E

ISOtech

<!ENTITY ang CDATA "&#8736;">

Угол (Р )

U+2220

ISOamso

<!ENTITY and CDATA "&#8743;">

Логическое И =призма ∧

U+2227

ISOtech

<!ENTITY or CDATA "&#8744;">

Логическое ИЛИ ∨

U+2228

ISOtech

<!ENTITY cap CDATA "&#8745;">

Пересечение ∩

U+2229

ISOtech

<!ENTITY cup CDATA "&#8746;">

Объединение ∪

U+222A

ISOtech

<!ENTITY int CDATA "&#8747;">

Интеграл ∫

U+222B

ISOtech

!ENTITY there4 CDATA "&#8756;">

Следовательно ∴

U+2234

ISOtech

<!ENTITY sim CDATA "&#8764;">

Оператор тильда = изменяется с = подобно тому ###)

U+223C

ISOtech

<!ENTITY cong CDATA "&#8773;">

Приблизительно равно ≅

U+2245

ISOtech

<!ENTITY asymp CDATA "&#8776;">

Почти равно= асимптотическое приближение к ≈

U+2248

ISOamsr

<!ENTITY ne CDATA "&#8800;">

Не равно (N )

U+2260

ISOtech

<!ENTITY equiv CDATA "&#8801;">

Идентично = тождественно равно ( )

U+2261

ISOtech

<!ENTITY le CDATA "&#8804;">

Меньше или равно (ё )

U+2264

ISOtech

<!ENTITY ge CDATA "&#8805;">

Больше или равно ∁

U+2265

ISOtech

<!ENTITY sub CDATA "&#8834;">

Входит в ∞

U+2282

ISOtech

<!ENTITY sup CDATA "&#8835;">

Включает в себя ∟

U+2283

ISOtech

<!ENTITY nsub CDATA "&#8836;">

Не является субнабором чего-то ∠

U+2284

ISOamsn

<!ENTITY sube CDATA "&#8838;">

Входит в или тождественен ∢

U+2286

ISOtech

<!ENTITY supe CDATA "&#8839;">

Включает в себя или тождественен ∣

U+2287

ISOtech

<!ENTITY oplus CDATA "&#8853;">

Плюс в кружочке = direct sum (Е )

U+2295

ISOamsb

<!ENTITY otimes CDATA "&#8855;">

Векторное произведение = знак умножения в кружочке (Д )

U+2297

ISOamsb

<!ENTITY perp CDATA "&#8869;">

Ортогонально = перпендикулярно (^ )

U+22A5

ISOtech

<!ENTITY sdot CDATA "&#8901;">

Оператор точка ####)

U+22C5

ISOamsb

#) prod не тождественен символу U+03A0 'греческая прописная буква pi' хотя один и тот же глиф может быть использован для отображения обоих

##) sum не тождественен символу U+03A3 'греческая прописная буква сигма' хотя один и тот же глиф может быть использован для отображения обоих

###) tilde оператор не тождественен символу U+007E, хотя один и тот же глиф может быть использован для отображения обоих

####) Оператор dot не тождественен символу U+00B7 центральная точка

Различные технические символы

Определение

Название символа

Уникод

Название набора

<!ENTITY lceil CDATA "&#8968;">

left ceiling = apl upstile

U+2308

ISOamsc

<!ENTITY rceil CDATA "&#8969;">

right ceiling (` )

U+2309

ISOamsc

<!ENTITY lfloor CDATA "&#8970;">

left floor = apl downstile

U+230A

ISOamsc

<!ENTITY rfloor CDATA "&#8971;">

right floor

U+230B

ISOamsc

<!ENTITY lang CDATA "&#9001;">

левая угловая скобка

U+2329

ISOtech

<!ENTITY rang CDATA "&#9002;">

правая угловая скобка= закрывающая скобка

U+232A

ISOtech

 

Геометрические формы

Определение

Название символа

Уникод

Название набора

<!ENTITY loz CDATA "&#9674;">

ромб (а )

U+25CA

ISOpub

 

Различные символы

Определение

Название символа

Уникод

Название набора

<!ENTITY spades CDATA "&#9824;">

черные пики ( )

U+2660

ISOpub

<!ENTITY clubs CDATA "&#9827;">

черные крести=лист кислицы ( )

U+2663

ISOpub

<!ENTITY hearts CDATA "&#9829;">

черные черви ( )

U+2665

ISOpub

<!ENTITY diams CDATA "&#9830;">

черные бубни ( )

U+2666

ISOpub

Эталонные символьные объекты для символов разметки текста и интернационализации

Эталонные символьные объекты в этой секции предназначены для символов разметки текста (markup) (они те же, что и в HTML 2.0 и 3.2), для обозначения пробелов и дефисов. Остальные символы в этой секции используются для интернационализации.

Добавлены некоторые символы из CP-1252, которые не встречаются в наборах HTMLlat1 или HTMLsymbol. Все они из диапазона 128 - 159 символьного набора cp-1252. Эти объекты позволяют обозначать символы независимо от платформы.

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

Список символов

<!-- Набор символьных объектов:
<!ENTITY % HTMLspecial PUBLIC "-//W3C//ENTITIES Special//EN//HTML">
%HTMLspecial; -->

<!-- Используется набор объектов ISO, если не введены новые имена. Новые имена (напр., не из списка ISO 8879) не будут конфликтовать с любыми существующими именами объектов ISO 8879. Коды символов ISO 10646 приводятся для всех символов в шестнадцатеричном виде. Значения CDATA представляют собой десятичные коды ISO 10646. Имена соответствуют именам Unicode 2.0. -->

Специальные символы HTML. Контроли C0 и базовый латинский

Определение

Название символа

Уникод

Название набора

<!ENTITY quot CDATA "&#34;">

Кавычка = APL quote

U+0022

ISOnum

<!ENTITY amp CDATA "&#38;">

Знак &

U+0026

ISOnum

<!ENTITY lt CDATA "&#60;">

Знак меньше чем

U+003C

ISOnum

<!ENTITY gt CDATA "&#62;">

Знак больше чем

U+003E

ISOnum

 

Латинские буквы, расширение А

Определение

Название символа

Уникод

Название набора

<!ENTITY OElig CDATA "&#338;">

Латинская прописная лигатура OE

U+0152

ISOlat2

<!ENTITY oelig CDATA "&#339;">

Латинская строчная лигатура oe

U+0153

ISOlat2

<!ENTITY Scaron CDATA "&#352;">

Латинская прописная буква S с короной

U+0160

ISOlat2

<!ENTITY scaron CDATA "&#353;">

Латинская строчная буква s с короной

U+0161

ISOlat2

<!ENTITY Yuml CDATA "&#376;">

Латинская прописная буква Y с тремой (умляутом)

U+0178

ISOlat2

Латинские буквы, расширение B

Определение

Название символа

Уникод

Название стандарта

<!ENTITY fnof CDATA "&#402;" -->

Латинская строчная буква f с крючком = флорин

U+0192

ISOtech

Модификаторы букв

Определение

Название символа

Уникод

Название стандарта

<!ENTITY circ CDATA "&#710;">

Модификатор буквы - облегченное ударение

U+02C6

ISOpub

<!ENTITY tilde CDATA "&#732;">

Малая тильда

U+02DC

ISOdia

Previous: 10.18 Краткий справочник по командам UNIX    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.20 Справочные данные по математике


previous up next index index
Previous: 10.19 Символьный набор HTML    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.21 Элементы теории графов

10.20 Справочные данные по математике
Семенов Ю.А. (ГНЦ ИТЭФ)

 

Прекрасна благодушная язвительность,
С которой в завихрениях истории
Хохочет бесноватая действительность
Над мудрым разумением теории

 

И. Губерман

Приводимые в данном разделе определения вляются "шпаргалкой" на случай, когда вы знаете предмет, но что-то забыли. Для первичного изучения математических основ рекомендую обратиться к серьезным монографиям и учебникам.

Условная вероятность .

В теории вероятностей характеристикой связи событий А и B служит условная вероятность P(А|B) события А при условии B, определяемая как P(А|B) = ,

где N(B) - число всех элементарных исходов w, возможных при условии наступления события B, а N(АB) - число тех из них, которые приводят к осуществлению события А.

Если событие B ведет к обязательному осуществлению А: b , то P(A|B)=1, если же наступление B исключает возможность события А: A*B=0, то P(A|B)=0. Если событие А представляет собой объединение непересекающихся событий A1, A2,.: A = , то P(A|B) = .

Если имеется полная система несовместимых событий B =B1, B2,. т.е. такая система непересекающихся событий, одно из которых обязательно осуществляется, то вероятность события A (P(A)) выражается через условные вероятности P(A|B) следующим образом:


(формула полной вероятности).

Множества.

Множество - это совокупность некоторых элементов. Если элемент х входит в множество А, это записывается как x О A. Соотношения A1 Н A2 или A2 К A1 означает, что A1 содержится во множестве A2 (каждый элемент х множества A1 входит в множество A2; A1 является подмножеством A2).
Суммой или объединением множеств А1 и А2 называется множество, обозначаемое A1 И A2, которое состоит из всех точек х, входящих хотя бы в одно из множеств A1 или A2.
Пересечением или произведением множеств А1 и А2 называется множество, обозначаемое A1 З A2, A1*A2 или A1A2, которое состоит из всех точек х, одновременно входящих и в A1 и в A2; пересечение произвольного числа множеств Аa состоит из всех точек х, которые одновременно входят во все множества Аa.
Пустые множества обозначаются 0.
Множества, дополнительные к открытым множествам топологического пространства Х, называются замкнутыми .
Нормированное пространство Х называется гильбертовым , если определена числовая функция двух переменных х1 и х2, обозначаемая (x1,x2) и называемая скалярным произведением, обладающим следующими свойствами:

  1. (x,x)Ё 0;
  2. (x,x)=0 тогда и только тогда, когда х=0;
  3. (l 1x1+l 2 x2, x) = l 1(x1,x) + l 2(x2,x);
  4. (x, l 1x1+l 2 x2) = l 1(x,x1) + l 2(x,x2)
при любых l 1, l 2 и x1, x2 ОX. Норма ||x|| элемента гильбертова пространства Х определяется как ||x||= .

Счетно-гильбертово пространство Х называется ядерным , если для любого р найдется такое q и такой ядерный оператор А в гильбертовом пространстве Х со скалярным произведением (х1,x2)=(х12)q, что (х1,x2)p=(Ax1,x2)q.

Действительное число M является верхней границей или нижней границей множества Sy действительных чисел y, если для всех y О Sy соответственно y ё M или yЁ M. Множество действительных или комплексных чисел ограничено (имеет абсолютную границу), если верхнюю границу имеет множество абсолютных величин этих чисел; в противном случае множество не ограничено. Каждое непустое множество Sy действительных чисел y, имеющее верхнюю границу, имеет точную верхнюю границу (наименьшую верхнюю границу) sup y, а каждое непустое множество действительных чисел y, имеющее нижнюю границу, имеет точную нижнюю границу (наибольшую нижнюю границу) inf y. Если множество Sy конечно, то его точная верхняя граница sup y необходимо равна наибольшему значению (максимуму) max y, фактически принимаемому числом y в Sy , а точная нижняя граница inf y равна минимуму min y.
Множество называется открытым, если оно состоит только из внутренних точек. Точка P множества называется внутренней для множества S, если P имеет окрестность, целиком содержащуюся в S.

Компакт. Система множеств G называется центрированной , если пересечение конечного числа любых множеств из G не пусто. Замкнутое множество A Н X называется компактом , если всякая центрированная система G его замкнутых подмножеств F имеет непустое пересечение: Множество А называется компактным в Х, если его замыкание F=[A] является компактом .

Гауссовы случайные процессы .

Действительная случайная величина x называется гауссовой, если ее характеристическая функция j =j (u) имеет вид

;
фигурирующие здесь параметры a и s 2 имеют простой вероятностный смысл: a=Mx (среднее значение), s 2 = Dx (средне-квадратичное отклонение). Соответствующее распределение вероятностей также называется гауссовым, его плотность имеет вид

Марковские случайные процессы .

Случайный процесс x =x(t) на множестве T действительной прямой в фазовом пространстве ( E,B ) называется марковским, если условные вероятности P(A| U (-,s) событий AО U (t, ) относительно s-алгебры U (-,s) таковы, что при s ёt с вероятностью 1
,
здесь U (u,v) означает s-алгебру порождаемую всевозможными событиями вида { x(t) О B}, t О[u,v]З T, BО B . Если параметр t интерпретировать как время, то описанное марковское свойство случайного процесса x =x (t) состоит в том, что поведение процесса после момента t при фиксированном состоянии x= x (t) не зависит от поведения процесса до момента t. Для любых событий А О U (-,t1) и A2 О U (t1, ) и при любом t О T t1 ёtё t2 с вероятностью 1

P(A1A2|x (t)) = P(A1|x (t)) P(A2|x(t)).

Цепи Маркова . Пусть x (t) - состояние системы в момент времени t, и пусть соблюдается следующая закономерность: если в данный момент времени s система находится в фазовом состоянии i, то в последующий момент времени t система будет находиться в состоянии j с некоторой вероятностью pij(s,t) независимо от поведения системы до указанного момента s. Описывающий поведение системы процесс x (t) называется цепью Маркова. Вероятности pij(s,t) = p{x (t)=j|x (s)=i} (i,j = 1, 2, .) называются переходными вероятностями марковской цепи x (t).

Марковская цепь x (t) называется однородной , если переходные вероятности pij(s,t) зависят лишь от разности t-s: pij(s,t) = pij(s-t) (i,j=1,2,.)

Финальные вероятности . Пусть состояния однородной марковской цепи x (t) образует один замкнутый положительный непериодический класс. Тогда для любого состояния j существует предел  (j=1, 2,.), один и тот же при всех исходных состояниях i=1,2,.. Предельные значения P1, P2,. представляют собой распределение вероятностей: pj есть финальная вероятность находиться в состоянии j; при этом
Pj=  (j=1,2,...),
где Qj - среднее время возвращения в состояние j в дискретные моменты t = 0, 1, 2, . .

Коэффициент эргодичности . Пусть x =x (t) - случайный марковский процесс в фазовом пространстве (E, B ) с переходной функцией P(s,x,t,B). С вероятностью 1 имеет место равенство

b (s,t) = |P(A| U (-¥, s))- P(A| =

Величина k(s,t) = 1 -

называется коэффициентом эргодичности марковского процесса x =x (t).

Переходная функция. Функция P(s,x,t,B) переменных s, tО T, s ё t и xО E, bО b называется переходной функцией марковского случайного процесса x =x (t) на множестве T в фазовом пространстве (E, B ), если эта функция при фиксированных s, tО T и xО E представляет собой распределение вероятностей на s -алгебре b и при фиксированных s, tО T и BО b является измеримой функцией от x О E.

Стационарные случайные процессы . Стационарный действительный или комплексный случайный процесс x =x (t), рассматриваемый как функция параметра t со значениями в гильбертовом пространстве L2(W) всех действительных или комплексных случайных величин h =h (w), M|h |2< (со скалярным произведением
(h 1, h 2)= M h 1 h 2),
может быть представлен в виде

Белый шум. Простейшим по структуре стационарным процессом с дискретным временем является процесс z =z (t) с некоррелированными значениями:

Mz(t)=0, M|z(t)|2=1,
Mz(t1) при t1 ≠ t2

В случае непрерывного времени t аналогом такого процесса является так называемый "белый шум" - обобщенный стационарный процесс z = б u, z с вида


(параметр u=u(t) есть бесконечно дифференцируемая функция), где стохастическая мера z = z (d ) такова, что

Mz (D )=0, M|z (D )|2 =t-s при D =(s,t), Mz (D 1) z (D 2)=0 для любых непересекающихся D 1 и D 2.

Стационарный процесс x= x(t), Mx(t)=0, называется линейно-регулярным, если
,
где H(s,t) - замкнутая линейная оболочка в пространстве L2(W) значений x(u), s ё u ё t. Стационарный процесс x =x(t) со спектральной мерой F является линейно-регулярным тогда и только тогда, когда F=F( D) абсолютно непрерывна:
F(D) =
а спектральная плотность f=f(l) удовлетворяет условию

(для дискретного t)


(для непрерывного t)

Стационарный процесс x =x(t) линейно-регулярен тогда и только тогда, когда он получается некоторым физически осуществимым линейным преобразованием из процесса z = z(t) с некоррелированными значениями - в случае дискретного t:

x(t) =

и из процесса z =б u, z с "белого шума" - в случае непрерывного t:

x(t) =

Регулярность . Реальные стационарные процессы часто возникают в результате некоторого случайного стационарного возмущения Z = z (t) типа "белого шума". Процесс z = z(t) подвергается некоторому линейному преобразованию и превращается в стационарный процесс x =x(t). Спектральная плотность f= f(l) такого процесса в диапазоне -p ё l ё p для целочисленного времени и - <l < для непрерывного времени t не может обращаться тождественно в нуль ни на каком интервале: в противном случае стационарный процесс x (t) будет сингулярным, что означает возможность его восстановления лишь на полуоси - ,t0. Процессы, спектр которых практически сосредоточен в полосе частот -W< l <W, не обладают свойствами сингулярных процессов. С энергетической точки зрения эти процессы имеют ограниченный спектр. Составляющие их гармонические колебания вида Ф(dl )eilt с частотами вне интервала (-W,W) имеют весьма малые энергии, но они существенно влияют на линейный прогноз значений x (t+t) на основе x (s) на временной полуоси sёt.

Линейные устройства, используемые при решении конкретных задач, должны иметь вполне определенную постоянную времени T (определяет длительность переходных процессов). Это означает, что весовая функция h=h(t) рассматриваемого линейного устройства, связанная с соответствующей передаточной функцией Y =Y(p) равенством

должна удовлетворять требованию h(t)=0 при t>T.
Рассмотрим задачу линейной фильтрации при наличии на входе процесса x =x(t). Тогда x (t)= z (t) +h(t), где h =h(t) - полезный сигнал, а z(t) - независимый от него стационарный случайный процесс (шум). Линейное устройство должно быть выбрано так, чтобы процесс на входе

был по возможности близок к входному полезному сигналу h = h(t), так что в стационарном режиме работы

Линейное устройство, отвечающее поставленным требованиям, должно иметь такую передаточную функцию Y=Y(p), чтобы соответствующая спектральная характеристика

являлась решением интегрального уравнения

Где

- спектральная плотность входного процесса x (t), а Bh h(t) - корреляционная функция полезного сигнала h (t).

Закон больших чисел . Пусть x 1,., x n - независимые случайные величины, имеющие одно и то же распределение вероятностей, в частности одни и те же математические ожидания a = M x k и дисперсии
s 2=Dx k, k=1,.,n. Каковы бы ни были e >0 и d >0, при достаточно большом n арифметическое среднее
(таким образом )
с вероятностью, не меньшей 1-d, будет отличаться от математического ожидания a лишь не более чем на

Распределение Эрланга

Рассмотрим систему, которая способна обслуживать m запросов одновременно. Предположим, что имеется m линий и очередной запрос поступает на одну из них, если хотя бы одна из них свободна. В противном случае поступивший запрос будет отвергнут. Поток запросов считается пуассоновским с параметром l 0 , а время обслуживания запроса (в каждом из каналов) распределено по показательному закону с параметром l , причем запросы обслуживаются независимо друг от друга. Рассмотрим состояния E0, E1,.,Em, где Ek означает, что занято k линий. В частности E0 означает, что система свободна, а Em - система полностью занята. Переход из одного состояния в другое представляет собой марковский процесс, для которого плотности перехода можно описать как:

При t переходные вероятности pij(t) экспоненциально стремятся к своим окончательным значениям Pj, j=0,.,m. Окончательные вероятности Pj могут быть найдены из системы:

-l 0P0+lP1=0

l 0Pk-1 - (l 0+kl)Pk + (k+1)lPk+1 =0 (1ё k<m)

l 0pm-1+ml Pm=0

решение которой имеет вид:

Эти выражения для вероятностей называются формулами (распределением) Эрланга.

Previous: 10.19 Символьный набор HTML    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.21 Элементы теории графов


previous up next index index
Previous: 10.20 Справочные данные по математике    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.22 Имена временных зон

10.21 Элементы теории графов
Семенов Ю.А. (ГНЦ ИТЭФ)

Графы представляют собой наиболее абстрактную структуру, с которой приходится сталкиваться в теории ЭВМ (computer science). Графы используются для описания алгоритмов автоматического проектирования, в диаграммах машины конечных состояний, при решении задач маршрутизации потоков и т.д. Любая система, предполагающая наличие дискретных состояний или наличие узлов и переходов между ними может быть описана графом. Соединения между узлами графа называются ребрами. Если узлы графа не нумерованы, то ребра являются неориентированными. У графа с нумерованными узлами ребра ориентированы. Ребрам могут быть присвоены определенные веса или метки. На рис. 10.21.1А и 10.21.1Б приведены примеры обычного и ориентированного графа.

Рис. 10.21.1 Примеры неориентированного и ориентированного графов (А и Б)

Введем более строгие определения. Граф представляет собой структуру П = <V,E>, в которой V представляет собой конечный набор узлов, а EН VЕV представляет собой конечный набор ребер. Для ориентированного графа E Н V V - конечный набор ориентированных ребер. Ребром может быть прямая или кривая линия. Ребра не могут иметь общих точек кроме вершин (узлов) графа. Замкнутая кривая в E может иметь только одну точку из множества V, а каждая незамкнутая кривая в E имеет ровно две точки множества V. Если V и E конечные множества, то и граф им соответствующий называется конечным . Граф называется вырожденным , если он не имеет ребер. Параллельными ребрами графа называются такие, которые имеют общие узлы начала и конца.

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

Граф G называется плоским , если его можно отобразить в плоскости без пересечения его граней.

Очертанием графа (face) считается любая топологически связанная область, ограниченная ребрами графа.

Неориентированный граф G = <V,E> называется связанным , если для любых двух узлов x,y О V существует последовательность ребер из набора E, соединяющий x и y.

Граф G связан тогда и только тогда, когда множество его вершин нельзя разбить на два непустых подмножества V1 и V2 так, чтобы обе граничные точки каждого ребра находились в одном и том же подмножестве.

Граф G называется k-связным (k Ё 1), если не существует набора из k-1 или меньшего числа узлов V`Н V, такого, что удаление всех узлов V` и сопряженных с ними ребер, сделают граф G несвязанным.

Теорема Менгера: граф G является k-связанным тогда и только тогда, когда любые два различные узла x и y графа G соединены по крайне мере k путями, не содержащими общих узлов.

k-связанные графы представляют особый интерес для сетевых приложений. Определенную проблему составляет автоматическое отображение графа на экране или бумаге. Кроме того, для многих приложений (например, CAD) все узлы графа должны совпадать с узлами технологической сетки. Возникают и другие ограничения, например необходимость размещения всех узлов на прямой линии. В этом случае ребра графа могут представлять собой кривые линии, дуги или ломаные линии, состоящие из отрезков прямых. Смотри, например, рисунок 10.21.2.

Рис. 10.21.2

Граф слева безусловно легче воспринять, чем граф справа, хотя они эквивалентны. Существует ряд алгоритмов, позволяющих определить, является ли граф плоским. Так граф на рис. 10.21.3 на первый взгляд не является плоским (ведь его ребра пересекаются в нескольких местах). Но он может быть перерисован (см. рис. 10.21.3а), после чего его плоскостность уже не подвергается сомнению.

 

1

2

3

4

5

1

0

0

1

1

0

2

0

0

0

1

1

3

1

0

0

0

1

4

1

1

0

0

0

5

0

1

1

0

0

Матрица смежности графа G

Рис. 10.21.3. Граф и его матрица смежности

Рис. 10.21.3а. Преобразование графа с рис 3

Матрица смежности, характеризующая этот граф, эквивалентна приведенной на рис. 10.21.3, а сами графы изоморфны . Для представления графа может использоваться Булева функция S(x,y), для которой S(i,j)=1 тогда и только тогда, когда (i,j)О E. S(i,j) обозначает ребро графа, соединяющее узлы i и j. Одной из возможностей реализации s является использование матрицы смежности А графа g. А - двухмерная матрица.

Для описания графа с помощью матрицы смежности A(i,j), где (i,j)О E, необходимо пронумеровать узлы графа. Элементы матрицы могут принимать значения 0 или 1. Так как представленный на рисунке граф не имеет ребер исходящих и завершающихся в одном и том же узле (нет петель), диагональные элементы матрицы равны нулю. Единицы присутствуют в позициях, которые соответствуют парам узлов, соединенных ребрами, например, 1-3, 1-4 или 5-2 и 5-3. Число ребер, исходящих из вершины (петля учитывается дважды), называется степенью вершины d(v). В конечном графе число вершин с нечетной степенью всегда четно.

Другой способ представления графа обеспечивает функция, которая выдает списки узлов, с которыми данный узел связан непосредственно. Для графа, отображенного на рис. 10.21.4, такое описание можно представить в виде структуры (таблица 10.21.1). В колонке s представлены номера узлов, далее в строке таблицы следует список соседних узлов. По этой причине число колонок в каждой из строк различно.

Рис. 10.21.4

Таблица 10.21.1.

S

Список "соседних" узлов

1

2

5

6

 

2

1

3

 

 

3

2

4

5

 

4

3

 

 

 

5

1

3

6

7

6

1

5

7

 

7

5

6

 

 

Нули и единицы в матрице смежности могут быть заменены целыми числами, характеризующими путь из точки i в точку j (например, метрика маршрута телекоммуникационной сети). Такая матрица называется матрицей оценки . Граф называется обыкновенным , если он не содержит петель и параллельных ребер.

Граф называется полным , если любые две вершины являются смежными.

Если для всех вершин d(v) = k, то граф называется однородным графом степени k или k-однородным. Граф на рис. 10.21.5 является полным и 3-однородным.

Рис. 10.21.5.

Конечная последовательность ребер графа e 1, e2,.,en называется маршрутом длины n. Маршрут называется замкнутым, если вершины начала и конца маршрута совпадают. Если ребра, образующие маршрут различны, то такой маршрут называется цепью .

Граф называется деревом , если он связан и не имеет циклов. Граф является деревом тогда и только тогда, когда каждая пара различных вершин соединяется одной и только одной цепью. Каждое дерево с n вершинами имеет ровно n-1 ребро. Удаление любого ребра в дереве делает его несвязным. По этой причине дерево можно считать минимальным связным графом. Если все вершины графа G принадлежат дереву Т, то считается, что дерево покрывает граф G.

Граф, не имеющий циклов и состоящий из k компонент, называется лесом из k деревьев. Лес из k деревьев, содержащий n вершин имеет в точности n-k ребер.

Пусть G=(v,e) связный граф и FМ E подмножество его ребер. При этом F называется разделяющим подмножеством тогда и только тогда, когда подграф G'=(V, E-F) несвязан. E-F обозначает множество ребер, которое принадлежит Е, но не принадлежит F.

Если узлы графа могут быть соединены несколькими путями, сеть, описываемая таким графом, обладает повышенной надежностью. Рассмотрим задачу выбора оптимального дерева маршрутов, лишенного циклов, в такой сети (см. рис. 10.21.6). Алгоритм используется в схеме "расширяющееся дерево" для локальных сетей со сложной топологией. Алгоритм преобразует многосвязный граф в плоский без замкнутых структур.

Рис. 10.21.6.

В качестве начального выбираем узел 1. Матрица оценки формируется поэтапно (А-E). На этапе А выбирается узел 5, так как к нему ведет ребро с метрикой 1. Здесь становятся доступными ребра, ведущие к узлам 2, 4, 6 и 7. Ребро 1-5 из рассмотрения устраняется. На следующем этапе выбирается узел 7, к нему от узла 5 ведет ребро с метрикой 1. Здесь в рассмотрение включаются ребра 7-4 и 7-8. Следующим выбранным узлом становится 4 и включается в перечень ребро 4-2. Далее рассматривается узел 6 и ребра 6-8 и 6-3.

В результате граф приобретает вид, показанный на рисунке 10.21.7.

Рис. 10.21.7.

Рассмотренный алгоритм сходен с алгоритмом Дикстры, используемым для поиска наилучшего пути во внутреннем протоколе маршрутизации ospf.

Выбранный метод аналитического представления графа достаточно прост, но требует для графа с N узлами N2 ячеек памяти (бит). Впрочем, для неориентированного графа матрица является симметричной и для ее хранения в памяти ЭВМ достаточно N(N-1)/2 ячеек. Это справедливо и для ориентированных графов без петель.

Петлей называется ребро графа, которое начинается и завершается в одном и том же узле (рис. 10.21.8).

Рис. 10.21.8.

Справедливо следующее утверждение. Узлы i,j соединены путем длиной k тогда и только тогда, когда Ak(i,j)=1.

Надо сказать, что графы являются весьма удобным средством описания и оптимизации алгоритмов вычисления. В качестве примера рассмотрим вычисление квадратного полинома ax2+bx+c по схеме Горнера (рис. 10.21.9).

Рис. 10.21.9. Граф вычисления квадратного полинома по схеме Горнера.

Previous: 10.20 Справочные данные по математике    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.22 Имена временных зон


previous up next index index
Previous: 10.22 Имена временных зон    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.24 Сети Петри

10.23 Модель машины конечных состояний
Семенов Ю.А. (ГНЦ ИТЭФ)

Базовой концепцией построения многих современных протоколов является машина конечных состояний (FSM - Finite State Machine). При этом подходе каждый протокол характеризуется машиной, которая в любой момент времени находится в каком-то конкретном состоянии. Каждому состоянию соответствует определнный набор значений системных переменных. Такой подход требует определенного уровня абстрагирования. Например, для того чтобы ЭВМ перешла из состояния ожидания в состояние, когда получено некоторое сообщение, реализуется достаточно много промежуточных операций (проверка качества сигнала, контроль целостности сообщения, проверка отсутствия переполнения буфера и многие другие). Все эти промежуточные операции и состояния считаются переходными и в данной модели не рассматриваются. Таким образом, состояние протокольной машины полностью определяется набором значений определенных системных переменных. Так состояние протокольной машины канала определяется состояниями клиента и сервера. Если состояние как отправителя так и получателя характеризуются двумя битами, то состояние системы будет характеризоваться 16 состояниями. Из любого состояния может быть нуль или более возможных переходов в другое состояние. Переход из одного состояние в другое происходит при наступлении определенного события (например, полчение сообщения, прерывание, таймаут и т.д.).

Машина состояний протокола может быть охарактеризована с помощью ориентированного графа, в котором число узлов равно числу конечных состояний системы, а число ребер всей совокупности возможных переходов из одного состояния в другое. Одно из состояний выбирается в качестве исходного. Из этого состояния система может попасть в некоторые (все) другие состояния с помощью последовательности переходов. Данный подход позволяет часто выявить слабые места протокола (например, возможности "повисаний").

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

S

Набор состояний процессов и канала

M

Набор кадров, которые могут быть переданы по каналу

I

Набор исходных состояний процессов

T

Набор переходов между состояниями

В начальный момент все процессы находятся в исходных состояниях. Дальнейшие переходы из состояния в состояние определяются событиями, происходящими в системе. Каждое событие может вызвать переход в новое состояние какого-то процесса или канала. Если в результате анализа графа машины конечных состояний выясняется, что в случае прихода кадра некоторого типа, не определено, в какое состояние должна перейти машина, это свидетельствует о наличии ошибки в протоколе. Если обнаруживается одно или несколько состояний, из которых нет перехода куда-либо во вне (тупик), такое положение также свидетельствует об ошибке. В качестве примера машины конечных состояний можно рассмотреть граф протокола TCP.

Previous: 10.22 Имена временных зон    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.24 Сети Петри


previous up down next index index
Previous: 10.1 Рекомендации CCITT по телекоммуникациям    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.3 Стандартные мультикастинг-адреса Интернет

10.2 Коды протоколов в Ethernet II
Семенов Ю.А. (ГНЦ ИТЭФ)

Десятичный код

Hex

Описание

 

0-05DC

Поле длины IEEE 802.3

512

0200

XEROX PUP (PARC Universal Packet)

513

0201

Трансляция адреса для пакетов PUP

1536

0600

XEROX NS IDP

2048

0800

Internet протокол (IPv4)

2049

0801

X.75 Internet

2050

0802

NBS Internet

2051

0803

ECMA Internet

2052

0804

Chaosnet

2053

0805

X.25 уровень 3

2054

0806

Протокол трансляции адреса (ARP)

2055

0807

XNS совместимость

2560

0A00

Xerox IEEE-802.3 PUP

4096

1000

Berkley Trailer

21000

5208

BBN Simnet

24577

6001

DEC MOP Dump/Load

24578

6002

DEC MOP удаленный терминал

24579

6003

DEC DECnet фаза IV

24580

6004

DEC LAT (Local Area Transport)

24582

6005

Диагностический протокол DEC

24583

6006

Протокол пользователя DEC

24586

6010-6014

Корпорация 3Com

28720

7030

Proteon

32773

8005

HP Probe

32776

8008

AT&T

32784

8010

Excelan

32787

8013

Диагностика SGI

32788

8014

Сетевые игры SGI

32793

8019

Apollo Computers

32821

8035

Реверсивный протокол ARP (RARP)

32824

8038

DEC LANbridge

32829

803D

Ethernet шифрование DEC

32831

803F

Сетевой монитор трафика DEC

32872

8068

General Dynamics

32873

8069

AT&T

32923

809B

AppleTalk

33011

80F3

AppleTalk AARP

33072

8130

Heyes Microcomputers

33079

8137-8138

NetWare IPX/SPX

33100

814C

SNMP

 

818D

Motorola Computer

 

81A5-81AE

RAD Network Devices

36865

9001

3Com(Bridge) XNS Sys Mgmt(Системное управление XNS)

36866

9002

3Com(Bridge) TCP-IP System

Previous: 10.1 Рекомендации CCITT по телекоммуникациям    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.3 Стандартные мультикастинг-адреса Интернет


previous up down next index index
Previous: 10.2 Коды протоколов в Ethernet II    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.4 Таблица операций и субопераций NCP

10.3 Стандартные мультикастинг-адреса Интернет
Семенов Ю.А. (ГНЦ ИТЭФ)

Адрес

Зона действия

Нормативный документ

224.0.0.0

Базовый адрес мультикастинга (зарезервировано)

RFC-1112

224.0.0.1

Все системы этой субсети

RFC-1112

224.0.0.2

Все маршрутизаторы этой субсети

224.0.0.3

Не стандартизовано

224.0.0.4

DVMRP маршрутизаторы

RFC-1075

224.0.0.5

Все маршрутизаторы OSPFIGP

RFC-1583

224.0.0.6

Заданные маршрутизаторы OSPFIGP

RFC-1583

224.0.0.7

Маршрутизаторы ST

RFC-1190

224.0.0.8

ЭВМ ST

RFC-1190

224.0.0.9

Маршрутизаторы RIP2

224.0.0.10

Маршрутизаторы IGRP

224.0.0.11

Mobile-Agents

224.0.0.12-224.0.0.255

Не стандартизовано

224.0.1.0

Группа менеджеров VMTP

RFC-1045

224.0.1.1

Протокол сетевого времени

RFC-1119

224.0.1.2

SGI-Dogfight

224.0.1.3

Rwhod

224.0.1.4

VNP

224.0.1.5

Artificial Horizons - Aviator

224.0.1.6

Сервер имен (NSS)

224.0.1.7

AUDIONEWS - мультикастинг аудио-новостей

224.0.1.8

SUN NIS + Информационная служба

224.0.1.9

Мультикастинг транспортный протокол (MTP)

224.0.1.10

IETF-1-LOW-AUDIO

224.0.1.11

IETF-1-AUDIO

224.0.1.12

IETF-1-VIDEO

224.0.1.13

IETF-2-LOW-AUDIO

224.0.1.14

IETF-2-AUDIO

224.0.1.15

IETF-2-VIDEO

224.0.1.16

MUSIC-SERVICE

224.0.1.17

Телеметрия SEANET

224.0.1.18

SEANET-IMAGE

224.0.1.19

MLOADD

224.0.1.20

Любой частный эксперимент

224.0.1.21

DVMRP на MOSPF

224.0.1.22

SVRLOC

224.0.1.23

XINGTV

224.0.1.24

microsoft-ds

224.0.1.25

nbc-pro

224.0.1.26

P>nbc-pfn

224.0.1.27-224.0.1.255

Не стандартизовано

224.0.2.1

"rwho" Group(BSD) (неофициально)

224.0.2.2

SUN RPC PMAPPROC_CALLIT

224.0.3.000-224.0.3.255

RFE Generic Service

224.0.4.000-224.0.4.255

RFE Individual Conferences

224.0.5.000-224.0.5.127

Группы CDPD

224.0.5.128-224.0.5.255

Не стандартизовано

224.0.6.000-224.0.6.127

Проект Cornell ISIS

224.0.6.128-224.0.6.255

Не стандартизовано

224.1.0.0-224.1.255.255

ST Multicast Groups

RFC-1190

224.2.0.0-224.2.255.255

Multimedia Conference Calls

224.252.0.0-224.255.255.255

DIS transient groups

232.0.0.0-232.255.255.255

VMTP transient groups

RFC-1045

Previous: 10.2 Коды протоколов в Ethernet II    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.4 Таблица операций и субопераций NCP


previous up down next index index
Previous: 10.4 Таблица операций и субопераций NCP    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.6 Таблица типов кадров управления доступом для сети Token Ring

10.5 Таблица операций службы каталогов Netware
Семенов Ю.А. (ГНЦ ИТЭФ)

Код операции

Описание

0x01

Resolve Name

0x02

Read Entry Information

0x03

Read

0x04

Compare

0x05

List

0x06

Search Entries

0x07

Add Entry

0x08

Remove Entry

0x09

Modify Entry

0x0A

Modify Relative Distinguished Name

0x0B

Define Attribute

0x0C

Read Attribute Definition

0x0D

Remove Attribute Definition

0x0E

Define Class

0x0F

Read Class Definition

0x10

Modify Class Definition

0x11

Remove Class Definition

0x12

List Containable Classes

0x13

Get Effective Rights

0x14

Add Partition

0x15

Remove Partition

0x16

List Partitions

0x17

Split Partition

0x18

Join Partition

0x19

Add Replica (копия секции каталога)

0x1A

Remove Replica

0x1B

Open Stream

0x1D

Create Subordinate Reference

0x1E

Link Replica

0x1F

Change Replica Type

0x20

Start Update Schema

0x21

End Update Schema

0x22

Update Schema

0x23

Start Update Replica

0x24

End Update Replica

0x25

Update Replica

0x26

Synchronize Partition

0x27

Synchronize Schema

0x29

Get Replica Root ID

0x2A

Begin Move Entry

0x2B

Finish Move Entry

0x2C

Release Move Entry

0x2D

Backup Entry

0x2E

Restore Entry

0x32

Close Iteration

0x35

Get Server Address

0x36

Set Keys

0x3B

Begin Authentication

0x3C

Finish Authentication

0x3F

Repair Timestamps

0x40

Create Back Link

0x41

Delete External Reference

0x42

Rename External Reference

0x43

Create Entry Directory

0x44

Remove Entry Directory

0x45

Designate New Master

0x46

Change Tree Name

0x47

Partition Entry Count

0x48

Check Login Restrictions

0x49

Start Join

0x4A

Low Level Split

0x4B

Low Level Join

0x4C

Abort Low Level Join

0x4D

Get All Servers

Previous: 10.4 Таблица операций и субопераций NCP    UP: 10.1 Рекомендации CCITT по телекоммуникациям
Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.6 Таблица типов кадров управления доступом для сети Token Ring


previous up next index index
Previous: 10.21 Элементы теории графов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.23 Модель машины конечных состояний

10.22 Имена временных зон
Семенов Ю.А. (ГНЦ ИТЭФ)

Временная зона

Сокращение

Универсальное время (Universal Time, тоже, что и GMT)

UT

Время по Гринвичу (Greenwich Mean Time)

GMT

Восточное стандартное время (Eastern Standard Time)

EST

Центральное стандартное время (Central Standard Time)

CST

Центральное дневное время (Central Daylight Time)

CDT

Mountain Standard Time

MST

Mountain Daylight Time

MDT

Pacific Standard Time

PST

Pacific Daylight Time

PDT

Previous: 10.21 Элементы теории графов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.23 Модель машины конечных состояний


previous up next index index
Previous: 10.23 Модель машины конечных состояний    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.25 Интернет вчера, сегодня и завтра

10.24 Сети Петри
Семенов Ю.А. (ГНЦ ИТЭФ)

Протоколы можно описывать не только с помощью модели машины конечных состояний. Альтернативой можно считать сети Петри (смотри, также книгу "Сети Петри", Котов В.Е., Москва, "Наука", ГРФМЛ, 1984 откуда взяты некоторые примеры и фрагменты данной статьи). Модель сети Петри является принципиально асинхронной и служит для отображения и анализа причинно-следственных связей в системе. Для привязки к определенным моментам времени тех или иных переходов в синхронных системах используются события. Переходы из состояния в состояния считаются "мгновенными". Если переход реально происходит через какие-то промежуточные состояния, а нам существенно учесть в модели эти обстоятельства, то вводятся соответствующие "подсобытия". Сеть Петри имеет четыре базовых элемента: позиции (places), переходы, дуги и метки (token).

Позиция (место) - это состояние, в котором находится система или определенная ее часть. Смотри рис. 10.24.1.

Рис. 10.24.1. Сеть Петри с двумя позициями и двумя переходами. Цифрами 1 и 2 обозначены переходы, а буквами А и Б - позиции.

Состояние системы формируется в результате реализации локальных операций, называемых условиями реализации событий. Условие имеет емкость:

  • Условие не выполнено - емкость равна нулю
  • Условие выполнено - емкость равна 1.
  • Условие выполнено с n-кратным запасом - емкость равна n.

Определенная комбинация условий может стимулировать определенное событие, которое вызовет в свою очередь изменение изменение условий. В сетях Петри события и условия отображаются абстрактными символами, называемыми переходами(вертикальными или горизонатальными полосками - "барьерами") и позициями (кружками). Условия-позиции и события-переходы связаны отношениями зависимости, которые отображаются с помощью ориентированных дуг. Позиции, из которых исходят дуги данного перехода, называются входными позициями. Позиции же, к которым ведут дуги данного перехода, называются выходными позициями. Выполнение условий отображается помещением соотвествтующего числа меток в соответствующую позицию. Если число меток велико (более 2-3), емкость условия может быть отображена числом.

В исходный момент система находится в состоянии А, что отмечено на рис. 4.9. меткой в виде синего кружочка. Переходы обозначаются горизонтальными или вертикальными линиями. Каждый переход имеет нуль или более входных дуг, исходящих из позиций, и нуль или более исходящих дуг, направленных к выходным позициям. Переход разрешен, если имеется как минимум одна входая метка в каждой из его исходных позиций. Любой разрешенный переход может произойти (fire), удалив все входные метки и установив метки в выходных позициях, что отражает изменение условий (и емкостей). Если числа входных и выходных дуг отличаются, число меток не сохраняется. Если разрешено более одного перехода, может произойти любой из них. Причем один из осуществившихся переходов, может блокировать реализацию всех остальных переходов из данного набора. Формализм сетей Петри не предусматривает каких-либо механизмов преодоления подобных конфликтов. Переход осуществляется, если выполнены все условия реализации данного события. Если два или более переходов могут осуществиться (выполнены все условия) и они не имеют общих входных позиций, то из реализация некоррелирована и может происходить параллельно или в любой последовательности. Выбор перехода, вообще говоря, не определен. В отличии от модели машины конечных состояний здесь отсутствуют комбинированные состояния типа отправитель-канал-получатель, и переходы из состояния в состояние для каждого процесса или объекта рассматриваются независимо. Если условия ни для одного из переходов не реализованы, сеть переходит в заблокированное состояние.

Аналитическое определение. Сеть Петри - набор N = (P, T, F, W, M0), где (P, T, F) - конечная сеть (множество Х = ЗuT конечно), а W: F→ N\ {O} (знак \ здесь означает разность множеств) и M0: P→N - две функции, называемые кратностью дуг и начальной пометкой. Первая ставит в соответствие каждой дуге число N>0 (кратность дуги). Если N>0, то при графическом представлении сети число N выписывается рядом с короткой чертой, пересекающей дугу. Дуги с кратностью 1 не помечаются. Каждой позиции p ставится в соответствие некоторое число M0(p) N (пометка позиции).

Формально работа сети Петри описывается множеством последовательностей срабатываний и множеством реализуемых разметок позиций.

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

Previous: 10.23 Модель машины конечных состояний    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
   Next: 10.25 Интернет вчера, сегодня и завтра


previous up next index index
Previous: 10.24 Сети Петри    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
    Next: 10.26 Таблица цветов, их имен и кодов

10.25 Интернет вчера, сегодня и завтра
Семенов Ю.А. (ГНЦ ИТЭФ)

Если считать началом Интернет реализацию проекта ARPA-Net, то время его существования насчитывает более 31 года. Ведь в 1969 году был подготовлен документ RFC-1. Замечу, что протоколы Ethernet были сформированы лишь в 1973-79 годах. Интернет в РФ на 20 лет моложе. Динамику развития этой технологии можно проследить по темпу выпуска RFC (смотри рис. 1). В 2000 году ожидается не менее 250 публикаций.

Рис. 1. Число выпущенных документов RFC по годам.

К 1979 году полностью сформировался пакет протоколов TCP/IP и их приложений, началось внедрение. К 1989 году выявились некоторые недостатки старых протоколов, возникла необходимость разработки новых. Рост числа публикаций в период 1989-99 в основном определяется разработками в области безопасности (TLS (RFC-2246, -2817), RADIUS (RFC-2058), а также RFC-2817, -2845, -2875 и многие др.), мультимедиа (MIME; RFC-1590, -2045, -2046, -2047, -2048, -2049) и специальных приложений (например, протокол IOTP). Рост числа узлов Интернет за этот же интервал времени (рис. 2) и количества WEB-серверов (рис. 3) также впечатляет.

Рис. 2. Рост числа узлов Интернет в 1989-99 годах

Рис. 3. Рост числа WEB-серверов в период 1994-2000 годы

К числу новейших достижений Интернет следует отнести электронную торговлю (протоколы IOTP, SET, CyberCash и др.), IP-телефонию, мощные поисковые системы, электронную прессу и многое другое. IP-телефония уже сегодня существенно понизила тарифы на международные переговоры. Схема реализации IP-телефонной сети показана на рис. 4.

Рис. 4. Схема IP-телефонной сети

На рисунке MVW-модуль (Multiflex Voice/WAN), включаемый в маршрутизатор, например, CISCO-3662, служит для связи с общедоступной телефонной сетью. Если сеть "А" размещена в Рио-де-Жанейро, а "В" в Москве, то любой клиент нижней сети сможет разговаривать с клиентом в Рио "бесплатно", а с клиентами телефонных сетей "А" и "B" по локальным тарифам. В левой части рисунка показаны телефонные аппараты, которые подключаются непосредственно к сегменту локальной сети. Такие приборы уже поступили в продажу.

Грядет интеграция цифрового телевидения, телефонии (включая видео-телефонию) и Интернет, звуковые и видео письма уже реальность. Схема построения интерактивной сети цифрового кабельного телевидения показана на рис. 5.

Рис. 5. Схема реализации интерактивного цифрового телевидения

Данная схема, реализованная в США и Канаде несколько лет назад, позволяет клиентам индивидуально заказывать программу телевидения на неделю вперед. Помимо этого в режиме меню можно получить данные о погоде, состоянии дорог, заказать билеты в театр или на самолет, а также вызвать на экран нужную статью какой-то газеты. Заказанные фильмы копятся в сервере буферизации и в требуемое время транслируются для клиента-заказчика. Существующая инфраструктура кабельного телевидения в США вполне пригодна для решения таких задач. В реальном масштабе времени здесь передаются только новости и спортивные соревнования.

Помимо ставшей уже привычной электронной почты Интернет дал нам WEB-технологию, глобальные поисковые системы, электронные журналы, оперативный доступ к прессе, электронную торговлю и многое другое. Молодые люди объясняются в любви по электронной почте, в реальном масштабе времени общаются с людьми на других континентах, играют в шахматы с партнерами из других стран. Все шире внедряются IP- и ISDN видео конференции.

Перспективы

1. IP-телефония. IP-телефония уже сегодня теснит традиционную не только потому, что может предложить новые разновидности услуг, но и за счет снижения тарифов. В настоящее время внедряются протоколы RTP, RTCP и RSVP, которые вместе с расширением полосы пропускания магистральных каналов уберут последние барьеры на пути внедрения этой технологии. Можно вполне ожидать дальнейшего снижения требований, налагаемых на полосы пропускания, для реализации одного разговора. Там, где достаточно донести до партнера текст сообщения (например, пейджерная связь), можно реализовать распознавание и преобразование сообщения в ASCII-последовательность, что снизит требования к полосе пропускания в сотни раз. Еще большего эффекта можно достичь, используя схему, показанную на рис. 6 (технологии для этого по большей части уже существуют, но схема пока не реализована).

Рис. 6. Схема возможного снижения требуемой полосы пропускания при передаче голоса

Символьное отображение голоса приводит к потере индивидуальных особенностей говорящего и эмоциональной окраски его речи. Системы распознавания людей по голосу уже существуют. Индивидуальные особенности голоса вещь достаточно стабильная. Если произвести анализ голоса конкретного человека и параметризовать эти особенности, то их можно будет использовать в дальнейшем в течение длительного времени. Если набор этих параметров записать на телефонную магнитную карту, то этой картой не сможет воспользоваться никто другой. Передача этих данных принимающей стороне может производиться в процессе установления телефонного соединения. В принципе можно параметризовать и эмоциональную окраску речи говорящего, но в этом случае это нужно делать в реальном масштабе времени. Реализация предлагаемой схемы будет приводить к дополнительным задержкам, но при использовании быстродействующих процессоров эти задержки можно минимизировать. Снижение требуемой полосы пропускания вместе с повсеместным внедрением протоколов RTP и RSVP сделает беседу через Интернет общедоступной.

2. Электронные книги и сфера развлечений. Если индивидуальные особенности голоса и эмоциональная окраска факторизованы, появляется возможность сделать плейеры, которые будут воспроизводить текст голосом определенного актера. Это потребует разработки специального языка разметки текста (вроде HTML) с учетом требуемой эмоциональной окраски. В этом случае на одном CD можно записать целую библиотеку.

Мало того, что появляется возможность заказывать программу телепередач на неделю вперед, получать различную справочную информацию, в принципе могут стать доступными многосюжетные фильмы, где сценарий адаптируется под вкус и желание зрителя (такие фильмы уже снимаются). Зритель может вмешиваться по ходу фильма и направлять линию сценария по одному из нескольких возможных путей.

Сети Интернет открывают новые возможности для интерактивных сетевых развлечений. Ограничения здесь иногда возникают лишь из-за полосы пропускания каналов. Развитие технологии виртуальной реальности будет еще более разнообразить возможности сетевых развлечений.

  • Сети в жилых помещениях. Внедрение бытовой техники со встроенными процессорами создает предпосылку для создания сетей в обычных жилых домах. Появились дешевые сетевые интерфейсы, например типа CAN (Controller Area Network). Помимо удовлетворения мечты о своевременном автоматическом приготовлении утреннего кофе, такая сеть может взять на себя функции обеспечения безопасности, выдавая при пожаре сигнал тревоги в ближайшую пожарную часть, а в случае попытки несанкционированного вторжения, во вневедомственную охрану. Такая система может взять на себя функции экономии энергии, воды и других ресурсов, а также контроля экологической ситуации, предлагая хозяевам закрыть окна, если в воздухе на улице появились вредные примеси в опасных количествах.
  • Интернет. Внедрение адресации IPv6 упростит и удешевит маршрутизаторы. Управление и конфигурирование серверов и маршрутизаторов будет осуществляться через базы данных, где описана маршрутная политика и политика безопасности данной автономной системы (см., например, описание языка RPSL; RFC-2280). На очереди разработка стандартных маршрутных протоколов для мобильных объектов (см. RFC-2486). Крайне актуальна раз работка внешних протоколов маршрутизации, базирующихся на "состоянии канала", а не на "векторах расстояния" (как сегодня в BGP).
  • Интерактивное телевидение. Интеграция Интернет и цифрового телевидения позволит сильно повлиять на газетный бизнес. Уже сейчас многие люди читают газеты через Интернет. Но не каждая домохозяйка умеет и хочет иметь дело с ЭВМ. Когда же появится возможность вывода статей газет на экран телевизора, а при наличии дешевого принтера и распечатки их, ситуация резко изменится. В принципе не нужно будет подписываться на какую-то конкретную газету. Можно подписаться на определенный объем данных и по аннотациям вызывать на экран только то, что заинтересовало. Эта технология сэкономит леса (ведь ни один читатель не захочет печатать всю газету), сбережет горючее, расходуемое при доставке газет на дом.
  • Электронная торговля. Эта сфера бизнеса начала развиваться и в РФ. Здесь этому препятствует отсутствие широко используемых электронных платежных средств. В этом году IETF опубликовал открытый торговый протокол для Интернет IOTP (RFC-2801). Этот протокол определяет взаимодействие для всех участников торговых сделок (покупателя, продавца, банкира, агента доставки и агента обслуживания). Этот протокол совместим со всеми известными платежными средствами и протоколами, включая протокол SET, гарантирующий неразглашение номера кредитной карточки и наивысший уровень безопасности транзакции.
  • Интернет в медицине и образовании. Консультации пациентов через Интернет нельзя переоценить, ведь трудно рассчитывать на высококвалифицированную помощь в удаленных районах РФ. Интернет позволяет в принципе передать эксперту рентгенограмму, кардиограмму или томограмму, не говоря о результатах различных анализов.
  • Дистанционное обучение может решить проблему учебников и откроет новые возможности в дополнительном образовании, которое крайне важно при массовом перепрофилировании производств. В сочетании с технологией MBONE и IP-видеоконференциями это позволит сделать уроки высококлассных преподавателей доступными в общероссийском масштабе. Хорошие же учителя также редки, как и хорошие врачи. В отличие от телевизионных учебных программ здесь возможно задавание вопросов и получение на них ответов в процессе занятия.

  • Безопасность. Решение проблем сетевой безопасности (при тотальном внедрении сетей) это уже сегодня актуальнейшая задача. В эту сферу попадает обеспечение устойчивой работы сети, сохранность информации, противодействие сетевым вирусам и хакерам, гарантия конфиденциальности при передаче данных. Здесь нельзя не упомянуть об отсутствии правовой базы для применения современных методов криптографии, в частности электронной подписи.
  • Целевая реклама. Нравится это или нет, но реклама решительно вошла в нашу жизнь. Телевизионная реклама назойлива, временами безвкусна и до крайности не эффективна, прежде всего, потому, что не является целевой. Интернет предлагает виды рекламы, которые не только не раздражают, но и помогают решать наши проблемы. Автор уже давно осуществляет закупку компьютерных компонентов, используя исключительно рекламные и справочные WEB-серверы. Появились и подписные виды рекламы, где информация рассылается подписчикам по электронной почте. Здесь важно, чтобы клиент мог в любой момент воспользоваться командой unsubscribe J .
  • Интернет - новое средство массовой информации. Здесь предстоит решить не только технические, финансовые, правовые, но и политические проблемы.

    Развитие Интернет впервые предоставляет возможность общения любого гражданина земли с любым, даже с тем, о существовании которого он и не подозревал (многие с этим познакомились через SPAM J). Это качественно меняет современную цивилизацию, создавая невиданные возможности и неведанные до сих пор угрозы.

    Темпы технического прогресса зависят от скорости накопления информации об окружающем нас мире и о нас самих. Одним из параметров, определяющих этот процесс, является задержка с момента получения информации (в результате измерения, исследования или обработки уже известных данных) и до получения ее заинтересованными лицами. Последние сто лет эта задержка оставалась почти постоянной. В науке время публикации статьи в журнале занимало до полугода (книги до года). В сфере общественной жизни (газеты) задержка составляла около суток. За последние годы сначала радио и телевидение сократило эту задержку в общественной сфере до часа-двух. Интернет сократил задержку с момента появления научных данных до их опубликования до нескольких часов (в реферируемых журналах до месяца), то есть более чем в 5 раз за десять лет. Это неизбежно скажется на темпах технического прогресса в сторону его существенного ускорения, причем в самое ближайшее время.

    Нерешенные пока проблемы:

    1. Сетевая безопасность. Существующее программное обеспечение пока не может предоставить требуемого уровня конфиденциальности при передаче информации в бизнесе и частной жизни. Постоянная тенденция унификации программных средств, операционных средств и протоколов (тенденция в принципе положительная) таит в себе угрозу создания благоприятных условий для создания компьютерных вирусов с глобальной зоной действия. Требуются более надежные и эффективные программы мониторинга и детектирования вторжения хакеров и сетевых вирусов, нужны также средства для борьбы с нежелательной рекламой (SPAM). В РФ не обеспечены юридические аспекты шифрования (для электронной подписи и сертификатов). Смотри RFC-1704, -2485 и др.
    2. Поиск нужной информации. Если 6-8 лет назад люди обменивались адресами узлов, где имеется какая-то полезная информация, то сегодня проблема в выборе узла, где следует искать нужные данные. Все, кто пользуется поисковыми серверами типа Alta-Vista или Rambler, знают, что почти на любой запрос приходят десятки и сотни ссылок на один и тот же документ, лежащий в разных депозитариях. Решение проблемы может быть достигнуто путем автоматического присвоения индивидуальных кодов всем документам в сети (ID-атрибут объекта META в языке HTML). Задача релевантности документа запросу также ждет своего эффективного решения. Внедряются кластерные системы поиска, тезаурусы и многие другие ухищрения, но проблема из-за лавинного роста суммарного объема данных также далека от решения, как и десять лет назад.
    3. Пропускная способность каналов особенно с учетом мультимедийных требований (например, ТВ высокого разрешения). В новом тысячелетии человечество выроет из земли миллионы тонн медного кабеля и закопает туда соответствующее количество оптических волноводов.
    4. Сетевая диагностика. Это не только выявление нежелательных вторжений, но и детектирование всплесков широковещательных сообщений, а также дубликатов IP-адресов и их местоположения. Нужны средства для выявления узких мест в сети, до того как они станут реальной проблемой. Смотри, например, RMON (RFC-2613, -2074, -2021, 1757, -1513)
    5. Решение проблемы мультимедийной передачи без потерь по IP-каналам. Этому может способствовать повсеместное внедрение протоколов RTP и RSVP. Необходимо дальнейшее совершенствование алгоритмов выявления и управления перегрузками в IP-каналах.
    6. Оптимальная маршрутизация. На очереди создание внешних протоколов маршрутизации, учитывающих состояние каналов (сегодня они используют алгоритм вектора расстояния), а также разработка универсальных алгоритмов вычисления метрики, учитывающей реальную загрузку, пропускную способность, задержку и другие характеристики каналов.
    7. Создание единой сети прокси-серверов, которая будет гарантировать доставку самой свежей версии документа или программы с самого "близкого" сервера, что может в разы снизить загрузку каналов, сделать сеть более надежной и эффективной. Это предполагает дальнейшее совершенствование протокола HTTP.

    Данный список выглядит коротким потому, что проблем всегда видно меньше, чем их есть на самом деле.

    Некоторые материалы по рассмотренным в данном сообщении проблемам можно найти на сервере http://book.itep.ru . В этом году в издательстве "Горячая линия - Телеком" должна выйти моя книга "Протоколы Интернет. Энциклопедия" объемом около 1100 страниц.

    Приложение

    Предложение по совершенствованию цифровой телефонии

    Современные системы цифровой телефонии (например, ISDN) предполагают выделение 32 кбит/с на каждый разговор. Если же перевести все, что говорит человек в символьное представление, то это будет эквивалентно потоку примерно в 64 бит/c (примерно такова же предельная скорость ввода данных с клавиатуры). Разрыв в требуемых пропускных способностях соответствует 5000. Понятно, что символьное представление не содержит индивидуальных особенностей голоса и эмоциональной окраски речи. Современные системы сжатия голосовой информации позволяют сократить требования к полосе пропускания до 7,5 кбит/с, но уже с некоторым ухудшением качества воспроизведения. Наилучшие современные системы (например, VOCODER) позволяют обходиться полосой в 1 кбит/c, при весьма серьезном ухудшении качества (голос неузнаваем и напоминает речь робота). Любое сокращение требования к полосе при сохранении качества передачи голоса крайне желательно. Современная телефония - это высокодоходная отрасль, и любая фирма готова будет заплатить за такого рода разработку, так как это решит конкурентное противостояние в ее пользу. Рост пропускной способности каналов не решает проблемы, так как все телефонные компании используют эту сеть, но преуспеет та, которая сможет предложить более низкие тарифы.

    В США планируется выпуск автомобилей с бортовым компьютером, управляемым голосом водителя (руки у него заняты). Таким образом, проблема преобразования голоса в последовательность символов можно считать практически решенной.

    Еще большего эффекта можно достичь, используя схему, показанную на рис. 6 (технологии для этого уже существуют, но схема пока не реализована).

    Символьное отображение голоса приводит к потере индивидуальных особенностей говорящего и эмоциональной окраски его речи. Системы распознавания людей по голосу уже существуют (например, в системах идентификации). Индивидуальные особенности голоса вещь достаточно стабильная. Если произвести анализ голоса конкретного человека и параметризовать эти особенности, то их можно будет использовать в дальнейшем в течение длительного времени. Если набор этих параметров записать на телефонную магнитную карту, то этой картой не сможет воспользоваться никто другой. Передача этих данных принимающей стороне может производиться в процессе установления телефонного соединения. В принципе можно параметризовать и эмоциональную окраску речи говорящего, но в этом случае это нужно делать в реальном масштабе времени. Реализация предлагаемой схемы будет приводить к дополнительным задержкам, но при использовании быстродействующих процессоров, или аппаратных средств эти задержки можно минимизировать.

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

    Возможные приложения при частичном или полном успехе проекта:

    1. Организация пейджерной связи без оператора посредника
    2. Снижение телефонных тарифов (особенно для дальней телефонной связи).
    3. Обучение языку, коррекция произношения
    4. Распознавание преступников по голосу

    Грубые оценки показывают, что высокого качества передачи голоса методом параметризации можно достичь при полосе 1кбит/c.

    Previous: 10.24 Сети Петри    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
       Next: 10.26 Таблица цветов, их имен и кодов


    previous up next index index
    Previous: 10.25 Интернет вчера, сегодня и завтра    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
        Next: 10.27 Законы Мерфи для программистов

    10.26 Таблица цветов, их имен и кодов
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Надеюсь, эта таблица окажется полезной для WEB-дизайнеров. Пожалуйста, не пытайтесь печатать эти страницы, ничего хорошего не получится! Цвета отображены с использованием атрибута bgcolor. Ю.А.С.

    Образец Код Название CSS Название Образец Код Название CSS Название
              #F0F8FF aliceblue блекло-голубой           #A52A2A brown коричневый
             #FAEBD7 antiquewhite античный белый          #DEB887 burlywood старого дерева
         #00FFFF aqua синий      #5F9EA0 cadetblue блеклый серо-голубой
              #7FFF00 chartreuse фисташковый           #FF7F50 coral коралловый
              #F5F5DC azure лазурь           #D2691E chocolate шоколадный
              #F5F5DC beige бежевый           #6495ED cornflowerblue васильковый
              #FFE4C4 bisque бисквитный           #000000 black черный
              #FFF8DC cornsilk темно-зеленый           #DC143C crimson малиновый
           #FFEBCD blanchedalmond светло-кремовый        #00FFFF cyan циан
           #0000FF blue голубой        #00008B darkblue темно-голубой
           #8A2BE2 blueviolet светло-фиолетовый        #008B8B darkcyan темный циан
           #B8860B darkgoldenrot темный красно-золотой     #A9A9A darkgray темно-серый
           #006400 darkgreen темно-зеленый        #BDB76B darkkhaki темный хаки
           #8B008B darkmagenta темный фуксин        #556B2F darkolivegreen темно-оливковый
           #FF8C00 darkorange темно-оранжевый     #9932CC darkorchid темно-орхидейный
        #8B0000 darkred темно-красный     #E9967A darksalmon темно-оранжево-розовый
        #8FBC8F darkseagreen темный морской волны     #483D8B darkslateblue темный сине-серый
        #2F4F4F darkslategray темный сине-серый     #00CED1 darkturqueise темно-бирюзовый
        #9400D3 darkviolet темно-фиолетовый     #FF1493 deeppink темно-розовый
        #00BFFF deepskyblue темный небесно-голубой     #696969 dimgray тускло-серый
        #1E90FF dodgerblue тускло-васильковый     #B22222 firebrick огнеупорного кирпича
        #FFFAF0 floralwhite цветочно-белый     #228B22 forestgreen лесной зеленый
        #FF00FF fuchsia фуксии     #F8F8FF ghostwhite туманно-белый
        #DCDCDC gainsboro гейнсборо     #FFD700 gold золотой
        #DAA520 goldenrod красного золота     #808080 gray серый
        #008000 green зеленый     #ADFF2F greenyellow желто-зеленый
        #F0FFF0 honeydew свежего меда     #FF69B4 hotpink ярко-розовый
        #CD5C5C indianred ярко-красный     #4B0082 indigo индиго
        #FFFFF0 ivory слоновой кости     #F0E68C khaki хаки
        #E6E6FA lavender бледно-лиловый     #FFF0F5 lavenderblush бледный розово-лиловый
        #7CFC00 lawngreen зеленой лужайки     #FFFACD lemonchiffon лимонный
        #ADD8E6 lightblue светло-голубой     #F08080 lightcoral светло-кораловый
        #E0FFFF lightcyan светло-циановый     #FAFAD2 lightgoldenrodyellow светлый золотисто-желтый
        #90EE90 lightgreen светло-зеленый     #D3D3D3 lightgrey светло-серый
        #FFB6C1 lightpink светло-розовый     #FFA07A lightsalmon светлый оранжево-розовый
        #20B2AA lightseagreen светлый морской волны     #87CEFA lightskyblue светлый небесно-голубой
        #778899 lightslategray светлый сине-серый     #B0C4DE lightsteelblue светло-стальной
        #FFFFE0 lightyellow светло-желтый     #00FF00 lime цвета извести
        #32CD32 limegreen зеленовато-известковый     #FAF0E6 linen льняной
        #FF00FF фуксин blanchedalmond     #800000 maroon оранжево-розовый
        #66CDAA mediumaquamarine умеренно-аквамариновый     #0000CD mediumblue умеренно-голубой
        #3CB371 mediumseagreen умеренный морской волны     #7B68EE mediumslateblue умеренный серо-голубой
        #BA55D3 mediumorchid умеренно-орхидейный     #9370DB mediumpurple умеренно-пурпурный
        #00FA9A mediumspringgreen умеренный сине-серый     #48D1CC mediumturquose умеренно-бирюзовый
        #0C71585 mediumvioletred умеренный красно-фиолетовый     #191970 midnightblue полуночный синий
        #0F5FFFA mintcream мятно-кремовый     #FFE4E1 mistyrose туманно-розовый
        #FFE4B5 moccasin болотный     #FFDEAD navajowhite грязно-серый
        #000080 navy морской     #FDF5E6 oldlace старого коньяка
        #808000 olive оливковый     #6B8E23 olivedrab
        #FFA500 orange оранжевый     #FF4500 orangered оранжево-красный
        #DA70D6 orchid орхидейный     #EEE8AA palegoldenrod бледно-золотисный
        #98FB98 palegreen бледно-зеленый     #AFEEEE paleturquoise бледно-бирюзовый
        #DB7093 palevioletred бледный красно-фиолетовый     #FFEFD5 papayawhip дынный
        #FFDAB9 peachpuff персиковый     #CD853F peru коричневый
        #FFC0CB pink розовый     #DDA0DD plum сливовый
        #B0E0E6 powderblue туманно-голубой     #800080 purple пурпурный
        #FF0000 red красный     #BC8F8F rosybrown розово-коричневый
        #4169E1 royalblue королевский голубой     #8B4513 saddlebrown старой кожи
        #FA8072 salmon оранжево-розовый     #F4A460 sandybrown рыже-коричневый
        #2E8B57 seagreen морской зеленый     #FFF5EE seashell морской пены
        #A0522D sienna охра     #C0C0C0 silver серебристый
            #87CEEB skyblue небесно-голубой         #6A5ACD slateblue серо-голубой
            #708090 slategray сине-серый         #FFFAFA snow снежный
            #00FF7F springgreen весенне-зеленый         #4682B4 steelblue сине-стальной
            #D2B48C tan желто-коричневый         #008080 teal чайный
            #D8BFD8 thistle чертополоха         #FF6347 tomato томатный
            #40E0D0 turquoise бирюзовый         #EE82EE violet фиолетовый
            #F5DEB3 wheat пшеничный         #FFFFFF white белый
            #F5F5F5 whitesmoke белый дымчатый         #FFFF00 yellow желтый
            #9ACD32 yellowgreen желто-зеленый         #7FFFD4 aquamarine аквамарин

    Previous: 10.25 Интернет вчера, сегодня и завтра    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
       Next: 10.27 Законы Мерфи для программистов


    previous up next index index
    Previous: 10.26 Таблица цветов, их имен и кодов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
        Next: 11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

    10.27 Законы Мерфи для программистов
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Интернет - это система сотрудничающих программ, а программы, как известно, пишутcя программистами. Некоторые мои студенты, правда, пытаются оспаривать этот факт и считают, что стоит как следует поискать в сети, и найдешь, то что нужно. Я сам являюсь программистом и мне близки эти проблемы. Предлагаю вашему вниманию мой перевод избранных законов Мерфи для программистов. Полный "свод законов" можно найти на сайте Законы Мерфи

    1. Любая работающая программа уже устарела.
    2. Любая программа обходится дороже и требует больше времени, чем казалось в начале.
    3. Если программа полезна, ее обязательно переделывают.
    4. Если программа бесполезна, ее тщательно документируют.
    5. Любая программа в конце концов занимает всю доступную память.
    6. Ценность программы обычно определяется весом выдаваемой ею распчатки.
    7. Сложность программы обычно растет до тех пор, пока не превысит способности программиста, призванного ее поддерживать.
    8. Если утилиты, испытанные при инсталяции, работают идеально, все остальные функции будут работать не верно.
    9. Если входной редактор спроектирован так, чтобы исключить неверный ввод, найдется изобретательный идиот, который изыщет метод ввести разрушительную команду.
    10. Невежество - единственный язык, которым владеют все программисты.
    11. Увеличение численности программистов, работающих над проектом, увеличивает сроки его выполнения.
    12. Небрежно спланированный проект требует в 3 раза больше времени, чем ожидалось, а тщательно спланированный - только в 2.
    13. В программе всегда есть еще одна ошибка.
    14. Невозможно создать программу с полной защитой от дураков, ибо дураки крайне изобретательны.
    15. Если все идет хорошо, вас вскоре ждут серьезные осложнения.
    16. Если дела идут хуже некуда, вскоре выяснится, что это не так.
    17. Если кажется, что все в порядке, вы просто что-то просмотрели.
    18. Тестовые операции и результаты их выполнения должны быть воспроизводимы - они все должны давать одинаковые отказы.
    19. Вы всегда найдете еще одну ошибку, если еще раз загляните в свою программу.
    20. Терминал работает лучше, если его включить в сеть.
    21. Если все не работает, читайте документацию.
    22. Если вам не понятно какое-то слово в технической документации, игнорируйте его, смысл от этого не пострадает.
    23. Не важно, много ли вы работаете, вы все равно работаете недостаточно.
    24. То, чего вы не делаете, всегда важнее того, что вы делаете.
    25. Всегда оставляйте место для объяснения того, почему ваша программа работает не так как планировалось.
    26. Не существует ничего невозможного для человека, который не собирается ничего делать сам.
    27. Если бы строители сооружали здания также, как программисты пишут свои программы, первый же дятел разрушил бы человеческую цивилизацию.
    28. Программисты действуют рационально, лишь тогда, когда другие способы исчерпаны.

    Previous: 10.26 Таблица цветов, их имен и кодов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
       Next: 11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"


    previous up down next index index
    Previous: 9 Литература    UP: 9 Литература
    Down: 10.1 Рекомендации CCITT по телекоммуникациям
        Next: 10.1 Рекомендации CCITT по телекоммуникациям

    10 Приложения
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    10 Приложения

    1

    8

    10.1 Рекомендации CCITT по телекоммуникациям

    10

    88

    10.2 Коды протоколов в Ethernet II

    2

    11

    10.3 Стандартные мультикастинг-адреса Интернет

    2

    2

    10.4 Таблица операций и субопераций NCP

    8

    8

    10.5 Таблица операций службы каталогов Netware

    2

    9

    10.6 Таблица типов кадров управления доступом для сети Token Ring

    2

    13

    10.7 Типы субвекторов кадров управления доступом

    2

    11

    10.8 Управляющие регистры модемов и их функции

    6

    38

    10.9 Набор AT-команд модемов

    4

    25

    10.10 Наиболее употребимые сокращения, используемые в телекоммуникациях (с разбивкой по буквам)

    210

    1826

    10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций

    5

    25

    10.12 Национальные коды доменов в Интернет

    7

    7

    10.13 Список кодов и откликов на почтовые команды и сообщения

    1

    7

    10.14 Принципы формирования кода отклика в системе SMTP

    1

    5

    10.15 Базовые протоколы Internet

    2

    15

    10.16 Разъем AUI

    1

    5

    10.17 Разводка разъемов

    3

    93

    10.18 Краткий справочник по командам UNIX

    27

    80

    10.19 Символьный набор HTML

    8

    131

    10.20 Справочные данные по математике

    10

    122

    10.21 Элементы теории графов

    6

    69

    10.22 Имена временных зон

    1

    3

    10.23 Модель машины конечных состояний

    1

    3

    10.24 Сети Петри

    2

    33

    10.25 Интернет вчера, сегодня и завтра

    8

    250

    10.26 Таблица цветов, их имен и кодов

    3

    38

    10.27 Законы Мерфи для программистов

    1

    1

    11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

    13

    40

    Previous: 9 Литература    UP: 9 Литература
    Down: 10.1 Рекомендации CCITT по телекоммуникациям    Next: 10.1 Рекомендации CCITT по телекоммуникациям


    previous up down next index index
    Previous: 10.6 Таблица типов кадров управления доступом для сети Token Ring    UP: 10.1 Рекомендации CCITT по телекоммуникациям
    Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
        Next: 10.8 Управляющие регистры модемов и их функции

    10.7 Типы субвекторов кадров управления доступом
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Тип

    Наименование

    Значение

    0x01

    Аварийный сигнал

    0001 - установлен режим восстановления
    0002 - в кольце потерян сигнал
    0003 - борьба за монитор завершилась неудачей, нет кадров запроса маркера

    0x02

    Ближайший активный предшественник

    Адрес станции - активного предшественника (нуль, если предшественник не выявлен)

    0x03

    Номер локального кольца

    Номер локального кольца передающего адаптера

    0x04

    Задание номера физического отвода

    Задает номер физического отвода для адаптера

    0x05

    Значение таймера для сообщения о неустойчивой ошибке

    Время в мсек для таймера неустойчивой ошибки адаптера

    0x06

    Классы допустимых функций

    Классы отправителей, которым разрешена передача

    0x07

    Приоритет разрешенного доступа

    Максимальный приоритет маркера, при котором адаптеру разрешена передача (0-3)

    0x08

    Разрешенная среда

    0 - несанкционированный режим сети
    1 - санкционированный режим

    0x09

    Коррелятор

    Используется для связи кадров друг с другом

    0x0A

    Последний адрес при опросе кольца

    Адрес станции, передавшей последний кадр наличия активного или резервного монитора перед нарушением режима опроса кольца

    0x0B

    Номер физического отвода

    Номер физического отвода адаптера (назначается администратором)

    0x20

    Код отклика

    Код, используемый в кадре управления доступом:
    0x001 - положительный отклик
    0x8003 - команда не поддерживается
    0x7007 - потерян необходимый субвектор
    0x800A - операция заблокирована

    0x21

    Модификатор адреса

    Посланный модификатор адреса адаптера не поддерживается

    0x22

    Идентификатор устройства

    Идентифицирует параметры адаптера (код модели, имя фирмы производителя и пр.)

    0x23

    Характеристика программного обеспечения

    Версия драйвера адаптера

    0x26

    Перенос данных

    Заполнитель данных в кадрах управления доступом при проверке сетевой среды

    0x27

    Передача кадра

    Кадр Token Ring, который быть должен передан адаптером получателю. Используется сервером конфигурации для тестирования маршрутов

    0x29

    Вектор состояния адаптера

    Например: адаптер открыт
    подзадача не готова;
    ожидание подтверждения

    0x2A

    Передача кода состояния

    Код, означающий "изъятия переданного кадра"

    0x2B

    Групповой адрес

    Установлен групповой адрес передающей станцией (равен нулю, если нет)

    0x2C

    Функциональный адрес

    Функциональный адрес отправителя

    0x2D

    Локализуемые ошибки

    Счетчики локализуемых ошибок:
    байт 0 - ошибки потери кадра
    байт 1 - внутренние ошибки
    байт 2 - ошибки пакета
    байт 3 - ошибки флагов ARI/FCI
    байт 4 - "передан ограничитель аварийного завершения"

    0x2E

    Нелокализуемые ошибки

    Счетчики нелокализуемых ошибок:
    байт 0 - ошибки потери кадра
    байт 1 - ошибки перегрузки при приеме
    байт 2 - ошибки копирования кадра
    байт 3 - частотные ошибки
    байт 4 - ошибки маркера

    0x30

    Код ошибки

    Код, определяющий условия ошибки:
    0x0001 - ошибка монитора
    0x0002 - дублирование монитора
    0x0003 - дублирование адреса

    Previous: 10.6 Таблица типов кадров управления доступом для сети Token Ring    UP: 10.1 Рекомендации CCITT по телекоммуникациям
    Down: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций    Next: 10.8 Управляющие регистры модемов и их функции


    previous up index index
    Previous: 10.27 Законы Мерфи для программистов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций

    11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"
    Семенов Ю.А. (ГНЦ ИТЭФ)

    (http://book.itep.ru)

    Этот сервер официально зарегистрирован на Rambler лишь в марте 2002 года, но существует он уже с конца 1999 года. Отклики интересны, прежде всего, тем, что они написаны по инициативе отправителя. Я полагаю, что многие из читателей время от времени просматривают самые разные сайты в Интернет. Но вряд ли многие пишут на них отклики...
    Я сознательно исключил переписку, возникавшую в связи с присланными запросами. Не все отклики попали в перечень (я получаю большой объем СПАМа и часто слишком поспешно уничтожаю сообщения от незнакомых лиц). Признаюсь, я не всегда отвечаю на приходящие письма, так как их число превышает 50 в день. География откликов довольно широка (Владивосток, Новосибирск, Иркутск, С-Петербург, Ижевск, Саратов, Ноябрьск, Луганск, Тихорецк, Ставрополь, Киев, Эстония, США, Болгария и, конечно же, Москва). В основном они положительны (может быть отчасти потому, что авторы о чем-то просят J ). Но был один явно отрицательный отклик, он также включен в перечень. Было несколько запросов относительно off-line версии сервера. Отвечая на них, скажу, что я планирую изготовить CD-версию сервера, но дело это хлопотное и экономически совершенно нерациональное. Обычно в такой версии нуждаются люди с плохим доступом к Интернет (как правило не москвичи), себестоимость такого CD около 2$, плюс цена пересылки, назначить цену, которая бы компенсировала трудозатраты я не могу, да и люди не смогут ее заплатить, а рассылать диски с убытком не позволяет моя зарплата.
    Отклики размещены в хронологическом порядке, со временем надеюсь создать "нормальную" книгу посещений-отзывов.

    From : Andrey Cherezov andrey@cherezov.koenig.su
    To: semenov@ns.itep.ru
    Subject: О ваших Книгах
    Date: 2 августа 1998 г. 22:15
    Добрый день!
    Неужели Вы тот самый Ю.А.Семенов, который книгу о Форте написал?!
    J
    Очень рад, что теперь можно с вами поговорить!
    Всего наилучшего, Андрей Черезов http://www.enet.ru/win/cherezov/

    Date : Sat, 27 Mar 1999 20:38:37
    Уважаемый господин Cеменов!
    Oглавление, перечисляющее разделы вашего сайта "Cети Интернет", просто потрясающее. Но по каким-то причинам Я не могу открыть большинство страниц. Если они (страницы :-) уже созданы, то хотелось бы, чтоб проблемы, связанные с этим (причинами :-( , поскорее были преодолены.
    C уважением,
    Bаш потенциальный постоянный посетитель
    Aлександр <lommoff@yahoo.com>

    Date : Mon, 6 Mar 2000 03:56:49
    Восхищен и поражен Вашим сайтом Telecommunication technologies - телекоммуникационные технологии. Творческих успехов и всего хорошего.
    Egor Kobylkin egork@iname.com http://i.am/egork

    Date : Thu, 1 Jun 2000 13:47:11
    Уважаемый Юрий Алексеевич!
    С удовольствием прочитал в Интернет Вашу книгу "Сети Интернет..." Благодарю за бесплатное размещение этой очень полезной книги в сети. Пользуясь случаем, прошу оказать помощь в приобретении полного текста. Рекомендаций МСЭ-Т G.703 (Копия, оригинал или адрес в сети). Посоветуйте где это можно найти.
    С уважением
    Ведущий специалист ЗАО"АКОС" (Сотовая связь. г. Владивосток)
    Сергей Гречуха
    мой адрес: sgrechuha@akos.ru

    Date : Wed, 14 Jun 2000 16:25:45
    Добрый день, Юрий Алексеевич.
    Я студент МФТИ ФРТК 4-й курс, пишу вам по поводу вашей книги Телекоммуникационные Технологии (http://book.itep.ru). В данный момент занимаюсь моделированием локальных сетей на языке GPSS/PC. В частности, моделирую Ethernet 802.3 коллизийный домен. Я нашел некоторые неоднозначности в разной литературе описывающие протокол CSMA/CD.
    И хотел бы у вас утонить правильность моих рассуждений, так как при моделировании данной сети, у меня получается, что одна станция (по крайней мере из 3-х станций в сети) захватывает весь эфир и не дает возможность передавать другим. Как работает CSMA/CD, я понимаю так:
    1. Станция все время прослушивает среду (шину). Если среда свободна (освободилась), то ждет interframe gap
    (межкадровый интервал), равный 9,6 мкс (в это время все равно слушает среду). Если в течение этих 9,6 мкс никто не захватил шину, то начинает передавать (шаг 2.). Если кто-то захватил шину в течение этого времени, то возвращается к шагу 1.
    2. При передачи, станция все время слушает среду. Если обнаруживает коллизию, то посылает сигнал коллизии 32 BT = 3.2 мкс. И вычисляет задержку по формуле (51,2*(RAND [0,(2^m-1)]), где m = min (к,10), а к - число коллизий, при передачи данного кадра.
    То есть, если к=1, то возможная задержка (0, 51.2) если к=2, то возможная задержка (0, 51.2, 102.4, 52428.8), и т.д. После ожидания вычисленной задержки, возвращается к шагу 1. Если к=16, станция отказывается отправлять кадры. (Кстати, у Вас задержка вычисляется по формуле (51,2*(RAND [0,(2^m)]))
    3.Если коллизии не было, то завершает передачу. Устанавливает к = 0. Возвращается к шагу 1. Я моделирую насыщенный режим работы сегмента и почему-то одна станция захватывает весь эфир. Модель работает к предписано алгоритмом выше. Попробовал аналитически рассмотреть работу >CSMA/CD. Допустим все станции (3 штуки) захотели передавать в одно и тоже время, определив, что шина свободна. Обнаружится коллизия, все станции идут в задержку. прибавляя к 'К' единицу. Далее, кто первее освободился (если задержка 0, то сразу идет к шагу 1), тот начал передачу. Во время передачи этой станции освобождаются, другие станции из коллизийной задержки. Соответственно ждут, пока освободит шину передающая станция (шаг 1). Как только эта станция освобождает шину, она идет в шаг 1. (причем 'к' сбрасывает в нуль) на ровне с другими станциями. Ждут 96 ВТ = 9.6 мкс межкадрового времени, начинают передавать. Опять образуется коллизия. У первой станции 'к' будет равно единицы, а у других 'к'=2. Это говорит о том, что вероятность получить меньшую задержки у первой станции больше чем у других. (у меня так и происходит). станция с к=1 выбирает меньшую задержку, чем другие. Ждет и идет передавать. Далее все идет по циклу, у первой станции 'к' то обнуляется, то равно 1, у других станций 'к' растет, соответственно, вероятность получить большую задержку тоже растет. Я моделировал передачу кадров минимальной длины, что уж говорить о кадров максим. длины 1526КВ. Ситуация на мой взгляд еще больше усугубится. Юрий Алексеевич, подскажите, может быть я не правильно понял алгоритм? Он несколько отличается от Вашего (http://book.itep.ru/4/41/Eth_4111.htm), но мне кажется не принципиально.
    Всего доброго, Рябенко Максим maxy@rt.mipt.ru

    Date : Wed, 12 Jul 2000 16:45:27
    Уважаемый Юрий Алексеевич
    В своей книге "Сети Интернет. Архитектура и протоколы", Вы пишите о том, что Вы написали собственную программу для анализа сетевого трафика, и в частности эта программа анализирует содержимое MIB. Меня интересует такой вопрос: как в Вашей программе реализован поиск SNMP-агентов, и можно ли организовать его автоматически?
    С уважением, Юрий Чашков. chashkov@mail.ru

    Date : Fri, 4 Aug 2000 15:32:33
    Здравствуйте.
    В Вашей книге (http://book.itep.ru/7/Prog_72.htm)
    читаю:
    "...(см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi)..." Не могли бы Вы уточнить, действительно ли существует описание 8390 в Интернете и как его выловить? (очень надо для отладки драйвера под RTEMS)
    Спасибо.
    Sincerely, Dmitry Kargapolov, ICQ 54000305, dk@gentex.ru

    Date : Tue, 15 Aug 2000 05:16:31
    Доброго времени суток Юрий Алексеевич.
    Попал на Ваш сайт, и был приятно удивлен количеству полезной информации. Но к сожалению, я не имею постоянной возможности работы в Интернете. И меня интересует, такая возможность, как получить Ваш сайт в виде архива. Для ЛИЧНОГО использования. По некоторым статьям я считаю, что мог бы несколько дополнить их. Но, к сожалению, по причине описанной выше не могу внимательно ознакомится с теми разделами, в которых у меня имеется богатый практический опыт. Рад буду, если Вы откликнитесь на мою просьбу. А также надеюсь на плодотворное сотрудничество.
    Заранее спасибо.
    С уважением Алексей Алексеевич. mailto:wwfnet@mail.ru

    Date : Thu, 31 Aug 2000 12:49:28
    Уважаемый Юрий Алексеевич!
    Сердечно благодарю Вас за отклик на нашу просьбу. Надеюсь, что Вы сможете, что-нибудь придумать. Информацию о сфере нашей деятельности, заказчиках и др. Вы сможете посмотреть на нашем сайте. Очень горжусь, пусть телефонным, знакомством с Вами и надеюсь, что смогу быть Вам полезным. С Уважением и наилучшими пожеланиями, исполнительный директор НПФ Беркут
    Кельганкин Олег
    ook@bercut.spb.ru
    www.bercut.ru
    т/ф (812) 271-48-98
    т/ф (812) 274-70-59
    т/ф (812) 275-44-91
    Россия, Санкт-Петербург, Моисеенко 43.

    Date : Thu, 31 Aug 2000 13:48:14
    Здравствуйте Юpий Алексеевич!
    Ну для начала я представлюсь. Корнилов Игорь Геннадьевич, 25 лет. Работаю ставшим преподавателем на кафедре ВТ ИжГТУ (Ижевский гос. тех. университет). С прошлого года я читаю курсы по корпоративным сетям и Интернету. В подготовке к лекциям в прошлом году мне сильно помогала Ваша книга "Протоколы и ресурсы INTERNET". Позже я стал пользоваться сервером book.itep.ru. Замечательный, полезный сервер! Спасибо Вам огромное>! Но у нас есть одна проблема! Канал через который подключен к инету наш университет не отличается высокой скоростью и надежностью. :( А я бы хотел, чтоб ресурсами вашего сервера могли свободно пользоваться наши студенты. И в связи с этим вопрос: можно ли разместить зеркало вашего сервера на сервере нашей кафедры?
    С уважением, Корнилов Игорь. eggog@vao.udmnet.ru

    Date : Mon, 04 Sep 2000 10:59:47
    Добpый день, Юpий Алексеевич
    Зеркало уже почти готово! Скоро я его размещу на нашем сервере zuko.istu.udm.ru
    . У меня уже есть старая копия, которой я пользовался. Hо из миpа в настоящее время его видно не будет (проблемы с внешними каналами :((( Как только появится возможность доступа к нам из вне я Вам сообщу дополнительно. И вот тут еще. Меня заинтересовало ваше сообщении о новой книге, хотелось бы уточнить, когда она выходит и как ее можно будет заказать (а то тут у нас сложно с ХОРОШЕЙ литературой в магазинах :))) )? eggog@vao.udmnet.ru
    С уважением? Игорь Корнилов.

    Date : Mon, 4 Sep 2000 18:34:03
    Здравствуйте, Юрий Алексеевич!
    Случайно обнаружил Ваш сайт в бескрайнем мире Интернет и был приятно удивлен. Не каждый день встречаешь столько полезной информации в одном месте. Поскольку на сайте размещены обложки книг, то у меня возникло вполне определенное желание иметь эти книги в своей библиотеке. Если Вас не затруднит, подскажите, где их можно приобрести. При просмотре Вашего сайта у опытных пользователей возникает необходимость получения информации по какому-либо ключевому слову. Не могли Вы при дальнейшей работе учесть это и организовать самую простую поисковую машину. И еще вопрос. Не встречали ли Вы где-либо подробную информацию о коде hdb3? Если Вас не затруднит, дайте, пожалуйста, ссылочку на источник.
    Спасибо Вам за то, что Вы делаете!
    С уважением, Артем Глазунов, специалист Иркутского областного телеграфа.
    e-mail: gav@irtel.ru

    From : "Lex" <3694_KAN@nw.ie.tasur.edu.ru>
    Organization: Industrial Electronics of TASCR
    To: <semenov@itep.ru>
    Date: Mon, 2 Oct 2000 19:40:23
    В вашей книге "Протоколы Интернет" описан обработчик приема пакетов для пакетных драйверов receiver - он описан как процедура near а как сделать чтобы этот обработчик обращался к данным прикладной программы, например вставка в receiver строк типа
    mov> ah,09h
    lea dx,string
    int 21h
    Где string описана в данных прикладной программы приводит к выводу всякой ваты на экран и зависанию компа при обращении драйвера к receiverу причем $ на конце stringa не забыл указать и относительно другого сегмента пробовал (com программа) cs:[string] все равно Вы моя последняя надежда...

    Date : Wed, 01 Nov 2000 11:53:59
    Subject: Огромное СПАСИБО за то, что Вы есть!
    У меня к Вам убедительная просьба отправить мне ответы на закрепляющие вопросы к теме "Каналы передачи данных" (http://book.itep.ru/) Я хотел бы проверить свои знания в этой области.
    С уважением, Колот Сергей <kolot@mail.ru>

    Date : Mon, 18 Dec 2000 00:49:29
    Глубокоуважаемый Юрий Алексеевич!
    Я хотел бы попросить Вас исправить русскоязычное написание имени и фамилии Michael Burrows'a -- одного из авторов WBT ("Burrows-Wheeler Transformation", also known as " Block Sorting"); его зовут Майкл Барроуз. Так получилось, что я работал в Великобритании и знаком с ним.
    Спасибо, Андрей Кадач akadatch@microsoft.com

    Здравствуйте,
    Позвольте поблагодарить Вас, за тот труд, который Вы вложили в создание http://book.itep.ru/, он помог мне заполнить те пробелы в моих знаниях, которые долгое время не давали мне покоя. Спасибо.
    Вы пишите:
    > Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные
    > описания протоколов (конспективность здесь неизбежна) и представить необходимые
    > справочные материалы...
    Не могли бы Вы подсказать, где можно найти более полную информацию, касающуюся вопросов моделирования и оптимизации сетей. Заранее благодарен.
    Kirill V. Krinkin
    mailto:krinkin@mailru.com
    Brainbench Public Transcript: 173921,
    http://www.brainbench.com/transcript.jsp?pid=173921
    7 января 2001 г.

    Date : Mon, 05 Feb 2001 16:44:31
    Здравствуйте. Пишет вам Константин из города Луганска. Я ищу описание дельта кодака. К сожалению я не знаю его точного названия, но знаю что в данном протоколе используется метод адаптивной дельта модуляции, частота передачи 32 Кбит/сек, и на одну линию подсоединяется 8 цифровых т/а. Если описание подобного протокола в вашей книге?
    e_mail: kos_k@inbox.ru

    Thu, 15 Feb 2001 22:31:43
    From: "I. F." <code@dir.bg>
    To: <semenov@itep.ru>
    Date: Thu, 15 Feb 2001 21:33:47
    bravo bravo good book:
    about <http://book.itep.ru/1/intro1.htm>

    Date : Thu, 22 Feb 2001 17:40:26
    Здравствуйте!
    Я хотел бы узнать, где можно найти вашу книгу "Telecommunication technologies - телекоммуникационные технологии" в электронном виде.
    Алексей В. Майоров МФТИ ФПМЭ. lexa@megasoft.ru

    Date : Mon, 12 Mar 2001 18:25:34
    Уважаемый Юрий Алексеевич, меня очень понравился сайт ( <http://book.itep.ru/> )с вашими книгами. Я осваиваю программирование под Windows, с уклоном в сетевые технологии, и столкнулся с тем, что в Инете очень мало информации по этой теме, на русском языке, поэтому приходилось искать на буржуйских сайтах, но в силу слабости моих познаний английского, меня этот путь не совсем устраивает, и сегодня блуждая по поисковикам наткнулся на вашу главу , посвященную Сокетам, мне она очень понравилась, благодаря своему подробному описанию данного вопроса. Затем посмотрел на оглавление, мне понравилось еще больше, показал друзьям - программистам - они тоже оценили. По моему мнению, это лучшая книга по обработке информации, и сетевым технологиям (по крайней мере среди русскоязычных). Выражаю Вам огромную признательность от своего имени за проделанную колоссальную работу в области развития информационных технологий среди начинающих программистов(и профессиональных также):).
    В заключение, хотелось бы узнать, изданы ли они в печатном виде и, если да, то где их можно приобрести
    С уважением, Вячеслав Потапов, студент МИСиС. VPotapov@estra.ru

    Date : Wed, 28 Mar 2001 14:52:42 +0400
    From: "maks" <imv@ghost.dn.ua>
    Пишет вам студентка Украинской Государственной Академии связи, мой преподаватель выдал мне диплом на тему "видеотелеконференции - как услуга центра документальной электросвязи ", сославшись на то что поискать информацию по этой теме можно в ваших книгах. Причем, какие конкретно книги он мне не сказал. Если вас не затруднит, напишите пожалуйста по этому адресу, какие книги на интересующую меня тему вы написали. Или, если можно и есть публикации в Интернете скиньте пару ссылок на них.
    заранее благодарна!
    Best regards,
    Марина mailto:imv@ghost.dn.ua

    From: "Digitman" <digitman@dax.ru>
    To: <semenov@itep.ru>
    Date: Tue, 3 Apr 2001 13:01:37
    Добрый день , ув . Ю.А.!
    С интересом проштудировал раздел "Сокеты" http://book.itep.ru
    В наст. момент я занимаюсь разработкой пакета Делфи-компонентов, реализующих логику клиент-серверного взаимодействия не базе гнезд. Общая идея, подвигнувшая меня на разработку, заключалась в усовершенствовании базовых решений данных технологий, представленных в виде устойчивых классов TServerSocket и TSocketConnection, c учетом преимуществ технологий MIDAS и ASTA. Не могу утверждать об идеальном понимании мной в данный момент концепции гнезд TCP/IP, но стремление к совершенству результата требует того.
    В связи с этим я столкнулся с малопонятой и малодокументированной проблемой, возникающей при использовании сокет-сервером логики установления коннекта с сокет-клиентом с использованием расширенной ф-ции WSAAccept() вместо стандартно применяемой в компонентах VCL Accept():
    Я использую гнезда в режиме SOCK_STREAM. По специф-ции MS Winsock2 ф-ция> WSAAccept() должна позволять принимать/отвергать/откладывать вх запросы клиентских гнезд на установление коннекта. С этой целью в Проблемная ситуация состоит в следующем:
    1. Если ConditionFunc() возвращает CF_REJECT (отвергнуть вх.запрос на соединение), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО клиентский вызов connect(), запросивший соединение, завершается УСПЕШНО, сигнализируя об установлении соединения, ХОТЯ сервер ОТВЕРГ его!
    2. Если ConditionFunc() возвращает CF_DEFER (отложить рассмотрение вх.запроса на соединение, не уничтожая его в очереди BackLog), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО ТОЛЬКО при первом ее вызове. Повторные вызовы WSAAccept() (как правило, этот вызов - блокирующий и вложен в цикл в отдельном потоке) предполагают повторные проверки условий ф-цией ConditionFunc() для очеред.элемента из BackLog-очереди, которым может оказаться и только что отложенный запрос (!), НО почему-то вызова callback-функции проверки условий в этом случае не происходит !!!! Вместо этого WSAAccept() безусловно возвращает дескриптор нового сокета для вновь установленного соединения (а может, мне его снова нужно было бы отложить? или отвергнуть по каким-либо причинам ?).
    САМОЕ ПЕЧАЛЬНОЕ, что при любом раскладе клиентское гнездо СРАЗУ ЖЕ получает подтверждение постановки запроса со стороны "слушающего" серверного гнезда, если сервер вовремя вызвал Listen() и параметры (IP-адрес и порт) кл.гнезда
    указаны корректно, хотя в этот момент сервер еще не принял решения об акцепте запроса !!!!! Т.е., подтверждение сервером получения клиентского запроса на установление соединения выглядит на клиентской стороне как реальный (а не виртуальный) коннект, и клиент может развернуть последовательность зависимых от успешного коннекта действий (например, начать формирование буфера передачи), не подозревая, что через доли секунды произойдет дисконнект, связанный с отвержением запроса.
    Где здесь"зарыта собака" ?
    Можно ли обойти проблему и каким образом ?
    Слышал, что MS намеренно реализовал такую логику с целью, якобы, минимизации времени на установление коннекта. Но - жесткая ли она, эта логика ? Как ее обойти, возможно, заданием спец. опций TCP-протокола (или QOS) ?? Можно ли найти более-менее понятные и надежные примеры реализации "верной по сути" логики ? (неважно, на чем сверстанные). Есть ли в сети сайты/форумы, посвященные данным проблемам, желательно, в Рунете? Заранее признателен Вам за внимание. Надеюсь на любую помощь в возникших у меня вопросах с учетом Вашей компетенции.

    Date : Mon, 9 Apr 2001 13:41:42
    Уважаемый госп. Семенов!
    Не могли бы Вы сообщить об условиях размещения информации о компании "Атлант_Информ", являющейся разработчиком сертифицированной АСР для телекоммуникационных предприятий "Атлант" на Вашем сайте в рубрике 10.11 "Адреса фирм, работающих в сфере телекоммуникаций".
    Заранее благодарна, начальник отдела по связям с общественностью компании "Атлант-Информ"
    Наталья Лыкова. <market@atlant-inform.ru>

    From : "Shefanovski Dennis" <shefanovski@infosec.ru>
    To: <semenov@itep.ru>
    Date: Tue, 3 Apr 2001 06:20:34
    Посмотрел и стало грустно...
    Прочитайте документацию, есть ведь даже модели конечных состояний клиента и сервера.
    Так нельзя.
    PS Я прекрасно понимаю, что все охватить невозможно, но все же
    Best regards! DennisShefanovski <shefanovski@infosec.ru>

    Это единственный негативный отклик. Именно по этой причине позволю себе краткий комментарий. Во-первых у меня давно устойчивая аллергия на машины конечных состояний. Во-вторых, с моей точки зрения нужно быть большим педантом, чтобы диалоговый алгоритм описывать с помощью формализма FSM. Скажем, протокол TCP, еще куда ни шло, а SSL, эту уж действительно чересчур. В-третьих, то, что помещено на сервере, взято было со страницы компании NetScape. Но, признаю, нет предела совершенству, и я не хотел бы утверждать, что создал образец для подражания. Интернет прекрасен тем, что если вы знаете как что-то сделать лучше, - сделайте это и дайте другим воспользоваться.

    Date : Fri, 20 Apr 2001 16:46:44
    Уважаемый Юрий Алексеевич, внимательно прочел материалы, размещенные Вами на сервере http://book.itep.ru/ под общим названием Telecommunication technologies - телекоммуникационные технологии.
    Особенно интересным мне показался раздел о диагностике сетевого оборудования. Вы приводите описание программы для мониторинга состояний серверов в сети; не могли бы Вы (если, конечно, это возможно) сообщить адрес электронной почты разработчика этой программы (конечно, с его согласия) - мне очень нужна консультация по вопросам, связанным с мониторингом состояния серверов в internet.
    С уважением, Дмитрий <meditech@spb.cityline.ru>

    Date : Wed, 16 May 2001 04:04:29
    Добрый день, уважаемый Семенов Ю.А.
    Простите за беспокойство, но может быть Вы сможете мне помочь. Меня зовут Александр, я программист из Киева. Раньше мне никогда не приходилось сталкиваться с задачами
    телекоммуникаций, но по работе срочно необходимо написать программу
    демодуляции фазоманипулированных сигналов PSK, BPSK, QPSK (источник - звук, принимаемый SoundBlasterom).
    Если Вас не затруднит, не могли бы Вы подсказать мне алгоритм, принцип, формулы, что угодно, для демодуляции этих сигналов. Или, по меньшей мере, подскажите, где можно об этом прочесть (книги, Internet).
    Заранее крайне Вам признателен.
    Александр. <VORONUK@APORT.RU>

    Date : Sat, 2 Jun 2001 15:38:00
    Добрый день.
    Заходил к Вам на сайт, узнал о кафедре "Телекоммуникационные сети и системы". Подскажите? пожалуйста, есть ли у Вас дистанционная, либо заочная форма обучения и каким специальностям у Вас обучают.
    С уважением, Анфёров Евгений
    Инженер ЭВМ ООО "СК Мост"
    676850, г. Белогорск ул. Кирова 279 "Б"
    E-Mail: jon@most.com.ru ICQ# 23629387
    www.skmost.ru

    Date : Mon, 11 Jun 2001 10:54:20
    Добрый день!
    У меня к вам большая просьба!
    Мне срочно нужна информация по написанию драйверов для сетевого адаптера под MS-DOS (для диплома). Подскажите pls, где можно ее найти. (мои поиски пока ни к чему не приводят, кроме вашей статьи "Программирование при работе с TCP/IP пакетами"). Заранее благодарен,
    Александр <phoenix@aib.ru>
    P.S. Нет так нет (буду искать)

    From : "Alexandr Ivanov" <ivanov@kons.ru>
    To: <semenov@itep.ru>
    Здравствуйте, Юрий Алексеевич!
    Сегодня случайно наткнулся в сети на Вашу книгу. Очень полезное и необходимое издание. Хочу просить Вашего разрешения на зеркалирование этого сайта... Я исключаю любое коммерческое использование. Хочу просто создать копию у себя на сервере и продвигать этот ресурс среди своих клиентов. Компания, в которой я работаю, является крупнейшей телекоммуникационной компанией в регионе. Среди наших клиентов 80% провайдеров города Саратова.
    Жду Вашего ответа. Спасибо.
    С Уважением, Александр Иванов
    Начальник отдела ИТ ЗАО "Конверсия-связь"
    ______________________________________________
    AI1410-RIPE  mailto:ivanov@kons.ru  +7 845 2450544

    Date : Wed, 27 Jun 2001 10:26:15
    Здравствуйте, Юрий Алексеевич!
    Все наши ресурсы построены именно таким образом, что тексты и рисунки лежат в какой-то базе данных. А дизайн - это 2-3 шаблона. Именно из-за того, что информация на Вашем сайте постоянно обновляется и нужен такой вариант, чтобы не выкачивать страницы целиком. а только обновления базы. Цель, которую я преследую такова: есть необходимость иметь локально нужный, интересный и полезный ресурс и пропагандировать его среди своих клиентов. Клиенты создают трафик, чем он больше, тем дешевле стоит и для меня и для клиентов. По-поводу идей: направляю Ваше письмо своему WEB-мастеру. Думаю, он сможет что-то предложить. Адрес, где будет размещено зеркало: book.kons.ru
    , но это будет позже, когда мой администратор вернется из командировки (на следующей неделе).
    С Уважением,
    Александр Иванов
    Директор департамента ИТ ЗАО "Конверсия-связь"
    ______________________________________________
    AI1410-RIPE  mailto:ivanov@kons.ru  +7 845 2450544

    Date : Tue, 03 Jul 2001 19:05:35>
    Здравствуйте!
    Я обнаружил вашу электронную версию книги "Сети Интернет" Скажи, пожалуйста есть ли у вас версия в PDF и где её можно найти?
    С Уважением М.А. Пикулин
    Молоток: от Фаберже до неглиже
    http://www.molotok.ru/?190

    Date: Mon, 9 Jul 2001 17:40:10
    Добрый день !
    Если у Вас , есть информация по аналоговым интерфейсам :
    e&m (
    типы 1, 2, 3, 4, 5 )
    ls/gs Subscriber (FXS)
    ls/gs Exchange (FXO)
    MRD
    по цифровым
    v.24/v.28/rs-232c
    rs-530-a, v.36/rs-449, x.21
    и x.35
    OCU-DP
    G.703
    сонаправленный 64 кбит / с ......
    и возможность, вышлите ее (информацию), пожалуйста, на
    evsve@mail.ru
    с уважением, Евграфов Сергей!

    Date: Thu, 9 Aug 2001 12:34:56
    Уважаемый господин Семенов Ю.А.
    Должен Вам сообщить о некоторой неточности, которая присутствует в перечислении компаний, работающих в области телекоммуникаций. ( сайт http://book.itep.ru/1/intro1.htm раздел 10 ). Компаний Wandel Goltermann и Wavetek в настоящее время не существует, т к в 1998 году они путем слияния были преобразованы в корпорацию Wavetek Wandel Goltermann с соответствующим сайтом в Интернете www.wwgsolutions.com . Однако это не последнее преобразование фирмы.
    В 2000 году произошло следующее слияние компаний WWG и американской ТТС. В результате образованная компания получила название ACTERNA. Именно под этим названием компания и работает в настоящее время. Сайт в Интернете называется - www.acterna.com (или российский сайт - www.acterna.ru )

    Date: Sat, 6 Oct 2001 18:22:46
    From: "profy.ru" <info@profy.ru>
    To:
    semenov@itep.ru
    Уважаемые господа !
    Разрешите предложить Вашему вниманию для возможного размещения в разделе ссылок Вашего сайта наш Интернет-проект "Мир Профессионалов"- www.profy.ru . Это универсальный кадровый сервер, с которым сотрудничают и размещают свои вакансии более 1500 компаний и кадровых агентств. Все размещаемые вакансии модерируются, то есть исключены вакансии от недобросовестных работодателей. Надеемся, ссылка на www.profy.ru окажется интересной для Ваших посетителей. Кнопку сайта можно выбрать здесь - http://moscow.profy.ru/linktoprofy.phtml
    С наилучшими пожеланиями,
    Владимир Ершов,
    менеджер проекта
    www.profy.ru
    info@profy.ru

    From: "spartak@nojabrsk.ru"
    Date: Fri, 19 Oct 2001 02:34:33

    Здравствуйте, Юрий Алексеевич.
    Спасибо Вам за Вашу электронную книгу по сетям. Впечатляет. Имеется ли что-нибудь по программированию, по дискретной и вычислительной математикам.
    С уважением
    Александр Суворов
    Best regards,
    Alexandre mailto:spartak@nojabrsk.ru

    Date: Thu, 25 Oct 2001 21:44:41
    Здравствуйте господин Семенов !
    Меня зовут Олег. Я столкнулся с необходимостью получения документации по протоколу Х500. В рунете я нашел вашу статью на эту тему, но предложенной там информации оказалось недостаточно. Не могли бы вы, если вас не затруднит, подсказать на каких русскоязычных ресурсах можно найти информацию на эту тему. Заранее вам благодарен.
    solid82@rambler.ru
    Бесплатная почта http://mail.Rambler.ru/
    Рамблер-Покупки http://ad.rambler.ru/ban.clk?pg=1691&bn=9346

    Date : Wed, 12 Dec 2001 15:24:57
    Здравствуйте Юрий Алексеевич,
    Недавно наткнулся на ?кусочки? ваших электронных лекций у одного из своего знакомых. Очень заинтересовался вашим материалом, но к сожалению, ваших книжек в продаже не нашел. Если вас не затруднит, пожалуйста, напишите, где можно заказать или пробрести вашу литературу, CD (если он вышел) и вышли ли ваши новые труды после ?Протоколы и ресурсы Интернет? (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы? (Сиринъ, М. 1998).
    Заранее благодарен,
    с уважением, студент 4-го курса СПбГТУ
    Бесплатная почта http://mail.Rambler.ru/

    Date: Wed, 29 May 2002 13:03:21
    Уважаемый Юрий Алексеевич!
    Большое спасибо за вашу работу, результатами которой очень приятно пользоваться (а главное с пользой). На сервере представлено очень много информации, но доступ к ней удобен только для тех, кто имеет постоянный доступ в сеть. Не планируете ли вы выкладывать для скачивания оффлайновую версию сайта? george@comtv.ru

    From: "Eugene Rybakov" <rybakov@bhv.ru>
    To: <semenov@itep.ru>
    Date: Thu, 11 Apr 2002 13:07:37
    ..Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".
    ...данное направление науки и технологии развивается стремительно и отследить прогресс в этой отрасли с использованием техники книжных издательств практически невозможно (первая книга готовилась к печати с уровня машинных файлов около года, вторая - 4 месяца). Автор решил попытаться решить эту проблему методами современных сетевых технологий.

    Уважаемый Юрий Алексеевич!
    Если Вы не разочаровались окончательно в технике книжных издательств, прошу обратить внимание на возможность издания очередной книги в "BHV-Петербург". Тематика нас весьма интересует.
    Рассмотрим встречные предложения.
    Евгений Рыбаков, научный редактор.

    From: "AdminAtlas" <kisasoft@atlas-nsk.ru>
    To: <semenov@itep.ru >
    Date: Wed, 11 Sep 2002 12:33:00
    Прошу Вашего согласия на размещение текста сайта http://book.itep.ru/ у себя на сайте http://www.atlas-nsk.ru в одном из разделов посвященных сходной тематике. Сохранность авторской редакции текста гарантирую. Ссылки на автора будут установлены. Жду ответа.
    С уважением . Семенов Юрий Анатольевич.

    From: <anatoly@podgoretsky.com>
    To: <semenov@itep.ru >
    Date: Wed, 14 Sep 2002 19:14:23 +0300

    Здраствуйте господин Семенов!

    Я веду ряд проектов электронной библиотеки, в частности и проект Интернет. Ваша книга "Telecommunication technologies - телекоммуникационные технологии" была бы ценным приобретением для данного проекта, естественно, что без вашего соглаисия я не могу ее разместить на своем сайте http://www.podgoretsky.com/internet.html/. Проект абсолютно не коммерческий. Если вы дадите свое согласие, то я буду очень благодарен.
    С уважением,
    Анатолий Подгорецкий
    http://www.podgoretsky.com anatoly@podgoretsky.com

    From: <safonov@tih.ru>
    To: <semenov@itep.ru >
    Date: Wed, 27 Nov 2002 09:58:34
    Здравствуйте, Юрий Алексеевич.
    Совершенно случайно нашел Ваш сайт "телекоммуникационные технологии". Огромное спасибо за него! Я только начинаю администрить и он уже стал моим "настольным" справочником.
    С уважением, Сафонов Андрей
    mailto:safonov@tih.ru
    www.tihoretsk.ru

    From: <worker@smtn.stavropol.ru > statel.stavropol.ru (statel.stavropol.ru [212.96.96.1])
    To: <semenov@itep.ru >
    Date: Tue, 18 Feb 2003 03:22:34 -0500

    Здравствуйте, уважаемый Юрий Алексеевич!

    Я являюсь администратором сервера зеркал http://mirrors.smtn.stavropol.ru , целью которого является развлечение и образование "подрастающего поколения", поскольку сервер расположен в зоне городской Интранет-сети, доступ к которой в пределах города Ставрополя по коммутируемой линии дешевле доступа к Интернет в 2-3 раза, что позволяет пользоваться услугами сети молодежи и людям с невысокими доходами. Блуждая по бескрайним просторам Интернет я наткнулся на Ваш информационный ресурс http://book.itep.ru, который показался мне очень полезным для целей образования. В свете вышесказанного у меня к Вам вопрос: не рассматривали ли Вы возможность зеркалирования сайта (с учетом наличия скриптов контроля знаний) и как Вы отнесетесь к размещению зеркала сайта на нашем сервере?

    С уважением!
    Лещенко Владимир Николаевич

    Previous: 10.27 Законы Мерфи для программистов    UP: 10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций


    previous up down next index index
    Previous: 2.9.1 Используемые стандарты    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 3 Каналы передачи данных

    2.10 Статистическая теория каналов связи
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Данная статья имеет целью познакомить с терминологией и математическими основами статистической теории передачи данных. Именно на этой математической основе зиждятся приведенные выше теоремы Шеннона и Найквиста. Статья является компиляцией из нескольких источников (Ю.В.Прохоров, Ю.А.Розанов "Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы" Наука, М. 1967; Л.Ф. Куликовский, В.В.Мотов, "Теоретические основы информационных процессов", Высшая школа, 1987; Р. Галлагер "Теория информации и надежная связь" Советское радио, 1974 и др.). Материалы, предлагаемые здесь не могут считаться исчерпывающими и призваны быть поводом для более углубленного изучения по существующим монографиям.

    Канал связи предназначен для транспортировки сообщений. Математическая модель канала связи описывается некоторой совокупностью Х 1 элементов х1 (X1 = {x11, x12,, .x1j }), называемых сигналами на входе канала, совокупностью Х2 элементов х 2 (x2 = {x21, x22,, .x2k}), называемых выходными сигналами, и условными распределениями вероятностей p2=p2(a2 |x1) в пространстве x2 выходных сигналов x2 . Если посланный сигнал (сигнал на входе) есть х1 , то с вероятностью P2=P2(A2|x1 ) на выходе канала будет принят сигнал х2 из некоторого множества A2 М Х2 (распределения задают вероятности того или иного искажения посланного сигнала х1 ). Совокупность всех возможных сообщений обозначим символом x0. Предполагается, что каждое из сообщений x0 О X0 может поступать с определенной вероятностью. То есть, в пространстве X0 имеется определенное распределение вероятностей P0=P0(A0 ).

    Сообщения х0 не могут быть переданы по каналу связи непосредственно, для их пересылки используются сигналы x1 О X1 . Кодирование сообщений х0 в сигналы х1 описывается при помощи условного распределения вероятностей P1=P1(A1 |x0). Если поступает сообщение х0, то с вероятностью P1=P1(A1|x0) будет послан один из сигналов х1 , входящих в множество A1 М Х1 (условные распределения P1(A1|x0) учитывают возможные искажения при кодировании сообщений). Аналогичным образом описывается декодирование принимаемых сигналов х2 в сообщения x3 . Оно задается условным распределением вероятностей P3=P3(A3|x2) на пространстве Х3 сообщений х3 , принимаемых на выходе канала связи.

    На вход канала связи поступает случайное сообщение x 0 с заданным распределением вероятностей P0=P0(A0 ). При его поступлении передается сигнал x 1, распределение вероятностей которого задается правилом кодирования P1=P1(A1|x0):

    P{x 2 О A2|x 0, x 1} = P2(A2|x 1)

    Принятый сигнал x 2 декодируется, в результате чего получается сообщение x 3:

    P{x 3 О A3|x 0, x 1, x 2} = P3(A3| x 2)

    Последовательность x 0 x 1 x 2 x 3 является марковской. При любых правилах кодирования и декодирования описанного типа имеет место неравенство:

    I(x 0, x 3) ё I(x 1, x 2),

    где I( x 0, x 3) - количество информации о x 0 в принятом сообщении x 3, I(x 1, x 2) - количество информации о x 1 в принятом сигнале x 2.

    Предположим, что распределение вероятности входного сигнала x 1 не может быть произвольным и ограничено определенными требованиями, например, оно должно принадлежать классу W. Величина C = sup I(( x 1 , x 2) , где верхняя грань берется по всем возможным распределениям P1 О W, называется емкостью канала и характеризует максимальное количество информации, которое может быть передано по данному каналу связи (теорема Шеннона).

    Предположим далее, что передача сообщений x 0 x 3 должна удовлетворять определенным требованиям точности, например, совместное распределение вероятностей P x0 x1 передаваемого и принимаемого сообщений x 0 и x 3 должно принадлежать некоторому классу V. Величина H= inf I( x 0 x 3), где нижняя грань берется по всем возможным распределениям P xx3 О V, характеризует минимальное количество информации, которое должно заключать в себе принимаемое сообщение x 3 о x 0, чтобы было выполнено условие точности передачи. Величина H называется энтропией источника сообщений.

    Если возможна передача x 0 x 1 x 2 x 3 с соблюдением требований V и W, то есть существуют соответствующие способы кодирования и декодирования (существуют условные распределения P1, P2 и P3), то H ё С.

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

    Предположим, что совокупность Х0 всех возможных сообщений х0 является дискретной (имеется не более чем счетное число различных сообщений x0 , поступающих с соответствующими вероятностями P0(x0), x0 О X0 ) и условие точности передачи v состоит в том, что принимаемое сообщение x 3 должно просто совпадать с переданным сообщением x 3 = x 0 с вероятностью 1. Тогда

    Предположим далее, что имеется лишь конечное число N различных входных сигналов х1 и нет никаких ограничений на вероятности P{ x 1 = x1}, x1   О  X1. Кроме того, предположим, что передаваемые сигналы принимаются без искажений, то есть с вероятностью 1 x 2= x 1 . Тогда емкость канала выражается формулой C = log 2N, т.е. передаваемое количество информации I( x 1, x 2 ) будет максимальным в том случае, когда сигналы x1 О X1 равновероятны.

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


    группа сообщений, поступающая на кодирование с вероятностью

    Пусть H<C, положим также d=(1/2)(C-H). Согласно закону больших чисел, примененному к последовательности независимых и одинаково распределенных случайных величин

    с математическим ожиданием

    для любого e >0 найдется такое n(e), что при всех n Ё n(e )

    P{-H-d ё (1/n)logP( x 0n) ё H+d } Ё 1-e, где


    Полученное неравенство говорит о том, что все группы сообщений х0n можно разбить на два класса. К первому классу относятся высоковероятные сообщения х 0n, для которых P(x0n) Ё 2-n(H+d ) и количество которых Mn не больше чем 2n(H+d ):

    Mn ё 2n(H+d )

    Ко второму классу относятся все остальные маловероятные сообщения х0n :
    .

    Каждую группу высоковероятных сообщений х0n можно в принципе передать, закодировав ее соответствующей комбинацией сигналов . Число всевозможных комбинаций такого вида есть Nn=2nC, и видно, что Mn<Nn. Имеется Nn различных сигналов x1n, с помощью которых можно закодировать и передать безошибочно все Mn высоковероятных сообщений x0n Если в дополнение к этому при поступлении любого маловероятного сообщения x0n передавать некоторый один и тот же сигнал (отличный от сигналов, при помощи которых передаются высоковероятные сообщения x0n , то с вероятностью, не меньшей чем 1-e, на выходе канала связи будет приниматься последовательность :

    .

    При выполнении неравенства H < C оказывается возможной передача достаточно длинных сообщений с той оговоркой, что с вероятностью e (e - наперед заданное сколь угодно малое положительное число) может быть допущена ошибка. Имеется целое семейство каналов связи и источников сообщений, зависящих от параметра n.

    Количество информации I( x 0, x 3 ) для абстрактных случайных величин x 0 и x 3 со значениями в пространствах Х0 и Х3 может быть записано в виде:

    I( x 0, x 3) = Mi(x 0, x 3), где


    - информационная плотность. Последовательность пар ( x 0n, x 3n) называется информационно устойчивой, если при n

    I( x 0, x 3) и

    (по вероятности)

    Рассмотренная выше последовательность ( x 0n, x 3n), x 3n= x 0n поступающих сообщений x 0n =( ) обладает свойством информационной устойчивости, что в конечном счете и определило возможность передачи сообщений x 0n с точностью до e. Этот факт допускает широкое обобщение. Например, если Сn - пропускная способность канала
    x 1n ╝ x 2n, Hn - минимальное количество информации, необходимое для соблюдения требуемой точности передачи x 0n ╝ x 3n, причем


    (при n ),

    и существуют информационно устойчивые последовательности пар ( x 0n, x 3n ) и ( x 1n, x2n ), для которых одновременно

    то при весьма широких предположениях для любого наперед заданного e >0 существует такое n(e), что по всем каналам связи с параметром n Ё n(e) возможна передача с точностью до e.

    2.10.2. Канал связи с изменяющимися состояниями

    Как было указано выше, канал характеризуется условными распределениями З2, задающими вероятности тех или иных искажений посылаемого сигнала х1. Несколько изменим схему канала связи, считая, что имеется некоторое множество Z возможных состояний z канала связи, причем если канал находится в некотором состоянии z и на входе возникает сигнал x1, то независимо от других предшествующих обстоятельств канал переходит в другое состояние z1. Этот переход подвержен случайностям и описывается условными распределениями P(C|x1, z) (P(C|x1, z) - вероятность того, что новое состояние z1 будет входить в множество C М Z). При этом уже считается, что выходной сигнал х2 однозначно определяется состоянием канала z1, т.е. существует некоторая функция j = j (z) на пространстве z возможных состояний канала такая, что х2= j (z1). Эта более общая схема позволяет учитывать те изменения, которые в принципе могут возникать в канале по мере его работы.

    Рассмотрим стационарный режим работы канала связи. Предположим, что последовательно передаваемые сигналы
    .., x 1(-1), x 1(0), x 1(1),., соответствующие состояниям канала ., z (-1), z (0), z (1),., и определяемые ими сигналы
    ., x 2(-1), x 2(0), x 2(1),., на выходе образуют стационарные и стационарно связанные случайные последовательности. Величина С=supI(x 1,x 2), где I(x 1,x 2), означает скорость передачи информации о стационарной последовательности {x 1(n)} последовательностью {x 2(n)} и верхняя грань берется по всем допустимым распределениям вероятностей входной последовательности {x 1(n)}, называется пропускной способностью канала связи.

    Предположим, что поступающие на вход канала связи сообщения {x 0(n)}, n =., -1, 0, 1 ,., образуют случайную последовательность. Будем считать правило кодирования заданным, если при всех k, m и k 1,., km Ё k определены условные вероятности

    P{x 1(k1) О B1,., x 1 (km)О Bm|x 0(- ,k)}

    Того, что при поступлении последовательности сообщений

    x 0(- ,k) = ., x 0(k-1), x 0(k)

    на соответствующих местах будут переданы сигналы x 1(k1),., x 1(km), входящие в указанные множества B 1, ., Bm. Эти вероятности считаются стационарными в том смысле, что они не меняются при одновременной замене индексов k и k1,.,km на k+l и k1+l,.,km+l при любом целом l. Аналогичными вероятностями p{ x 3(k1) О D1,., x 3(km) О Dm|x 2(- ,k)} задается правило декодирования.

    Определим величину H формулой H = inf I( x 0,x 3), где I(x 0, x 3) - скорость передачи информации о стационарной последовательности {x 0(n)} последовательностью {x 3(n)}, n = ., -1, 0, 1,. (эти последовательности предполагаются стационарно связанными), и нижняя грань берется по всем допустимым распределениям вероятностей, удовлетворяющим требованиям точности передачи {x 0(n)} { x 3(n)}.

    Неравенство H ё C является необходимым условием возможности передачи

    {x 0(n)} {x 1(n)} {x 2(n)} {x 3(n)}.

    Напомним, что каждое сообщение x 0(n) представляет собой некоторый элемент х0 из совокупности Х 0 . Можно интерпретировать Х0 как некоторый алфавит, состоящий из символов х0 . Предположим, что этот алфавит Х0 является конечным и требование точности передачи состоит в безошибочном воспроизведении передаваемых символов:

    P{x 3(k) = x 3(k)} =1 для любого целого k.

    Предположим также, что имеется лишь конечное число входных сигналов х1 и состояний канала z. Обозначим состояния канала целыми числами 1, 2, ., N, и пусть p(k, x1,j) - соответствующие вероятности перехода из состояния k в состояние j при входном сигнале x1:

    p(k,x1,j) = P{z (x+1) = j|z (n)=k, x 1(n+1)=x1}.

    Дополнительно предположим, что любые произведения вида

    p(k0,x1(1),k1)p(k1,x1(2),k2). p(kn-1,x1(n),kn)

    являются стохастическими матрицами, задающими эргодические цепи Маркова. Это условие будет выполнено, если, например, каждая из переходных матриц {p(k,x1,j)} имеет положительный коэффициент эргодичности. Тогда при выполнении неравенства H<C и соблюдении условия эргодичности стационарной последовательности {x 0(n)} сообщений на входе передача возможна с точностью до любого e >0, т.е. при соответствующих способах кодирования и декодирования принимаемая последовательность сообщений {x 3(n)} будет обладать тем свойством, что p{x 3(k) N x 0(k)} < e для любого целого k.

    Пусть x 1 = {x (t), t О T1} и x 2= {x (t), t О T2} - два семейства случайных величин, имеющих совместное гауссово распределение вероятностей, и пусть H1 и H 2 - замкнутые линейные оболочки величин x (t), t О T1, и x (t), t О T2, в гильбертовом пространстве L2 (W). Обозначим буквами P1 и P2 операторы проектирования на пространства H1 и H2 и положим P(1) = P1P2P1, P(2) = P2P1P2. Количество информации I(x 1,x 2) о семействе величин x 1, содержащееся в семействе x 2, конечно тогда и только тогда, когда один из операторов P(1) или P(2) представляет собой ядерный оператор, т.е. последовательность l 1, l 2,. его собственных значений (все они неотрицательны) удовлетворяет условию . При этом

    .

    В случае, когда x 1 и x 2 образованы конечным числом гауссовых величин:

    x 1={x (1),., x (m)}, x 2 = {x (m+1),., x (m+n)}, причем корреляционная матрица B общей совокупности x (1),., x (m+n) является невырожденной, количество информации I(x 1 , x 2) может быть выражено следующей формулой:

    ,

    где B1 и B2 - корреляционные матрицы соответствующих совокупностей x 1 и x 2 .

    Гауссовы распределения обладают следующим экстремальным свойством. Для произвольных распределений вероятностей величин

    x 1 = {x (1), ., x (m)} и x 2 = {x (m+1), ., x (m+n)}

    с соответствующими корреляционными матрицами B1, B2 и B количество информации I(x 1 , x 2) удовлетворяет неравенству

    Пусть x = (x 1,.,x n) и h = (h 1,.,h n) - векторные случайные величины в n-мерном евклидовом пространстве X и r(x,y) - некоторая неотрицательная функция, определяющая условие близости величин x и h, которое выражается следующим соотношением:

    Mr(x ,h ) ё e .

    Величину H=H e , определенную как H e = inf I(x, h), обычно называют e-энтропией случайной величины x (нижняя грань берется по всем случайным величинам h, удовлетворяющим указанному условию e-близости случайной величине x).

    Пусть r(x,y) = r(|x-y|) и существует производная r'(0), 0< r'(0)<. Тогда при e 0 имеет место асимптотическая формула, в которой логарифмы берутся по основанию e:

    где g() - гамма функция и h(x) - дифференциальная энтропия случайной величины x:

    (p x (x) - плотность распределения вероятностей, удовлетворяющая весьма широким условиям, которые выполняются, например, если плотность p x (x) ограничена и h(x ) > - ).
    Пусть (a, b > 0)

    Тогда

    В частности, при a =2, b =1 имеет место асимптотическая формула

    Пусть пара случайных процессов (x 1(t), x 2(t)) образует стационарный в узком смысле процесс, x [u,v] - совокупность значений x (t), u ё t ё v, и пусть
    - условное количество информации о процессе x 1= , содержащееся в отрезке процесса x 2. Среднее количество указанной информации представляет собой линейно растущую функцию от t:

    Фигурирующая здесь величина I(x1 , x2 ) называется средней скоростью передачи информации стационарным процессом x2 о стационарном процессе x 1 или просто - скоростью передачи информации.

    Скорость передачи информации I(x 1,x 2) обладает рядом свойств, аналогичных свойствам количества информации. Но она имеет и специфические свойства. Так для всякого сингулярного случайного процесса x 2 , т.е. такого процесса, все значения x 2(t) которого являются функциями от совокупности величин (t0 может быть выбрано любым), имеет место равенство I(x 1, x 2)=0.

    Для всякого регулярного случайного процесса x 2 равенство I(x 1,x 2)=0 справедливо лишь тогда, когда случайный процесс x 1 не зависит от процесса x 2 (это говорит о том, что в некоторых случаях I(x 1,x 2) N I(x 2,x 1) ).

    При дополнительных условиях типа регулярности скорость передачи информации I(x 1,x 2) совпадает с пределом

    ,

    где - количество информации об отрезке процесса , заключенное в . Так будет, например тогда, когда время меняется дискретно, а отдельные величины x 1(t) и x 2(t) могут принимать лишь конечное число различных значений или когда распределение вероятностей процессов x 1 и x 2 является гауссовым. В случае непрерывного времени t так будет для гауссовых процессов, когда спектральная плотность f(l) процесса x 2(t) удовлетворяет условию

    0< c ё l 2nf(l ) ё c <

    Пусть стационарный процесс x = x (t) представляет собой последовательность величин, каждая из которых принимает значения из некоторого алфавита x, состоящего из конечного числа символов x1, x2,.,xn. Предположим, что вероятность появления на фиксированном месте определенного символа xi есть pi, а вероятность появиться за ним символу xj не зависит от предшествующих xi значений и есть pij:

    P{x (t) = xi} = pi, P{x(t+1) = xi xi|x(t) = xi, x(t-1),., } = pij

    Другими словами x = x (t) - стационарная цепь Маркова с переходными вероятностями {p ij} и стационарным распределением {p i}. Тогда скорость передачи информации стационарным процессом x(t) будет

    I(x,x) = -

    В частности, если x = x(t) - последовательность независимых величин (в случае p ij = pj), то

    I(x,x) = -

    Пусть x 1 = x 1(t) и x 2 = x 2(t) - стационарные гауссовы процессы со спектральными плотностями f11(l), f22(l) и взаимной спектральной плотностью f12(l) причем процесс x 2 = x 2(t) является регулярным. Тогда

    I(x 1, x 2) = -

    Рассмотрим следующее условие близости гауссовых стационарных процессов x 1 (t) и x 2(t):

    M|x 1(t) - x 2(t)|2 ё d 2

    Наименьшая скорость передачи информации
    H = inf I(x 1,x 2), совместимая с указанным условием "d-точности", выражается следующей формулой:

    где

    ,

    а параметр q 2 определяется из равенства

    .

    Эта формула показывает, какого типа спектральная плотность f22(l) должна быть у регулярного стационарного процесса x 2(t), который несет минимальную информацию I (x 1,x 2) " H о процессе x 1(t). В случае дискретного времени, когда f11(l ) Ё q 2 при всех l , -p ё l ё p, нижняя грань H скорости передачи достигается для такого процесса x 2 (t) (со спектральной плотностью f22(l), задаваемой приведенной выше формулой), который связан с процессом x 1 (t) формулой
    x 2 (t) = x 1 (t) + z(t), где z(t) - стационарный гауссов шум, не зависящий от процесса x 2 (t); в общем случае формула f 22(l) задает предельный вид соответствующей спектральной плотности регулярного процесса x 2 (t).

    В случае, когда спектральная плотность f 11(l) приближенно выражается формулой

    соответствующая минимальная скорость передачи информации H может быть вычислена по приближенной формуле , s 2 = M[x(t)]2.

    2.10.3. Симметричный канал без памяти

    Рассмотрим симметричный канал передачи данных без памяти c конечным числом входных сигналов х1 , когда передаваемый сигнал х1 с вероятностью 1-p правильно принимается на выходе канала связи, а с вероятностью p искажается, причем все возможные искажения равновероятны: вероятность того, что на выходе будет сигнал х2 , равна для любого х2 N x1, где N - общее число сигналов. Для такого канала связи пропускная способность
    c = sup I( x 1,x 2) достигается в случае, когда на вход поступает последовательность независимых и равномерно распределенных сигналов ., x 1(-1), x 1(0), x 1(1),.; эта пропускная способность выражается формулой

    Рассмотрим канал связи, на входе которого сигналы образуют стационарный процесс x 1 = x 1(t), M[x 1(t)]2 < .

    Пусть при прохождении сигнала x 1 = x 1(t) он подвергается линейному преобразованию Aj со спектральной характеристикой j (l) и, кроме того, на него накладывается аддитивный стационарный гауссов шум z =z (t), так что на выходе канала имеется случайный процесс x 2(t) вида x 2(t) = aj x 1(t) + z (t).

    Предположим также, что ограничения на входной процесс состоит в том, что M[ x 1(t)]2 ё D 2 (постоянная D 2 ограничивает среднюю энергию входного сигнала). Пропускная способность такого канала может быть вычислена по формуле

    (в последнем выражении интегрирование ведется в пределах -p ё l ё p для дискретного времени t и в пределах - <l < для непрерывного t), где fz z (l) - спектральная плотность гауссова процесса z (t), функция f(l) имеет вид

    а параметр q 2 определяется из равенства

    Нужно сказать, что если функция f(l ) представляет собой спектральную плотность регулярного стационарного гауссова процесса x 1(t), то этот процесс, рассматриваемый как входной сигнал, обеспечивает максимальную скорость передачи информации: I(x 1,x 2) = C. Однако в наиболее интересных случаях, когда время t меняется непрерывно, функция f(l ) обращается в нуль на тех интервалах частот l, где уровень шума сравнительно высок (отличные от нуля значения f(l ) сосредоточены в основном на тех интервалах частот l, где уровень шума сравнительно мал), и поэтому не может служить спектральной плотностью регулярного процесса. Более того, если в качестве входного сигнала выбрать процесс x 1(t) с спектральной плотностью f(l ), то этот сигнал будет сингулярным и соответствующая скорость передачи информации I(x 1,x 2) будет равна нулю, а не максимально возможному значению C, указанному выше.

    Тем не менее, приведенные выражения полезны, так как позволяют приблизительно представить вид спектральной плотности f(l ) регулярного входного сигнала x 1(t), обеспечивающей скорость передачи I(x 1, x 2), близкую к максимальному значению C. С практической точки зрения наиболее интересен случай, когда канал связи имеет ограниченную полосу w пропускаемых частот, т.е. когда спектральная характеристика выражается формулой

    а проходящий через канал шум имеет равномерный спектр:

    В этом случае пропускная способность может быть вычислена по приближенной формуле

    .

    При этом входной сигнал x 1(t), обеспечивающий скорость передачи информации I(x 1, x 2 ), близкую к максимальной, является гауссовым стационарным процессом со спектральной плотностью f(l ) вида

    так что параметры D 2 и s 2 имеют следующий физический смысл:

    - энергетический уровень входного сигнала,

    - энергетический уровень шума.

    Previous: 2.9.1 Используемые стандарты    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 3 Каналы передачи данных


    previous up down next index index
    Previous: 2.1 Передача сигналов по линиям связи    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов
        Next: 2.2 Представление электрических сигналов в цифровой форме

    2.1.1 Влияние шумов и помех
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Шумы определяют емкость канала и задают частоту ошибок при передаче цифровых данных. Шум по своей природе нестабилен и можно говорить лишь о том, что его величина с некоторой вероятностью лежит в определенном интервале значений. Плотность вероятности p(x) определяет вероятность того, что случайный сигнал X имеет значение амплитуды в интервале между x и x+Dx. При этом вероятность того, что значение х лежит в интервале между x1 и x2 определяется равенством:

    , условием нормировки при этом является равенство . P(x) - вероятность, а p(x) - плотность вероятности. Вероятность того, что x меньше некоторой величины y равна , откуда следует, что P{x1 2} = P(x2) - P{x1}, а

    Так называемый белый шум подчиняется непрерывному нормальному (Гауссову) распределению , где а - среднее значение x, а s - среднеквадратичное отклонение х от a. В случае шумов среднее значение х с учетом полярности часто принимает нулевое значение (а=0) .

    В этом случае, если мы хотим знать вероятность того, что амплитуда шумового сигнала лежит в пределах v, то можно воспользоваться выражением

    Для вычисления P{x1<x<-x1} обычно используются равенства
    и . Тогда P{x1 1} = = .

    Распределение P(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность

    P{-ks s}=Pk(k s) = , которая позволяет оценить возможность того, что шумовой сигнал превысит некоторый порог, заданный значением k.

    Из числа дискретных распределений наиболее часто используемым является распределение Пуассона.
    , где n = 0, 1, 2, .; a=mP, m - число испытаний. Распределение Пуассона описывает вероятность процессов, где P<<1. При большом значении m отношение n/m приближается к значению вероятности P.
    Среднее значение x , а для дискретного распределения . Среднеквадратичное отклонение s случайной величины х определяется как: , то же для дискретного распределения .

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

    . Если шум носит чисто тепловой характер, то s 2=kTB. В общем случае s 2 = EnB [Вт], где полоса B измеряется в Гц, En энергия шума.

    Шум определяет вероятность ошибки при передаче сообщения по каналу связи и, в конечном итоге, пропускную способность канала (см. теорему Шеннона; раздел 2.1 Передача сигналов по линиям связи ).

    Previous: 2.1 Передача сигналов по линиям связи    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов    Next: 2.2 Представление электрических сигналов в цифровой форме


    previous up down next index index
    Previous: 2 Преобразование, кодировка и передача информации    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов
        Next: 2.1.1 Влияние шумов и помех

    2.1 Передача сигналов по линиям связи
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Теорема Шеннона ограничивает предельную пропускную способность канала I с заданной полосой пропускания F и отношением сигнал/шум S/N :
    [2.1]

    Для стандартного телефонного канала F=3кГц, N/S=30db, следовательно, теоретический предел для публичной коммутируемой телефонной сети равен примерно 30кбит/с. Ослабление для телефонных скрученных пар составляет около 15 дБ/км, дополнительные ограничения возникают из-за перекрестных наводок. Стандартные проводные линии связи имеют ослабление 6 дБ/км на частоте 800 Гц, или 10 дБ/км на частоте 1600 Гц. На рис. 2.1.1 показана зависимость ослабления от частоты передаваемого сигнала для медной линии с сечением 0,5 мм.


    Рис. 2.1.1. Зависимость ослабления сигнала в медной линии сечением 0,5мм от частоты

    От частоты зависит фаза (из расчета на километр) и волновое сопротивление скрученной пары (см. рис. 2.1.2), по этой причине искажения формы сигнала при заметной длине линии неизбежны.

    Из формулы [2.1] видно, что расширять пропускную способность канала можно за счет широкополосности и высокого отношения сигнал-шум. Существует много источников шума, один из главных тепловые шумы (N = kTB, где T - температура в градусах Кельвина, B - полоса пропускания приемника, а k - постоянная Больцмана). На практике существенно большее влияние оказывают различного рода наводки. Увеличeние пропускной способности сети достигается путем сокращения длины кабеля (уменьшение расстояния между узлами сети), заменой типа кабеля, например, на провод с большим сечением, или применив оптоволоконный кабель. Определенный эффект может быть получен и с помощью усовершенствованной системы шумоподавления (новый, более эффективный модем).


    Рис. 2.1.2. Зависимость волнового импеданса скрученной пары и фазы (сечение 0,5мм) от частоты

    Сопротивление скрученной пары от коммутатора до терминального оборудования может лежать в пределах 800-20000 Ом. Следует учитывать, что при подаче питания на терминальное оборудование (телефон) по подводящему кабелю, большое его сопротивление, помимо прочего, приведет к падению питающего напряжения. В многожильных кабелях определенные проблемы создают перекрестные наводки и шумы. Обычно рассматриваются два случая перекрестных наводок:

    • Источник сигнала и приемник находятся по одну сторону кабеля (NEXT - near end crosstalk);
    • Приемник и источник находятся на разных концах кабеля (FRXT - far end crosstalk).

    NEXT-наводки при большом числе пар проводов в кабеле подчиняются закону f1.5 , а их уровень составляет около 55 дБ при частоте 100 кГц. FEXT-наводки сильно зависят от схемы коммутации и разводки проводов и обычно менее опасны, чем NEXT. Еще одним источников наводок является импульсный шум внешних электромагнитных переходных процессов. Этот вид наводок обычно характеризуется процентом времени, в течении которого его уровень превышает порог чувствительности, и варьируется в зависимости от обстоятельств в очень широких пределах.

    При передаче по линии сигналы модулируются, при этом важно обеспечить сохранение среднего уровня сигнала (постоянной составляющей). Определенные искажения сигнала вносит сам кабель. Заметное влияние на характер искажений оказывает межсимвольная интерференция (ISI - Intersymbol Interference). Эта интерференция возникает из-за расплывания импульсов в процессе их передачи по линии и наезжания их друг на друга. Проблема усложняется тем, что характеристики передающей линии могут меняться со временем (коммутаторы и маршрутизаторы). По этой причине очень важно обеспечить идентичность условий передачи различных частот при наличии таких вариаций. Для решения этой задачи используются линейные эквилайзеры (рис. 2.1.3 и 2.1.4), которые выполняют эту операцию во всем спектре частот, или после стробирования для реального спектра сигнала. Этот метод чувствителен к шумам в системе. Эквилайзеры с решающей обратной связью (DFE - Decision Feedback Equalizer) не чувствительны к шумам, они управляются принятой информацией. Но влияние ошибок при приеме информации в этом случае может быть усилено.


    Рис. 2.1.3. Линейное выравнивание (эквилизация)


    Рис. 2.1.4. Эквилизация с помощью решающей обратной связи

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

    Для улучшения отношения сигнал/шум следует поднимать амплитуду передаваемого по линии сигнала. Выбранное значение определяется требованиями перекрестных наводок и возможностями существующих БИС. В результате компромисса выбрана амплитуда 2.5 В на нагрузке 135 ом. Любые нелинейные искажения должны быть менее 36 дБ по отношению к основному сигналу. Учитывая динамический диапазон сигналов в линиях связи, отношение сигнал шум предполагается равным 20 дБ, что соответствует ограничению 6дБ на число ошибок 1/106 для гауссова распределения шума. При аналого-цифровом преобразовании одному биту соответствует 6 дБ.

    Обычно двухпроводная линия (тем более 4-х проводная) используется для одновременного двухстороннего обмена (full duplex). Эта задача может быть решена схемотехнически мультиплексированием по времени (TDD - Time Division Duplex) или частоте (FDD - Frequency Division Duplex). TDD довольно легко реализовать, этот метод не требует сложных фильтров и эквилайзеров. Метод TDD привлекателен при малых длинах кабеля для коммутируемых телефонных сетей.

    Рис. 2.1.5. Схема эхо-компенсации

    Более широко для реализации двухстороннего обмена по одной паре проводов используется метод эхо-компенсации. Этот метод предполагает вычитание передаваемого сигнала из принимаемого, определяя тем самым истинную форму входного сигнала. Если на приведенном рисунке 2.1.5 Zвх равно волновому сопротивлению линии, то выходной сигнал передатчика не будет влиять на работу приемника. Здесь предполагается, что выходное сопротивление передатчика много меньше z= zлинии. Учитывая вариации ослабления сигнала, схема эхо-компенсации должна уметь работать в очень широком динамическом диапазоне амплитуд, сохраняя удовлетворительную линейность. Это обстоятельство, а также зависимость zлинии от частоты, приводит к заметному усложнению схем эхо-компенсации (Рис. 2.1.6). Системы эхо-компенсации весьма чувствительны к временному разбросу срабатывания пороговых схем, так как это приводит к фазовому сдвигу вычитаемых друг из друга сигналов.

    Рис. 2.1.6. Схема эхо-компенсации с адаптивным фильтром

    На рис. 2.1.7 показана зависимость скорости пропускания от сопротивления петли передающей линии для разных схем кодирования сигнала (пунктирной линией отображен вариант четырехуровневого кодирования). Те, кто работал с выделенными линиями, усвоили эту зависимость на практике. Если сопротивление линии более 1,5 кОм вы скоро будете знать дежурных вашей телефонной станции по имени, узнаете, что такое грозовые вставки и что они имеют привычку окисляться.


    Рис. 2.1.7. Зависимость максимальной скорости передачи данных от сопротивления петли передающей линии

    Различные методы модуляции приводят к разным уровням перекрестных наводок, и, как следствие, могут обеспечить разные скорости пропускания сигналов. Так применение линейной эквилизации при амплитудной модуляции дает улучшение пропускной способности примерно в 5 раз. Из рисунка 2.1.8 видно, что переход от линейного выравнивания к эквилизации с обратной связью позволяет добиться улучшения почти в 1,5 раза. Многоуровневый метод кодирования увеличивает скорость пропускания еще на 30%. Следует, правда, иметь в виду, что многоуровневый метод кодирования характеризуется большим уровнем импульсных помех и, следовательно, ошибок.

    Рис. 2.1.8. Минимальное отношение сигнал-шум при скорости передачи ~150кбит/с

    На рис. 2.1.8 показана зависимость отношения сигнал-шум от сопротивления петли для разных схем передающего канала. Пунктиром проведены зависимости для случая четырехуровневого кодирования. Кривые 1 соответствует случаю амплитудной модуляции с линейным выравниванием, а кривые 2 - варианту эквилизации с обратной связью.

    Previous: 2 Преобразование, кодировка и передача информации    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов    Next: 2.1.1 Влияние шумов и помех


    previous up down next index index
    Previous: 2.1.1 Влияние шумов и помех    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов
        Next: 2.3 Цифровые каналы T1 и Е1

    2.2 Представление электрических сигналов в цифровой форме
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Прогресс последних лет в области повышения пропускной способности каналов в заметной мере связан с развитием технологии передачи цифровых данных. Здесь нужно решить проблемы синхронизации, эффективного кодирования и надежной передачи. Чем шире импульс, тем большую энергию он несет, тем лучше отношение сигнал/шум, но тем ниже и предельная скорость передачи. Раньше каждому двоичному разряду соответствовал импульс или перепад в кодовой последовательности. Сегодня перепад возникает лишь при смене последовательности нулей на последовательность единиц или наоборот. Цифровой метод имеет целый ряд преимуществ перед аналоговым:

    • Высокую надежность. Если шум ниже входного порога, его влияние не ощущается, возможна повторная посылка кода.
    • Отсутствие зависимости от источника информации (звук, изображение или цифровые данные).
    • Возможность шифрования, что повышает безопасность передачи.
    • Независимость от времени. Можно передавать не тогда, когда информация возникла, а когда готов канал.

    На рисунке 2.2.1В представлена уже не последовательность импульсов, а последовательность переходов из одного состояния в другое. При этом уровень +V соответствует логической <1>, а -V - логическому <0>. Переключение из состояния <0> в состояние <1> и наоборот (бод) уже не соответствует передаче одного бита.

    Рис. 2.2.1 Передача цифровых кодов по передающей линии

    На практике число нулей или единиц следующих подряд не лимитировано. По этой причине на принимающей стороне при этом рано или поздно возникает проблема синхронизации временных шкал передатчика и приемника. Для решения этой проблемы существует два метода передачи данных: синхронный и асинхронный . Асинхронный метод используется для относительно низкоскоростных каналов передачи и автономного оборудования. Синхронный метод применяется в скоростных каналах и базируется на пересылке синхронизующего тактового сигнала по отдельному каналу или путем совмещения его с передаваемыми данными. При наличии синхронизации приемника и передатчика можно допустить более длинные последовательности нулей или единиц, что способствует повышению пропускной способности. На рис. 2.2.2 показана схема канала, использующая технику импульсно-кодовой модуляции. Импульсно-кодовая модуляция (ИКМ) была предложена в 30-ые годы 20-го века, но реализована лишь в 1962 году.

    Рис. 2.2.2. Система коммуникаций с использованием кодово-импульсной модуляции (pcm)

    Шаг квантования в АЦП должен быть много меньше диапазона вариации входного сигнала. Число уровней квантования n выбирается из соображений минимизации искажений сигнала и повышения уровня s/n. При разумных предположениях (биполярность сигнала (+V -V), однородность распределения уровня сигнала в рабочем диапазоне, ошибка квантования не более S/2, где S шаг квантования, и т.д.) [S/N]db = 10 log10(22n) = 6n (N - шум квантования при этом равен S 2/12). Это означает, что при 2n уровнях квантования и при условии, что входной сигнал может варьироваться во всем рабочем диапазоне АЦП, отношение сигнал-шум (S/N), связанное с самим процессом квантования, будет равно 6n при n=8 это составит 48 дБ). Отсюда следует известное значение относительного расстояния между уровнями квантования, равное 6 дБ. Звуковой сигнал может иметь динамический диапазон 40 дБ, что создает определенные проблемы, которые преодолеваются путем прямого и обратного логарифмического преобразования (см. рис. 2.4.1).

    Типичный кадр данных в асинхронном канале начинается со стартового бита, за которым следует 8 битов данных. Завершается такой кадр одним или двумя стоп-битами. Стартовый бит имеет полярность противоположную пассивному состоянию линии и переводит приемник в активное состояние. Пример передачи такого кадра показан на рис. 2.2.3.

    Рис. 2.2.3. Пример передачи кадра в асинхронном режиме

    Одним из способов обеспечения надежной синхронизации является применение в приемнике частоты, например, в 8 раз больше частоты следования данных. При этом стробирование данных может производиться примерно в середине сигнала бита (см. рис. 2.2.4).

    Рис. 2.2.4. Схема синхронизации и стробирования с 8-кратной тактовой частотой приемника

    Начальный и стоп-биты на каждый байт данных снижают пропускную способность канала и по этой причине используются только для низких скоростей обмена. Увеличение же длины блока данных приводит к ужесточению требований к точности синхронизации. При использовании синхронного метода передачи необходимы специальные меры для выделения кадра в общем потоке данных. Для решения этой задачи используется специальная сигнатура. Если такая последовательность встретится внутри кадра, она видоизменяется путем ввода в нее двоичных нулей (bit stuffing). Синхронный приемник нуждается в синхронизирующем сигнале, передаваемом передатчиком. Обычно это реализуется путем введения определенного вида кодирования сигнала, например, биполярного кодирования. В этом случае используется три уровня сигнала: +v соответствует логической 1; -v - логическому нулю, а 0 вольт логическому нулю или единице. Пример такого типа кодирования показан на рис. 2.2.5.

    Рис. 2.2.5. Пример биполярного кодирования сигнала (схема RZ - return-to-zero)

    Другой разновидностью такого рода кодирования является использование манчестерского кода. В этой схеме логической единице и нулю соответствует не уровни напряжения, а перепады. Так логической единице поставлен в соответствие переход с низкого уровня на высокий, а логическому нулю - с высокого на низкий (схема NRZ - non-return-to-zero). Пример представления сигнала с использованием манчестерского кода показан на рис. 2.2.6.

    Рис. 2.2.6. Кодирование сигнала с использованием манчестерского кода.

    Манчестерский код достаточно неэффективно использует пропускную способность канала. Оба описанные выше кода требуют удвоения полосы для передачи данных. Этого можно избежать, используя схему цифровой фазировки DPLL - Digital Phase Locked Loop). Эта схема предполагает применение кодирования NRZI (non-return-zero-inverted). Здесь сигнал сначала кодируется с использованием кода NRZ и только затем последовательность преобразуется в NRZI. В процессе такого преобразования логический нуль из NRZ вызывает определенную модификацию исходного кода, в то время как логическая единица не приводит ни к каким вариациям. Здесь создаются условия, при которых количество переходов 0/1 и 1/0 в единицу времени достаточно велико, чтобы обеспечить надежную синхронизацию. Схема NRZI кодирования с использованием DPLL проиллюстрирована на рис. 2.2.7.

    Рис. 2.2.7. NRZI-кодирование

    Симметричная скрученная пара проводов с волновым сопротивлением 120 Ом обеспечивает пропускную способность 2048 Мбит/с (система кодирования HDB3, длина проводов ~100м), а 100 Ом - 1544 Мбит/с (амплитуда сигналов 3 в, система кодирования B8ZS). Номинальное значение перепада обычно составляет 750 мВ.

    Наиболее простая схема передача данных путем представления <0> и <1> с помощью двух уровней напряжения не применяется из-за того, что линия обычно используется для подачи на оконечное (терминальное) оборудование. Проблема может быть решена, если <0> характеризуется 0 вольт (приращение над постоянным уровнем), а <1> попеременно сигналами положительной и отрицательной полярности (AMI - Alternate Mark Inversion). Такая схема создает проблему синхронизации, когда подряд следует большое число нулей. Необходимо, чтобы было достаточное число переходов 0->1 и 1->0 в единицу времени. Существует также схема ADI (Alternate Digit Inversion), где инверсия полярности производится для каждого из передаваемых двоичных разрядов. Но эта схема менее эффективна.

    По этой причине система кодирования AMI была модифицирована в HDB3 (High Density Bipolar 3). Цифра 3 указывает на максимально возможное число последовательных нулей в кодовой последовательности. AMI требует, чтобы <1> передавались попеременно сигналами противоположной полярности, так последовательность 11011 должна быть передана как +-0+-. HDB3 заменяет любую группу из 4 нулей последовательностью из 3 нулей, за которой следует нарушение последовательности отображения единиц. Таким образом, последовательность 11000001 будет отображена как +-000-0+ (возможен инверсный вариант, когда символы + заменяются на - и наоборот). Дальнейшего улучшения балансировки сигнала можно достичь, если заменить код, содержащий 4 нуля подряд, последовательностью b00v (b - обычный биполярный сигнал, v - нарушение последовательности). В США используют схему кодировки B8ZS (Bipolar with 8 Zeros Substitution), где 8 нулей кодируются как 00b0vb0v. В 1986 году ansi принял решение о введение схемы кодирования 2B1Q (2 Binary into 1 Quaternary). При этой схеме каждая пара бит преобразуется в четверичные элементы +3 +1 -1 -3. Код синхронизации (SW - Synchronization Word) при этом содержит 9 четверичных элементов, повторяющихся каждые 1.5 мс:

    +3 +3 -3 -3 -3 +3 -3 +3 +3 (+3 соответствует +2.5 В)

    В Германии используется схема кодировки 4B3T (4 двоичных разряда кодируются в 3 циклических кода).

    Двоичная информация передается блоками, обычно зазываемыми кадрами (или пакетами). В рамках системы 2B1Q для передачи 144 кбит/с требуется частота модуляции не менее 72 кбод. На практике для передачи кадров и выполнения функций управления необходимо создать дополнительные виртуальные каналы. Это доводит требуемую частоту модуляции до 80 кбод. Сводные данные по наиболее популярным схемам кодирования приведены в табл. 2.2.1.

    Таблица 2.2.1.

    Название метода

    Расшифровка

    Описание

    1B2B

    Один бит исходной последовательности кодируется комбинацией из 2 бит половинной длительности

    B3ZS
    B6ZS
    B8ZS

    bipolar with 3/6/8 zero substitution

    Биполярный код с заменой 000/000000/00000000 на последовательности 00v/0vb0vb/000vb0vb (или b0v для B3ZS)

    HDB2 (/3)

    High density bipolar code of order 2 (/3)

    Биполярный код высокой плотности второго (третьего) порядка. Эквивалентен коду с возвратом к нулю (RZ) и с инверсией для логических 1. Последовательность 000 (соответственно 0000) заменяется на 00v или b0v (соответственно 000v или b00v). Число b сигналов между v-сигналами всегда нечетно. В результате возникает трехуровневый код.

    CMI

    coded mark inversion

    Двухуровневый двоичный код (класса 1B2B) без возвращения к нулю. Используется инверсия полярности для каждой логической 1 (единице ставится в соответствие 11 или 00), а для каждого логического нуля вводится смена полярности в середине интервала.

    Кадр содержит 120 пар бит (quats), что соответствует 240 бит, 8 кадров образуют мультифрэйм. Первый кадр мультифрэйма выделяется путем посылки Inverted Synchronization Word (ISW). В конце каждого кадра всегда присутствуют специальные биты, которые служат для целей управления (бит активации, бит холодного старта, биты состояния питания, биты управления синхронизацией и т.д.). Структура кадра выглядит следующим образом:

    Биты

    quats

    Канал

    1-18

    1-9

    isw (кадр 1)

    sw (кадры 2-8)

    19-26

    10-13

    b-канал 1

    27-34

    14-17

    b-канал 2

    34-36

    18

    d-канал

    37-44

    19-22

    b

    45-52

    23-26

    b

    53-54

    27

    d

    55-62

    28-31

    b

    63-70

    32-35

    b

    71-72

    36

    d

    73-80

    37-40

    b

    81-88

    41-44

    b

    89-90

    45

    d

    91-98

    46-49

    b

    99-106

    50-53

    b

    107-108

    54

    d

    109-116

    55-58

    b

    117-124

    59-62

    b

    125-126

    63

    d

    Биты

    quats

    Канал

    127-134

    64-67

    b

    135-142

    68-71

    b

    143-144

    72

    d

    145-152

    73-76

    b

    153-160

    77-80

    b

    161-162

    81

    d

    163-170

    82-85

    b

    171-178

    86-89

    b

    179-180

    90

    d

    181-188

    91-94

    b

    189-196

    95-98

    b

    197-198

    99

    d

    199-206

    100-103

    b

    204-214

    104-107

    b

    215-216

    108

    d

    217-224

    109-112

    b

    225-232

    113-116

    b

    233-234

    117

    d

    235-240

    118-120

    Контроль и управление

    Кадры следуют каждые 1.5мс. Здесь нужно следить за тем, чтобы не было корреляции между сигналами, следующими в противоположных направлениях. Для этого используются скрэмблеры.

    В традиционной телефонной сети для соединения с требуемым клиентом используются аппаратные коммутаторы. Если коммутатор имеет n входов и n выходов, то одновременно можно реализовать не более n связей. Реально это число всегда меньше и клиент слышит в трубке "короткие гудки" сигнала "занято". В случае комбинирования традиционного коммутатора с m-канальными мультиплексорами пакетов по времени можно осуществить до m*n связей одновременно. При этом становится возможным объединить нескольких клиентов так, что они все одновременно могут говорить друг с другом. Схема такого переключателя каналов показана на рис. 2.2.8.

    Рис. 2.2.8. Схема переключателя каналов с мультиплексированием по времени.

    Кружочки на пересечениях линий представляют собой ключи, замыкая которые можно соединить i-й входной канал с j-м выходным. На каждой линии может быть только один замкнутый ключ. Такая схема коммутации называется TST (Time-Space-Time). Именно она преобладает сегодня при построении сетей ISDN. Магистральные каналы ISDN строятся в соответствии со стандартом T1.

    Такая схема при числе входных и выходных каналов равном N=1000 требует миллиона элементарных переключателей. Можно рассмотреть вариант когда используются коммутаторы с n входами и k выходами. Схема коммутатора с N=16, n=4 и k=2 показана на рис. 2.2.9. Число элементаных переключателей в таком коммутаторе М равно:

    M = 2kN + k(N/n)2

    Первое слагаемое характеризует число элементарных переключателей во входной и выходной секциях системы, а второе - число элементарных переключателей в k внутренних модулях При N=1000, n=50 и k=10 требуется 24000 элементарных переключателей вместо миллиона (но и число одновременно формируемых каналов становится много меньше 1000).

    Рис. 2.2.9. Каскадный переключатель-мультиплексор.

    Previous: 2.1.1 Влияние шумов и помех    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов    Next: 2.3 Цифровые каналы T1 и Е1


    previous up down next index index
    Previous: 2.2 Представление электрических сигналов в цифровой форме    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов
        Next: 2.4 Методы преобразования и передачи звуковых сигналов

    2.3 Цифровые каналы T1 и Е1
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Системы (каналы) T1 имеют пропускную способность, соответствующую 24 аналоговым каналам с полосой 0-3.3 кГц (американская версия стандарта). Частота стробирования равна 8 кГц, что соответствует передаче 8000 кадров в сек. После каждых 6000 футов коаксиального кабеля ставятся системы регенерации сигналов. Все 24 канала мультиплексируются на общий коаксиальный кабель, предварительно производится PCM-преобразование сигналов. 24 канала по 8 бит (при 8-битном АЦП) дает 192 бита на кадр. Один дополнительный (193-ий) бит используется для целей синхронизации (F). Таким образом частота бит в канале Т1 составляет 193*8000=1,554 Мбит/с (это стандарт США, его европейский аналог - Е1 имеет 30 каналов и пропускную способность 2048 кбит/c). Это соответствует частоте кадров 667/с. Каждый восьмой бит (младший) байта (временного домена на рис. 2.3.1) используется для целей управления, что несколько снижает пропускную способность. В ISDN каналы 1,544 и 2,048 Мбит/с, форматы которых здесь описаны, называются первичными.

    8-битовые pcm-блоки генерируются каждые 125мксек (8000/с). Структура данных при передаче со скоростью 1,544 Мбит/с представлена ниже (isdn 2*B+D):

    Рис. 2.3.1. Структура кадров для американского (вверху) и европейского (внизу) стандартов передачи данных

    Скорости передачи 1,544 (кодирование B8ZS) и 2,048 Мбит/с (HDB3) называются первичными скоростями. Кадры структурированы так, что временные домены (таймдомен на рис. 2.3.1) для передачи данных по каналам B1 и B2 чередуются. В Европе используется 2048Мбит/с интерфейс. Каждый 6-ой кадр используется для сигнальных целей. Количество временных доменов в кадре определяет число телефонных разговоров, которые могут осуществляться одновременно. Для американского стандарта это число равно 24, а для европейского 30 (в последнем случае учтено то, что часть доменов используется в служебных целях).

    Все современные коммутаторы управляются центральным процессором. Такие коммутаторы обычно называются коммутаторами, управляемыми встроенной памятью (SPC - Stored Program Controlled exchanges).

    Previous: 2.2 Представление электрических сигналов в цифровой форме    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.4 Методы преобразования и передачи звуковых сигналов    Next: 2.4 Методы преобразования и передачи звуковых сигналов


    previous up down next index index
    Previous: 2.4 Методы преобразования и передачи звуковых сигналов    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.4.2 Кодировщики голоса (Vocoder)

    2.4.1 Дельта-модуляция
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Дельта-модуляция представляет собой вариант дифференциальной импульсно-кодовой модуляции, где для кодирования разностного сигнала используется только один бит. Этот бит служит для того, чтобы увеличить или уменьшить оценочный уровень. Примером реализации дельта-модуляции может служить схема, показанная на рис. 2.4.1.1. Сигнал ЦАП отслеживает входной сигнал in(t). Здесь компаратор заменил дифференциальный усилитель, который используется в дифференциальном импульсно-кодовом модуляторе.

    Рис. 2.4.1.1 Схема устройства линейной дельта-модуляции

    Если скорость нарастания входного сигнала велика, то уровень на выходе ЦАП будет отставать и сможет нагнать In(t) только, когда входной сигнал начнет уменьшаться. Данный метод не является разумной альтернативой PCM. Для улучшения характеристик дельта-преобразователя реверсивный счетчик можно заменить цифровым процессором, при этом шаг S становится переменным, но кратным некоторому базовому значению.

    Существуют много других способов кодирования человеческого голоса, среди них наиболее эффективный реализован в приборах, носящих название - вокодер (VOCODER).

    Previous: 2.4 Методы преобразования и передачи звуковых сигналов    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.4.2 Кодировщики голоса (Vocoder)


    previous up down next index index
    Previous: 2.4.1 Дельта-модуляция    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.4.3 Передача голоса по каналам Интернет

    2.4.2 Кодировщики голоса (Vocoder)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Эта технология находит применение в военных системах связи, в диспетчерских службах, а также в системах пейджерной связи. Разработчики преобразователей голоса учли особенности работы горла, голосовых связок и всего речевого аппарата. Звонкие и глухие звуки воспроизводятся здесь различными способами (с помощью импульсного генератора и генератора шума, соответственно). Блок-схема преобразователя звука типа вокодер показана на рис. 2.4.2.1. Исходный спектр человеческого голоса здесь делится на ряд субдиапазонов (на рис. 2.4.2.1 их число равно16) по 200 Гц каждый. Эти субдиапазоны выделяются узкополосными фильтрами, за которыми следуют выпрямители и фильтры низких частот (20 Гц). Выходные сигналы этих фильтров мультиплексируются и преобразуются в цифровую форму. Частота стробирования этих сигналов составляет примерно 50 Гц. Разрядность АЦП в этом случае может составлять 3 бита. На принимающей стороне осуществляется цифро-аналоговое преобразование (ЦАП) и мультиплексирование. Сбалансированные амплитудные модуляторы, управляемые ЦАП и переключателем, выдают сигналы на узкополосные фильтры. Все эти сигналы смешиваются в сумматоре, а результат воспроизводится.

    Не трудно видеть, что в случае схемы, показанной на рис. 2.4.2.1, необходимое быстродействие передающей линии составляет 3 бита * 50 Гц * 16 каналов = 2,4 Кбит/с. Дальнейший выигрыш может быть получен за счет цифрового сжатия. Число каналов (фильтров) и ширина пропускаемой полосы частот может варьироваться, соответственно будет меняться и качество воспроизведения звука. Минимально возможная полоса пропускания передающей линии, при которой значение передаваемого текста еще воспринимается правильно, лежит ниже 1 Кбит/с.

    Предшествующая фраза, включая пробелы и знаки препинания, содержит около 150 символов. Для ее произношения требуется около 10 сек (15 символов в сек). Но даже вокодеру потребуется для этого предложения передать не менее 10000 бит. Откуда такое отличие? Во-первых, человеческая речь индивидуальна и эта фраза, произнесенная разными людьми, будет звучать по-разному, кроме того, существует эмоциональная окраска, которой практически лишена буквенная запись. Во-вторых, даже самая совершенная современная система сжатия звуковой информации не идеальна и остается широкое поле для дальнейшего совершенствования. Пути могут быть разными в зависимости от поставленной задачи. Если требуется передать только информацию, следует преобразовать звук в символьную (буквенную) форму, передать эти данные в цифровом виде, а на принимающей стороне осуществить обратное преобразование. Само буквенное представление может быть также подвергнуто некоторому сжатию, но это неизбежно увеличит задержку воспроизведения. В сущности, данная схема является развитием идей, заложенных в вокодере.

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

    Рис. 2.4.2.1. Блок-схема кодирования/декодирования человеческого голоса (Vocoder)

    Previous: 2.4.1 Дельта-модуляция    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.4.3 Передача голоса по каналам Интернет


    previous up down next index index
    Previous: 2.4.2 Кодировщики голоса (Vocoder)    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.5 Методы преобразования и передачи изображения

    2.4.3 Передача голоса по каналам Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Несколько лет назад появился новый вид услуг в Интернет - голосовая связь (IP-phone, Vocaltec). Сегодня имеется 30 миллионов абонентов, регулярно пользующихся IP-phone и его аналогами, ожидается до 200 миллионов до конца текущего десятилетия, качество передачи постепенно приближается к уровню цифровой телефонии.

    Среди пользователей есть те, для кого это лишь возможность общения, как для радиолюбителей; но все больше людей использует IP-phone для деловых контактов или даже как объект бизнеса.

    Существуют два алгоритма сжатия звуковой информации, используемых для ip-телефонных переговоров: GSM (global system for mobile communications, ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm), которая обеспечивает коэффициент сжатия 5, и алгоритм DSP-группы (true speech) с коэффициентом сжатия данных 18 (работает при частотах 7.7 кбит/с). Добавление аппаратных средств сжатия информации позволяет сократить необходимую полосу до 6.72 Кбит/с. Потеря 2-5% пакетов остается незамеченной, 20% оставляет разговор понятным. В таблице 2.4.3.1 представлена зависимость необходимой полосы телекоммуникационного канала от частоты стробирования звукового сигнала, которая определяет качество воспроизведения.

    Таблица 2.4.3.1.

    Пропускная способность
    [бит/с]

    Частота стробирования
    [1/с]

    9600

    4000

    14400

    6000

    19200

    8000

    28800

    11000

    Для подключения к сети ip-phone необходима мультимедийная карта, микрофон, динамики (или наушники), 8 Мбайт оперативной памяти, доступ к Интернет и соответствующее программное обеспечение. Качество передачи звука зависит от загруженности IP-канала. В качестве транспорта используется протокол UDP. Для обеспечения высокого качества звука нужна гарантированная ширина IP-канала, ведь задержанные сверх меры UDP-дейтограммы теряются безвозвратно, что и приводит к искажениям. Внедрение протоколов, гарантирующих определенную ширину канала сделают IP-phone значительно более привлекательным. Многие компании уже предлагают такое оборудование и программы. Программы и описания этого вида услуг можно найти по адресам:

    ftp://cs.ucl.ac.uk/mice/videoconference
    http://www.pulver.com/netwatch
    http://www.planeteers.com
    http://www.newparadigm.com
    http://www.vocaltec.com
    http://www.itelco.com
    http://www.quarterdeck.com

    В последнее время технология передачи звука по каналам Интернет стала широко использоваться для трансляции новостей и музыки. При этом обеспечивается вполне удовлетворительное качество даже при передаче стерео программ. В этом случае имеется возможность применить более эффективное сжатие информации и протоколы типа RTP и RTCP. Задержка при передаче в этом случае никакого значения не имеет, а качество доставки гарантировано. Современные системы ip-телефонии снабжены гибкой системой буферов, позволяющих использовать для передачи паузы, когда один из партнеров молчит. (См. также "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000" RFC-2833 и "URLs for Telephone Calls. A. Vaha-Sipila. April 2000". RFC-2806).

    В настоящее время имеется практически полный набор технологий, чтобы создать электронную книгу. Такая книга будет представлять собой систему размером с ноут-бук, снабженное устройством для чтения CD-дисков. Текст книги вместе с иллюстрациями и необходимыми командными последовательностями записывается на CD. При этом в перспективе можно рассматривать возможность того, что такое устройство будет читать "книгу" вслух (вывод на наушники). В настоящее время имеется достаточно большое количество книг, записанных на cd. Это, прежде всего, энциклопедические словари, альбомы музеев, библия и многие другие. Преимущество такой формы книги уже сегодня ощутимо - вы можете использовать современные поисковые средства, чтобы найти нужный раздел или какую-то конкретную информацию. По мере развития этой технологии и интеграции ее с сетями можно будет осуществлять поиск не только по данной книге, но и по книгам или журналам, ссылки на которые в данной книге содержатся, что может быть особенно полезно при первичном знакомстве с какой-то проблемой. Я здесь не говорю о компактности, а в перспективе, и долговечности такой формы записи информации. При звуковом воспроизведении читатель сможет выбирать, голосом какого актера или актеров будет читаться данная книга. Разумеется, для этого не потребуется начитывать данный текст самим актерам. Достаточно иметь запись характерных особенностей голоса и интонаций конкретного голоса, а процессор сам при генерации звука будет использовать голосовые особенности того или иного человека. Немного фантазии и можно будет представить, как ЭВМ будет воспроизводить текст в виде фильма, который она сгенерировала по выданному ей тексту (ведь сгенерирован же на ЭВМ корабль "Титаник" и море, по которому он плывет). Аналогичные услуги смогут оказываться и через сеть Интернет. Наибольшие трудности вызовет реализация качественного воспроизведения. Программы способные преобразовывать символьный текст в голос уже существуют. Проблема распознавания индивидуального голоса давно решена в охранных системах. Осталось научиться использовать результаты такого анализа при воспроизведении.

    Активно разрабатываются многие новые стандарты и протоколы для обеспечения передачи звука по ip-каналам, проведения видеоконференций и управления в реальном масштабе времени. К таким протоколам относятся RTP (real time protocol, RFC-1889, -1890), RTCP (real-time control protocol), который является дополнением RTP, и RSVP (resource reservation protocol, см. разделы проектов IETF nic.nordu.net, ftp.isi.edu, munnari.oz.au и ds.internic.net или ftp.ietf.org/internet-drafts/draft-ietf-rsvp-spec-16.txt), служащий для обеспечения своевременной доставки данных при работе в реальном времени. Протокол RTP способен работать помимо UDP/IP в сетях CLNP, ATM и IPX. Он обеспечивает детектирование потерь, идентификацию содержимого, синхронизацию и безопасность (доступ по шифрованному паролю, см. RFC-1423). Проблема синхронизации при передаче звука особенно важна, так как даже для локальных сетей время доставки пакетов может варьироваться в весьма широких пределах из-за используемого алгоритма доступа (например, CSMA/CD), а это приводит к искажениям при воспроизведении. Протоколы RTP и RTCP позволяют одновременное голосовое общение неограниченного числа людей в рамках сети Интернет. Протокол же RSVP (или его аналог) в случае внедрения гарантирует качество связи (разумеется, при достаточной широкополосности канала) за счет повышения приоритета пакетов реального времени. Следует иметь в виду, что голосовое общение, хотя и весьма привлекательно, не является единственной и даже главной целью разработчиков. По мере совершенствования протоколов Интернет сделает возможным управление в реальном масштабе времени довольно сложными удаленными объектами.

    В таблице 2.4.2 представлены характеристики аудио-кодеков, которые можно использовать в IP-телефонии.

    Таблица 2.4.2. Характеристики аудио-кодеков

    Кодек

    Выходная скорость кодека

    G.711

    64 кбит/с

    g.723.1

    5,3 или 6,4 кбит/с

    g.722

    48, 56 или 64 кбит/с

    g.728

    16 кбит/с

    g.728/g.729a

    8 кбит/с

    При внедрении ip-телефонии желательно, чтобы сетевая инфраструктура обеспечивала:

    • Время задержки в одну сторону менее 100 мсек.
    • Вероятность потери пакета менее 5%.
    • Оборудование должно соответствовать требованиям H.323v2, а механизмы безопасности - стандарту H.235.
    • Наличие функции привратника в маршрутизаторе/шлюзе (блокирует установку новых телефонных соединений при отсутствии необходимых ресурсов)

    Одна из возможных реализаций IP-телефонии показана на рис. 2.4.3.1. (MVD - Multiflex Voice/WAN модуль, включаемый в маршрутизатор, например, Cisco-3662).


    Рис. 2.4.3.1. Пример реализации системв IP-телефонии

    На рисунке MVW-модуль (Multiflex Voice/WAN), включаемый в маршрутизатор, например, CISCO-3662, служит для связи с общедоступной телефонной сетью. Если сеть "А" размещена в Рио-де-Жанейро, а "В" в Москве, то любой клиент нижней сети сможет разговаривать с клиентом в Рио "бесплатно", а с клиентами телефонных сетей "А" и "B" по локальным тарифам. В левой части рисунка показаны телефонные аппараты, которые подключаются непосредственно к сегменту локальной сети. Такие приборы уже поступили в продажу.

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

    Previous: 2.4.2 Кодировщики голоса (Vocoder)    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.5 Методы преобразования и передачи изображения


    previous up down next index index
    Previous: 2.3 Цифровые каналы T1 и Е1    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.6 Методы сжатия информации
        Next: 2.4.1 Дельта-модуляция

    2.4 Методы преобразования и передачи звуковых сигналов
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    2.4 Методы преобразования и передачи звуковых сигналов

    6

    5

    2.4.1 Дельта-модуляция

    1

    1

    2.4.2 Кодировщики голоса (Vocoder)

    2

    2

    2.4.3 Передача голоса по каналам Интернет

    4

    2

    На физическом уровне в ISDN используется кодово-импульсная модуляция с частотой стробирования 8кГц (что превосходит ограничение Найквиста = 2*3.3кГц, где 3.3кГц - полоса пропускания канала для традиционной телефонной сети). Эмпирически установлено, что для удовлетворительного воспроизведения речи, достаточно 4096 уровней квантования сигнала (12 разрядов АЦП). Такое разрешение диктуется большим динамическим диапазоном сигналов. По этой причине возникает возможность преобразования 12-битных кодов в 8-битные, что формирует информационный поток в 64 Кбит/c. Для этого используется логарифмическое преобразование. Природа позаботилась о человеке, снабдив его логарифмической чувствительностью слуха, в противном случае у нас в мозгу перегорали бы предохранители при близком выстреле или грозовом разряде. Логарифмическое преобразование наталкивается на определенные трудности при низких значениях входного сигнала, ведь логарифм для значений меньше 1 имеет отрицательную величину. Функция же преобразования должна пройти через нуль. В США две логарифмические кривые смещаются в направлении оси ординат (вертикальная ось), в результате получается функция вида:

    y ~ log(1 +mx)

    (так называемая m-зависимость [m-law])

    В Европе используется функция преобразования вида:

    y ~ ax

    в области значений x вблизи нуля и

    y ~ 1 + log(Ax)

    при "больших" значениях x (A-зависимость [a-law], см. рис. 2.4.1)

    Для дальнейшего упрощения процесса преобразования реальные кривые апроксимируются последовательностью отрезков прямых, наклоны которых каждый раз меняется вдвое. На практике функция табулируется (рекомендация G.711) и отличия m- и A-функций пренебрежимо малы. Но следует учитывать, что при реализации практической связи между Европой и Америкой, например телефонной, необходим m/A-конвертор.

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

    Рис. 2.4.1. Иллюстрация функций преобразования сигналов

    Дальнейшим усовершенствованием схемы pcm является адаптивный дифференциальный метод кодово-импульсной модуляции (Рис. 2.4.2). Здесь преобразуется в код не уровень сигнала в момент времени ti , а разница уровней в моменты ti и ti-1 . Так как обычно сигнал меняется плавно, что типично для человеческой речи, можно заметно сократить необходимое число разрядов АЦП. Принципиальное отличие между PCM и ADPCM (1984 год) заключается в использовании адаптивного АЦП и дифференциального кодирования, соответственно. Адаптивный АЦП отличается от стандартного PCM-преобразователя тем, что в любой момент времени уровни квантования расположены однородно (а не логарифмически), причем шаг квантования меняется в зависимости от уровня сигнала. Применение адаптивного метода базируется на том, что в человеческой речи последовательные уровни сигнала не являются независимыми. Поэтому, преобразуя и передавая лишь разницу между предсказанием и реальным значением, можно заметно снизить загрузку линии, а также требования к широкополосности канала. Следует иметь в виду, что метод не лишен серьезных недостатков: уровень шумов, связанный с квантованием сигнала, выше; при резких изменениях уровня сигнала, превышающих диапазон АЦП, возможны серьезные искажения.

    Рис. 2.4.2. Адаптивный преобразователь голоса в код

    Расширение диапазона преобразования достигается умножением шага квантования на величину несколько больше (или меньше) единицы.

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

    Рис. 2.4.3. ADPCM-преобразователь голоса в код для 32кбит/с

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

    Для компактных музыкальных дисков (cd) характерна полоса 50Гц - 20 кГц, обычная же речь соответствует полосе 50 Гц - 7 кГц. Только звуки типа Ф или С имеют заметные составляющие в высокочастотной части звукового спектра. Для высококачественной передачи речи используется субдиапазонный ADPCM-преобразователь (Adaptive Differential Pulse Code Modulation). В нем звук сначала стробируется с частотой 16 кГц, производится преобразование в цифровой код с разрешением не менее 14 бит, а затем подается на квадратурный зеркальный фильтр (qmf), который разделяет сигнал на два субдиапазона (50Гц-4кГц и 4кГц-7кГц). Диапазоны этих фильтров перекрываются в области 4кГц. Нижнему диапазону ставится в соответствие 6 бит (48кбит/с), а верхнему 2 бита (16 Кбит/с). Выходы этих фильтров мультиплексируются, формируя 64 кбит/с -поток.

    На CD используется 16-битное кодирование с частотой стробирования 44,1 кГц, что создает информационный поток 705 Кбит/c. Для стерео сигнала этот поток может удвоиться. Практически это не так - сигналы в стереоканалах сильно коррелированны, и можно кодировать и передавать лишь их разницу, на практике высокочастотные сигналы каналов суммируются, для различия каналов передается код их относительной интенсивности. Исследования показывают, что для акустического восприятия тонкие спектральные детали важны лишь в окрестности 2 кГц. Для передачи звуковой информации с учетом этих факторов был разработан стандарт MUSICAM (Masking pattern Universal Sub-band Integrated Coding and Multiplexing), который согласуется с ISO MPEG (Moving Picture Expert Group; стандарт ISO 11172). musicam развивает идеологию деления звукового диапазона на субдиапазоны, здесь 20кГц делится на 32 равных интервалов. Логарифмическая чувствительность человеческого уха и эффект маскирования позволяет уменьшить число разрядов кодирования. Эффект маскирования связан с тем, что в присутствии больших звуковых амплитуд человеческое ухо нечувствительно к малым амплитудам близких частот. Причем чем ближе частота к частоте маскирующего сигнала, тем сильнее этот эффект (см. рис. 2.4.4). Сплошной линией на рисунке показана нормальная зависимость порога чувствительности уха, а пунктиром - зависимость порога чувствительности в присутствии 500-герцного тона с амплитудой в 110 дБ.

    Рис. 2.4.4.Изменение порога чувствительности человеческого уха под влиянием эффекта маскирования.

    При разбиении на субдиапазоны можно оценить эффект маскирования и передавать только ту часть информации, которая этому эффекту не подвержена. При этом уровень ошибок квантования следует держать лишь ниже порога маскирования, что также снижает информационный поток. Для стробирования высококачественных звуковых сигналов используются частоты 32, 44,1 или 48 кГц. Стандартом предусмотрено три уровня кодирования звука, отличающиеся по сложности и качеству. На первом уровне производится разбивка на 32 диапазона, определение диапазонных коэффициентов и формирование кадров, несущих по 384 результатов стробирования. Уровень 2 формирует кадры с 1152 результатами стробирования и дополнительными данными. Уровень 3 допускает динамическое разбиение на субдиапазоны и уплотнение данных с использованием кодов Хафмана. Любой декодер способен работать на своем и более низком уровне.

    Для улучшения качества передачи низких частот в дополнение к суб-диапазонным фильтрам, используется быстрое Фурье-преобразование (FFT). Результирующая частота бит при передаче звуковых данных оказывается не постоянной. Практическое измерение показывает, что частота редко превышает 110кбит/с, применение 128кбит/с делает качество воспроизведения неотличимым от CD. Ограничение скорости на уровне 64 Кбит/с вносит лишь незначительные искажения.

    Ниже в таблицах представлены данные по скоростям передачи аудиоданных по традиционным цифровым и отповолоконным каналам (см. также раздел 3.5.6).

    Таблица 2.4.1 Скорости передачи данных по цифровым каналам

    Линия

    Быстродействие
    Мбит/с

    Число аудио каналов

    DS-0

    0,064

    1

    T-1

    1,544

    24

    T-1C

    3,152

    48

    T-2

    6,312

    96

    T-3

    44,736

    672

    Таблица 2.4.2. Скорости передачи данных по оптическим каналам

    Линия OC-x

    Быстродействие
    Мбит/с

    Число аудио каналов

    STM-x

    1

    51,84

    672

    -

    3

    155,52

    2016

    1

    9

    466,56

    6048

    3

    12

    622.08

    8064

    4

    24

    1244,16

    16128

    8

    48

    2488,32

    32256

    16

    96

    4976,64

    64512

    32

    192

    9953,28

    129024

    64

    Еще одним методом, нацеленным на повышение эффективности преобразования входного аналогового сигнала в код, является дельта-модуляция.

    Previous: 2.3 Цифровые каналы T1 и Е1    UP: 2 Преобразование, кодировка и передача информации
    Down: 2.6 Методы сжатия информации    Next: 2.4.1 Дельта-модуляция


    previous up down next index index
    Previous: 2.5.1 Стандарт MPEG-4    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.6 Методы сжатия информации

    2.5.2 Стандарт MPEG-7
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Перевод http://mpeg.telecomitalialab.com/standards/mpeg-7/

    MPEG-7 является стандартом ISO/IEC, разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал стандарты MPEG-1, MPEG-2 и MPEG-4. Стандарты MpeG-1 и MPEG-2 сделали возможным интерактивное видео на CD-ROM и цифровое телевидение. Стандарт MPEG-4 предоставляет стандартизованные технологические элементы, позволяющие интеграцию парадигм производства, рассылки и доступа к содержимому в области цифрового телевидения, интерактивной графики и интерактивного мультимедиа.

    MPEG-7 формально называется "Мультимедиа-интерфейс для описания содержимого" (Multimedia Content Description Interface), он имеет целью стандартизовать описание мультимедийного материала, поддерживающего некоторый уровень интерпретации смысла информации, которая может быть передана для обработки ЭВМ. Стандарт MPEG-7 не ориентирован на какое-то конкретное приложение, он стандартизует некоторые элементы, которые рассчитаны на поддержку как можно более широкого круга приложений. Дополнительную информацию о MPEG-7 можно найти на базовой странице MPEG:

    http://www.cselt.it/mpeg

    а WEB-страница MPEG-7 (Industry Focus Group) размещена по адресу http://www.mpeg-7.com. Эти WEB-страницы содержат ссылки на информацию об MPEG, включая описание MPEG-7, многие общедоступные документы, списки "Frequently Asked Questions" и ссылки на WEB-страницы MPEG-7.

    1. Введение

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

    Тенденция очевидна. В ближайшие несколько лет, пользователи столкнутся с таким большим числом мультимедийных материалов, предоставляемых разными провайдерами, что эффективный доступ к этому почти бесконечному материалу представляется трудно вообразимым. Несмотря на тот факт, что пользователи имеют увеличивающиеся ресурсы, управление ими становится все более сложной задачей, из-за их объема. Это касается как профессионалов, так и пользователей. Вопрос идентификации и управления материалами не ограничивается приложениями доступа к базам данных, таким как цифровые библиотеки, но распространяются в сферу выбора широковещательных каналов, мультимедийного редактирования и служб мультимедийных каталогов. Протокол MPEG-7 призван решить многие из этих проблем.

    MPEG-7 является стандартом ISO/IEC, разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал также стандарты MPEG-1 (1992), MPEG-2 (1995), и MPEG-4 (версия 1 в 1998 и версия 2 в 1999). Стандарты MPEG-1 и MPEG-2 позволили производить широко распространенные коммерческие продукты, такие как интерактивные CD, DVD, цифровое широковещательное аудио (DAB), цифровое телевидение, и многие другие коммерческие услуги. MPEG-4 является первым реальным мультимедийным стандартом для представления данных, позволяющим интерактивно работать с комбинациями натурального и синтетического материала, закодированного в виде объектов (он моделирует аудио-визуальные данные, как комбинацию таких объектов). MPEG-4 предоставляет стандартизованные технологические элементы, допускающие интеграцию производства, распределения и доступа к мультимедийному материалу. Это относится к интерактивному и мобильному мультимедиа, интерактивной графике и улучшенному цифровому телевидению.

    Стандарт MPEG-7, формально назван "Multimedia Content Description Interface". MPEG-7 предоставит широкий набор стандартизованных средств описания мультимедиа материала. В области действия MPEG-7 находятся как пользователи-люди, так и автоматические системы, выполняющие обработку аудио-визуального материала.

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

    Дополнительную информацию о MPEG-7 можно найти на WEB-сайте MPEG-7 http://drogo.cselt.it/mpeg/ и сайте MPEG-7 Industry Focus Group http://www.mpeg-7.com. Эти web-страницы содержат ссылки на ценную информацию о MPEG, включая материалы по MPEG-7, многие общедоступные документы, несколько списков 'Frequently Asked Questions' и ссылки на другие WEB-страницы MPEG-7.

    1.1. Контекст MPEG-7

    Доступно все больше и больше аудиовизуального материала из самых разных источников. Информация может быть представлена в различных медийных формах, таких как статические изображения, графика, 3D модели, звук, голос, видео. Аудиовизуальная информация играет важную роль в обществе, будучи записана на магнитную или фото пленку, или поступая в реальном масштабе времени от аудио или визуальных датчиков в аналоговой или цифровой форме. В то время как аудиовизуальная информация первоначально предназначалась для людей, в настоящее время все чаще такие данные генерируются и передаются и воспринимаются компьютерными системами. Это может быть, например, сопряжено с распознаванием голоса или изображения и медийным преобразованием (голос в текст, картинку в голос, голос в картинку, и т.д.). Другими сценариями являются извлечение информации (быстрый и эффективный поиск для различных типов мультимедийных документов, представляющих интерес для пользователя) и фильтрация потоков описаний аудиовизуального материала (чтобы получить только те элементы мультимедиа данных, которые удовлетворяют предпочтениям пользователя). Например, программа во время телепередачи запускает соответствующим образом программируемый VCR, чтобы записать эту программу, или сенсор изображения выдает предупреждение, когда происходит определенное событие. Автоматическое транскодирование может быть выполнено для строки символов, преобразовав ее в аудиоданные, или можно провести поиск в потоке аудио или видео данных. Во всех этих примерах, аудио-визуальная информация была приемлемым образом закодирована, что позволяет программе ЭВМ предпринять соответствующие действия.

    Аудиовизуальные источники будут играть в перспективе все большую роль в нашей жизни, и будет расти необходимость обрабатывать такие данные. Это делает необходимым обработку видов аудиовизуальной информации, имеющей волновую форму, компрессированный формат (такой как MPEG-1 и MPEG-2) или даже объектно-ориентированный (такой как MPEG-4) формат. Необходимы формы презентации, которые позволяют некоторую степень интерпретации смысла информации. Эти формы могут быть переданы в, или доступны для прибора или программы ЭВМ. В примерах приведенных выше датчики изображения могут генерировать визуальные данные не в форме PCM (значения пикселей), а в форме объектов с ассоциированными физическими величинами и временной информацией. Эти объекты могут быть запомнены и обработаны с целью проверки, выполняются ли определенные условия. Видео записывающий прибор может получить описания аудиовизуальной информации, ассоциированной с программой, которая при выполнении заданных условий выдаст команду на запись, например, только новости за исключением спорта или запись фильма с автоматическим вырезанием вставок рекламы (согласитеь, об этом сегодня можно только мечтать).

    MPEG-7 будет стандартом для описания мультимедийных данных, которые поддерживают определенные операционные требования. MPEG не стандартизует приложения. MPEG может, однако использовать приложения для понимания требований и развития технологий. Должно быть ясно, что требования, сформулированные в данном документе, получены из анализа широкого диапазона потенциальных приложений, которые могут использовать описания MPEG-7. MPEG-7 не ориентирован на какое-то конкретное приложение; скорее, элементы, которые стандартизует MPEG-7, будут поддерживать максимально широкий диапазон приложений.

    1.2. Цель MPEG-7

    В октябре 1996, группа MPEG начала разработку проблем, рассмотренных выше. Новым элементом семейства MPEG стал интерфейс описаний мультмедийного материала, называемый "Multimedia Content Description Interface" (или сокращенно MPEG-7), целью которого явилась стандартизация базовых технологий, позволяющих описание аудио-визуальных данных в рамках мультимедийной среды.

    Аудиовизуальный материал MPEG-7 может включать в себя: статические изображения, графику, 3D модели, звук, голос, видео и композитную информацию о том, как эти элементы комбинируются при мультимедийной презентации. В особых случаях этих общих видов данных сюда может включаться выражения лица и частные характеристики личности.

    Средства описаний MPEG-7 однако не зависят от способа кодирования и записи материала. Можно сформировать описание MPEG-7 аналогового фильма или картинки, которая напечатана на бумаге, точно также, как и цифрового материала.

    MPEG-7, как и другие объекты семейства MPEG, предоставляют стандартное представление аудио-визуальных данных, удовлетворяющих определенным требованиям. Одной из функций стандарта MPEG-7 является обеспечение ссылок на определенные части мультимедийного материала. Например, дескриптор формы, используемый в MPEG-4, может оказаться полезным в контексте MPEG-7, точно также Это может относиться к полям вектора перемещения, используемым в MPEG-1 и MPEG-2.

    В своих описаниях MPEG-7 допускает различную гранулярность, предлагая возможность существования различных уровней дискриминации. Хотя описание MPEG-7 не зависит от кодового представления материала, он может использовать преимущества, предоставляемые кодированным материалом MPEG-4. Если материал кодирован с использованием MPEG-4, который предоставляет средства кодирования аудио-визуального материала, в виде объектов, имеющих определенные связи во времени (синхронизация) и в пространстве (на сцене для видео или в комнате для аудио), будет возможно связать описания с элементами (объектами) в пределах сцены, такими как аудио и видео объекты.

    Так как описательные характеристики должны иметь смысл в контексте приложения, они будут различными для разных приложений. Это подразумевает, что один и тот же материал может быть описан различным образом в зависимости от конкретного приложения. Возьмем в качестве примера визуальный материал: нижним уровнем абстракции будет описание, например, формы, размера, текстуры, цвета, движения (траектории) и позиции ("где на сцене может размещаться объект"). А для аудио: ключ, тональность, темп, вариации темпа, положение в звуковом пространстве. Высшим уровнем представления будет семантическая информация: "Это сцена с лающей коричневой собакой слева и голубым мячом, падающим справа, с фоновым звуком проезжающих авто". Могут существовать промежуточные уровни абстракции.

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

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

    • Форма. Примером формы является используемая схема кодирования (например, JPEG, MPEG-2), или общий объем данных. Эта информация помогает определить, может ли материал быть воспринят пользователем.

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

    • Классификация. Это включает оценку происхождения материала и его классификацию по предопределенным категориям.

    • Связь сдругим важным материалом. Информация может помочь пользователю ускорить поиск.

    • Контекст. В случае записанного документального материала, очень важно знать обстоятельства записи (например, олимпийские игры 1996, финал of 200-метрового забега для мужчин с барьерами)

    Во многих случаях будет желательно использовать для описания текстовые данные. Необходимо позаботиться о том, чтобы полезность описаний была независима по возможности от языка. Хорошим примером текстуального описания является указания авторов, названия фильма и пр.

    Следовательно, средства MPEG-7 позволят формировать описания (т.e., наборы схем описания и соответствующих дескрипторов по желанию пользователя) материала, который может содержать:

    • Информацию, описывающую процессы создания и производства материала (директор, заголовок, короткометражный игровой фильм)
    • Информацию, относящуюся к использованию материала (указатели авторского права, история использования, расписание вещания)
    • Информация о характеристиках записи материала (формат записи, кодирование)
    • Структурная информация о пространственных, временных или пространственно-временных компонентах материала (разрезы сцены, сегментация областей, отслеживание перемещения областей)

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

    Все эти описания являются, конечно, эффективно закодированными для поиска, отбора и т.д.

    Чтобы удовлетворить этому многообразию дополнительных описаний материала, MPEG-7 осуществляет описание материала с нескольких точек зрения. Наборы средств описаний, разработанные с учетом этих точек зрения, представляются в виде отдельных объектов. Однако они взаимосвязаны и могут комбинироваться множеством способов. В зависимости от приложения, некоторые будут присутствовать, а другие отсутствовать, а могут присутствовать лишь частично.

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

    Данные MPEG-7 могут физически размещаться вместе с ассоциированным AВ-материалом, в том же информационном потоке или в той же системе памяти, но описания могут также размещаться на другом конце света. Когда материал и его описания размещены не совместно, необходим механизм для соединения AВ-материала и его описаний MPEG-7; эти связи должны работать в обоих направлениях.

    Тип материала и запрос могут не совпадать; например, визуальный материал может быть запрошен, используя визуальное содержимое, музыка, голос, и т.д. Согласование данных запроса и описания MPEG-7 выполняется поисковыми системами и агентами фильтрации.

    MPEG-7 относится ко многим различным приложениям в самых разных средах. Этот стандарт должен обеспечивать гибкую и масштабируемую схему описания аудио-визуальных данных. Следовательно, MPEG-7 не определяет монолитную систему описания материала, а предлагает набор методов и средств для различных подходов описания аудио-визуального материала. MPEG-7 сконструирован так, чтобы учесть все подходы, учитывающие требования основных стандартов, таких как, SMPTE Metadata Dictionary, Dublin Cилиe, EBU P/Meta, и TV Anytime. Эти стандарты ориентированы на специфические приложения и области применения, в то время как MPEG-7 пытается быть как можно более универсальным. MPEG-7 использует также схему XML в качестве языка выбора текстуального представления описания материала. Главными элементами стандарта MPEG-7 являются:

    • Дескрипторы (D). Представление характеристик, которые определяют синтаксис и семантику представления каждой из характеристик.

    • Схемы описания DS (Description Scheme), которые специфицируют структуру и семантику взаимодействия между компонентами. Эти компоненты могут быть дескрипторами и схемами описания.

    • Язык описания определений DDL (Description Definition Language), позволяющий создавать новые схемы описания и, возможно, дескрипторы и обеспечивающий расширение и модификацию существующих схем описания,

    • Системные средства служат для поддержки мультиплексирования описаний, синхронизации описаний и материала, механизмов передачи, кодовых представлений (как текстуальных, так и двоичных форматов) для эффективной записи и передачи, управления и защиты интеллектуальной собственности в описаниях MPEG-7.

    1.3. Область действия стандарта

    MPEG-7 относится к приложениям, которые могут осуществлять запись (или реализовать поточную передачу, например, производить широковещательную пересылку в Интернет), и могут работать как в реальном времени так и off-line. 'Среда реального времени' в данном контексте означает, что описание генерируется в процессе приема материала.

    На рис. 1 показана блок-схема системы обработки данных MPEG-7. Чтобы полностью использовать возможности описаний MPEG-7, автоматическое извлечение характеристик (или 'дескрипторов') может оказаться особенно заметным. Ясно также, что автоматическое извлечение не всегда возможно. Как было указано выше, чем выше уровень абстракции, тем труднее автоматическое извлечение характеристик, и тем полезнее интерактивные средства.

    Рис. 1. Область MPEG-7.

    Чтобы улучшить понимание терминологии введенной выше (т.e. дескриптор, схема описания и DDL), рассмотрите рис.2 и рис. 3.

    Рис. 2. Взаимодействие различных элементов MPEG-7

    На рис. 2 продемонстрирована масштабируемость рассмотренной концепции. Более того, там показано, что DDL предоставляет механизм построения схемы описания, которая в свою очередь образует основу для формирования описания (см. также рис. 3).

    Рис. 3. Абстрактное представление возможных приложений на основе MPEG-7

    Овалами обозначены средства, которые выполняют операции, такие как кодирование или декодирование, в то время как прямоугольниками отмечены статические элементы, такие как описания. Пунктирные прямоугольники на рисунке окружают нормативные элементы стандарта MPEG-7.

    Главной задачей MPEG-7 будет предоставление новых решений для описания аудио-визуального материала. Таким образом, чисто текстовые документы не являются объектами MPEG-7. Однако аудио-визуальный материал может содержать и сопряженный с ним текст. MPEG-7 будет, следовательно, рассматривать и поддерживать существующие решения, разработанные другими организациями стандартизации для текстовых документов.

    Помимо самих дескрипторов на рабочие характеристики системы довольно сильно влияют DB-структуры. Чтобы быстро решить, представляет ли данный материал какой-то интерес, нужно структурировать индексную информацию, например, иерархическим или ассоциативным способом.

    1.4. Область применения MPEG-7

    Элементы, которые стандартизует MPEG-7, будут поддерживать широкий диапазон приложений (например, мультимедийные цифровые библиотеки, выбор широковещательного медийного материала, мультимедийное редактирование, домашние устройства для развлечений и т.д.). MPEG-7 сделает возможным мультимедийный поиск в WEB столь же простым, как и текстовый. Это станет применимо для огромных архивов, которые станут доступны для широкой публики, это придаст новый стимул для электронной торговли, так как покупатели смогут искать нужный товар по видеообразцам. Информация, используемая для извлечения материала, может также применяться агентами для отбора и фильтрации широковещательного материала или целевой рекламы. Кроме того, описания MPEG-7 позволят быстрые и эффективные с точки зрения затрат полуавтоматические презентации и редактирование.

    Все области применения, базирующиеся на мультимедиа, выиграют от использования MPEG-7. Ниже предлагается список возможных приложений MPEG-7, которые любой из читателей без труда сможет дополнить:

    • Архитектура, недвижимость и интерьерный дизайн (например, поиск идей)

    • Выбор широковещательного медийного канала (например, радио, TV)

    • Услуги в сфере культуры (исторические музеи, картинные галереи и т.д.)

    • Цифровые библиотеки (например, каталоги изображений, музыкальные словари, биомедицинские каталоги изображений, фильмы, видео и радио архивы)

    • E-коммерция (например, целевая реклама, каталоги реального времени, каталоги электронных магазинов)

    • Образование (например, депозитарии мультимедийных курсов, мультимедийный поиск дополнительных материалов)

    • Домашние развлечения (например, системы управления личной мультимедийной коллекцией, включая манипуляцию содержимым, например, Редактирование домашнего видео, поиск игр, караоке)

    • Исследовательские услуги (например, распознавание человеческих особенностей, экспертизы)

    • Журнализм (например, поиск речей определенного политика, используя его имя, его голос или его лицо)

    • Мультимедийные службы каталогов (например, Желтые страницы, туристская информация, географические информационные системы

    • Мультимедийное редактирование (например, персональная электронная служба новостей, персональная медийная среда для творческой деятельности)

    • Удаленное опознавание (например, картография, экология, управление природными ресурсами)

    • Осуществление покупок (например, поиск одежды, которая вам нравится)

    • Надзор (например, управление движением, транспортом, неразрушающий контроль в агрессивной среде)

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

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

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

    • Определите объекты, включая цветовые пятна или текстуры и получите образцы, среди которых вы выберете интересующие вас объекты.

    • Опишите действия и получите список сценариев, содержащих эти действия.

    • Используя фрагмент голоса Паваротти, получите список его записей, видео клипов, где Паваротти поет, и имеющийся графический материал, имеющий отношение к этому певцу.

    1.5. План и метод работы

    Метод разработки совместим с тем, что регламентировано в предыдущих стандартах MPEG. Работа над MPEG обычно выполнялась в три этапа: определение, соревнование и сотрудничество. На первой фазе определяется область действия и требования, предъявляемые к стандарту MPEG-7. На следующем этапе участники работают над различными технологиями самостоятельно. Результатом этого этапа является выработка документа CfP (Call for Proposals). В разработке стандарта участвовало около 60 коллективов, было получено 400 предложений.

    Выбранные элементы различных предложений на завершающей фазе инкорпорированы в общую модель (eXperimentation Model или XM) стандарта. Целью являлось построение наилучшей модели, которая по существу представляла собой проект стандарта. На завершающей фазе, XM последовательно актуализовалась до тех пор, пока MPEG-7 в октябре 2000 года не достиг уровня CD (Committee Draft). Дальнейшее усовершенствование XM осуществлялось посредством базовых экспериментов (CE - Core Experiments). CE призваны протестировать существующие средства с учетом новых возможностей и предложений. Наконец все части XM (или рабочего проекта), которые соответствуют нормативным элементам MPEG-7, были стандартизованы.

    1.6. Части MPEG-7

    Стандарт MPEG-7 состоит из следующих частей:

    1. Системы MPEG-7. Средства, которые необходимы при подготовке описаний MPEG-7 для эффективной передачи и записи, и для обеспечения синхронизации между материалом и описаниями. Эти средства имеют также отношение к охране интеллектуальной собственности.

    2. Язык описания определений MPEG-7. Язык для определения новых схем описания и, возможно, новых дескрипторов.

    3. MPEG-7 Audio - дескрипторы и схемы описания, имеющие отношение исключительно к описанию аудио материала.

    4. MPEG-7 Visual - дескрипторы и схемы описания, имеющие отношение исключительно к описанию визуального материала

    5. MPEG-7 Multimedia Description Schemes - дескрипторы и схемы описания, имеющие отношение к общим характеристикам описаний мультимедиа.

    6. MPEG-7 Reference Software - программные реализации соответствующих частей стандарта MPEG-7

    7. MPEG-7 Conformance - базовые принципы и процедуры тестирования рабочих характеристик практических реализаций MPEG-7.

    1.7. Структура документа

    Данный обзорный документ делится на 4 части, не считая введения и приложений. Каждая часть делится на несколько секций, характеризующих различные стороны MPEG-7 [2].

    • секция 2 описывает основные функции,
    • секция 3 содержит детальное техническое описание, а
    • секция 4 содержит список FAQ (Frequently Asked Questions).

    2. Главные функции MPEG-7
    2.1. Системы MPEG-7

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

    2.2. Язык описания определений MPEG-7

    Согласно определению в MPEG-7 язык описания определений DDL (Description Definition Language) представляет собой:

    "... язык, который позволяет формировать новые схемы описания и, возможно, дескрипторы. Он также позволяет расширение и модификацию существующих схем описания".

    В качестве основы DDL был выбран язык XML. Как следствие, DDL может быть поделен на следующие логические нормативные компоненты:

    -Структурная схема языковых компонентов XML;
    -Компоненты типа данных схемы;
    -Специфические расширения MPEG-7.

    2.3. Аудио MPEG-7

    Окончательный проект аудио MPEG-7 представляет шесть технологий: система аудио описаний (которая включает в себя дерево шкал и низкоуровневые дескрипторы), средства описания звуковых эффектов, средства описания тембра инструмента, описание голосового материала, сегмент молчания и дескрипторы мелодии, облегчающие обработку запросов.

    2.4. Визуальный MPEG-7

    Средства визуального описания MPEG-7, включенные в CD/XM состоят из базовых структур и дескрипторов, которые характеризуют следующие визуальные характеристики:

    • Цвет
    • Текстура
    • Форма
    • Движение
    • Локализация
    • Прочие

    Каждая категория состоит из элементарных и сложных дескрипторов.

    2.5. Основные объекты и схемы описания мультимедиа MPEG-7

    Базисом схем описания мультимедиа MDS (Multimedia Description Schemes) является стандартизация набора средств описания (дескрипторы и схемы описания), имеющие дело с общими и мультимедийными объектами.

    Общими объектами являются характеристики, которые используются в аудио, видео и текстовых описаниях и, следовательно, характеризуют все медийные типы материала. Такими характеристиками могут быть, например, вектор, время и т.д.

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

    1. Описание материала: представление воспринимаемой информации;
    2. Управление материалом: информация о характере медийного материала, формирование и использование АВ материала;
    3. Организация материала: представление анализа и классификации нескольких AВ материалов;
    4. Поиск и доступ: спецификация кратких характеристик и изменений АВ-материала;
    5. Взаимодействие с пользователем: описание предпочтений пользователя и истории использования мультимедийного материала.

    2.6. Эталонные программы MPEG-7: модель экспериментов (eXperimentation Model)

    Программное обеспечение модели XM (eXperimentation Model) представляет собой систему моделирования для дескрипторов MPEG-7 (D), схем описания (DS), схем кодирования (CS), языка описания определений (DDL). Кроме нормативных компонентов, системе моделирования необходимы некоторые дополнительные элементы, существенные при исполнении некоторых процедурных программ. Структуры данных и процедурные программы образуют приложения. Приложения XM образуют две разновидности: приложения клиента и сервера.

    3. Детальное техническое описание стандарта MPEG-7
    3.1. Системы MPEG-7

    Системы MPEG-7 в настоящее время определяет архитектуру терминала и нормативных интерфейсов.

    3.1.1. Архитектура терминала

    Представление информации, специфицированное в стандарте MPEG-7 предоставляет средства описаний кодированного мультимедийного материала. Объект, который использует такое кодовое представление мультимедийного материала, называется "терминалом". Этот терминал может соответствовать отдельно стоящему приложению или быть целой прикладной системой. Архитектура такого терминала изображена на рис. 4, а его работа описана ниже.

    Рис. 4. Архитектура MPEG-7

    В нижней части рис. 4 размещена система передачи/записи. Это относится к нижнему уровню инфраструктуры доставки (сетевой уровень и ниже). Эти уровни передают мультиплексированные потоки данных уровню доставки. Транспортная среда MPEG-7 базируется на многих системах доставки данных. Это включает, например, транспортные потоки MPEG-2, IP или MPEG-4 (MP4) файлы или потоки. Уровень доставки реализует механизмы, позволяющие выполнять синхронизацию, формирование кадров и мультиплексирование материала MPEG-7. Материал MPEG-7 может быть доставлен независимо или вместе с данными, которые он описывает. Архитектура MPEG-7 позволяет передавать данные (например, запросы) назад из терминала к отправителю или серверу.

    Уровень доставки предоставляет уровню сжатия MPEG-7 элементарные потоки. Элементарные потоки MPEG-7 состоят из последовательности индивидуально доступных порций данных, называемых блоками доступа (Access Units). Блок доступа является наименьшим информационным объектом, к которому может относиться временная информация. Элементарные потоки MPEG-7 содержат данные различной природы:

    • Схемная информация: эта информация определяет структуру описания MPEG-7;
    • Информация описаний: эта информация является либо полным описанием мультимедийного материала или фрагментами такого описания.

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

    Данные MPEG-7 могут быть представлены либо в текстовом, либо в двоичном формате, или в виде комбинации этих форматов, в зависимости от типа приложения. MPEG-7 определяет однозначную связь между двоичным и текстовым форматами. Возможно установление двухсторонней однозначной связи между текстовым и двоичным представлениями. Следует заметить, что это не всегда доступно: некоторые приложения могут не захотеть передавать всю информация, содержащуюся в текстовом представлении, а могут предпочесть использовать более эффективную с точки зрения полосы двоичную кодировку с потерями.

    Синтаксис текстуального формата определен в части 2 (DDL - Description Definition Language) стандарта. Синтаксис двоичного формата (BiM - двоичный формат для данных MPEG-7) определен в части 1 (системы) стандарта. Схемы определены в частях 3, 4 и 5 (визуальная, аудио и схемы описания мультимедиа) стандарта.

    На уровне компрессии, производится разборка потока блоков доступа (текстуальных или двоичных), а описания материала реконструируются. MPEG-7 не перепоручает реконструкцию текстуального представления в качестве промежуточного шага декодирующему процессу. Двоичный поток MPEG-7 может быть разобран с помощью BiM, передан в текстовом формате и затем в этом виде транспортирован для последующей реконструкционной обработки, или двоичный поток может быть разобран BiM и затем передан в подходящем формате для последующей обработки.

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

    3.1.2. Нормативные интерфейсы
    3.1.2.1. Описание нормативных интерфейсов

    MPEG-7 имеет два нормативных интерфейса, как это показано на рис. 5.

    Рис. 5. Нормативные интерфейсы MPEG-7

    • Материал: это данные, которые должны быть представлены согласно формату, описанному в данной спецификации. Под материалом подразумеваются сами медийные данные, либо их описание.

    • Двоичный/текстовый кодировщик MPEG-7: программа, осуществляющая преобразование материала к формату, который согласуется с данной спецификацией. Это может включать комплексное преобразование материала с целью извлечения деталей.

    • Интерфейс текстового формата. Этот интерфейс описывает формат текстуальных блоков доступа. Текстовый декодер MPEG-7 воспринимает поток таких блоков доступа и реконструирует описание материала нормативным способом.

    • Интерфейс двоичного формата. Этот интерфейс описывает формат двоичных блоков доступа. Двоичный декодер MPEG-7 воспринимает поток таких блоков доступа и реконструирует описание материала нормативным способом.

    • Двоичный/текстовый декодер MPEG-7. Программа, осуществляющая преобразование материала к формату, который согласуется с данной спецификацией.

    3.1.2.2. Верификация стандарта

    В данном разделе описывается, как проверяется то, что двоичное и текстуальное представление являются адекватными одному и тому же материалу. Этот процесс описан на рис. 6.

    Рис. 6 - Процесс верификации

    Кроме элементов описанных в разделе 3.1.2.1, процесс валидации включает определение канонического представления описания материала. В каноническом пространстве, описания материала могут быть сравнены. Процесс валидации работает следующим образом:

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

    2. Два кодированных описания декодируются соответствующими двоичным и текстовым декодерами.
    3. Из реконструированных описаний материала генерируются два канонических описания.
    4. Два канонических описания должны быть эквивалентны.

    Описание канонической презентации XML-документа определено в Canonical XML[3].

    3.2. Язык описания определений MPEG-7 (DDL)

    Главными средствами, используемыми в описаниях MPEG-7 являются DDL (Description Definition Language), схемы описаний (DS) и дескрипторы (D). Дескрипторы связывают характеристики с набором их значений. Схемы описания являются моделями мультимедийных объектов и всего многообразия элементов, которые они представляют, например, модели данных описания. Они специфицируют типы дескрипторов, которые могут быть использованы в данном описании, и взаимоотношения между этими дескрипторами или между данными схемами описания.

    DDL образует центральную часть стандарта MPEG-7. Он обеспечивает надежную описательную основу, с помощью которой пользователь может создать свои собственные схемы описания и дескрипторы. DDL определяет семантические правила выражения и комбинации схем описания и дескрипторов.

    DDL не является языком моделирования, таким как UML (Unified Modeling Language), а языком схем для представления результатов моделирования аудио-визуальных данных, например, DS и D.

    DDL должен удовлетворять требованиям MPEG-7 DDL. Он должен быть способен выражать пространственные, временные, структурные и концептуальные взаимоотношения между элементами DS и между DS. Он должен предоставить универсальную модель для связей и ссылок между одним или более описаниями и данными, которые им описываются. Кроме того, язык не должен зависеть от платформы и приложения и быть читаемым как машиной, так и человеком. MPEG-7 должен базироваться на синтаксисе XML. Необходима также система разборки DDL (парсинга), которая должна быть способна проверять схемы описания (материал и структуру) и дескрипторы типа данных, как примитивные (целые, текст, дата, время) так и составные (гистограммы, нумерованные типы).

    3.2.1. Разработка контекста

    Так как схемный язык XML не был специально разработан для аудио-визуального материала, необходимы определенные расширения, для того чтобы удовлетворить всем требованиям MPEG-7 DDL.

    3.2.2. Обзор схемы XML

    Целью схемы является определение класса XML-документов путем использования конкретных конструкций, чтобы наложить определенные ограничения на их структуру: элементы и их содержимое, атрибуты и их значения, количество элементов и типы данных. Схемы можно рассматривать, как некоторые дополнительные ограничения на DTD.

    Главной рекомендацией MPEG-7 AHG было использование схемы, базирующейся на XML. В начале разработки имелось много решений, но ни одно из них не оказалось достаточно стабильным. В исходный момент группа DDL решила разработать свой собственный язык, следуя принципам, используемым группой W3C при подготовке схемы XML. В апреле 2000, рабочая группа W3C XML опубликовала последнюю версию спецификации схемы XML 1.0. Улучшенная стабильность схемного языка XML, его потенциально широкое поле применения, доступность средств и программ разборки, а также его способность удовлетворить большинству требований MPEG-7, привели к тому, что схема XML явилась основой DDL. Однако так как схема XML не была разработана специально для аудио-визуального материала, необходимы некоторые специфические расширения. DDL делится на следующие логические нормативные компоненты:

    • Схемные структурные компонентыXML;
    • Схемные компоненты типа данных XML;
    • Расширениядля XML схемы MPEG-7.

    3.2.3. Схема XML: Структуры

    Схема XML: Структуры являются частью 2-частной спецификации XML-схемы. Она предоставляет средства для описания структуры и ограничений, налагаемых на материалы документов XML 1.0. Схема XML состоит из набора компонентов структурной схемы, которые могут быть разделены на три группы. Первичными компонентами являются:

    • Схема - внешний уровень определений и деклараций;
    • Определения простых типов;
    • Определения составных типов;
    • Декларации атрибутов;
    • Декларации элементов.

    Вторичными компонентами являются:

    • Определения группы атрибутов;
    • Определения ограничений идентичности;
    • Определения группы;
    • Декларации нотации.

    Третья группа образована компонентами "helper", которые входят в другие компоненты и не могут существовать отдельно:

    • Аннотации;
    • Фрагменты (Particles);
    • Произвольные подстановки (Wildcards).

    Определения типа задают внутренние компоненты схемы, которые могут использоваться в других компонентах, таких как элементы, атрибуты деклараций или другие определения типа. Схема XML предоставляет два вида компонентов определения типа:

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

    Новые типы могут быть также определены на основе существующих типов (встроенных или вторичных) путем расширения базового типа. Детали использования этих компонентов можно найти в проекте DDL или в схеме XML: Спецификация структур.

    3.2.4. Схема XML: Типы данных

    XML Schema:Datatypes является второй частью 2-частной схемной спецификации XML. Она предлагает возможности определения типов данных, которые могут быть использованы для ограничения свойств типов данных элементов и атрибутов в рамках схем XML. Она предлагает более высокую степень проверки типа, чем доступна для XML 1.0 DTD:

    • набор встроенных примитивных типов данных;
    • набор встроенных вторичных типов данных;
    • механизмы, с помощью которых пользователи могут определить свой собственный вторичный тип данных.

    Подробные детали встроенных типов данных и механизмы получения вторичных типов можно найти в окончательном проекте DDL или в спецификации XML Schema:Datatypes.

    3.2.5. Расширения схемы XML MPEG-7

    Следующие характеристики будет нужно добавить к спецификации языка XML для того, чтобы удовлетворить специфическим требованиям MPEG-7:

    • Массив и матрица типов - как фиксированного, так и параметризованного размеров;
    • Встроенные примитивные временные типы данных: basicTimePoint и basicDuration.

    Программы разборки, специфические для MPEG-7 будут разработаны путем добавления валидации этих дополнительных конструкций к стандартным схемным разборщикам XML.

    3.3. Аудио MPEG-7

    Аудио MPEG-7 FCD включает в себя пять технологий: структура аудио описания (которая включает в себя масштабируемые последовательности, дескрипторы нижнего уровня и униформные сегменты тишины), средства описания тембра музыкального инструмента, средства распознавания звука, средства описания голосового материала и средства описания мелодии.

    3.3.1. Описание системы аудио MPEG-7

    Аудио структура содержит средства нижнего уровня, созданные для обеспечения основы для формирования аудио приложений высокого уровня. Предоставляя общую платформу структуры описаний, MPEG-7 Аудио устанавливает базис для совместимости всех приложений, которые могут быть созданы в рамках данной системы.

    Существует два способа описания аудио характеристик нижнего уровня. Один предполагает стробирование уровня сигнала на регулярной основе, другой может использовать сегменты (смотри описание MDS) для пометки сходных и отличных областей для заданного звукового отрывка. Обе эти возможности реализованы в двух типах дескрипторов нижнего уровня (один для скалярных величин, таких как мощность или частота, и один для векторов, таких как спектры), которые создают совместимый интерфейс. Любой дескриптор, воспринимающий эти типы может быть проиллюстрирован примерами, описывающими сегмент одной результирующей величиной или последовательностью результатов стробирования, как этого требует приложение.

    Величины, полученные в результате стробирования, сами могут подвергаться последующей обработке с привлечением другого унифицированного интерфейса: они могут образовать масштабируемые ряды (Scalable Series). Дерево шкал может также хранить различные сводные значения, такие как минимальное, максимальное значение дескриптора и его дисперсию.

    Аудио дескрипторы нижнего уровня имеют особую важность при описании звука. Существует семнадцать временных и пространственных дескрипторов, которые могут использоваться в самых разных приложениях. Они могут быть грубо поделены на следующие группы:

    • Базовая: мгновенные значения уровня волнового сигнала и мощности.
    • Базовая спектральная: частотный спектр мощностей, спектральные характеристики, включая среднее значение, спектральная полоса и спектральная однородность.

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

    • Представления спектрального базиса: характеристики, используемые первично для распознавания звука.

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

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

    Кроме того, очень простым, но полезным средством является дескриптор тишины. Он использует простую семантику "тишины" (то есть отсутствие значимого звука) для аудио сегмента. Такой дескриптор может служить для целей дальнейшей сегментации аудио потока.

    3.3.2. Средства описания аудио верхнего уровня (D и DS)

    Четыре набора средств описания аудио, которые приблизительно представляют области приложения, интегрированы в FCD: распознавание звука, тембр музыкального инструмента, разговорный материал и мелодическая линия.

    3.3.2.1. Средства описания тембра музыкальных инструментов

    Дескрипторы тембра служат для описания характеристик восприятия звуков. Тембр в настоящее время определен в литературе как характеристика восприятия, которая заставляет два звука, имеющих одну высоту и громкость, восприниматься по-разному. Целью средства описания тембра является представление этих характеристик восприятия сокращенным набором дескрипторов. Дескрипторы относятся к таким понятиям как "атака", "яркость" или "богатство" звука.

    В рамках четырех возможных классов звуков музыкальных инструментов, два класса хорошо детализированы, и являются центральным объектом экспериментального исследования. В FCD представляются гармонические, когерентные непрерывные звуки и прерывистые, ударные звуки. Дескриптор тембра для непрерывных гармонических звуков объединяет спектральные дескрипторы тембра с временным дескриптором log attack. Дескриптор ударных инструментов комбинирует временные дескрипторы тембра с дескриптором спектрального центроида. Сравнение описаний, использующих один из наборов дескрипторов выполняется с привлечением метрики масштабируемого расстояния.

    3.3.2.2. Средства распознавания звука

    Схемы дескрипторов и описаний распознавания звука, представляют собой наборы средств для индексирования и категорирования звуков, с немедленным использованием для звуковых эффектов. Добавлена также поддержка автоматической идентификации звука и индексация. Это сделано для систематики звуковых классов и средств для спецификации онтологии устройств распознавания звука. Такие устройства могут использоваться для автоматической индексации сегментов звуковых треков.

    Средства распознавания используют в качестве основы спектральные базисные дескрипторы низкого уровня. Эти базисные функции далее сегментируются и преобразуются в последовательность состояний, которые заключают в себя статистическую модель, такую как смешанная модель Маркова или Гаусса. Эта модель может зависеть от своего собственного представления, иметь метку, ассоциированную с семантикой исходного звука, и/или с другими моделями для того, чтобы категоризовать новые входные звуковые сигналы для системы распознавания.

    3.3.2.3. Средства описания содержимого сказанного

    Средства описания Spoken Content позволяет детальное описание произнесенных слов в пределах аудио-потока. Учитывая тот факт, что сегодняшнее автоматическое распознавание речи ASR-технологий (Automatic Speech Recognition) имеет свои ограничения, и что всегда можно столкнуться с высказыванием, которого нет в словаре, средства описания Spoken Content жертвует некоторой компактностью ради надежности поиска. Чтобы этого добиться, средства отображают выходной поток и то, что в норме может быть видно в качестве текущего результата автоматического распознавания речи ASR. Средства могут использоваться для двух широких классов сценария поиска: индексирование и выделение аудио потока, а также индексирование мультимедийных объектов аннотированных голосом.

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

    3.3.2.4. Средства описания мелодии

    DS мелодического очертания (Melody Contour) является компактным представлением информации о мелодии, которая позволяет эффективно и надежно контролировать мелодическую идентичность, например, в запросах с помощью наигрывания. DS мелодического очертания использует 5-ступенчатый контур (представляющий интервал между смежными нотами), в котором интервалы дискретизированы. DS мелодического очертания (Melody Contour DS) предоставляет также базовую информацию ритмики путем запоминания частот, ближайших к каждой из нот, это может существенно увеличить точность проверки соответствия запросу.

    Для приложений, требующих большей описательной точности или реконструкции заданной мелодии, DS мелодии поддерживает расширенный набор дескрипторов и высокую точность кодирования интервалов. Вместо привязки к одному из пяти уровней в точных измерителях используется существенно больше уровней между нотами (100 и более). Точная информация о ритмике получается путем кодирования логарифмического отношения разностей между началами нот способом аналогичным с используемым для кодирования уровней сигнала.

    3.4. Визуальный MPEG-7

    Средства визуального описания MPEG-7, включенные в CD/XM состоят из базовых структур и дескрипторов, которые охватывают следующие основные визуальные характеристики:

    • Цвет
    • Текстура
    • Форма
    • Движение
    • Локализация
    • Прочее

    Каждая категория состоит из элементарных и составных дескрипторов.

    3.4.1. Базовые структуры

    Существует пять визуально связанных базовых структур: сеточная выкладка, временные ряды (Time Series), многопрекционность (MultiView), пространственные 2D-координаты и временная интерполяция (TemporalInterpolation).

    3.4.1.1. Сеточная выкладка

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

    3.4.1.2. Многовидовые 2D-3D

    Дескриптор 2D/3D специфицирует структуру, которая комбинирует 2D дескрипторы, представляющие визуальные параметры 3D-объекта, видимые с различных точек. Дескриптор образует полное 3D-представление объекта на основе его проекций. Может использоваться любой визуальный 2D-дескриптор, такой как, например, форма контура, форма области, цвет или текстура. Дескриптор 2D/3D поддерживает интеграцию 2D-дескрипторов, используемых в плоскости изображения для описания характеристик 3D-объектов (реальный мир). Дескриптор позволяет осуществлять сравнение 3D-объектов путем сравнения их проекций.

    3.4.1.3. Временные ряды

    Этот дескриптор определяет в видео сегменте дескрипторы временных рядов и предоставляет возможность сравнения изображения с видео-кадром и видео-кадров друг с другом. Доступно два типа временных рядов (TimeSeries): RegularTimeSeries и IrregularTimeSeries. В первом, дескрипторы размещаются регулярным образом (с постоянным шагом) в пределах заданного временного интервала. Это допускает простое представление для приложений, которые предполагают ограниченную сложность. Во втором, дескрипторы размещаются нерегулярно (с переменными интервалами) в пределах заданного временного интервала. Это обеспечивает эффективное представление для приложений, которые требуют малой полосы пропускания или малой емкости памяти. Они полезны в частности для построения дескрипторов, которые содержат временные ряды дескрипторов.

    3.4.1.4. Пространственные координаты 2D

    Это описание определяет 2D пространственную координатную систему, которую следует использовать в других D/DS, где это важно. Оно поддерживает два вида координатных систем: "локальную" и "интегрированную" (рис. 7). В "локальной" координатной системе, все изображения привязаны к одной точке. В "интегрированной" координатной системе, каждое изображение (кадр) может быть привязано к разным областям. Интегрированная координатная система может использоваться для представления координат на мозаичном видео снимке.

    a) "Локальные" координаты b) "интегрированные" координаты

    Рис. 7. "Локальная" и "интегрированная" координатная система

    3.4.1.5. Временная интерполяция

    TemporalInterpolation D описывает временную интерполяцию, использующую связанные многогранники. Это может использоваться для аппроксимации многомерных значений переменных, которые меняются со временем, такие как положение объекта в видео. Размер описания временной интерполяции обычно много меньше, чем описание всех величин. На рис. 8 25 реальных величин представлены пятью линейными интерполяционными функциями и двумя квадратичными интерполяционными функциями. Начало временной интерполяции всегда привязывается ко времени 0.

    Рис. 8. Реальные данные и функции интерполяции

    3.4.2. Описатели цвета

    Существует восемь дескрипторов цвета: цветового пространства, доминантных цветов, цветовой дискретизации, GoF/GoP цвета, цветовой структуры, цветового размещения и масштабируемой гистограммы цветов.

    3.4.2.1. Цветовое пространство

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

    • R,G,B
    • Y,Cr,Cb
    • H,S,V
    • HMMD
    • Матрица линейного преобразования с учетом R, G, B
    • Монохромное

    3.4.2.2. Оцифровка цвета

    Этот дескриптор определяет дискретизацию цветового пространства и поддерживает линейные и нелинейные преобразователи, а также lookup-таблицы. Число уровней квантования конфигурируемо так, чтобы обеспечить большую гибкость для широкого диапазона приложений. В случае нелинейного АЦП, ширина канала преобразования может также конфигурироваться. Для разумных приложений в контексте MPEG-7, этот дескриптор должен комбинироваться с другими, например, чтобы характеризовать значения в цветовой гистограмме.

    3.4.2.3. Доминантный цвет(а)

    Этот дескриптор цвета является наиболее удобным для представления локальных характеристик (области объекта или изображения), где для предоставления цветовой информации достаточно малого числа цветов. Могут использоваться и полные изображения, например, картинки флагов или цветных торговых марок. Квантование цвета используется для получения малого числа характерных цветов в каждой области/изображении. Соответственно вычисляется процент каждого дискретизируемого цвета в области. Определяется также пространственная когерентность всего дескриптора.

    3.4.2.4. Масштабируемый цвет

    Дескриптор масштабируемого цвета (Scalable Color) является гистограммой цветов в цветном пространстве HSV, которая кодируется с помощью преобразования Хара. Ее двоичное представление является масштабируемым с точки зрения числа каналов и числа бит, характеризующих значение точности в широком диапазоне потоков данных. Дескриптор масштабируемого цвета полезен для сравнения изображений и поиска, базирующегося на цветовых характеристиках. Точность отображения возрастает с увеличением числа бит, используемых для описания.

    3.4.2.5. Описатель структуры цвета

    Дескриптор цветовая структура (Color Structure) является описателем цветовой характеристики, которая объединяет цветовое содержимое (аналогично цветовой гистограмме) и информацию о структуре материала. Его главная задача сравнение изображений главным образом для статических картинок. Метод выборки вводит данные о цветовой структуре в дескриптор, учитывая локально цвета окрестных пикселей, и не анализирует каждый пиксель отдельно. Дескриптор цветовая структура обеспечивает дополнительную функциональность и улучшенный поиск, базирующийся на подобии естественных изображений.

    3.4.2.6. Выкладка цвета

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

    3.4.2.7. Цвет GoF/GoP

    Дескриптор цвета группа_кадров/группа_картинок расширяет возможности дескриптора масштабируемого цвета, который определен для статических изображений, чтобы выполнять цветовое описание видео сегментов или собрания статических изображений. Дополнительные два бита позволяют определить, была ли вычислена цветовая гистограмма, прежде чем было осуществлено преобразование Хара: для усреднения, медианы или пересечения. Усредненная гистограмма, которая соответствует усредненному значению счетчика для каждой ячейки всех кадров или изображений, эквивалентна вычислению совокупной цветовой гистограммы всех кадров или изображений с последующей нормализацией. Медианная гистограмма соответствует вычислению медианного значения счетчика для каждой ячейки совокупности кадров или изображений. Более надежно округлять ошибки и присутствие выбросов в распределении яркости изображения по сравнению с усредненной гистограммой. Гистограмма пересечения соответствует вычислению минимального значения счетчика для каждой ячейки совокупности кадров или изображений, чтобы получить цветовые характеристики "наименьшего общего" группы изображений. Заметим, что это отличается от гистограммы пересечения, которая является скалярной мерой. Аналогичные меры сходства/различия, которые используются для сравнения масштабируемых цветовых описаний, могут быть применены для сопоставления цветовых дескрипторов GoF/GoP.

    3.4.3. Описатели текстуры

    Существует три текстурных дескриптора: Edge Histogram, Homogeneous Texture и Texture Browsing.

    3.4.3.1. Описатели однородной текстуры

    Однородная текстура представляет собой важный визуальный примитив для поиска и просмотра большой коллекции выглядящих сходно образов. Изображение может рассматриваться как мозаика однородных текстур, так что эти текстурные характеристики, соответствующие областям могут использоваться для индексации визуальных данных. Например, пользователь, просматривающий абстрактную базу данных изображений, может захотеть идентифицировать различные блоки в этой коллекции изображений. Блоки с автомашинами, запаркованными регулярным образом являются хорошим примером однородного текстурного образца, рассматриваемого с большого расстояния, как это происходит при аэросъемке. Аналогично, сельскохозяйственные области и участки растительности являются другим примером однородных текстур, встречающихся при аэро и спутниковых наблюдениях. Примеры запросов, которые могут поддерживаться в этом контексте, могут включать в себя "Поиск всех спутниковых изображений Санта Барбары, которые имеют меньше чем 20% облачного покрытия" или "Найти растительный участок, который выглядит как эта область". Чтобы поддерживать такой поиск изображений, необходимо эффективное представление текстуры. Дескриптор однородной текстуры предоставляет количественное представление, используя 62 числа (по 8 бит каждое), которое удобно для поиска сходства. Получение данных осуществляется следующим образом; изображение сначала обрабатывается посредством набора фильтров Габора, настроенных на определенные ориентации и масштаб (смоделированные с помощью функций Габора). Дескриптор однородной текстуры предоставляет точное количественное описание текстуры, которое может использоваться для поиска. Вычисление этого дескриптора базируется на фильтрации.

    3.4.3.2. Просмотр текстуры

    Дескриптор просмотра текстуры (Texture Browsing) полезен для представления однородной текстуры в приложениях, служащих для просмотра, и требует только 12 бит (максимум). Он предоставляет перцептуальную характеристику текстуры, аналогично человеческому описанию в терминах регулярности, шероховатости, ориентированности. Вычисление этого дескриптора осуществляется также как и дескриптора однородной текстуры. Сначала, изображение фильтруется с помощью набора специально настроенных фильтров (смоделированных посредством функций Габора); в отфильтрованном результате идентифицируются два доминантных ориентаций текстуры. Три бита используются для представления каждой из доминантных ориентаций. За этим следует анализ проекций отфильтрованного изображения вдоль доминантных направлений, чтобы определить регулярность (характеризуемую двумя битами) и загрубленность (2 бита x 2). Этот дескриптор совместно с дескриптором однородной текстуры предоставляет масштабируемое решение для представления областей изображения с однородной текстурой.

    3.4.3.3. Краевая гистограмма

    Дескриптор краевой гистограммы представляет пространственное распределение пяти типов краев, в частности четырех ориентированных краев и одного неориентированного. Так как края играют важную роль для восприятия изображения, данный дескриптор помогает найти изображения со сходным семантическим значением. Таким образом, он изначально ориентирован на сравнение изображений (по образцам или наброскам), в особенности на естественные изображения с нерегулярными краями. В этом контексте, свойства системы поиска изображения могут быть существенно улучшены, если дескриптор краевой гистограммы комбинируется с другими дескрипторами, такими как дескриптор цветовой гистограммы. Кроме того, наилучшие характеристики системы поиска изображения, учитывая только этот дескриптор, достигаются путем использования полу-глобальных и глобальных гистограмм, получаемых непосредственно из дескриптора краевых гистограмм.

    3.4.4. Описатели формы

    Существует четыре типа дескрипторов формы: объектная форма, базирующаяся на областях, форма, базирующаяся на контурах, 3D-форма и 2D-3D множественные проекции.

    3.4.4.1. Форма, базирующаяся на областях (Region-Based)

    Форма объекта может состоять из одной области или набора областей, а также некоторых отверстий в объектах, как это показано на рис 9. Так как дескриптор формы, базирующейся на областях, использует все пиксели, определяющие форму в пределах кадра, он может описывать любую форму, то есть не только простые формы с односвязными областями, как на рис. 9 (a) и (b), но также сложные формы, которые содержат отверстия или несколько не соединенных областей, как показано на рис. 9 (c), (d) и (e), соответственно. Дескриптор формы, базирующейся на областях, может не только эффективно описать столь несхожие формы, но и минимизировать искажения на границах объекта.

    На рис. 9 (g), (h) и (i) показаны очень схожие изображения чашки. Различия имеются только в форме ручки. Форма (g) имеет трещину на нижней части ручки, в то время как в (i) ручка не имеет отверстия. Дескриптор формы, базирующейся на областях, рассматривает (g) и (h) подобными, но отличными от (i), так как там ручка не имеет отверстия. Аналогично, на рис. 9(j-l) показана часть видео последовательности, где два диска постепенно разделяются. С точки зрения дескриптора формы, базирующейся на областях, эти картинки схожи.

    Рис. 9. Примеры различной формы

    Заметим, что черный пиксель в пределах объекта соответствует 1 на изображении, в то время как пиксели белого фона соответствуют 0.

    Дескриптор характеризуется малым размером и быстрым временем поиска. Размер данных для представления является фиксированным и равным 17.5 байт.

    3.4.4.2. Форма, основанная на контуре

    Дескриптор формы, базирующейся на контуре, получает параметры формы объекта или его контур, извлеченный из описания областей. Он использует так называемое Curvature Scale-Space представление, которое воспринимает значимые параметры формы.

    Дескриптор формы, базирующейся на контуре объекта, использует Curvature Scale Space представление контура. Это представление имеет несколько важных особенностей, в частности:

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

    Некоторые из выше перечисленных свойств проиллюстрированы на рис. 10, каждый кадр содержит весьма сходные с точки зрения CSS изображения, основанные на результате действительного поиска в базе данных MPEG-7.

    Рис. 10.

    На рис. 10 (a) продемонстрированы свойства обобщения формы (внешнее сходство различных форм), (b) устойчивость по отношению к плавному движению (бегущий человек), (c) устойчивость к частичному перекрытию (хвосты или ноги лошадей)

    3.4.4.3. 3D-форма

    Рассматривая непрерывное развитие мультимедийных технологий, виртуальных миров, 3D-материал становится обычным для современных информационных систем. В большинстве случаев, 3D-информация представляется в виде сетки многоугольников. Группа MPEG-4, в рамках подгруппы SNHC, разрабатывала технологии для эффективного кодирования модели 3D-сеток. В стандарте MPEG-7 необходимы средства для интеллектуального доступа к 3D-информации. Главные приложения MPEG-7 имеют целью поиск, получение и просмотр баз 3D-данных.

    Предлагаемый дескриптор 3D-формы имеет целью предоставление внутреннего описания формы сеточных 3D-моделей. Он использует некоторые локальные атрибуты 3D-поверхности.

    3.4.5. Дескрипторы перемещения

    Существует четыре дескриптора перемещения: перемещение камеры, траектория перемещение объекта, параметрическое движение объекта и двигательная активность.

    3.4.5.1. Движение камеры

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

    Дескриптор движения камеры поддерживает следующие стандартные операции с камерой (см. рис. 11): фиксированное положение, панорамное движение (горизонтальное вращение), слежение за движущимся объектом (горизонтальное поперечное перемещение), вертикальное вращение, вертикальное поперечное перемещение, изменение фокусного расстояния, наезд (трансфокация вдоль оптической оси) и вращение вокруг оптической оси.

    Рис. 11. Перемещения камеры

    Отрывок, для которого все кадры характеризуются определенным типом перемещения камеры, относящееся к одному виду или нескольким, определяет базовые модули для дескриптора перемещения камеры. Каждый составляющий блок описывает начальный момент, длительность, скорость перемещения изображения и увеличение фокусного расстояния (FOE) (или сокращение фокусного расстояния - FOC). Дескриптор представляет объединение этих составляющих блоков, он имеет опцию описания смеси типов перемещения камеры. Смешанный режим воспринимает глобальную информацию о параметрах перемещения камеры, игнорируя детальные временные данные, путем совместного описания нескольких типов движения, даже если эти типы перемещения осуществляются одновременно. С другой стороны, несмешанный режим воспринимает понятие чистых перемещений и их совмещения на протяжении определенного временного интервала. Ситуации, когда одновременно реализуется несколько типов перемещений, описывается, как суперпозиция описаний чистых независимых типов перемещения. В этом режиме описания, временное окно конкретного элементарного сегмента может перекрываться с временным окном другого элементарного сегмента.

    3.4.5.2. Траектория движения

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

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

    Дескриптор является списком ключевых точек (x,y,z,t) вместе с набором опционных интерполирующих функций, которые описывают путь объекта между ключевыми точками, в терминах ускорения. Скорость неявно известна с помощью спецификации ключевых точек. Ключевые точки специфицируются путем задания моментов времени или их 2-D или 3-D декартовых координат, в зависимости от приложения. Интерполирующие функции определены для каждого компонента x(t), y(t) и z(t) независимо. Некоторые свойства этого представления перечислены ниже:

    • оно не зависит от пространственно-временного разрешения материала (например, 24 Hz, 30 Hz, 50 Hz, CIF, SIF, SD, HD, и т.д.), то есть если материал существует во многих форматах одновременно, для описания траектории объекта необходим только один набор дескрипторов данного материала.

    • оно компактно и масштабируемое. Вместо запоминания координаты объекта для каждого кадра, гранулярность дескриптора выбирается на основе ряда ключевых точек, используемых для каждого из временных интервалов.

    • оно непосредственно допускает широкое разнообразие применений, типа поиска подобия, или категорирование по скорости (быстрые, медленные объекты), поведению (ускоряется, когда приближается к этой области) или по другим характеристикам движения высокого уровня.

    3.4.5.3. Параметрическое движение

    Модели параметрического движения были использованы в рамках различных схем анализа и обработки изображения, включая сегментацию перемещения, оценки глобального перемещения, и отслеживание объектов. Модели параметрического перемещения использовались уже в MPEG-4, для оценки перемещения и компенсации. В контексте MPEG-7, перемещение является крайне важной характеристикой, связанный с пространственно-временной структурой видео, относящейся к нескольким специфическим MPEG-7 приложениям, таким как запоминание и поиск в видео базах данных, и для целей анализа гиперсвязей. Движение является также критической характеристикой для некоторых специфических приложений, которые уже рассматривались в рамках MPEG-7.

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

    Параметрическая модель ассоциирована с произвольными фоновыми объектами или объектами переднего плана, определенными как области (группа пикселей) в изображении в пределах заданного интервала времени. Таким способом, движение объекта записывается компактным образом в виде набора из нескольких параметров. Такой подход ведет к очень эффективному описанию нескольких типов перемещения, включая простые преобразования, вращения и изменения масштаба, или более сложные перемещения, такие как комбинации перечисленных выше элементарных перемещений.

    Определение подобия характеристик моделей движения является обязательным для эффективного поиска объектов. Оно также необходимо для поддержки запросов нижнего уровня, полезно и в запросах верхнего уровня, таких как "поиск объектов приближающихся к камере ", или для "объектов, описывающих вращательное движение", или "поиск объектов, перемещающихся влево", и т.д.

    3.4.5.4. Двигательная активность

    Просмотр человеком видео или анимационной последовательности воспринимается как медленная последовательность, быстро протекающий процесс, последовательность действий и т.д. Дескриптор активности воспринимает интуитивное понятие 'интенсивность действия' или 'темп действий' в видео сегменте. Примеры высокой 'активности' включают такие сцены, как 'ведение счета голов в футбольном матче', 'автомобильные гонки' и т.д. С другой стороны сцены, типа 'чтение новостей', 'интервью', 'снимок' и т.д. воспринимаются как кадры низкой активности. Видео материал охватывает диапазон от низкой до высокой активности, следовательно нам нужен дескриптор, который позволяет нам точно выражать активность данной видео последовательности/снимка и всесторонне перекрывать упомянутый выше диапазон. Дескриптор активности полезен для приложений, таких как видео наблюдение, быстрый просмотр, динамическое видео резюмирование, информационные запросы и т.д. Например, мы можем замедлить темп презентации кадров, если дескриптор активности указывает на высокую активность, так чтобы облегчить просмотр этой активности. Другим примером приложения является нахождения всех кадров высокой активности в новой видео программе, которая может рассматриваться как просмотр, так и абстракцию.

    3.4.6. Локализация
    3.4.6.1. Локатор области

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

    3.4.6.2. Пространственно-временной локатор

    Локатор описывает пространственно-временные области в видео последовательности, такой как области движущихся объектов, и обеспечивает функцию локализации. Главным его приложением является гипермедиа, где выделенная точка находится внутри объекта. Другим ведущим приложением является поиск объектов путем проверки, прошел ли объект определенные точки. Это может использоваться для наблюдения. Дескриптор SpatioTemporalLocator может описывать как связанные, так и несвязанные области.

    Рис. 12. Пространственно-временная область

    3.4.7. Прочие
    3.4.7.1. Распознавание лица

    Дескриптор FaceRecognition может использоваться для получения изображения лиц, которые соответствуют запросу. Дескриптор представляет проекцию вектора лица на набор базовых векторов, которые охватывают пространство возможных векторов лица. Набор параметров FaceRecognition получается из нормализованного изображения лица. Это нормализованное изображения лица содержит 56 строк с 46 значениями уровня в каждой строке. Центры двух глаз на каждом изображении лица размещаются на 24-ом ряду и 16-ой и 31-ой колонке для правого и левого глаз соответственно. Это нормализованное изображение затем используется для получения одномерного вектора лица, который состоит из значений яркости пикселей нормализованного изображения лица, которое получается в результате растрового сканирования, начинающегося в верхнем левом углу и завершающегося в нижнем правом углу изображения. Набор параметров FaceRecogniton вычисляется путем проектирования одномерного вектора лица на пространство, определяемое набором базисных векторов.

    3.5. Схемы описания мультимедиа MPEG-7

    Дескрипторы MPEG-7 сконструированы для описания следующих типов информации: низкоуровневые аудио-визуальные характеристики, такие как цвет, текстура, движение, уровень звука и т.д.; высокоуровневые семантические объекты, события и абстрактные принципы; процессы управления материалом; информация о системе памяти и т.д. Ожидается, что большинство дескрипторов, соответствующих низкоуровневым характеристикам будут извлекаться автоматически, в то время как человеческое вмешательство будет необходимо для формирования высокоуровневых дескрипторов.

    MPEG-7 DS преобразуются в дескрипторы путем комбинирования индивидуальных дескрипторов а также других DS в рамках более сложных структур и определения соотношения составляющих дескрипторов и DS. В MPEG-7 DS категорируются в отношении к аудио или видео областям, или по отношению к описанию мультимедиа. Например, характерные DS соответствуют неизменным метаданным, связанным с формированием, производством, использованием и управлением мультимедиа, а также описанием материала. Обычно мультимедийные DS относятся ко всем типам мультимедиа, в частности к аудио, видео и текстовым данным, в то время как специфичные для области дескрипторы, такие как цвет, текстура, форма, мелодия и т.д., относятся исключительно к аудио или видео областям. Как в случае дескрипторов, реализация DS может в некоторых вариантах базироваться на автоматических средствах, но часто требует вмешательства человека.

    3.5.1. Средства организации MDS

    На рис. 13 представлена схема организации мультимедийных DS MPEG-7 в следующих областях: базовые элементы, описание материала, управление материалом, организация материала, навигация и доступ, взаимодействие с пользователем.

    Рис. 13. Обзор мультимедийных DS MPEG-7

    3.5.1.1. Базовые элементы

    Спецификация мультимедийных DS MPEG-7 определяет определенное число схемных средств, которые облегчают формирование и выкладку описаний MPEG-7. Схемные средства состоят из корневого элемента, элементов верхнего уровня и средств выкладки (Package Tools). Корневые элементы, которые являются начальными элементами описания MPEG-7, позволяют сформировать полные XML-документы и фрагменты описания MPEG-7. Элементы верхнего уровня, которые позволяют корневым элементам в описании MPEG-7 организовать DS для объектно-ориентированных задач описания, таких как описание изображения, видео, аудио или аудио-визуальный материал, собрания (коллекции), пользователи или семантики мира. Созданы пакетные средства для группирования или ассоциации связанных компонентов DS описаний в каталоги или пакеты. Пакеты полезны для организационных и передающих структур и типов описательной информации MPEG-7 для систем поиска и для помощи при просмотре пользователям, незнакомым с особенностями описаний MPEG-7.

    Спецификация мультимедийных DS MPEG-7 определяет также некоторое число базовых элементов, которые используются повторно в качестве фундаментальной конструкции при определении MPEG-7 DS. Многие базовые элементы предоставляют специфические типы данных и математические структуры, такие как вектора и матрицы, которые важны для описания аудио-визуального материала. Они включаются также в качестве элементов для связи медиа файлов и локализации сегментов, областей и т.д. Многие базовые элементы предназначены для специальных нужд описания аудио-визуального материала, таких как описание времени, мест, людей, индивидуальностей, групп, организаций, и других текстовых аннотаций. Из-за их важности для описания аудио-визуального материала, давайте очертим подходы MPEG-7 к описанию временной информации и текстовых аннотаций:

    • Временная информация: DS для описания времени базируется на стандарте ISO 8601, который был воспринят схемным языком XML. Временные DS предоставляют временную информацию в медиа-потоки и для реального мира. MPEG-7 расширяет спецификацию времени ISO 8601 для того, чтобы описать время в терминах стробирования аудио-визуального материала, например, путем подсчета периодов стробирования. Это позволяет поддержать эффективное описание временной информации в больших массивах аудио-визуального материала.

    • Текстовая аннотация: текстовая аннотация является также важным компонентом многих DS. MPEG-7 предоставляет некоторое число базовых конструкций для текстового аннотирования, включая свободный текст (слова, фразы), структурированный текст (текст плюс назначение слов) и зависимая структурированная аннотация (структурированный текст плюс взаимные связи), для того, чтобы поддерживать широкий диапазон функций текстовых описаний.

    3.5.1.2. Управление содержимым

    MPEG-7 предоставляет также DS для управления материалом. Эти элементы описывают различные аспекты создания медиа материала, медиа кодирование, запись, форматы файлов и использование материала. Функциональность каждого из этих классов DS представлена ниже [5]:

    • Создание информации: описывает формирование аудио-визуального материала. Эта информация описывает создание и классификацию аудио-визуального материала и других данных, которые с ним связаны. Информация формирования выдает заголовок (который может быть текстовым или фрагментом аудио-визуального материала), текстовую аннотацию, а также данные о создателях, месте формирования и дате. Классификационная информация описывает, как аудио-визуальный материал классифицируется в таких категориях как жанр, тема, цель, язык и т.д. Она предоставляет также обзор и управляющую информацию, такую как классификация по возрасту, тематический обзор, рекомендации создателей и т.д.. Наконец, информация, сопряженная с материалом, описывает, существует ли другой материал, который связан тематически с данным материалом.

    • Использование информации: описывает информацию об использовании аудио-визуального материала, такую как права использования, доступность, записи об использовании и финансовая информация. Правовая информация не включается в описание MPEG-7, вместо этого, предлагаются ссылки на владельцев прав и другие данные, относящиеся к защите авторских прав. Правовые DS предоставляют эти ссылки в форме уникальных идентификаторов, которые управляются извне. Базовая стратегия описаний MPEG-7 заключается в предоставлении доступа к текущей информации о владельце без возможности непосредственного обсуждения возможных условий доступа к самому материалу. DS доступности и DS записей об использовании предоставляют данные, относящиеся, соответственно к доступности и прошлому использованию материала, такому как широковещательная демонстрация, доставка по требованию, продажа CD и т.д. Наконец, финансовые DS предоставляют информацию, связанную со стоимостью производства и доходами, которые могут результатом использования материала. Информация использования является обычно динамической, меняющейся за время жизни аудио-визуального материала.

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

    3.5.1.3. Описание содержимого

    MPEG-7 предоставляет также DS для описания материала. Эти элементы описывают структуру (области, видео кадры и аудио сегменты) и семантику (объекты, события, абстрактные понятия). Функциональность каждого из классов DS представлена ниже:

    • Структурные аспекты. DS описывает аудио-визуальный материал с точки зрения его структуры. Структурные DS формируются на основе DS сегментов, которые представляют пространственную, временную или пространственно-временную структуру аудио-визуального материала. Для получения оглавления или индекса для поиска аудио-визуального материала DS сегменты могут быть организованы в иерархические структуры. Сегменты могут быть описаны на основе характеристик восприятия с помощью дескрипторов MPEG-7 для цвета, текстуры, формы, движения, аудио параметров и т.д.

    • Концептуальные аспекты. DS описывает аудио-визуальный материал с точки зрения семантики реального мира и концептуальных представлений. DS семантики включают в себя такие характеристики как объекты, события, абстрактные концепции и отношения. DS структуры и DS семантики имеют отношение к набору связей, который позволяет описать аудио-визуальный материал на основе его структуры и семантики.

    3.5.1.4. Навигация и доступ

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

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

    • Разделы и декомпозиции описывают различные составляющие аудио-визуального сигнала в пространстве, времени и частоте. Разделы и декомпозиции могут использоваться для описания различных проекций аудио-визуальных данных, которые важны для доступа с разным разрешением.

    • Вариации предоставляют информацию о различных вариантах аудио-визуальных программ, таких как резюме и аннотации; масштабируемые, сжатые версии и варианты с низким разрешением; а также версии на различных языках- звук, видео, изображение, текст и т.д. Одной из важных возможностей, обеспечиваемых DS вариации, является выбор наиболее удобной версии аудио-визуальной программы, которая может заменить оригинал, если необходимо, адаптироваться к различным возможностям терминального оборудования, сетевым условиям или предпочтениям пользователя.

    3.5.1.5. Организация содержимого

    MPEG-7 предоставляет также DS для организации и моделирования собрания аудио-визуального материала, а также его описания. DS собрания организует коллекцию аудио-визуального материала, сегментов, событий, и/или объектов. Это позволяет описать каждое собрание как целое на основе общих характеристик. В частности, для описания значений атрибутов собрания могут быть специфицированы различные модели и статистики.

    3.5.1.6. Интеракция с пользователем

    Наконец, последний набор DS MPEG-7 имеет отношение к взаимодействию с пользователем. DS взаимодействия с пользователем описывает предпочтения пользователя и историю использования мультимедийного материала. Это позволяет, например, найти соответствие между предпочтениями пользователя и описаниями аудио-визуального материала, для того чтобы облегчить индивидуальный доступ к аудио-визуальному материалу, презентации и пр.

    3.5.2. Управление содержимым

    Средства управления описанием материала позволяют охарактеризовать жизненный цикл материала.

    Материал, охарактеризованный описаниями MPEG-7, может быть доступным в различных форматах и режимах, с разными схемами кодирования. Например, концерт может быть записан в двух разных режимах: звуковом и аудио-визуальном. Каждый из этих режимов может использовать различное кодирование. Это создает несколько медиа профайлов. Наконец, могут быть получены несколько копий одного и того же материала. Эти принципы режимов и профайлов проиллюстрированы на рис 14.

    Рис. 14. Модель материала, профайла и копии

    • Материал. Реальное событие, такое как концерт может быть представлено различными типами медиа-материала, например, звуковой материал, аудио-визуальный материал. Материал является объектом, который имеет специфическую структуру для отображения реальности.

    • Медиа информация. Физический формат материала описывается DS медиа информации. Одна копия описания DS будет ассоциирована с одним материалом.

    • Медиа профайл. Один объект может иметь один или более профайлов, которые соответствуют различным схемам кодирования. Один из профайлов является оригинальным, он называется мастерным профайлом, который соответствует первоначально созданному или записанному материалу. Другие будут получаться перекодированием из мастерного. Если материал закодирован тем же кодирующим средством, но с другими параметрами, формируется другой медиа-профайл.

    • Медиа копия. Медиа-объект может быть поставлен в соответствие физическому объекту, называемому медиа-копией. Медиа-копия специфицируется идентификатором или локатором.>

    • CreationInformation. Информация о процессе формирования материала описывается DS CreationInformation. Одна копия описания DS будет ассоциирована с одним материалом.

    • UsageInformation. Информация об использовании материала описывается DS UsageInformation. Одна копия описания DS будет ассоциирована с одним материалом.

    Единственной частью описания, которая зависит от среды записи или формата кодирования является MediaInformation, описанная в этом разделе. Остальная часть описания MPEG-7 не зависит от профайлов или копий и, как следствие, может использоваться, чтобы описать все возможные копии материала.

    3.5.2.1. Средства описания среды

    Описание среды включает в себя один элемент верхнего уровня, DS MediaInformation. Оно состоит из опционного MediaIdentification D и одного или нескольких MediaProfile D

    Идентификация среды (Media Identification) D содержит средства описания, которые являются специфическими по отношению к идентификации аудио-визуального материала вне зависимости от имеющихся различных копий.

    Медиа-профайл D содержит различные средства описания, которые позволяют охарактеризовать один профайл аудио-визуального материала. Концепция профайла относится к различным вариациям, которые могут отклоняться от оригинала в зависимости от выбранного кодирования, формата записи и т.д. Профайл, соответствующий оригиналу или мастерной копии аудио-визуального материала, считается мастерным профайлом. Для каждого профайла может быть одна или более медиа-копии мастерного медиа-профайла. MediaProfile D состоит из:

    • MediaFormat D содержит средства описания, которые являются специфическими для формата кодирования медиа-профайла.

    • MediaInstance D содержит средства описания, которые идентифицируют и локализуют различные копии медиа-профайлов.

    • MediaTranscodingHints D содержит средства описания, которые специфицируют рекомендации по транскодированию для описываемого материала. Целью этого D (дескриптора) является улучшение качества и сокращение сложности транскодирующих приложений. Рекомендации по транскодированию могут использоваться в виде схем оценки кодирования с целью снижения вычислительной сложности.

    • MediaQuality D предоставляет информацию об уровне качества аудио или видео материала. Это может использоваться для представления как субъективной, так и объективной оценки качества.

    3.5.2.2. Создание и производство средств описания

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

    Описание формирования и производства материала содержит в качестве элемента верхнего уровня, DS CreationInformation, который состоит из одного Creation D, нуля или одного Classification D, и нуля или нескольких RelatedMaterial D.

    Creation D содержит средства описания, имеющие отношение к формированию материала, включая место, дату, действия, материалы, персонал (технический и творческий) и организации, участвовавшие в процессе.

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

    Related Material D содержит средства описания, имеющие отношение к дополнительной информации о аудио-визуальном материале, имеющемся в других материалах.

    3.5.2.3. Средства описания использования содержимого

    Средства описания информации об использовании материала предоставляют данные о процессе использования аудио-визуального материала.

    Описание данных об использовании обеспечивается посредством DS UsageInformation, который может включать один Rights D, нуль или один Financial D и нуль или несколько Availability D и UsageRecord D.

    Важно заметить, что описание DS UsageInformation предполагает добавление новых описаний, каждый раз, когда материал используется (например, DS UsageRecord, доход в Financial D), или когда имеются другие способы доступа к материалу (например, Availability D).

    • Rights D предоставляет доступ к информации о правах владельцев и правах доступа.

    • Financial D содержит информацию, относящуюся к издержкам и доходам от полученного аудио-визуального материала. Понятия частичных издержек и доходов позволяют классифицировать различные издержки и доходы, в зависимости от их типа. Итоговые издержки и доходы вычисляются приложением на основе указанных выше составляющих.

    • Availability D содержит средства описания, относящиеся к доступности использования материала.

    • DS UsageRecord содержит средства описания, относящиеся к прошлому использованию материала.


    3.5.3. Описание содержимого
    3.5.3.1. Описание структурных аспектов содержимого

    Основным элементом этой части описания является DS сегмента. Она относится к описанию физического и логического аспектов аудио-визуального материала. DS сегмента может использоваться для формирования сегментных деревьев. MPEG-7 специфицирует также DS графа, который позволяет представлять сложные взаимоотношения между сегментами. Она используется для описания пространственно-временных соотношений, между сегментами, которые не описаны структурами дерева.

    Сегмент представляет собой секцию аудио-визуального материала. DS сегмента является абстрактным классом (в смысле объектно-ориентированного программирования). Она имеет девять основных подклассов: DS мультимедийного сегмента, DS аудио-визуальной области, DS аудио-визуального сегмента, DS аудио сегмента, DS статической области, DS статической 3D-области, DS подвижной области, DS видео сегмента и DS электронной раскраски. Следовательно, она может иметь как пространственные, так и временные свойства. Временной сегмент может быть набором фрагментов аудио-визуальной последоватеьности, представленным DS аудио сегмента, набором кадров видео последовательности, представленным DS видео сегмента или комбинацией аудио и видео информации, охарактеризованной DS аудио-визуального сегмента. Пространственный сегмент может быть областью изображения или кадром в визуальной последовательности, представленным DS статической области для 2D-областей и DS статической области 3D для 3D-областей. Пространственно временной сегмент может соответствовать подвижной области в видеопоследовательности, представленной DS подвижной области или более сложной комбинацией визуального и аудио материала, представленного, например, DS аудио-визуальной области. InkSegment DS описывает временной интервал или сегмент электронной раскраски, который соответствует набору чернильных капель, выбрасываемых из сопла. Наконец, наиболее общим сегментом является DS мультимедийного сегмента, который описывает составные сегменты, образующие мультимедийную презентацию. DS сегмента является абстрактным и не может быть отображен сам по себе: он используется для определения общих свойств его подклассов. Любой сегмент может быть описан с помощью информации формирования, использования медийных данных и текстовой аннотации. Более того, сегмент может быть поделен на субсегменты с помощью DS декомпозиции сегмента.

    Сегмент не является обязательно связанным, он может быть составлен из нескольких несвязанных компонентов. Связность здесь относится как к пространственным, так и временным доменам. Временной сегмент (видео сегмент, аудио сегмент или аудио-визуальный сегмент) считается связанными, если он является непрерывной последовательностью видео кадров или аудио фрагментов. Пространственный сегмент (статическая область или статическая 3D-область) считается связанными, если он является группой связанных пикселей. Пространственно-временной сегмент (подвижная область или аудио-визуальная область) считается связанным в пространстве и времени, если временной сегмент, где он размещен является связанным, и, если каждый кадр, в него входящий, является пространственно связанным (заметим, что это не является классической связностью в 3D-пространстве).

    На рис. 16 проиллюстрированы несколько примеров временных или пространственных сегментов и их связности. Рис. 16a и 16b иллюстрируют временные и пространственные сегменты, содержащие один связный компонент. Рис. 16c и 16d иллюстрирует временной и пространственный сегменты, состоящие из трех связанных компонент. Заметим, что в последнем случае, дескрипторы и DS, привязанные к сегменту, являются глобальными по отношению к объединению связанных компонент, образующих сегмент. На этом уровне, невозможно индивидуально описать связанные компоненты сегмента. Если связанные компоненты должны быть описаны индивидуально, тогда сегмент разделяется покомпонентно.

    DS Сегмента является рекурсивным, то есть, он может быть поделен на субсегменты, и, таким образом, образовать древовидную структуру. Результирующее сегментное дерево используется для определения медиа-источника, временной и/или пространственной структуры аудио-визуального материала. Например, видео программа может быть временно преобразована в ряд сцен различного уровня, снимков, и микро-сегментов; оглавление может, таким образом, генерироваться на основе этой структуры. Подобные стратегии могут использоваться для пространственных и пространственно-временных сегментов.

    Рис. 15. Примеры разложения сегмента на компоненты: a) и b) Декомпозиции сегмента без зазоров и перекрытий; c) и d) Декомпозиции сегмента с зазорами и перекрытиями

    Сегмент может также разделен на составные части по медиа-источникам, таким как различным звуковым дорожкам или разным позициям видеокамер. Иерархическая декомпозиция полезна при формировании эффективных стратегий поиска (от глобального до локального). Она также позволяет описанию быть масштабируемым: сегмент может быть описан непосредственно с помощью его набора дескрипторов и DS, а может быть также описан набором дескрипторов и DS, которые относятся к его субсегментам. Заметим, что сегмент может быть разделен на субсегменты различного типа, например, видео сегмент может быть разложен движущиеся области, которые в свою очередь разлагаются на статические области.

    Так как это выполняется в пространственно-временном пространстве, декомпозиция должна описываться набором атрибутов, определяющих тип разложения: временное, пространственное или пространственно-временное. Более того, пространственная и временная подсекции могут располагаться с зазором или с перекрытием. Несколько примеров декомпозиций для временных сегментов описано на рис. 15. Рис. 15a и 15b описывают два примера декомпозиции без зазоров или перекрытий. В обоих случаях объединение дочерних объектов соответствует в точности временному продолжению родительского, даже если родитель сам не является связанным (смотри пример на рис. 15b). Рис. 15c демонстрирует пример декомпозиции с зазорами, но без перекрытий. Наконец, рис. 15d иллюстрирует более сложный случай, где родитель состоит из двух связанных компонентов и его декомпозиция создает три дочерних объекта: первый сам состоит из двух связанных компонентов, остальные два состоят из одного связанного компонента. Декомпозиция допускает зазоры и перекрытия. Заметим, что в любом случае декомпозиция означает, что объединение пространственно-временного пространства, определенного дочерними сегментами, включается в пространство, определенное его сегментом-предшественником (дочерние объекты содержатся в предшественниках).

    Рис. 16. Примеры сегментов: a) и b) сегменты состоят из одного связного компонента; c) и d) сегменты состоят из трех связанных компонентов

    Таблица 1. Примеры характеристик для описания сегмента

    Характеристика

    Видео
    сегмент

    Стационарная область

    Подвижная область

    Видио сегмент

      Время
      Форма
      Цвет
      Текстура
      Движение
      Движение камеры
      Мозаика
      Характеристики звука

    X
    .
    X
    .
    X
    X
    X
    .

    .
    X
    X
    X
    .
    .
    .
    .

    X
    X
    X
    .
    X
    .
    .
    X

    X
    .
    .
    .
    .
    .
    .
    X

    Как упомянуто выше, любой сегмент может быть описан с помощью данных формирования, информации об использовании, медиа-данных и текстовой аннотации. Однако специфические характеристики, зависящие от типа сегмента, также допускаются. Примеры специфических характеристик представлены в таблице 1. Большинство дескрипторов (D), соответствующих этим характеристикам может быть получено автоматически из исходного материала. Для этой цели в литературе описано большое число различных средств.

    Пример описания изображения представлен на рис. 17. Исходные изображения описаны как стационарные области, SR1, которые описаны с помощью данных формирования (заголовок, создатель), информации использования (авторские права), медийной информации (формат файла), а также текстовой аннотации (обобщающей свойства изображения), гистограмм цвета и дескриптора текстуры. Исходная область может быть в дальнейшем разложена на составные области. Для каждого шага декомпозиции, мы указываем, допустимы или нет зазоры и перекрытия. Дерево сегмента состоит из 8 стационарных областей (заметим, что SR8 является одиночным сегментом, составленным из двух связанных сегментов). Для каждой области, на рис. 17 показан тип характеристики, которая реализована. Заметим, что в иерархическом дереве не нужно дублировать информацию формирования, использования и пр., так как предполагается, что дочерние сегменты наследуют эти характеристики.

    Рис. 17. Примеры описания изображения с стационарными областями

    Описание структуры материала может выходить за рамки иерархического дерева. Хотя, иерархические структуры, такие как деревья, удобны при организации доступа, поиска и масштабируемого описания, они подразумевают ограничения, которые делают их неприемлемыми для некоторых приложений. В таких случаях DS графа сегмента не используется. Структура графа определяется набором узлов, представляющих сегменты, и набора ребер, определяющих отношения между узлами. Чтобы проиллюстрировать использование графов, рассмотрим пример, представленный на рис. 18.

    Рис. 18. Пример видео-сегмента и областей для графа, представленного на рис. 19.

    Этот пример демонстрирует момент футбольного матча. Определены два видео-сегмента, одна стационарная область и три движущиеся области. Граф, описывающий структуру материала, показан на рис. 19. Видео-сегмент: Обводка & удар включает в себя мяч, вратаря и игрока. Мяч остается рядом с игроком, движущимся к вратарю. Игрок появляется справа от вратаря Видео-сегмент гол включает в себя те же подвижные области плюс стационарную область ворота. В этой части последовательности, игрок находится слева от вратаря, а мяч движется к воротам. Этот очень простой пример иллюстрирует гибкость данного вида представления. Заметим, что это описание в основном представляется структурным, так как отношения, специфицированные ребрами графа, являются чисто физическими, а узлы, представляющие сегменты, которые являются объектами, определяемыми данными создания, информацией использования и медиа-данными, а также дескрипторами низкого уровня, такими как цвет, форма, движение. В семантически явном виде доступна только информация из текстовой аннотации (где могут быть специфицированы ключевые слова мяч, игрок или вратарь).

    Рис. 19. Пример графа сегмента

    3.5.3.2. Описание концептуальных аспектов содержимого

    Для некоторых приложений, подход, описанный выше, не приемлем, так как он выделяет структурные аспекты материала. Для приложений, где структура практически не используется, но где пользователь в основном интересуется семантикой материала, альтернативным подходом является семантический DS. В этом подходе, акцент делается не на сегментах, а на событиях, объектах, концепциях, месте, времени и абстракции.

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

    Как показано на рис. 20, DS SemanticBase описывает документальные сферы и семантические объекты. Кроме того, несколько специальных DS получается из DS SemanticBase, которые описывают специфические типы семантических объектов, таких как описательные сферы, объекты, объекты агента, события, место и время, например: Семантический DS описывает документальные сферы (narrative worlds - реальные миры), которые отображаются или сопряжены с аудио-визуальным материалом. Он может использоваться для описания шаблонов аудио-визуального материала. На практике, семантический DS служит для инкапсуляции описания документальной области. DS объекта описывает воспринимаемый или абстрактный объект. Воспринимаемый объект является сущностью, которая является реальностью, то есть, имеет временное и пространственное протяжение в описываемом мире (например, "Пианино Вани"). Абстрактный объект является результатом абстрагирования воспринимаемого объекта (например, "любое пианино"). Это абстрагирование генерирует шаблон объекта. DS AgentObject расширяет возможности DS объекта. Она описывает человека, организацию, группу людей, или персонализированные объекты (например, "говорящую чашку в анимационном кино"). DS события описывает воспринимаемое или абстрактное событие. Воспринимаемое событие является динамическим отношением, включающим один или более объектов, которые возникают во времени или пространстве описываемого мира (например, "Ваня играет на пианино"). Абстрактное событие является результатом абстрагирования воспринимаемых событий (например, "кто-то играет на пианино"). Эта абстракция позволяет сформировать шаблон события. DS концепции описывает семантическую сущность, которая не может быть описана, как обобщение или абстрагирование специфицированного объекта, события, временного интервала или состояния. Она представляет собой свойство или собрание свойств (например, "гармония" или "готовность"). Эта DS может относиться к среде непосредственно или к другой описываемой семантической сущности. DS SemanticState описывает один или более параметрических атрибута семантической сущности в данное время или в данной точке описываемого мира или в данной позиции среды (например, вес пианино равен 100 кг). Наконец, DS SemanticPlace и SemanticTime характеризуют соответственно место и время в описываемом мире.

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

    Рис. 20. Средства для описания концептуальных аспектов

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

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

    Стандартная абстракция является обобщением медиа-абстракции для описания общего класса семантических сущностей или описаний. Вообще, стандартная абстракция получается путем замещения конкретных объектов, событий или других семантических сущностей классами. Например, если "Ваня играет на пианино" заменяется на "человек играет на пианино", описание становится стандартной абстракцией. Стандартные абстракции могут быть рекурсивными, то есть определять абстракцию абстракций. Обычно стандартная абстракция предназначена для повторного использования или ориентирована на применение в качестве ссылки.

    Простой пример описания концептуальных аспектов показан на рис. 21. Описываемый мир включает в себя в данном случае Ваню Иванова играющего на фортепиано со своим учителем. Событие характеризуется семантическим описанием времени: "19:00 24-го апреля 2002", и семантикой места: "Консерватория". Описание включает одно событие: игра и четыре объекта: фортепьяно, Ваня Иванов, его учитель и абстрактное понятие музыканта. Последние три объекта принадлежат к классу агент.

    Рис. 21. Пример концептуальных аспектов описания.

    3.5.4. Навигация и доступ

    MPEG-7 предоставляет DS, которые облегчают навигацию и доступ к аудио-визуальному материалу путем спецификации резюме, обзоров, разделов и вариаций медиа-данных. DS резюме предоставляет аннотации аудио-визуального материала для того, чтобы обеспечить эффективный просмотр и навигацию в аудио-визуальных данных. Пространственно-частотная проекция дает возможность рассматривать аудио-визуальные данные в пространственно-частотной плоскости. DS вариации специфицируют отношения между различными вариантами аудио-визуального материала, которые позволяют адаптивный выбор различных копий материала при различных условиях доставки и для разных терминалов.

    3.5.4.1. Резюме

    Аудио-визуальные резюме предоставляют компактные аннотации аудио-визуального материала для облегчения обнаружения, просмотра, навигации, визуализации и озвучивания этого материала. DS резюме позволяет осуществлять навигацию в рамках аудио-визуального материала иерархическим или последовательным образом. Иерархическая декомпозиция резюме организует материал послойно, так что он на различных уровнях выдает различную детализацию (от грубой до подробной). Последовательные резюме предоставляет последовательности изображений или видео кадров, возможно синхронизованные с аудио и текстом, которые формируют слайд-демонстрации или аудио-визуальные наброски.

    • DS резюмирования. Резюме MPEG-7 делают возможным быстрый и эффективный просмотр и навигацию аудио-визуального материала путем передачи существенных составляющих этого материала. DS резюмирования содержит связи с аудио-визуальным материалом, включая сегменты и кадры. Данное описание резюмирования, терминального оборудования, такого как цифровая приставка к телевизору, могут иметь доступ к аудио-визуальному материалу, формируя резюме и отображая результат для последующего взаимодействия с пользователем. DS резюмирования допускает формирования нескольких резюме для одного и того же материала, которые могут быть созданы с разным уровнем детализации.

    • DS иерархического резюме. DS HierarchicalSummary организует резюме нескольких уровней, которые описывают аудио-визуальный материал с разной детализацией. Элементы иерархии специфицируются DS HighlightSummary и HighlightSegment. Иерархия имеет форму дерева, так как каждый элемент в иерархии кроме корневого имеет прародителя. Элементы иерархии могут опционно иметь дочерние элементы.

    • DS HighlightSummary и HighlightSegment. DS HierarchicalSummary сконструирован на основе базового представления временных сегментов AВ-данных, описанных HighlightSegments. Каждый HighlightSegment содержит указатели на AВ-материал, чтобы обеспечить доступ к ассоциированным ключевым видео- и аудио-клипам, к ключевым кадрам и ключевым звуковым составляющим, он может также содержать текстовую аннотацию, относящуюся к ключевым темам. Эти AВ-сегменты группируются в резюме, или рубрики, посредством схемы описания HighlightSummary.

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

    Рис. 22. Пример иерархического резюме видео записи футбольного матча, имеющего многоуровневую иерархию. Иерархическое резюме предполагает достоверность (то есть, f0, f1, .) ключевых кадров с точки зрения видео сегмента следующего более низкого уровня.

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

    3.5.4.2. Разделы и декомпозиции

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

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

    • DS отображений описывают различные пространственные и частотные отображения аудио-визуальных данных. Определены следующие DS отображения: DS SpaceView описывает пространственное отображение аудио-визуальных данных, например, пространственный сегмент изображения. DS FrequencyView описывает отображение в пределах заданного частотного диапазона, например, частотный субдиапазон звукового сопровождения. DS SpaceFrequencyView специфицирует многомерное отображение аудио-визуальных данных одновременно в пространстве и по частоте, например, частотный субдиапазон пространственного диапазона изображения. DS ResolutionView специфицирует отображение с низким разрешением, такое как набросок изображения. Концептуально, отображение разрешения является частным случаем частотного отображения, которое соответствует низкочастотному субдиапазону данных. DS SpaceResolutionView специфицирует отображение одновременно в пространстве и по разрешению, например, отображение изображения пространственного сегмента с низким разрешением.

    • DS декомпозиции проекции описывают различные пространственные и частотные декомпозиции и организацию отображения аудио-визуальных данных. Определены следующие DS декомпозиции проекций: DS ViewSet описывает набор проекций, который может иметь различные свойства полноты и избыточности, например, набор субдиапазонов, полученный при частотной декомпозиции аудио сигнала, образующего ViewSet. DS SpaceTree описывает дерево декомпозиции данных, например, пространственная декомпозиция квадрантов изображения. DS FrequencyTree описывает частотную декомпозицию данных, например, волновую декомпозицию изображения DS. SpaceFrequencyGraph описывает декомпозицию данных одновременно в пространстве и по частоте. Здесь отображение использует частотный и пространственный графы. Граф видео отображения специфицирует декомпозицию видео данных в пространстве координата-время-частота, например, декомпозиция видео 3-D-субдиапазона. Наконец, MultiResolutionPyramid специфицирует иерархию проекций аудио-визуальных данных, например, пирамиду изображений с разным разрешением.

    На рис. 23 приведен пример пространственно-частотного графа декомпозиции изображения. Структура пространственного и частотного графа включает элементы узлов, которые соответствуют различным пространственным и частотным проекциям изображения, состоящего из пространственных проекций (пространственные сегменты), частотных (частотные субдиапазоны), и пространственно-частотных (частотные субдиапазоны пространственных сегментов). Структура пространственного и частотного графа включает также элементы переходов, которые содержат анализ и синтез зависимостей между проекциями. Например, на рис. 23, "S" переходы указывают на пространственную декомпозицию, в то время как "F" переходы отмечают частотную или субдиапазонную декомпозицию.

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

    3.5.4.3. Вариации содержимого

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

    3.5.5. Организация содержимого

    MPEG-7 предоставляет DS для организации и моделирования коллекций аудио-визуального материала, сегментов, событий, и/или объектов, и описания их общих свойств. Коллекции могут быть далее описаны, используя различные модели и статистики для того, чтобы характеризовать атрибуты элементов коллекции.

    3.5.5.1. Собрания (Collections)

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

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

    Рис. 24. DS структуры коллекции описывает коллекции аудио-визуального материала, включая отношения (то есть, R AB, RBC, RAC) внутри и между кластерами коллекций

    3.5.5.2. Модели

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

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

    3.5.6. Взаимодействие с пользователями

    DS UserInteraction описывает предпочтения пользователей имеющих отношение к использованию AВ-материала, а также историю его использования. Описания АВ-материала в MPEG-7 может быть приведено в соответствие с описаниями предпочтений для того, чтобы выбрать и персонализовать АВ-материал для более эффективного доступа, презентации и использования. DS UserPreference описывает предпочтения для различных типов материала и моделей просмотра, включая зависимость от контекста в терминах времени и места. DS UserPreference описывает также вес относительной важности различных предпочтений, характеристики конфиденциальности предпочтений и будут ли предпочтения изменяться в процессе взаимодействия, агента с пользователем. DS UsageHistory описывает историю действий, предпринятых пользователем мультимедийной системы. Описания истории использования могут пересылаться между клиентами, их агентами, провайдерами материала и оборудованием, и могут быть в свою очередь использованы для определения предпочтений пользователей с учетом характера АВ-материала.

    3.6. Эталонные программы: экспериментальная модель
    3.6.1. Цели

    Программы XM являются основой для эталонных кодов стандарта MPEG-7. Они используют нормативные компоненты MPEG-7:

    • Дескрипторы (D),
    • Схемы описания (DS),
    • Схемы кодирования (Cs),
    • Язык описания определений DDL (description definition language)
    • Компоненты систем BiM.

    Кроме нормативных компонентов, симуляционной платформе необходимы также некоторые ненормативные компоненты, существенные для выполнения некоторых процедурных программ, выполняемых для нормативных информационных структур. Информационные структуры и процедурные программы образуют приложения. Для большинства D или DS существует как минимум одно приложение в программном пакете, позволяющее проверить функциональность каждого нормативного компонента. Приложения показывают также, как извлечь метаданные из медиа-материала, или как мета данные могут использоваться в простых приложениях. Следовательно, XM реализует только базовые типы элементарных приложений, а не приложения реального мира. Более того, программы XM имеют только интерфейс командной строки, который не позволяет какого-либо взаимодействия в процессе исполнения.

    Модули программного обеспечения XM разработаны так, что все они используют специфицированные интерфейсы. Это позволяет облегчить навигацию среди множества различных модулей для разных D и DS. С другой стороны, использование фиксированного интерфейса позволяет повторно использовать и объединять отдельные модули в большие приложения.

    3.6.2. Извлечение и приложения клиента

    В рамках программного обеспечения XM, приложения соотносятся с одним конкретным дескриптором или схемой описания. Так как стандартизовано много дескрипторов и схем описания (DS), существует также много приложений интегрированных в программный пакет. Приложения, которые формируют дескриптор (D) или схему описания (DS), которые они тестируют, называются приложениями выборки. С другой стороны, приложения, которые используют тестируемые D или DS (DUT), называются приложениями клиента. Извлекающие приложения нужны, если D или DS являются дескриптором низкого уровня, это означает, что описание может быть извлечено из мультимедийного материала автоматически. Для D или DS высокого уровня выборка не может быть реализована аналогично. Однако в большинстве случаев выборка может быть основана на предварительной информации. Это означает, что процесс выборки читает эти дополнительные данные помимо медийного материала, чтобы получить описания. Таким образом, набор мультимедийного материала расширяется путем добавления входных данных высокого уровня.

    3.6.3. Модульность XM-программ

    По умолчанию модули для всех D и DS скомпилированы так, чтобы создать один большой исполнимый модуль, который может затем вызвать приложение для индивидуального D или DS. Однако результирующий исполняемый модуль становится необыкновенно большим, из-за массы индивидуальных D и DS определяемых стандартом. Компиляция с целью получения исполняемого модуля может выдать файл размером более 100 Мбайт (в случае, если включен режим отладки). Следовательно, программное обеспечение MPEG-7 XM сконструировано так, чтобы поддерживать частичную компиляцию с использованием только одного D или DS. С другой стороны, во многих случаях желательно комбинировать субнаборы D или DS. Более того, комбинирование D и DS также необходимо, когда DS строится иерархически из других D и DS. При этом сценарии, не только важно обеспечить частичную компиляцию, но существенно сконструировать программу так, чтобы код можно было использовать повторно. Таким образом, все приложения построены из модулей. Среди этих модулей:

    • класс медийного декодера,
    • класс мультимедийных данных,
    • класс средства выборки (только для приложений выборки),
    • класс дескриптора,
    • класс схемы кодирования, и
    • класс средства поиска (только для приложений клиента).

    Чтобы увеличить возможность повторного использования, все эти классы используют специальные интерфейсы, независящие от D или DS, к которым они принадлежат. Таким образом, нужно, чтобы программу можно было использовать повторно, например, применить средство выборки D или DS для других D или DS без глубокого знания, как это делается в данном средстве. Это возможно, если только известно, как использовать интерфейс этого средства выборки. Модули, перечисленные выше, скомбинированы или соединены друг с другом так, чтобы образовать цепочку обработки. Это сделано в классах приложений, которые могут относиться к классам выборки или приложения клиента.

    3.6.4. Модули приложения
    3.6.4.1. Медийные декодеры

    Медиа-декодер (класс MediaIO) поддерживает широкий диапазон возможных входных медийных форматов. Среди них:

    • аудио данные в файлах WAV,
    • видео потокиMPEG-1,
    • векторы перемещения из видео потоков MPEG-1 (обрабатываемые как статическое изображение),
    • статические изображения (JPEG, GIF, PNM и многие другие),
    • список ключевых точек 4D (t,x,y,z),
    • список ключевых точек nD (t, x[0..n-1]), и
    • другие частные входные форматы для информации верхнего уровня

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

    • библиотека Afsp для аудио-файлов, и
    • ImageMagick для статических изображений.

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

    Так как класс MediaIO является интерфейсом для этих библиотек, использование внешних библиотек не нужно и не разрешено для любого другого класса программ XM, например, разрешающих аудио-экспертам использовать программы XM без специфичной для видео библиотеки ImageMagick.

    3.6.4.2. Мультимедийные данные

    Класс MultiMedia хранит загруженные медиа данные в памяти. Видео последовательности, не загружаются в память (в память могут заноситься лишь отдельные кадры).

    Для статических изображений XM использует сокращенную структуру данных MoMuSys Vop из модели верификации MPEG-4 (VM). Ключевые точки записываются в двухмерный связанный список, одно измерение для временных точек (один кадр) содержащих второе измерение, которое включает в себя все ключевые точки для этого кадра. Структура аудио-данных в данный момент не согласована, но будет доступна в ближайшем будущем.

    3.6.4.3. Средства выборки

    Средство выборки выполняет выборку из базы данных характеристики одного элемента мультимедиа. Процесс выборки не является нормативным средством в стандарте MPEG-7. Чтобы получить характеристику, средство выборки воспринимает ссылку на медиа-данные, являющиеся входными для данной операции, и в то же время ссылкой для описания, которое записывает результаты процесса выборки.

    Так как в случае обработки видео последовательности, невозможно предоставить все входные данные одновременно, выборка производится по-кадрово. Это означает, что имеется три функции, которые используются для реализации процедуры выборки:

    • InitExtracting, которое вызывается до обработки первого кадра,
    • StartExtracting, которое вызывается в цикле для всех кадров, чтобы извлечь часть описания, и
    • PostExtracting, которое вызывается после того, как все кадры обработаны. Это необходимо, если некоторая часть описания может быть сформирована после того, как все данные станут доступны (например, число кадров в последовательности).

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

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

    Средства выборки используются исключительно для получения данных из медиа среды прикладного типа. Как будет показано позднее, имеется возможность извлечь проверяемые D или DS из других данных описания. В этом случае, процесс выборки может быть реализован только через один функциональный вызов, то есть, без итеративных циклов с входными данными для каждой временной точки или периода.

    3.6.4.4. Класс дескрипторов

    Классы дескрипторов несут в себе описательные данные. В программах XM классы для каждого D или DS представляют непосредственно нормативную часть стандарта. Имеются также функции для элементов реализации описаний.

    В программах XM имеется два различных способа конструирования классов D или DS. В случае визуальных D, этот класс использует простой подход класса C++. Во всех других случаях этот класс реализуется с помощью общего модуля, который в XM называется GenericDS. Этот класс является интерфейсом между программами C++ XM и реализацией парсера DDL. Здесь используется XML парсер, предоставляющий DOM-API (Data Object Model - Application Programming Interface - прикладной программный интерфейс объектной модели данных). Следовательно, GenericDS является интерфейсом между XM и парсером DOM-API. Управление памятью для описательных данных выполняется посредством библиотеки парсера DOM. Оба подхода могут комбинироваться с помощью функций ImportDDL и ExportDLL реализованных классов дескриптора C++.

    3.6.4.5. Схема кодирования

    Схема кодирования включает в себя нормативный кодировщик и декодер для D или DS. В большинстве случаев схема кодирования определена только заданием схемы DDL. Здесь, кодирование представляет собой вывод описания в файл, а декодирование является разборкой (parsing) и загрузкой файла описания в память. Описание запоминается, с использованием класса GenericDS, который является оболочкой для DOM-API. Следовательно, мы можем использовать библиотеку парсера DOM-API для кодирования и декодирования. Эти функции встроены XM с помощью класса GenericDSCS (CS = схема кодирования). Помимо ASCII-представления XML-файла MPEG-7 стандартизует также двоичное представление описаний (BiM).

    Другим подходом является использование визуальной группы MPEG-7. Здесь, каждый D имеет также индивидуальное двоичное представление. Это позволяет специфицировать число бит, которое следует использовать для кодирования индивидуальных элементов описания. Примером может служить число бит, используемых для кодирования каждой ячейки гистограммы.

    3.6.4.6. Средство поиска

    В качестве средств извлечения и поиска используется ненормативное средство стандарта. Оно берет одно описание из базы данных и одно описание запроса, причем запрос может не соответствовать нормативам MPEG-7 D или DS. Средство поиска анализирует описание и обрабатывает нужные входные данные так, как это требуется для специфицированного приложения.

    Средства поиска используются во всех клиентских приложениях, которые являются приложениями поиска и доставки (search & retrieval) и приложениями медиа-транскодирования (media transcoding). В случае приложений поиска и доставки, средство поиска сравнивает два входных описания и вычисляет величину их отличия. Для приложения медиа-транскодирования обрабатываются медиа-данные, то есть, медийная информация модифицируется на основе описания и запроса. Так как медиа данные обрабатываются, средство поиска вызывается из приложения транскодирования.

    3.6.5. Типы приложений в XM-программах
    3.6.5.1. Извлечение из среды

    Выборка из медиа приложения относится к типам приложений выборки. Обычно, все D или DS низкого уровня должны иметь класс приложения этого типа. Как показано на рис. 25 это приложение извлекает тестируемые D/DS (DUT) из входных медиа данных. Сначала медиа файл загружается медиа-декодером в мультимедиа-класс, то есть, память. На следующем шагу с помощью средства выборки описание может быть извлечено из мультимедиа-класса. Затем описание проходит через кодировщик и закодированные данные записываются в файл. Этот процесс повторяется для всех мультимедийных файлов медийной базы данных.

    Рис. 25. Выборка для приложения медийного типа. Описание извлекается из входных медийных данных

    3.6.5.2. Приложение поиска и извлечения

    Приложение поиска и получения данных, показанное на рис. 26, относится к типу клиентского приложения. Сначала все описания базы данных, которые могут быть извлечены из медиа приложения, декодируются и загружаются в память. Из медиа данных с помощью средства выборки может быть извлечено и описание запроса. С другой стороны запрос может быть загружен непосредственно из файла. После получения всех входных данных, запрос обрабатывается для всех элементов базы данных, а результирующие расстояния (значения отличия) используются для сортировки данных согласно уровню соответствия запросу. Наконец, сортированный список записывается в качестве медиа базы данных в файл.

    Рис. 26. Поиск и выборка прикладного типа. Сортированная информация из медиа базы данных получается из описаний и запроса

    3.6.5.3. Приложение транскодирования среды

    Приложение медиа транскодирования также относится к клиентскому типу. Как показано на рис. 27, медиа файлы и их описания загружены. Основываясь на описаниях, медиа данные модифицируются (транскодируются), а новая медиа база данных записывается в файл. Более того, может быть специфицирован запрос, который обрабатывается для описаний до транскодирования.

    Рис. 27. Тип приложения медиа транскодирования. Из исходной DB создается транскодированная база данных, соответствующая описаниям и опционно запросу.

    3.6.5.4. Приложение описания фильтрации

    Приложение фильтрации описаний может относиться к типу выборки или клиента, в зависимости оттого сгенерирован или использован исследуемый дескриптор (DUT). В обоих случаях описания входной базы данных фильтруются на основе регламентаций запроса. Результирующие отфильтрованные описания записываются затем в выходные файлы.

    Рис. 28. Приложение фильтрации описаний

    3.6.6. Модель ключевого приложения MPEG-7
    3.6.6.1. Определение ключевых приложений

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

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

    3.6.6.2. Модель интерфейса

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

    Рис. 29. Интерфейсная модель ключевых приложений XM. Эта модель показывает супернабор возможных входов и выходов ключевого приложения XM.

    Помимо уже используемых выходов, предполагается, что будет также тип выхода, соответствующий входному запросу. На рис. 29 этот выход имеет название прочий выход. Возможными приложениями для этого могут быть уточняющие запросы, например, для просматривающих приложений. Однако использование этого выхода все еще не ясно и нуждается в дальнейших исследованиях.

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

    3.6.7. Ключевые приложения против приложений реального мира

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

    Рис. 30. Пример приложения реального мира, извлекающего два разных описания (XM-Appl1, XM-Appl2). Основываясь на первом описании выбран адекватный набор материала (XM-Appl3), который затем транскодирован с использованием второго описания (XM-Appl4). (MDB = медийная база данных, DDB = база данных описаний).

    На рис. 30 приведен пример приложения реального мира. Сначала, из медиа базы извлекаются два объекта. Затем, основываясь на первом объекте, из базы данных выбираются адекватные медиа файлы. Эти медиа файлы транскодируются с привлечением второго извлеченного объекта.

    Ссылки

    Имеется большое число документов на базовой странице MPEG http://drogo.cselt.it/mpeg/, включая:

    • Введение в MPEG-7
    • ТребованияMPEG-7
    • ПриложенияMPEG-7
    • КонцепцияMPEG-7
    • Документы MPEG-7 CD, WD и XM: системы, DDL, видео, аудио и MMDS.

    Информацию, имеющую отношение к промышленной сфере, можно найти на Web-сервере MPEG-7 http://www.mpeg-7.com (Industry Focus Group).

    Приложение А. Словарь и сокращения

    CD

    Committee Draft - проект комитета

    CE

    Cилиe Experiment - центральный эксперимент

    CS

    Coding Scheme - схема кодирования

    D

    Дескриптор

    DDL

    Data Description Language - Язык описания данных

    DS

    Description Scheme - Схема описания

    FCD

    Final Committee Draft - окончательный проект комитета

    FDIS

    Final Draft of International Standard - окончательный проект международного стандарта

    IS

    International Standard - Международный стандарт

    MMDS

    Multimedia Description Schemes - Схемы описания мультимедиа

    MPEG

    Moving Pictures Experts Group - Группа экспертов по движущимся изображениям

    WD

    Working Draft - рабочий проект

    XM

    eXperimentation Model - модель экспериментирования

    Previous: 2.5.1 Стандарт MPEG-4    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.6 Методы сжатия информации


    previous up down next index index
    Previous: 2.4.3 Передача голоса по каналам Интернет    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.5.1 Стандарт MPEG-4

    2.5 Методы преобразования и передачи изображения
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Передача изображения представляет собой наиболее тяжелую проблему, так как человеческий глаз с информационной точки зрения несравненно совершеннее уха.

    В 1902 году Артур Корн (Германия) запатентовал систему фотоэлектрического сканирования изображения, а в 1910 году заработала первая международная факсимильная связь Берлин-Париж-Лондон. До 60-х годов этого века рынок факсимильной аппаратуры был ограничен.

    В 1968 году CCITT разработала рекомендации по факсимильному оборудованию, которое было способно передавать страницу за 6 минут при разрешении 3.85 линий на мм. Позднее в 1976 году аналоговая факсимильная техника была улучшена. Это позволило сократить время передачи страницы до 3 минут. В 1980 году разработан стандарт для цифровых факс-машин (группа 3), здесь уже предусматривается сжатие информации, что позволяет сократить время передачи страницы до 1 мин при скорости передачи 4800 бит/с. Следует иметь в виду, что сжатие информации в сочетании с ошибками пересылки может приводить к неузнаваемости изображения локальному или полному. По этой причине число линий сканирования, которые используются при обработке изображения, с целью сжатия может варьироваться (1-4) и определяется в результате диалога между отправителем и получателем, а передача каждой скан-линии завершается довольно длинным кодом, предназначенным для надежного распознавания завершения строки сканирования, а также коррекции ошибок. Факсимильное оборудование группы 3 может и не обеспечивать сжатия передаваемых (принимаемых) данных. В 1984 году разработаны требования к факс-аппаратам группы 4. Система базируется на двухмерной системе кодирования изображения (MMR - Modified Modified Reed).

    Факсимильное оборудование поделено на 4 группы. Первая группа практически совпадает с традиционным фототелеграфным оборудованием (6 минут на страницу при разрешении 3.85 линий на миллиметр). Динамической вариации кодовой таблицы не предусмотрено. При этом для кодирования очередной линии сканирования используются результаты, полученные для предшествующей линии. Следует учитывать, что зона сканирования факс-машины больше размера изображения и всегда имеются пустые строки и поля, что предоставляет дополнительные возможности для сжатия передаваемой информации. Существует три режима кодирования: вертикальный, горизонтальный и проходной. Последний режим реализуется, когда позиция в эталонной строке a2 находится слева от b1 (см. рис. 2.5.1; вериткальному и горизонтальному режиму соответствует нижняя часть рисунка). При "вертикальном" режиме кодирования (a2 справа от b1 и |b1a1|<= 3) позиция b1 кодируется относительно позиции a1. Относительное положение b1a1 может принимать одно из семи значений V(0), VR(1), VR(2), VR(3), VL(1), vL(2) и VL(3) (см. табл. 2.5.1). Индексы r и l указывают на то, что b1 находится справа или слева по отношению к a1, а число в скобках обозначает расстояние b1a1. Если используется "горизонтальный" режим кодирования (a2 справа от b1 и |b1a1|>3), длины b0b1 и b1b2 отображаются с помощью кодовой комбинации H+M(b0b1)+M(b1b2). H представляет собой код 001, взятый из двумерной кодовой таблицы. M(b0b1) и M(b1b2) являются кодовыми словами, которые характеризуют длину и цвет субстрок b0b1 и b1b2 соответственно.

    Рис. 2.5.1. Режимы кодирования: проходной; вертикальный; горизонтальный

    Факс-оборудование группы 4 может поддерживать так называемый расширенный режим, когда часть рабочего поля кодируется без использования алгоритмов уплотнения информации (как правило, это участки, где попытка сжать либо ничего не дает, либо даже приводит к увеличению объема передаваемых данных). Оборудование этой группа использует на канальном уровне процедуры HDLC LAPB. Рекомендуемой полосой пропускания канала, к которому подключается такое оборудование, является 64 Кбит/с.

    Таблица 2.5.1. Кодирование элементов изображения

    Режим кодирования

    Элементы, подлежащие кодированию

    Обозначение

    Код

    Проход

    a1a2

    p

    0001

    Горизонтальный

    b0b1,b1b2

    h

    001+m(b0b1)+m(b1b2)

    Вертикальный

    b1 под a1 b1a1=0
    b1 справа от a1 b1a1=1
    b1a1=2
    b1a1=3
    b1 слева от a1 b1a1=1
    b1a1=2

    b1a1=3

    v(0)
    vr(1)
    vr(2)
    vr(3)
    vl(1)
    vl(2)
    vl(3).

    1
    011
    000011
    0000011
    010
    000010
    0000010
    0000001ххх

    Перед началом передачи терминалы должны обменяться своими идентификаторами (TID - terminal identification). В последнее время появились факс-аппараты, которые печатают изображение на обычную бумагу с разрешением 300-400 точек на дюйм. Такая схема удобна, но имеет некоторые недостатки. Такие аппараты дороги, печать может начаться не ранее, чем будет передана вся страница; передающий аппарат может иметь более низкое разрешение, нужно уметь адаптироваться к любому разрешению, что приводит к тому, что скорость печати изображения при низком разрешении остается столь же низкой, как и при высокой.

    В 1970 году в Бритиш Телеком были разработаны основные принципы еще одного вида передачи графической информации - телетекста, первые опыты по его внедрению относятся к 1979 году. Стандарт на мозаичное представление символов был принят CEPT в 1983 году. Каждому символу ставится в соответствие код длиной в 7-8 бит. На экране такой символ отображается с помощью специального знакового генератора, использующего таблицу.

    Полному экрану видео текста, содержащему 24 строки по 40 символов, соответствует 960 байт, для передачи которых по коммутируемой телефонной сети требуется 6,4 секунды. D-канал ISDN может пропустить эту информацию за 1 сек, а B-канал быстрее за 0,1 сек. Телетекст позволяет более эффективно использовать каналы связи и не налагает чрезмерных требований на устройства отображения.

    Известно, что для корректной передачи цвета требуется 16 миллионов оттенков (8 бит на каждую из трех цветовых компонент). Таким образом, для описания картинки на экране, содержащей 575 линий по 720 пикселей, требуется 1,240 Мбайта. Для передачи такой информации по B-каналу ISDN, если не используется сжатие, потребуется около 2,5 минут. Эта цифра помогает понять актуальность проблемы сжатия графической информации. При передаче чисто текстовой информации электронная почта имеет по этой причине абсолютное преимущество перед факсом. В перспективе можно ожидать внедрения сжатия информации при передаче почтовых сообщений с последующей дешифровкой данных принимающей стороной. Первым шагом на этом пути является внедрение системы MIME. Такое усовершенствование электронной почты сделает ее еще более грозным конкурентом факс-машин. Ведь передача графических образов уже не является монополией факсимильных систем, а возможность шифрования почтовых сообщений (например, в PGP) делает электронную почту более противостоящей перехвату. Таким образом, чтобы выдержать конкуренцию со стороны электронной почты разработчикам факс-систем нужно упорно работать.

    Стандарты для представления и передачи изображения разрабатывает Joint Photographic Expert Group (JPEG). Для сжатия графической информации в настоящее время используется дискретное косинусное двухмерное преобразование (DCT - Discrete Cosine Transform), которое дает субъективно наилучший результат и описывается уравнением:

    [2.5.1]

    где v - горизонтальная координата графического блока, u - вертикальная, x - вертикальная координата внутри блока, а y - горизонтальная координата внутри блока, C(u), C(v) = 1/ для u,v = 0 и С(u), С(v) = 1 в противном случае. Два члена в квадратных скобках являются ядрами преобразования, показанными ниже на рис. 2.5.2, а p(x,y) представляет собой пиксельные данные блока реального рисунка. Начало координат в обоих случаях в верхнем левом углу. Процесс кодирования сводится к разбиению изображения на блоки 8*8 пикселей и выполнению процедуры двухмерного DCT для каждого из этих блоков. Полученные коэффициенты преобразования дискретизируются. 64 числа, характеризующие уровень сигнала, превращаются в 64 коэффициента преобразования (амплитуды пространственных частот), которые хорошо поддаются процедуре сжатия. Дискретизатор округляет коэффициенты, эта процедура вносит некоторые ошибки, но обратное преобразование на принимающей стороне за счет усреднения частично устраняет вносимые искажения. На практике дискретизатор реализует несколько более сложный алгоритм.

    Интуитивно метод DCT базируется на выявлении того, насколько вышестоящий блок отличается от нижестоящего. Для реального представления (сжатия) коэффициентов преобразования здесь также используются коды Хафмана.

    Рис. 2.5.2. Графическое представление двухмерного преобразования по формуле [2.5.1]

    DCT обеспечивает сжатие на уровне 0.5-1.0 бит/пиксель при хорошем качестве изображения. Сжатие требует времени, а максимально приемлемым временем задержки при пересылке изображения является 5 секунд. На рис. 2.5.3 приведена качественная оценка четкости и соответствия оригиналу изображения в зависимости от величины сжатия (DCT). Если использовать скорость обмена 64 кбит/с, то степени сжатия 0,01 бита на пиксель будет соответствовать время передачи изображения 0,04 секунды, а сжатию 10 - время передачи 40сек.

    Рис. 2.5.3. Качество DCT-изображения для различных значений сжатия информации (картинка имеет разрешение 512*512 пикселей; заполненные квадратики соответствуют цветному изображению, а незаполненные - черно-белому)

    Отображение графического образа может выполняться последовательно (примерно так, как мы читаем текст: слева-направо и сверху-вниз) или с использованием прогрессивного кодирования (сначала передается вся картинка с низким разрешением, затем последовательно четкость изображения доводится до максимальной). Последний метод весьма удобен для систем WWW, где просмотрев изображение низкого разрешения, можно отменить передачу данных улучшающих четкость и тем самым сэкономить время. Хорошо распознаваемое изображение получается при сжатии порядка 0,1 бита на пиксель.

    Проблема сжатия и передачи движущегося изображения еще сложнее. Алгоритм кодирования такого изображения описан в рекомендациях CCITT H.261 и предполагает, что скорость передачи при этом лежит в интервале 40кбит/с - 2Мбит/с. Следует иметь в виду, что видео телефония и видеоконференции требуют синхронной передачи звука и изображения (стандарт H.221, например 46,4 Кбит/с для видео и 16 Кбит/с для звука). Нормальный формат телевидения имеет 625 и 525 строк развертки и частоту кадров 25-30 в секунду. Цветное телевидение использует сигналы R (red), G (green) и B (blue), причем яркость луча (y) определяется соотношением: Y = 0.30R + 0.59G + 0.11B (при отображении белого цвета). Информация о цветах определяется формулами: СB = B - Y и CR = R - Y. Зная величины y, CB и СR, можно восстановить значения R, G и B. При сжатии цветного изображения учитывается тот факт, что человеческий глаз извлекает большую часть информации из контуров предметов, а не из цветных деталей. Например в рекомендации CCIR 601 предлагается использовать полосу 13.5 Мгц для кодирования Y и только по 6.75 Мгц для СB и CR. Такая схема требует 216 Мбит/с, что в 3375 раза превышает возможности стандартного 64кбит/с B-канала ISDN. Приемлемыми решениями могут быть:

    1. снижение числа строк до 288 (формат 625 строк) для отображения яркости;
    2. использование максимально возможного сжатия графических данных;
    3. повышение пропускной способности канала. Для разрешение по горизонтали вполне достаточно 3 Мгц. Рекомендация 601 требует 720 пикселей для яркости и 360 для каждой из составляющих цветов. В настоящее время используется стандарт CIF (Common Intermediate Format). Для некоторых приложений рекомендовано вдвое более низкое разрешение по каждой из осей (quarter CIF). PCM-кодирование CIF с 8 битами на пиксель требует 352х288х(1+1/4+1/4)х29.97х8 = 36.5 Мбит/с.

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

    При пересылке движущегося изображения производится сравнение текущего кадра с предшествующим. Если кадры идентичны, никакого информационного обмена не происходит. Если кадры отличаются лишь смещением какого-то объекта, выявляются границы этого объекта, направление и величина вектора его перемещения. Так как использование индивидуальных векторов перемещения для каждого пикселя слишком расточительно, используется общий вектор для блока пикселей 16*16 по яркости и для соответствующего блока 8*8 по цвету. Точность задания вектора перемещения обычно лежит в пределах 1/2 пикселя (стандарт MPEG-2). Только эта информация и передается по каналу связи. Выявление движущихся объектов осуществляется путем вычитания изображения двух последовательных кадров. Если бы передавалась всегда только разница кадров, происходило бы накопление ошибок. Кроме того, как кодер, так и декодер содержат прямой и обратный DCT-преобразователь. Если комбинация прямого и обратного DCT-преобразования не приводит к получению исходного объекта, то такого рода эффекты могут заметно усилиться. Для исключения этого время от времени производится передача непосредственно видеосигнала. Практически преобразователь изображения представляет чудо современной технологии, которое даст работу еще не одному поколению математиков и инженеров.

    Нисколько не проще система передачи и мультиплексирования потока видео данных, который содержит помимо обычной информации описания формы движущихся объектов, векторы перемещения, коэффициенты дискретизации и многое другое. Схема передачи графической информации имеет 4-х уровневую, иерархическую структуру. Передача каждого кадра изображения начинается с 20-битного кода PSC (Picture Start Code, эта сигнатура позволяет выделить начало кадра изображения в общем потоке), далее следует 5-битовый код TR (Temporal Reference, временная метка, которая позволяет поместить соответствующую часть изображения в правильную точку экрана). Изображение пересылается частями, имеется 4 уровня: кадр, группа блоков GoB (Group of Blocks), макроблоки (MB) и просто блоки.

    Ядро всей структуры составляет процедура передачи кадра (внутренний слой, существуют еще слои GoB, MB и блока, см. рис. 2.5.4, 2.5.5, 2.5.6)

    Рис. 2.5.4. Схема передачи кадра изображения

    Поле Ptype содержит 6 бит, которые характеризуют формат изображения (используется ли формат CIF или QCIF). Однобитное поле PEI указывает на то, следует ли далее 8-битное поле PSpare (предназначено на будущее). Если PEI=0, начинается цикл передачи GoB. Группа блоков составляет одну двенадцатую картинки CIF или одну треть QCIF. GoB описывает Y (яркость), 176 пикселей для каждой из 48 строк и соответствующие 88*24 элементов для CB и CR.

    GBSC - (Group of Blocks Start Code) представляет собой 16-разрядное слово, за которым следует 4 бита номера GoB (GN - GoB number). GN указывает, какой части изображения соответствует данный GoB. Поле gquant имеет 5 бит и указывает на номер преобразователя (одного из 31 дискретизаторов), который используется данным GoB. Смысл GEI идентичен PEI. GEI и GSpare позволяют сформировать структуру данных, идентичную той, что используется на уровне кадра.

    Формат пересылки mb сложнее (см. [17]). Каждый GoB делится на 33 макроблока (MB), каждый из которых соответствует 16 строкам по 16 пикселей Y (четыре блока 8*8) и CB и CR. Каждый макроблок начинается с его адреса MBA (MacroBlock Address), имеющего переменную длину и определяющего положение макроблока в GoB.

    Рис. 2.5.5. Блок-схема кодирования и передачи изображения

    Макроблоки не передаются, если данная часть изображения не изменилась. За MBA следует код переменной длины Mtype, характеризующий формат макроблока (применен ли метод подвижного вектора MVD и т.д.) и последующую информацию. CBP (Coded Block Pattern) представляет собой кодовое слово переменной длины, которое несет в себе информацию о том, какой из шести блоков преобразования (8*8) содержит коэффициенты (слой блоков). CBP нужно не для всех типов макроблоков. Каждый блок завершается флагом EOB (End of Block).

    Рис. 2.5.6. Размещение блоков в макроблоках

    Сама природа алгоритма кодирования и передачи графических данных такова, что число бит передаваемых в единицу времени зависит от характера изображения. Чем динамичнее изменяется картинка, тем больше поток данных. Для выравнивания потока данных широко используется буферизация. Буферизация в свою очередь порождает дополнительные задержки, которые в случае видео-конференций или видео-телефонии не должны превышать нескольких сотен миллисекунд.

    Так как при передаче изображения широко используются коды переменной длины, она крайне уязвима для любых искажений. В случае ошибки будет испорчена вся информация вплоть до следующего стартового кода GoB. Из-за рекурсивности алгоритма формирования картинки, искажения будут оставаться на экране довольно долго. Использование векторов перемещения может привести к дрейфу искажений по экрану и расширению их области. Для того чтобы уменьшить последствия искажений, в передаваемый информационный поток включаются коды коррекции ошибок BCH (511,493; Forward Error Correction Code), которые позволяют исправить любые две ошибки или кластер, содержащий до 6 ошибок в блоке из 511 бит (см. рис. 2.5.7). Алгоритм работает в широком диапазоне скоростей передачи информации. Для реализации коррекции ошибок в поток двоичных данных включается 8 пакетов, каждый из которых включает в себя 1 кадровый бит, 1 бит индикатор заполнения, 492 бита кодированных данных и 18 бит четности. Поле Fi (индикатор заполнения) может равняться нулю, тогда последующие 492 бита не являются графической информацией и могут игнорироваться. Алгоритм предназначен для работы в динамическом диапазоне частот 40:1.

    Рис. 2.5.7 Схема передачи данных с коррекцией ошибок

    Во время переговоров или в ходе видеоконференции может возникнуть необходимость отобразить текст, выделить на экране какой-то объект, послать факс и т.д. Для решения таких задач можно использовать D-канал, но это не оптимально, так как он имеет свои специфические функции. Поэтому более привлекательным представляется создание специального протокола, работающего в рамках B-канала (H.221). Для этих целей используется младший бит каждого из октетов, что позволяет создать канал с пропускной способностью 8 Кбит/с. этот сервисный канал использует кадры по 80 бит. Первые 8 бит служат для целей синхронизации (FAS - Frame Alignment Signal) и выполняют следующие функции:

    • выделение начала кадра (исключение имитации этого в информационном потоке);
    • выделение начала блока кадров (опционно до 16 кадров);
    • выполнение функций счетчика в многокадровых блоках (по модулю 16), может использоваться в многоточечных соединениях;
    • нумерация соединений;
    • CRC-контроль (опционно);
    • "A-бит" для определения кадр/мультикадр/синхронизация при пересылке в противоположном направлении (A=0 - передача, см. также структуру кадров isdn );

    При работе с каналами на 384, 1536 и 1920 Кбит/с сервисный канал использует тайм-слот 1. Следующие 8 бит имеют название BAS (Bit Allocation Signal) и выполняют следующие функции:

    • код, характеризующий возможности канала (узко/широко полосная передача звука, различные видео параметры, тип шифрования и т.д.);
    • коды команд, определяющие значения передаваемых кадров;
    • ESC-последовательности.

    Очевидно, что BAS-коды (H.242) должны быть надежно защищены от ошибок. Для этой цели они пересылаются с использованием кодов, допускающих коррекцию ошибок. При работе оба приемника непрерывно ищут разделительный код кадров. Когда он обнаружен, бит А для выходного канала делается равным нулю. Только после получения А=0 терминал может быть уверен в том, что удаленный терминал правильно воспринял код BAS. Работа с кодами BAS описана в документе H.242. При установлении режима обмена терминалы обмениваются командами BAS. Команда действительна для последующих двух кадров, следовательно, при частоте кадров 100 Гц, изменения режима могут производиться каждые 20 мс.

    Многоточечный вызов может рассматриваться как несколько связей между терминалами и бриджом MCU (Multipoint Control Unit) по схеме точка-точка. Простой MTU передает на каждый из терминалов смешанный аудио-сигнал от остальных терминалов. Каждый терминал осуществляет широковещательную передачу для остальных терминалов, участвующих в обмене. При видео обмене на терминал выводится только одна картинка. Дополнительную информацию по данной тематике можно найти в рекомендациях H.231, H242 и H.243.

    Для передачи нормального телевизионного изображения необходимо 364 Кбит/с (4х64 Кбит/c). Интеграция телевидения с сетями передачи данных, появление видеотелефона и широкое внедрение видеоконференций становится велением времени. Требования к каждому из этих видов услуг варьируется значительно в зависимости от приложения. Например, ставшие обычными телевизионные мосты требуют высокого качества передачи изображения и звука. А в некоторых дорогостоящих отраслях науки, где международное сотрудничество стало неизбежным, важным является передача статических изображений (чертежи, схемы, описания алгоритмов, и т.д.) с высоким (иногда более высоким, чем в телевидении) разрешением. Здесь важно передать звук с приемлемым качеством (но заметно хуже, чем на ТВ) и обеспечить синхронное перемещение маркера мыши по экрану в ходе обсуждения переданного документа. Экономия только на авиа билетах (не говоря о командировочных и времени экспертов) способна перекрыть издержки по оплате канала для видеоконференции. В этом режиме приемлемым может считаться один кадр в 1-4 секунды.

    Рисунок известного французского художника Клода Серрэ из книги "Черный юмор и люди в белом" (см. начало раздела) может служить иллюстрацией того, к чему может привести использование протокола tcp при передаче изображения в реальном масштабе времени. Предположим, что в процессе передачи изображения носа пакеты были повреждены, тогда спустя некоторое время, определяемое размером окна (TCP), будет проведена повторная их передача. Тем временем переданные ранее пакеты будут использованы для построения изображения, а часть картинки, содержавшаяся в пакетах, посланных вместо поврежденных, будет отображена совсем не там, где это следует. Реально из-за повреждения пакетов возможны в этой версии и более тяжелые искажения изображения. Именно это является причиной использования UDP для передачи видео и аудио информации при видео и аудио конференциях (еще лучшего результата можно достичь, использую протокол RTP). Протокол UDP не требует подтверждения и повторной передачи при ошибке доставки. Поврежденные пакеты вызовут искажения изображения (или звука) лишь локально.

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

    Стандарт MPEG

    Стандарт MPEG-2 является усовершенствованием MPEG-1 и базируется на схеме шифрования с потерями и передачи без потерь. Кодирование в MPEG-2 идентично используемому в MPEG-1 (I- P- и B-кадры; В-кадры не используются). I-кадр (Intracoded) представляет собой изображение, закодированное согласно стандарту JPEG при полном разрешении по яркости и половинном разрешении по цвету. Такие кадры должны появляться периодически. Эти кадры обеспечивают совместимость с MPEG-1, и исключают влияние накопления ошибок в процессе передачи. P-кадры (Predictive) содержат отличие блоков в последнем кадре изображения (базируются на идее макроблоков). B-кадры (Bidirectional) характеризуют отличие двух последовательных изображений. Здесь применено двойное косинусное преобразование с числом коэффициентов 10*10 (против 8*8 в MPEG-1). MPEG-2 предназначен для широковещательного телевидения (включая прямое спутниковое - DBS) и для записи на CD-ROM и поддерживает четыре разных стандартов разрешения: 352*240 (низкое), 720*480 (базовое), 1440*1152 (высокое-1440) и 1920*1080 (высокое). Низкое разрешение служит для обеспечения совместимости с MPEG-1. Базовое разрешение ориентировано на работу со стандартом NTSC. Последние два стандарта относятся к телевидению высокого разрешения (HDTV). Помимо этого MPEG-2 поддерживает 5 профайлов для различных прикладных областей. Основной профайл ориентирован на общие приложения с базовым разрешением. Простой профайл сходен с основным профайлом, но не работает с B-кадрами, чтобы облегчить процедуры кодирования/декодирования. Остальные профайлы служат для обеспечения масштабируемости и работы с HDTV, они отличаются цветовым разрешением и форматами информационных потоков. Скорость передачи данных для каждой комбинации разрешения и профайла различна и лежит в диапазоне от 3 до 100 Мбит/c. Для обычного ТВ характерна скорость 3-4 Мбит/c. В таблице 2.5.2 представлены размеры кадров в битах для MPEG-1 и MPEG-2.

    Таблица 2.5.2. Размеры кадров MPEG-1 и MPEG-2

    Тип кадра

    i

    p

    b

    Средний

    mpeg-1 (1,15 Мбит/с)

    150,000

    50,000

    20,000

    38,000

    mpeg-2 (4 Мбит/c)

    400,000

    200,000

    80,000

    130,000

    Мультиплексирование аудио- и видеоданных в MPEG-2 показано на рис. 2.5.8. На выходе пакетизатора мы имеем элементарные потоки пакетов (PES- Packetized Elementary Stream), содержащих около 30 полей, включая длину, идентификаторы потоков, временные метки, контрольные суммы и т.д. В MPEG-2 формируется два комплексных потока, программный поток (PS) длинных пакетов переменной длины сходный с MPEG-1, содержащий видео и аудио данные и имеющий общую временную шкалу, и транспортный поток (TS) пакетов постоянной длины (188 байт) без общей временной шкалы. В последнем случае минимизируется влияние потерь пакетов в процессе транспортировки. Предусмотрено выделение в потоке составляющих разной степени важности (например, DCT-коэффициентов и обычных графических данных).

    Рис. 2.5.8. Мультиплексирование аудио и видео данных в MPEG-1 и MPEG-2 (внизу)

    Преобразование аналогового сигнала в цифровую последовательность осуществляется в MPEG-2 с помощью кодеков, создавая первичный поток в 140 Мбит/с, который затем преобразуется для передачи через стандартные каналы 1,5 и 15 Мбит/с (например, для прямого широковещательного, спутникового телевидения). В соответствии со стандартом сжатия данных H.320 можно обеспечить передачу видео + аудио по каналу 56 кбит/с с низким разрешением и частотой 1 кадр/сек. Смотри раздел "Видеоконференции по каналам ISDN и Интернет".

    Интерактивное телевидение

    В последнее время благодаря широкому внедрению цифрового телевидения и новых стандартов передачи изображения (MPEG-2) открылись возможности для "телевидения по требованию" (интерактивного телевидения) - системы, где клиент может самостоятельно и индивидуально формировать ТВ-программу. Первые опыты такого рода относятся к 1995 году. Такие системы базируются на существующих сетях кабельного телевидения. Но развитие оптоволоконных технологий позволяют ожидать полной интеграции кабельного цифрового телевидения и информационных сетей Интернет. Следует, впрочем, заметить, что оптоволокно в каждом жилище является пока непозволительной роскошью. Общая схема такой системы показана на рис. 2.5.9.

    Рис. 2.5.9. Схема реализации интерактивного телевидения

    Базовый мультимедийный сервер может обслуживать отдельный район города. В пределах квартала размещается промежуточный центр, где размещается локальный буферный сервер, где записываются фрагменты программ, заказанные локальными клиентами. Только новостийные и некоторые спортивные программы передаются в реальном масштабе времени, все фильмы берутся из локальной фильмотеки или предварительно записываются в накопитель из центрального мультимедиа-сервера. Транспортной средой здесь может стать ATM, SDH или Fibre Channel. Оптическое волокно доходит до квартального сервера или даже до дома клиента. Индивидуальная раздача сигнала на терминалы (телевизоры) может осуществляться через существующие телевизионные кабели. В этом случае по имеющимся каналам может передаваться не только программа телевидения и осуществляться телефонные переговоры, но выполняться полное информационное обслуживание. Сюда может включаться, помимо заказа ТВ-программ, подписка на газеты, заказ билетов на транспорт или в театр, получение прогноза погоды и данных о состоянии дорог, доступ к базам данных, включая библиотеки и фонотеки и многое другое. Особый интерес представляет возможность практически полного вытеснения традиционных газет. Клиент сможет получать только интересующие его статьи из любых газет (и только их и оплачивать). Если какая-то статья его заинтересует и он захочет почитать ее позднее в машине или на даче, он сможет ее распечатать на принтере, подключенном к его телевизору-терминалу. Цены на цветные принтеры в настоящее время спустились ниже 100 долларов, таким образом нужная копия уже сейчас дешевле стоимости газеты. Экономия на бумаге и средствах доставки очевидны, да и необходимость в типографиях отпадет, ведь даже книги можно будет получить непосредственно дома (хотя привлекательность данной услуги и не вполне очевидна - хорошо сброшированная и переплетенная книга будет привлекательным объектом еще долго (прогноз относительно будущих книг сотри в разделе "Заключение"). Массовое внедрение таких технологий будет стимулировать падение цен на соответствующие процессоры и принтеры. Интерактивная схема подключения телевизора-терминала сделает возможным многие новые виды развлечений, а также выполнение многих покупок, не выходя из дома. Традиционной почте подписала отсроченный приговор почта электронная, но появление интерактивных широкополосных средств завершит многовековую историю почты (да и телеграфа). Ей будет оставлена доставка товаров, билетов и документов. Побочным продуктом прогресса в данной области станет общедоступный видеотелефон.

    В жилье клиента будет входить оптоволоконный кабель, завершающийся интерфейсной коробкой с разъемами для подключения телефона, телевизора и ЭВМ. Даже современные ограниченные скорости передачи позволяют решить стоящие проблемы. Во-первых люди не смотрят телевизор круглые сутки, это позволяет ночью или в рабочее время, когда клиент на службе, произвести передачу нужных фрагментов ТВ-программы на локальный сервер. Во-вторых популярность фильмов и программ не однородна, что также снижает требование на широкополосность. Известно, что наиболее популярный фильм запрашивается примерно в К раз чаще, чем фильм, занимающий к-ое место в списке популярности (эмпирический закон Ципфа (Zipf), выведенный из статистики контор по прокату видеокассет). Это означает, что из предлагаемого списка будут выбраны не все фильмы, а наиболее популярные фрагменты программ можно передавать по схеме MBONE, минимизируя загрузку каналов (смотри также описание протокола PIM). Способствовать решению данной проблемы будет и появление CD с емкостью 4 Гбайта. Но проблем здесь остается немало, так трудно себе представить, что все клиенты захотят смотреть один и тот же фильм в одно время. Решение подобной задачи потребует очень большого объема буферной памяти и ощутимо поднимет требования к широкополосности канала. "Синхронизовать" клиентов можно будет дифференциацией оплаты для разных временных интервалов, и группированием клиентов, заказавших близкие времена начала демонстрации фильмов, путем предварительного оповещения. Но несмотря на все эти ухищрения, локальные серверы должны будут иметь сложную иерархическую систему буферной памяти, базирующейся на разных принципах работы (CD, магнитная лента, дисковая память и даже RAM).

    Практическая реализация фантастической схемы, предложенной в предыдущем абзаце, уже осуществляется в США и Канаде. Здесь есть немало проблем, например, нужен дешевый широкополосный кабельный модем (смотри раздел "Модемы", там же приведена схема подключения телевизора-терминала через кабельный модем). Предстоит написать огромное число различных сервисных программ, но все базовые технологии уже существуют.

    Previous: 2.4.3 Передача голоса по каналам Интернет    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.5.1 Стандарт MPEG-4


    previous up down next index index
    Previous: 2.5 Методы преобразования и передачи изображения    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации
        Next: 2.5.2 Стандарт MPEG-7

    2.5.1 Стандарт MPEG-4
    Семенов Ю.А. (ГНЦ ИТЭФ)

     

    Какое счастье, что вокруг
    Живут привольно и просторно
    Слова и запах, цвет и звук,
    Фактура, линия и форма

     

    И. Губерман

    MPEG-4 является стандартом ISO/IEC разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал такие известные стандарты как MPEG-1 и MPEG-2. Эти стандарты сделали возможным интерактивное видео на CD-ROM и цифровое телевидение. MPEG-4 является результатом работы сотен исследователей и разработчиков всего мира. Разработка MPEG-4 (в ISO/IEC нотации имеет название ISO/IEC 14496) завершена в октябре 1998. Международным стандартом он стал в начале 1999. Полностью совместимый расширенный вариант MPEG-4 версия 2 был разработан к концу 1999 и стал международным стандартом в начале 2000. Работы над этим документом продолжаются (см. http://sound.media.mit.edu/mpeg4/SA-FDIS.pdf). MPEG-4 предназначен для решения трех проблем:

    • Цифровое телевидение;
    • Интерактивные графические приложения (synthetic content);
    • Интерактивное мультимедиа World Wide Web.

    Стандарт можно купить в ISO, связь через e-mail:sales@iso.ch. Программное обеспечение MPEG-4 может быть получено через сеть по адресу: www.iso.ch/ittf. Эти программы бесплатны, но это не означает, что они не защищены патентами. Смотри также http://mpeg.telecomitalialab.com/standards/mpeg-4/mpeg-4.htm.

    1. Особенности стандарта MPEG-4

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

    • Для разработчиков, MPEG-4 позволяет создавать объекты, которые обладают большей адаптивностью и гибкостью, чем это возможно сейчас с использованием разнообразных технологий, таких как цифровое телевидение, анимационная графика WWW и их расширения. Новый стандарт делает возможным лучше управлять содержимым и защищать авторские права.
    • Для сетевых провайдеров MPEG-4 предлагает прозрачность данных, которые могут интерпретироваться и преобразовываться приемлемые сигнальные сообщения для любой сети посредством стандартных процедур. MPEG-4 предлагает индивидуальные QoS-дескрипторы (Quality of Service) для различных сред MPEG-4. Точное преобразование параметров QoS для каждой из сред в сетевые значения QoS находится за пределами регламентаций MPEG-4 (оставлено на усмотрение сетевых провайдеров). Передача QoS-дескрипторов MPEG-4 по схеме точка-точка оптимизирует транспортировку данных в гетерогенных средах.
    • Для конечных пользователей, MPEG-4 предлагает более высокий уровень взаимодействия с содержимым объектов. Стандарт транспортировать мультимедиа данные через новые сети, включая те, которые имеют низкую пропускную способностью, например, мобильные. Описания приложений MPEG-4 можно найти на странице http://www.cselt.it/mpeg.

    Стандарт MPEG-4 определяет следующее:

    1. Представляет блоки звуковой, визуальной и аудиовизуальной информации, называемые "медийными объектами". Эти медийные объекты могут быть естественного или искусственного происхождения; это означает, что они могут быть записаны с помощью камеры или микрофона, а могут быть и сформированы посредством ЭВМ;
    2. Описывает композицию этих объектов при создании составных медийных объектов, которые образуют аудиовизуальные сцены;
    3. Мультиплексирование и синхронизацию данных, ассоциированных с медийными объектами, так чтобы они могли быть переданы через сетевые каналы, обеспечивая QoS, приемлемое для природы специфических медийных объектов; и
    4. Взаимодействие с аудиовизуальной сценой, сформированной на принимающей стороне.

    1.1. Кодированное представление медийных объектов

    Аудиовизуальные сцены MPEG-4 формируются из нескольких медийных объектов, организованных иерархически. На периферии иерархии находятся примитивные медийные объекты, такие как:

    • статические изображения (например, Фон изображения),
    • видео-объекты (например, говорящее лицо - без фона)
    • аудио-объекты (например, голос данного лица);
    • и т.д.

    MPEG-4 стандартизует число таких примитивных медиа-объектов, способных представлять как естественные, так и синтетические типы содержимого, которые могут быть 2- или 3-мерными. Кроме медиа-объектов, упомянутых выше и показанных на рис. 1, MPEG-4 определяет кодовое представление объектов, такое как:

    ∙ текст и графика;
    ∙ говорящие синтезированные головы и ассоциированный текст, использованный для синтеза речи и анимации головы;
    ∙ синтезированный звук

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

    Кодовое представление медиа-объектов максимально эффективно с точки зрения получения необходимой функциональности. Примерами такой функциональности являются разумная обработка ошибок, легкое извлечение и редактирование объектов и представление объектов в масштабируемой форме.

    1.2. Состав медийных объектов

    На рис. 1 объясняется способ описание аудио-визуальных сцен в MPEG-4, состоящих из отдельных объектов. Рисунок содержит составные медиа-объекты, которые объединяют примитивные медиа-объекты. Примитивные медиа-объекты соответствуют периферии описательного дерева, в то время как составные медиа-объекты представляют собой суб-деревья. В качестве примера: визуальные объекты, соответствующие говорящему человеку, и его голос объединены друг с другом, образуя новый составной медиа-объект.

    Такое группирование позволяет разработчикам создавать комплексные сцены, а пользователям манипулировать отдельными или группами таких объектов.

    MPEG-4 предлагает стандартизованный путь описания сцен, позволяющий:

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

    Описание сцены строится во многих отношениях также как и в языке моделирования виртуальной реальности VRML (Virtual Reality Modeling language).

    Рис. 1. Пример сцены MPEG-4

    1.3. Описание и синхронизация потоков данных для медийных объектов

    Медиа-объектам может быть нужен поток данных, который преобразуется в один или несколько элементарных потоков. Дескриптор объекта идентифицирует все потоки ассоциированные с медиа-объектом. Это позволяет иерархически обрабатывать кодированные данные, а также ассоциированную медиа-информацию о содержимом (называемом "информация содержимого объекта").

    Каждый поток характеризуется набором дескрипторов для конфигурирования информации, например, чтобы определить необходимые ресурсы записывающего устройства и точность кодированной временной информации. Более тог, дескрипторы могут содержать подсказки относительно QoS, которое необходимо для передачи (например, максимальное число бит/с, BER, приоритет и т.д.)

    Синхронизация элементарных потоков осуществляется за счет временных меток блоков данных в пределах элементарных потоков. Уровень синхронизации управляет идентификацией таких блоков данных (модулей доступа) и работой с временными метками. Независимо от типа среды, этот слой позволяет идентифицировать тип модуля доступа (например, видео или аудио кадры, команды описания сцены) в элементарных потоках, восстанавливать временную базу медиа-объекта или описания сцены, и осуществлять их синхронизацию. Синтаксис этого слоя является конфигурируемым самыми разными способами, обеспечивая работу с широким спектром систем.

    1.4. Доставка потоков данных

    Синхронизованная доставка потока данных отправителя получателю, использующая различные QoS, доступные в сети, специфицирована в терминах слоя синхронизации и доставки, которые содержат двухслойный мультиплексор (см. рис. 2).

    Первый слой мультиплексирования управляется согласно спецификации DMIF (Delivery Multimedia Integration Framework). Это мультиплексирование может быть реализовано определенным в MPEG мультиплексором FlexMux, который позволяет группировать элементарные потоки ES (Elementary Streams) с низкой избыточностью. Мультиплексирование на этом уровне может использоваться, например, для группирования ES с подобными требованиями по QoS, чтобы уменьшить число сетевых соединений или значения задержек.

    Слой "TransMux" (Transport Multiplexing) на рис. 2 моделирует уровень, который предлагает транспортные услуги, удовлетворяющие требованиям QoS. MPEG-4 специфицирует только интерфейс этого слоя, в то время как остальные требования к пакетам данных будут определяться транспортным протоколом. Любой существующий стек транспортных протоколов, например, (RTP)/UDP/IP, (AAL5)/ATM, или MPEG-2 Transport Stream поверх подходящего канального уровня может стать частным случаем TransMux. Выбор оставлен за конечным пользователем или серис-провайдером, и позволяет использовать MPEG-4 с широким спектром операционного окружения.

    Рис. 2. Модель системного слоя MPEG-4

    Использование мультиплексора FlexMux является опционным и, как показано на рис. 2, этот слой может быть пустым, если нижележащий TransMux предоставляет все необходимые функции. Слой синхронизации, однако, присутствует всегда. С учетом этого возможно:

    • идентифицировать модули доступа, транспортные временные метки и эталонную временную информацию, а также регистрировать потерю данных.
    • опционно выкладывать данные от различных элементарных потоков в потоки FlexMux
    • передавать управляющую информацию:
    • индицировать необходимый уровень QoS для каждого элементарного потока и потока FlexMux;
    • транслировать данные требования QoS в действительные сетевые ресурсы;
    • ассоциировать элементарные потоки с медиа-объектами

    • передавать привязку элементарных потоков к FlexMux и TransMux каналам

    1.5. Взаимодействие с медийными объектами

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

    • изменить точку наблюдения/слушания на сцене;
    • перемещать объекты по сцене;
    • вызывать последовательность событий путем нажатия кнопки мыши на определенных объектах, например, запуская или останавливая поток данных;
    • выбирать предпочтительный язык, когда такой выбор возможен;

    1.6. Менеджмент и идентификация интеллектуальной собственности

    Важно иметь возможность идентифицировать интеллектуальную собственность в MPEG-4 медиа-объектах. Полный перечень требований для идентификации интеллектуальной собственности можно найти на базовой странице MPEG в разделе 'Management and Protection of Intellectual Property'.

    MPEG-4 включает в себя идентификацию интеллектуальной собственности путем запоминания уникальных идентификаторов, которые выданы международными системами нумерации (например ISAN, ISRC, и т.д. [ISAN: International Audio-Visual Number, ISRC: International Standard Recording Code]). Эти числа могут использоваться для идентификации текущего владельца прав медиа-объекта. Так как не все содержимое идентифицируется этим числом, MPEG-4 версия 1 предлагает возможность идентификации интеллектуальной собственности с помощью пары ключевых значений (например:"композитор"/"John Smith"). Кроме того, MPEG-4 предлагает стандартизованный интерфейс, который тесно интегрирован с системным слоем для людей, которые хотят использовать системы, контролирующие доступ к интеллектуальной собственности. С этим интерфейсом системы контроля прав собственности могут легко интегрироваться со стандартизованной частью декодера.

    2. Основные функции в MPEG-4 версия 1

    2.1. DMIF

    DMIF поддерживает следующие функции:

    • Прозрачный интерфейс MPEG-4 DMIF-приложения независящий оттого, является ли партнер удаленным интерактивным или локальной запоминающей средой.
    • Контроль установления каналов FlexMux
    • Использование однородных сетей между интерактивными партнерами: IP, ATM, мобильные, PSTN, узкополосные ISDN.

    2.2. Системы

    Как объяснено выше, MPEG-4 определяет набор алгоритмов улучшенного сжатия для аудио и видео данных. Потоки данных (Elementary Streams, ES), которые являются результатом процесса кодирования, могут быть переданы или запомнены независимо. Они должны быть объединены так, чтобы на принимающей стороне возникла реальная мультимедийная презентация.

    Системные части MPEG-4 обращаются к описаниям взаимодействий между аудио и видео компонентами, которые образуют сцену. Эти взаимодействия описаны на двух уровнях.

    • Двоичный формат для сцен BIFS (Binary Format for Scenes) описывает пространственно-временные отношения объектов на сцене. Зрители могут иметь возможность взаимодействия с объектами, например, перемещая их на сцене или изменяя свое положение точки наблюдения в 3D виртуальной среде. Описание сцены предоставляет широкий набор узлов для композиционных 2-D и 3-D операторов и графических примитивов.
    • На нижнем уровне, Дескрипторы объектов OD (Object Descriptors) определяют отношения между элементарными потоками, имеющими отношение к конкретному объекту (например, аудио- и видео-потоки участников видеоконференции). OD предоставляют также дополнительную информацию, такую как URL, необходимые для доступа к элементарным потокам, характеристики декодеров, нужных для их обработки, идентификация владельца авторских прав и пр.

    Некоторые другие особенности работы системы MPEG-4:

    • Интерактивно, включая: взаимодействие клиент-сервер; общая модель событий или отслеживание действий пользователя; общая обработка событий и отслеживание взаимодействий объектов на сцене пользователем или с помощью событий, генерируемых на сцене.
    • Средство объединения большого числа потоков в один общий поток, включая временную информацию (мультиплексор FlexMux).
    • Средство для запоминания данных MPEG-4 в файле (файловый формат MPEG-4, 'MP4')
    • Интерфейсы для различных терминалов и сетей в виде Java API (MPEG-J)
    • Независимость транспортного уровня.
    • Текстовые презентации с международной лингвистической поддержкой, выбор шрифта и стиля, согласование времени и синхронизация.
    • Инициализация и непрерывное управление буферами приемных терминалов.
    • Идентификация временной привязки, синхронизация и механизмы восстановления.
    • Наборы данных, включающие идентификацию прав интеллектуальной собственности по отношению к медиа-объектам.

    2.3. Аудио-система

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

    • Речь: Кодирование речи может производиться при скоростях обмена от 2 кбит/с до 24 кбит/с. Низкие скорости передачи, такие как 1.2 кбит/с, также возможны, когда разрешена переменная скорость кодирования. Для коммуникационных приложений возможны малые задержки. Когда используются средства HVXC, скорость и высота тона могут модифицироваться пользователем при воспроизведении. Если используются средства CELP, изменение скорости воспроизведения может быть реализовано с помощью дополнительного средства.
    • Синтезированная речь: TTS-кодировщики с масштабируемой скоростью в диапазоне от 200 бит/с до 1.2 кбит/с которые позволяют использовать текст или текст с интонационными параметрами (вариация тона, длительность фонемы, и т.д.), в качестве входных данных для генерации синтетической речи. Это включает следующие функции.
    • Синтез речи с использованием интонации оригинальной речи
    • Управление синхронизацией губ и фонемной информации.
    • Трюковые возможности: пауза, возобновление, переход вперед/назад.
    • Международный язык и поддержка диалектов для текста (т.е. можно сигнализировать в двоичном потоке, какой язык и диалект следует использовать)
    • Поддержка интернациональных символов для фонем.
    • Поддержка спецификации возраста, пола, темпа речи говорящего.
    • Поддержка передачи меток анимационных параметров лица FAP (facial animation parameter).
    • Общие аудио сигналы. Поддержка общей кодировки аудио потоков от низких скоростей до высококачественных. Рабочий диапазон начинается от 6 кбит/с при полосе ниже 4 кГц и распространяется до широковещательного качества передачи звукового сигнала для моно и многоканальных приложений.
    • Синтезированный звук: Поддержка синтезированного звука осуществляется декодером структурированного звука (Structured Audio Decoder), который позволяет использовать управление музыкальными инструментами с привлечением специального языка описания.
    • Синтетический звук с ограниченной сложностью: Реализуется структурируемым аудио декодером, который позволяет работать со стандартными волновыми форматами.

    Примерами дополнительной функциональности является возможность управления скоростью обмена и масштабируемость в отношении потоков данных, полосы пропускания, вероятности ошибок, сложности, и т.д. как это определено ниже.

    • Возможность работы при изменении скорости передачи допускает изменение временного масштаба без изменения шага при выполнении процесса декодирования. Это может быть, например, использовано для реализации функции "быстро вперед" (поиск в базе данных) или для адаптации длины аудио-последовательности до заданного значения, и т.д.
    • Функция изменения шага позволяет варьировать шаг без изменения временного масштаба в процессе кодирования или декодирования. Это может быть использовано, например, для изменения голоса или для приложений типа караоке. Эта техника используется в методиках параметрического и структурированного кодирования звука.
    • Изменение скорости передачи допускает анализ потока данных с разбивкой на субпотоки меньшей скорости, которые могут быть декодированы в осмысленный сигнал. Анализ потока данных может осуществляться при передаче или в декодере.
    • Масштабируемость полосы пропускания является частным случаем масштабируемости скорости передачи данных, когда часть потока данных, представляющая часть частотного спектра может быть отброшена при передаче или декодировании.
    • Масштабируемость сложности кодировщика позволяет кодировщикам различной сложности генерировать корректные и осмысленные потоки данных.
    • Масштабируемость сложности декодера позволяет заданную скорость потока данных дешифровать посредством декодеров с различным уровнем сложности. Качество звука, вообще говоря, связано со сложностью используемого кодировщика и декодера.
    • Аудио эффекты предоставляют возможность обрабатывать декодированные аудио сигналы с полной точностью таймирования с целью достижения эффектов смешения, реверберации, создания объемного звучания, и т.д.

    2.4. Видео-система

    Стандарт MPEG-4 Видео допускает гибридное кодирование естественных (пиксельных) изображений и видео вместе с синтезированными сценами (генерированными на ЭВМ). Это, например, допускает виртуальное присутствие участников видеоконференций. Видео стандарт содержит в себе средства и алгоритмы, поддерживающие кодирование естественных (пиксельных) статических изображений и видео последовательностей, а также средства поддержки сжатия искусственных 2-D и 3-D графических геометрических параметров.

    2.4.1. Поддерживаемые форматы

    Следующие форматы и скорости передачи будут поддерживаться MPEG-4 версия 1:

    ∙ Скорости передачи: обычно между 5 кбит/с и 10 Mбит/с
    ∙ Форматы: progressive а также interlaced видео
    ∙ Разрешение: обычно от sub-QCIF вплоть до HDTV

    2.4.2. Эффективность сжатия

    • Эффективное сжатие видео будет поддерживаться для всех скоростей обмена. Сюда входит компактное кодирование текстур с качеством, регулируемым от уровня "приемлемо" (для высоких сжатий данных) вплоть до "практически без потерь".
    • Эффективное сжатие текстур для 2-D и 3-D сеток.
    • Произвольный доступ к видео, обеспечивающий такие функции как пауза, быстрый переход вперед или назад для записанного видео.

    2.4.3. Функции, зависящие от содержимого (Content-Based)

    • Кодирование, учитывающее содержимое изображения и видео, позволяет разделить кодовое преобразование и реконструкцию видео-объектов произвольной формы.
    • Произвольный доступ к содержимому видео последовательности открывает возможность реализации функций пауза, быстрый переход вперед или назад для записанного видео-объектов.
    • Расширенное манипулирование видео последовательностями позволяет наложения естественный или синтетический текст, текстуры, изображения и видео. Примером может служить наложение текста на движущийся видео объект, когда текст движется синфазно с объектом.
    • 2.4.4. Масштабируемость текстур изображений и видео

      • Масштабируемость сложности в кодировщике позволяет кодировщикам различной сложности генерировать корректный и осмысленный поток данных для данной текстуры, изображения или видео.
      • Масштабируемость сложности в декодере позволяет декодировать потоки текстур, изображений или виде декодерами различного уровня сложности. Достигаемое качество, вообще говоря, зависит от сложности используемого декодера. Это может подразумевать, что простые декодеры обрабатывают лишь часть информационного потока.
      • Пространственная масштабируемость позволяет декодерам обрабатывать некоторую часть общего потока, сформированного кодировщиком, при реконструкции и отображении текстур, изображений или видео-объектов при пониженном пространственном разрешении. Для текстур и статических изображений будет поддерживаться не более 11 уровней масштабируемости. Для видео последовательностей поддерживается не более трех уровней.
      • Временная масштабируемость позволяет декодерам обрабатывать некоторую часть общего потока, сформированного кодировщиком, при реконструкции и отображении видео при пониженном временном разрешении. Поддерживается не более трех уровней.
      • Масштабируемость качества позволяет разбить поток данных на несколько составляющих различной мощности так, чтобы комбинация этих составляющих могла при декодировании давать осмысленный сигнал. Разложение потока данных на составляющие может происходить при передаче или в декодере. Полученное качество, вообще говоря, зависит от числа компонент, используемых при реконструкции.

      2.4.5. Кодирование формы и Alpha-представление

      • Кодирование формы будет поддерживаться, чтобы помочь описанию и композиции изображений и видео, а также видео-объектов произвольной формы. Приложения, которые используют двоичные побитовые карты изображения, служат для презентаций баз данных изображений, интерактивных игр, наблюдения, и анимации. Предлагаются эффективные методы кодирования двоичных форм. Двоичная альфа-маска определяет, принадлежит или нет пиксель объекту. Она может быть включена ('on') или выключена ('off').
      • 'Серая шкала' или 'alpha' кодирование формы

      Alpha-плоскость определяет прозрачность объекта, которая не обязательно является однородной. Многоуровневые alpha-карты часто используются для затенения различных слоев последовательности изображений. Другими приложениями, которые используют при работе с изображениями ассоциированные двоичные alpha-маски, являются презентации баз данных изображений, интерактивные игры, наблюдения, и анимация. Предлагаются методики, которые позволяют эффективно кодировать двоичные и альфа-плоскости с серой шкалой изображения. Двоичная альфа-маска определяет, принадлежит ли пиксель данному объекту. Маска с серой шкалой предоставляет возможность точно определить прозрачность каждого пикселя.

      2.4.6. Надежность в средах, подверженных ошибкам

      Устойчивость к ошибкам будет поддерживаться, чтобы обеспечить доступ к изображениям и видео через широкий спектр систем памяти и передающих сред. Это включает в себя операции алгоритмов сжатия данных в среде, подверженной сбоям при низких скоростях передачи (т.e., меньше чем 64 Кбит/с).

      2.4.7. Анимация лица

      Часть стандарта, связанная с 'анимацией лица', позволяет посылать параметры, которые помогают специфицировать и анимировать синтезированные лица. Эти модели не являются сами частью стандарта MPEG-4, стандартизированы только параметры.

      ∙ Определение и кодирование анимационных параметров лица (модельно независимое):
      ∙ Позиции характерных деталей и их ориентация для определения сеток при анимации лица.
      ∙ Визуальные конфигурации губ, соответствующие фонемам речи.
      ∙ Определение и кодирование параметров описания лица (для калибровки модели):
      ∙ 3-D позиции характерных признаков (деталей)
      ∙ 3-D калибровочные сетки для анимации головы.
      ∙ Текстурная карта лица.
      ∙ Персональные характеристики.
      ∙ Кодирование лицевой текстуры.

      2.4.8. Кодирование 2-D сеток с нечетко выраженной структурой

      ∙ Предсказание, базирующееся на сетке, и трансфигурация анимационных текстур
      ∙ 2-D-формализм с регулярной сеткой и отслеживанием перемещения анимированных объектов
      ∙ Предсказание перемещения и отложенная передача текстуры с динамическими сетками.
      ∙ Геометрическое сжатие для векторов перемещения:
      ∙ 2-D сжатие сетки с неявной структурой и реконструкция в декодере.

      3. Главные функции в MPEG-4 версия 2

      Версия 2 была зафиксирована в декабре 1999. Существующие средства и профайлы из версии 1 в версии 2 не заменены; новые возможности будут добавлены в MPEG-4 в форме новых профайлов. Системный слой версии 2 обладает обратной совместимостью с версией 1.

      3.1. Системы

      Версия 2 систем MPEG-4 расширяет версию 1, с тем, чтобы перекрыть такие области, как BIFS-функциональность и поддержка Java (MPEG-J). Версия 2 также специфицирует формат файлов для записи содержимого MPEG-4.

      3.2. Видео-системы

      3.2.1. Натуральное видео

      Видео MPEG-4 версия 2 добавляет новые возможности в следующих областях:

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

      3.2.2. Анимация тела

      В версии 2 к анимации лица, существовавшей в версии 1, добавлена анимация тела.

      3.2.3. Кодирование 3-D полигональных сеток

      Версия 2 MPEG-4 предоставляет набор средств для кодирования многогранных 3-D сеток. Многогранные сетки широко используются для представления 3-D объектов.

      3.3. Звук

      MPEG-4 Аудио версия 2 является расширением MPEG-4 Аудио версия 1. В новой версии добавлены новые средства и функции, все прежние возможности и функции сохранены. Версия 2 MPEG-4 Аудио предоставляет следующие возможности:

      • Улучшенная устойчивость к ошибкам
      • Кодирование аудио, которое сочетает в себе высокое качество и малые задержки
      • Масштабируемость зерна изображения (масштабируемость разрешения вплоть до 1 кбит/с на канал)
      • Параметрическое аудио-кодирование для манипулирования звуком при низких скоростях.
      • Сжатие пауз в разговоре (CELP) для дальнейшего понижения потока данных при кодировании голоса.
      • Параметрическое кодирование речи, устойчивое к ошибкам.
      • Пространственная ориентация - возможность реконструировать звуковое окружение, используя метод моделирования.
      • Обратный канал, который полезен для настройки кодирования или масштабируемого воспроизведения в реальном времени.
      • Низкая избыточность транспортного механизма MPEG-4 для звука

      3.4. DMIF

      Основные средства, вводимые DMIF версия 2 предоставляют поддержку (ограниченную) мобильных сетей и мониторирования QoS.

      3.4.1. Поддержка мобильных сетей

      Спецификация H.245 была расширена (H.245v6), чтобы добавить поддержку систем MPEG-4; спецификация DMIF предоставляет возможность работу с сигналами H.245. Мобильные терминалы могут теперь использоваться системами MPEG-4, такими как BIFS и OD-потоки.

      3.4.2. Мониторирование QoS

      DMIF V.2 вводит концепцию мониторирования качества обслуживания (QoS). Реализуемого в сети. Интерфейс DMIF-приложения был соответственно расширен. Модель допускает до трех различных режимов мониторирования QoS: непрерывное мониторирование, контроль специфических очередей, и наблюдение за нарушениями QoS

      3.4.3. Пользовательские команды с ACK

      Модель DMIF позволяет приложениям партнеров обмениваться любыми сообщениями пользователей (поток управляющих сообщений). В DMIF V2 добавлена поддержка сообщений-откликов.

      3.4.4. Управление информацией уровня Sync MPEG-4

      V.2 улучшает модель DMIF, чтобы позволить приложениям обмениваться прикладными данными со слоем DMIF. Это добавление было введено, чтобы сделать возможным в пределах модели обмен блоками протокольных данных уровня Sync. Это комбинация чисто медийных данных (PDU) и логической информации уровня Sync. Модель подтверждает, что в пределах существующего транспортного стека существуют средства, которые перекрываются с Sync-слоем систем MPEG-4. Это случай RTP и MPEG-2 элементарных потоков пакетов PES (Packetized Elementary Steams), а также MP4-атомов в файловом формате. Во всех таких случаях очевидной реализацией DMIF является преобразование информации уровня Sync, извлеченной из этих структур, а также из SL-PDU, в однородное логическое представление заголовка пакета уровня Sync. Как следствие, введены соответствующие параметры для DAI, с учетом обеспечения их семантической независимости от транспортного стека и приложения.

      3.4.5. DAI-синтаксис на языке СИ

      DMIF V.2 вводит информативное дополнение, который предоставляет синтаксис C/C++ для прикладного интерфейса DMIF, как это рекомендуется API-синтаксисом.

      4. Расширения MPEG-4 за пределы версии 2

      MPEG в настоящее время работает с номером расширения версии 2, в визуальной и системной областях. Никаких работ по расширению MPEG-4 DMIF или Аудио за пределы версии 2 не проводились.

      4.1. Визуальная область системы

      В визуальной области подготавливается добавление следующих методик:

      • Масштабируемость пространственного разрешения (Fine Grain) находится на фазе голосования, с предложенными 'Профайлами поточного видео' ('Advanced Simple' и 'Fine Grain Scalability'). Масштабируемость пространственного разрешения представляет собой средство, которое допускает небольшие изменения качества путем добавления или удаления слоев дополнительной информации. Это полезно во многих ситуациях, особенно для организации потоков, но также и для динамического ('статического') мультиплексирования предварительно закодированных данных в широковещательной среде.
      • Средства для использования MPEG-4 в студии. Для этих целей были приняты меры для сохранения некоторой формы совместимости с профайлами MPEG-2. В настоящее время, простой студийный профайл находится на фазе голосования (Simple Studio Profile), это профайл с кодированием только I-кадра при высоких скоростях передачи данных (несколько сот Мбит/с), который использует кодирование формы (shape coding). Ожидается добавление профайла ядра студии (Core Studio Profile) (с I и P кадрами).
      • Изучаются цифровые камеры. Это приложение потребует truly lossless coding, и not just the visually lossless that MPEG-4 has provided so far. A Preliminary Call for Proposals was issued in October 2000.

      4.2. Системы

      4.2.1. Advanced BIFS

      Продвинутый BIFS предоставляет дополнительные узлы, которые могут быть использованы в графе сцены для мониторирования доступности и управляемости среды, такие как посылка команд серверу, продвинутый контроль воспроизведения, и так называемый EXTERNPROTO, узел, который обеспечивает дальнейшую совместимость с VRML, и который позволяет написание макросов, определяющих поведение объектов. Предусмотрено улучшенное сжатие данных BIFS, и в частности оптимальное сжатие для сеток и для массивов данных.

      4.2.2. Текстуальный формат

      Расширяемый текстовой формат MPEG-4 XMT (Extensible Textual format) является базовым для представления MPEG-4 описаний сцен, использующих текстовой синтаксис. XMT позволяет авторам текста обмениваться его содержимым друг с другом. Консорциумом Web3D разработаны средства обеспечения совместимости с расширяемым X3D (Extensible 3D), и интеграционным языком синхронизованного мультимедиа SMIL (Synchronized Multimedia Integration Language) от консорциума W3C.

      Формат XMT может быть изменен участниками SMIL, VRML, и MPEG-4. Формат может быть разобран и воспроизведен непосредственно участником W3C SMIL, преобразован в Web3D X3D и заново воспроизведен участником VRML, или компилирован в презентацию MPEG-4, такую как mp4, которая может быть затем воспроизведена участником MPEG-4. Ниже описано взаимодействие с XMT. Это описание содержит в себе MPEG-4, большую часть SMIL, масштабируемую векторную графику (Scalable Vector Graphics), X3D, а также текстуальное представление описания MPEG-7 (смотри http://www.cselt.it/mpeg, где имеется документация на стандартe MPEG-7).

      XMT содержит два уровня текстуального синтаксиса и семантики: формат XMT-A и формат XMT-Ù.

      XMT-A является версией MPEG-4, базирующейся на XML, содержащей субнабор X3D. В XMT-A содержится также расширение MPEG-4 для X3D, что бы работать с некоторыми специальными средствами MPEG-4. XMT-A предоставляет прямое соответствие между текстовым и двоичным форматами.

      XMT-Ù является абстракцией средств MPEG-4 высокого уровня, базирующейся на W3C SMIL. XMT предоставляет по умолчанию соответствие Ù и A.

      4.2.3. Улучшенная модель синхронизации

      Продвинутая модель синхронизации (обычно называемая 'FlexTime') поддерживает синхронизацию объектов различного происхождения с возможно разной временной шкалой. Модель FlexTime специфицирует временную привязку, используя гибкую модель с временными ограничениями. В этой модели, медиа-объекты могут быть связаны друг с другом в временном графе с использованием таких ограничений как "CoStart", "CoEnd", или "Meet". И, кроме того, для того чтобы обеспечить определенную гибкость и адаптацию к этим ограничениям, каждый объект может иметь адаптируемую длительность с определенными предпочтениями для растяжения и сжатия, которые могут быть применены.

      Модель FlexTime базируется на так называемой метафоре "пружины". Пружина имеет три ограничения: минимальная длина, менее которой она не сжимается, максимальная длина, при которой она может оборваться, и оптимальная длина, при которой она остается ни сжатой, ни растянутой. Следуя модели пружины, временные воспроизводимые медиа-объекты могут рассматриваться как пружины, с набором длительностей воспроизведения, соответствующих этим трем ограничениям пружины. Оптимальная длительность воспроизведения (оптимальная длина пружины) может рассматриваться как предпочтительный выбор автора для длительности воспроизведения медиа-объекта. Участник, где возможно, поддерживает длительность воспроизведения настолько близко к оптимальному значению, насколько позволяет презентация, но может выбрать любую длительность между минимальной и максимальной, как это специфицировал автор. Заметим, что поскольку растяжение или сжатие длительности в непрерывных средах, например, для видео, подразумевает соответствующее замедление или ускорение воспроизведения, для дискретных сред, таких как статическое изображение, сжатие или растяжение сопряжено в основном с модификацией периода рэндеринга.

      5. Профайлы в MPEG-4

      MPEG-4 предоставляет большой и богатый набор средств для кодирования аудио-визуальных объектов. Для того чтобы позволить эффективную реализацию стандарта, специфицированы субнаборы систем MPEG-4, средств видео и аудио, которые могут использоваться для специфических приложений. Эти субнаборы, называемые 'профайлами', ограничивают набор средств, которые может применить декодер. Для каждого из этих профайлов, устанавливается один или более уровней, ограничивающих вычислительную сложность. Подход сходен с MPEG-2, где большинство общеизвестных комбинаций профайл/уровень имеют вид 'главный_профайл @главный_уровень'. Комбинация профайл@уровень позволяет:

      ∙ конфигуратору кодека реализовать только необходимый ему субнабор стандарта,
      ∙ проверку того, согласуются ли приборы MPEG-4 со стандартом.

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

      5.1. Визуальные профайлы

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

      1. Простой визуальный профайл обеспечивает эффективное, устойчивое к ошибкам кодирование прямоугольных видео объектов, подходящих для приложений мобильных сетей, таких как PCS и IMT2000.

      2. Простой масштабируемый визуальный профайл добавляет поддержку кодирования временных и пространственных, масштабируемых объектов в простом визуальном профайле. Он полезен для приложений, которые обеспечивают услуги на более чем одном уровне качества, связанных с ограничениями скорости передачи данных или ресурсами декодера, такими как использование Интернет и программное декодирование.

      3. Центральный визуальный профайл добавляет поддержку кодировки время-масштабируемых объектов произвольной формы в простой визуальный профайл. Он полезен для приложений, осуществляющих относительно простую интерактивность (приложения Интернет мультимедиа).

      4. Главный визуальный профайл добавляет поддержку кодирования черезстрочных, полупрозрачных, и виртуальных объектов в центральном визуальном профайле. Он полезен для интерактивного широковещательного обмена (с качеством для развлечений) и для DVD-приложений.

      5. N-битный визуальный профайл добавляет поддержку кодирования видео объектов, имеющих пиксельную глубину в диапазоне от 4 до 12 бит в главный визуальный профайл. Он удобен для использования в приложениях для наблюдения.

      Профайлами для синтетических и синтетико-натуральных гибридных визуальных материалов являются:

      6. Простой визуальный профайл для анимации лица (Simple Facial Animation) предоставляет простые средства анимации модели лица, удобные для таких приложений как аудио/видео презентации лиц с ухудшенным слухом.

      7. Визуальный масштабируемый профайл для текстур (Scalable Texture Visual) предоставляет пространственное масштабируемое кодирование статических объектов изображений (текстур), полезное для приложений, где нужны уровни масштабируемости, такие как установление соответствия между текстурой и объектами игр, а также работа с цифровыми фотокамерами высокого разрешения.

      8. Визуальный профайл базовых анимированных 2-D текстур (Basic Animated 2-D Texture) предоставляет пространственную масштабируемоcть, SNR- масштабируемоcть, и анимацию, базирующуюся на сетках для статических объектов изображений (текстур), а также простую анимацию объектов лица.

      9. Гибридный визуальный профайл комбинирует возможность декодировать масштабируемые объекты натурального видео произвольной формы (как в главном визуальном профайле) с возможностью декодировать несколько синтетических и гибридных объектов, включая анимационные статические объекты изображения. Он удобен для различных сложных мультимедиа приложений.

      Версия 2 добавляет следующие профайлы для натурального видео:

      10. Профайл ARTS (Advanced Real-Time Simple) предоставляет продвинутый метод кодирования прямоугольных видео объектов устойчивый к ошибкам, использующий обратный канал и улучшенную стабильность временного разрешения при минимальной задержке буферизации. Он удобен для кодирования в случае приложений реального времени, таких как видеотелефон, телеконференции и удаленное наблюдение.

      11. Центральный масштабируемый профайл добавляет поддержку кодирования объектов произвольной формы с пространственным и временным масштабированием в центральный профайл. Главная особенность этого профайла является SNR, и пространственная и временная масштабируемость для областей и объектов, представляющих интерес. Он полезен для таких приложений как Интернет, мобильные сети и широковещание.

      12. Профайл ACE (Advanced Coding Efficiency) улучшает эффективность кодирования для прямоугольных объектов и объектов произвольной формы. Он удобен для таких приложений как мобильный широковещательный прием, и другие приложения, где необходимо высокая эффективность кодирования.

      Профайлы версии 2 для искусственного и синтетического/натурального гибридного визуального материала:

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

      14. Продвинутый центральный профайл комбинирует возможность декодирования видео объектов произвольной формы (как в центральном визуальном профайле) с возможностью декодирования масштабируемых статических объектов произвольной формы (как в продвинутом масштабируемом профайле текстур.) Он удобен для различных мультимедийных приложений, таких как интерактивная передача потоков мультиимедиа через Интернет.

      15. Профайл простой анимации лица и тела является супернабором профайла простой анимации лица с добавлением анимации тела.

      В последующих версиях будут добавлены следующие профайлы:

      16. Продвинутый простой профайл выглядит как простой, здесь он содержит только прямоугольные объекты, но он имеет несколько дополнительных средств, которые делают его более эффективным: B-кадры, компенсация перемещения ¼ пикселя и компенсация общего перемещения.

      17. Масштабируемый профайл тонкой гранулярности допускает большое число масштабных уровней - до 8 - так что качество доставки можно легко адаптировать к условиям передачи и декодирования. Он может использоваться с простым или продвинутым простым в качестве базового уровня.

      18. Простой студийный профайл является профайлом с очень высоким качеством для применения в приложениях студийного редактирования. Он работает только с I-кадрами, но он действительно поддерживает произвольные формы и большое число alpha-каналов. Возможная скорость передачи достигает 2 Гбит/c.

      19. Центральный студийный профайл добавляет P-кадры к простому студийному варианту ( Simple Studio), делая его более эффективным, но требующим более сложной реализации.

      5.2. Аудио профайлы

      Определены четыре аудио-профайла в MPEG-4 V.1:

      1. Разговорный профайл предоставляет HVXC, который является параметрическим кодером голоса, рассчитанным на очень низкие скорости передачи, CELP узкополосным/широкополосным кодером голоса, или интерфейсом текст-голос.
      2. Профайл синтеза предоставляет собой синтез, использующий SAOL, волновые таблицы и интерфейс текст-голос для генерации звука и речи при очень низких скоростях передачи.
      3. Масштабируемый профайл, супер набор профайла речи, удобен для масштабируемого кодирования речи и музыки для таких сетей, как Интернет и NADIB (Narrow band Audio DIgital Broadcasting). Диапазон скоростей передачи лежит в пределах от 6 кбит/с до 24 кбит/с, при ширине полосы 3.5 и 9 кГц.
      4. Главный профайл является расширенным супер набором всех других профайлов, содержащий средства для синтетического и естественного аудио.

      Еще четыре профайла добавлено в MPEG-4 V.2:

      1. Профайл высококачественного аудио содержит кодировщик голоса CELP и простой кодировщик AAC, содержащий систему долгосрочного предсказания. Масштабируемое кодирование может быть выполнено с помощью AAC масштабируемого объектного типа. Опционно, может использоваться синтаксис потока, устойчивый к ошибкам (ER).
      2. Профайл аудио с низкой задержкой (Low Delay Audio) содержит HVXC и CELP кодировщики голоса (опционно использующие синтаксис ER), AAC-кодеры с низкой задержкой и интерфейс текст-голос TTSI.
      3. Профайл натурального аудио содержит все средства кодирования натурального аудио, доступные в MPEG-4.
      4. Профайл межсетевого мобильного аудио (Mobile Audio Internetworking) содержит AAC масштабируемые объектные типы с малой задержкой, включая TwinVQ и BSAC. Этот профайл предназначен для расширения телекоммуникационных приложений за счет алгоритмов не-MPEG кодирования речи с возможностями высококачественного аудио кодирования.

      5.3. Профайлы графики

      Профайлы графики определяют, какие графические и текстовые элементы могут использоваться в данной сцене. Эти профайлы определены в системной части стандарта:

      1. Простой 2-D графический профайл предоставляется только для графических элементов средства BIFS, которым необходимо разместить один или более визуальных объектов в сцене.
      2. Полный 2-D графический профайл предоставляет двухмерные графические функции и supports такие возможности как произвольная двухмерная графика и текст, если требуется, в сочетании с визуальными объектами.
      3. 3. Полный графический профайл предоставляет продвинутые графические элементы, такие как сетки и экструзии и позволяет формировать содержимое со сложным освещением. Полный графический профайл делает возможными такие приложения, как сложные виртуальные миры, которые выглядят достаточно реально.
      4. 3D аудио графический профайл имеет противоречивое на первый взгляд название, в действительности это не так. Этот профайл не предлагает визуального рэндеринга, а предоставляет графические средства для определения акустических свойств сцены (геометрия, акустическое поглощение, диффузия, прозрачность материала). Этот профайл используется для приложений, которые осуществляют пространственное представление аудио сигналов в среде сцены.

      5.4. Графические профайлы сцены

      Графические профайлы сцены (или профайлы описания сцены), определенные в системной части стандарта, допускают аудио-визуальные сцены только аудио, 2-мерным, 3-мерным или смешанным 2-D/3-D содержимым.

      1. Графический профайл аудио сцены предоставляется для набора графических элементов сцены BIFS для применение исключительно в аудио приложениях. Графический профайл аудио сцены поддерживает приложения типа широковещательного аудио.
      2. Графический профайл простой 2-D сцены предоставляется только для графических элементов BIFS, которым необходимо разместить один или более аудио-визуальных объектов на сцене. Графический профайл простой 2-D сцены допускает презентации аудио-визуального материала, допускающий коррекцию, но без интерактивных возможностей. Графический профайл простой 2-D сцены поддерживает приложения типа широковещательного телевидения.
      3. Графический профайл полной 2-D сцены предоставляется для всех элементов описания 2-D сцены средства BIFS. Он поддерживает такие возможности, как 2-D преобразования и alpha-сглаживание. Графический профайл полной 2-D сцены делает возможными 2-D приложения, которые требуют широкой интерактивности.
      4. Графический профайл полной сцены предоставляет полный набор графических элементов сцены средства BIFS. Графический профайл полной 2-D сцены сделает возможными приложения типа динамического виртуального 3-D мира и игр.
      5. Графический профайл 3D аудио сцены предоставляет средства трехмерного позиционирования звука в отношении с акустическими параметрами сцены или ее атрибутами, характеризующими восприятие. Пользователь может взаимодействовать со сценой путем изменения позиции источника звука, посредством изменения свойств помещения или перемещая место слушателя. Этот профайл предназначен для использования исключительно аудио-приложениями.

      5.5. Профайлы MPEG-J

      Существуют два профайла MPEG-J: персональный и главный:

      1. Персональный - небольшой пакет для персональных приборов.

      Персональный профайл обращается к ряду приборов, включая мобильные и портативные аппараты. Примерами таких приборов могут быть видео микрофоны, PDA, персональные игровые устройства. Этот профайл включает в себя следующие пакеты MPEG-J API:

      a) Сеть
      b) Сцена
      c) Ресурс

      1. Главный - включает все MPEG-J API.

      Главный профайл обращается к ряду приборов, включая средства развлечения. Примерами таких приборов могут служить набор динамиков, компьютерные системы мультимедиа и т.д. Он является супер набором персонального профайла. Помимо пакетов персонального профайла, этот профайл содержит следующие пакеты MPEG-J API:

      a) Декодер
      b) Функции декодера
      c) Секционный фильтр и сервисная информация

      5.6. Профайл дескриптора объекта

      Профайл описания объекта включает в себя следующие средства:

      • Средство описания объекта (OD)
      • Средство слоя Sync (SL)
      • Средство информационного содержимого объекта (OCI)
      • Средство управления и защиты интеллектуальной собственности (IPMP)

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

      6. Верификационное тестирование: проверка работы MPEG

      MPEG выполняет верификационные тесты для проверки того, предоставляет ли стандарт то, что должно быть. Результаты испытаний можно найти на базовой странице MPEG: http://www.cselt.it/mpeg/quality_tests.htm

      6.1. Видео
      6.1.1. Тесты эффективности кодирования
      6.1.1.1. Низкие и средние скорости передачи бит (версия 1)

      При испытаниях для низкой и средней скорости передачи, рассматривались последовательности кадров, которые следуют стандарту MPEG-1. (MPEG-2 будет идентичным для прогрессивных последовательностей за исключением того, что MPEG-1 немного более эффективен, так как имеет несколько меньшую избыточность заголовков). Тест использует типовую тестовую последовательность для разрешений CIF и QCIF, закодированный с идентичными условиями по скорости передачи для MPEG-1 и MPEG-4. Тест был выполнен для низких скоростей от 40 кбит/с до 768 кбит/с.

      Тесты эффективности кодирования показывают полное превосходство MPEG-4 перед MPEG-1 как на низкой, так и на средней скорости передачи.

      6.1.1.2. Кодирование, базирующееся на содержимом (версия 1)

      Верификационные тесты для кодирования, базирующегося на содержимом, сравнивают визуальное качество кодирования object-based и frame-based. Главным соображением было гарантировать, чтобы object-based кодирование можно было поддерживать без ухудшения визуального качества. Содержимое теста было выбрано так, чтобы перекрыть широкий спектр условий моделирования, включая видео сегменты с различными типами движения и сложностью кодирования. Кроме того, условия теста были выбраны так, чтобы перекрыть низкие скорости передачи в диапазоне от 256 кбит/с до 384 кбит/с, и высокие скорости передачи в диапазоне от 512кбит/с до 1.15 Мбит/с. Результаты тестов ясно продемонстрировали, что объектно-ориентированная функциональность, предоставляемая MPEG-4, не имеет избыточности или потерь визуального качества, по сравнению с кодированием frame-based. Не существует статистически значимого различия между вариантами object-based и frame-based.

      6.1.1.3. Профайл продвинутой эффективности кодирования ACE (Advanced Coding Efficiency) (версия 2)

      Формальные верификационные тесты профайла ACE (Advanced Coding Efficiency) были выполнены с целью проверки, улучшают ли эффективность кодирования три новые средства версии 2, включенные в визуальный ACE профайл MPEG-4 версии 2 (компенсация общего перемещения, компенсация перемещения на четверть пикселя и адаптированное к форме преобразование DCT), по сравнению с версией 1. Тесты исследуют поведение ACE профайла и главного визуального профайла MPEG-4 версия 1 в режимах object-based и frame-based при низкой скорости передачи, frame-based при высокой скорости передачи. Полученные результаты показывают преимущество ACE профайла перед главным профайлом. Ниже приведены некоторые детали сопоставления работы этих профайлов:

      • Для объектно-ориентированного случая, качество, предоставляемое профайлом ACE при 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 384 кбит/с.
      • Для кадр-ориентированного случая, качество, предоставляемое профайлом ACE при 128 кбит/с и 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 256 кбит/с и 384 кбит/с соответственно.
      • Для кадр-ориентированного случая при высоких скоростях передачи, качество, предоставляемое профайлом ACE при 768 кбит/с равно качеству, обеспечиваемому главным профайлом при 1024 кбит/с.

      При интерпретации этих результатов, нужно заметить, что главный профайл MPEG-4 более эффективен, чем MPEG-1 и MPEG-2.

      6.1.2. Тесты устойчивости к ошибкам
      6.1.2.1. Простой профайл (версия 1)

      Устойчивость видео к ошибкам в простом профайле MPEG-4 была оценена в ходе тестов, которые симулируют видео MPEG-4, выполненных при скоростях между 32 кбит/с и 384 кбит/с. Испытания произведены при BER < 10-3, и средней длине блока ошибок около 10мс. Тестовая методология базировалась на непрерывной оценке качества в течение 3 минут.

      Результаты показывают, что в среднем качество видео, полученное для мобильного канала, является высоким, что воздействие ошибок в видео MPEG-4 остается локальным, и что качество быстро восстанавливается по завершении блока ошибок.

      6.1.2.2. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)

      Устойчивость видео к ошибкам в MPEG-4 профайле ARTS была оценена в ходе тестов, аналогичных описанным выше, при скоростях между 32 кбит/с и 128 кбит/с. В этом случае, остаточный уровень ошибок достигал 10-3, а средняя длительность блока ошибок была около 10 мс или 1 мс.

      Результаты испытаний показывают превосходство профайла ARTS над простым профайлом для всех параметров исследования. Профайл ARTS предпочтительнее простого по времени восстановления после прохождения блока ошибок.

      6.1.3. Тестирование стабильности временного разрешения
      6.1.3.1. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)

      В данном тесте исследовались характеристики видео кодека, использующего технику преобразования с динамическим разрешением, которая адаптирует разрешение видео материала к обстоятельствам в реальном времени. Материал активной сцены кодировался при скоростях 64 кбит/с, 96 кбит/с и 128 кбит/с. Результаты показывают, что при 64 кбит/с, он превосходит простой профайл, работающий при 96 кбит/с, а при 96 кбит/с, визуальное качество эквивалентно полученному для простого профайла при 128 кбит/с.

      6.1.4. Проверки масштабируемости
      6.1.4.1. Простой масштабируемый профайл (версия 1)

      Тест масштабируемости для простого масштабируемого профайла был создан для проверки того, что качество, обеспечиваемое средством временной масштабируемости в простом, масштабируемом профайле, сравненное с качеством, предоставляемым одноуровневым кодированием в простом профайле, и с качеством, обеспечиваемым в простом профайле. В этом тесте используются 5 последовательностей с 4 комбинациями скоростей передачи:

      a) 24 кбит/с для базового слоя и 40 кбит/с для улучшенного слоя.
      b) 32 кбит/с для обоих слоев.
      c) 64 кбит/с для базового слоя и 64 кбит/с для улучшенного слоя.
      d) 128 кбит/с для обоих слоев.

      Формальные верификационные тесты показали, что при всех условиях, кодирование с временной масштабируемостью в простом масштабируемом профайле демонстрирует то же или несколько худшее качество, чем достижимое при использовании однослойного кодирования в простом профайле. Далее, очевидно, что кодирование с временной масштабируемостью в простом масштабируемом профайле обеспечивает лучшее качество, чем симулкастное (одновременная передача по радио и телевидению или передача несколькими потоками с разной скоростью) кодирование в простом профайле для тех же условий.

      6.1.4.2. Центральный профайл (core profile версия 1)

      Верификационный тест был создан для оценки характеристик средств временной масштабируемости MPEG-4 видео в центральном профайле (Core Profile).

      Тестирование было выполнено с использованием метода "Single Stimulus". Тест создавался с использованием 45 субъектов из двух различных лабораторий. Результаты испытаний показывают, что качество последовательностей, закодированных с привлечением средств временного масштабирования сопоставимы по качеству с вариантом без масштабирования. Очевидно также, что средство временного масштабирования в центральном профайле обеспечивает лучшее качество при равных условиях, чем симулкастное кодирование в центральном профайле.

      6.2. Звук

      Аудио-технология MPEG-4 состоит из большого числа средств кодирования. Верификационные тесты выполнялись в основном для небольшого набора средств кодирования, которые имеет сходные области использования, чтобы их можно было сравнивать. Так как сжатие является критическим параметром в MPEG, сравнение производилось при сходных скоростях обмена.

      Оценка

      Характеристика восприятия

      5

      Неощутимо

      4

      Ощутимо, но не раздражающе

      3

      Слегка раздражающе

      2

      Раздражающе

      1

      Весьма плохо

      Первоначальной целью тестов является получение субъективного уровня качества средства кодирования, работающего при заданной скорости обмена. Большинство аудио тестов представляют результаты в виде субъективной шкалы оценки качества. Это непрерывная шкала с максимальным значением 5 баллов, как это показано в табличке выше.

      Работа различных средств кодирования MPEG-4 представлена в таблице ниже. Для лучшей оценки свойств технологии MPEG-4 в тесты были включены несколько кодировщиков от MPEG-2 и ITU-T и их оценка также включены в таблицу. Результаты из различных тестов не следует сравнивать.

      Средство кодирования

      #каналов

      Общая скорость передачи

      [кбит/c]

      Типовое значение субъективного качества

      AAC

      5

      320

      4.6

      1995 обратно совместимый MPEG-2 слой II

      5

      640

      4.6

      AAC

      2

      128

      4.8

      AAC

      2

      96

      4.4

      MPEG-2 слой II

      2

      192

      4.3

      MPEG-2 слой III

      2

      128

      4.1

      AAC

      1

      24

      4.2

      Масштабируемый: CELP база и улучшение AAC

      1

      6 base, 18 enh.

      3.7

      Масштабируемый: Twin VQ база и улучшение AAC

      1

      6 base, 18 enh.

      3.6

      AAC

      1

      18

      3.2

      G.723

      1

      6.3

      2.8

      Широкополосный CELP

      1

      18.2

      2.3

      BSAC

      2

      96

      4.4

      BSAC

      2

      80

      3.7

      BSAC

      2

      64

      3.0

      AAC - LD (однопроходная задержка 20 мсек)

      1

      64

      4.4

      G.722

      1

      32

      4.2

      AAC - LD (однопроходная задержка 30 мсек)

      1

      32

      3.4

      Узкополосный CELP

      1

      6

      2.5

      Twin VQ

      1

      6

      1.8

      HILN

      1

      16

      2.8

      HILN

      1

      6

      1.8

      При кодировании 5-канального материала при 64 кбит/с/канал (320 кбит/с) Продвинутое кодирование аудио AAC (Advanced Audio Coding) главного профайла было оценено как имеющее "неотличимое качество" (относительно оригинала) согласно определению EBU. При кодировании 2- канального материала при 128 кбит/с как AAC главного профайла так и AAC профайла низкой сложности были оценены как имеющие "неотличимое качество" (относительно оригинала) согласно определению EBU.

      Два масштабируемых кодировщика, CELP-база с улучшение AAC, и TwinVQ база с улучшением AAC, работают лучше чем AAC "multicast", работающий при скорости передачи уровня улучшения, но не так хороши как кодировщик AAC, работающий при полной скорости передачи.

      Широкополосное кодирующее средство CELP демонстрирует прекрасные характеристики только для голоса.

      Побитовое арифметическое кодирование (BSAC) предоставляет весьма малые шаги масштабирования. На верху диапазона масштабирования это кодирование не имеет штрафных балов по отношению к AAC, однако в нижней части диапазона оно уступает односкоростной AAC.

      Узкополосный CELP, TwinVQ и индивидуальные гармонические линии и шум (HILN) все могут обеспечить очень высокое сжатие сигнала.

      Средства противодействия ошибкам (ER) обеспечивают эквивалентно хорошую устойчивость к ошибкам в широком диапазоне условий канальных ошибок, и делают это с достаточно малой избыточностью по скорости передачи.

      7. Промышленный форум MPEG-4

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

      • Целью M4IF будет: продвижение MPEG-4, предоставление информации об MPEG-4, предоставление средств MPEG-4 или указание мест, где эти данные можно получить, формирование единого представления об MPEG-4.
      • Цели реализуются через открытое международное сотрудничество всех заинтересованных участников.
      • Деятельность M4IF не преследует целей получения финансовой прибыли.
      • Любая корпорация и частная фирма, государственный орган или интернациональная организация, поддерживающая цели M4IF может являться членом форума.
      • Члены не обязаны внедрять или использовать специфические технологические стандарты или рекомендации в качестве следствия своего членства в M4IF.
      • Не существует каких-либо лицензионных требований, налагаемых членством в M4IF, и M4IF не налагает лицензионных ограничений на использование технологии MPEG-4.
      • Начальный членский взнос равен 2,000 $ в год.

      M4IF имеет свою WEB-страницу: http://www.m4if.org

      Деятельность M4IF начинается там, где кончается активность MPEG. Сюда входят позиции, с которыми MPEG не может иметь дело, например, из-за правил ISO, таких как патентная чистота.

      8. Детальное техническое описание MPEG-4 DMIF и систем

      Рис. 3 показывает как потоки, приходящие из сети (или запоминающего устройства), как потоки TransMux, демультиплексируются в потоки FlexMux и передаются соответствующим демультиплексорам FlexMux, которые извлекают элементарные потоки. Элементарные потоки (ES) анализируются и передаются соответствующим декодерам. Декодирование преобразует данные в AV объект и выполняет необходимые операции для реконструкции исходного объекта AV, готового для рэндеринга на соответствующем аппарате. Аудио и визуальные объекты представлены в их кодированной форме, которая описана в разделах 10 и 9 соответственно. Реконструированный объект AV делается доступным для слоя композиции при рэндеринга сцены. Декодированные AVO, вместе с данными описания сцены, используются для композиции сцены, как это описано автором. Пользователь может расширить возможности, допущенные автором, взаимодействовать со сценой, которая отображается.

      Рис. 3. Главные компоненты терминала MPEG-4 (принимающая сторона)

      8.1. DMIF

      DMIF (Delivery Multimedia Integration Framework) является протоколом сессии для управления мультимедийными потоками поверх общих средств доставки данных. В принципе это имеет много общего с FTP. Единственное (существенное) отличие заключается в том, что FTP предоставляет данные, DMIF предоставляет указатели, где получить данные (streamed).

      Когда работает FTP, первым действием, которое производит протокол, является установление сессии с удаленным партнером. Далее, выбираются файлы, и FTP посылает запрос об их передаче, партнер FTP пересылает файл через отдельное, сформированное для этой цели соединение.

      Аналогично, когда работает DMIF, первым действием, которое он выполняет, является установление сессии с удаленным партнером. Позднее, выбираются потоки и DMIF посылает запрос, передать их, партер DMIF в отклике пришлет указатель на соединение, где будут проходить потоки, и затем также устанавливает соединение.

      По сравнению с FTP, DMIF является системой и протоколом. Функциональность, предоставляемая DMIF, определяется интерфейсом, называемым DAI (DMIF-Application Interface), и реализуется через протокольные сообщения. Эти протокольные сообщения для разных сетей могут отличаться.

      При конструировании DMIF рассматривается и качество обслуживания (QoS), а DAI позволяет пользователю DMIF специфицировать требования для нужного потока. Проверка выполнения требований оставляется на усмотрение конкретной реализации DMIF. Спецификация DMIF предоставляет советы, как решать такие задачи на новом типе сети, таком, например, как Интернет.

      Интерфейс DAI используется для доступа к широковещательному материалу и локальным файлам, это означает, что определен один, универсальный интерфейс для доступа к мультимедийному материалу для большого числа технологий доставки.

      Как следствие, уместно заявить, что интегрирующая система DMIF покрывает три главные технологии, интерактивную сетевую технику, широковещательную технологию и работу с дисками; это показано на рис. 4 ниже.

      Рис. 4. DMIF осуществляет интеграцию доставки для трех основных технологий

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

      На рис. 5 представлена указанная выше концепция. Приложение получает доступ к данным через интерфейс приложения DMIF, вне зависимости от того, откуда получены данные: от широковещательного источника, локальной памяти или от удаленного сервера. Во всех сценариях локальное приложение только взаимодействует через универсальный интерфейс (DAI). Различные варианты DMIF будут затем транслировать запросы локального приложения в специфические сообщения, которые должны быть доставлены удаленному приложению, учитывая особенности используемых технологий доставки. Аналогично, данные, поступающие на терминал (из удаленного сервера, широковещательных сетей или локальных файлов) доставляются локальному приложению через DAI.

      Специализированные версии DMIF подключаются приложением апосредовано, чтобы управлять различными специфическими технологиями доставки данных, это, однако прозрачно для приложения, которое взаимодействует только с одним "DMIF фильтром". Этот фильтр отвечает за управление конкретным примитивом DAI в нужный момент.

      Концептуально, "настоящее" удаленное приложение доступное через сеть, например, через IP или ATM, ничем не отличается от эмулируемого удаленного приложения, получающего материал от широковещательного источника или с диска. В последнем случае, однако, сообщения, которыми обмениваются партнеры, должны быть определены, чтобы обеспечить совместимость (это сигнальные сообщения DMIF). В последнем случае, с другой стороны, интерфейсы между двумя партнерами DMIF и эмулируемым удаленным приложением являются внутренними по отношению реализации и не должны рассматриваться в этой спецификации. Заметим, что для сценариев получения данных широковещательно и из локальной памяти, рисунок показывает цепочку "Локальный DMIF", "Удаленный DMIF (эмулированный)" и "Удаленное приложение (эмулированное)". Эта цепочка представляет концептуальную модель и не должна отражаться в практической реализации (на рисунке она представлена закрашенной областью).

      Рис. 5. Архитектура коммуникаций DMIF

      При рассмотрении сценариев с широковещанием и локальной памятью предполагается, что эмулируемое удаленное приложение знает, как данные доставлены/запомнены. Это подразумевает знание типа приложения, с которым осуществляется взаимодействие. В случае MPEG-4, это в действительности предполагает знание идентификатора элементарного потока, дескриптора первого объекта, названия услуги. Таким образом, в то время как уровень DMIF концептуально не знает ничего о приложении, которое поддерживает, в частном случае работы DMIF с широковещанием и локальной памятью это утверждение не вполне корректно из-за присутствия эмулированного удаленного приложения (которое, с точки зрения локального приложения является частью слоя DMIF).

      При рассмотрении сценария удаленного взаимодействия, слой DMIF ничего не знает о приложении. Введен дополнительный интерфейс DNI (DMIF-Network Interface), который служит для подчеркивания того, какого рода информацией должны обмениваться партнеры DMIF. Дополнительные модули SM (Signaling mapping) служат для установления соответствия между примитивами DNI и сигнальными сообщениями, используемыми в конкретной сети. Заметим, что примитивы DNI специфицированы для информационных целей, и интерфейс DNI в настоящей реализации может отсутствовать.

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

      8.1.1. Вычислительная модель DMIF

      Когда приложение запрашивает активацию услуги, оно использует сервисный примитив DAI, и формирует соответствующую сессию. Реализация DMIF устанавливает контакт с соответствующим партнером (который концептуально может быть либо удаленным, либо эмулируемым локальным партнером) и формирует вместе с ним сетевую сессию. В случае широковещательного и локального сценариев, способ формирования и управления сессией находится вне зоны ответственности данного документа. В случае интерактивного сценария с удаленным сервером, DMIF использует свой сигнальный механизм для формирования и управления сессией, например, сигнальный механизм ATM. Приложения партнеров используют эту сессию для установления соединения, которое служит для передачи прикладных данных, например, элементарных потоков MPEG-4.

      Когда приложению нужен канал, оно использует примитивы канала DAI, DMIF транслирует эти запросы в запросы соединения, которые являются специфическими для конкретных запросов сетевых реализаций. В случае сценариев широковещания и локальной памяти, метод установления соединения и последующего управления находится за пределами регламентаций MPEG-4. В случае сетевого сценария напротив, DMIF использует свой сигнальный механизм для формирования и управления соединением. Это соединение используется приложением для целей доставки данных.

      На рис. 6 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа:

      • Приложение-инициатор посылает запрос активизации услуги своему локальному слою DMIF - коммуникационное соединение между приложением-инициатором и его локальным партнером DMIF устанавливается в контрольной плоскости (1)
      • Партнер-инициатор DMIF запускает сетевую сессию с партнером-адресатом DMIF - коммуникационное соединение партнером-инициатором DMIF и партнером-адресатом DMIF устанавливается в контрольной плоскости (2).
      • Партнер-адресат DMIF идентифицирует приложение-адресат и переадресует запрос активации услуги - коммуникационное соединение между партнером-адресатом DMIF и приложением-адресатом устанавливается в контрольной плоскости (3)
      • Приложения партнеров создают каналы (запросы передаются через коммуникационные пути 1, 2 и 3). Результирующие каналы в пользовательской плоскости (4) используются приложениями для реального информационного обмена. DMIF вовлечена во все четыре этапа.

      Рис. 6. Вычислительная модель DMIF

      Слой DMIF автоматически определяет, предполагается ли предоставление данной услуги удаленным сервером в конкретной сети, например, в IP, или ATM, широковещательной сетью, или устройством локальной памяти: выбор основывается на адресной информации партнера, предоставляемой приложением в качестве части URL, переданной DAI.

      8.2. Демультиплексирование, синхронизация и описание потоков данных

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

      Для целей интегрирования MPEG-4 в системную среду, интерфейс приложения DMIF является точкой, где можно получить доступ к элементарным потокам, как к потокам sync. DMIF является интерфейсом для реализации функций, недоступных в MPEG. Управляющая часть интерфейса рассмотрена в разделе DMIF.

      MPEG-4 определяет модель системного декодера. Это позволяет точно описать операции терминала, не делая ненужных предположений о деталях практической реализации. Это важно для того, чтобы дать свободу разработчикам терминалов MPEG-4 и декодирующих приборов. Это оборудование включает в себя широкий диапазон аппаратов от телевизионных приемников, которые не имеют возможности взаимодействовать с отправителем, до ЭВМ, которые полноценный двунаправленный коммуникационный канал. Некоторые приборы будут получать потоки MPEG-4 через изохронные сети, в то время как другие будут использовать для обмена информацией MPEG-4 асинхронные средства (например, Интернет). Модель системного декодера предоставляет общие принципы, на которых могут базироваться все реализации терминалов MPEG-4.

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

      8.2.1. Демультиплексирование

      Демультиплексирование происходит на уровне доставки, который включает в себя слои TransMux и DMIF. Извлечение входящих информационных потоков из сетевого соединения или из памяти включает в себя два этапа. Во-первых, каналы должны быть найдены и открыты. Это требует наличия некоторого объекта, который осуществляет транспортный контроль и устанавливает соответствие между транспортными каналами и специальными элементарными потоками. Таблица карты таких потоков связывает каждый поток с ChannelAssociationTag (канальной меткой), которая служит указателем для канала, через который идет поток. Определение ChannelAssociationTags для реального транспортного канала, а также управление сессией и каналами осуществляется DMIF-частью стандарта MPEG-4.

      Во-вторых, входящие потоки должны быть соответствующим образом демультиплексированы, чтобы восстановить SL-потоки пакетов от нижележащих каналов (входящих в принимающий терминал). В интерактивных приложениях, соответствующий узел мультиплексирования переправляет данные в вышерасположенные каналы (исходящие из принимающего терминала).

      Базовый термин 'TransMux Layer' используется, чтобы абстрагироваться от нижележащей функциональности - существующей или будущей, которая пригодна для транспортировки потоков данных MPEG-4. Заметим, что этот уровень не определен в контексте MPEG-4. Примерами могут служить транспортный поток MPEG-2, H.223, ATM AAL 2, IP/UDP. Предполагается, что слой TransMux предоставляет защиту и средства мультиплексирования, этот уровень обеспечивает определенный класс QoS. Средства безопасности включают в себя защиту от ошибок и детектирование ошибок, удобное для данной сети или устройств памяти.

      В любом конкретном сценарии приложения используется один или более специфических TransMux. Каждый демультиплексор TransMux предоставляет доступ к каналам TransMux. Требования на информационный интерфейс доступа к каналу TransMux те же, что и для всех интерфейсов TransMux. Они включают необходимость надежного детектирования ошибок, доставки, если возможно, ошибочных данных с приемлемой индикацией ошибок и кадрирование поля данных, которое может включать потоки либо SL либо FlexMux. Эти требования реализованы в интерфейсе TransMux (системная часть стандарта MPEG-4). Адаптация потоков SL должна быть специфицирована для каждого стека протоколов.

      Средство FlexMux специфицировано MPEG для того, чтобы опционно предоставить гибкий метод, имеющий малую избыточность и задержку для переукладки данных в тех случаях, когда ниже лежащие протоколы не поддерживают это. Средство FlexMux само по себе недостаточно устойчиво по отношению к ошибкам и может либо использоваться в каналах TransMux с высоким QoS, либо для объединения элементарных потоков, которые достаточно устойчивы к ошибкам. FlexMux требует надежного детектирования ошибок. Эти требования реализованы в информационных примитивах прикладного интерфейса DMIF, который определяет доступ к данным в индивидуальных транспортных каналах. Демультиплексор FlexMux выделяет SL-потоки из потоков FlexMux.

      8.2.2. Синхронизация и описание элементарных потоков

      Рис. 7. Архитектура буферов модели системного декодера

      Слой sync имеет минимальный набор средств для проверки согласованности, чтобы передать временную информацию. Каждый пакет состоит из блока доступа или фрагмента блока доступа. Эти снабженные временными метками блоки образуют единственную семантическую структуру элементарных потоков, которые видны на этом уровне. Временные метки используются для передачи номинального времени декодирования. Уровень sync требует надежного детектирования ошибок и кадрирования каждого индивидуального пакета нижележащего слоя. Как осуществляется доступ к данным для слоя сжатия, определяется интерфейсом элементарных потоков, описание которого можно найти в системной части стандарта MPEG-4. Слой sync извлекает элементарные потоки из потоков SL.

      Чтобы с элементарные потоки могли взаимодействовать с медиа-объектами в пределах сцены, используются дескрипторы объектов. Дескрипторы объектов передают информацию о номере и свойствах элементарных потоков, которые ассоциированы с конкретными медиа-объектами. Сами дескрипторы объектов передаются в одном или более элементарных потоков, так как допускается добавление и удаление потоков (и объектов) в процессе сессии MPEG-4. Для того чтобы обеспечить синхронизацию, такие модификации помечаются временными метками. Потоки дескрипторов объектов могут рассматриваться как описание потоковых ресурсов презентации. Аналогично, описание сцены также передается как элементарный поток, позволяя модифицировать пространственно-временную картину презентации со временем.

      8.2.3. Управление буфером

      Чтобы предсказать, как декодер будет себя вести, когда он декодирует различные элементарные потоки данных, которые образуют сессию MPEG-4, модель системного декодера (Systems Decoder Mode) позволяет кодировщику специфицировать и мониторировать минимальные буферные ресурсы, необходимые для декодирования сессии. Требуемые буферные ресурсы передаются декодеру в объектных дескрипторах во время установления сессии MPEG-4, так что декодер может решить, может ли он участвовать в этой сессии.

      При управлении конечным буферным пространством модель позволяет отправителю, например, передавать данные, не привязанные к реальному времени, досрочно, если имеется достаточно места в буфере со стороны приемника. Запомненные данные будут доступны в любое время, позволяя использовать для информации реального времени при необходимости большие ресурсы канала.

      8.2.4. Идентификация времени

      Для операции реального времени, модель синхронизации is assumed in which the end-to-end delay from the signal output from an encoder to the signal input to a decoder is constant. Более того, передаваемые потоки данных должны содержать времязадающую информацию в явном или неявном виде. Существует два типа временной информации. Первый тип используется для передачи частоты часов кодировщика, или временной шкалы, декодеру. Второй, состоящий из временных меток, присоединенных к закодированным AV данным, содержит желательное время декодирование для блоков доступа или композиции, а также время истечения применимости композиционных блоков. Эта информация передается в заголовках SL-пакетов сформированных в слое sync. С этой временной информацией, интервалы в пределах картинки и частота стробирования аудио может подстраиваться в декодере, чтобы соответствовать интервалам частоте стробирования на стороне кодировщика.

      Различные медиа-объекты могут кодироваться кодировщиками с различными временными шкалами, и даже с небольшим отличием времязадающих частот. Всегда возможно установить соответствие между этими временными шкалами. В этом случае, однако, никакая реализация приемного терминала не может избежать случайного повторения или потери AV-данных, из-за временного наезда (относительное растяжение или сжатие временных шкал).

      Хотя допускается работа систем без какой-либо временной информации, определение модели буферизации в этом случае невозможно.

      8.3. Улучшенная модель синхронизации (FlexTime)

      Модель FlexTime (Advanced Synchronization Model) расширяет традиционную модель хронирования MPEG-4, чтобы разрешить синхронизацию большого числа потоков и объектов, таких как видео, аудио, текст, графика, или даже программы, которые могут иметь разное происхождение.

      Традиционная модель синхронизации MPEG-4 первоначально была сконструирована для широковещательных приложений, где синхронизация между блоками доступа осуществляется через "жесткие" временные метки и эталонные часы. В то время как этот механизм предоставляет точную синхронизацию внутри потока, он терпит неудачу при синхронизации потоков, приходящих из разных источников (и возможно с разными эталонными часами) как это имеет место в случае большинства приложений Интернет и в более сложных широковещательных приложениях.

      Модель FlexTime позволяет разработчику материала специфицировать простые временные соотношения для выбранных объектов MPEG-4, таких как "CoStart," "CoEnd," и "Meet." Автор материала может также специфицировать ограничения гибкости для объектов MPEG-4, как если бы объекты были растяжимыми пружинами. Это позволяет синхронизовать большое число объектов согласно специфицированным временным соотношениям.

      Наибольшую эффективность внедрение этой техники может дать в случае приложений Интернет, где нужно синхронизовать большое число источников на стороне клиента.

      8.3.1. Гибкая длительность

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

      Для того чтобы понизить чувствительность к задержке времени доставки, модель FlexTime основывается на так называемой метафоре "пружины", смотри раздел 4.2.3.

      Следуя модели пружины, элементарные потоки, или фрагменты потоков, рассматриваются как пружины, каждый с тремя 3 ограничениями. Оптимальная длина (длительность воспроизведения потока) может рассматриваться как подсказка получателю, когда возможны варианты. Заметим, что при растяжении или сжатии длительности непрерывной среды, такой как видео, подразумевает соответствующее замедление или ускорение воспроизведения, когда элементарный поток состоит из статических картинок. В этом случае растяжение или сжатие предполагает удержание изображения на экране в течение большего или меньшего времени.

      8.3.2. Относительное время начала и конца

      Два или более элементарных потоков или потоков сегментов могут быть синхронизованы друг относительно друга, путем определения того, что они начинаются ("CoStart") или кончаются ("CoEnd") в одно и то же время или завершение одного совпадает с началом другого ("Meet").

      Важно заметить, что существует два класса объектов MPEG-4. Синхронизация и рэндеринг объекта MPEG-4, который использует элементарный поток, такого как видео, не определяется одним потоком, но также соответствующими узлами BIFS и их синхронизацией. В то время как синхронизация и рэндеринг объекта MPEG-4, который не использует поток, такой как текст или прямоугольник, определяется только соответствующими узлами BIFS и их синхронизацией.

      Модель FlexTime позволяет автору материала выражать синхронизацию объектов MPEG-4 с потоками или сегментами потоков, путем установления временных соотношений между ними.

      Временные соотношения (или относительные временные метки) могут рассматриваться как "функциональные" временные метки, которые используются при воспроизведении. Таким образом, действующее лицо FlexTime может:

      1. Компенсировать различные сетевые задержки с помощью поддержки синхронизованной задержки прибытия потока, прежде чем действующее лицо начнет рэндеринг/воспроизведение ассоциированного с ним узла.
      2. Компенсировать различные сетевые разбросы задержки путем поддержки синхронизованного ожидания прибытия сегмента потока.
      3. Синхронизовать большое число медиа/BIFS-узлов с некоторым медиа потоком неизвестной длины или неуправляемым временем прибытия.
      4. Синхронизовать модификации BIFS (например, модификации полей сцены) при наличии большого числа узлов/потоков, когда некоторые потоки имеют неизвестную длину или неуправляемое время прибытия.
      5. Замедлять или ускорять рэндеринг/воспроизведение частей потоков, чтобы компенсировать ситуации не синхронности, вызванные неизвестной длиной, неуправляемым временем прибытия или его вариацией.

      8.3.3. Поддержка FlexTime в MPEG-4

      Модель FlexTime поддерживается в MPEG-4 двумя узлами: TemporalTransform и TemporalGroup, и дескриптором: SegmentDescriptor. Узел TemporalTransform специфицирует временные свойства объекта MPEG-4, который нуждается в синхронизации. Узел TemporalGroup специфицирует временные соотношения между объектами, которые представлены узлами TemporalTransform, а SegmentDescriptor идентифицирует доли потока, которые могут быть синхронизованы.

      8.3.3.1. Узел TemporalTransform

      TemporalTransform поддерживает синхронизацию узлов в пределах сцены с медиа потоком, или его сегментом, и поддерживает гибкое преобразование ко времени сцены. Этот группирующий узел может гибко поддерживать замедление, ускорение, замораживание или смещение временной шкалы сцены для рэндеринга узлов содержащихся в ней. Его дочернее поле может содержать список узлов типа SF3Dnode, а узел может влиять на замедление, ускорение, замораживание или смещение временной шкалы композитора, когда он осуществляет рэндеринг дочерних узлов, которые преобразованы этим узлом. Кроме того, этот узел имеет поле url, которое может ссылаться на элементарный поток или его сегмент и в этом случае, узел воздействует на временную шкалу потока, указанного в ссылке.

      8.3.3.2. Узел TemporalGroup

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

      8.3.3. Дескриптор сегмента (SegmentDescriptor)

      Массив SegmentDescriptors добавляется в качестве составного элемента в ES_Descriptor. SegmentDescriptor идентифицирует и помечает сегмент потока, так что отдельные сегменты потока могут быть адресуемы с помощью их полей url в узле TemporalTansform.

      8.3.4. Модель исполнения

      Временное декодирование и настройка часов медиа потоков в соответствии с временными метками является функцией слоя sync. Модель FlexTime требует небольшого изменения модели буферизации MPEG-4 и декодирования. Декодирование может быть задержано у клиента, по отношению к стандартному времени.

      Модель буферов для flextime может быть специфицировано следующим образом: "В любое время от момента, соответствующего его DTS, вплоть до границы времени, заданной Flextime, AU немедленно декодируется и удаляется из буфера." Так как точное время удаления из буфера декодирования AU может варьироваться, нельзя быть уверенным, что оно будет удалено раньше наихудшего времени (максимальная задержка для медиа-потока). Используя наихудшее время, а не время, заданное DTS, буфер декодирования может управляться и не так, как предписывается MPEG-4.

      8.4. Описание синтаксиса

      MPEG-4 определяет язык синтаксического описания чтобы характеризовать точный двоичный синтаксис для двоичных потоков, несущих медиа-объекты и для потоков с информацией описания сцены. Это уход от прошлого подхода MPEG, использовавшего язык псевдо C. Новый язык является расширением C++, и используется для интегрированного описания синтаксического представления объектов и классов медиа-объектов и сцен. Это предоставляет удобный и универсальный способ описания синтаксиса. Программные средства могут использоваться для обработки синтаксического описания и генерации необходимого кода для программ, которые выполняют верификацию.

      8.5. Двоичный формат описания сцены BIFS (Binary Format for Scene description)

      Кроме обеспечения поддержки кодирования индивидуальных объектов, MPEG-4 предоставляет также возможность создать набор таких объектов в рамках сцены. Необходимая информация композиции образует описание сцены, которая кодируется и передается вместе с медиа-объектами. Начиная с VRML (Virtual reality Modeling Language), MPEG разработал двоичный язык описания сцены, названный BIFS. BIFS расшифровывается как BInary Format for Scenes.

      Для того чтобы облегчить авторскую разработку, а также создание средств манипулирования и взаимодействия, описания сцены кодируются независимо от потоков, имеющих отношение в примитивным медиа-объектам. Специальные меры предпринимаются для идентификации параметров, относящихся к описанию сцены. Это делается путем дифференциации параметров, которые используются для улучшения эффективности кодирования объектов (например, векторы перемещения в алгоритмах видео-кодирования), а также те, которые используются в качестве модификаторов объекта (например, положение объекта на сцене). Так как MPEG-4 должен допускать модификацию последнего набора параметров без необходимости декодировать самих примитивных медиа-объектов, эти параметры помещаются в описание сцены, а не в примитивные медиа-объекты. Следующий список предлагает некоторые примеры информации, представленные в описании сцены.

      Как объекты группируются. Сцена MPEG-4 следует иерархической структуре, которая может быть представлена как ориентированный граф без циклов. Каждый узел графа является медиа-объектом, как показано на рис. 8. Три структуры не обязательно являются статическими; атрибуты узла (например, позиционирующие параметры) могут быть изменены, в то время как узлы могут добавляться, замещаться, или удаляться.

      Рис. 8. Возможная логическая структура сцены

      Как объекты позиционируются в пространстве и времени. В модели MPEG-4, аудиовизуальные объекты имеют протяженность в пространстве и во времени. Каждый медиа-объект имеет локальную координатную систему. Локальная координатная система объекта является той, в которой объект имеет фиксированное пространственно-временное положение и шкалу. Локальная координатная система служит в качестве указателя для манипулирования медиа-объектом в пространстве и во времени. Медиа-объекты позиционируются на сцене путем спецификации координатного преобразования из локальной координатной системы объекта в глобальную систему.

      Выбор значения атрибута. Индивидуальные медиа-объекты и узлы описания сцены демонстрируют набор параметров композиционному слою через который может частично контролироваться их поведение. Среди примеров можно назвать понижение звука (pitch), цвет для синтетических объектов, активация или дезактивация информации улучшения для масштабируемого кодирования и т.д.

      Другие преобразования медиа-объектов. Как упомянуто выше, структура описания сцены и семантика узла подвержены сильному влиянию VRML, включая его модель событий. Это предоставляет MPEG-4 очень богатый набор операторов конструирования сцены, включая графические примитивы, которые могут использоваться для построения сложных сцен.

      8.5.1. Продвинутый формат BIFS

      BIFS версия 2 (продвинутый BIFS) включает в себя следующие новые возможности:

      • Моделирование продвинутой звуковой среды в интерактивных виртуальных сценах, где в реальном времени вычисляются такие характеристики как рефлексы в комнате, реверберация, допплеровсеие эффекты и перегораживание звука объектами, появляющимися между источником и слушателем. Моделирование направленности источника звука позволяет осуществлять эффективное включение звуковых источников в 3-D сцены.
      • Анимация тела с использованием на уровне декодера модели тела по умолчанию или загружаемой модели. Анимация тела осуществляется путем посылки анимационных параметров в общем потоке данных.
      • Применение хроматических ключей, которые служат для формирования формы маски и значения прозрачности для изображения или видео последовательности.
      • Включение иерархических 3-D сеток в BIFS сцен.
      • Установление соответствия интерактивных команд и медийных узлов. Команды передаются серверу через обратный канал для соответстующей обработки.
      • PROTOs и EXTERNPROTOs
      • >

      8.6. Взаимодействие с пользователем

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

      Другие формы взаимодействия на стороне клиента требуют поддержки со стороны синтаксиса описания сцены и должны быть специфицированы в стандарте. Использование структуры событий VRML предоставляет богатую модель, на основании которой разработчики могут создать вполне интерактивный материал.

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

      8.7. IPR идентификация и защита

      MPEG-4 предоставляет механизмы для защиты прав интеллектуальной собственности (IPR). Это достигается путем предоставления кодированных медиа-объектов с опционным набором данных идентификационной интеллектуальной собственности IPI (Intellectual Property Identification), несущим информацию о содержимом, типе содержимого и о владельцах прав на данный материал. Набор данных, если он имеется, является частью дескриптора элементарного потока, который описывает поточную информацию, ассоциированную с медиа-объектом. Номер набора данных, который ассоциируется с каждым медиа-объектом достаточно гибок; другие медиа-объекты могут использовать тот же набор. Предоставление наборов данных позволяет внедрить механизм отслеживания, мониторинга, выставления счетов и защиты от копирования.

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

      Данный подход позволяет конструировать и использовать системы IPMP специфичные для доменов (IPMP-S). В то время как MPEG-4 не стандартизует сами системы IPMP, он стандартизует интерфейс IPMP MPEG-4. Этот интерфейс состоит из IPMP-дескрипторов (IPMP-Ds) и элементарных потоков IPMP (IPMP-ES).

      IPMP-Ds и IPMP-ESs предоставляют коммуникационный механизм взаимодействия систем IPMP и терминала MPEG-4. Определенные приложения могут требовать нескольких систем IPMP. Когда объекты MPEG-4 требуют управления и защиты, они имеют IPMP-D, ассоциированные с ними. Эти IPMP-Ds указывают на то, какие системы IPMP следует использовать и предоставляют информацию о том, как защищать получаемый материал. (Смотри рис. 9).

      Кроме предоставления владельцам интеллектуальной собственности возможности управления и защиты их прав, MPEG-4 предлагает механизм идентификации этих прав с помощью набора данных IPI (Intellectual Property Identification Data Set). Эта информация может использоваться системами IPMP в качестве входного потока процесса управления и защиты.

      Рис. 9. Интерфейсы IPMP в системе MPEG-4

      8.8. Информация содержимого объекта

      MPEG-4 позволяет подсоединять к объектам информацию об их материале. Пользователи стандарта могут использовать этот поток данных 'OCI' (Object Content Information) для передачи текстовой информации совместно с материалом MPEG-4.

      8.9. Формат файлов MPEG-4

      Формат файла MP4 сконструирован так, чтобы информация MPEG-4 имела легко адаптируемый формат, который облегчает обмены, управление, редактирование и представление медиа-материала. Презентация может быть локальной по отношению к системе осуществляющей этот процесс, или осуществляемой через сеть или другой поточный механизм доставки (TransMux). Формат файлов сконструирован так, чтобы не зависеть от конкретного типа протокола доставки, и в тоже время эффективно поддерживать саму доставку. Конструкция основана формате QuickTime╝ компании Apple Computer Inc.

      Формат файла MP4 сформирован из объектно-ориентированных структур, называемых атомами. Каждый атом идентифицируется тэгом и длиной. Большинство атомов описывают иерархию метаданных, несущих в себе такую информацию как индексные точки, длительности и указатели на медиа данные. Это собрание атомов содержится в атоме, называемом 'кино атом'. Сами медиа-данные располагаются где-то; они могут быть в файле MP4, содержащемся в одном или более 'mdat', в медийных информационных атомах или размещаться вне файла MP4 с доступом через URL.

      Мета данные в файле в сочетании с гибкой записью медийных данных в память позволяют формату MP4 поддерживать редактирование, локальное воспроизведение и обмен, и тем самым удовлетворять требованиям интермедиа MPEG4.

      8.10. MPEG-J

      MPEG-J является программной системой a programmatic system (в противоположность параметрической системе MPEG-4 версия 1), которая специфицирует API для кросс-операций медиа-проигрывателей MPEG-4 с программами на Java. Комбинируя среду MPEG-4 и безопасный исполнительный код, разработчики материала могут реализовать комплексный контроль и механизмы обработки их медиа в рамках аудио-визуальной сессии. Блок-схема плеера MPEG-J в среде системного плеера MPEG-4 показана на рис. 10. Нижняя половинка этого рисунка отображает системный параметрический плеер MPEG-4, называемый также средство презентации (ДП). Субсистема MPEG-J, контролирующая ДП, называется средством приложения (Application Engine), показана в верхней половине рис. 10.

      Приложение Java доставляется в качестве отдельного элементарного потока, поступающего на терминал MPEG-4. Оно будет передано MPEG-J, откуда программа MPEG-J будет иметь доступ к различным компонентам и данным плеера MPEG-4. MPEG-J не поддерживает загружаемых декодеров.

      По выше указанной причине, группой был определен набор API с различными областями применения. Задачей API является обеспечение доступа к графу сцены: рассмотрение графа, изменение узлов и их полей, и добавление и удаление узлов графа. Менеджер ресурсов API используется для управления исполнением: он обеспечивает централизованное средство управления ресурсами. API терминальных возможностей (Terminal Capability) используется, когда исполнение программы зависит от конфигурации терминала и его возможностей, как статических (которые не меняются во время исполнения) так и динамических. API медийных декодеров (Media Decoders) позволяет контролировать декодеры, которые имеются в терминале. Сетевое API предлагает способ взаимодействия с сетью, являясь прикладным интерфейсом MPEG-4 DMIF.

      Рис. 10. Положение интерфейсов в архитектуре MPEG-J

      9. Детальное техническое описание визуальной секции MPEG-4

      Визуальные объекты могут иметь искусственное или натуральное происхождение.

      9.1. Приложения видео-стандарта MPEG-4

      MPEG-4 видео предлагает технологию, которая перекрывает широкий диапазон существующих и будущих приложений. Низкие скорости передачи и кодирование устойчивое к ошибкам позволяет осуществлять надежную связь через радио-каналы с ограниченной полосой, что полезно, например, для мобильной видеотелефонии и космической связи. При высоких скоростях обмена, имеются средства, позволяющие передачу и запоминание высококачественного видео на студийном уровне.

      Главной областью приложений является интерактивное WEB-видео. Уже продемонстрированы программы, которые осуществляют живое видео MPEG-4. Средства двоичного кодирования и работы с видео-объектами с серой шкалой цветов должны быть интегрированы с текстом и графикой.

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

      9.2. Натуральные текстуры, изображения и видео

      Средства для естественного видео в визуальном стандарте MPEG-4 предоставляют стандартные технологии, позволяющие эффективно запоминать, передавать и манипулировать текстурами, изображениями и видео данными для мультимедийной среды. Эти средства позволяют декодировать и представлять атомные блоки изображений и видео, называемые "видео объектами" (VO). Примером VO может быть говорящий человек (без фона), который может быть также создан из других AVO (аудио-визуальный объект) в процессе формирования сцены. Обычные прямоугольные изображения образуют специальный случай таких объектов.

      Для того чтобы достичь этой широкой цели функции различных приложений объединяются. Следовательно, визуальная часть стандарта MPEG-4 предоставляет решения в форме средств и алгоритмов для:

      • Эффективного сжатия изображений и видео
      • Эффективного сжатия текстур для их отображения на 2-D и 3-D сетки
      • Эффективного сжатия для 2-D сеток
      • Эффективного сжатия потоков, характеризующих изменяющуюся со временем геометрию (анимация сеток)
      • Эффективного произвольного доступа ко всем типам визуальных объектов
      • Расширенной манипуляции изображениями и видео последовательностей
      • Кодирования, зависящего от содержимого изображений и видео
      • Масштабируемости текстур, изображений и видео
      • Пространственная, временная и качественная масштабируемость
      • Обеспечения устойчивости к ошибкам в среде предрасположенной к сбоям

      9.3. Синтетические объекты

      Синтетические объекты образуют субнабор большого класса компьютерной графики, для начала будут рассмотрены следующие синтетические визуальные объекты:

      ∙ Параметрические описания

      a) синтетического лица и тела (анимация тела в версии 2)
      b) Кодирование статических и динамических сеток Static и Dynamic Mesh Coding with texture mapping

      ∙ Кодирование текстуры для приложений, зависимых от вида

      9.4. Масштабируемое кодирование видео-объектов

      Существует несколько масштабируемых схем кодирования в визуальном MPEG-4: пространственная масштабируемость, временная масштабируемость и объектно-ориентированная пространственная масштабируемость. Пространственная масштабируемость поддерживает изменяющееся качество текстуры (SNR и пространственное разрешение). Объектно-ориентированная пространственная масштабируемость расширяет 'обычные' типы масштабируемости в направлении объектов произвольной формы, так что ее можно использовать в сочетании с другими объектно-ориентированными возможностями. Таким образом, может быть достигнута очень гибкая масштабируемость. Это делает возможным при воспроизведении динамически улучшать SNR, пространственное разрешение, точность воспроизведения формы, и т.д., только для объектов, представляющих интерес, или для определенной области.

      9.5. Устойчивость в среде, предрасположенной к ошибкам

      Разработанная в MPEG новая методика, названная NEWPRED ('new prediction' - новое предсказание), предоставляет быстрое восстановление после ошибок в приложениях реального времени. Она использует канал от декодера к кодировщику. Кодировщик переключает эталонные кадры, приспосабливаясь к условиям возникновения ошибок в сети. Методика NEWPRED обеспечивает высокую эффективность кодирования. Она была проверена в условиях высоких потоков ошибок:

      ∙ Короткие всплески ошибок в беспроводных сетях (BER= 10-3, длительность всплеска 1мс)

      ∙ Потери пакетов в Интернет (вероятность потери = 5%)

      9.6. Улучшенная стабильность временного разрешения с низкой задержкой буферизации

      Еще одной новой методикой является DRC (Dynamic Resolution Conversion), которая стабилизирует задержку буферизации при передаче путем минимизации разброса числа кодовых бит VOP на выходе. Предотвращается отбрасывание больших пакетов, а кодировщик может контролировать временное разрешение даже в высоко активных сценах.

      9.7. Кодирование текстур и статические изображения

      Следующие три новых средства кодирования текстур и статических изображений предлагается в версии V.2:

      • Wavelet tiling (деление на зоны) позволяет делить изображение на несколько составных частей, каждая из которых кодируется независимо. Это означает, что большие изображения могут кодироваться/декодироваться в условиях достаточно низких требований к памяти, и что произвольный доступ к декодеру существенно улучшен.
      • Масштабируемое кодирование формы позволяет кодировать текстуры произвольной формы и статические изображения с привлечением масштабируемости. Используя это средство, декодер может преобразовать изображение произвольной формы с любым желательным разрешением. Это средство позволяет приложению использовать объектно-ориентированную пространственную и качественную масштабируемость одновременно.
      • Средство противодействия ошибкам добавляет новые возможности восстановления при ошибках. Используя пакетирование и технику сегментных маркеров, оно значительно улучшает устойчивость к ошибкам приложений, таких как передача изображения через мобильные каналы или Интернет.

      Упомянутые выше средства используются в двух новых 'продвинутых масштабируемых текстурах' и продвинутом центральном профайле (advanced core profile).

      9.8. Кодирование нескольких видов и большого числа вспомогательных компонентов

      В MPEG-4 видео версии 1 поддерживается до одного альфа-канала на видео канальный слой и определены три типа формы. Все три типа формы, т.е. двоичная форма, постоянная форма и форма с серой шкалой, допускают прозрачность видео объекта. При таком определении MPEG-4 не может эффективно поддерживать такие вещи как многовидовые видео объекты (Multiview Video Objects). В версии 2 введено применение множественных альфа-каналов для передачи вспомогательных компонент.

      Базовой идеей является то, что форма с серой шкалой не является единственной для описания прозрачности видео объекта, но может быть определена в более общем виде. Форма с серой шкалой может, например, представлять:

      • Форму прозрачности
      • Форму несоразмерности (Disparity shape) для многовидовых видео объектов (горизонтальных и вертикальных)
      • Форму глубины (Depth shape) (получаемую посредством лазерного дальномера или при анализе различия)
      • Инфракрасные или другие вторичные текстуры

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

      В качестве примера использования множественных вспомогательных компонентов в случае формы несоразмерности для многовидовых видео объектов описаны ниже.

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

      Мы назначаем области, которые используются для кодирования данных от каждой конкретной камеры как "области интереса" (AOI). Эти AOI могут теперь быть просто определены как видео объекты MPEG-4, и закодированы с их ассоциированными значениями несоразмерности. Из-за возможного отражения объектов в различных видах, а также из-за отклонений цветов или различия экспозиций для разных камер, границы между областями, которые нужно реконструировать на основе разных исходных видов могут оказаться видимыми. Чтобы решить эту проблему, необходимо предварительно обработать пиксели вблизи границ AOI, так чтобы осуществить плавный переход путем интерполяции пикселей из различных смежных видов в пределах переходной области.

      Чтобы реконструировать различные точки зрения из текстуры, проекция поверхности с компенсации несоразмерности формируется из текстурных данных в пределах конкретных AOI, с привлечением карты несоразмерностей, полученной из вспомогательной компоненты, декодированной из видео потока MPEG-4. Каждая AOI обрабатывается независимо, а затем проекции изображений ото всех AOI собираются для получения окончательного вида видео объекта с заданной точки зрения. Эта процедура может быть выполнена для системы с двумя камерами с параллельной установкой, но может быть распространена на случай с несколькими камерами со сходящимися оптическими осями.

      9.8.1. Анимация лица

      'Лицевой анимационный объект' может использоваться для представления анимированного лица. Форма, текстура и выражения лица управляются параметрами определения лица FDP (Facial Definition Parameters) и/или параметрами анимации лица FAP (Facial Animation Parameters). Объект лица содержит базовый вид лица с нейтральным выражением. Это лицо может уже отображено. Оно может также получить немедленно анимационные параметры из потока данных, который осуществит анимацию лица: выражения, речь и т.д. Между тем, могут быть посланы параметры определения, которые изменять облик лица от некоторого базового к заданному лицу со своей собственной формой и (опционно) текстурой. Если это желательно, через набор FDP можно загрузить полную модель лица.

      Анимация лица в MPEG-4 версии 1 предназначена для высоко эффективного кодирования параметров анимации, которые могут управлять неограниченным числом моделей лица. Сами модели не являются нормативными, хотя существуют средства описания характеристик модели. Кадровое и временное-DCT кодирование большой коллекции FAP может использоваться для точной артикуляции.

      Двоичный формат систем для сцены BIFS (Systems Binary Format for Scenes), предоставляет возможности поддержки анимации лица, когда нужны обычные модели и интерпретации FAP:

      1. Параметры определения лица FDP (Face Definition Parameters) в BIFS (модельные данные являются загружаемыми, чтобы конфигурировать базовую модель лица, запомненную в терминале до д екодирования FAP, или инсталлировать специфическую модель лица в начале сессии вместе с информацией о том, как анимировать лицо).
      2. Таблица анимации лица FAT (Face Animation Table) в рамках FDP (загружаемые таблицы функционального соответствия между приходящими FAP и будущими контрольными точками сетки лица. Это дает кусочно-линейную карту входящих FAP для управления движениями лица. Например: FAP может приказать 'open_jaw (500)' (открыть челюсти) и таблица определит, что это означает в терминах перемещения характерных точек;
      3. Интерполяционная методика для лица FIT (Face Interpolation Technique) в BIFS (загружаемое определение карты входящих FAP в общий набор FAP до их использования в характерных точках, которая вычисляется с использованием полиномиальных функций при получении интерполяционного графа лица). Это может использоваться для установления комплексных перекрестных связей FAP или интерполяции FAP, потерянных в потоке, с привлечением FAP, которые доступны для терминала.

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

      9.8.2. Анимация тела

      Тело является объектом способным генерировать модели виртуального тела и анимации в форме наборов 3-D многоугольных сеток, пригодных для отображения (rendering). Для тела определены два набора параметров: набор параметров определения тела BDP (Body Definition Parameter), и набор параметров анимации тела BAP (Body Animation Parameter). Набор BDP определяет параметры преобразования тела по умолчанию в требующееся тело с нужной поверхностью, размерами, и (опционно) текстурой. Параметры анимации тела (BAP), если интерпретированы корректно, дадут разумно высокий уровень результата выражаемого в терминах позы и анимации для самых разных моделей тела, без необходимости инициализировать или калибровать модель.

      Конструкция объекта тело содержит обобщенное виртуальное человеческое тело в позе по умолчанию. Это тело может быть уже отображено. Объект способен немедленно принимать BAP из потока данных, который осуществляет анимацию тела. Если получены BDP, они используются для преобразования обобщенного тела в конкретное, заданное содержимым параметров. Любой компонент может быть равен нулю. Нулевой компонент при отображении тела заменяется соответствующим значением по умолчанию. Поза по умолчанию соответствует стоящей фигуре. Эта поза определена следующим образом: стопы ориентированы в фронтальном направлении, обе руки размещаться вдоль тела с ладонями повернутыми внутрь. Эта поза предполагает также, что все BAP имеют значения по умолчанию.

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

      Стандарт анимации тела был разработан MPEG в сотрудничестве с Рабочей группой анимации гуманоидов (Humanoid Animation Working Group) в рамках консорциума VRML.

      9.8.3. Анимируемые 2-D сетки

      Сетка 2-D mesh является разложением плоской 2-D области на многоугольные кусочки. Вершины полигональных частей этой мозаики называются узловыми точками сетки. MPEG-4 рассматривает только треугольные сетки, где элементы мозаики имеют треугольную форму. Динамические 2-D сетки ссылаются на сетки 2-D и информацию перемещения всех узловых точек сетки в пределах временного сегмента интереса. Треугольные сетки использовались в течение долгого времени для эффективного моделирования формы 3-D объектов и воспроизведения в машинной графики. Моделирование 2-D сеток может рассматриваться как проекцию треугольных 3-D сеток на плоскость изображения.

      Узловые точки динамической сетки отслеживают особенности изображения во времени с помощью соответствующих векторов перемещения. Исходная сетка может быть регулярной, или адаптироваться к характеру изображения, которая называется сеткой, адаптируемой к изображению. Моделирование 2-D сетки, адаптируемая к изображению, соответствует неоднородному стробированию поля перемещения в некотором числе узловых точек вдоль контура и внутри видео объекта. Методы выбора и отслеживания этих узловых точек не является предметом стандартизации.

      В 2-D сетке, базирующейся на текстуре, треугольные элементы, в текущем кадре деформируются при перемещении узловых точек. Текстура в каждом мозаичном элементе эталонного кадра деформируется с помощью таблиц параметрического соответствия, определенных как функция векторов перемещения узловых точек. Для треугольных сетей обычно используется аффинное преобразование. Его линейная форма предполагает текстурный мэпинг с низкой вычислительной сложностью. Афинный мэпинг может моделировать преобразование, вращение, изменение масштаба, отражение и вырезание и сохранение прямых линий. Степени свободы, предоставляемые тремя векторами перемещения вершин треугольника, соответствуют шести параметрам афинного преобразования (affine mapping). Это предполагает, что исходное 2-D поле перемещения может быть компактно представлено движением узловых точек, из которого реконструируется афинное поле перемещение. В то же время, структура сетки ограничивает перемещения смежных, мозаичных элементов изображения. Следовательно, сетки хорошо годятся для представления умеренно деформируемых, но пространственно непрерывных полей перемещения.

      Моделирование 2-D сетки привлекательно, та как 2-D сетки могут сформированы из одного вида объекта, сохраняя функциональность, обеспечиваемую моделированием с привлечением 3-D сеток. Подводя итог можно сказать, что представления с объектно-ориентированными 2-D сетками могут моделировать форму (многогранная апроксимация контура объекта) и перемещение VOP в неоднородной структуре, которая является расширяемой до моделирования 3-D объектов, когда имеются данные для конструирования таких моделей. В частности, представление видео-объектов с помощью 2-D-сетки допускает следующие функции:

      A. Манипуляция видео-объектами

      • Улучшенная реальность. Объединение виртуальных (сгенерированых ЭВМ) изображений с реальными движущимися объектами (видео) для создания улучшенной видео информации. Изображения, созданные компьютером должны оставаться в идеальном согласии с движущимися реальными изображениями (следовательно необходимо отслеживание).
      • Преображение/анимация синтетических объектов. Замещение естественных видео объектов в видео клипе другим видео объектом. Замещающий видео объект может быть извлечен из другого естественного видео клипа или может быть получен из объекта статического изображения, используя информацию перемещения объекта, который должен быть замещен.
      • Пространственно-временная интерполяция. Моделирование движения сетки представляет более надежную временную интерполяцию с компенсацией перемещения.

      B. Сжатие видео-объекта

      • Моделирование 2-D сеток может использоваться для сжатия, если выбирается передача текстурных карт только определенных ключевых кадров и анимация этих текстурных карт для промежуточных кадров. Это называется само преображением выбранных ключевых кадров с использованием информации 2-D сеток.

      C. Видео индексирование, базирующееся на содержимом

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

      9.8.4. 3D-сетки

      Возможности кодирования 3-D сеток включают в себя:

      • Кодирование базовых 3-D многоугольных сеток делает возможным эффективное кодирование 3-D полигональных сеток. Кодовое представление является достаточно общим, чтобы поддерживать как много- так и одно-сеточный вариант.
      • Инкрементное представление позволяет декодеру реконструировать несколько лиц в сетке, пропорционально числу бит в обрабатываемом потоке данных. Это, кроме того, делает возможным инкрементный рэндеринг.
      • Быстрое восстановление при ошибках позволяет декодеру частично восстановить сетку, когда субнабор бит потока данных потерян и/или искажен.
      • Масштабируемость LOD (Level Of Detail - уровень детализации) позволяет декодеру реконструировать упрощенную версию исходной сетки, содержащей уменьшенное число вершин из субнабора потока данных. Такие упрощенные презентации полезны, чтобы уменьшить время рэндеринга объектов, которые удалены от наблюдателя (управление LOD), но также делает возможным применение менее мощного средства для отображения объекта с ухудшенным качеством.

      9.8.5. Масштабируемость, зависящая от изображения

      Масштабируемость, зависящая от вида, делает возможными текстурные карты, которые используются реалистичных виртуальных средах. Она состоит в учете точки наблюдения в виртуальном 3-D мире для того чтобы передать только видимую информацию. Только часть информации затем пересылается, в зависимости от геометрии объекта и смещения точки зрения. Эта часть вычисляется как на стороне кодировщика, так и на стороне декодера. Такой подход позволяет значительно уменьшить количество передаваемой информации между удаленной базой данных и пользователем. Эта масштабируемость может работать с кодировщиками, базирующимися на DCT.

      9.9. Структура средств для представления натурального видео

      Алгоритмы кодирования изображение MPEG-4 и видео предоставляют эффективное представление визуальных объектов произвольной формы, а также поддержку функций, базирующихся на содержимом. Они поддерживают большинство функций, уже предлагаемых в MPEG-1 и MPEG-2, включая эффективное сжатие стандартных последовательностей прямоугольных изображений при варьируемых уровнях входных форматов, частотах кадров, глубине пикселей, скоростях передачи и разных уровнях пространственной, временной и качественной масштабируемости.

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

      Рис. 11. Классификация средств и алгоритмов кодирования звука и изображения MPEG-4

      "Ядро VLBV" (VLBV - Very Low Bit-rate Video) предлагает алгоритмы и средства для приложений, работающих при скоростях передачи между 5 и 64 кбит/с, поддерживающие последовательности изображений с низким пространственным разрешение (обычно ниже разрешения CIF) и с низкими частотами кадров (обычно ниже 15 Гц). К приложениям, поддерживающим функциональность ядра VLBV относятся:

      1. Кодирование обычных последовательностей прямоугольных изображений с высокой эффективностью кодирования и высокой устойчивостью к ошибкам, малыми задержками и низкой сложностью для мультимедийных приложений реального времени, и
      2. Операции "произвольный доступ", "быстрая перемотка вперед" и " быстрая перемотка назад" для запоминания VLB мультимедиа ДБ и приложений доступа.

      Та же самая функциональность поддерживается при высоких скоростях обмена с высокими параметрами по временному и пространственному разрешению вплоть до ITU-R Rec. 601 и больше - используя идентичные или подобные алгоритмы и средства как в ядре VLBV. Предполагается, что скорости передачи лежат в диапазоне от 64 кбит/с до 10 Мбит/с, а приложения включают широковещательное мультимедиа или интерактивное получение сигналов с качеством, сравнимым с цифровым телевидением.

      Функциональности, базирующиеся на содержимом, поддерживают отдельное кодирование и декодирование содержимого (т.е. физических объектов в сцене, VO). Эта особенность MPEG-4 предоставляет наиболее элементарный механизм интерактивности.

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

      Расширенные алгоритмы и средства MPEG-4 для функциональности, зависящей от содержимого, могут рассматриваться как супер набор ядра VLBV и средств для работы при высоких потоках данных.

      9.10. Поддержка обычной функциональности и зависящей от содержимого

      MPEG-4 видео поддерживает обычные прямоугольные изображения и видео, а также изображения и видео произвольной формы.

      Кодирование обычных изображений и видео сходно с обычным кодированием в MPEG-1/2. Оно включает в себя предсказание/компенсацию перемещений за которым следует кодирование текстуры. Для функциональности, зависящей от содержимого, где входная последовательность изображений может иметь произвольную форму и положение, данный подход расширен с помощью кодирования формы и прозрачности. Форма может быть представлена двоичной маской или 8-битовой компонентой, которая позволяет описать прозрачность, если один VO объединен с другими объектами.

      9.11. Видео изображение MPEG-4 и схема кодирования

      Рис. 12 описывает базовый подход алгоритмов MPEG-4 видео к кодированию входной последовательности изображений прямоугольной и произвольной формы.

      Рис. 12. Базовая блок-схема видео-кодировщика MPEG-4

      Базовая структура кодирования включает в себя кодирование формы (для VO произвольной формы), компенсацию перемещения и кодирование текстуры с привлечением DCT (используя стандарт 8>x8 DCT или DCT адаптирующийся к форме).

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

      ∙ Стандартная оценка и компенсация перемещения, базирующаяся на блоках 8x8 или 16x16 пикселей.
      ∙ Глобальная компенсация перемещения, базирующаяся на передаче статического "образа". Статическим образом может быть большое статическое изображение, описывающее панораму фона. Для каждого изображения в последовательности, кодируются для реконструкции объекта только 8 глобальных параметров перемещения, описывающих движение камеры. Эти параметры представляют соответствующее афинное преобразование образа, переданного в первом кадре.

      9.11.1. Эффективность кодирования в V.2

      Стандарт MPEG-4 V.2 улучшает оценку перемещения и компенсации для объектов и текстур прямоугольной и произвольной формы. Введены две методики для оценки и компенсации перемещения:

      ∙ Глобальная компенсация перемещения GMC (Global Motion Compensation). Кодирование глобального перемещения для объекта, использующего малое число параметров. GMC основано на глобальной оценке перемещения, деформации изображения, кодировании траектории перемещения и кодировании текстуры для ошибок предсказания.

      ∙ Четверть-пиксельная компенсация перемещения улучшает точность схемы компенсации, за счет лишь небольшого синтаксической и вычислительной избыточности. Точное описание перемещения приводит к малым ошибкам предсказания и, следовательно, лучшему визуальному качеству.

      В области текстурного кодирования DCT (SA-DCT - адаптивный к форме) улучшает эффективность кодирования объектов произвольной формы. Алгоритм SA-DCT основан на предварительно определенных ортонормальных наборах одномерных базисных функций DCT.

      Субъективные оценочные тесты показывают, что комбинация этих методик может дать экономию в необходимой полосе канала до 50% по сравнению с версией 1, в зависимости от типа содержимого и потока данных.

      9.12. Кодирование текстур в статических изображениях

      Эффективное кодирование визуальных текстур и статических изображений (подлежащих, например, выкладке на анимационные сетки) поддерживается режимом визуальных текстур MPEG-4. Этот режим основан на алгоритме элементарных волн (wavelet) с нулевым деревом, который предоставляет очень высокую эффективность кодирования в широком диапазоне скоростей передачи. Вместе с высокой эффективностью сжатия, он также предлагает пространственную и качественную масштабируемость (вплоть до 11 уровней пространственной масштабируемости и непрерывной масштабируемости качества), а также кодирование объектов произвольной формы. Кодированный поток данных предназначен также для загрузки в терминал иерархии разрешения изображения. Эта технология обеспечивает масштабируемость разрешения в широком диапазоне условий наблюдения более типичном для интерактивных приложений при отображении 2-D и 3-D виртуальных миров.

      9.13. Масштабируемое кодирование видео-объектов

      MPEG-4 поддерживает кодирование изображений и видео объектов с пространственной и временной масштабируемостью, для обычных прямоугольных и произвольных форм. Под масштабируемостью подразумевается возможность декодировать лишь часть потока данных и реконструировать изображение или их последовательность с:

      ∙ уменьшенной сложностью декодера и следовательно ухудшенным качеством
      ∙ уменьшенным пространственным разрешением
      ∙ уменьшенным временным разрешением
      ∙ равным временным и пространственным разрешением, но с ухудшенным качеством.

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

      Для декодирования статических изображений, стандарт MPEG-4 предоставит 11 уровней гранулярности, а также масштабируемость качества до уровня одного бита. Для видео последовательностей в начале будет поддерживаться 3 уровня гранулярности, но ведутся работы по достижению 9 уровней.

      9.14. Устойчивость в среде, предрасположенной к ошибкам

      MPEG-4 обеспечивает устойчивость к ошибкам, чтобы позволить доступ к изображениям и видео данным через широкий круг устройств памяти и передающих сред. В частности, благодаря быстрому росту мобильных телекоммуникаций, необычайно важно получить доступ к аудио и видео информации через радио сети. Это подразумевает необходимость успешной работы алгоритмов сжатия аудио и видео данных в среде предрасположенной к ошибкам при низких скоростях передачи (т.е., ниже 64 кбит/с).

      Средства противостояния ошибкам, разработанные для MPEG-4 могут быть разделены на три основные группы: ресинхронизация, восстановление данных и подавления влияния ошибок. Следует заметить, что эти категории не являются уникальными для MPEG-4, они широко используются разработчиками средств противодействия ошибкам для видео.

      9.14.1. Ресинхронизация

      Средства ресинхронизации пытаются восстановить синхронизацию между декодером и потоком данных нарушенную в результате ошибки. Данные между точкой потери синхронизации и моментом ее восстановления выбрасываются.

      Метод ресинхронизации принятый MPEG-4, подобен используемому в структурах групп блоков GOB (Group of Blocks) стандартов ITU-T H.261 и H.263. В этих стандартах GOB определена, как один или более рядов макроблоков (MB). В начале нового GOB потока помещается информация, называемая заголовком GOB. Этот информационный заголовок содержит стартовый код GOB, который отличается от начального кода кадра, и позволяет декодеру локализовать данный GOB. Далее, заголовок GOB содержит информацию, которая позволяет рестартовать процесс декодирования (т.е., ресинхронизовать декодер и поток данных, а также сбросить всю информацию предсказаний).

      Подход GOB базируется пространственной ресинхронизации. То есть, раз в процессе кодирования достигнута позиция конкретного макроблока, в поток добавляется маркер ресинхронизации. Потенциальная проблема с этим подходом заключается в том, что из-за вариации скорости процесса кодирования положение этих маркеров в потоке четко не определено. Следовательно, определенные части сцены, такие как быстро движущиеся области, будут более уязвимы для ошибок, которые достаточно трудно исключить.

      Подход видео пакетов, принятый MPEG-4, базируется на периодически посылаемых в потоке данных маркерах ресинхронизации. Другими словами, длина видео пакетов не связана с числом макроблоков, а определяется числом бит, содержащихся в пакете. Если число бит в текущем видео пакете превышает заданный порог, тогда в начале следующего макроблока формируется новый видео пакет.

      Маркер ресинхронизации используется чтобы выделить новый видео пакет. Этот маркер отличим от всех возможных VLC-кодовых слов, а также от стартового кода VOP. Информация заголовка размещается в начале видео пакета. Информация заголовка необходима для повторного запуска процесса декодирования и включает в себя: номер макроблока первого макроблока, содержащегося в этом пакете и параметр квантования, необходимый для декодирования данный макроблок. Номер макроблока осуществляет необходимую пространственную ресинхронизацию, в то время как параметр квантования позволяет заново синхронизовать процесс дифференциального декодирования.

      В заголовке видео пакета содержится также код расширения заголовка (HEC). HEC представляет собой один бит, который, если равен 1, указывает на наличие дополнительной информации ресинхронизации. Сюда входит модульная временная шкала, временное приращение VOP, тип предсказания VOP и VOP F-код. Эта дополнительная информация предоставляется в случае, если заголовок VOP поврежден.

      Следует заметить, что, когда в рамках MPEG-4 используется средство восстановления при ошибках, некоторые средства эффективного сжатия модифицируются. Например, вся кодированная информация предсказаний заключаться в одном видео пакете так чтобы предотвратить перенос ошибок.

      В связи с концепцией ресинхронизацией видео пакетов, в MPEG-4 добавлен еще один метод, называемый синхронизацией с фиксированным интервалом. Этот метод требует, чтобы стартовые коды VOP и маркеры ресинхронизации (т.е., начало видео пакета) появлялись только в легальных фиксированных позициях потока данных. Это помогает избежать проблем, связанных эмуляциями стартовых кодов. То есть, когда в потоке данных встречаются ошибки, имеется возможность того, что они эмулируют стартовый код VOP. В этом случае, при использовании декодера с синхронизацией с фиксированным интервалом, стартовый код VOP ищется только в начале каждого фиксированного интервала.

      9.14.2. Восстановление данных

      После того как синхронизация восстановлена, средства восстановления данных пытаются спасти данные, которые в общем случае могут быть потеряны. Эти средства являются не просто программами коррекции ошибок, а техникой кодирования данных, которая устойчива к ошибкам. Например, одно конкретное средство, которое было одобрено видео группой (Video Group), является обратимыми кодами переменной длины RVLC (Reversible Variable Length Codes). В этом подходе, кодовые слова переменной длины сконструированы симметрично, так что они могут читаться как в прямом, так и в обратном направлении.

      Пример, иллюстрирующий использование RVLC представлен на рис. 13. Вообще, в ситуации, когда блок ошибок повредил часть данных, все данные между двумя точками синхронизации теряются. Однако, как показано на рис. 13, RVLC позволяет восстановить часть этих данных. Следует заметить, что параметры, QP и HEC, показанные на рисунке, представляют поля, зарезервированные в заголовке видео пакета для параметра квантования и кода расширения заголовка, соответственно.

      Рис. 13. Пример реверсивного кода переменной длины

      9.14.3. Сокрытие ошибок

      Сокрытие ошибок (имеется в виду процедура, когда последствия ошибок не видны) является исключительно важным компонентом любого устойчивого к ошибкам видео кодека. Средства аналогичные данному рассмотрены выше, эффективность стратегии сокрытия ошибок в высшей степени зависит от работы схемы ресинхронизации. По существу, если метод ресинхронизации может эффективно локализовать ошибку, тогда проблема сокрытия ошибок становится легко решаемой. Для приложений с низкой скоростью передачи и малой задержкой текущая схема ресинхронизации позволяет получить достаточно приемлемые результаты при простой стратегии сокрытия, такой как копирование блоков из предыдущего кадра.

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

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

      10. Подробное техническое описание MPEG-4 аудио

      MPEG-4 кодирование аудио объектов предлагает средства как для представления естественных звуков (таких как речь и музыка) так и синтетических - базирующихся на структурированных описаниях. Представление для синтетического звука может быть получено из текстовых данных или так называемых инструментальных описаний и параметров кодирования для обеспечения специальных эффектов, таких как реверберация и объемное звучание. Представления обеспечивают сжатие и другую функциональность, такую как масштабируемость и обработку эффектов.

      Средства аудио кодирования MPEG-4, охватывающие диапазон от 6кбит/с до 24кбит/с, подвергаются верификационным тестированиям для широковещательных приложений цифрового AM-аудио совместно с консорциумом NADIB (Narrow Band Digital Broadcasting). Было обнаружено, что высокое качество может быть получено для одного и того же частотного диапазона с привлечением цифровых методик и что конфигурации масштабируемого кодировщика могут обеспечить лучшие эксплуатационные характеристики.

      10.1. Натуральный звук

      MPEG-4 стандартизирует кодирование естественного звука при скоростях передачи от 2 кбит/с до 64 кбит/с. Когда допускается переменная скорость кодирования, допускается работа и при низких скоростях вплоть до 1.2 кбит/с. Использование стандарта MPEG-2 AAC в рамках набора средств MPEG-4 гарантирует сжатие аудио данных при любых скоростях вплоть до самых высоких. Для того чтобы достичь высокого качества аудио во всем диапазоне скоростей передачи и в то же время обеспечить дополнительную функциональность, техники кодирования голоса и общего аудио интегрированы в одну систему:

      ∙ Кодирование голоса при скоростях между 2 и 24 кбит/с поддерживается системой кодирования HVXC (Harmonic Vector eXcitation Coding) для рекомендуемых скоростей 2 - 4 кбит/с, и CELP (Code Excited Linear Predictive) для рабочих скоростей 4 - 24 кбит/с. Кроме того, HVXC может работать при скоростях вплоть до 1.2 кбит/с в режиме с переменной скоростью. При кодировании CELP используются две частоты стробирования, 8 и 16 кГц, чтобы поддержать узкополосную и широкополосную передачу голоса, соответственно. Подвергнуты верификации следующие рабочие режимы: HVXC при 2 и 4 кбит/с, узкополосный CELP при 6, 8.3, и 12 кбит/с, и широкополосный CELP при 18 кбит/с.

      ∙ Для обычного аудио кодирования при скоростях порядка и выше 6 кбит/с, применены методики преобразующего кодирования, в частности TwinVQ и AAC. Аудио сигналы в этой области обычно стробируются с частотой 8 кГц.

      Чтобы оптимально перекрыть весь диапазон скоростей передачи и разрешить м асштабируемость скоростей, разработана специальная система, отображенная на рис. 14.

      Рис. 14. Общая блок-схема MPEG-4 аудио

      Масштабируемость полосы пропускания является частным случаем масштабируемости скоростей передачи, по этой причине часть потока, соответствующая части спектра полосы пропускания, может быть отброшена при передаче или декодировании.

      Масштабируемость сложности кодировщика позволяет кодирующим устройствам различной сложности формировать корректные информационные потоки. Масштабируемость сложности декодера позволяет данному потоку данных быть декодированному приборами с различной сложностью (и ценой). Качество звука, вообще говоря, связано со сложностью используемого кодировщика и декодера Масштабируемость работает в рамках некоторых средств MPEG-4, но может также быть применена к комбинации методик, например, к CELP, как к базовому уровню, и AAC.

      Уровень систем MPEG-4 позволяет использовать кодеки, следующие, например, стандартам MPEG-2 AAC. Каждый кодировщик MPEG-4 предназначен для работы в автономном режиме (stand-alone) со своим собственным синтаксисом потока данных. Дополнительная функциональность реализуется за счет возможностей кодировщика и посредством дополнительных средств вне его.

      10.2. Улучшения MPEG-4 аудио V.2
      10.2.1. Устойчивость к ошибкам

      Средства устойчивости к ошибкам предоставляют улучшенные рабочие характеристики для транспортных каналов, предрасположенных к ошибкам.

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

      • Средство виртуального кодового блокнота (VCB11)
      • Средство с обращаемыми кодовыми словами переменной длины RVLC (Reversible Variable Length Coding)
      • Средство изменения порядка кодовых слов Хафмана HCR (Huffman Codeword Reordering)

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

      Средство защиты от ошибок (EP tool) работает со всеми аудио объектами MPEG-4 версии 2, предоставляя гибкую возможность конфигурирования для широкого диапазона канальных условий. Главными особенностями средства EP являются следующие:

      • Обеспечение набора кодов для коррекции/детектирования ошибок с широким диапазоном масштабируемости по рабочим характеристикам и избыточности.
      • Обеспечение системы защиты от ошибок, которая работает как с кадрами фиксированной, так и переменной длины.
      • Обеспечение управления конфигурацией защиты от неравных ошибок UEP (Unequal Error Protection) с низкой избыточностью.

      Алгоритмы кодирования MPEG-4 аудио версии 2 предоставляет классификацию всех полей потока согласно их чувствительности к ошибкам. На основе этого, поток данных делится на несколько классов, которые могут быть защищены раздельно с помощью инструмента EP, так что более чувствительные к ошибкам части окажутся защищены более тщательно.

      10.2.2. Аудио-кодирование с малыми задержками

      В то время как универсальный аудио кодировщик MPEG-4 очень эффективен при кодировании аудио сигналов при низких скоростях передачи, он имеет алгоритмическую задержку кодирования/декодирования, достигающую нескольких сот миллисекунд и является, таким образом, неподходящим для приложений, требующих малых задержек кодирования, таких как двунаправленные коммуникации реального времени. Для обычного аудио кодировщика, работающего при частоте стробирования 24 кГц и скорости передачи 24 кбит/с, алгоритмическая задержка кодирования составляет 110 мс плюс до 210 мс дополнительно в случае использования буфера. Чтобы кодировать обычные аудио сигналы enable с алгоритмической задержкой, не превышающей 20 мс, MPEG-4 версии 2 специфицирует кодировщик, который использует модификацию алгоритма MPEG-2/4 AAC (Advanced Audio Coding). По сравнению со схемами кодирования речи, этот кодировщик позволяет сжимать обычные типы аудио сигналов, включая музыку, при достаточно низких задержках. Он работает вплоть до частот стробирования 48 кГц и использует длину кадров 512 или 480 значений стробирования, по сравнению с 1024 или 960 значений, используемых в стандарте MPEG-2/4 AAC. Размер окна, используемого при анализе и синтезе блока фильтров, уменьшен в два раза. Чтобы уменьшить артифакты предэхо в случае переходных сигналов используется переключение размера окна. Для непереходных частей сигнала используется окно синусоидальной формы, в то время как в случае переходных сигналов используется так называемое окно с низким перекрытием. Использование буфера битов минимизируется, чтобы сократить задержку. В крайнем случае, такой буфер вообще не используется.

      10.2.3. Масштабируемость гранулярности

      Масштабируемость скорости передачи, известная как встроенное кодирование, является крайне желательной функцией. Обычный аудио кодировщик версии 1 поддерживает масштабируемость с большими шагами, где базовый уровень потока данных может комбинироваться с одним или более улучшенных уровней потока данных, чтобы можно было работать с высокими скоростями и, таким образом, получить лучшее качество звука. В типовой конфигурации может использоваться базовый уровень 24 кбит/с и два по 16 кбит/с, позволяя декодирование с полной скоростью 24 кбит/с (моно), 40 кбит/с (стерео), и 56 кбит/с (стерео). Из-за побочной информации передаваемой на каждом уровне, малые уровни-добавки поддерживаются в версии 1 не очень эффективно. Чтобы получить эффективную масштабируемость с малыми шагами для стандартного аудио кодировщика, в версии 2 имеется средство побитового арифметического кодирования BSAC (Bit-Sliced Arithmetic Coding). Это средство используется в комбинации с AAC-кодированием и замещает бесшумное кодирование спектральных данных и масштабных коэффициентов. BSAC предоставляет масштабируемость шагами в 1 кбит/с на аудио канал, т.е. шагами по 2 кбит/с для стерео сигнала. Используется один базовый поток (уровень) данных и много небольших потоков улучшения. Базовый уровень содержит общую информацию вида, специфическую информацию первого уровня и аудио данные первого уровня. Потоки улучшения содержат только специфические данные вида и аудио данные соответствующего слоя. Чтобы получить масштабируемость с небольшими шагами, используется побитовая схема a квантования спектральных данных. Сначала преобразуемые спектральные величины группируются в частотные диапазоны. Каждая из этих групп содержит оцифрованные спектральные величины в их двоичном представлении. Затем биты группы обрабатываются порциями согласно их значимости. Таким образом сначала обрабатываются все наиболее значимые биты (MSB) оцифрованных величин в группе и т.д. Эти группы бит затем кодируются с привлечением арифметической схемы кодирования, чтобы получить энтропийные коды с минимальной избыточностью. Представлены различные модели арифметического кодирования, чтобы перекрыть различные статистические особенности группировок бит.

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

      10.2.4. Параметрическое кодирование звука

      Средства параметрического аудио-кодирования сочетают в себе низкую скорость кодирования обычных аудио сигналов с возможностью модификации скорости воспроизведения или шага при декодировании без бока обработки эффектов. В сочетании со средствами кодирования речи и звука версии 1, ожидается улучшенная эффективность кодирования для использования объектов, базирующихся на кодировании, которое допускает выбор и/или переключение между разными техниками кодирования.

      Параметрическое аудио-кодирование использует для кодирования общих аудио сигналов технику HILN (Harmonic and Individual Lines plus Noise) при скоростях 4 кбит/с, а выше применяется параметрическое представление аудио сигналов. Основной идеей этой методики является разложение входного сигнала на аудио объекты, которые описываются соответствующими моделями источника и представляются модельными параметрами. В кодировщике HILN используются модели объектов для синусоид, гармонических тонов и шума.

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

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

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

      Очень интересное свойство этой схемы параметрического кодирования происходит из того факта, что сигнал описан через параметры частоты и амплитуды. Эта презентация сигнала позволяет изменять скорость и высоту звука простой вариацией параметров декодера. Параметрический аудио кодировщик HILN может быть объединен с параметрическим кодировщиком речи MPEG-4 (HVXC), что позволит получить интегрированный параметрический кодировщик, покрывающий широкий диапазон сигналов и скоростей передачи. Этот интегрированный кодировщик поддерживает регулировку скорости и тона. Используя в кодировщике средство классификации речи/музыки, можно автоматически выбрать HVXC для сигналов речи и HILN для музыкальных сигналов. Такое автоматическое переключение HVXC/HILN было успешно продемонстрировано, а средство классификации описано в информативном приложении стандарта версии 2.

      10.2.5. Сжатие тишины CELP

      Средство "сжатия тишины" уменьшает среднюю скорость передачи благодаря более низкому сжатию пауз (тишины). В кодировщике, детектор активности голоса используется для разделения областей с нормальной голосовой активностью и зон молчания или фонового шума. Во время нормальной голосовой активности используется кодирование CELP как в версии 1. В противном случае передается дескриптор SID (Silence Insertion Descriptor) при малой скорости передачи. Этот дескриптор SID активирует в декодере CNG (Comfort Noise Generator). Амплитуда и форма спектра этого шума специфицируются энергией и параметрами LPC как в обычном кадре CELP. Эти параметры являются опционной частью SID и таким образом могут модифицироваться.

      10.2.6. Устойчивое к ошибкам HVXC

      Объект HVXC, устойчивый к ошибкам (ER) поддерживается средствами параметрического кодирования голоса (ER HVXC), которые предоставляют режимы с фиксированными скоростями обмена (2.0-4.0 кбит/с) и режим с переменной скоростью передачи (<2.0 кбит/с, <4.0 кбит/с) в раках масштабируемой и не масштабируемой схем. В версии 1 HVXC, режим с переменной скоростью передачи поддерживается максимум 2.0 кбит/с, а режим с переменной скоростью передачи в версии ER HVXC 2 дополнительно поддерживается максимум 4.0 кбит/с. ER HVXC обеспечивает качество передачи голоса международных линий (100-3800 Hz) при частоте стробирования 8кГц. Когда разрешен режим с переменной скоростью передачи, возможна работа при низкой средней скорости передачи. Речь, кодированная в режиме с переменной скоростью передачи при среднем потоке 1.5 кбит/с, и типовом среднем значении 3.0 кбит/с имеет существенно то же качество, что для 2.0 кбит/с при фиксированной скорости и 4.0 кбит/с, соответственно. Функциональность изменения тона и скорости при декодировании поддерживается для всех режимов. Кодировщик речи ER HVXC ориентирован на приложения от мобильной и спутниковой связи, до IP-телефонии, и голосовых баз данных.

      10.2.7. Пространственные характеристики среды

      Средства пространственной характеристики среды позволяют создавать аудио сцены с более естественными источниками звука и моделированием звукового окружения, чем это возможно в версии 1. Поддерживается как физический подход, так и подход восприятия. Физический подход основан на описании акустических свойств среды (например, геометрии комнаты, свойств конструкционных материалов, положения источников звука) и может быть использован в приложениях подобно 3-D виртуальной реальности. Подход с позиций восприятия позволяет на высоком уровне описать аудио восприятие сцены, основанное на параметрах, подобных тем, что используются блоком эффекта реверберации. Таким образом, аудио и визуальная сцена могут быть сформированы независимо, как это обычно требуется в случае кинофильмов. Хотя пространственной характеристики среды относятся к аудио, они являются частью описания BIFS (BInary Format for Scene) в системах MPEG-4 и называются продвинутым AudioBIFS.

      10.2.8. Обратный канал

      Обратный канал (back channel) позволяет передать запрос клиента и/или клиентского терминала серверу. Посредством обратного канала может быть реализована интерактивность. В системе MPEG-4 о необходимости обратного канала (back channel) клиентский терминал оповещается с помощью соответствующего дескриптора элементарного потока, характеризующего параметры этого канала. Терминал клиента открывает этот обратный канал, так же как и обычные каналы. Объекты (например, медиа кодировщики или декодеры), которые соединены через обратный канал известны через параметры, полученные через дескриптор элементарного потока и за счет ассоциации дескриптора элементарного потока с дескриптором объекта. В MPEG-4 аудио, обратный канал обеспечивает обратную связь для настройки скорости передачи, масштабируемости и системы защиты от ошибок.

      10.2.9. Транспортный поток звука

      Транспортный поток MPEG-4 аудио определяет механизм передачи аудио потоков MPEG-4 без использования систем MPEG-4 и предназначен исключительно для аудио приложений. Транспортный механизм использует двухуровневый подход, а именно уровни мультиплексирования и синхронизации. Уровень мультиплексирования (Low-overhead MPEG-4 Audio Transport Multiplex: LATM) управляет мультиплексированием нескольких информационных полей MPEG-4 аудио и аудио конфигурационной информации. Уровень синхронизации специфицирует синтаксис транспортного потока MPEG-4 аудио, который называется LOAS (Low Overhead Audio Stream - аудио поток с низкой избыточностью). Интерфейсный формат для транспортного уровня зависит от ниже лежащего коммуникационного уровня.

      10.3. Синтетический звук

      MPEG-4 определяет декодеры для генерирования звука на основе нескольких видов структурированного ввода. Текстовый ввод Text преобразуется в декодере TTS (Text-To-Speech), в то время как прочие звуки, включая музыку, могут синтезироваться стандартным путем. Синтетическая музыка может транспортироваться при крайне низких потоках данных.

      Декодеры TTS (Text To Speech) работают при скоростях передачи от 200 бит/с до 1.2 Кбит/с, что позволяет использовать при синтезе речи в качестве входных данных текст или текст с просодическими параметрами (тональная конструкция, длительность фонемы, и т.д.). Такие декодеры поддерживают генерацию параметров, которые могут быть использованы для синхронизации с анимацией лица, при осуществлении перевода с другого языка и для работы с международными символами фонем. Дополнительная разметка используется для передачи в тексте управляющей информации, которая переадресуется другим компонентам для обеспечения синхронизации с текстом. Заметим, что MPEG-4 обеспечивает стандартный интерфейс для работы кодировщика TTS (TTSI = Text To Speech Interface), но не для стандартного TTS-синтезатора.

      10.3.1. Синтез с множественным управлением (Score Driven Synthesis).

      Средства структурированного аудио декодируют входные данные и формируют выходной звуковой сигнал. Это декодирование управляется специальным языком синтеза, называемым SAOL (Structured Audio Orchestra Language), который является частью стандарта MPEG-4. Этот язык используется для определения "оркестра", созданного из "инструментов" (загруженных в терминал потоком данных), которые формирует и обрабатывает управляющую информацию. Инструмент представляет собой маленькую сеть примитивов обработки сигналов, которые могут эмулировать некоторые специфические звуки, такие, которые могут производить настоящие акустические инструменты. Сеть обработки сигналов может быть реализована аппаратно или программно и включать как генерацию, так и обработку звуков, а также манипуляцию записанными ранее звуками.

      MPEG-4 не стандартизует "единственный метод" синтеза, а скорее описывает путь описания методов синтеза. Любой сегодняшний или будущий метод синтеза звука может быть описан в SAOL, включая таблицу длин волн, FM, физическое моделирование и гранулярный синтез, а также непараметрические гибриды этих методов.

      Управление синтезом выполняется путем включения "примитивов" (score) или "скриптов" в поток данных. Примитив представляет собой набор последовательных команд, которые включают различные инструменты в определенное время и добавляют их сигнал в общий музыкальный поток или формируют заданные звуковые эффекты. Описание примитива, записанное на языке SASL (Structured Audio Score Language), может использоваться для генерации новых звуков, а также включать дополнительную управляющую информацию для модификации существующих звуков. Это позволяет композитору осуществлять тонкое управление синтезированными звуками. Для процессов синтеза, которые не требуют такого тонкого контроля, для управления оркестром может также использоваться протокол MIDI.

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

      Для терминалов с меньшей функциональностью, и для приложений, которые не требуют такого сложного синтеза, стандартизован также "формат волновой таблицы" ("wavetable bank format"). Используя этот формат, можно загрузить звуковые образцы для использования при синтезе, а также выполнить простую обработку, такую как фильтрация, реверберация, и ввод эффекта хора. В этом случае вычислительная сложность необходимого процесса декодирования может быть точно определена из наблюдения потока данных, что невозможно при использовании SAOL.

      11. Приложение. Словарь и сокращения

      AAC

      Advanced Audio Coding - продвинутое кодирование звука

      AAL

      ATM Adaptation Layer - адаптационный уровень ATM

      Access Unit

      Логическая субструктура элементарного потока для облегчения доступа или манипуляции потоком данных

      ACE

      Advanced Coding Efficiency (профайл) - эффективность продвинутого кодирования

      Amd

      Поправка

      AOI

      Area Of Interest - область интереса

      API

      Application Programming Interface - программный интерфейс приложения

      ARTS

      Advanced Real-time Simple - простой, продвинутый профайл реального времени

      ATM

      Asynchronous Transfer Mode - режим асинхронной передачи

      BAP

      Body Animation Parameters - параметры анимации тела

      BDP

      Body Definition Parameters - параметры описания тела

      BIFS

      Binary Format for Scenes - двоичный формат сцены

      BSAC

      Bit-Sliced Arithmetic Coding - побитовое арифметическое кодирование

      CD

      Committee Draft - проект комитета

      CE

      Core Experiment - центральный эксперимент

      CELP

      Code Excited Linear Prediction - линейное предсказание, стимулируемое кодом

      CIF

      Common Intermediate Format - общий промежуточный формат

      CNG

      Comfort Noise Generator - генератор комфортного шума

      DAI

      DMIF-Application Interface - прикладной интерфейс DMIF

      DCT

      Discrete Cosine Transform - дискретное косинусное преобразование

      DMIF

      Delivery Multimedia Integration Framework -

      DNI

      DMIF Network Interface - сетевой интерфейс DMIF

      DRC

      Dynamic Resolution Conversion - преобразование с динамическим разрешением

      DS

      DMIF signaling - сигнальная система DMIF

      EP

      Error Protection - защита от ошибок

      ER

      Error Resilient - противостояние ошибкам

      ES

      Elementary Stream (элементарный поток): последовательность данных, которая исходит из передающего терминала MPEG-4 Terminal и приходит одному получателю, например, медиа- или управляющему объекту в приемном терминале MPEG-4. Он проходит через один канал FlexMux.

      FAP

      Facial Animation Parameters - параметры анимации лица

      FBA

      Facial and Body Animation - анимация лица и тела

      FDP

      Facial Definition Parameters - параметры описания лица

      FlexMux stream

      Последовательность пакетов FlexMux, ассоциированных с одним или более каналов FlexMux, идущих через один канал TransMux

      FlexMux tool

      A Flexible (Content) Multiplex tool - гибкое средство мультиплексирования

      GMC

      Global Motion Compensation - компенсация общего перемещения

      GSTN

      General Switched Telephone Network - общедоступная коммутируемая телефонная сеть

      HCR

      Huffman Codeword Reordering - смена порядка кодовых слов Хафмана

      HFC

      Hybrid Fiber Coax - гибридный волоконный коаксиал

      HTTP

      HyperText Transfer Protocol - протокол передачи гипертекста

      HVXC

      Harmonic Vector Excitation Coding - кодирование с гармоническим возбуждением вектора

      IP

      Internet Protocol - протокол Интернет

      IPI

      Intellectual Property Identification - идентификация интеллектуальной собственности

      IPMP

      Intellectual Property Management и Protection - защита и управление интеллектуальной собственностью

      IPR

      Intellectual Property Rights - Права интеллектуальной собственности

      IS

      International Standard - международный стандарт

      ISDN

      Integrated Service Digital Network - цифровая сеть с интегрированными услугами

      LAR

      Logarithmic Area Ratio - логарифмическое отношение области

      LATM

      Low-overhead MPEG-4 Audio Transport Multiplex:

      LC

      Low Complexity - низкая сложность

      LOAS

      Low Overhead Audio Stream - аудио поток с низкой избыточностью

      LOD

      Level Of Detail - уровень детализации

      LPC

      Linear Predictive Coding - линейно-предсказательное кодирование

      LTP

      Long Term Prediction - долгосрочное предсказание

      M4IF

      MPEG-4 Industry Forum - Промышленный форум MPEG-4

      MCU

      Multipoint Control Unit - многоточечный блок управления

      Mdat

      media data atoms - атомы медийных данных

      Mesh

      A graphical construct consisting of connected surface elements to describe the geometry/shape of a visual object. -

      MIDI

      Musical Instrument Digital Interface - цифровой интерфейс музыкального инструмента>

      MPEG

      Moving Pictures Experts Group - Экспертная группа по движущимся изображениям

      MSB

      Most Significant Bits - наиболее значимые биты

      OCI

      Object Content Information - информационное содержание объекта

      OD

      Object Descriptor - дескриптор объекта

      PDA

      Personal Digital Assistant - персональный цифровой помощник

      PDU

      Protocol Data Unit - Протокольный блок данных

      PSNR

      Peak Signal to Noise Ratio - отношение пикового значения сигнала к шуму

      QCIF

      Quarter Common Intermediate Format - четвертинный промежуточный формат изображения (видео)

      QoS

      Quality of Service - качество обслуживания

      Rendering

      The process of generating pixels for display - процесс генерации пикселей для отображения

      RTP

      Real Time Transport Protocol - транспортный протокол реального времени

      RTSP

      Real Time Streaming Protocol - поточный протокол реального времени

      RVLC

      Reversible Variable Length Coding - реверсивное кодирование с переменной длиной

      SA-DCT

      shape-adaptive DCT - двойное косинусное преобразование, адаптируемое к форме объекта

      SID

      Silence Insertion Descriptor - дескриптор паузы

      SL

      Sync(hronization) layer - уровень синхронизации

      SMIL

      Synchronized Multimedia Integration Language - интеграционный язык для синхронизованного мультимедиа

      SNHC

      Synthetic- Natural Hybrid Coding - синтетико-натуральное кодирование

      SNR

      Signal to Noise Ratio - отношение сигнал-шум

      Sprite

      Статический спрайт представляет собой возможно большое статическое изображение, описывающие панорамный фон

      SRM

      Session Resource Manager - субъект управления ресурсами сессии

      SVG

      Scalable Vector Graphics - масштабируемая векторная графика

      T/F coder

      Time/Frequency Coder - преобразователь времени в частоту

      TCP

      Transmission Control Protocol - протокол управления передачей данных

      TransMux

      Общая абстракция для любой схемы транспортного мультиплексирования

      TTS

      Text-to-speech - текст в голос

      UDP

      User Datagram Protocol - протокол передачи датограмм пользователя

      UEP

      Unequal Error Protection -

      UMTS

      Universal Mobile Telecommunication System - универсальная мобильная телекоммуникационная система

      VCB

      Virtual CodeBook - виртуальная кодовая книга

      Viseme

      Выражение лица, сопряженное с определенной фонемой

      VLBV

      Very Low Bitrate Video - видео с очень низкой скоростью передачи данных

      VM

      Verification Model - верификационная модель

      VOP

      Video Object Plane - объектная плоскость видео

      VRML

      Virtual Reality Modeling Language - язык моделирования виртуальной реальности

      W3C

      World Wide Web Consortium - консорциум WWW

      WD

      Working Draft - рабочий черновик (проект)

      WWW

      World Wide Web - Всемирная паутина

      XMT

      Extensible MPEG-4 textual format - расширяемый текстуальный формат MPEG-4

    Previous: 2.5 Методы преобразования и передачи изображения    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 2.6 Методы сжатия информации    Next: 2.5.2 Стандарт MPEG-7


    previous up down next index index
    Previous: 2.6.1 Алгоритм Зива-Лемпеля    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

    2.6.2 Локально адаптивный алгоритм сжатия
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Этот алгоритм используется для кодирования (L,I), где L строка длиной N, а I - индекс. Это кодирование содержит в себе несколько этапов.

    1. Сначала кодируется каждый символ L с использованием локально адаптивного алгоритма для каждого из символов индивидуально. Определяется вектор целых чисел R[0],.,R[N-1], который представляет собой коды для символов L[0],.,L[N-1]. Инициализируется список символов Y, который содержит в себе каждый символ из алфавита Х только один раз. Для каждого i = 0,.,N-1 устанавливается R[i] равным числу символов, предшествующих символу L[i] из списка Y. Взяв Y = ['a','b','c','r'] в качестве исходного и L = 'caraab', вычисляем вектор R: (2 1 3 1 0 3).

    2. Применяем алгоритм Хафмана или другой аналогичный алгоритм сжатия к элементам R, рассматривая каждый элемент в качестве объекта для сжатия. В результате получается код OUT и индекс I.

    Рассмотрим процедуру декодирования полученного сжатого текста (OUT,I).

    Здесь на основе (OUT,I) необходимо вычислить (L,I). Предполагается, что список Y известен.

    1. Сначала вычисляется вектор R, содержащий N чисел: (2 1 3 1 0 3).
    2. Далее вычисляется строка L, содержащая N символов, что дает значения R[0],.,R[N-1]. Если необходимо, инициализируется список Y, содержащий символы алфавита X (как и при процедуре кодирования). Для каждого i = 0,.,N-1 последовательно устанавливается значение L[i], равное символу в положении R[i] из списка Y (нумеруется, начиная с 0), затем символ сдвигается к началу Y. Результирующая строка L представляет собой последнюю колонку матрицы M. Результатом работы алгоритма будет (L,I). Взяв Y = ['a','b','c','r'] вычисляем строку L = 'caraab'.

    Наиболее важным фактором, определяющим скорость сжатия, является время, необходимое для сортировки вращений во входном блоке. Наиболее быстрый способ решения проблемы заключается в сортировке связанных строк по суффиксам.

    Для того чтобы сжать строку S, сначала сформируем строку S', которая является объединением S c EOF, новым символом, который не встречается в S. После этого используется стандартный алгоритм к строке S'. Так как EOF отличается от прочих символов в S, суффиксы S' сортируются в том же порядке, как и вращения S'. Это может быть сделано путем построения дерева суффиксов, которое может быть затем обойдено в лексикографическом порядке для сортировки суффиксов. Для этой цели может быть использован алгоритм формирования дерева суффиксов Мак-Крейгта. Его быстродействие составляет 40% от наиболее быстрой методики в случае работы с текстами. Алгоритм работы с деревом суффиксов требует более четырех слов на каждый исходный символ. Манбер и Майерс предложили простой алгоритм сортировки суффиксов строки. Этот алгоритм требует только двух слов на каждый входной символ. Алгоритм работает сначала с первыми i символами суффикса а за тем, используя положения суффиксов в сортируемом массиве, производит сортировку для первых 2i символов. К сожалению этот алгоритм работает заметно медленнее.

    В работе [1] предложен несколько лучший алгоритм сортировки суффиксов. В этом алгоритме сортируются суффиксы строки S, которая содержит N символов S[0,.,N-1].

    1. Пусть k число символов, соответствующих машинному слову. Образуем строку S' из S путем добавления k символов EOF в строку S. Предполагается, что EOF не встречается в строке S.
    2. Инициализируем массив W из N слов W[0,.,N-1] так, что W[i] содержат символы S'[i,.,i+k-1] упорядоченные таким образом, что целочисленное сравнение слов согласуется с лексикографическим сравнением для k-символьных строк. Упаковка символов в слова имеет два преимущества: это позволяет для двух префиксов сравнить сразу k байт и отбросить многие случаи, описанные ниже.
    3. Инициализируется массив V из N целых чисел. Если элемент V содержит j, он представляет собой суффикс S', чей первый символ равен S'[j]. Когда выполнение алгоритма завершено, суффикс V[i] будет i-ым суффиксом в лексикографическом порядке.
    4. Инициализируем целочисленный массив V так, что для каждого i = 0,.,N-1 : V[i]=i.
    5. Сортируем элементы V, используя первые два символа каждого суффикса в качестве ключа сортировки. Далее для каждого символа ch из алфавита выполняем шаги 6 и 7. Когда эти итерации завершены, V представляет собой отсортированные суффиксы S и работа алгоритма завершается.
    6. Для каждого символа ch' в алфавите выполняем сортировку элементов V, начинающихся с ch, за которым следует ch'. В процессе выполнения сортировки сравниваем элементы V путем сопоставления суффиксов, которые они представляют при индексировании массива W. На каждом шаге рекурсии следует отслеживать число символов, которые оказались равными в группе, чтобы не сравнивать их снова. Все суффиксы, начинающиеся с ch, отсортированы в рамках V.
    7. Для каждого элемента V[i], соответствующего суффиксу, начинающемуся с ch (то есть, для которого S[V[i]] = ch), установить W[V[i]] значение с ch в старших битах и i в младших битах. Новое значение W[V[i]] сортируется в те же позиции, что и старые значения.

    Данный алгоритм может быть улучшен различными способами. Одним из самоочевидных методов является выбор символа ch на этапе 5, начиная с наименьшего общего символа в S и предшествующий наиболее общему.

    Ссылки

    1. M.Burrows and D.J.Wheeler. A block-sorting Lossless Data Compression Algorithm. Digital Systems Research Center. SRC report 124. May 10, 1994.
    2. J.L.Bently, D.D.Sleator, R.E.Tarjan, and V.K.Wei. A locally adaptive data compression algorithm. Communications of the ACM, Vol. 29, No. 4, April 1986, pp. 320-330
    3. E.M.McCreight. A space economical suffix tree construction algorithm. Journal of the ACM, Val. 32, No. 2, April 1976, pp. 262-272.
    4. U.Manber and E.W.Mayers, Suffix arrays: Anew method for on-line string searches. SIAM Journal on Computing, Vol. 22, No. 5, October 1993, pp. 935-948.

    Смотри также раздел 2.6.3 "Сжатие данных с использованием преобразования Барроуза-Вилера",

    Previous: 2.6.1 Алгоритм Зива-Лемпеля    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера


    previous up down next index index
    Previous: 2.6.2 Локально адаптивный алгоритм сжатия    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.6.4 Метод Шеннона-Фано

    2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Майкл Барроуз и Давид Вилер (Burrows-Wheeler) в 1994 году предложили свой алгоритм преобразования (BWT). Этот алгоритм работает с блоками данных и обеспечивает эффективное сжатие без потери информации. В результате преобразования блок данных имеет ту же длину, но другой порядок расположения символов. Алгоритм тем эффективнее, чем больший блок данных преобразуется (например, 256-512 Кбайт). Пояснение работы алгоритма будет выполнено на ограниченном объеме исходных данных (строка S длиной N, например, SEMENOV). Строка S рассматривается как последовательность, состоящая из N строк.

    Сначала осуществляется циклический сдвиг строки S и формируется N-1 новая строка. На практике строки не размножаются, а создается массив указателей на циклический буфер, где лежит исходная строка S.

    Строка

    S E M E N O V

    S0

    E M E N O V S

    S1

    M E N O V S E

    S2

    E N O V S E M

    S3

    N O V S E M E

    S4

    O V S E M E N

    S5

    V S E M E N O

    S6

    Далее выполняется лексикографическое упорядочение (сортировка) этих строк (указателей). Для упорядочения можно использовать С-функции типа strcmp() или memcmp() (учитывая особенности структуры буфера, это должны быть их функциональные аналоги).

    F

    L

    Строка

    E

    M

    E

    N

    O

    V

    S

    S1

    E

    N

    O

    V

    S

    E

    M

    S3

    M

    E

    N

    O

    V

    S

    E

    S2

    N

    O

    V

    S

    E

    M

    E

    S4

    O

    V

    S

    E

    M

    E

    N

    S5

    S

    E

    M

    E

    N

    O

    V

    S0

    V

    S

    E

    M

    E

    N

    O

    S6

    Первая колонка помечена буквой F, а последняя - L. Колонка F (EEMNOSV) содержит все символы исходной строки S, записанные в упорядоченной последовательности. Строка L представляет собой последовательность префиксных символов для строки S.

    Результатом работы алгоритма BWT является строка L и первичный индекс, который представляет собой номер элемента строки L, где хранится первый символ исходной строки S. В приведенном примере индекс равен 1.

    Смотри http://web2.airmail/markn/articles/bwt/bwt.htm

    Previous: 2.6.2 Локально адаптивный алгоритм сжатия    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.6.4 Метод Шеннона-Фано


    previous up down next index index
    Previous: 2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.6.5 Статический алгоритм Хафмана

    2.6.4 Метод Шеннона-Фано
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Данный метод выделяется своей простотой. Берутся исходные сообщения m(i) и их вероятности появления P(m(i)). Этот список делится на две группы с примерно равной интегральной вероятностью. Каждому сообщению из группы 1 присваивается 0 в качестве первой цифры кода. Сообщениям из второй группы ставятся в соответствие коды, начинающиеся с 1. Каждая из этих групп делится на две аналогичным образом и добавляется еще одна цифра кода. Процесс продолжается до тех пор, пока не будут получены группы, содержащие лишь одно сообщение. Каждому сообщению в результате будет присвоен код x c длиной -lg(P(x)). Это справедливо, если возможно деление на подгруппы с совершенно равной суммарной вероятностью. Если же это невозможно, некоторые коды будут иметь длину -lg(P(x))+1. Алгоритм Шеннона-Фано не гарантирует оптимального кодирования. Смотри http://www.ics.uci.edu/~dan/pubs/DC-Sec3.html.

    Previous: 2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.6.5 Статический алгоритм Хафмана


    previous up down next index index
    Previous: 2.6.4 Метод Шеннона-Фано    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.7 Обнаружение ошибок

    2.6.5 Статический алгоритм Хафмана
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Статический алгоритм Хафмана можно считать классическим (см. также Р. Галлагер. Теория информации и надежная связь. "Советское радио", Москва, 1974.) Определение статический в данном случае отностится к используемым словарям. Смотри также www.ics.ics.uci.edu/~dan/pubs/DataCompression.html (Debra A. Lelewer и Daniel S. Hirschberg).

    Пусть сообщения m(1),.,m(n) имеют вероятности P(m(1)),. P(m(n)) и пусть для определенности они упорядочены так, что P(m(1)) Ё P(m(2)) Ё . Ё P(m(N)). Пусть x1,., xn - совокупность двоичных кодов и пусть l1, l2,., lN - длины этих кодов. Задачей алгоритма является установление соответствия между m(i) и xj . Можно показать, что для любого ансамбля сообщений с полным числом более 2 существует двоичный код, в котором два наименее вероятных кода xN и xN-1 имеют одну и ту же длину и отличаются лишь последним символом: xN имеет последний бит 1, а xN-1 - 0. Редуцированный ансамбль будет иметь свои два наименее вероятные сообщения сгруппированными вместе. После этого можно получить новый редуцированный ансамбль и так далее. Процедура может быть продолжена до тех пор, пока в очередном ансамбле не останется только два сообщения. Процедура реализации алгоритма сводится к следующему (см. рис. 2.6.5.1). Сначала группируются два наименее вероятные сообщения, предпоследнему сообщению ставится в соответствие код с младшим битом, равным нулю, а последнему - код с единичным младшим битом (на рисунке m(4) и m(5)). Вероятности этих двух сообщений складываются, после чего ищутся два наименее вероятные сообщения во вновь полученном ансамбле (m(3) и m`(4); p(m`(4)) = p(m(4)) + P(m(5))).

    Рис. 2.6.5.1 Пример реализации алгоритма Хафмана

    На следующем шаге наименее вероятными сообщениями окажутся m(1) и m(2). Кодовые слова на полученном дереве считываются справа налево. Алгоритм выдает оптимальный код (минимальная избыточность).

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

    Возможно применение стандартных алфавитов (кодовых таблиц) для пересылки английского, русского, французского и т.д. текстов, программных текстов на С++, Паскале и т.д. Кодирование при этом не будет оптимальным, но исключается статистическая обработка пересылаемых фрагментов и отпадает необходимость пересылки кодовых таблиц.

    Previous: 2.6.4 Метод Шеннона-Фано    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.7 Обнаружение ошибок


    previous up down next index index
    Previous: 2.5.2 Стандарт MPEG-7    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 3 Каналы передачи данных
        Next: 2.6.1 Алгоритм Зива-Лемпеля

    2.6 Методы сжатия информации
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    2.6 Методы сжатия информации

    3

    3

    2.6.1 Алгоритм Зива-Лемпеля

    3

    3

    2.6.2 Локально адаптивный алгоритм сжатия

    2

    2

    2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

    1

    1

    2.6.4 Метод Шеннона-Фано

    1

    3

    2.6.5 Статический алгоритм Хафмана

    1

    1

    Полагаю, что все читатели знакомы с архиваторами файлов, вероятно, многие из вас неоднократно ими пользовались. Целью архивации файлов является экономия места на жестком или гибком магнитном диске. Кому не приходилось время от времени задумываться над тем, войдет ли данный файл на дискету? Существует большое число программ-архиваторов, имеются и специальные системные программные средства типа Stacker или Doublespace и т.д., решающие эту проблему.

    Первые теоретические разработки в области сжатия информации относятся к концу 40-х годов. В конце семидесятых появились работы Шеннона, Фано и Хафмана. К этому времени относится и создание алгоритма FGK (Faller, Gallager, Knuth), где используется идея "сродства", а получатель и отправитель динамически меняют дерево кодов (смотри, например, http://www.ics.uci.edu/~dan/plus/DC-Sec4.html).

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

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

    Сжатие информации без потерь осуществляется статистическим кодированием или на основе предварительно созданного словаря. Статистические алгоритмы (напр., схема кодирования Хафмана) присваивают каждому входному символу определенный код. При этом наиболее часто используемому символу присваивается наиболее короткий код, а наиболее редкому - более длинный. Таблицы кодирования создаются заранее и имеют ограниченный размер. Этот алгоритм обеспечивает наибольшее быстродействие и наименьшие задержки. Для получения высоких коэффициентов сжатия статистический метод требует больших объемов памяти.

    Альтернативой статистическому алгоритму является схема сжатия, основанная на динамически изменяемом словаре (напр., алгоритмы Лембеля-Зива). Данный метод предполагает замену потока символов кодами, записанными в памяти в виде словаря (таблица перекодировки). Соотношение между символами и кодами меняется вместе с изменением данных. Таблицы кодирования периодически меняются, что делает метод более гибким. Размер небольших словарей лежит в пределах 2-32 килобайт, но более высоких коэффициентов сжатия можно достичь при заметно больших словарях до 400 килобайт.

    Реализация алгоритма возможна в двух режимах: непрерывном и пакетном. Первый использует для создания и поддержки словаря непрерывный поток символов. При этом возможен многопротокольный режим (например, TCP/IP и DECnet). Словари сжатия и декомпрессии должны изменяться синхронно, а канал должен быть достаточно надежен (напр., X.25 или PPP), что гарантирует отсутствие искажения словаря при повреждении или потере пакета. При искажении одного из словарей оба ликвидируются и должны быть созданы вновь.

    Пакетный режим сжатия также использует поток символов для создания и поддержания словаря, но поток здесь ограничен одним пакетом и по этой причине синхронизация словарей ограничена границами кадра. Для пакетного режима достаточно иметь словарь объемом, порядка 4 Кбайт. Непрерывный режим обеспечивает лучшие коэффициенты сжатия, но задержка получения информации (сумма времен сжатия и декомпрессии) при этом больше, чем в пакетном режиме.

    При передаче пакетов иногда применяется сжатие заголовков, например, алгоритм Ван Якобсона (RFC-1144). Этот алгоритм используется при скоростях передачи менее 64 Kбит/с. При этом достижимо повышение пропускной способности на 50% для скорости передачи 4800 бит/с. Сжатие заголовков зависит от типа протокола. При передаче больших пакетов на сверх высоких скоростях по региональным сетям используются специальные канальные алгоритмы, независящие от рабочих протоколов. Канальные методы сжатия информации не могут использоваться для сетей, базирующихся на пакетной технологии, SMDS (Switched Multi-megabit Data Service), ATM, X.25 и Frame Relay. Канальные методы сжатия дают хорошие результаты при соединении по схеме точка-точка, а при использовании маршрутизаторов возникают проблемы - ведь нужно выполнять процедуры сжатия/декомпрессии в каждом маршрутизаторе, что заметно увеличивает суммарное время доставки информации. Возникает и проблема совместимости маршрутизаторов, которая может быть устранена процедурой идентификации при у становлении виртуального канала.

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

    Если при работе с пакетами заголовки оставлять неизмененными, а сжимать только информационные поля, ограничение на использование стандартных маршрутизаторов может быть снято. Пакеты будут доставляться конечному адресату, и только там будет выполняться процедура декомпрессии. Такая схема сжатия данных приемлема для сетей X.25, SMDS, Frame Relay и ATM. Маршрутизаторы корпорации CISCO поддерживают практически все режимы сжатия/декомпрессии информации, перечисленные выше.

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

    Previous: 2.5.2 Стандарт MPEG-7    UP: 2.4 Методы преобразования и передачи звуковых сигналов
    Down: 3 Каналы передачи данных    Next: 2.6.1 Алгоритм Зива-Лемпеля


    previous up down next index index
    Previous: 2.6 Методы сжатия информации    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.6.2 Локально адаптивный алгоритм сжатия

    2.6.1 Алгоритм Зива-Лемпеля
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Большинство алгоритмов сжатия базируется на последовательной схеме сжатия Лемпеля-Зива (Lempel-Ziv, 1977). Этот алгоритм используется, в частности, стандартной процедурой UNIX Compress. Методики со статистическим моделированием могут обеспечить лучшее сжатие, но они заметно медленнее. Но существует алгоритм, который совмещает в себе лучшие из черт названных выше. Этот алгоритм не предусматривает последовательной обработки входных данных, а обрабатывает текст по-блочно. Здесь используется обратимое преобразование блока данных к виду, который позволяет эффективно сжать данные с помощью простых алгоритмов. Преобразование имеет целью сгруппировать символы так, чтобы вероятность появления последовательностей идентичных символов значительно возросла. Такой текст может быть легко сжат посредством локально-адаптивных алгоритмов в сочетании с кодировкой Хафмана и арифметической кодировкой.

    Последовательность S, содержащая N символов ({S(0),. S(N-1)}), подвергается N циклическим сдвигам (вращениям), лексикографической сортировке, а последний символ при каждом вращении извлекается. Из этих символов формируется строка L, где i-ый символ является последним символом i-го вращения. Кроме строки L создается индекс I исходной строки S в упорядоченном списке вращений. Существует эффективный алгоритм восстановления исходной последовательности символов S на основе строки L и индекса I. Процедура сортировки объединяет результаты вращений с идентичными начальными символами. Предполагается, что символы в S соответствуют алфавиту, содержащему K символов.

    Для пояснения работы алгоритма возьмем последовательность S= "abraca" (N=6), алфавит X = {'a','b','c','r'}.

    1. Формируем матрицу из N*N элементов, чьи строки представляют собой результаты циклического сдвига (вращений) исходной последовательности S, отсортированных лексикографически. По крайней мере одна из строк M содержит исходную последовательность S. Пусть I является индексом строки S. В приведенном примере индекс I=1, а матрица M имеет вид:

    Номер строки

    0

    aabrac

    1

    abraca

    2

    acaabr

    3

    bracaa

    4

    caabra

    5

    racaab

    2. Пусть строка L представляет собой последнюю колонку матрицы M с символами L[0],.,L[N-1] (соответствуют M[0,N-1],.,M[N-1,N-1]). Формируем строку последних символов вращений. Окончательный результат характеризуется (L,I). В данном примере L='caraab', I =1.

    Процедура декомпрессии использует L и I. Целью этой процедуры является получение исходной последовательности из N символов (S).

    1. Сначала вычисляем первую колонку матрицы M (F). Это делается путем сортировки символов строки L. Каждая колонка исходной матрицы M представляет собой перестановки исходной последовательности S. Таким образом, первая колонка F и L являются перестановками S. Так как строки в M упорядочены, размещение символов в F также упорядочено. F='aaabcr'.

    2. Рассматриваем ряды матрицы M, которые начинаются с заданного символа ch. Строки матрицы М упорядочены лексикографически, поэтому строки, начинающиеся с ch упорядочены аналогичным образом. Определим матрицу M', которая получается из строк матрицы M путем циклического сдвига на один символ вправо. Для каждого i=0,., N-1 и каждого j=0,.,N-1,

    M'[i,j] = m[i,(j-1) mod N]

    В рассмотренном примере M и M' имеют вид:

    Строка

    M

    M'

    0

    aabrac

    caabra

    1

    abraca

    aabraс

    2

    acaabr

    racaab

    3

    bracaa

    abraca

    4

    caabra

    acaabr

    5

    racaab

    bracaa

    Подобно M каждая строка M' является вращением S, и для каждой строки M существует соответствующая строка M'. M' получена из M так, что строки M' упорядочены лексикографически, начиная со второго символа. Таким образом, если мы рассмотрим только те строки M', которые начинаются с заданного символа ch, они должны следовать упорядоченным образом с учетом второго символа. Следовательно, для любого заданного символа ch, строки M, которые начинаются с ch, появляются в том же порядке что и в M', начинающиеся с ch. В нашем примере это видно на примере строк, начинающихся с 'a'. Строки 'aabrac', 'abraca' и 'acaabr' имеют номера 0, 1 и 2 в M и 1, 3, 4 в M'.

    Используя F и L, первые колонки M и M' мы вычислим вектор Т, который указывает на соответствие между строками двух матриц, с учетом того, что для каждого j = 0,.,N-1 строки j M' соответствуют строкам T[j] M.

    Если L[j] является к-ым появлением ch в L, тогда T[j]=1, где F[i] является к-ым появлением ch в F. Заметьте, что Т представляет соответствие один в один между элементами F и элементами L, а F[T[j]] = L[j]. В нашем примере T равно: (4 0 5 1 2 3).

    3. Теперь для каждого i = 0,., N-1 символы L[i] и F[i] являются соответственно последними и первыми символами строки i матрицы M. Так как каждая строка является вращением S, символ L[i] является циклическим предшественником символа F[i] в S. Из Т мы имеем F[T[j]] = L[j]. Подставляя i =T[j], мы получаем символ L[T(j)], который циклически предшествует символу L[j] в S.

    Индекс I указывает на строку М, где записана строка S. Таким образом, последний символ S равен L[I]. Мы используем вектор T для получения предшественников каждого символа: для каждого i = 0,.,N-1 S[N-1-i] = L[Ti[I]], где T0[x] =x, а Ti+1[x] = T[Ti[x]. Эта процедура позволяет восстановить первоначальную последовательность символов S ('abraca').

    Последовательность Ti[I] для i =0,.,N-1 не обязательно является перестановкой чисел 0,.,N-1. Если исходная последовательность S является формой Zp для некоторой подстановки Z и для некоторого p>1, тогда последовательность Ti[I] для i = 0,.,N-1 будет также формой Z'p для некоторой субпоследовательности Z'. Таким образом, если S = 'cancan', Z = 'can' и p=2, последовательность Ti[I] для i = 0,.,N-1 будет [2,4,0,2,4,0].

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

    Возьмем в качестве примера букву "t" в слове 'the' и предположим, что исходная последовательность содержит много таких слов. Когда список вращений упорядочен, все вращения, начинающиеся с 'he', будут взаимно упорядочены. Один отрезок строки L будет содержать непропорционально большое число 't', перемешанных с другими символами, которые могут предшествовать 'he', такими как пробел, 's', 'T' и 'S'.

    Аналогичные аргументы могут быть использованы для всех символов всех слов, таким образом, любая область строки L будет содержать большое число некоторых символов. В результате вероятность того, что символ 'ch' встретится в данной точке L, весьма велика, если ch встречается вблизи этой точки L, и мала в противоположном случае. Это свойство способствует эффективной работе локально адаптивных алгоритмов сжатия, где кодируется относительное положение идентичных символов. В случае применения к строке L, такой кодировщик будет выдавать малые числа, которые могут способствовать эффективной работе последующего кодирования, например, посредством алгоритма Хафмана.

    Ссылки

    1. J.Ziv and A.Lempel. A universal algorithm for sequential data compression. IEEE Transactions on Information Theory. Vol. IT-23, N.3, May 1977, pp. 337-343.
    2. J.Ziv and A.Lempel. Compression of individual sequences via variable rate coding. IEEE Transactions on Information Theory. Vol. IT-24. N.5, September 1978, pp. 530-535.
    3. M.Burrows and D.J.Wheeler. A block-sorting Lossless Data Compression Algorithm. Digital Systems Research Center. SRC report 124. May 10, 1994.
    4. J.L.Bently, D.D.Sleator, R.E.Tarjan, and V.K.Wei. A locally adaptive data compression algorithm. Communications of the ACM, Vol. 29, No. 4, April 1986, pp. 320-330
    5. http://www.ics.uci.edu/~dan/pubs/DataCompression.html (Saleem Bhatti)
    6. http://www.speednet/~spenser/ted/DataCompression.html
    7. http://www.iicm.edu/jucs_1_8/differencial_ziv_lempel_text/html/paper.html

    Previous: 2.6 Методы сжатия информации    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.6.2 Локально адаптивный алгоритм сжатия


    previous up down next index index
    Previous: 2.6.5 Статический алгоритм Хафмана    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.8 Коррекция ошибок

    2.7 Обнаружение ошибок
    Семенов Ю.А. (ГНЦ ИТЭФ)

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

    Простейшим способом обнаружения ошибок является контроль по четности. Обычно контролируется передача блока данных (М бит). Этому блоку ставится в соответствие кодовое слово длиной N бит, причем N>M. Избыточность кода характеризуется величиной 1-M/N. Вероятность обнаружения ошибки определяется отношением M/N (чем меньше это отношение, тем выше вероятность обнаружения ошибки, но и выше избыточность).

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

    Пусть А и Б две двоичные кодовые последовательности равной длины. Расстояние Хэмминга между двумя этими кодовыми последовательностями равно числу символов, которыми они отличаются. Например, расстояние Хэмминга между кодами 00111 и 10101 равно 2.

    Можно показать, что для детектирования ошибок в n битах, схема кодирования требует применения кодовых слов с расстоянием Хэмминга не менее N+1. Можно также показать, что для исправления ошибок в N битах необходима схема кодирования с расстоянием Хэмминга между кодами не менее 2N+1. Таким образом, конструируя код, мы пытаемся обеспечить расстояние Хэмминга между возможными кодовыми последовательностями больше, чем оно может возникнуть из-за ошибок.

    Широко распространены коды с одиночным битом четности. В этих кодах к каждым М бит добавляется 1 бит, значение которого определяется четностью (или нечетностью) суммы этих М бит. Так, например, для двухбитовых кодов 00, 01, 10, 11 кодами с контролем четности будут 000, 011, 101 и 110. Если в процессе передачи один бит будет передан неверно, четность кода из М+1 бита изменится.

    Предположим, что частота ошибок (BER) равна р=10-4. В этом случае вероятность передачи 8 бит с ошибкой составит 1-(1-p)8=7,9х10-4. Добавление бита четности позволяет детектировать любую ошибку в одном из переданных битах. Здесь вероятность ошибки в одном из 9 бит равна 9p(1-p)8. Вероятность же реализации необнаруженной ошибки составит 1-(1-p)9 - 9p(1-p)8 = 3,6x10-7. Таким образом, добавление бита четности уменьшает вероятность необнаруженной ошибки почти в 1000 раз. Использование одного бита четности типично для асинхронного метода передачи. В синхронных каналах чаще используется вычисление и передача битов четности как для строк, так и для столбцов передаваемого массива данных. Такая схема позволяет не только регистрировать но и исправлять ошибки в одном из битов переданного блока.

    Контроль по четности достаточно эффективен для выявления одиночных и множественных ошибок в условиях, когда они являются независимыми. При возникновении ошибок в кластерах бит метод контроля четности неэффективен и тогда предпочтительнее метод вычисления циклических сумм (CRC). В этом методе передаваемый кадр делится на специально подобранный образующий полином. Дополнение остатка от деления и является контрольной суммой.

    В Ethernet Вычисление crc производится аппаратно (см. также ethernet). На рис. 2.7.1. показан пример реализации аппаратного расчета CRC для образующего полинома B(x)= 1 + x2 + x3 +x5 + x7. В этой схеме входной код приходит слева.

    Рис. 2.7.1. Схема реализации расчета CRC

    Эффективность CRC для обнаружения ошибок на многие порядки выше простого контроля четности. В настоящее время стандартизовано несколько типов образующих полиномов. Для оценочных целей можно считать, что вероятность невыявления ошибки в случае использования CRC, если ошибка на самом деле имеет место, равна (1/2)r, где r - степень образующего полинома.

    CRC-12 x12 + x11 + x3 + x2 + x1 + 1
    CRC-16 x16 + x15 + x2 + 1
    CRC-CCITT x16 + x12 + x5 + 1

    Previous: 2.6.5 Статический алгоритм Хафмана    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.8 Коррекция ошибок


    previous up down next index index
    Previous: 2.7 Обнаружение ошибок    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.9 Видеоконференции по каналам Интернет и ISDN

    2.8 Коррекция ошибок
    Семенов Ю.А. (ГНЦ ИТЭФ)

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

    Код Хэмминга представляет собой блочный код, который позволяет выявить и исправить ошибочно переданный бит в пределах переданного блока. Обычно код Хэмминга характеризуется двумя целыми числами, например, (11,7) используемый при передаче 7-битных ASCII-кодов. Такая запись говорит, что при передаче 7-битного кода используется 4 контрольных бита (7+4=11). При этом предполагается, что имела место ошибка в одном бите и что ошибка в двух или более битах существенно менее вероятна. С учетом этого исправление ошибки осуществляется с определенной вероятностью. Например, пусть возможны следующие правильные коды (все они, кроме первого и последнего, отстоят друг от друга на расстояние 4):

    00000000
    11110000
    00001111
    11111111

    При получении кода 00000111 не трудно предположить, что правильное значение полученного кода равно 00001111. Другие коды отстоят от полученного на большее расстояние Хэмминга.

    Рассмотрим пример передачи кода буквы s = 0x073 = 1110011 с использованием кода Хэмминга (11,7).

    Позиция бита:

    11

    10

    9

    8

    7

    6

    5

    4

    3

    2

    1

    Значение бита:

    1

    1

    1

    *

    0

    0

    1

    *

    1

    *

    *

    Символами * помечены четыре позиции, где должны размещаться контрольные биты. Эти позиции определяются целой степенью 2 (1, 2, 4, 8 и т.д.). Контрольная сумма формируется путем выполнения операции XOR (исключающее ИЛИ) над кодами позиций ненулевых битов. В данном случае это 11, 10, 9, 5 и 3. Вычислим контрольную сумму:

    11 =

    1011

    10 =

    1010

    09 =

    1001

    05 =

    0101

    03 =

    0011

    s =

    1110

    Таким образом, приемник получит код:

    Позиция бита:

    11

    10

    9

    8

    7

    6

    5

    4

    3

    2

    1

    Значение бита:

    1

    1

    1

    1

    0

    0

    1

    1

    1

    1

    0

    Просуммируем снова коды позиций ненулевых битов и получим нуль.

    11 =

    1011

    10 =

    1010

    09 =

    1001

    08 =

    1000

    05 =

    0101

    04 =

    0100

    03 =

    0011

    02 =

    0010

    s =

    0000

    Ну а теперь рассмотрим два случая ошибок в одном из битов посылки, например, в бите 7 (1 вместо 0) и в бите 5 (0 вместо 1). Просуммируем коды позиций ненулевых бит еще раз.

    11 =

    1011

    10 =

    1010

    09 =

    1001

    08 =

    1000

    07 =

    0111

    05 =

    0101

    04 =

    0100

    03 =

    0011

    02 =

    0010

    s =

    0111

    11 = 1011

    10 =

    1010

    09 =

    1001

    08 =

    1000

    04 =

    0100

    03 =

    0011

    02 =

    0010

    s =

    0101

    В обоих случаях контрольная сумма равна позиции бита, переданного с ошибкой. Теперь для исправления ошибки достаточно инвертировать бит, номер которого указан в контрольной сумме. Понятно, что если ошибка произойдет при передаче более чем одного бита, код Хэмминга при данной избыточности окажется бесполезен.

    В общем случае код имеет N=M+C бит и предполагается, что не более чем один бит в коде может иметь ошибку. Тогда возможно N+1 состояние кода (правильное состояние и n ошибочных). Пусть М=4, а N=7, тогда слово-сообщение будет иметь вид: M4, M3, M2, C3, M1, C2, C1. Теперь попытаемся вычислить значения С1, С2, С3. Для этого используются уравнения, где все операции представляют собой сложение по модулю 2:

    С1 = М1 + М2 + М4
    С2 = М1 + М3 + М4
    С3 = М2 + М3 + М4

    Для определения того, доставлено ли сообщение без ошибок, вычисляем следующие выражения (сложение по модулю 2):

    С11 = С1 + М4 + М2 + М1
    С12 = С2 + М4 + М3 + М1
    С13 = С3 + М4 + М3 + М2

    Результат вычисления интерпретируется следующим образом.

    С11

    С12

    С13

    Значение

    1

    2

    4

    Позиция бит

    0

    0

    0

    Ошибок нет

    0

    0

    1

    Бит С3 не верен

    0

    1

    0

    Бит С2 не верен

    0

    1

    1

    Бит М3 не верен>

    1

    0

    0

    Бит С1 не верен>

    1

    0

    1

    Бит М2 не верен

    1

    1

    0

    Бит М1 не верен

    1

    1

    1

    Бит М4 не верен

    Описанная схема легко переносится на любое число n и М.

    Число возможных кодовых комбинаций М помехоустойчивого кода делится на n классов, где N - число разрешенных кодов. Разделение на классы осуществляется так, чтобы в каждый класс вошел один разрешенный код и ближайшие к нему (по расстоянию Хэмминга) запрещенные коды. В процессе приема данных определяется, к какому классу принадлежит пришедший код. Если код принят с ошибкой, он заменяется ближайшим разрешенным кодом. При этом предполагается, что кратность ошибки не более qm.

    Можно доказать, что для исправления ошибок с кратностью не более qmm (как правило, оно выбирается равным D = 2qm +1). В теории кодирования существуют следующие оценки максимального числа N n-разрядных кодов с расстоянием D.

    d=1

    n=2n

    d=2

    n=2n-1

    d=3

    n < 2n /(1+n)

    d=2q+1

    (для кода Хэмминга это неравенство превращается в равенство)

    В случае кода Хэмминга первые k разрядов используются в качестве информационных, причем

    k= n - log(n+1),

    откуда следует (логарифм по основанию 2), что k может принимать значения 0, 1, 4, 11, 26, 57 и т.д., это и определяет соответствующие коды Хэмминга (3,1); (7,4); (15,11); (31,26); (63,57) и т.д.

    Циклические коды

    Обобщением кодов Хэмминга являются циклические коды BCH (Bose-Chadhuri-Hocquenghem). Это коды с широким выбором длины и возможностей исправления ошибок. Циклические коды характеризуются полиномом g(x) степени n-k, g(x) = 1 + g1x + g2x2 + . + xn-k. g(x) называется порождающим многочленом циклического кода. Если многочлен g(x) n-k и является делителем многочлена xn + 1, то код C(g(x)) является линейным циклическим (n,k)-кодом. Число циклических n-разрядных кодов равно числу делителей многочлена xn + 1.

    При кодировании слова все кодовые слова кратны g(x). g(x) определяется на основе сомножителей полинома xn +1 как:

    xn +1 = g(x)h(x)

    Например, если n=7 (x7+1), его сомножители (1 + x + x3)(1 + x + x2 + x4), а g(x) = 1+x + x3.

    Чтобы представить сообщение h(x) в виде циклического кода, в котором можно указать постоянные места проверочных и информационных символов, нужно разделить многочлен xn-kh(x) на g(x) и прибавить остаток от деления к многочлену xn-kh(x). См. Л.Ф. Куликовский и В.В. Мотов, "Теоретические основы информационных процессов". Москва "Высшая школа" 1987. Привлекательность циклических кодов заключается в простоте аппаратной реализации с использованием сдвиговых регистров.

    Пусть общее число бит в блоке равно N, из них полезную информацию несут в себе K бит, тогда в случае ошибки, имеется возможность исправить m бит. Таблица 2.8.1 содержит зависимость m от N и K для кодов ВСН.

    Таблица 2.8.1

    Общее число бит N

    Число полезных бит М

    Число исправляемых бит m

    31

    26

    1

    21

    2

    16

    3

    63

    57

    1

    51

    2

    45

    3

    127

    120

    1

    113

    2

    106

    3

    Увеличивая разность N-M, можно не только нарастить число исправляемых бит m, но открыть возможность обнаружить множественные ошибки. В таблице 2.8.2 приведен процент обнаруживаемых множественных ошибок в зависимости от M и N-M.

    Таблица 2.8.2

    Число полезных бит М

    Число избыточных бит (n-m)

    6

    7

    8

    32

    48%

    74%

    89%

    40

    36%

    68%

    84%

    48

    23%

    62%

    81%

    Другой блочный метод предполагает "продольное и поперечное" контрольное суммирование предаваемого блока. Блок при этом представляется в виде N строк и M столбцов. Вычисляется биты четности для всех строк и всех столбцов, в результате получается два кода, соответственно длиной N и M бит. На принимающей стороне биты четности для строк и столбцов вычисляются повторно и сравниваются с присланными. При выявлении отличия в бите i кода битов четности строк и бите j - кода столбцов, позиция неверного бита оказывается определенной (i,j). Понятно, что если выявится два и более неверных битов в контрольных кодах строк и столбцов, задача коррекции становится неразрешимой. Уязвим этот метод и для двойных ошибок, когда сбой был, а контрольные коды остались корректными.

    Применение кодов свертки позволяют уменьшить вероятность ошибок при обмене, даже если число ошибок при передаче блока данных больше 1.

    Линейные блочные коды

    Блочный код определяется, как набор возможных кодов, который получается из последовательности бит, составляющих сообщение. Например, если мы имеем К бит, то имеется 2К возможных сообщений и такое же число кодов, которые могут быть получены из этих сообщений. Набор этих кодов представляет собой блочный код. Линейные коды получаются в результате перемножения сообщения М на порождающую матрицу G[IA]. Каждой порождающей матрице ставится в соответствие матрица проверки четности (n-k)*n. Эта матрица позволяет исправлять ошибки в полученных сообщениях путем вычисления синдрома. Матрица проверки четности находится из матрицы идентичности i и транспонированной матрицы А. G[IA] ==> H[ATI].

    I A AT

    Если , то H[ATI] =

    Синдром полученного сообщения равен

    S = [полученное сообщение] . [матрица проверки четности].

    Если синдром содержит нули, ошибок нет, в противном случае сообщение доставлено с ошибкой. Если сообщение М соответствует М=2k, а k =3 высота матрицы, то можно записать восемь кодов:

    Сообщения

    Кодовые вектора

    Вычисленные как

    M1 = 000

    V1 = 000000

    M1.G

    M2 = 001

    V2 = 001101

    M2 . G

    M3 = 010

    V3 = 010011

    M3 . G

    M4 = 100

    V4 = 100110

    M4 . G

    M5 = 011

    V5 = 011110

    M5 . G

    M6 = 101

    V6 = 101011

    M6 . G

    M7 = 110

    V7 = 110101

    M7 . G

    M8 = 111

    V8 = 111000

    M8 . G

    Кодовые векторы для этих сообщений приведены во второй колонке. На основе этой информации генерируется таблица 2.8.3, которая называется стандартным массивом. Стандартный массив использует кодовые слова и добавляет к ним биты ошибок, чтобы получить неверные кодовые слова.

    Таблица 2.8.3. Стандартный массив для кодов (6,3)

    000000

    001101

    010011

    100110

    011110

    101011

    110101

    111000

    000001

    001100

    010010

    100111

    011111

    101010

    110100

    111001

    000010

    001111

    010001

    100100

    011100

    101001

    110111

    111010

    000100

    001001

    010111

    100010

    011010

    101111

    110001

    111100

    001000

    000101

    011011

    101110

    010110

    100011

    111101

    110000

    010000

    011101

    000011

    110110

    001110

    111011

    100101

    101000

    100000

    101101

    110011

    000110

    111110

    001011

    010101

    011000

    001001

    000100

    011010

    101111

    010111

    100010

    111100

    011001

    Предположим, что верхняя строка таблицы содержит истинные значения переданных кодов. Из таблицы 2.8.3 видно, что, если ошибки случаются в позициях, соответствующих битам кодов из левой колонки, можно определить истинное значение полученного кода. Для этого достаточно полученный код сложить с кодом в левой колонке посредством операции XOR.

    Синдром равен произведению левой колонки (CL "coset leader") стандартного массива на транспонированную матрицу контроля четности HT.

    Синдром = CL . HT

    Левая колонка стандартного массива

    000

    000000

    001

    000001

    010

    000010

    100

    000100

    110

    001000

    101

    010000

    011

    100000

    111

    001001

    Чтобы преобразовать полученный код в правильный, нужно умножить полученный код на транспонированную матрицу проверки четности, с тем чтобы получить синдром. Полученное значение левой колонки стандартного массива добавляется (XOR!) к полученному коду, чтобы получить его истинное значение. Например, если мы получили 001100, умножаем этот код на HT:

    этот результат указывает на место ошибки, истинное значение кода получается в результате операции XOR:

    под горизонтальной чертой записано истинное значение кода.

    Смотри также www.cs.ucl.ac.uk/staff/S.Bhatti/D51-notes/node33.html (Saleem Bhatti).

    Previous: 2.7 Обнаружение ошибок    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.9 Видеоконференции по каналам Интернет и ISDN


    previous up down next index index
    Previous: 2.9 Видеоконференции по каналам Интернет и ISDN    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.10 Статистическая теория каналов связи

    2.9.1 Используемые стандарты
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Для видеоконференций стандартизованы следующие скорости обмена:

    112 Кбит/с (64 видео, 48 аудио);
    128 Кбит/с (64 видео, 64 - аудио);
    128 Кбит/с (96 видео, 32 -аудио);
    128 Кбит/с (112 - видео, 16 -аудио);
    384 Кбит/с (320 - видео, 64 аудио).

    G.711 CCITT рекомендация для импульсно-кодовой модуляции (PCM) голоса с использованием m-закона кодирования при 8 кГц (8000 стробирований в сек)

    G.721 CCITT рекомендация для адаптивной дифференциальной импульсно-кодовой модуляции (ADPCM) для кодирования звука с полосой 32 кГц.

    G.722 CCITT рекомендация для ADPCM при 64 Кбит/с (7 кГц)

    G.723 CCITT рекомендация для ADPCM при 24 Кбит/с

    G.728 (CLEP) CCITT рекомендация для ADPCM при 16 Кбит/с (3.1 кГц)

    H.221 CCITT рекомендация для структуры кадров аудио-видео каналов при скоростях 64 - 1920 Кбит/с.

    H.261 или P*64- CCITT рекомендация для кодирования/декодирования аудио-видео процедур при скоростях p x 64 Кбит/с, где p=1-30, что эквивалентно 64 Кбит/с - 2 Мбит/с. Рекомендации первоначально были разработаны для узкополосного ISDN. Достижимы коэффициенты сжатия от 4:1 до 160:1. Регламентированы форматы:

    CIF 352x288 15 кадров/сек.
    Quarter CIF (QCIF) 176x144
    CIF 704x576
    QCIF 352x288
    Super CIF 704x576.

    H.320 CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC.

    JPEG - ISO/CCITT рекомендации объединенной группы фотоэкспертов. В рекомендации определен алгоритм сжатия для стационарных цветных изображений, при котором отбрасываются визуально второстепенные детали изображения, убирается избыточность в пределах кадра, в результате обеспечивается сжатие1:30 при потере качества изображения и 1:15 без потери качества.

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

    MPEG-1 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, определен алгоритм сжатия для движущегося изображения при работе с каналами 1.5 Мбит/с (1.2 Мбит/с видео + 200 Кбит/с для аудио) с коэффициентами сжатия от 50:1 до 200:1 при размере изображения 352x240x24 бит и частоте кадров 30/сек.

    MPEG-2 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, поток данных для видео и аудио лежит в пределах между 4 и 15 Мбит/с, достигаются коэффициенты сжатия от 50:1 до 200:1, размер изображения 728x486, качество соответствует телевидению высокого разрешения стандарта NTSC (National Television Standards Committee US).

    Сводные данные по стандартам для видеоконференций представлены в таблице 2.9.1.1. Новым универсальным набором стандартов для реализации видео-телефонии и мультимедийных обменов является H.323.

    Таблица 2.9.1.1

    H.320

    H.321

    H.322

    H.323

    V1/V2

    H.324

    Дата принятия

    1990

    1995

    1995

    1996/1998

    1996

    Сеть

    Узкополосная переключаемая цифровая ISDN Широкополосная ISDN
    ATM
    LAT

    Сети с гарантированной полосой пропускания

    Сети без гарантированной полосы пропускания (Ethernet)

    PSTN или POTS, аналоговые телефонные системы

    Видео

    H.261 H.263

    H.261 H.263

    H.261 H.263

    H.261
    H.263

    H.261 H.263

    Аудио

    G.711
    G.722
    G.728

    G.711
    G.722
    G.728

    G.711
    G.722
    G.728

    G.711
    G.722
    G.728
    G.723
    G.729

    G.723

    Мультиплексирование

    H.221

    H.221

    H.221

    H.225

    H.223

    Управление

    H.230
    H.242

    H.242

    H.230
    H.242

    H.245

    H.245

    Многоточечный режим

    H.231
    H.243

    H.231
    H.243

    H.231
    H.243

    H.323

    Данные

    T.120

    T.120

    T.120

    T.120

    T.120

    Общий интерфейс

    I.400

    AAL
    I.363
    AJM I.361
    PHY I.400

    I.400 &
    TCP/IP

    TCP/IP>

    V.34
    модем

    Previous: 2.9 Видеоконференции по каналам Интернет и ISDN    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.10 Статистическая теория каналов связи


    previous up down next index index
    Previous: 2.8 Коррекция ошибок    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных
        Next: 2.9.1 Используемые стандарты

    2.9 Видеоконференции по каналам Интернет и ISDN
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Расширение международных контактов и реализация проектов с "удаленными" отечественными партнерами делает актуальной проблему экономии командировочных расходов особенно в случае коротких поездок (1-7 дней). Одним из средств решения проблемы является использование видеоконференций. Видеоконференции по каналам Интернет могут быть привлекательны для дистанционного обучения и медицинской диагностики. В отличие от телевизионных программ обучение с использованием Интернет предполагает диалог между преподавателем и обучаемым, что делает процесс более эффективным (эта техника может успешно дополнить WWW-методику, широко используемую в университетах США и Европы). Медицинские приложения еще более многообещающи. Видеоконференции позволят проконсультироваться в клинике, отстоящей на тысячи километров, устроить консилиум с участием врачей из разных городов, оперативно передать томограмму или многоканальную кардиограмму пациента с целью ее интерпретации и т.д. В более отдаленной перспективе технология видеоконференций может быть применена для целей телевидения.

    Рис. 2.9.1. Оборудование, необходимое для видеоконференций

    Для проведения видеоконференции необходимо иметь цифровой канал с пропускной способностью не менее 56-128кбит/с. Если канал не позволяет, можно ограничиться аудио телеконференцией (см. раздел IP-phone). Схеме оборудования, необходимого для видеоконференции показано на рис. 2.9.1.

    Помимо стандартного оборудования рабочей станции (как правило, под ОС UNIX) требуется интерфейс для подключения видеокамеры и микрофонов. Этот интерфейс обычно снабжается аппаратной схемой сжатия видео и аудио данных. Многие современные мультимедиа интерфейсы снабжены входами для видеокамеры. Из обязательного оборудования на рис. 2.9.1 не показаны наушники и звуковые колонки. Полезным дополнением может служить сканнер, который позволит с высоким разрешением передать изображения документов или чертежей, видеомагнитофон, а также видео проектор для отображений принятого изображения на экране или телевизор с большим экраном.

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

    Реализовать видеоконференцию можно разными путями, из них два наиболее реальны:

    1.

    Использование оборудования, каналов и программного обеспечения ISDN. Полоса и качество здесь гарантируются, но стоимость весьма высока

    2.

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

    При видеоконференциях используется технология codec (coder/decoder) для выделенных и телефонных коммутируемых линий (>56 Кбит/с, интерфейс V35), применим и режим коммутации пакетов (multicast backbone, >256 Кбит/с). Перечень стандартов, регламентирующих протоколы видеоконференций можно найти в следующем разделе (2.9.1). Но базовым протоколом для работы в локальных сетях, где не гарантируется нужный уровень qos), является h.323 (1996-98 гг.; вторая дата относится к принятию версии 2). Этот стандарт обеспечивает видеоконференции для соединений точка-точка и для многоточечных топологий в рамках стека протоколов tcp/ip, он регламентирует и принципы сжатия видео и аудио информации. Привлекательность стандарта заключается в том, что он применим к уже существующей инфраструктуре телекоммуникаций с широкими вариациями задержек отклика. Способствует этому возрастающая пропускная способность локальных (fast ethernet и gigabit ethernet) и региональных сетей (SDH, ATM, FDDI, Fibre Channel и т.д.). Способствуют этому как новейшие протоколы из семейства IP - RTP и RSVP, так и поддержка H.323 такими компаниями как Intel, Microsoft, Cisco и IBM. H.323 не привязан ни к одной операционной системе и не предполагает использования какого-либо специализированного оборудования. На рис. 2.9.2 показана структура системы H.323 и основных ее компонентов.

    Рис. 2.9.2. Структура системы H.323 и основных ее компонентов

    H.323 определяет четыре главных составляющих коммуникационной системы:

    • Терминалы
    • Шлюзы
    • Блоки многоточечного управления
    • Системы управления доступом (gatekeepers)

    Терминалы служат для предоставления пользователям определенных услуг и обеспечивают двухсторонний обмен данными в реальном масштабе времени. Все терминалы H.323 должны также поддерживать стандарт H.245, который служит для выбора параметров канала. Структура терминала показана на рис. 2.9.3.

    Рис. 2.9.3. Структура терминала H.323

    Интерфейс RAS (registration/admission/status) служит для взаимодействия с блоком доступа (gatekeeper) и поддерживает протоколы RTP/RTCP. Опционными частями H.323 являются видео кодеки, протоколы для проведения информационных конференций (T.120) и возможности поддержания многоточечной связи (mcu). Внешний шлюз также является опционным элементом конференций H.323. Шлюз может выполнять функции интерфейса для согласования с требованиями других форматов, например, H.225 - H.221 или других коммуникационных процедур, например, H.245 - H.242. Типичным шлюзом можно считать соединитель H.323 с коммутируемой телефонной сетью (GSTN). Блок схема такого шлюза показана на рис. 2.9.4.

    Данный шлюз устанавливает аналоговую связь с терминалами GSTN, с терминалами H.320 по каналам ISDN и с терминалами H.324 по сети GSTN. Терминалы взаимодействуют со шлюзом через протоколы H.245 и Q.931. Применяя соответствующую перекодировку, можно обеспечить работу шлюза H.323 с терминалами, поддерживающими протоколы V.70, H.322, H.310 и H.321. Многие функции шлюза не стандартизованы, к их числу, например, относится нумерация подключенных терминалов.

    Рис. 2.9.4. Схема шлюза IP/GSTN

    Узел управления доступом (gatekeeper) является центральным блоком сети H.323. Через него проходят все запросы обслуживания, при этом он выполняет функцию виртуального переключателя. Узел управления доступом осуществляет преобразование имен терминалов и шлюзов в их IP и IPX-адреса в соответствии со спецификацией RAS. Например, если администратор сети установил верхний предел на число участников конференции, при достижении этого порога узел управления доступом может отказать в установлении соединения. Совокупность терминалов, шлюзов и блоков MTU, управляемая общим блоком доступа, называется зоной H.323. Узел управления доступом может опционно маршрутизовать запросы H.323. Разработчики иногда совмещают функции шлюза, MCU и узла управления доступом, возможно независимое совмещение функций MCU и узла управления доступом. К числу обязательных функций узла управления доступом относится.

    • преобразование адресов (например, из стандарта E.164 в транспортный формат)
    • осуществление контроля доступа к локальной сети с использованием сообщений Admission Request, Confirm и Reject (возможен режим разрешения доступа для всех запросов)
    • управление полосой пропускания (поддержка сообщений Bandwidth Request, Confirm и Reject)
    • Управление зоной. Реализация всех вышеперечисленных функций для MCU, шлюза и терминалов, зарегистрированных в зоне.

    Определены некоторые опционные функции узла управления доступом:

    • обработка запросов управления Q.931
    • осуществление авторизации терминалов (Q.931), допускаются ограничения доступа на определенные периоды времени
    • управление запросами (контроль занятости терминалов и использования полосы пропускания)

    Для организации конференций с числом участников три и более используется блок многоточечного доступа (MCU). MCU включает в себя многоточечный контроллер (MC) и многоточечный процессор (MP). MC осуществляет согласование рабочих параметров терминалов для обеспечения совместимости при передаче видео и аудио информации в рамках протокола H.245. Многоточечный контроллер управляет также ресурсами каналов, при этом поддерживается как уникастный, так и мультикастный обмен. Все терминалы посылают аудио, видео и данные MCU в режиме соединения точка-точка. Управляющая канальная информация H.245 передается непосредственно в MC. MP может выполнять перекодировку в случае использования кодеков различного типа. Конференция может быть организована в централизованном (все обмены идут через MCU) и децентрализованном режиме, когда терминалы непосредственно взаимодействуют друг с другом. Терминалы используют протокол H.245, для того чтобы сообщить MC, сколько видео- и аудио- потоков они могут обработать одновременно. MP может осуществлять отбор видеосигналов и смешение аудио-каналов при децентрализованной многоточечной конференции. Допускается и смешенный режим, когда одновременно реализуется централизованная и децентрализованная схема обменов.

    Новейшая версия H.323 (v2) за счет аутентификации и шифрования/дешифрования обеспечивает безопасность и конфиденциальность (перехват в промежуточных узлах становится невозможным). Более подробно возможности версии 2 изложены в документе http://www.databeam.com/h323/ .

    Звуковой сигнал передается в оцифрованной и сжатой форме. Алгоритмы компрессии, поддерживаемые H.323, соответствуют требованиям стандартов ITU. Терминалы H.323 должны быть способны работать со стандартом компрессии голоса G.711 (56 или 64 Кбит/c). Голосовой кодек должен следовать рекомендациям G.723, а видео кодек должен соответствовать стандарту H.261 (поддержка H.263 является опционной, этот стандарт обеспечивает более высокое качество изображения). В таблице 2.9.1 приведены форматы для видео-конференций ITU.

    Таблица 2.9.1

    Формат картинки для видео-конференции

    Размер изображения в пикселях

    H.261

    H.263

    Sub-QCIF

    128*96

    не специфицировано

    необходимо

    QCIF

    176*44

    необходимо

    необходимо

    CIF

    352*288

    опционно

    опционно

    4CIF

    702*576

    -

    опционно

    16CIF

    1408*1152

    -

    опционно

    Видеоконференции реализуемы на ЭВМ IBM/PC [1,2], Mackintosh, SUN, HP, DEC. Пакетная техника обеспечивает удовлетворительное качество изображения и звукового сопровождения при низкой загрузке канала и малой вероятности ошибок при передаче пакетов. Достижимое сжатие видеосигнала - 1000:1, звукового 8:1.

    Например, система SPARC classic M позволяет передавать по сети Ethernet до 30 кадров в секунду при разрешении 768x576 точек (PAL). Рассмотренное оборудование может использоваться не только для "дальней" связи, но для коллективного редактирования документов и чертежей в пределах одного предприятия, используя локальную сеть. Это может найти применение при реализации систем САПР больших предприятий. Для компрессии применяются методы CellB, JFPEG, MPEG1, Capture (YUV, RGB-8).

    Наиболее популярные программные продукты для телеконференций: vic, vat, nv, wb, sd, ivs. (см. http://www.anl.gov/linda/video.html .)

    Такие программные средства как VAT (Visual Audio Tool, ftp.ee.lbl.gov ), nevot (network voice terminal, gaia.cs.umass.edu:/pub/hgschulz/nevot), VIC (Video Conference), IVS (INTRA Videoconferencing System, avahi.inria.fr:/pub/videoconference), NV (Net Video, beta.xerox.com:/pub/net-research) или wb (whiteboard, ftp.ee.lbl.gov) базируются на утилитах X11, они позволяют пользователю осуществить связь ЭВМ-ЭВМ или сессии с большим числом участников по каналам Интернет. Поддерживаются следующие схемы кодирования и передачи данных: PCM (64 Кбит/с), DVI, GSM и LPC (8 Кбит/с). В wb имеется возможность импорта файлов Postscript (обычно используемых для прозрачек). При этом достигается разрешение 640*512, число цветов равно 256, число кадров 2-20, коэффициент сжатия информации ~20:1, а требуемая полоса пропускания канала >128 Кбит/с. Эти параметры не идеальны. Желательно вдвое большее разрешение, число цветов должно быть равно 16 миллионам, а частота кадров 25-50, но это требует существенно большей пропускной способности каналов (> 2 Мбит/с). Но прогресс в области быстродействия каналов связи столь стремителен....

    Система mmcc (Multimedia Conference Control program, ftp.isi.edu:confctrl/mmcc.tar.Z) во многом аналогична описанным выше, она позволяет клиенту осуществить вызов нужного партнера. Весьма полезной утилитой является SD (Session Directory, ftp.ee.lbl.gov:sd.tar.Z ), которая может запускать приложения, необходимые для проведения видео конференций.

    Пакет CUSeeMe (gated.cornell.edu:/pub/video/Mac.CU-SeeMe0.60b1) предназначен для персонального общения через Интернет, он работает на IBM/PC и MAC, требует 4 Мбайт оперативной памяти. Один кадр передается за 6-7 сек при полосе 28,8 Кбит/с, разрешение 320*240 пикселей. Такое качество соответствует скорее видео телефону. На экране предусмотрена область прокрутки, где можно напечатать какой-либо текст. Этим список доступных программных продуктов не исчерпывается. Приведенные здесь краткие описания даны лишь в качестве примеров.

    Подчеркну, что качество работы сети более критично для передачи звука, чем изображения, ведь потеря нескольких кадров подчас совсем незаметна. Потеря же пакетов при передаче звука более заметна, особенно при диалоге. Когда же используется сжатие, любые повреждения пакетов приводят к потере целых блоков данных.

    Для экспериментов с передачей звука и изображения группой IETF (Internet Engineering Task Force) была сформирована структура мультикастинг-сети MBONE. MBONE (Multicast Backbone, до 300 Кбит/с) представляет собой виртуальную сеть, построенную из уникаст-туннелей, которые функционируют поверх Интернет. MBONE составляет около 3,5% от всего Интернет. Рабочие станции для доступа к MBONE должны поддерживать IP-мультикастинг (см. RFC-1112 "Host Extensions for IP Multicasting"). Следует иметь в виду, что не все маршрутизаторы поддерживают мультикастинг.

    При работе с MBONE отправитель не должен знать, кто является получателем, а требуемая пропускная способность канала не зависит от того, обслуживается один клиент или 100.

    Требуемая полоса канала для видеоконференций определяется необходимой разрешающей способностью и частотой кадров. Таблица требований к каналу для передачи изображения представлена ниже.

    Частота
    кадров/с

    Размер экрана (24 цветовых бит)

    1280*1024

    640*480

    320*240

    160*120

    30

    900 Мбит/с

    211 Мбит/с

    53 Мбит/с

    13 Мбит/с

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

    Степень сжатия данных

    Размер экрана

    1280*1024

    640*480

    320*240

    160*120

    100:1

    9 Мбит/с

    2.11 Мбит/с

    0.53 Мбит/с

    0.13 Мбит/с

    50:1

    18

    4,22

    1,06

    0,26

    25:1

    36

    8,44

    2,12

    0.52

    12:1

    75

    17,58

    4,4

    1,08

    6:1

    150

    35,17

    8,8

    2,16

    Требования при передаче звука определяются необходимым качеством, так для получения полосы 6 Кгц нужно 64 Кбит/с, а для уровня, сопоставимого с CD, - 1,4 Мбит/с. Применение сжатия информации позволяет снизить эти требования в 4-8 раз. Общепринятыми стандартами для сжатия изображения при видеоконференциях являются JPEG, MPEG, H.261. Обычно они реализуются программно, но есть и аппаратные реализации.

    Если сегодня базовым транспортным протоколом для мультимедиа является UDP, то в самое ближайшее время его потеснит RTR и дополнят RSVP и ST-II, что заметно повысит качество и надежность (см. также раздел IP-phone).

    Набор стеков протоколов, которые могут использоваться для реализации видео конференций в рамках стандартов ITU (транспортный протокол H.320):

    1.

    GSTN - H.324 - H.320 - [T.120; H.243; H.281]

    2.

    ISDN - H.221 - H.320 - [T.120; H.243; H.281]

    3.

    ISDN - PPP - IP - H.323 - H.320 - [T.120; H.243; H.281]

    4.

    LC - PPP - IP - H.323 - H.320 - [T.120; H.243; H.281]

    5.

    ATM - AAL5 - IP - H.323 - H.320 - [T.120; H.243; H.281]

    6.

    ATM - AAL1 - H.221 - H.320 - [T.120; H.243; H.281]

    Previous: 2.8 Коррекция ошибок    UP: 2.6 Методы сжатия информации
    Down: 3 Каналы передачи данных    Next: 2.9.1 Используемые стандарты


    previous up down next index index
    Previous: 1 Введение (общие принципы построения сетей)    UP: 1 Введение (общие принципы построения сетей)
    Down: 2.4 Методы преобразования и передачи звуковых сигналов
        Next: 2.1 Передача сигналов по линиям связи

    2 Преобразование, кодировка и передача информации
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    2 Преобразование, кодировка и передача информации

    4

    3

    2.1 Передача сигналов по линиям связи

    8

    6

    2.2 Представление электрических сигналов в цифровой форме

    10

    7

    2.3 Цифровые каналы T1 и Е1

    2

    1

    2.4 Методы преобразования и передачи звуковых сигналов

    6

    5

    2.5 Методы преобразования и передачи изображения

    14

    12

    2.6 Методы сжатия информации

    3

    3

    2.7 Обнаружение ошибок

    2

    2

    2.8 Коррекция ошибок

    6

    6

    2.9 Видеоконференции по каналам Интернет и ISDN

    8

    97

    2.10 Статистическая теория каналов связи

    10

    145

    Для передачи информации на большие расстояния в настоящее время используются исключительно электромагнитные волны (акустические волны пригодны лишь для ограниченных расстояний). При этом пересылка может осуществляться по медным проводам, оптоволоконному кабелю или непосредственно, по схеме передатчик-приемник. В последнем случае используются антенны. Для того чтобы антенна была эффективна, ее размеры должны быть сравнимы с длиной передаваемой волны. Чем шире динамический диапазон передаваемых частот, тем труднее сделать антенну, пригодную для решения этой задачи. Именно по этой причине для передачи используются частоты, начиная с многих сотен килогерц и выше (длина волн сотни метров и меньше). Передача сигнала непосредственно по лучу лазера ограничена расстояниями 100-3000м и становится неустойчивой при наличии осадков даже для инфракрасных длин волн. Между тем человек воспринимает акустические колебания в диапазоне 20-12000 Гц и для целей пересылки звука (например, телефония) требуется именно этот диапазон частот. Динамический диапазон частот в этом случае равен 600, а для высококачественного воспроизведения звука он в два раза шире. При решении этой проблемы используется преобразование частот и различные методы модуляции. Так тот же частотный диапазон, лежащий в пределах (100 - 100,012) Мгц, соответствует динамическому диапазону 0,012%, что позволяет сделать компактную антенну и упростить частотное выделение сигнала.

    Для преобразования частот используется перемножение сигналов. Пусть мы имеем два синусоидальных сигнала: A 1*sin(w1 t) и A 2*sin( w2 t). Из тригонометрии известно, что:

    A1*sin( w1 t)*A2*sin( w2 t)=1/2*A1*A2*[sin( w1+w2)t + sin( w1-w2)t]. [1.1]

    Это означает, что в результате перемножения вместо двух частот f 1=w1/2p и f 2= w2/2p мы имеем две новые частоты (w1+w2)/2p и (w1-w2)/2p с амплитудой 1/2*A 1*A2. Если входной сигнал имеет полосу 0 - fм, то после перемножения с сигналом, имеющим частоту fн (несущая частота), получим сигнал с полосой в интервале от (fн - fм) до (fн+ fм). Это преобразование проиллюстрировано на рис. 2.1. (по вертикальной оси отложена спектральная плотность сигнала f(jw )). На практике это преобразование выполняется с помощью смесителей или гетеродинов, частота fн называется сигналом гетеродина или несущей.

    Рис. 2.1. Частотное преобразование

    Получение исходного сигнала из преобразованного достигается путем обратного преобразования, которое сводится к умножению полученного сигнала на sin(w нt), где w н = 2 p*fн. При таком обратном преобразовании мы получим сигнал с исходным частотным диапазоном. Помимо этого будет получен сигнал с полосой от (2fн - fм) до (2fн+ fм). Так как fн обычно много больше fм, серьезных проблем это не вызывает - достаточно воспользоваться соответствующим фильтром. Этому методу обратного преобразования присущи некоторые недостатки. Если сигнал fн имеет фазовый сдвиг q по отношению к тому, что имел сигнал, использованный при прямом преобразовании, то амплитуда выходного сигнала будет пропорциональна cosq. Понятно, что при вариации фазы амплитуда будет меняться, а при q=p/2 станет нулевой. По этой причине должны быть предприняты специальные меры для синхронизации этих сигналов (fн. передатчика и fн приемника).

    Соотношение [1.1] используется при реализации амплитудной, частотной или фазовой модуляции. Так в случае амплитудной модуляции при временной вариации A1 (=Авх) будет изменяться и амплитуда выходного сигнала (А2=Aн - амплитуда несущей частоты при этом остается постоянной; w1=w н при этом может также варьироваться). Форма сигнала на выходе такого преобразователя имеет вид: Авых = Ан[1+Авх(t)] sin w нt. Для получения формы исходного сигнала на принимающей стороне используется схема детектора (например, диодного), на выходе которого получается сигнал, пропорциональный модулю огибающей функции входного сигнала. Существуют и другие методы демодуляции амплитудно-модулированного сигнала. Главным недостатком метода амплитудной модуляции является возможность нелинейных искажений из-за перемодуляции (когда амплитуда модулирующего сигнала слишком велика).

    При частотной и фазовой модуляции амплитуда передаваемого сигнала остается почти постоянной, что исключает нелинейные искажения, связанные с широким динамическим амплитудным диапазоном. Выходной сигнал для этого вида модуляции имеет вид: Авых = Ан sin[w нt + q(t)], где q(t) зависит от формы преобразуемого входного сигнала. Часто используется комбинация амплитудной и фазовой модуляции, которая носит название квадратурной модуляции.

    Системы передачи данных с амплитудной или частотной модуляцией являются аналоговыми системами и по этой причине весьма чувствительны к шумам на входе приемника. Применение цифровых методов пересылки информации увеличивает вероятность корректной доставки. Если для аналоговой передачи требуется отношение сигнал/шум на уровне 40-60 дБ, то при цифровой передаче достаточно 10-12 дБ. Выбор типа модуляции зависит от стоящей задачи и от характеристик канала (полосы пропускания, ослабления сигнала и т.д.). Частотная модуляция менее чувствительна к амплитудным флуктуациям сигнала. Ослабление сигнала может варьироваться во времени из-за изменений в транспортной среде, это довольно типично для коммутируемых телефонных сетей. В сетях, использующих выделенные каналы, это также возможно благодаря применению динамических протоколов маршрутизации, когда длина пути может изменяться в пределах одного сеанса связи. В любом случае на передающей стороне необходим модулятор, а на принимающей демодулятор. Так как обмен обычно двунаправлен, эти устройства объединяются в одном приборе, который называется модемом (см. также раздел "4.3.7. Модемы").

    В модемах применимы несколько видов модуляции:

    FSK

    (Frequency Shift Keying) - ступенчатое переключение частоты синусоидального сигнала от f1 к f2 при неизменной амплитуде, частоте f1 ставится в соответствие логический нуль, а f2 - логическая единица.

    BPSK

    (Binary Phase-Shift Keying) - скачкообразное переключение фазы синусоидального сигнала на p при неизменной амплитуде, при этом фазе 0 ставится в соответствие логический нуль, а p- логическая единица.

    DPSK

    (Differential Phase Shift Keying) - метод, при котором изменяется фаза несущей частоты при постоянной амплитуде и частоте. Разновидность PSK, при которой кодируется лишь изменение сигнала.

    QAM

    (Quadrature Amplitude Modulation) - комбинация амплитудной и фазовой модуляции, позволяет осуществить кодирование 8 бит на бод.

    QPSK

    (Quadrature Phase-Shift Keying) - квадратурная фазовая модуляция. Использует 4 фиксированных значения фазы 0, p/2, p и 3p/2. Требует в два раза более узкую полосу, чем PSK, и по этой причине весьма популярна.

    TCM

    (Trellis Coded Modulation) - метод предполагает использование избыточности, каждый бод несет дополнительный бит, который позволяет более точно восстановить информационную битовую последовательность. При кодировании сигнала используется метод QAM. Метод реализован в современных высокоскоростных модемах и позволяет снизить требования к отношению сигнал/шум на 4-5 дБ.

    В QAM-модуляции используется 8/16 комбинаций амплитуда-фаза (см. рис. 2.2). Понятно, что такой тип модуляции более уязвим для шумов.

    Рис. 2.2. QAM-модуляция с 3 битами на бод (слева) и 4 битами на бод (справа)

    Previous: 1 Введение (общие принципы построения сетей)    UP: 1 Введение (общие принципы построения сетей)
    Down: 2.4 Методы преобразования и передачи звуковых сигналов    Next: 2.1 Передача сигналов по линиям связи


    previous up down next index index
    Previous: 3.1 Кабельные каналы связи    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.3 Беспроводные (радио) каналы и сети

    3.2 Оптоволоконные каналы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    А.Г.Белл в 1880 году запатентовал фотофон - прибор для передачи голоса посредством светового сигнала с селеновым фотодетектором. Первые коммерческие телефонные системы были созданы лишь в 1977 году и работали со скоростью 44,7 Мбит/с. Одномодовые волоконные кабели начали производиться в 1983 году. В 1990 году Линн Моллинер (Bellcore) продемонстрировал передачу данных со скоростью 2,5Гбит/c на расстояние 7500 км (без промежуточных усилителей сигнала) В 1990 году в США суммарная протяженность оптических волокон составляла около 9000000 км. В 2000 году обшая длина оптоволокон только в США превысила 30 миллионов километров. Оптоволоконные линии связи работают в частотном диапазоне 1013 - 1016Гц, что на 6 порядков больше, чем в случае радиочастотных каналов (это обеспечивает пропускную способность 50000 Гбит/c). Но земная атмосфера является плохой средой для распространения света. По этой причине только разработка кремниевых волокон с низким коэффициентом поглощения в инфракрасном диапазоне (< 0,2 дБ/км) сделало возможным широкое распространение оптических каналов связи. Укладывается ~1000км оптоволоконного кабеля в день. В настоящее время каналы обычно имеют пропускную способность ~1Гбит/c и это связано с ограниченным быстродействием оборудования, преобразующего оптический сигнал в электрический и обратно. В ближайшие годы следует ожидать увеличения быстродействия таких устройств в 100-1000 раз. Учитывая, что

    df = (cdl)/l 2, где с - скорость света, f - частота, а l - длина волны.

    Для наиболее популярного диапазона l = 1,3m и dl = 0,17m мы имеем df = ~30ТГц.

    В 2002 году компанией Zonu разработан фототрансивер (GBIC) на 1,25Гбит/c для передачи и приема данных по одному и тому же волокну при длине волны 1310 нм. Для одномодового волокна расстояние передачи может составлять до 10 км. При длине волны 1550 нм достижимо расстояние передачи в 40 км. Разрабатывается вариант для скоростей передачи 2,5Гбит/c

    Оптоволоконное соединение гарантирует минимум шумов и высокую безопасность (практически почти невозможно сделать отвод). Пластиковые волокна применимы при длинах соединений не более 100 метров и при ограниченном быстродействии (<50 МГц). Вероятность ошибки при передаче по оптическому волокну составляет <10-10, что во многих случаях делает ненужным контроль целостности сообщений.

    При построении сетей используются многожильные кабели (рис. 3.2.1; существуют и другие разновидности кабеля: например, двух- или четырехжильные, а также плоские). В верхней части рисунка [a] изображено отдельное оптоволокно, а в нижней [Б] сечение восьмижильного оптического кабеля. Свет (длина волны l ~ 1350 или 1500 нм) вводится в оптоволокно (диаметром d<100m) с помощью светоизлучающего диода или полупроводникового лазера. Центральное волокно покрывается слоем (клэдинг, 1А), коэффициент преломления которого меньше чем у центрального ядра (стрелками условно показан ход лучей света в волокне). Для обеспечения механической прочности извне волокно покрывается полимерным слоем (2А). Кабель может содержать много волокон, например 8 (1Б). В центре кабеля помещается стальной трос (3Б), который используется при прокладке кабеля. С внешней стороны кабель защищается (от крыс!) стальной оплеткой (2Б) и герметизируется эластичным полимерным покрытием.

    Рис. 3.2.1. Сечение оптоволоконного кабеля

    Существует несколько типов оптических волокон, обладающих различными свойствами. Они отличаются друг от друга зависимостью коэффициента преломления от радиуса центрального волокна. На рис. 3.2.2 показаны три разновидности волокна (А, Б и В). Буквами А и Б помечен мультимодовый вид волокон. Тип Б имеет меньшую дисперсию времени распространения и по этой причине вносит меньшие искажения формы сигнала. Установлено, что, придавая световым импульсам определенную форму (обратный гиперболический косинус), дисперсионные эффекты можно полностью исключить. При этом появляется возможность передавать импульсы на расстояние в тысячи километров без искажения их формы. Такие импульсы называются солитонами. При современных же технологиях необходимо использовать повторители через каждые 30 км (против 5 км для медных проводов). По сравнению с медными проводами оптоволоконные кабели несравненно легче. Так одна тысяча скрученных пар при длине 1 км весит 8 тонн, а два волокна той же длины, обладающие большей пропускной способностью, имеют вес 100кг. Это обстоятельство открывает возможность укладки оптических кабелей вдоль высоковольтных линий связи, подвешивая или обвивая их вокруг проводников.

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

    Буквой В помечен одномодовый вид волокна (понятие мода связано с характером распространения электромагнитных волн). Мода представляет собой одно из возможных решений уравнения Максвелла. В упрощенном виде можно считать, что мода - это одна из возможных траекторий, по которой может распространяться свет в волокне. Чем больше мод, тем больше дисперсионное искажение сформы сигнала. Одномодовое волокно позволяет получить полосу пропускания в диапазоне 50-100 ГГц-км. Типовое значение модовой дисперсии лежит в пределах от 15 до 30 нсек/км. Эта разновидность волокна воспринимает меньшую долю света на входе, за то обеспечивает минимальное искажение сигнала и минимальные потери амплитуды. Следует также иметь в виду, что оборудование для работы с одномодовым волокном значительно дороже. Центральная часть одномодового волокна имеет диаметр 3-10 m, а диаметр клэдинга составляет 30-125 m. Число мод, допускаемых волокном, в известной мере определяет его информационную емкость. Модовая дисперсия приводит к расплыванию импульсов и их наезжанию друг на друга. Дисперсия зависит от диаметра центральной части волокна и длины волны света. Число мод n равно для волокна типа А:

    ,

    где d - диаметр центральной части (ядра), a - численная апертура волокна, а l - длина волны. Волокно с диаметром центральной части волокна 50 m поддерживает 1000 мод. Для волокна типа Б (рис. 3.2.2) значение n в два раза меньше. Численная апертура А равна , где n1 (~1,48) и n2 (~1,46), соответственно, коэффициенты преломления ядра и клэдинга. Величина А определяет ширину входного конуса волокна q (телесный угол захвата входного излучения) q= arcsinA (~3,370).

    Очевидно, что чем больше длина волны, тем меньше число мод и меньше искажения сигнала. Это, в частности, является причиной работы в длинноволновом инфракрасном диапазоне. Но даже для одной и той же моды различные длины волн распространяются по волокну с разной скоростью. Волокно со сглаженным профилем показателя преломления имеет дисперсию 1 нсек/км и меньше. Это, в частности, связано с тем, что свет в перефирийных областях волокна с большей длиной траектории движется быстрее (там ведь меньше коэффициент преломления). Одномодовый режим реализуется тогда, когда длина волны вета становится сравнимой с диаметром ядра волокна. Длина волны, при которой волокно становится одномодовым, называется пороговой. Волокно с диаметром 50 микрон может поддерживать до 1000 мод. В отличие от многомодового волокна, в одномодовом - излучение присутствует не только внутри ядра. По этой причине повышаются требования к оптическим свойствам клэдинга. Для многомодового волокна требования к прозрачности клэдинга весьма умеренны. Затуханием обычно называется ослабление сигнала по мере его движения по волокну. Оно измеряется в децибелах на километр и варьируется от 300 дБ/км для пластиковых волокон до 0,21 дБ/км - для одномодовых волокон. Полоса пропускания волокна определяется дисперсией. Приближенно полосу пропускания одномодового волокна можно оценить согласно формуле.

    BW = 0,187/(Disp*SW*L),

    где Disp - дисперсия на рабочей длине волны в сек на нм и на км;
    SW - ширина спектра источника в нм;M
    L - длина волокна в км;

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

    Потеридиам = 10log10(Диаметрволокна/Диаметристочника)2

    Потерь нет, когда волокно имеет диаметр больше диаметра источника света. Если числовая апертура источника больше апертуры волокна, то потери света составят:

    Потеридиам = 10log10(Aволокна/Aисточника)2

    Помимо дисперсии быстродействие оптического канала ограничивается шумами. Шумы имеют две составляющие: дробовой и тепловой шум. Дробовой шум определяется соотношением:

    isn 2= 2eiB,

    где е - заряд электрона, i - средний ток, протекающий через приемник, и В - ширина полосы пропускания приемника. Типовое значение дробового шума составляет 25 нА при температуре 25 градусов Цельсия. Тепловой шум характеризуется соотношением:

    isn 2=(4kTB)/RL

    где k - постоянная Больцмана, Т - температура по шкале Кельвина, В - ширина полосы пропускания приемника, RL - сопротивление нагрузки. При полосе в 10 МГц и температуре 298 0К эта составляющая шума равна 18 нА. Одной из составляющих теплового шума является темновой ток, который возрастает на 10% при росте температуры на 1 градус.

    Чувствительность приемника задается квантовой эффективностью, которая характеризует отношение числа первичных электронно-дырочных пар к числу падающих на детектор фотонов. Этот параметр часто выражается в процентах (реже в амперах на люмен). Так, если на каждые 100 фотонов приходится 60 пар электрон-дырка, то квантовая эффективность равна 60%. Чувствительность фотодетектора R может быть вычислена на основе квантовой чувствительности. R= (nel)/hc, где е - заряд электрона, h - постоянная Планка, с - скорость света l - длина волны, а n - квантовая чувствительность.

    Источники излучения инжектируемого в волокно имеют конечную полосу частот. Так светоизлучающие диоды излучают свет с шириной полосы 35 нм, а лазеры 2-3 нм (лазеры имеют, кроме того, более узкую диаграмму направленности, чем диоды). Характеристики светодиодов и инжекционных лазерных диодов приведены в таблице 3.2.1.

    Таблица 3.2.1. Характеристики светодиодов и инжекционных лазерных диодов

    Параметры

    Светодиод (led)

    Инжекционные лазерные диоды

    Выходная мощность

    0,5 - 11,5 мВт

    3 - 10 мВт

    Время нарастания

    1 - 20 нс

    1 - 2 нс

    Диапазон тока смещения

    5- - 150 мА

    100 - 500 мА

    Время нарастания фотодиода ограничивает быстродействие системы. Не малую роль играет и уровень шумов на входе приемника. При этом световой импульс должен нести достаточно энергии (заметно больше уровня шума), чтобы обеспечить низкий уровень ошибок. В таблице 3.2.2 приведены характеристики оптических приемников.

    Таблица 3.2.2. Характеристики оптических приемников

    Параметры

    pin

    Лавинный фотодиод

    Фототранзистор

    Фотоприемник Дарлингтона

    Чувствительность

    0,5 мкa/мкВт

    15 мкa/мкВт

    35 мкa/мкВт

    180 мкa/мкВт

    Время нарастания

    1 нс

    2 нс

    2 мкс

    40 мкс

    Напряжение смещения

    10 В

    100 В

    10 В

    10 В

    Поглощение света в волокне происходит по нескольким причинам. Поглощение в собственно стекле волокна падает с частотой, в то время как потери из-за рассеяния на дефектах стекла (релеевское рассеяние) с увеличением частоты растет. При сгибании волокна поглощение увеличивается. По этой причине следует избегать малых радиусов изгиба (кроме всего прочего это может привести и к обрыву). В результате потери света в волокне обычно лежит в диапазоне (2-5) дБ/км для длин волн 0,8 - 1,8 m. Зависимость поглощения света в волокне от длины волны показана на рис. 3.2.3. Используемые диапазоны отмечены на рисунке зеленым цветом. Все эти диапазоны имеют ширину 25000-30000 ГГц.

    Рис. 3.2.3. Зависимость поглощения света в волокне от длины волны

    Из рисунка видно, что минимумы поглощения приходятся на 1300 и ~1500 нм, что и используется для целей телекоммуникаций. При длине волны 1300 нм дисперсия скоростей распространения различных длин волн минимальна. Диапазон ~850 нм характеризуется высоким поглащением, но он привлекателен тем, что как лазеры, так и электроника могут быть изготовлены из одного материала (арсенида галлия). Используемые оптические диапазоны выделены зеленым цветом. Зависимость дисперсии от длины волны показана на рис. 3.2.4.

    Рис. 3.2.4. Зависимость дисперсии от длины волны

    Из рисунка видно, что в области ниже 1300 нм более длинные волны движутся быстрее коротких. Для длин волн >1300нм имеет место обратная ситуация - более длинные волны движутся медленнее коротких. Для одномодовых волокон определяющий вклад в искажения вносится дисперсией скоростей распространения, для многомодовых основной вклад вносит модовая дисперсия. Зависимость полосы пропускания волокна от его длины приведена на рис. 3.2.5.

    Рис. 3.2.5. Зависимость полосы пропускания волокна от его длины

    Типовые характеристики оптических волокон приведены в таблице 3.2.3. (См. также Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. "ЛОРИ, Москва, 1998 а также Дж. Гауэр, Оптические системы связи. Москва, "Радио и связь", 1989)

    Таблица 3.2.3. Типовые характеристики оптических волокон

    Тип волокна

    Диаметр ядра
    [мкм]

    Диаметр клэдинга
    [мкм]

    А

    Затухание
    [дБ/км]

    Полоса пропускания [МГц/км]

    Длина волны

    850

    1300

    1550

    Одномодовое

    9,3
    8,1

    125
    125

    0,13
    0,17

    0,4
    0,5

    0,3
    0,25

    5000 для 850 нм

    Со сглаженным индексом

    50
    62,5
    85

    125
    125
    125

    0,2
    0,275
    0,26

    2,4
    3,0
    2,8

    0,6
    0,7
    0,7

    0,5
    0,3
    0,4

    600 для 850 нм;
    1500 для 1300 нм

    Ступенчатый индекс

    200

    380

    0,27

    6,0

    6 при 850 нм

    Одним из критических мест волоконных систем являются сростки волокон и разъемы. Учитывая диаметр центральной части волокна, нетрудно предположить, к каким последствиям приведет смещение осей стыкуемых волокон даже на несколько микрон (особенно в одномодовом варианте, где диаметр центрального ядра менее 10 микрон) или деформация формы сечения волокон.

    Соединители для оптических волокон имеют обычно конструкцию, показанную на рис. 3.2.6, и изготовляются из керамики. Потеря света в соединителе составляет 10-20%. Для сравнения сварка волокон приводит к потерям не более 1-2%. Существует также техника механического сращивания волокон, которая характеризуется потерями около 10% (splice). Оптические аттенюаторы для оптимального согласования динамического диапазона оптического сигнала и интервала чувствительности входного устройства представляют собой тонкие металлические шайбы, которые увеличивают зазор между волокном кабеля и приемником.

    Рис. 3.2.6. Схема оптического разъема

    С использованием оптических волокон можно создавать не только кольцевые структуры. Возможно построение фрагмента сети, по характеру связей эквивалентного кабельному сегменту или хабу. Схема такого фрагмента сети представлена на рис. 3.2.7 (пассивный хаб-концентратор). Базовым элементом этой субсети является прозрачный цилиндр, на один из торцов которого подключаются выходные волокна всех передатчиков интерфейсов устройств, составляющих субсеть. Сигнал с другого торца через волокна поступает на вход фото приемников интерфейсов. Таким образом, сигнал, переданный одним из интерфейсов, поступает на вход всех остальных интерфейсов, подключенных к этой субсети. При этом потери света составляют 2С + S + 10*log(N), где С - потери в разъеме, S - потери в пассивном разветвителе, а N - число оптических каналов (N может достигать 64). Современные микросхемы приемо-передатчиков (корпус DIP) имеют встроенные разъемы для оптического кабеля (62,5/125мкм или 10/125 мкм). Некоторые из них (например, ODL 200 AT&T) способны осуществлять переключение на обходной оптический путь (bypass) при отключении питания.

    Рис. 3.2.7. Схема пассивного оптоволоконного хаба

    В последнее время заметного удешевления оптических каналов удалось достичь за счет мультиплексирования с делением по длине волны. За счет этой техники удалось в 16-160 раз увеличить широколосность канала из расчета на одно волокно. Схема мультиплесирования показана на рис. 3.2.8. На входе канала сигналы с помощью призмы объединяются в одно общее волокно. На выходе с помощью аналогичной призмы эти сигналы разделяются. Число волокон на входе и выходе может достигать 32 и более (вместо призм в последнее время используются миниатюрные зеркала, где применяется 2D-развертка (или 3D)по длине волны). Разработка технологии получения особо чистого материала волокон позволила раширить полосу пропускания одномодового волокна до 100 нм (для волокон с l =1550нм). Полоса одного канала может лежать в диапазоне от 2 до 0,2 нм. Эта технология в самое ближайшее время расширит скорость передачи данных по одному волокну с 1 до 10 Тбит/с.

    Рис. 3.2.8. Мультиплексирование с делением по длине волны в оптическом волокне

    Previous: 3.1 Кабельные каналы связи    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.3 Беспроводные (радио) каналы и сети


    previous up down next index index
    Previous: 3.2 Оптоволоконные каналы    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.4 Протокол SLIP

    3.3 Беспроводные (радио) каналы и сети
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Применение электромагнитных волн для телекоммуникаций имеет уже столетнюю историю. Спектр используемых волн делится на ряд диапазонов, приведенных в таблице 3.3.1.

    Таблица 3.3.1.

    Номер

    Название диапазона

    Частота

    Длина волны

    1

    Высокочастотный

    3 - 30 МГц

    100 - 10 м

    2

    VHF

    50 - 100 Мгц

    6 - 3 м

    3

    УВЧ (UHF)

    400-1000 МГц

    75-30 см

    4

    Микроволновый

    3 109 - 1011 Гц

    10 см - 3 мм

    5

    Миллиметровый

    1011 - 1013Гц

    3 мм - 0,3 мм

    6

    Инфракрасный

    1012 - 6 1014

    0,3 мм - 0,5 m

    Далее следуют диапазоны видимого света, ультрафиолета, рентгеновских и гамма-лучей. Диапазоны часто, используемые различными каналами связи показаны на рис. 3.3.1.

    Рис. 3.3.1. Диапазоны частот различных телекоммуникационных каналов.

    Если не используется направленная антенна и на пути нет препятствий, радиоволны распространяются по всем направлениям равномерно и сигнал падает пропорционально квадрату расстояния между передатчиком и приемником (удвоение расстояния приводит к потерям 6дБ). Радио каналы для целей передачи информации используют частотные диапазоны 902-928 МГц (расстояния до 10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до 50 км, до 8 Мбит/с). Они используются там, где не существует кабельных или оптоволоконных каналов или их создание по каким-то причинам невозможно или слишком дорого. Более низкие частоты (например, 300 МГц) мало привлекательны из-за ограничений пропускной способности, а большие частоты (>30 ГГц) работоспособны для расстояний не более или порядка 5км из-за поглощения радиоволн в атмосфере. При использовании диапазонов 4, 5 и 6 следует иметь в виду, что любые препятствия на пути волн приведут к их практически полному поглощению. Для этих диапазонов заметное влияние оказывает и поглощение в атмосфере. Зависимость поглощения от длины волны радиоволн показана на рис. 3.3.1а.

    Рис. 3.3.1а. Зависимость поглощающей способности земной атмосферы от длины волны

    Из рисунка видно, что заметную роль в поглощении радиоволн играет вода. По этой причине сильный дождь, град или снег могут привести к прерыванию связи. Поглощение в атмосфере ограничивает использование частот более 30 ГГц. Атмосферные шумы, связанные в основном с грозовыми разрядами, доминируют при низких частотах вплоть до 2 МГц. Галактический шум, приходящий из-за пределов солнечной системы дает существенный вклад вплоть до 200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от частоты показана на рис. 3.3.2.

    Рис. 3.3.2. Зависимость поглощения радиоволн в тумане и дожде от частоты

    Мощность передатчика обычно лежит в диапазоне 50 мВт - 2 Вт. Модемы, как правило, используют шумоподобный метод передачи SST (spread spectrum transmission). Для устройств на частоты 2.4 ГГц и выше, как правило, используются направленные антенны и необходима прямая видимость между приемником и передатчиком. Такие каналы чаще работают по схеме точка-точка, но возможна реализация и многоточечного соединения. На аппаратном уровне здесь могут использоваться радиорелейное оборудование радиомодемы или радио-бриджи. Схема этих устройств имеет много общего. Отличаются они лишь сетевым интерфейсом (см. рис. 3.3.3). Антенна служит как для приема, так и для передачи. Трансивер (приемопередатчик) может соединяться с антенной через специальные усилители. Между трансивером и модемом может включаться преобразователь частот. Модемы подключаются к локальной сети через последовательные интерфейсы типа RS-232 или v.35 (RS-249), для многих из них такие интерфейсы являются встроенными. Отечественное радиорелейное оборудование имеет в качестве выходного интерфейс типа G.703 и по этой причине нуждается в адаптере. Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля от модема до трансивера лежит в пределах 30-70м, а соединительный кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер располагается обычно рядом с антенной.

    Рис. 3.3.3. Схема оборудования радиоканала передачи данных

    Схемы соединения радиомодемов и традиционных модемов совершенно идентичны (см. рис. 3.3.4).

    Рис. 3.3.4. Схема подключения радио-модемов

    Кроме уже указанных примеров перспективным полем применения радиомодемов могут стать "подвижные ЭВМ". Сюда следует отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и все случаи, когда ЭВМ по характеру своего применения подвижна, например, медицинская диагностика на выезде, оперативная диагностика сложного электронного оборудования, когда необходима связь с базовым отделением фирмы, геологические или геофизические исследования и т.д. Радиомодемы позволяют сформировать сеть быстрее (если не считать времени на аттестацию оборудования, получение разрешения на выбранную частоту и лицензии на использование данного направления канала). В этом случае могут стать доступными точки, лишенные телефонной связи (что весьма привлекательно для условий России). Подключение объектов к центральному узлу осуществляется по звездообразной схеме. Заметное влияние на конфигурацию сети оказывает ожидаемое распределение потоков информации. Если все объекты, подключенные к узлу, примерно эквивалентны, а ожидаемые информационные потоки не велики, можно в центральном узле обойтись простым маршрутизатором, имеющим достаточное число последовательных интерфейсов.

    Применение радио-бриджей особенно выигрышно для организаций, имеющих здания, отстоящие друг от друга на несколько километров. Возможно использование этих средств связи и для подключения к сервис-провайдеру, когда нужны информационные потоки до 2 Мбит/с (например, для проведения видео конференций). Если расстояния не велики (<5км), можно воспользоваться всенаправленной антенной (см. рис. 3.3.5).

    Рис. 3.3.5. Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны

    Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены радио-бриджами. Такая схема подключения эквивалентна с одной стороны кабельному сегменту ethernet, так как в любой момент времени возможен обмен лишь между двумя объектами; с другой стороны радио-бриджи А, Б, В и Г логически образуют много портовый бридж (или переключатель), что исключает загрузку локальных сетей объектов "чужими" пакетами. Модификации таких схем связи позволяют строить телекоммуникационные системы по схеме сотовых телефонных сетей.

    При построении каналов на основе радиорелейных систем или радио-бриджей следует учитывать возможность их взаимного влияния (см. рис. 3.3.6). Проектируя такие каналы в городе и используя направленные параболические антенны, нужно учитывать возможные помехи от зданий и профиля местности. Направленная антенна с площадью А обеспечивает усиление сигнала:

    , где l длина волны несущей.

    Угол излучения q такой антенны с радиусом R равен 0,61 l/R. Отсюда видно, что чем больше радиус, тем больше усиления и уже угол излучения и чувствительности.

    Предельные расстояния для радио каналов приводятся поставщиками в предположении, что в пределах первой зоны Френеля каких-либо физических помех нет. При звездообразной схеме каналов (как на рис. 3.6.) нужно по возможности выполнить требования на минимальное расстояние между принимающими антеннами d (оно должно быть больше определенного значения, зависящего от апертуры антенны и расстояния между передатчиком и приемником).

    Рис. 3.3.6.

    Это расстояние определяется расходимостью (a) радиолуча и используемой длиной волны. Если это требование не выполнимо, следует в смежных каналах использовать разные длины волн. Диаграмма излучения направленной антенны показана на рис. 3.3.7 (стрелкой отмечено основное направление излучения). Эту диаграмму следует учитывать при выборе места установки антенны, особенно при использовании большой мощности излучения. Иначе один из лепестков излучения может прийтись на места постоянного пребывания людей (например, жилье). Учитывая эти обстоятельства, проектирование такого рода каналов целесообразно поручить профессионалам.

    Рис. 3.3.7. Диаграмма излучения параболической антенны

    Стоимость антенного комплекса обычно пропорциональна кубу диаметра антенны. Стандартная антенна intelsat имеет диаметр 30 м и угол излучения 0,01 0.

    Спутниковые каналы используют диапазоны перечисленные в таблице 3.3.2.

    Таблица 3.3.2. Частотные диапазоны, используемые для спутниковых телекоммуникаций

    Диапазон

    Канал снижения (downlink)[ГГц]

    Канал подъема (uplink)[ГГц]

    Источники помех

    С

    3,7-4,2

    5,925-6,425

    Наземные помехи

    ku

    11,7-12,2

    14,0-14,5

    Дождь

    ka

    17,7-21,7

    27,5-30,5

    Дождь

    Из таблицы видно, что передача ведется на более высокой частоте, чем прием сигнала со спутника. Обычный спутник обладает 12-20 транспондерами (приемопередатчиками), каждый из которых имеет полосу 36-50МГц, что позволяет сформировать поток данных 50 Мбит/с. Такая пропускная способность достаточна для получения 1600 высококачественных телефонных каналов (32кбит/c). Современные спутники используют узкоапертурную технологию передачи vsat (very small aperure terminals). Такие терминалы используют антенны диаметром 1 метр и выходную мощность около 1 Вт. При этом канал к спутнику имеет пропускную способность 19,2 кбит/с, а со спутника более 512 кбит/c. Непосредственно такие терминалы не могут работать друг с другом, разумеется через телекоммуникационный спутник. Для решения этой проблемы используются промежуточные наземные антенны с большим усилением, что, правда увеличивает задержку. Схема связей в технологии VSAT.

    Рис. 3.3.8. Схема спутниковой связи VSAT

    Терминальные антены vsat имеют диаметр 1-1,5 м и излучаемую мощность 1-4 Вт, обеспечивая широкополосность до 64 кбит/с. Такие небольшие антенны не позволяют таким терминалам общаться непосредственно. На рис. 3.3.8. станции А и Б не могут непосредственно друг с другом. Для передачи данных используется промежуточная станция с большой антенной и мощностью (на рис. антенна В). Для создания постоянных каналов телекоммуникаций служат геостационарные спутники, висящие над экватором на высоте около 36000 км.

    Теоретически три таких спутника могли бы обеспечить связью практически всю обитаемую поверхность земли (см. рис. 3.3.9.). Спутники, работающие на одной и той же частоте должны быть разнесены по углу на 2o. Это означет что число таких спутников не может быть больше 180. В противном случае они должны работать в разных частотных диапазонах. При работе в ku-диапазоне угловое расстояние между спутниками можно сократить до 1o. Влияние дождя можно минимизировать, используя далеко отстоящие наземные станции (размеры урагана конечны!).

    Рис. 3.3.9.

    Реально геостационарная орбита переполнена спутниками различного назначения и национальной принадлежности. Обычно спутники помечаются географической долготой мест, над которым они висят. На практике геостационарный спутник не стоит на месте, а выполняет движение по траектории, имеющей вид цифры 8. Угловой размер этой восьмерки должен укладываться в рабочую апертуру антенны, в противном случае антенна должна иметь сервопривод, обеспечивающий автоматическое слежение за спутником. Из-за энергетических проблем телекоммуникационный спутник не может обеспечить высокого уровня сигнала. По этой причине наземная антенна должна иметь большой диаметр, а приемное оборудование низкий уровень шума. Это особенно важно для северных областей, для которых угловое положение спутника над горизонтом невысоко (это особенно существенно для широт более 700), а сигнал проходит довольно толстый слой атмосферы и заметно ослабляется. Спутниковые каналы могут быть рентабельны для областей, отстоящих друг от друга более чем на 400-500 км (при условии что других средств не существует). Правильный выбор спутника (его долготы) может заметно снизить стоимость канала.

    Число позиций для размещения геостационарных спутников ограничено. В последнее время для телекоммуникаций планируется применение так называемых низколетящих спутников (<1000 км; период обращения ~1 час). Эти спутники движутся по эллиптическим орбитам и каждый из них по отдельности не может гарантировать стационарный канал, но в совокупности эта система обеспечивает весь спектр услуг (каждый из спутников работает в режиме "запомнить и передать"). Из-за малой высоты полета наземные станции в этом случае могут иметь небольшие антенны и малую стоимость. Смотри также S.Bhatti.

    Типичный спутник имеет 12-20 транспондеров, каждый из которых имеет полосу 36-50 МГц. Один транспондер может обеспечить информационный поток в 50 Мбит/с или 800 64-килобитных каналов цифровой телефонии. Два транспондера могут использовать разную поляризацию сигнала и по этой причине работать на одной и той жк частоте. Каждый телекоммуникационный спутник снабжен несколькими антеннами. Низходящий луч может быть сфокусирован на достаточно ограниченную область на земле (с диаметром несколько сот км). Что также упрощает осуществление двунаправленного обмена.

    Существует несколько способов работы совокупности наземных терминалов со спутником. При этом может использоваться мультиплексирование по частоте (FDM), по времени (TDM), CDMA (Code Division Multiple Access), ALOHA или метод запросов.

    Схема запросов предполагает, что наземные станции образуют логическое кольцо, вдоль которого двигается маркер. Наземная станция может начать передачу на спутник, лишь получив этот маркер.

    Простая система ALOHA (разработана группой Нормана Абрамсона из Гавайского университета в 70-х годах) позволяет каждой станции начинать передачу тогда, когда она этого захочет. Такая схема с неизбежностью приводит к столкновениям. Связано это отчасти с тем, что передающая сторона узнает о столкновении лишь спустя ~270 мсек. После столкновения станция ожидает некоторое псевдослучайное время и совершает повторную попытку передачи еще раз. Такой алгоритм доступа обеспечивает эффективность использования канала на уровне около 18%, что совершенно недопустимо для таких дорогостоящих каналов, как спутниковые. По этой причине чаще используется доменная версия системы ALOHA, которая удваивает эффективность. Одна наземная станция (эталонная) периодически посылает специальный сигнал, который используется всеми участниками для синхронизации. Если длина временного домена равна DT, тогда домен с номером k начинается в момент времени kDT по отношению к упомянутому выше сигналу. Так как часы разных станций работают немного по разному, необходима периодическая ресинхронизация. Другой проблемой является разброс времени распространения сигнала для разных станций.

    Метод мультиплекcирования по частоте (FDM) является старейшим и наиболее часто используемым. Типичный транспондер с полосой 36 Мбит/с может использован для получения 500 64кбит/с ИКМ-каналов, каждый из которых работает со своей уникальной частотой, чтобы исключить интерференцию с другими. Соседние каналы должны отстоять на достаточном расстоянии друг от друга. Кроме того, должен контролироваться уровень передаваемого сигнала, так как при слишком большой выходной мощности могут возникнуть интерференционные помехо в соседнем канале. Если число станций невелико и постоянно, частотные каналы могут быть распределены стационарно. Но при переменном числе терминалов или при заметной флуктуации загрузки приходится переходить на динамическое распределение ресурсов. Одним из механизмов такого распределение имеет название SPADE, он использовался в первых версиях систем связи на базе INTELSAT. Каждый транспондер системы SPADE содержит 794 симплексных ИКМ-каналов по 64-кбит/c и один сигнальный канал с полосой 128 кбит/c. ИКМ-каналы используются попарно для обеспечения полнодуплексной связи. При этом восходящий и ниcходящий каналы имеют полосу по 50 Мбит/с. Сигнальный канал делится на 50 доменов по 1 мсек (128 бит). Каждый домен принадлежит одной из наземной станции, число которых не превышает 50. Когда станция готова к передаче, она произвольным образом выбирает неиспользуемый канал и записывает номер этого канала в очередной свой 128 битный домен. Если один и тот же канал попытаются занять две или более станции происходит столкновение и они вынуждены будут повторить попытку позднее.

    Метод мультиплекирования по времени сходен с FDM и довольно широко применяется на практике. Здесь также необходима синхронизация для доменов. Это делается как и в доменной системе ALOHA c помощью эталонной станции. Присвоение доменов наземным станциям может выполняться централизовано или децентрализовано. Рассмотрим систему ACTS (Advanced Communication Technology Satellite). Система имеет 4 независимых канала (TDM) по 110 Мбит/c (два восходящих и два ниcходящих). Каждый из каналов структурированы в виде 1-милисекундных кадров, каждый из которых имеет по 1728 временных доменов. Каждый из временных доменов имеет 64-битовое поле данных, что позволяет реализовать голосовой канал с полосой в 64 кбит/c. Управление временными доменами с целью минимизации времени на перемещения вектора излучения спутника предполагает знание географического положения наземных станций. Управление временными доменами осуществляется одной из наземных станций (MCS - Master Control Station). Работа системы ACTS представляет собой трехшаговый процесс. Каждый из шагов занимает 1 мсек. На первом шаге спутник получает кадр и запоминает его в 1728-ячеечном буфере. На втором - бортовая ЭВМ копирует каждую входную запись в выходной буфер (возможно для другой антенны). И, наконец, выходная запись передается наземной станции.

    В исходный момент каждой наземной станции ставится в соответствие один временной домен. Для получения дополнительного домена, например для организации еще одного телефонного канала, станция посылает запрос MCS. Для этих целей выделяется специальный управляющий канал емкостью 13 запросов в сек. Существуют и динамические методы распределения ресурсов в TDM (методы Кроузера [Crowther], Биндера [Binder] и Робертса [Roberts]).

    Метод CDMA (Code Division Multiple Access) не требует синхронизации и является полностью децентрализованным. Как и другие методы он не лишен недостатков. Во-первых, емкость канала CDMA в присутствии шума и отсутствии координации между станциями обычно ниже, чем в случае TDM. Во-вторых, система требует быстродействующего и более дорогого оборудования.

    Previous: 3.2 Оптоволоконные каналы    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.4 Протокол SLIP


    previous up down next index index
    Previous: 3.3 Беспроводные (радио) каналы и сети    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.5 Протокол PPP

    3.4 Протокол SLIP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол SLIP (Serial Line IP, RFC-1055) - это простейший способ инкапсуляции IP-дейтограмм для последовательных каналов связи. Этот протокол стал популярным благодаря возможностям подключения домашних персональных машин к сети Интернет через порт RS-232, который соединен с модемом. IP-дейтограмма в случае SLIP должна завершаться специальным символом 0xC0, называемым конец. Во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Октет 0xDB выполняет в SLIP функцию ESC-символа. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD. Использование протокола SLIP предполагает выполнение ряда условий:

    1. Каждый партнер обмена должен знать IP-адрес своего адресата, так как не существует метода обмена такого рода информацией.
    2. SLIP в отличии от Ethernet не использует контрольных сумм, поэтому обнаружение и коррекция ошибок целиком ложится на программное обеспечение верхних уровней.
    3. Так как кадр SLIP не имеет поля тип, его нельзя использовать, в отличии от кадров Ethernet, для реализации других протоколов методом инкапсуляции.

    Впервые протокол SLIP был применен в 1984 году в 4.2BSD. Скорость передачи информации при использовании протокола SLIP не превышает 19.2кб/с, что обычно достаточно для интерактивного обмена в рамках протоколов telnet или RLOGIN. Максимальный размер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт, что обеспечивает разумный компромисс между значением задержки отклика (~256мс.) и эффективностью использования канала (~98% для CSLIP). При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка в IP-дейтограмме и 20 байт TCP-заголовка. Если мы учтем издержки формирования SLIP-кадра, накладные расходы превосходят 40 байт. Частично этот недостаток устранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной Джекобсоном в 1990 году). В CSLIP заголовок сокращается до 3-5байт (против 40 в SLIP). Эта версия протокола способна поддерживать до 16 TCP-соединений на каждом из концов последовательного канала. Многие современные SLIP-драйверы поддерживают и CSLIP.

    3.4.1. Протоколы RS

    Протоколы RS (RS-232, RS-449, RS-423-А, RS-422-А и RS-485) относятся к семейству рекомендованных протоколов (буква R в названии обозначает recommended). RS-232 обеспечивает дуплексную связь и скорость передачи 19,2 кбит/с при длине связи до 15м. На практике при расстояниях порядка 10 метров можно получить быстродействие канала более 100кбит/с. Здесь обеспечивается связь точка-точка. Логической 1 соответствует уровень сигнала -(5-15)В, а логическому нулю +(5-15)В. В отличии от других упомянутых выше стандартов, которые допускают скорости обмена до 10Мбит/с (при длине линии 15м), данный протокол из-за низкой скорости обмена работает без использования симметричных сигналов на скрученной паре канала связи. Более подробную информацию можно найти, например, в http://ixbt.stack.net/comm/rs_proto.html. Разводка разъема приведена в приложении.

    Стандарт RS-449 представляет собой в действительности семейство, состоящее из 3-х стандартов. Механическая, функциональная и процедурная часть содержится в самом RS-449, а регламентации электрического интерфейса описаны в RS-423-A (подобен RS-232-C) дле схемы с общей землей. Балансная симметричная схема интерфейса представлена в документе на RS-422-A, для для передачи каждого сигнала используется два провода, что позволяет достичь быстродействия 2Мбит/с при длине соединения до 60м. Разводка разъемов представлена в приложении .

    Previous: 3.3 Беспроводные (радио) каналы и сети    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.5 Протокол PPP


    previous up down next index index
    Previous: 3.4 Протокол SLIP    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.6 Протокол G.703

    3.5 Протокол PPP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых. Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:

    • Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.
    • Протокол LCP для установления, конфигурирования и тестирования информационных каналов
    • Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.

    Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр ppp может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).

    Рис. 3.5.1 Формат кадра в протоколе PPP

    Поле адрес всегда содержит байт 0xff (смотри также HDLC). Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол ppp в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.

    Таблица 3.5.1. Стандартизованные DLL-номера протоколов для PPP (поле протокол)

    DLL-код протокола (шестнадцатеричный)

    Наименование протокола

    0001

    Протокол заполнения (padding)

    0003-001F

    Зарезервировано

    0021

    IP-протокол

    0023

    Сетевой уровень OSI

    0025

    Xerox NS IDP

    0027

    Decnet фаза IV

    0029

    Appletalk

    002B

    Novell IPX

    002D

    Компрессированный TCP/IP протокол Ван Джекобсона

    002F

    Не компрессированный TCP/IP протокол Ван Джекобсона

    0031

    PDU мостов

    0033

    Потоковый протокол (ST-II)

    0035

    Banyan Vines

    0039

    Appletalk EDDP

    003B

    Appletalk Smartbuffered

    003D

    Multi-link

    003F

    Кадры Netbios

    0041

    Cisco Systems

    0043

    Ascom Timeplex

    0047

    Удаленная локальная сеть DCA

    0049

    Транспортный протокол для последовательных данных (PPP-SDTP)

    004B

    SNA через 802.2

    004D

    SNA

    004F

    Сжатие заголовков IPv6

    007D

    Зарезервировано (Управл. ESC) [RFC1661]

    00FD

    1-ый вариант компрессии

    0201

    Пакеты отклика 802.1d

    0203

    IBM BPDU базовой маршрутизации

    8021

    Управляющий протокол Интернет (IPCP)

    8023

    Управляющий протокол сетевого уровня OSI

    8025

    Управляющий протокол Xerox NS IDP

    8027

    Управляющий протокол Decnet фаза VI

    8029

    Управляющий протокол Appletalk

    802B

    Управляющий протокол Novell IPX

    8031

    Бридж NCP

    8033

    Потоковый управляющий протокол

    8035

    Управляющий протокол Banyan Vines

    803D

    Многосвязный управляющий протокол

    803F

    Управляющий протокол кадров NetBIOS

    8041

    Управляющий протокол Cisco

    8043

    Ascom Timeplex

    8045

    Управляющий протокол Fujitsu LBLB

    8047

    Управляющий протокол удаленных локальных сетей DCA (RLNCP)

    8049

    Управляющий протокол передачи последовательных данных (PPP-SDCP)

    804B

    Управляющий протокол для передачи sna поверх 802.2

    804D

    Управляющий протокол SNA

    804F

    Управляющий протокол сжатия заголовков IPv6

    80FD

    Управляющий протокол сжатия

    C021

    Канальный управляющий протокол

    C023

    Протокол аутентификации паролей

    C025

    Сообщение о состоянии канала

    C081

    Управляющий протокол для работы с контейнерами

    Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от cxxx до exxx соответствуют управляющим протоколам (например, LCP).

    Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 3.5.2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.

    Рис. 3.5.2. Алгоритм установления соединения PPP

    При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP.

    В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.3.5.2). Формат LCP-пакета показан на рис. 3.5.3.

    Рис. 3.5.3. Формат заголовка LCP-пакета

    Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код, посылается пакет-отклик "отклонение кода". Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются.

    В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВИ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.

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

    Значение кода поля типа

    Назначение опции

    0

    Зарезервировано

    1

    Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят)

    3

    Authentication-Protocol (протокол аутотентификации)

    4

    Quality-Protocol (протокол качества)

    5

    Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи)

    6

    Protocol-Field-Compression

    7

    Address-and-Control-Field-Compression

    Существует три класса LCP-пакетов:

    1. Пакеты конфигурации канала, которые используются при формировании виртуального канала (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject)
    2. .
    3. Пакеты закрытия канала (Terminate-Request и Terminate-Ack).
    4. Пакеты поддержания, которые служат для управления и отладки(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

    Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332). Формат пакета IPCP показан на рис. 3.5.4.

    Рис. 3.5.4. Формат пакета IPCP. Младшие биты слева.

    Поле тип содержит 2, в поле длина заносится число байт в пакете (≥4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип=3, длина=6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес.

    Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код. Значения этих кодов приведены в таблице 3.5.2.

    Таблица 3.5.2 Значения поля код LCP-заголовка

    Код

    Тип пакета

    1

    Запрос конфигурации

    Configure-Request

    2

    Подтверждение конфигурации

    Configure-Ack

    3

    Не подтверждение конфигурации

    Configure-Nak

    4

    Отклонение конфигурации

    Configure-Reject

    5

    Запрос завершения

    Terminate-Request

    6

    Подтверждение завершения

    Terminate-Ack

    7

    Отклонение кода

    Code-Reject

    8*

    Отклонение протокола

    Protocol-Reject

    9*

    Запрос отклика

    Echo-Request

    10*

    Эхо-отклик

    Echo-Reply

    11*

    Запрос отмены

    Discard-Request

    12*

    Идентификация

    13*

    Остающееся время

    14**

    Запрос сброса

    15**

    Отклик на запрос сброса

    *) Только LCP;

    **) Только CCP

    Для случая запроса Discard-Request между полями длина и данные помещается 4-байтовое поле Magic-Number (магическое число).

    Протокол PPP многолик, он способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). Так как я не сталкивался со случаями, когда пропускной способности было вполне достаточно, данную модификацию PPP-протокола следует считать крайне важной. При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. Особую осторожность в этом случае следует соблюдать при использовании заполнителей. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

    Формат MP-пакета представлен на рис. 3.5.5.

    Рис. 3.5.5. Формат MР-пакета

    Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение полу увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал.

    При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:

    • Никакого асинхронного управления кодированием символов
    • Запрет использования магических чисел
    • Запрещено мониторирование качества канала
    • Сжатие полей адреса, протокола и управления
    • Никаких составных кадров
    • Запрет заполнения с самоописанием (Self-Describing-Padding)

    Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на рис. 3.5.6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP. Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).

    Рис. 3.5.6. Пример Multilink-конфигурации

    Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2 (см. сноску в начале раздела).

    Previous: 3.4 Протокол SLIP    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.6 Протокол G.703


    previous up down next index index
    Previous: 3.5 Протокол PPP    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 4 Сети передачи данных. Методы доступа

    3.6 Протокол G.703
    Семенов Ю.А. (ГНЦ ИТЭФ)

    (ITU-T Recommendation G.703.Physical/Electrical Characteristics of Hierarchical Digital Interfaces. 1972 last amended in 1991).

    Интерфейс G.703 (ITU-T Recommendation G.703.Physical/Electrical Characteristics of Hierarchical Digital Interfaces. 1972 last amended in 1991) был разработан в 1972 году и базируется на стандартах G.702, G.704 и I.430 и обслуживает сети с иерархией PDH и SDH. Первоначально он разрабатывался для систем с импульсно-кодовой модуляцией. G.703 может работать на скоростях передачи данных 64 Кбит/с, 1544, 6312, 32064 и 44736 Кбит/с (PDH, американская версия), 2048, 8448, 34368, 139264 Кбит/с (европейская версия). Предусматривается работа и при 155,52 Мбит/с. В качестве физического канала передачи может использоваться скрученная пара (Z=100-120 Ом) или коаксиальный кабель (75 Ом), амплитуда импульса 1-3В.

    При скорости 64 Кбит/с через интерфейс передается три типа сигналов: информационный (64 Кбит/с) и два синхронизирующих тактовых 64 Кбит/с и 8 Кбит/с. Стандарт предусматривает 3 вида взаимодействия терминального оборудования: однонаправленный (codirectional; рис. 3.6.1), разнонаправленный (рис. 3.6.2) и с центральным тактовым генератором (рис. 3.6.3).

    Рис. 3.6.1. Однонаправленная передача информации и тактовых сигналов

    Рис. 3.6.2. Разнонаправленная передача информации и тактового сигнала для 64 Кбит/с

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

    Рис. 3.6.3. Интерфейс с центральным тактовым генератором для 64 кбит/с

    Частота синхронизирующих сигналов может быть меньше скорости передачи данных в 2, 4 и 8 раз. Тип кода зависит от скорости передачи и типа аппаратного интерфейса. Характеристики основных разновидностей интерфейса G.703 приведены в таблице 3.6.1.

    Таблица 3.6.1.

    Скорость [кбит/с]

    64

    1544

    6312

    32064

    44736

    2048

    8448

    34368

    139264

    155520

    Тип кода

    AMI

    AMI
    B8ZS

    B6ZS

    AMI

    B3ZS

    HDB3

    HDB3

    HDB3

    CMI

    CMI

    Амплитуда, В

    1,0

    3,0

    1,0

    1,0

    1,0

    2,37
    3,0

    2,37

    1,0

    ╠0,55

    ╠0,55

    Ширина импульса, нс

    15000

    323,5

    79

    15,6

    11,2

    244

    59,0

    14,55

    3,59

    3,2

    Кодировка относится лишь для случая проводных каналов.

    Previous: 3.5 Протокол PPP    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 4 Сети передачи данных. Методы доступа


    previous up down next index index
    Previous: 2.10 Статистическая теория каналов связи    UP: 2.6 Методы сжатия информации
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.1 Кабельные каналы связи

    3 Каналы передачи данных
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    3 Каналы передачи данных

    1

    1

    3.1 Кабельные каналы связи

    7

    106

    3.2 Оптоволоконные каналы

    10

    8

    3.3 Беспроводные (радио) каналы и сети

    11

    8

    3.4 Протокол SLIP

    2

    20

    3.5 Протокол PPP

    9

    8

    3.6 Протокол G.703

    1

    21

    За последние двадцать лет пропускная способность каналов выросла с 56 кбит/c до 1 Гбит/с. Разработаны технологии, способные работать в случае оптических кабелей со скоростью 50 Тбит/с. Вероятность ошибки при этом сократилась с 10-5 на бит до пренебрежимо низкого уровня. Современный же лимит в несколько Гбит/с связан главным образом с тем, что люди не научились делать быстродействующие преобразователи электрических сигналов в оптические.

    Previous: 2.10 Статистическая теория каналов связи    UP: 2.6 Методы сжатия информации
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.1 Кабельные каналы связи


    previous up down next index index
    Previous: 3 Каналы передачи данных    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа
        Next: 3.2 Оптоволоконные каналы

    3.1 Кабельные каналы связи
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Кабельные каналы для целей телекоммуникаций исторически использовались первыми. Да и сегодня по суммарной длине они превосходят даже спутниковые каналы. Основную долю этих каналов, насчитывающих многие сотни тысяч километров, составляют телефонные медные кабели. Эти кабели содержат десятки или даже сотни скрученных пар проводов. Полоса пропускания таких кабелей обычно составляет 3-3,5 кГц при длине 2-10 км. Эта полоса диктовалась ранее нуждами аналогового голосового обмена в рамках коммутируемой телефонной сети. c учетом возрастающих требованиям к широкополосности каналов скрученные пары проводов пытались заменить коаксиальными кабелями, которые имеют полосу от 100 до 500 МГц (до 1 Гбит/с), и даже полыми волноводами. Именно коаксиальные кабели стали в начале транспортной средой локальных сетей ЭВМ (10base-5 и 10base-2; см. рис. 3.1.1).

    Рис. 3.1.1. 1 - центральный проводник; 2 - изолятор; 3 - проводник-экран; внешний изолятор

    Коаксиальная система проводников из-за своей симметричности вызывает минимальное внешнее электромагнитное излучение. Сигнал распространяется по центральной медной жиле, контур тока замыкается через внешний экранный провод. При заземлении экрана в нескольких точках по нему начинают протекать выравнивающие токи (ведь разные "земли" обычно имеют неравные потенциалы). Такие токи могут стать причиной внешних наводок (иной раз достаточных для выхода из строя интерфейсного оборудования), именно это обстоятельство является причиной требования заземления кабеля локальной сети только в одной точке. Наибольшее распространение получили кабели с волновым сопротивлением 50 ом. Это связано с тем, что эти кабели из-за относительно толстой центральной жилы характеризуются минимальным ослаблением сигнала (волновое сопротивление пропорционально логарифму отношения диаметров внешнего и внутреннего проводников). Но по мере развития технологии скрученные пары смогли вытеснить из этой области коаксиальные кабели. Это произошло, когда полоса пропускания скрученных пар достигла 200-350 МГц при длине 100м (неэкранированные и экранированные скрученные пары категории 5 и 6), а цены на единицу длины сравнялись. Скрученные пары проводников позволяют использовать биполярные приемники, что делает систему менее уязвимой (по сравнению с коаксиальными кабелями) к внешним наводкам. Но основополагающей причиной вытеснения коаксиальных кабелей явилась относительная дешевизна скрученных пар. Скрученные пары бывают одинарными, объединенными в многопарный кабель или оформленными в виде плоского ленточного кабеля. Применение проводов сети переменного тока для локальных сетей и передачи данных допустимо для весьма ограниченных расстояний. В таблице 3.1.1 приведены характеристики каналов, базирующихся на обычном и широкополосном коаксиальном кабелях.

    Таблица 3.1.1

    Стандартный кабель

    Широкополосный

    Максимальная длина канала

    2 км

    10 - 15 км

    Скорость передачи данных

    1 - 50 Мбит/с

    100 - 140 Мбит/с

    Режим передачи

    полудуплекс

    дуплекс

    Ослабление влияния электромагнитных и радиочастотных наводок

    50 дБ

    85 дБ

    Число подключений

    < 50 устройств

    1500 каналов с одним или более устройств на канал

    Доступ к каналу

    CSMA/CD

    FDM/FSK

    На рис. 3.1.2 показана зависимость ослабления кабеля (внешний диаметр 0,95 см) от частоты передаваемого сигнала.

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

    Рис. 3.1.2. Зависимость ослабления сигнала в кабеле от его частоты

    Таблица 3.1.2 Сопротивление кабеля по постоянному току

    Коаксиал

    Ом/сегмент

    Максимальная длина сегмента

    10BASE5

    5

    500 м

    10BASE2

    10

    185 м

    Эти данные взяты из Handbook of LAN Cable Testing. Wavetek Corporation, California

    .

    Скрученная пара

    Ом/100 м

    24 AWG

    18,8

    22 AWG

    11,8


    Таблица 3.1.3. Новые европейские стандарты для скрученных пар (CENELEC)

    Стандарт

    Назначение

    Экран

    Полоса пропускания

    EN 50288-2-1

    Для магистральной прокладки

    +

    < 100 МГц (кат. 5)

    EN 50288-2-2

    Для подключения приборов и коммутации

    +

    < 100 МГц (кат. 5)

    EN 50288-3-1

    Для магистральной прокладки

    -

    < 100 МГц (кат. 5)

    EN 50288-3-2

    Для подключения приборов и коммутации

    -

    < 100 МГц (кат. 5)

    EN 50288-4-1

    Для магистральной прокладки

    +

    < 600 МГц (кат. 7)

    EN 50288-4-2

    Для подключения приборов и коммутации

    +

    < 600 МГц (кат. 7)

    EN 50288-5-1

    Для магистральной прокладки

    +

    < 250 МГц (кат. 6)

    EN 50288-5-2

    Для подключения приборов и коммутации

    +

    < 250 МГц (кат. 6)

    EN 50288-6-1

    Для магистральной прокладки

    -

    < 250 МГц (кат. 6)

    EN 50288-6-2

    Для подключения приборов и коммутации

    -

    < 250 МГц (кат. 6)


    Таблица 3.1.3A. Обзор категорий кабелей со скрученными парами проводов (ISO/IEC 11801 = EN 50173)

    Категория

    Полоса пропускания

    Применения

    3

    до 16 МГц

    Ethernet, Token Ring, телефон

    4

    до 20 МГц

    Ethernet, Token Ring, телефон

    5

    до 100 МГц

    Ethernet, ATM, FE,Token Ring, телефон

    6

    до 200/250 МГц

    GigaEthernet,Ethernet, FE, ATM, Token Ring

    7

    до 600 МГц

    GigaEthernet,Ethernet, FE, ATM, Token Ring


    Таблица 3.1.3A1. Обзор классов соединений согласно требованиям ISO/IEC 11801 (EN 50173)

    Класс

    Применение

    A

    Голос и сетевые приложения до 100 кГц

    B

    Информационные приложения до 1 МГц

    С

    Информационные приложения до 16 МГц

    В

    Информационные приложения до 100 МГц

    E

    Информационные приложения до 200/250 МГц

    F

    Информационные приложения до 600 МГц

    LWL

    Информационные приложения от 10 МГц


    Таблица 3.1.3Б. Новые европейские стандарты на разъемы для скрученных пар (CENELEC)

    Стандарт

    Экран

    Полоса пропускания

    EN 60603-7-2

    -

    < 100 МГц (кат. 5)

    EN 60603-7-3

    +

    < 100 МГц (кат. 5)

    EN 60603-7-4

    -

    < 250 МГц (кат. 6)

    EN 60603-7-5

    +

    < 250 МГц (кат. 6)

    EN 60603-7-7

    +

    < 600 МГц (кат. 7)


    Конкретные зависимости ослабления сигнала от частоты и длины кабеля в децибелах представлены в таблице ниже (LANline Special IV/2002 p/26).

    Частота
    [МГц]

    Ослабление для кабеля категории 5 [дБ]

    Ослабление для кабеля категории 6 [дБ]

    Кабель 2 м

    Кабель 5 м

    Кабель 10 м

    Кабель 2 м

    Кабель 5 м

    Кабель 10 м

    1

    72.9

    71.6

    70.1

    65.0

    65.0

    65.0

    4

    61.0

    59.7

    58.4

    65.0

    65.0

    65.0

    16

    49.1

    48.0

    46.9

    62.0

    60.5

    59.0

    62.5

    37.6

    36.8

    36.0

    50.4

    49.2

    48.1

    100.0

    33.7

    33.0

    32.5

    46.4

    45.3

    44.4

    200.0

     

     

     

    43.0

    42.1

    41.4

    250.0

     

     

     

    38.8

    38.1

    37.6


    Данные, приведенные в таблице 3.1.2, могут использоваться для оперативной предварительной оценки качества кабельного сегмента (соответствует стандарту EIA/TIA 568, 1991 год). Частотные характеристики неэкранированных пар категории 6 представлены в табл. 3.1.5`.

    Таблица 3.1.5. Параметры неэкранированных пар категории 6

    Частота, МГц

    Затухание, дБ/100м

    NEXT, дБ

    ACR, дБ/100м

    1

    2,3

    62

    60

    10

    6,9

    47

    41

    100

    23,0

    38

    23

    300

    46,8

    31

    4

    Смотри www.osp.ru/lan/lan_6_96/source/57.htm
    ACR - Attenuation-to-Crosstalk Ratio.
    NEXT - Near End CrossTalk.

    Кабели, изготовленные из скрученных пар категории 5 (волновое сопротивление 100,15 Ом), с полосой 100 Мгц обеспечивают пропускную способность при передаче сигналов ATM 155 Мбит/с. При 4 скрученных парах это позволяет осуществлять передачу до 622 Мбит/с. Кабели категории 6 сертифицируются до частот 300 Мгц, а экранированные и до 600 Мгц (волновое сопротивление 100 Ом). В таблице 3.1.6 приведены данные по затуханию и перекрестным наводкам. Приведены характеристики такого кабеля с 4-мя скрученными экранированными парами (S-FTP).

    Таблица 3.1.6

    Частота, МГц

    Затухание, дБ/100м

    NEXT, дБ

    ACR, дБ/100м

    1

    2,1

    80

    77,9

    10

    6,0

    80

    74

    100

    19,0

    70

    51

    300

    33,0

    70

    37

    600

    50

    60

    10

    NEXT - Near End Cross Talk - перекрестные наводки ближнего конца кабеля.
    ACR - Attenuation-to Crosstalk Ratio.

    Такой кабель пригоден для передачи информации со скоростью более 1 Гбит/с. ACR - Attenuation-to-Crosstalk Ratio (отношение ослабления к относительной величине перекресных наводок).

    Ниже на рис. 3.1.3 показана зависимость наводок на ближнем конце кабеля, содержащего скрученные пары, (NEXT - Near End CrossTalk) от частоты передаваемого сигнала.

    Рис. 3.1.3. Зависимость наводок NEXT от частоты передаваемого сигнала.

    На рис. 3.1.4 представлена зависимость ослабления сигнала в неэкранированной скрученной паре (именно такие кабели наиболее часто используются для локальных сетей) от частоты передаваемого сигнала. Следует иметь в виду, что при частотах в области сотен мегагерц и выше существенный вклад начинает давать поглощение в диэлектрике. Таким образом, даже если проводники изготовить из чистого золота, существенного продвижения по полосе пропускания достичь не удастся.

    Рис. 3.1.4. Зависимость ослабления сигнала от частоты для неэкранированной скрученной пары

    Для неэкранированной скрученной пары 5-ой категории зависимость отношения сигнал-шум от длины с учетом ослабления и наводок NEXT показана на рис. 3.1.5.

    Рис. 3.1.5 Зависимость отношения сигнал/шум от частоты с учетом ослабления и наводок на ближнем конце кабеля

    Характеристики неэкранированных скрученных пар американского стандарта 24 AWG (приведены характеристики кабелей, используемых при построении локальных сетей) для кабелей различной категории собраны в таблице 3.1.7.

    Таблица 3.1.7.

    Категория кабеля

    Сопротивление по постоянному току (L=300м)

    Ослабление [дБ]

    NEXT [дБ]

    III

    28,4

    17 @ 4 МГц
    30 @ 10 МГц
    40 @ 16 МГц

    32 @ 4 МГц
    26 @ 10 МГц
    23 @ 16 МГц

    IV

    28,4

    13 @ 4 МГц
    22 @ 10 МГц
    27 @ 16 МГц
    31 @ 20 МГц

    47 @ 4 МГц
    41 @ 10 МГц
    38 @ 16 МГц
    36 @ 20 МГц

    V

    28,4

    13 @ 4 МГц
    20 @ 10 МГц
    25 @ 16 МГц
    28 @ 20 МГц
    67 @ 100 МГц

    53 @ 4 МГц
    47 @ 10 МГц
    44 @ 16 МГц
    42 @ 20 МГц
    32 @ 100 МГц

    Подводя итоги можно сказать, что при расстояниях до 100 метров с успехом могут использоваться скрученные пары и коаксиальные кабели, обеспечивая полосу пропускания до 150 Мбит/с, при больших расстояниях или более высоких частотах передачи оптоволоконный кабель предпочтительнее. Следует заметить, что работа с кабелями предполагает необходимость доступа к системе канализации (иногда это требует специальных лицензий; а там часто размещаются усилители-повторители). Кабельное хозяйство требует обслуживания. В этом отношении радиоканалы предпочтительнее, ведь случаев коррозии электромагнитных волн не зарегистрировано, да и крысы их не грызут. Справедливости ради отмечу, что здесь серьезную угрозу представляют корыстолюбивые бюрократы, ответственные за выдачу лицензий, а они пострашнее крыс.

    Previous: 3 Каналы передачи данных    UP: 3 Каналы передачи данных
    Down: 4 Сети передачи данных. Методы доступа    Next: 3.2 Оптоволоконные каналы


    previous up down next index index
    Previous: 3.6 Протокол G.703    UP: 3 Каналы передачи данных
    Down: 4.1 Локальные сети (обзор)
        Next: 4.1 Локальные сети (обзор)

    4 Сети передачи данных. Методы доступа
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4 Сети передачи данных. Методы доступа

    14

    13

    4.1 Локальные сети (обзор)

    1

    1

    4.2 Наложенные сети

    1

    6

    4.3 Региональные сети

    1

    5

    4.4 Интернет

    3

    2

    4.5 Процедуры Интернет

    1

    9

    4.6 Электронная торговля в Интернет

    7

    60

    Топология

    Среди топологических схем наиболее популярными являются (см. рис. 4.1):

    1. Шина
    2. Звезда
    3. Кольцо
    4. Многокаскадные и многосвязные сети (См. раздел 4.1.10; 41\ban_4110.doc)

    Рис. 4.1. Примеры сетевых топологий

    К первым трем типам топологии относятся 99% всех локальных сетей. Наиболее популярный тип сети - Ethernet, может строиться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует по одному интерфейсу на машину и не нуждается в каком-либо дополнительном оборудовании. Сети Token Ring и FDDI используют кольцевую топологию (3 на рис. 4.1), где каждый узел должен иметь два сетевых интерфейса. Эта топология удобна для оптоволоконных каналов, где сигнал может передаваться только в одном направлении (но при наличии двух колец, как в FDDI, возможна и двунаправленная передача). Нетрудно видеть, что кольцевая топология строится из последовательности соединений точка-точка.

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

    Вариант А на рис. 4.2 представляет собой схему с полным набором связей (все узлы соединены со всеми), такая схема используется только в случае, когда необходимо обеспечить высокую надежность соединений. Эта версия требует для каждого из узлов наличия n-1 интерфейсов при полном числе узлов n. Вариант Б является примером нерегулярной топологии, а вариант В - иерархический случай связи (древовидная топология).

    Если топологии на рис. 4.1 чаще применимы для локальных сетей, то топологии на рис. 4.2 более типичны для региональных и глобальных сетей. Выбор топологии локальной или региональной сети существенно сказывается на ее стоимости и рабочих характеристиках. При этом важной характеристикой при однородной сети является среднее число шагов между узлами d. , где nd - число ЭВМ на расстоянии d. n - полное число ЭВМ в сети; d - расстояние между ЭВМ. Для сети типа А на рис. 4.2 d=1.

    Рис. 4.2. Различные сетевые топологические схемы

    Современные вычислительные системы используют и другие топологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д. (см. рис. 4.3). Но так как некоторые вычислительные системы (кластеры) базируются на сетевых технологиях, я привожу и такие примеры. В некоторых системах топология может настраиваться на решаемую задачу.

    Рис. 4.3. Некоторые топологии вычислительных систем

    Метод доступа к сети

    Метод доступа определяет метод, который используется при мультиплексировании/демультиплексировании данных в процессе передачи их по сети. Большая часть современных сетей базируется на алгоритме доступа CSMA/CD (carrier sensitive multiple access with collision detection), где все узлы имеют равные возможности доступа к сетевой среде, а при одновременной попытке фиксируется столкновение и сеанс передачи повторяется позднее. Здесь нет возможности приоритетного доступа и по этой причине такие сети плохо приспособлены для задач управления в реальном масштабе времени. Некоторое видоизменение алгоритма CSMA/CD (как это сделано в сетях CAN или в IBM DSDB) позволяют преодолеть эти ограничения. Доступ по схеме CSMA/CD (из-за столкновений) предполагает ограничение на минимальную длину пакета. По существу, метод доступа CSMA/CD предполагает широковещательную передачу пакетов (не путать с широковещательной адресацией). Все рабочие станции логического сетевого сегмента воспринимают эти пакеты хотя бы частично, чтобы прочесть адресную часть. При широковещательной адресации пакеты не только считываются целиком в буфер, но и производится прерывание процессора для обработки факта прихода такого пакета. Логика поведения субъектов в сети с доступом CSMA/CD может варьироваться. Здесь существенную роль играет то, синхронизовано ли время доступа у этих субъектов. В случае Ethernet такой синхронизации нет. В общем случае при наличии синхронизации возможны следующие алгоритмы.

    А.

    1. Если канал свободен, терминал передает пакет с вероятностью 1.
    2. Если канал занят, терминал ждет его освобождения, после чего производится передача.
    Б.
    1. Если канал свободен, терминал передает пакет.
    2. Если канал занят, терминал определяет время следующей попытки передачи. Время этой задержки может задаваться некоторым статистическим распределением.
    В.
    1. Если канал свободен, терминал с вероятностью р передает пакет, а с вероятностью 1-р он откладывает передачу на t секунд (например, на следующий временной домен).
    2. При повторении попытки при свободном канале алгоритм не изменяется.
    3. Если канал занят, терминал ждет пока канал не освободится, после чего действует снова согласно алгоритму пункта 1.

    Алгоритм А на первый взгляд представляется привлекательным, но в нем заложена возможность столкновений с вероятностью 100%. Алгоритмы Б и В более устойчивы в отношении этой проблемы.

    Следующим по популярности после csma/cd является маркерный доступ (Token Ring, Arcnet и FDDI), который более гибок и обеспечивает приоритетную иерархию обслуживания. Массовому его внедрению препятствует сложность и дороговизна. Хотя региональные сети имеют самую разнообразную топологию, практически всегда они строятся на связях точка-точка.

    В таблице 4.1 представлены сводные данные по основным видам локальных сетей, используемых в настоящее время (список не является полным).

    Таблица 4.1. Параметры различных локальных сетей

    Название сети

    Топология

    Быстродействие
    Мбит/с

    Доступ

    Тип кабеля

    NEXT при макс. частоте [дб]

    Размер сети (сегмента)

    Макс. число узлов

    10base5

    шина

    10

    CSMA/CD

    RG-58 (50 Ом)

    500м

    1024

    10base2

    шина

    10

    CSMA/CD

    RG-58 (50 Ом)

    185 м

    90

    10base-t

    шина

    10

    CSMA/CD

    UTP (III; 100 Ом)

    26

    100 м

    -

    10broad36

    шина

    10

    CSMA/CD

    RG-59 (75 Ом)

    3600 м

    1024

    100base-tx

    звезда

    100

    CSMA/CD

    UTP (v; 100 Ом)

    29

    200 м

    -

    100base-fx

    звезда

    100

    CSMA/CD

    оптоволокно

    300 м

    -

    100base-t4

    звезда

    100

    CSMA/CD

    UTP (III; 100 Ом)

    21

    200 м

    -

    1base5 (starlan)

    шина/ звезда

    1

    CSMA/CD

    UTP (II)

    22

    400 м

    1210

    IEEE 802.4

    шина

    1/5/10/20

    маркер

    RG-59 (75 Ом)

    Arcnet

    звезда

    2,5/20

    маркер

    RG-62/utp (93 Ом)

    600/125м

    255

    IEEE 802.5

    звезда

    4/16

    маркер

    STP/UTP (150/120 Ом)

    22/32

    366 м

    260

    Appletalk

    шина/
    звезда

    0,23

    CSMA/CD

    STP/UTP (100 Ом)

    22/32

    300/3000 м

    32 на сегмент

    Ethertalk

    шина/

    звезда

    10

    CSMA/CD

    STP/UTP, коаксиальный кабель

    500/3000 м

    254/1023

    ISN

    звезда

    8,64

    Шина доступа

    stp, оптоволокно

    Не ограничено

    336/1920

    pc lan

    дерево, звезда

    2

    CSMA/CD

    RG-59 (75 Ом), UTP/STP

    32/22

    2000

    72

    Hyperchannel

    шина

    50

    CSMA/CD

    RG-59, оптоволокно

    3500 м

    256

    e-net

    шина

    10

    CSMA/CD

    RG-58 (50 Ом)

    700 м

    100

    G-net

    шина

    1

    CSMA/CD

    RG-58, RG-59

    2000 м

    100

    FDDI

    Двойное кольцо

    100

    маркер

    оптоволокно

    100км

    1000

    PX-net

    шина/ звезда

    1

    маркер

    RG-62 (93 Ом)

    7000 м

    100

    S-net

    шина/ звезда

    1

    Индивидуальный

    STP (100 Ом)

    21

    700 м

    24

    wangnet

    двойное дерево

    10

    CSMA/CD

    RG-59 (75 Ом)

    2800 м

    65000

    Приведенная таблица не может претендовать на полноту. Так сюда не вошла сеть IBM DSDB, разработанная в начале 80-х годов. Полоса пропускания сети составляет 64 Мбит/с. Эта сеть рассчитана на обслуживания процессов реального времени. Сеть имеет топологию шины с приоритетным доступом (длина шины до 500м). Коммуникационная шина логически делится на три магистрали: сигнальная - для реализации приоритетного доступа; лексемная шина для резервирования в буфере места назначения; и, наконец, коммуникационная шина для передачи данных. Каждая из указанных магистралей использует идеологию независимых временных доменов, границы которых синхронизованы для всех трех магистралей. Схема доступа сходна с описанной для сетей CAN (см. раздел 4.1.4).

    1. Узел, пытающийся получить доступ к одной из магистралей, выдает свой физический адрес и приоритет сообщения бит за битом.
    2. При этом узел мониторирует состояние магистрали, проверяя, соответствует ли уровень сигнала тому, что он передает.
    3. Если имеет место совпадение, передается следующий бит и осуществляется процедура пункта 2. При несовпадении узел прерывает передачу, возвращается к пункту 2 и ждет следующего цикла.

    Данная схема доступа исключает столкновения, характерные для CSMA. Именно это преимущество делает сеть применимой для задач реального времени.

    Существует целое семейство методов доступа, исключающих столкновение: это мультиплексирование по времени (TDM) и по частоте (FDM). Здесь каждому клиенту выделяется определенный временной домен или частотный диапазон. Когда наступает его временной интервал и клиент имеет кадр (или бит), предназначенный для отправки, он делает это. При этом каждый клиент ждет в среднем n/2 временных интервалов (предполагается, что работает n клиентов). При FDM передача не требует ожидания. Но в обоих случаях временные интервалы или частотные диапазоны используются клиентом по мере необходимости и могут заметное время быть не заняты (простаивать). Такие протоколы доступа часто используются в мобильной связи.

    Интересной разновидностью Ethernet является широкополосная сеть типа Net/one. Она может базироваться на коаксиальном кабеле (суммарная длина до 1500м) или на оптическом волокне (полная длина до 2500м). Эта сеть по многим характеристикам аналогична обычному ethernet (CSMA/CD) за исключением того, что коммуникационное оборудование передает данные на одной частоте, а принимает - на другой. Для каждого канала выделяется полоса 5 Мбит/с (полоса пропускания 6МГц соответствует телевизионному стандарту). Предусматривается 5 передающих (59,75-89,75 МГц) и 5 принимающих (252-282 МГц) каналов для каждого из сетевых сегментов. Частота ошибок (BER) для сети данного типа меньше 10-8.

    Другой Ethernet-совместимой сетью является Fibercom Whispernet. Сеть имеет кольцевую структуру (до 8км), полосу пропускания 10Мбит/c, число узлов до 100 на сегменте при полном числе узлов в сети - 1024. Число кольцевых сегментов может достигать 101. Максимальное межузловое расстояние - 2км.

    Примером нетрадиционного типа сети может служить Localnet 20 (Sytek). Сеть базируется на одном коаксиальном кабеле и имеет полную полосу пропускания 400 МГц. Сеть делится на 120 каналов, каждый из которых работает со скоростью 128 Кбит/с. Каналы используют две 36МГц-полосы, одна для передачи, другая для приема. Каждый из коммуникационных каналов занимает 300КГц из 36МГц. Сеть использует алгоритм доступа CSMA/CD, что позволяет подключать к одному каналу большое число сетевых устройств. Предусматривается совместимость с интерфейсом RS-232. Частота ошибок в сети не более 10-8.

    Фирма Дженерал Электрик разработала сеть gm (map-шина), совместимую со стандартом IEEE 802.4. Целью разработки было обеспечение совместимости с производственным оборудованием различных компаний. Сеть рассчитана на работу со скоростями 1, 5 и 50 Мбит/с.

    Традиционные сети и телекоммуникационные каналы образуют основу сети - ее физический уровень. Реальная топология сети может динамически изменяться, хотя это и происходит обычно незаметно для участников. При реализации сети используются десятки протоколов. В любых коммуникационных протоколах важное значение имеют операции, ориентированные на установление связи (connection-oriented) и операции, не требующие связи (connectionless - "бессвязные", ISO 8473). Интернет использует оба типа операций. При первом типе пользователь и сеть сначала устанавливают логическую связь и только затем начинают обмен данными. Причем между отдельными пересылаемыми блоками данных (пакетами) поддерживается некоторое взаимодействие. "Бессвязные" операции не предполагают установления какой-либо связи между пользователем и сетью (например, протокол UDP) до начала обмена. Отдельные блоки передаваемых данных в этом случае абсолютно независимы и не требуют подтверждения получения. Пакеты могут быть потеряны, задублированы или доставлены не в порядке их отправки, причем ни отправитель, ни получатель не будут об этом оповещены. Именно к этому типу относится базовый протокол Интернет - IP.

    Для каждой сети характерен свой интервал размеров пакетов. Среди факторов, влияющих на выбор размеров можно выделить

    • Аппаратные ограничения, например размер домена при мультиплексировании по времени.
    • Операционная система, например размер буфера 512 байт.
    • Протокол (например, число бит в поле длины пакета).
    • Обеспечение совместимости с определенными стандартами.
    • Желание уменьшить число ошибок при передаче ниже заданного уровня.
    • Стремление уменьшить время занятости канала при передаче пакета.
    • Ниже приведены максимальные размеры пакетов (mtu) для ряда сетей

      Сеть

      MTU
      Байт

      Быстродействие
      Мбит/с

      IEEE 802.3

      1500

      10

      IEEE 802.4

      8191

      10

      IEEE 802.5

      5000

      4

      Операции, ориентированные на установление связи (например, протокол TCP), предполагают трехстороннее соглашение между двумя пользователями и провайдером услуг. В процессе обмена они хранят необходимую информацию друг о друге, с тем, чтобы не перегружать вспомогательными данными пересылаемые пакеты. В этом режиме обмена обычно требуется подтверждение получения пакета, а при обнаружении сбоя предусматривается механизм повторной передачи поврежденного пакета. "Бессвязная" сеть более надежна, так как она может отправлять отдельные пакеты по разным маршрутам, обходя поврежденные участки. Такая сеть не зависит от протоколов, используемых в субсетях. Большинство протоколов Интернет используют именно эту схему обмена. Концептуально TCP/IP-сети предлагают три типа сервиса в порядке нарастания уровня иерархии:

      1. "бессвязная" доставка пакетов;
      2. надежная транспортировка информации;
      3. реализация прикладных задач.

      Немногие из читателей участвуют в создании региональных и тем более глобальных сетей, за то структура и принципы построения локальных сетей им, безусловно, близки. На рис. 4.4 и 4.5 приведены два варианта "ресурсных" локальных сетей (сети для коллективного использования ресурсов - памяти, процессоров, принтеров, магнитофонов и т.д.). Такие сети строятся так, чтобы пропускная способность участков, где информационные потоки суммируются, имели адекватную полосу пропускания. Эффективность сети на рис. 4.4 сильно зависит от структуры и возможностей контроллеров внешних устройств, от объема их буферной памяти.

      Рис. 4.4. Вариант схемы ресурсной локальной сети

      Сеть, показанная на рис. 4.5, несравненно более эффективна (практически исключены столкновения и легче гарантировать определенное время доступа к ресурсу). Здесь также немало зависит от свойств контроллеров внешних ресурсов (помечены красным цветом). Но такие сети обычно более дорого реализовать.

      Рис. 4.5.

      Для сопоставления быстродействия различных видов сетей Сталлингс (Stallings, W.: Data and Computer Communications, New York: Mac-Millan Publishing Company, 1985) в 1985 году разработал критерий. Критерий предполагает вычисление битовой длины BL (максимальное число бит в сегменте), которая равна произведению максимальной длины сегмента (L) на полосу пропускания (W), деленное на скорость распространения сигнала в сегменте (S):

      BL = l*W/S

      Для Ethernet BL = [500(м)*10 106(бит/c)]/2 108 (м/c) = 25 бит.

      Коэффициент использования сети равен b = 1/(1+a), где

      . Для Ethernet при длине пакета 1500 байта a = 0,0021, что дает для эффективности использования сети 0,997. Таким образом, максимальная пропускная способность ethernet составляет 9,97 Мбит/c или 1,25 Мбайт/с. Разумеется, в этом подходе не учитываются издержки, связанные с заголовками пакетов, которые дополнительно снижают эффективность сети. Из данного рассмотрения может показаться, что чем больше пакет, тем лучше. С точки зрения пропускной способности так оно и есть. Но с увеличением длины пакета увеличивается время отклика сети. Таким образом, выбор MTU определяется реальными требованиями пользователей.

      Принципы построения сетевых программных интерфейсов

      Существует большое разнообразие сетевых интерфейсов. Их структура зависит от характера физического уровня сетевой среды, от метода доступа, от используемого набора интегральных схем и т.д.. Здесь пойдет речь о принципах построения программного интерфейса (см. также раздел 7; ..\7\soft_7.html).

      Существует три возможности построения интерфейса: с базированием на памяти, с использованием прямого доступа и с применением запросов обслуживания.

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

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

      Второй компонент интерфейса, базирующегося на использовании памяти, часто реализуется в виде так называемых буферов управления передачей (TCB). Эти буферы содержат такую информацию как положения сообщения в памяти, длина сообщения, адрес места назначения, идентификатор процесса-отправителя, приоритет сообщения, предельное значение числа попыток передачи, а также флаг, указывающий на необходимость присылки подтверждения от получателя. TCB (transmission control buffer) создается процессом-отправителем и передается интерфейсу, после завершения записи в буфер сообщений. Параметры TCB используются интерфейсом при организации процесса передачи сообщения.

      Третий компонент интерфейса, базирующегося на использовании памяти, называется буфером управления приемом (RCB - Reception Control Buffer). RCB содержит в себе информацию, сходную с той, что записывается в TCB, например, идентификатор отправителя, длина сообщения, индикатор ошибки, время приема и идентификатор процесса места назначения. RCB заполняется интерфейсом при получении сообщения и передается процессору ЭВМ. Основополагающим принципом построение всех трех компонент является совместное использование памяти и гибкая система указателей. Версия программы, рассмотренная в разделе 7 ближе именно к этой схеме взаимодействия.

      Во втором варианте широко используемой схемы доступа к сети ("прямой доступ") взаимодействие ЭВМ и интерфейса строится по схеме клиент-сервер. Конкретная реализация программы в этом случае в большей степени зависит от структуры регистров физического интерфейса.

      В третьем варианте сетевого программного интерфейса используются служебные запросы. Этот тип сетевого доступа удобен для коммуникационных протоколов высокого уровня, таких как команды ввода/вывода CSP-стиля (Communicating Sequential Processes) или процедуры обмена языка Ада. В этом методе накладываются определенные ограничения на реализацию нижележащих коммуникационных уровней.

      Программирование для сетей существенным образом является программированием для процессов реального времени. Здесь часто можно столкнуться с тем, что одна и та же программа ведет себя по-разному в разных ситуациях. Особое внимание нужно уделять написанию многопроцессных сетевых программ, где также как в случае (см. раздел 7.1; ..\7\sock_71.html) работы с соединителями могут возникать ситуации блокировок. Пример такой ситуации показан на рис. 4.6.

      Рис. 4.6.

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

      Необычайно важной проблемой при построении сетей является их устойчивость при возникновении перегрузок. В Интернет для этого используется специальная опция протокола ICMP, а во Frame Relay имеются меры для преодоления перегрузок непосредственно на нижних протокольных уровнях.

      Методы работы в условиях перегрузки

      Оптимальность управления сетью в условиях перегрузок определяет эффективность использования сети. Пока субсеть загружена незначительно, число принимаемых и обрабатываемых пакетов равно числу пришедших. Однако, когда в субсеть поступает слишком много пакетов может возникнуть перегрузка и рабочие характеристики деградируют. При очень больших загрузках пропускная способность канала или сети может стать нулевой (см. [39]) Такая ситуация называется коллапсом сети.

      Отчасти это может быть связано с недостатком памяти для входных буферов, по этой причине некоторое увеличение памяти может помочь. Но следует помнить, что всякое лекарство хорошо в меру. Еще в 1987 году Нагле (Nagle) обнаружил, что если маршрутизатор имеет даже беспредельную память, эффект перегрузки может оказаться еще более тяжелым. Это сопряжено со временем, которые пакеты ожидают обработки. Если время ожидания в очереди превышает длительность таймаута, появятся дубликаты пакетов, что, безусловно, понижает эффективность системы. Причиной перегрузки может быть медленный процессор или недостаточная пропускная способность какого-то участка сети. Простая замена процессора или интерфейса на более быстродействующий не всегда решает проблему - чаще переносит узкое место в другую часть системы. Перегрузка, как правило, включает механизмы, усиливающие ее негативное воздействие. Так переполнение буфера приводит к потере пакетов, которые позднее должны будут переданы повторно (возможно даже несколько раз). Процессор передающей стороны получает дополнительную паразитную загрузку. Все это указывает на то, что контроль перегрузки является крайне важным процессом. Следует делать различие между контролем потока и контролем перегрузки. Под контролем потока подразумевается балансировка потока отправителя и возможности приема и обработки получателя. Этот вид контроля предполагает наличие обратной связи между получателем и отправителем. В этом процессе участвуют, как правило, только два партнера. Перегрузка же более общее явление, относящееся к сети в целом или к какой-то ее части. Например, 10 ЭВМ хотят передать одновременно какие-то файлы другим 10 ЭВМ. Конфликта потоков здесь нет, каждая из ЭВМ способна переработать поступающие данные, но сеть не может пропустить поток, генерируемый 10 сетевыми интерфейсами одновременно. Часто эти явления не так просто разделить. Отправитель может получить сообщение ICMP (quench) (в случае TCP/IP) при перегрузке получателя или при перегрузке какого-то сегмента сети.

      Начинать надо с решения проблемы выявления перегрузок. Перегрузкой следует считать ситуацию, когда нагрузка в течение некоторого оговоренного времени превышает заданную величину. Параметрами, которые позволяют судить о наличии перегрузки могут служить:

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

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

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

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

      Преодоление перегрузки может быть осуществлено понижением нагрузки или добавлением ресурсов приемнику.

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

      Одной из причин перегрузки часто являются импульсные загрузки сегмента сети или сетевого устройства. По этой причине любые меры (напр., pipelining), которые могут выравнять поток пакетов, безусловно улучшат ситуацию (например, traffic shaping в сетях ATM). В TCP же с его окнами импульсные загрузки предопределены.

      Алгоритм leaky bucket ("дырявое ведро")

      Для систем без обратной связи решение проблемы выравнивания скорости передачи данных может быть решено с помощью алгоритма leaky bucket. Суть этого алгоритма заключается в том, что на пути потока устанавливается буфер выходной поток которого постоянен и согласован с возможностью приемника. Если буфер переполняется, пакеты теряются. Потеря пакетов вещь мало приятная, но это блокирует процессы, которые могут привести к коллапсу сегмента или всей сети. Там, где потеря пакетов нежелательна, можно применить более гибкий алгоритм.

      Алгоритм Token Bucket ("маркерное ведро")

      Алгоритм token bucket предполагает наличие в буферном устройстве (или программе) некоторого количества маркеров. При поступлении на вход буфера пакетов маркеры используются для их транспортировки на выход. Дальнейшая передача данных на выход зависит от генерации новых маркеров. Поступающие извне пакеты тем временем накапливаются в буфере. Таким образом, полной гарантии отсутствия потерь мы не имеем и здесь. Но алгоритм token bucket позволяет передавать на выход "плотные" группы пакетов ограниченной численности (по числу маркеров), снижая в некоторых случаях вероятность потери. Если буферное устройство "смонтировано" внутри ЭВМ-отправителя, потерь можно избежать вовсе, блокируя передачу при заполнении буфера. Как в одном так и в другом алгоритме мерой передаваемой информации может быть не пакет, а n-байт (где n некоторое оговоренное заранее число).

      В системах, где управление трафиком осуществляется с использованием обратной связи, можно достичь большей эффективности. Одним из механизмов преодоления перегрузок является управление разрешением (admission control). Суть метода заключается в том, что при регистрации перегрузки не формируется более никаких виртуальных соединений до тех пор, пока ситуация не улучшится. Альтернативным вариантом может служить решение, где формирование нового соединения разрешается, но при этом осуществляется маршрутизация так, чтобы обойти узлы, в которых выявлена перегрузка (смотри рис. 4.7 ).

      Рис. 4.7. Выбор маршрута нового виртуального канала при наличии перегрузки

      На рис. 4.7 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены красным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка синим цветом показан новый виртуальный канал.

      Еще более универсальным решение, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов l, которая может принимать значения от 0 до 1. Когда l достигает некоторого порогового значения, отправителю посылается пакет блокировки. При вычислении l следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок.

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

      ЭВМ может понижать трафик, корректируя свои параметры, например, ширину окна или темп передачи на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на 0,25 от первичного и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки. Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или заполненность буфера.

      Ситуация перегрузки не всегда управляется однозначно. Например, при поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queueing (честная очередь). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отравляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок оказываются посланы по одному пакету из каждой очереди. Такой алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает некоторые преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложил некоторое усовершенствоввание алгоритма. В данном варианте организуется циклический просмотр очередей не по-пакетно, а по-байтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть рис. 4.8. (см. также [39])

      Рис. 4.8. Маршрутизатор с 4-мя входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов.

      Пакеты на рисунке имеют от трех до девяти октетов. Порядок пересылки октетов показан в левой части рисунка. В отсутствии поступления новых пакетов, кадры, записанные в буфер будут переданы в порядке, представленном в правой части рисунка. Особенностью этого алгоритма является равенство приоритета всех входных каналов.

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

      В протоколе TCP используется алгоритм управления трафиком, называемый "скользящее окно". Здесь размер окна, которое определяет число сегментов, посылаемых без получения подтверждения, варьируется в зависимости от наличия потерь пакетов. При большой вероятности потери система переходит в режим, когда очередной пакет не посылается до тех пор, пока не будет подтверждено получение предшествующего. При серьезных перегрузках, когда потери становятся значительными, нарушается механизм вычисления значений RTT и таймаутов, что может приводить к трудно предсказуемым последствиям. Следует обратить внимание, что в протоколе UDP какого-либо механизма управления трафиком не предусмотрено. По этой причине для некоторых мультимедийных задач, следует предусматривать другие, например, ICMP-способы подавления перегрузки. В приложениях типа NFS, где используется UDP, для подавления перегрузки используется упомянутый выше ICMP-механизм. К сожаления в ряде мультимедийных приложений потеря пакетов не контролируется (например IP-телефония). Там шлюз 100-10Мбит/с может восприниматься как канал с вероятностью потери пакета 90%.

      Если другие способы испробованы, а перегрузка не исчезла, маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не может обработать. Самое простое - это предоставить случаю выбор отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки мультимедийных данных предпочтение следует делать для последних полученных пакетов, а "старые" пакеты выбрасывать. При передаче файлов наоборот "старый" пакет имеет приоритет, ведь если его отбросить, придется повторно передавать не только его, но и все последующие пакеты. Некоторые методы передачи изображения требуют передачи время от времени всего кадра с последующей пересылкой только фрагментов, где произошли изменения. В таких условиях потеря пакета, составляющего базовый кадр, менее желательна. Сходные обстоятельства могут возникать и в других приложениях. Можно помечать пакеты, присваивая им определенные уровни приоритетов, что позволит осознанно принимать решение об отбрасывании того или иного пакета в условиях перегрузки. В перспективе проблема может быть решена на чисто коммерческой основе - компонента трафика, помеченная как высоко приоритетная, будет оплачиваться по более высокому тарифу. В некоторых сетях определенное количество пакетов объединяется в группы, образующие сообщение. Если одна ячейка такого сообщения выбрашена, все сообщение будет повторно переслано (смотри, например, адаптационные уровни сетей ATM).

    Previous: 3.6 Протокол G.703    UP: 3 Каналы передачи данных
    Down: 4.1 Локальные сети (обзор)    Next: 4.1 Локальные сети (обзор)


    previous up down next index index
    Previous: 4.1.1 Ethernet (IEEE 802.3)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.1.2 Fast Ethernet

    4.1.1.1 Архитектура сетей Ethernet
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации. К этой разновидности относится и Ethernet (10 Мбит/с 0,01%). Фирма Ксерокс осуществила разработку протокола Ethernet в 1973 году, а в 1979 году объединение компаний Ксерокс, Интел и DEC (DIX) предоставило документ для стандартизации протокола в IEEE. Предложение с небольшими изменениями было принято комитетом 802.3 в 1983 году. Кадр Ethernet имеет формат, показанный на рис. 4.1.1.1.1.

    Рис. 4.1.1.1.1 Формат кадра сетей ethernet (цифры в верхней части рисунка показывают размер поля в байтах)

    Поле преамбула содержит 7 байт 0хАА и служит для стабилизации и синхронизации среды (чередующиеся сигналы CD1 и CD0 при завершающем CD0), далее следует поле SFD (start frame delimiter = 0xab), которое предназначено для выявления начала кадра. Поле EFD (end frame delimiter) задает конец кадра. Поле контрольной суммы (CRC - cyclic redundancy check), также как и преамбула, SFD и EFD, формируются и контролируются на аппаратном уровне. В некоторых модификациях протокола поле efd не используется. Пользователю доступны поля, начиная с адреса получателя и кончая полем информация, включительно. После crc следует межпакетная пауза (IPG - interpacket gap - межпакетный интервал) длиной 9,6 мксек или более. Максимальный размер кадра равен 1518 байт (сюда не включены поля преамбулы, SFD и EFD). Интерфейс просматривает все пакеты, следующие по кабельному сегменту, к которому он подключен, ведь определить, корректен ли принятый пакет и кому он адресован, можно лишь приняв его целиком. Корректность пакета по CRC, по длине и кратности целому числу байт производится после проверки адреса места назначения. Вероятность ошибки передачи при наличии crc контроля составляет ~2-32. При вычислении CRC используется образующий полином:

    G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1.

    Алгоритм вычисления CRC сводится к вычислению остатка от деления кода M(x), характеризующего кадр, на образующий полином G(x) (Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification. Published by IEEE (802.3-1985). Wiley-Interscience, John & sons, inc.). CRC представляет собой дополнение полученного остатка R(x). CRC пересылается, начиная со старших разрядов. Схема взаимодействия различных субуровней при реализации протокола IEEE 802.3 показана на рис 4.1.1.1.2. Выше llc размещаются верхние субуровни, включая прикладной. Через AUI данные передаются с использованием манчестерского кода.

    Рис. 4.1.1.1.2. Схема взаимодействия субуровней 802.3 (CSMA/CD)

    Манчестерский код объединяет в бит-сигнале данные и синхронизацию. Каждый бит-символ делится на две части, причем вторая часть всегда является инверсной по отношению первой. В первой половине кодируемый сигнал представлен в логически дополнительном виде, а во второй - в обычном. Таким образом, сигнал логического 0 - CD0 характеризуется в первой половине уровнем HI, а во второй LO. Соответственно сигнал CD1 характеризуется в первой половине бит-символа уровнем LO, а во второй - HI. Примеры форм сигналов при манчестерском кодировании представлены на рис. 4.1.1.1.3.

    Рис. 4.1.1.1.3 Примеры кодировки с использованием манчестерского кода

    Ниже в таблице 4.1.1.1.1 приведены ограничения, налагаемые на сеть Ethernet в целом и на отдельные ее фрагменты.

    Таблица 4.1.1.1.1. Возможности различных схем реализации ethernet

    Тип кабеля

    Толстый
    (10base5)

    Тонкий
    (10base2)

    Скрученная
    пара (10baset)

    Максимальная длина сети (м)

    2500

    900

    -

    Максимальная длина кабельного сегмента (м)

    500

    185

    100

    Максимальное число подключений к сегменту

    100

    30

    1

    Минимальное расстояние между точками подключения (м)

    2.5

    0.5

    -

    Максимальное удаление узлов

    5 сегментов
    и 4 повторителя

    5 сегментов
    и 4 повторителя

    5 сегментов и 4 повторителя

    Из таблицы видно, что максимальная задержка в сети ethernet складывается из:

      1. 4*tr (задержка, вносимая повторителями, при их максимальном числе =4; tr - задержка сигнала в репитере, ~20 бит-тактов)
      2. 4,5нсек/м*5*500м (задержка пяти кабельных сегментов)
      3. 4нсек/м*2*50м (задержка, вносимая двумя кабелями aui, первого и последнего сегментов)
      4. задержки сетевых интерфейсов и трансиверов (~2*20 бит-тактов)

    В сумме это соответствует ~220 бит-тактам. Минимальная длина пакета должна быть больше удвоенного значения этой задержки (выбрано 64 байта = 512 тактов). Если размер пакета меньше 64 байт, добавляются байты-заполнители, чтобы кадр в любом случае имел соответствующий размер. При приеме контролируется длина пакета и, если она превышает 1518 байт, пакет считается избыточным и обрабатываться не будет. Аналогичная судьба ждет кадры короче 64 байт. Любой пакет должен иметь длину, кратную 8 бит (целое число байт). Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Формат адреса получателя или отправителя (MAC) показан на рис. 4.1.1.1.4. Для передачи данных на физическом уровне используется манчестерский код.

    Рис. 4.1.1.1.4. Формат mac-адреса

    В верхней части рисунка указана длина полей адреса, в нижней - нумерация разрядов. Субполе I/G представляет собой флаг индивидуального или группового адреса. I/G=0 - указывает на то, что адрес является индивидуальным адресом сетевого объекта. I/G=1 характеризует адрес как мультикастинговый, в этом случае дальнейшее разбиение адреса на субполя теряет смысл. Субполе UL является флагом универсального или местного управления (определяет механизм присвоения адреса сетевому интерфейсу). U/L=1 указывает на локальную адресацию (адрес задан не производителем и ответственность за уникальность лежит на администраторе LAN). U/L=I/G=0 характерно для стандартных уникальных адресов, присваиваемых интерфейсу его изготовителем. Субполе OUI (organizationally unique identifier) позволяет определить производителя сетевого интерфейса. Каждому производителю присваивается один или несколько OUI. Размер субполя позволяет идентифицировать около 4 миллионов различных производителей. За корректность присвоения уникального адреса интерфейса (OUA - organizationally unique address) несет ответственность производитель. Двух интерфейсов одного и того же производителя с идентичными номерами не должно существовать. Размер поля позволяет произвести примерно 16 миллионов интерфейсов. Комбинация oui и oua составляют UAA (universally administrated address = IEEE-адрес).

    Если в поле кадра протокол/тип записан код менее 1500, то это поле характеризует длину кадра. В противном случае - это код протокола, пакет которого инкапсулирован в кадр Ethernet.

    Доступ к каналу Ethernet базируется на алгоритме CSMA/CD (carrier sense multiple access with collision detection). В Ethernet любая станция, подключенная к сети, может попытаться начать передачу пакета (кадра), если кабельный сегмент, к которому она подключена, свободен. Свободен ли сегмент, интерфейс определяет по отсутствию "несущей" в течение 9,6 мксек. Так как первый бит пакета достигает остальных станций сети не одновременно, может случиться, что попытку передачи совершат две или более станций, тем более что задержки в повторителях и кабелях могут достигать достаточно больших величин. Такие совпадения попыток называются столкновениями. Столкновение (коллизия) распознается по наличию в канале сигнала, уровень которого соответствует работе двух или более трансиверов одновременно. При обнаружении столкновения станция прерывает передачу. Возобновление попытки может быть произведено после выдержки (кратной 51,2 мксек, но не превосходящей 52 мсек), значения которой является псевдослучайной величиной и вычисляется каждой станцией независимо (t= RAND(0,2min(n,10)), где n - содержимое счетчика попыток, а число 10 - backofflimit).

    После выдержки станция увеличивает на единицу счетчик попыток и начинает очередную передачу. Предельное число попыток по умолчанию равно 16, если число попыток исчерпано, связь прерывается и выдается соответствующее сообщение. Передаваемый длинный кадр способствует "синхронизации" начала передачи пакетов несколькими станциями. Ведь за время передачи с заметной вероятностью может возникнуть необходимость передачи у двух и более станций. В момент, когда они обнаружат завершение пакета, будут включены таймеры IPG. К счастью информация о завершении передачи пакета доходит до станций сегмента не одновременно. Но задержки, с которыми это связано, являются также причиной того, что факт начала передачи нового пакета одной из станций не становится известным немедленно. При вовлечении в столкновение нескольких станций они могут уведомить остальные станции об этом, послав сигнал "затора" (jam - не менее 32 бит). Содержимое этих 32 бит не регламентируется. Такая схема делает менее вероятным повторное столкновение. Источником большого числа столкновений (помимо информационной перегрузки) может служить запредельная суммарная длина логического кабельного сегмента, слишком большое число повторителей, обрыв кабеля, отсутствие терминатора (50-омного согласователя кабеля) или неисправность одного из интерфейсов. Но сами по себе столкновения не являются чем-то негативным - это механизм, регулирующий доступ к сетевой среде.

    Под логическим кабельным сегментом (иногда называемым областью столкновений) подразумевается один или несколько кабельных сегментов, объединенных повторителями. Анализ столкновений является одним из средств эффективной диагностики сети. Локальные столкновения (столкновения на сегменте, к которому непосредственно подключена рабочая станция) порождают укороченные пакеты-фрагменты (ведь их передача прерывается) с длиной менее 64 октетов. Большинство трансиверов и репитеров имеют на своих передних панелях индикаторы столкновений. Блок-схема реализации протокола CSMA/CD показана на рис. 4.1.1.1.4. Особое внимание я бы хотел обратить на влияние сигнала jam. В процессе пересылки столкнувшихся пакетов и за время передачи сигнала jam другие узлы могли захотеть что-то передать. Если таких узлов больше одного, то это приведет к синхронизации начала передачи этими узлами и к увеличению вероятности столкновения. Практически такую "синхронизацию" может осуществить любой достаточно длинный пакет. Такая синхронизация является причиной "коллапса" сети при большой загрузке.

    Рис. 4.1.1.1.5 Блок-схема реализации алгоритма доступа к сетевой среде CSMA/CD

    Метод CSMA/CD создает неопределенность времени доступа к сети, что делает ее неудобной для решения некоторых задач управления в реальном масштабе времени, где требуется малое время реакции системы на внешнее воздействие.

    Рис. 4.1.1.1.6 Схема некоторых возможных вариантов подключения рабочих станций к Ethernet

    Исторически первой появилась схема подключения к толстому 50-омному коаксиальному кабелю (сегмент 1 на рис. 4.1.1.1.6; Z=50 ╠2 Ом) через трансивер и многожильный кабель типа AUI (attachment unit interface, максимальная длина 50 м). Трансивер подключается к кабелю методом "наколки", то есть во внешней оплетке и изоляции сверлится с помощью специального инструмента отверстие и через него осуществляется контакт трансивера с центральной жилой кабеля и экраном. Кабель по возможности не должен содержать сросток, в противном случае его предельная длина должна быть сокращена. Кабельный сегмент должен быть согласован с обоих сторон с помощью терминаторов (50 Ом ╠1%). Позднее стала популярной схема соединений через тонкий коаксиальный кабель и t-образные коаксиальные разъемы (волновое сопротивление 50 Ом). В настоящее время наибольшее применение находит схема со специальными многовходовыми повторителями-концентраторами (Hub) и подключением оконечного оборудования через скрученные пары. Для подключения используется 8-контактный разъем RJ-45 (см. приложение 10.17 Разводка разъемов). Этому способствует удешевление категорированных скрученных пар, соответствующих повторителей, а также большая надежность и лучшая ремонтоспособность таких сетей. Следует иметь в виду, что предельные длины для коаксиальных кабелей, приведенные в таблице 4.1.1.1.1 относятся к зарубежным типам, в частности в случае тонкого кабеля - это rg-58. Отечественные разновидности кабеля, например РК-50-2-11, допускают (при максимальной загрузке) длины примерно в 1,3-1,5 раз меньше. Это связано с меньшим сечением центральной жилы и большей вариацией волнового сопротивления. Если же число ЭВМ подключенных к кабельному сегменту много меньше предельного, допускается использование и запредельных длин кабельных сегментов, но это не рекомендуется. Пропускная способность сети с методом доступа csma/cd снижается по мере роста загрузки из-за увеличения вероятности столкновений. По этой причине даже использование 100-мегагерцного ethernet не может гарантировать большей пропускной способности (по сравнению с обычным, см. рис. 4.1.1.1.8) при условии высоких загрузок и, как следствие, высоких вероятностей столкновений. ethernet-интерфейс перед началом передачи контролирует состояние кабельного сегмента (наличие несущей), выжидает некоторое время, если сегмент занят, после чего производит попытку передачи с контролем возможности столкновения.

    Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Схема интерфейса на уровне mau в упрощенном виде имеет вид, показанный на рис. 4.1.1.1.7.

    Рис. 4.1.1.1.7. Схема интерфейса на уровне mau

    Схема signal quality регистрирует коллизии и другие искажения сигнала и выдает в этом случае флаг SQE (signal quality error). sqe представляет собой сигнал CS0, посылаемый от MAU к DTE (точнее PMA к PLS, см. рис. 4.1.1.1.2). Сигнал SQE посылается mau также в случае завершения процесса передачи (output_idle). Узел isolate служит для блокировки передачи данных в сетевую среду, при этом DTE передает mau сигнал CS0. Суммарная емкостная нагрузка, вносимая mau, не должна превышать 4 пф. Входное сопротивление должно быть более 100 ком, а ток утечки должен лежать в пределах +2 мкА -25мкА. Выходной драйвер mau при передаче выдает в кабель -90 ╠4мa (эквивалентно -2,05В на нагрузке 25 Ом). Предельное ослабление сигнала на длине 500 м не должно превышать 8,5 дБ (на частоте 10МГц).

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

    Помимо столкновений в сети может быть зарегистрировано появление ложной несущей (FCE - false carrier event) - битовая последовательность не имеет байта SFD, соответствующего конкретному типу физической среды. Появление ложной несущей обычно связано с состоянием кабеля или шумами. Если фиксируется появление двух ложных несущих подряд, повторитель должен отключить порт (перевести в состояние link unstable) и послать сигнал jam во все остальные порты. Сигнал jam должен продолжаться до конца потока данных, вызвавшего появление ложной несущей. Если канал восстановлен, повторитель переводит порт в нормальное состояние. Отключение порта возможно также при возникновении множественных коллизий (ECE - excessive collision error) - более 60 коллизий подряд. После блокировки порта он будет восстановлен, если в течении 500 тактов коллизии не обнаружены или при повторном включении повторителя. Если рассмотреть зависимость пропускной способности сети L от ее суммарной загрузки Lin, мы для Ethernet получим кривую, показанную на рис. 4.1.1.1.8.

    Рис. 4.1.1.1.8. Зависимость пропускной способности l in сети со схемой доступа CSMA/CD от суммарной загрузки l

    Вначале эта зависимость линейна и на участке А пропускная способность удовлетворительна. Но при больших входных загрузках из-за коллизий сначала наступает насыщение, а затем и резкий спад (Ethernet collapse). Это свойство сетей с CSMA/CD дает определенные преимущества сетям с маркерным доступом: Token Ring, FDDI и др..

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

    Таблица 4.1.1.1.2 Сопротивление кабеля по постоянному току
    (Handbook of LAN Cable Testing. Wavetek Corporation, California)

    Коаксиал

    Ом/сегмент

    Максимальная длина сегмента

    10base5

    5

    500 м

    10base2

    10

    185 м

    Скрученная пара

    Ом/100 м

    24 awg

    18,8

    22 awg

    11,8

    Данные, приведенные в таблице, могут использоваться для оперативной предварительной оценки качества кабельного сегмента (соответствует стандарту EIA/TIA 568, 1991 год).

    Помимо уже описанных модификаций сетей ethernet в последнее время получили распространение сети для частот 100 Мбит/с, которые базируются на каналах, построенных из скрученных пар или оптоволоконных кабелей. Оптические связи используются и в обычном 10-мегагерцном ethernet (10base-FL, стандарт разработан в 1980 году, см. рис. 4.1.1.1.9).

    Оптоволоконная версия ethernet привлекательна при объединении сегментов сети, размещенных в различных зданиях, при этом увеличивается надежность сети, так как ослабляется влияние электромагнитных наводок, исключается влияние различия потенциалов земли этих участков сети. Облегчается переход от 10- к 100-мегагерцному Ethernet, также можно использовать уже имеющиеся оптоволоконные каналы, ведь они будут работать и на 100 Мбит/с (возможна реализация сетей со смешанной структурой, где используется как 100- так и 10-мегагерцное оборудование). На программном уровне 10- и 100-МГц ethernet не различимы. Требования к параметрам опто-волоконных кабелей не зависят от используемого протокола (FDDI, Token Ring, Fast Ethernet и т.д.) и определяются документом EN 50173 (European norm). Это утверждение не относится к топологии кабельных связей, которые в общем случае зависят от используемого протокола. При работе с оптоволоконными системами необходимы специальные тестеры, способные измерять потери света и отражения методом OTDR (рефлектометрия с использованием метода временных доменов). При пассивной звездообразной схеме длины оптоволоконных сегментов могут достигать 500 метров, а число подключенных ЭВМ - 33. Для передачи сигналов используются многомодовые волокна (MMF) с диаметром ядра 62,5 микрон и клэдинга 125 микрон. Длина волны излучения равна 850 (или 1350) нанометров при ослаблении сигнала в кабельном сегменте не более 12,5 дБ. Обычный кабель имеет ослабление 4-5 дБ/км. Оптические разъемы должны соответствовать требования стандарта ISO/IEC BFOC/2,5 и вносить ослабление не более 0,5 - 2,0 дБ. Количество используемых mau в логическом сегменте не должно превышать двух.

    Рис. 4.1.1.1.9. Схема 10-мегагерцного оптоволоконного Ethernet.

    На данном рисунке видно, что соединения повторителя с FOMAU является дуплексным, аналогичные возможности предоставляют многие современные переключатели. Полно дуплексное подключение оборудование во многих случаях может обеспечить практическое удвоение скорости обмена и, что возможно более важно, исключить столкновения пакетов. Схема полно дуплексного соединения показана на рис. 4.1.1.1.10.

    Рис. 4.1.1.1.10. Схеме реализации полно дуплексного канала Ethernet. (Буква К с цифрой отмечает номера ножек контактов разъема)

    При практической реализации локальной сети обычно возникает проблема защиты и заземления. Если этой проблеме не уделить внимание в самом начале она даст о себе знать позднее и обойдется ее решение дороже. Можно выделить три аспекта. Безопасность персонала, работающего с ЭВМ и сетевым оборудованием, устойчивость к внешним наводкам и помехам, а также безопасность самого сетевого оборудования (противостояние грозовым разрядам или резким скачкам в сети переменного тока (обычно ~220 В)). Безопасность персонала обеспечивается тем, что все объекты, за которые может взяться человек, должны иметь равные потенциалы и в любом случае разница потенциалов не должна превышать 50 вольт. При работе с коаксиальным кабелем существуют рекомендации его заземления в одной точке. Возникает вопрос, что делать с заземлением экранов в случае использования экранированных скрученных пар? Этой проблеме посвящена, например, статья в журнале LANline Special Juli/August 2002 страницы 27-32. Следует сразу заметить, что нужно избегать совмещения применения экранированных и неэкранированных скрученных пар в пределах одной системы. Представляется также естественной и разумной зонная концепция, рассматриваемая в упомянутой статье. На рис. 1. показана схема защиты. Эта схема содержит защитные выключатели на случай грозы или бросков напряжения (линия L). Буквой N обозначена нулевая (нейтральная) шина, а буквами PE - защитная шина.

    Рис. 4.1.1.1.11. Схема защиты для случая использования экранированных скрученных пар

    Рис. 4.1.1.1.12. Зоны заземлений

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

    Previous: 4.1.1 Ethernet (IEEE 802.3)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.1.2 Fast Ethernet


    previous up down next index index
    Previous: 4.1.1.1 Архитектура сетей Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.1.3 Интернет в Ethernet

    4.1.1.2 Fast Ethernet
    Семенов Ю.А. (ГНЦ ИТЭФ)

    100-мегагерцную сеть ethernet дешевле создать на базе скрученных пар. Существует несколько версий 100-мегагерцного ethernet ( 100base-T4, 100base-TX, 100base-FX, стандарт 100VG-anylan - IEEE 802.12).

    TX и RX передатчики и приемники входных/выходных оптоволоконных трансиверов, соответственно. FOMAU - (fiber optic media attachment unit) оптоволоконный трансивер (см. рис. 4.1.1.1.9).

    Сегменты T4 (100base-T4) используют четыре скрученные пары телефонного качества (экранированные и неэкранированные скрученные пары проводов категории 3, 4 или 5) длиной до 100м. Провода должны быть скручены по всей длине, скрутка может быть прервана не далее как в 12мм от разъема (это требование справедливо и для сегментов типа TX).

    Сегменты TX (100base-TX, стандарт ANSI TP-PMD) состоят из двух скрученных пар проводов информационного качества (волновое сопротивление 100-150 Ом, экранированные и неэкранированные скрученные пары проводов категории 5, длина до 100м).

    FX-сегменты (100base-FX) представляют собой оптоволоконные кабели, отвечающие требованиям стандарта ANSI. Мультимодовое волокно 62,5/125 m (см. выше) работает в инфракрасном диапазоне 1350нм. Максимальная длина сегмента составляет 412 метров, ограничение определяется соображениями допустимых задержек. Предельное ослабление сигнала в волокне не должно превышать 11 дБ, стандартный кабель имеет 1-5 дБ/км. Оптические разъемы должны отвечать тем же требованиям, что и разъемы, используемые в FDDI-сетях (MIC- Media Interface Connector).

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

    Универсальная схема подключения ЭВМ или любого другого оборудования (например, сетевого принтера) к 100-мегагерцному ethernet показана на рис. 4.1.1.2.1.

    Физическая среда служит для передачи сигналов Ethernet от одной ЭВМ к другой. Выше были перечислены три вида физических сред, используемых 100-мегагерцным Ethernet (T4, TX и FX). Здесь используется 8-контактный разъем (RJ-45) для скрученных пар или специальный оптоволоконный соединитель. Блок PHY выполняет ту же функцию, что и трансивер в 10-мегагерцном Ethernet. Он может представлять собой набор интегральных схем в сетевом порту или иметь вид небольшой коробочки на MII-кабеле. Интерфейс MII является опционным, он может поддерживать работу с 10- и 100-мегагерцным ethernet. Задачей MII является преобразование сигналов, поступающих от PHY, в форму, приемлемую для стандартного набора ИС Ethernet. Соединительный кабель не должен быть длиннее 0,5м. PHY и MII могут быть объединены на одной интерфейсной плате, вставляемой в ЭВМ.

    Рис. 4.1.1.2.1 Блок-схема подключения оборудования к 100-мегагерцному Ethernet

    В сетях 100-мегагерцного Ethernet используются повторители двух классов (I и II). Задержки сигналов в повторителях класса I больше (~140нс), зато они преобразуют входные сигналы в соответствии с регламентациями применяемыми при работе с цифровыми кодами. Такие повторители могут соединять каналы, отвечающие разным требованиям, например, 100base-TX и 100base-T4 или 100base-FX. Преобразование сигнала может занимать время, соответствующее передаче нескольких бит, поэтому в пределах одного логического сегмента может быть применен только один повторитель класса I, если кабельные сегменты имеют предельную длину. Повторители часто имеют встроенные возможности управления с использованием протокола SNMP.

    Повторители класса II имеют небольшие задержки (~90нс или даже меньше), но никакого преобразования сигналов здесь не производится, и по этой причине они могут объединять только однотипные сегменты. Логический сегмент может содержать не более двух повторителя класса II, если кабели имеют предельную длину. Повторители класса II не могут объединять сегменты разных типов, например, 100base-TX и 100base-T4. Согласно требованиям комитета IEEE время задержки сигнала jam в повторителе Fast Ethernet (TX и FX) не должно превышать 460 нсек, а для 100base-T4 - 670 нсек. Для повторителей класса I эта задержка не должна быть больше 1400 нсек. Значения предельных длин сегментов для различных конфигураций сети приведены в таблице 4.1.1.2.1.

    Таблица 4.1.1.2.1. Максимальные размеры логического кабельного сегмента

    Тип повторителя

    Скрученные пары
    [м]

    Оптическое волокно
    [м]

    Один сегмент ЭВМ-ЭВМ

    100

    412

    Один повторитель класса I

    200

    272

    Один повторитель класса II

    200

    320

    Два повторителя класса II

    205

    228

    Типовые задержки для различных устройств Fast Ethernet представлены в табл. 4.1.1.2.2.

    Таблица 4.1.1.2.2

    Сетевое устройство

    Задержка [нсек]

    Повторитель класса I

    700

    Повторитель класса II (порты T4 и TX/FX)

    460

    Повторитель класса II (все порты T4)

    340

    Сетевая карта T4

    345

    Сетевая карта ТХ или FX

    250

    Вариант построения 100-мегагерцной сети ethernet показан на рис. 4.1.1.2.2.

    Рис. 4.1.1.2.2. Возможная схема 100-мегагерцной сети ethernet.

    Из рисунка видно, что максимальная длина логического сегмента не может превышать А+Б+В = 205 метров (см. табл. 4.1.1.2.3.). Предельно допустимые длины кабелей А и В приведены в табл. 4.1.1.2.3.

    Таблица 4.1.1.2.3. Максимально допустимые длины кабелей для сети, показанной на рис. 4.1.1.2.2
    (Таблица взята из книги Лаема Куина и Ричарда Рассела Fast Ethernet, bhv, Киев, 1998.).

    Тип кабеля А (категория)

    Тип кабеля В (категория)

    Класс повторителя

    Макс. длина кабеля А [м]

    Макс. длина кабеля В [м]

    Макс. диаметр сети [м]

    5,4,3 (TX, FX)

    5,4,3 (TX, FX)

    I или II

    100

    100

    200

    5 (TX)

    Оптоволокно

    I

    100

    160,8

    260,8

    3 или 4 (T4)

    Оптоволокно

    I

    100

    131

    231

    Оптоволокно

    Оптоволокно

    I

    136

    136

    272

    5 (TX)

    Оптоволокно

    II

    100

    208,8

    308,8

    3 или 4 (T4)

    Оптоволокно

    II

    100

    204

    304

    Оптоволокно

    Оптоволокно

    II

    160

    160

    320

    При работе со скрученными парами (стандарт TX) используется 8-контактный разъем RJ-45 со следующим назначением контактов:

    Номер контакта

    Назначение сигнала

    Номер контакта

    Назначение сигнала

    1

    Передача +

    5

    Не используется

    2

    Передача -

    6

    Прием -

    3

    Прием +

    7

    Не используется

    4

    Не используется

    8

    Не используется

    Если используются экранированные пары и 9-контактный разъем "d"-типа, то назначение контактов следующее:

    Контакт 1

    Прием +

    Контакт 5

    Передача +

    Контакт 6

    Прием -

    Контакт 9

    Передача -

    Для стандарта 100base-T4 назначение контактов приведено в таблице 4.1.1.2.4.

    Таблица 4.1.1.2.4. Разъем MDI (media dependant interface) кабеля 100base-t4

    Номер контакта

    Назначение сигнала

    Цвет провода

    1

    tx_d1 + (передача)

    Белый/оранжевый

    2

    tx_d1 -

    Оранжевый/белый

    3

    rx_d2 + (прием)

    Белый/зеленый

    4

    bi_d3 + (двунаправленная)

    Голубой/белый>

    5

    bi_d3 -

    Белый/голубой

    6

    rx_d2 -

    Зеленый/белый

    7

    bi_d4 +

    Белый/коричневый>

    8

    bi_d4 -

    Коричневый/белый

    Как видно из таблицы, одна пара предназначена для передачи (TX), одна для приема (RX) и две для двунаправленной передачи (BI). Знак полярности сигналов обозначен соответственно + и -. Уровень логической единицы +3,5 В (CS1), нуля - 0 В (CS0), а -1 соответствует -3,5 В (CS-1). Стандарт 100base-T4 предполагает применение схемы кодирования 8B6T. Алгоритм 8B6T преобразует октет данных в 6-битовый тернарный символ, который называется кодовой группой 6Т. Эти кодовые группы передаются параллельно по трем скрученным парам сетевого кабеля, что позволяет осуществлять обмен лишь со скоростью 33,33Мбит/с. Скорость же передачи тернарных символов по каждой из пар проводов равна 6/8 от 33,33 Мбит/с, что эквивалентно 25 МГц. Шесть тернарных символов позволяют отобразить 36=729 различных кодов. Это позволяет отобрать для отображения 256 восьмибитовых кодов те тернарные символы, которые обеспечивают не менее 2 перепадов уровня сигнала. Схема подключения и передачи сигналов в сетях 100base-T4 показана на рис 4.1.1.2.3.

    Пары 2 и 3 также как и в ТХ предназначены для приема и передачи данных. Пары 1 и 4 используются в двух направлениях, преобразуя канал между узлом и повторителем в полудуплексную. В процессе передачи узел использует пары 1, 2 и 4, а повторитель - пары 1, 3 и 4. Следует заметить, что схема Т4, в отличие от ТХ, может работать только в полудуплексном режиме.

    Рис. 4.1.1.2.3. Схема подключения и передачи сигналов в сетях 100base-T4 (буквы К с цифрами обозначают номера контактов разъема)

    В сетях Fast Ethernet максимальное значение окна коллизий равно 5,12 мксек и называется временем канала (slot time). Это время в точности соответствует минимальной длине пакета в 64 байта. Для более короткого пакета коллизия может быть не зафиксирована. Окно коллизий представляет собой время от начала передачи первого бита кадра до потери возможности регистрации коллизии с любым узлом сегмента, это время равно удвоенной задержке распространения сигнала между узлами (RTT). Конфигурация сети Fast Ethernet, для которой значение окна коллизий превышает время канала, не верна. Время канала задает величину минимального размера кадра и максимальный диаметр сети. Для пояснения этих взаимозависимостей рассмотрим сеть, показанную на рис. 4.1.1.2.4.

    Рис. 4.1.1.2.4

    Задержка повторителя складывается из задержек физического уровня обоих портов и собственно задержки повторителя. Задержка на физическом уровне сетевого интерфейса считается равной 250 нсек. Рассмотрим задержки сигнала для всех пар узлов (a, b и c) изображенной на рисунке сети:

    a b

    250+110+700+11+250

    = 1321 нсек

    a c

    250+110+700+495+250

    = 1805 нсек

    b c

    250+11+700+495+250

    = 1706 нсек

    Когда А передает кадр, узлы В и С отслеживают наличие несущей. Это продолжается до тех пор, пока А не завершит эту процедуру. Как только узлы В и С фиксируют окончание передачи кадра узлом А, они запускают свои таймеры IPG. Запускает свой таймер ipg и узел А, причем его таймер стартует первым. На рис. 4.1.1.2.5 показана временная диаграмма развития событий в сетевом сегменте. Таймер В стартует следующим через 1321 нсек после А. Таймер узла С стартует спустя 1805 нсек после А.

    Рис. 4.1.1.2.5 Временная диаграмма, поясняющая возникновение коллизий (все времена в наносекундах)

    Узел В начинает передачу сразу после срабатывания его IPG-таймера, а через 484 наносекунды передачу начнет и узел С, так как канал с его точки зрения свободен. Но коллизии еще не происходит, так как их кадры еще не "столкнулись". Для того чтобы первый бит от узла В достиг узла С, требуется 1706 наносекунд. Узел С зарегистрирует столкновение первым, это произойдет в момент 3987нсек. После этого С будет продолжать передачу еще в течение 320 нсек (сигнал jam). Сигнал jam гарантирует регистрацию коллизии повторителем. Только спустя 484 нсек коллизию обнаружит узел В, начнет передачу своего сигнала jam после чего прекратит передачу. При этом предполагается, что jam не является контрольной суммой передаваемого пакета.

    Стандарт IEEE предусматривает возможность полнодуплексной связи при использовании скрученных пар или оптоволокна. Реализуется это путем выделения для каждого из направлений передачи независимого канала. Такая схема осуществляет связь типа точка-точка и при определенных условиях позволяет удвоить пропускную способность сети. Здесь нет нужды в стандартном механизме доступа к сетевой среде, невозможны здесь и столкновения. Дуплексную схему могут поддерживать все три модификации 100-мегагерцного Ethernet (100base-TX, 100base-T4 и 100base-FX). Для оптоволоконной версии дуплексной связи предельная длина сегмента может достигать 2 км (для полудуплексного варианта предельная длина сегмента может достигать 412 м). Следует иметь в виду, что для локальных сетей целесообразнее применение мультимодового оптоволокна (дешевле и больше коэффициент захвата света, но больше удельное поглощение).

    В настоящее время разрабатываются новые еще более скоростные варианты Ethernet IEEE 802.3z (гигабитный Ethernet утвержден в качестве стандарта в 1998 году; 1000base-FX; ftp:/stdsbbs.ieee.org/pub, смотри также www.gigabit-ethernet.org/technology/faq.html). Эти сети ориентированы на применения 4-х скрученных пар категории 5 (до 100м) и оптоволоконных кабелей. Применяется кодировка 8В/10b. Сетевые интерфейсы используют шину PCI.

    10-Гигабитный Ethernet

    Хотя Ethernet на 1 Гбит/с и не использовал все свои возможности, реализован уже 10Гбитный Ethernet (IEEE 802.3ae, 10GBase-LW или 10GBase-ER). Этот стандарт утвержден в июне 2002 года и соответствует для в случае использования для построения региональных каналов спецификациям OC-192c/SDH VC-4-46c (WAN). Опробован канал длиной 200 км с 10 сегментами. Существует серийное сетевое оборудование обеспечивающее надежную передачу на скорости 10Гбит/с при длине одномодового кабеля 10 км ( l=1310 nm). Эти данные взяты из журнала "LANline" (www.lanline.de) N7, Juli 2002. При работе с оптическими волокнами могут применяться лазеры с вертикальными резонаторами и поверхностным излучением VCSEL (Vertical Cavity Surface Emitting Laser). В случае мультимодовых вариантов используются волокна с градиентом коэффициента преломления. В протоколе 10Гбит/c Ethernet предусмотрен интерфейс chip-to-chip (802.3ae-XAUI - буквы ае означают здесь Ethernet Alliance - www.10gea.org). Такие каналы могут использоваться и в LAN для соединения переключателей сетевых кластеров. Соединение организуется по схеме точка-точка. Эта технология удобна для использования в фермах ЭВМ. Стандартизованы порты: 10Gbase-LR (до 10 км по одномодовому волокну - для высокопроизводительных магистральных и корпоративных каналов), 10Gbase-ER (до 40 км по одномодовому волокну), 10Gbase-SR (до 28 м по мультимодовому волокну - для соединений переключателей друг с другом), а также 10Gbase-LХ4 (до 300 м по мультимодовому волокну стандарта FDDI - для сетей в пределах одного здания). Обсуждается возможность построения 100Гбит/c Ethernet. В 10Gbase для локальных сетей применяется кодирование 64В/66B (вместо 8В/10B, используемого в обычном гигабитном Ethernet), так как старая схема дает 25% увеличение паразитного трафика. Следует обратить внимание, что такое решение делает непригодными существующие оптоволоконные технологии SDH/SONET. К концу 2002 года технология 10Гбит-Ethernet вторглась в область региональных (MAN; смотри форум Metro-Ethernet и EFM Task Force) и даже межрегиональных (WAN) сетей, тесня SDH, Fibre Channel, OC-192, PCI Express и InfiniBand.

    В версии 10Gbase-X4 используется кодирование 8В/10B. Там формируется 4 потока по 3,125Гбит/с, которые передаются по одному волокну (1310нм) с привлечением техники мультиплексирования длин волн (WWDM). В случае 10Gbase-W на уровне МАС вводится большая минимальная длина IPG.

    Рис. 4.1.1.2.6. Схема уровней для 10Gbase Ethernet

    • MDI Medium Dependent Interface
    • XGMII 10 Gigabit Media Independent Interface
    • PCS Physical Coding Sublayer
    • PMA Physical Medium Attachment
    • PMD Physical Medium Dependent
    • WIS WAN Interface Sublayer

    Таблица 4.1.1.2.5. Классификация категорий оптических волокон для сетевых приложений (данные взяты из журнала "LAN line Special" за июль-август 2002 года; www.lanline.de). Согласно принятым сокращениям буквы в конце обозначения канала (например, 10Gbase-LX) характеризуют оптическое волокно [E - Extended (для WAN или MAN, длина волны 1550нм), L - Long (для расстояний <10км при длине волны 1310нм, возможен вариант с многомодовым волокном длиной до 300м и привлечением техники WWDM) и S - Short (для расстояний менее 35 м при длине волны 850нм; для волокон с 160 МГц*км длина <28м, а для 200МГц*км < 35м)] и тип кодирования (R, W или X).

    Тип сети

    Потери ввода (дБ)

    Канал ISO/IEC 11801на основе

     

     

    Много-
    мод

    Одно-
    мод
    a

    Волокна ОМ1

    Волокна ОМ2

    Волокна ОМ3

    Волокно ОS1

     

    850 нм

    1300 нм

    1300 нм

    850 нм

    1300 нм

    850 нм

    1300 нм

    850 нм

    1300 нм

    1300 нм

    1500 нм

    ISO/IEC 8802-3:
    10Base-FL, FPb & FBf

    12,5(6,8)

    -

    -

    OF-2000

     

    OF-2000

     

    OF-2000

     

     

     

    ISO/IEC TR 11802-4:
    4 & 16 Мбит/c, Token Ringf

    13,0(8,0)

    -

    -

    OF-2000

     

    OF-2000

     

    OF-2000

     

     

     

    ATM @ 52 Мбит/cg

    NA

    10,0(5,3)

    10.0

     

    OF-2000

     

    OF-2000

     

    OF-2000

    OF-2000

     

    ATM @ 155 Мбит/cg

    7,2

    10,0(5,3)

    7.0

    OF-500

    OF-2000

    OF-500

    OF-2000

    OF-500

    OF-2000

    OF-2000

     

    ATM @ 622 Мбит/ce,f,g

    4.0

    6,0(2,0)

    7,0

    OF-300

    OF-500

    OF-300

    OF-500

    OF-300

    OF-500

    OF-2000

     

    ISO/IEC 14165-111:
    Fibre Channel (FC-PH)@ 133Мбит/cc,f

    NA

    6,0

     

     

    OF-2000

     

    OF-2000

     

    OF-2000

     

     

    ISO/IEC 14165-111:
    Fibre Channel (FC-PH)@ 266Мбит/cc,g

    12.0

    6,0(5.5)

    6.0

    OF-2000

    OF-2000

    OF-2000

    OF-2000

    OF-2000

    OF-2000

    OF-2000

     

    ISO/IEC 14165-111:
    Fibre Channel (FC-PH)@ 531Мбит/cc,g

    8.0

    -

    14.0

    OF-500

     

    OF-500

     

    OF-500

     

    OF-2000

     

    ISO/IEC 14165-111:
    Fibre Channel (FC-PH)@ 1062Мбит/ce,g

    4.0

    -

    6.0

    OF-300

     

    OF-500

     

    OF-500

     

    OF-2000

     

    ISO/IEC 8802-3: 1000Base-SXe

    2.6(3.56)

    -

    -

     

     

    OF-500

     

    OF-500

     

     

     

    ISO/IEC 8802-3: 1000Base-LXe,g

    -

    2.35

    4.56

     

    OF-500

     

    OF-500

     

    OF-500

    OF-2000

     

    ISO/IEC 9314-9: FDDI LCF-PMDb,f

    -

    7.0(2.0)

    -

     

    OF-500

     

    OF-500

     

    OF-500

     

     

    ISO/IEC 9314-3: FDDI PMDf

    -

    11.0(6.0)

    -

     

    OF-2000

     

    OF-2000

     

    OF-2000

     

     

    ISO/IEC 9314-3: FDDI SMF-PMDg

    -

    -

    10.0

     

     

     

     

     

     

    OF-2000

     

    ISO/IEC 8802-3: 100BASE-FXf

     

    11.0(6.0)

    -

     

    OF-2000

     

    OF-2000

     

    OF-2000

     

     

    IEEE 802.3: 10GBASE-LX4d

     

    2.0

    6.2

     

    OF-300

     

    OF-300

     

    OF-300

    OF-2000

     

    IEEE 802.3: 10GBASE-ER/EWd

     

     

     

     

     

     

     

     

     

     

    OF-2000

    IEEE 802.3: 10GBASE-SR/SWd

    1.6(62.5)
    1.8(OM-2)
    2.6(OM-3)

    -

    -

     

     

     

     

    OF-300

     

     

     

    IEEE 802.3: 10GBASE-LR/LWd,g

    -

    -

    6.2

     

     

     

     

     

     

    OF-2000

     

    1. Представлены значения для волокон с диаметрами 62.5/125 и 50/125 m(MMF). Там, где значения отличаются, в скобках дается величина для 50 мкм.
    2. Приложение в настоящее время промышленностью не поддерживается
    3. Приложение в настоящее время не поддерживается разрабатывавшей его группой
    4. Приложение в стадии разработки
    5. Приложение с ограниченной полосой пропускания для указанных длин канала. Использование для каналов с более высокими требованиями в случае применения компонентов с меньшим ослаблением, не рекомендуется.
    6. Длина канала может быть ограничена для волокон с диаметром 50 мкм.
    7. Длина канала для одномодового волокна может быть больше, но это находится вне пределов регламентаций стандарта.

    Таблица 4.1.1.2.6. Максимальные длины каналов с мультимодовыми волокнами

    Сетевое приложение

    Номинальная длина
    волны [нм]

    Максимальная длина канала в м

    Волокно 50мкмa

    Волокно 62,5мкм;b

    ISO/IEC 8802-3: FOIRL

    850

    514

    1000

    ISO/IEC 8802-3: 10BASE-FL&FB

    850

    1514

    2000

    ISO/IEC TR 11802-4: 4 &16Мбит/c Token Ring

    850

    1857

    2000

    ATM @ 155 Мбит/c

    850

    1000a

    1000b

    ATM @ 622 Мбит/c

    850

    300a

    300b

    ISO/IEC 14165-111: Fibre Channel (FC-PH) @ 266 Мбит/c

    850

    2000

    700

    ISO/IEC 14165-111: Fibre Channel (FC-PH) @ 531 Мбит/c

    850

    1000

    350

    ISO/IEC 14165-111: Fibre Channel (FC-PH) @ 1062 Мбит/cc

    850

    500a

    350b

    IEEE 802.3: 1000BASE-SX

    850

    550a

    275b

    ISO/IEC 9314-9: FDDI LCF-PMD

    1300

    500

    500

    ISO/IEC 9314-3: FDDI PMD

    1300

    2000

    2000

    ISO/IEC 8802-3: 100BASE-FX

    1300

    2000

    2000

    IEEE 802.5t: 100Мбит/c Token Ring

    1300

    2000

    2000

    ATM @ 52 Мбит/c

    1300

    2000

    2000

    ATM @ 155 Мбит/c

    1000

    2000

    2000

    ATM @ 622 Мбит/c

    1300

    330

    500

    ISO/IEC 14165-111: Fibre Channel (FC-PH) @ 133 Мбит/c

    1300

    Не поддерживается

    1500

    ISO/IEC 14165-111: Fibre Channel (FC-PH) @ 266 Мбит/c

    1300

    2000

    1500

    IEEE 802.3: 1000BASE-LXc

    1300

    550a

    550b

    1. Максимальное ослабление на км (850/130нм): 3.5/1.5 дБ/км; минимальная полоса пропускания для длин волн (850/130нм): 500МГцкм
    2. Максимальное ослабление на км (850/130нм): 3.5/1.5 дБ/км; минимальная полоса пропускания для длин волн (850/130нм): 200МГцкм/500МГцкм
    3. Эти приложения ограничены по полосе. Использование компонентов с меньшим поглощением для получения каналов с улучшенными параметрами, не рекомендуется.

    Всякая, даже гигантская сеть была когда-то маленькой. Обычно сеть начинается с одного сегмента типа 1, 3 или 4 (рис. 4.1.1.2.1). Когда ресурсы одного сегмента или концентратора (повторители для скрученных пар) исчерпаны, добавляется повторитель. Так продолжается до тех пор, пока ресурсы удлинения сегментов и каналы концентраторов закончатся и будет достигнуто предельное число повторителей в сети (4 для 10МГц-ного Ethernet). Если при построении сети длина кабельных сегментов и их качество не контролировалось, возможен и худший сценарий - резкое увеличение числа столкновений или вообще самопроизвольное отключение от сети некоторых ЭВМ. Когда это произошло, администратор сети должен понять, что время дешевого развития сети закончилось - надо думать о приобретении мостов, сетевых переключателей, маршрутизаторов, а возможно и диагностического оборудования. Применение этих устройств может решить и проблему загрузки некоторых сегментов, ведь в пределах одного логического сегмента потоки, создаваемые каждым сервером или обычной ЭВМ, суммируются. Не исключено, что именно в этот момент сетевой администратор заметит, что топология сети неудачна и ее нужно изменить. Чтобы этого не произошло, рекомендуется с самого начала тщательно документировать все элементы (кабельные сегменты, интерфейсы, повторители и пр.). Хорошо, если уже на первом этапе вы хорошо представляете конечную цель и те возможности, которыми располагаете. Бухгалтерская сеть и сеть, ориентированная на выход в Интернет, будут иметь разные структуры. Прокладывая кабели, рекомендуется учитывать, что положение ЭВМ время от времени меняется, и это не должно приводить к изменению длины сегмента или к появлению дополнительных "сросток". Следует также избегать применения в пределах сегмента кабелей разного типа и разных производителей. Если сеть уже создана, научитесь измерять информационные потоки в сегментах и внешние потоки (если ваша сеть соединена с другими сетями, например с Интернет), это позволит осмысленно намечать пути дальнейшей эволюции сети. Если возможности позволяют, избегайте использования дешевых сетевых интерфейсов, их параметры часто не отвечают требованиям стандарта. Сетевая архитектура требует немалых знаний и это дело лучше поручить профессионалам.

    Когда потоки данных в сети достигают уровня, при котором использование мостов и сетевых переключателей уже недостаточно, можно подумать о внедрении маршрутизаторов или оптоволоконных сегментов сети FDDI или быстрого (100 Мбит/с) Ethernet. Эти субсети будут играть роль магистралей, по которым идет основной поток данных, ответвляясь в нужных местах в субсети, построенные по традиционной технологии (см. раздел FDDI). Сеть FDDI для этих целей предпочтительнее, так как она не страдает от столкновений и у нее не падает пропускная способность при перегрузке. Если в вашей сети имеются серверы общего пользования, их рекомендуется подключить к быстродействующим сегментам и организовать несколько узлов доступа к FDDI-кольцу. Остальные потребители будут соединены с FDDI через эти узлы доступа (мосты/шлюзы). Аналогичную функцию могут выполнять и сегменты быстрого Ethernet (особенно хороши для этого схемы дуплексного обмена, см. выше).

    Особую проблему составляют переходы 100 Мбит/с 10 Мбит/с (рис. 4.1.1.2.7). Дело в том, что на MAC-уровне нет механизмов понижения скорости передачи для согласования возможностей отправителя и приемника. Такие возможности существуют только на IP-уровне (ICMP-congestion). Если функцию шлюза исполняет, например, переключатель, то исключить переполнение его буфера невозможно. Такое переполнение неизбежно приведет к потере пакетов, повторным передачам и, как следствие, к потере эффективной пропускной способности канала. Решить проблему может применение в качестве шлюза маршрутизатора (здесь работает ICMP-механизм "обратного давления").

    Рис. 4.1.1.2.7 Схема переходов 10-100-10 Мбит/с

    Если любые 2 или более каналов справа попытаются начать работу с одним из каналов слева, или наоборот, потери пакетов неизбежны. Проблема исчезает, когда SW работают на IP-уровне.

    Previous: 4.1.1.1 Архитектура сетей Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.1.3 Интернет в Ethernet


    previous up down next index index
    Previous: 4.1.1.2 Fast Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы

    4.1.1.3 Интернет в Ethernet
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В Интернет не существует иерархии сетей. Локальная сеть на основе Ethernet, две ЭВМ, связанные через последовательный интерфейс, или общенациональная сеть страны - это все сети и по логике Интернет они все равны. Каждая сеть имеет свое имя и как минимум один IP-адрес. Имя привычнее для людей, адреса - для машин. Между именами и адресами существует строгое соответствие.

    Для того чтобы пояснить взаимодействие различных систем в сети, рассмотрим сильно упрощенную схему обработки команды telnet vxdesy.desy.de, которая предполагает осуществление удаленного доступа к vx-кластеру в ДЕЗИ, Гамбург (вызов через windows обрабатывается практически аналогично). Сначала ЭВМ выделяет команду telnet и запускает соответствующую программу. Эта программа рассматривает символьный адрес vxdesy.desy.de в качестве параметра команды telnet.

    Рис. 4.1.1.3.1. Схема обработки сетевого запроса

    Сначала определим, что же нужно сделать для решения стоящей задачи? Чтобы обратиться к нужной ЭВМ, система должна знать ее IP-адрес, маску субсети и адрес маршрутизатора или ЭВМ, через которые можно обратиться с запросом на установление канала связи. Рассмотрим решение проблемы поэтапно. Сначала символьный адрес vxdesy.desy.de пересылается серверу имен (DNS-система может располагаться как в ЭВМ пользователя, так и в другой машине), где преобразуется в цифровой IP-адрес, пересылаемый в отклике на DNS-запрос (предварительно надо узнать его MAC-адрес). Но знания IP-адреса недостаточно, надо выяснить, где находится объект с этим адресом. На IP-адрес накладывается сетевая маска (задается при конфигурации рабочей станции), чтобы определить, не является ли данный адрес локальным. Если адрес локален, IP-адрес должен быть преобразован в Ethernet-адрес (MAC), ведь ваша ЭВМ может оперировать только с Ethernet-адресами. Для решения этой задачи посылается широковещательный (обращенный ко всем участникам локальной сети) ARP-запрос. Если адресат находится в пределах локальной субсети, то он откликнется, прислав Ethernet-адрес своей сетевой карты. Если это не так, что имеет место в приведенном примере, присылается Ethernet-адрес пограничного для данной сети маршрутизатора. Это происходит лишь в случае, если он поддерживает режим proxy-ARP. В противном случае рабочая станция должна воспользоваться IP-адресом маршрутизатора (gateway), заданным при ее конфигурации, и выявить его MAC-адрес с помощью ARP-запроса. Наконец с использованием полученного IP-адреса программа telnet формирует IP-пакет, который вкладывается в Ethernet-кадр и посылается в маршрутизатор узла (ведь именно его адрес она получила в ответ на ARP-запрос в данном примере). Последний анализирует имеющиеся у него маршрутные таблицы и выбирает, по какому из нескольких возможных путей послать указанный пакет. Если адресат внешний, IP-дейтограмма вкладывается в PPP- FDDI- или какой-то другой кадр (зависит от протокола внешнего канала) и отправляется по каналам Интернет. В реальной жизни все бывает сложней. Во-первых, присланный символьный адрес может быть неизвестен локальной dns-системе (серверу имен) и она вынуждена посылать запросы вышестоящим DNS-серверам, во-вторых, пограничный маршрутизатор вашей автономной системы может быть непосредственно не доступен (ваша ЭВМ находится, например, в удаленной субсети) и т.д. и т.п. Как система выпутывается из подобных осложнений, будет описано позднее. Следует иметь в виду, что, например, в системе unix все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (Telnet, FTP, Finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов (см. раздел 7). Ну а теперь начнем с фундаментальных положений Интернет.

    В Интернет информация и команды передаются в виде пакетов, содержащих как исходящий адрес, так и адрес места назначения (IP-адрес имеет 32 двоичных разряда). Каждой ЭВМ в сети поставлен в соответствие уникальный адрес, появление двух объектов с идентичными IP-адресами может дезорганизовать сеть. IP-адресация поддерживает пять различных классов сетей (практически используется только три) и, соответственно, адресов (версия IPv4). Класс А предназначен в основном для небольшого числа очень больших сетей. Здесь для кода сети выделено только 7 бит, это означает, что таких сетей в мире не может быть больше 127 (27-1). Класс B выделяет 14 бит для кода сети, а класс С - 22 бита. В классе C для кода ЭВМ (host) предназначено 8 бит, поэтому число ЭВМ в сети ограничено. Самые левые биты адреса предназначены для кода класса. ip-адрес характеризует точку подключения машины к сети. Поэтому, если ЭВМ перенесена в другую сеть, ее адрес должен быть изменен. Старшие биты адреса определяют номер подсети, остальные биты задают номер узла (номер ЭВМ). В таблице 4.1.1.3.1 приведено соответствие классов адресов значениям первого октета адреса и указано количество возможных IP-адресов каждого класса.

    Таблица. 4.1.1.3.1 Характеристики классов адресов

    Класс адреса

    Диапазон значений первого октета

    Возможное количество сетей

    Возможное количество
    узлов

    A

    001 ... 126

    128

    16777214

    B

    128 ... 191

    16382

    65534

    C

    192 ... 223

    2097150

    254

    D

    224 ... 239

    228

    E

    240 ... 247

    227

    Структура ip-адресов изображена на рисунке 4.1.1.3.2:

    Рис. 4.1.1.3.2. Структура IP-адресов (NetID = идентификатор сети)

    Для удобства чтения IP-адреса обычно записываются в десятично-точечной нотации, например: 192.148.166.129 (адрес класса C).

    Классу A соответствует диапазон адресов 1.0.0.0 - 127.255.255.255.
    Классу B соответствует диапазон адресов 128.0.0.0 - 191.255.255.255.
    Классу С соответствует диапазон адресов 192.0.0.0 - 223.255.255.255.
    Классу D соответствует диапазон адресов 224.0.0.0 - 239.255.255.255.
    Классу E соответствует диапазон адресов 240.0.0.0 - 247.255.255.255.

    Ряд адресов является выделенными для специальных целей:

    0.0.0.0 - обращение к ЭВМ, на которой производится работа;
    255.255.255.255 - обращение ко всем машинам локальной сети.
    127.xxx.xxx.xxx - помещение пакета во входной поток данной ЭВМ (loopback).
    Два другие специальные адреса показаны на рис. 4.1.1.3.2.а.

    Рис. 4.1.1.3.2.а. Специальные ip-адреса

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

    Рис. 4.1.1.3.3. Локальная часть IP-адреса

    Такая схема обеспечивает необходимую гибкость, дает возможность разделить локальную сеть на субсети. При работе с субсетью необходимо использовать 32-разрядную маску. Разряды маски должны равняться 1, если сеть рассматривает данный бит как часть адреса сети, и 0, если он характеризует адрес ЭВМ в этой сети. Например:

    255.255.255.254 (десятично-точечное представление)

    11111111 11111111 11111111 11111110 (двоичное представление)

    описывает маску субсети, в которой работает автор. Некоторую информацию о масках в работающей сети можно получить с помощью команды ifconfig (SUN):

    /usr/etc/ifconfig -a (курсивом здесь и далее выделяются команды, введенные с клавиатуры)

    le0: flags=863

    inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32

    lo0: flags=869

    inet 127.0.0.1 netmask ffffff00,

    где le0 и lo0 - имена интерфейсов, флаг -a предполагает выдачу данных обо всех интерфейсах.

    Во всех схемах IP-адресации адрес со всеми единицами в секции адрес ЭВМ (host) означает широковещательное обращение ко всем ЭВМ сети. Следует помнить, что широковещательные запросы сильно перегружают сеть, и без особой необходимости их использовать не следует. В настоящее время обсуждаются четыре предложения усовершенствования IP-адресации (см. RFC-1454):

    IP-адрес безусловно удобный для использования ЭВМ, почему-то плохо запоминается людьми, поэтому они разработали символьную систему имен для узлов Интернет. Эта система (DNS- domain name system) имеет иерархический характер. Имя содержит несколько полей, разделенных символом "." (точка). В качестве примера можно привести имя домена itepnet - cl.itep.ru. Это имя содержит три поля. Поле ru указывает на принадлежность данного домена России, поле itep определяет принадлежность узла ITEP (Institute for Theoretical and Experimental Physics), cl - характеризует то, что данное конкретное имя относится к кластеру ЭВМ (имя субдомена). Никаких ограничений на число полей в имени, кроме налагаемых здравым смыслом, не существует. Собственно имя домена - это itep.ru. Самое правое поле в имени домена характеризует принадлежность к определенному типу организации или стране. Таблица стандартизованных имен приведена в приложении Национальные коды . Преобразование символьного имени в IP-адрес производится в DNS-сервере узла, который представляет собой базу данных с удаленным доступом. Если искомое имя узла в локальном DNS-сервере отсутствует, он может прислать в качестве ответа адрес другого DNS-сервера, куда следует обратиться, чтобы определить IP-адрес искомого узла. Анализ имени обычно производится справа налево. Более подробно DNS-система описана в документах RFC-822, -823, а также ниже в разделе DNS. О правилах получения IP-адресов и регистрации имен сетей можно прочесть в [8].

    При формировании пакетов различного уровня используется принцип инкапсуляции (вложения). Так IP-пакеты вкладываются в Ethernet-пакеты (кадры). Всякий пакет имеет заголовок и тело, некоторые из них снабжены контрольной суммой. Схема такого вложения представлена на рисунках 4.1.1.3.4 и 4.1.1.3.5.

    Поле тип определяет используемый в дейтограмме протокол, PAD - пустые биты, дополняющие размер дейтограммы до 48 бит. В случае протокола IEEE 802.3 полю тип (>150010) соответствует поле длина (<150010), которое определяет длину кадра.

    Пакетный принцип позволяет передавать информацию от разных источников к различным адресатам по общему телекоммуникационному каналу. Схема вложения пакетов в рамках TCP/IP показана на рис. 4.1.1.3.4.

    Принцип вложения (также как и фрагментации) является фундаментальным для любых современных сетей. Этот принцип используется в сетях netware, Apple Talk, TCP/IP т.д.

    Рис. 4.1.1.3.4. cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код 0800)

    Отдельные сети в Интернет соединяются друг с другом через узловые серверы (gateway, их иногда называют пограничными маршрутизаторами - boarder gateway), расстояние между которыми может измеряться метрами или тысячами километров. В межсетевых обменах также используется принцип вложения так пакеты Ethernet могут вкладываться в пакеты FDDI и т.д..

    Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше работают только с ip-адресами, в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса).

    Обычно при описании сетей используется терминология 7-уровневой модели ISO ("стек протоколов"). Так уж получилось, но Интернет лишь с определенными натяжками можно описать, придерживаясь этой схемы.

    Ethernet инкапсуляция (RFC 894) (размеры полей указаны в байтах)

    Рис. 4.1.1.3.5. Вложение пакетов Интернет в Ethernet- и IEEE 802 пакеты

    LLC - управление логической связью (logical link control); DSAP = 0xaa (destination service access point) - поле адреса доступа к службе получателя; SSAP = 0xaa (source service access point) - поле адреса доступа к службе отправителя; SNAP - протокол доступа к субсетям (subnetwork access protocol). PAD - поле заполнитель. В общем случае форматы полей DSAP и SSAP имеют вид, показанный на рис. 4.1.1.3.6 I/G = 0 - индивидуальный адрес, I/G =1 - групповой адрес; D - бит адреса службы места назначения, S - бит адреса службы отправителя; C/R =0 - команда, C/R =1 - подтверждение.

    Рис. 4.1.1.3.6. Структура адресов DSAP и SSAP

    Поле CNTL может иметь длину 1 или 2 байта, а его структура соответствовать I, S или U-форматам (см. разделы "Эталонная модель iso" и "x.25"). В однобайтовых полях DSAP и SSAP записывается код типа протокола сетевого уровня. Для протоколов IPX/SPX это и последующее поле содержат код 0xE0. Поле CNTL=03 обозначает нечисловой формат для уровня ethernet 802.2. Эти три байта часто представляют собой код производителя, как правило, совпадающий с первыми тремя байтами адреса отправителя. Иногда они просто делаются равными нулю. Поле тип (2 байта) характеризует используемую версию Ethernet. Из рисунка 4.1.1.3.5 видно, что первые два поля (адреса получателя и отправителя) и последнее поле (CRC) во всех форматах идентичны. При расчете CRC содержимое кадра рассматривается как двоичный полином. Производится деление этого кода на специальный образующий полином. Полученный остаток от деления дополняется по модулю один, результирующий код и считается контрольной суммой CRC. В поле адрес получателя может быть записан код 0xffffffffffff, что указывает на широковещательную адресацию кадра. Адрес отправителя такой код содержать не может. Третье поле может служить для выявления типа используемого протокола. Если в этом поле содержится число более 1500 (десятичное), это указывает на то, что данный кадр имеет формат Ethernet II, а само поле содержит не длину кадра а тип данных. Теперь, надеюсь, читателю понятно, почему кадр Ethernet 802.3 не может содержать более 1500 байт.

    Кадр Ethernet 802.2 помимо первых трех полей содержит дополнительные три однобайтовые поля, следующие вслед за ними (DSAP, SSAP и CNTL). Кадр Ethernet SNAP является модификацией кадра Ethernet 802.2. Для этого кадра коды полей dsap и ssap равны 0xAA (признак кадра Ethernet SNAP), код CNTL=03 (нечисловой формат), поле код организации (3 байта, характеризует организацию сети) равен нулю (для IPX/SPX), а двухбайтовое поле тип характеризует протокол высокого уровня. Для протоколов IPX/SPX в этом поле должен быть записан код 0x8138 (для ip - 0x0800, для arp - 0x0806, для rarp - 0x8035, а для Apple Talk - 0x809b). Таблица кодов протоколов приведена в приложении Базовые протоколы Интернет (см. также RFC-1700). Поля тип протокола и по смыслу и по содержанию идентичны для всех разновидностей кадра Ethernet (кроме ieee 802.3).

    Транспортный уровень должен воспринимать данные от нескольких пользовательских программ и пересылать их на более низкий уровень. Многоуровневые протоколы спроектированы так, чтобы слой N по месту назначения получал ту же самую информацию, что была послана слоем N отправителя. Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше использует только IP-адреса (32 бита), в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса).

    Когда IP-дейтограмма попадает в ЭВМ, сетевое программное обеспечение передает ее программе IP-уровня. Если адрес места назначения совпадает с IP-адресом ЭВМ, дейтограмма принимается и передается на более высокий уровень для дальнейшей обработки. При несовпадении адресов дейтограмма уничтожается (переадресация дейтограмм для ЭВМ запрещена, это функция маршрутизатора). Хотя можно заставить ЭВМ выполнять задачи маршрутизации, с точки зрения Интернет-философии это плохая идея.

    Различные сети и каналы имеют разные скорости обмена и надежность передачи. Это определяет длину пакета, пересылка которого с высокой вероятностью будет осуществлена без ошибки. Так как Интернет объединяет самые разные узлы и сети, использующие разные длины посылок, при реализации связи между такими объектами размер пакета задается наименее надежным узлом и длина пакета выбирается минимальной из двух. Поэтому при передаче длинного пакета через такой участок сети он сегментируется и передается по частям. Размер фрагмента определяется величиной максимального передаваемого блока (MTU - maximum transfer unit, в Ethernet MTU=1500 октетам). Величины MTU для других сред приведены в таблице 4.1.1.3.2:

    Таблица 4.1.1.3.2 Значения mtu для различных сетевых стандартов

    Сеть

    MTU (байт)

    hyperchannel (Сеть с топологией типа шина, с csma/cd-доступом, числом подключений < 256, максимальной длиной сети около 3,5км (93-омный коаксиальный кабель rg59 или оптоволокно))

    65535

    16 Мбит/с маркерное кольцо (ibm)

    17914

    4 Мбит/с маркерное кольцо (ieee 802.5)

    4464

    fddi

    4352

    Ethernet II

    1500

    IEEE 802.3/802.2

    1492

    x.25

    576

    point-to-point (при малой задержке)

    296

    Рассмотрим по фрагментную передачу дейтограммы с длиной в 1300 октетов в предположении, что более 576 октетов за один раз передать нельзя.

    Рис. 4.1.1.3.6. Пример фрагментации пакета

    Куда будет направлен Ethernet-кадр, указывает значение для типа в заголовке кадра (рис. 4.1.1.3.5). Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP (Transmission Control Protocol), либо UDP, что определяется полем "протокол" в заголовке IP-пакета.

    Одним из основополагающих понятий в теории маршрутизации является автономная система (AS). Автономную систему составляет IP-сеть (или система из нескольких IP-сетей), проводящая единую политику внешней маршрутизации и имеющая одного или более операторов. Все AS имеют уникальные номера. Идеология AS позволяет решить проблему безудержного роста размера таблиц маршрутизации. Построение узла Интернет неотделимо от формирования локальной сети, поэтому прежде чем перейти к углубленному описанию протоколов TCP/IP, введем определения некоторых сетевых устройств, без которых построение локальной сети невозможно.

    Previous: 4.1.1.2 Fast Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы


    previous up down next index index
    Previous: 4.1.1.3 Интернет в Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.2 IEEE 802.5 (Token Ring)

    4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    На физическом уровне пакет представляет собой цуг импульсов, распространяющихся по коаксиальному кабелю, скрученной паре или оптическому волокну. За счет дисперсии, частичным отражениям от точек подключения и поглощению в среде импульсы в пакете "расплываются" и искажаются (ухудшается отношение сигнал/шум), это является одной из причин ограничения длин кабельных сегментов. Для преодоления этих ограничений вводятся сетевые повторители (repeater). Повторитель воспринимает входные импульсы, удаляет шумовые сигналы и передает вновь сформированные пакеты в следующий кабельный сегмент или сегменты. Никакого редактирования или анализа поступающих данных не производится. Задержка сигнала повторителем не должна превышать 7,5 тактов (750нсек для обычного Ethernet). Повторители могут иметь коаксиальные входы/выходы, AUI-разъемы для подключения трансиверов или других аналогичных устройств, или каналы для работы со скрученными парами.

    Рис. 4.1.1.4.1 Схема сетевого повторителя

    Все входы/выходы повторителя с точки зрения пакетов эквивалентны. Если повторитель многовходовый, то пакет пришедший по любому из входов будет ретранслирован на все остальные входы/выходы повторителя. Чем больше кабельных сегментов объединено повторителями, тем больше загрузка всех сегментов. При объединении нескольких сегментов с помощью повторителя загрузка каждого из них становится равной сумме всех загрузок до объединения. Это справедливо как для коаксиальных кабельных сегментов, так и для повторителей, работающих со скрученными парами (хабы - концентраторы). Некоторые повторители контролируют наличие связи между портом и узлом (link status), регистрируют коллизии и затянувшиеся передачи (jabber - узел осуществляет передачу дольше, чем это предусмотрено протоколом), выполняют согласование типа соединения (autonegotiation). В этом случае они обычно снабжены SNMP-поддержкой.

    Для преодоления этого нежелательного явления используются сетевые мосты или переключатели. Мост соединяет два сегмента сети, при инициализации он изучает списки адресов устройств, подсоединенных к каждому из сегментов. В дальнейшем мост записывает в свою память эти списки и пропускает из сегмента в сегмент лишь транзитные пакеты. Существуют мосты, которые оперируют с физическими и с IP-адресами (cм. стандарт IEEE 802.1d).

    Рис. 4.1.1.4.2. Схема сетевого моста

    Мост является активным устройством, которое способно адаптироваться к изменениям в окружающей сетевой среде. При этом пакеты, отправленные из сегмента А и адресованные устройству, которое подключено к этому же сегменту, никогда не попадут в сегмент Б и наоборот. Через мост проходят лишь пакета, отправленные из сети А в Б или из Б в А.

    Функцию моста с определенными скоростными ограничениями может выполнять и обычная ЭВМ, имеющая два сетевых интерфейса и соответствующее программное обеспечение. Мосты при разумном перераспределении серверов и рабочих станций по сетевым сегментам позволяют выровнять и даже эффективно снизить среднюю сетевую загрузку. Когда на один из входов моста приходит пакет, производится сравнение адреса получателя с содержимым внутренней базы данных. Если адрес в базе данных отсутствует, мост посылает широковещательный запрос в порт, противоположный тому, откуда получен данный пакет с целью выяснения местоположения адресата. Понятно, что появление в субсетях a и Б двух объектов с идентичными адресами ни к чему хорошему не приведет. При поступлении отклика вносится соответствующая запись в базу данных. Параллельно анализируется и адрес отправителя и, если этот адрес в базе данных отсутствует, производится его запись в банк адресов соответствующего порта. В базу данных записывается также время записи адреса в базу данных. Содержимое базы данных периодически обновляется. К любой подсети может вести несколько путей, но для нормальной работы мостов и переключателей все пути кроме одного должны быть заблокированы. Функциональная схема работы моста показана на рис. 4.1.1.4.3. Сети, между которыми включается мост, не обязательно должны работать согласно идентичным протоколам. Возможны мосты между Ethernet и Token Ring или между Ethernet и ATM.

    Рис. 4.1.1.4.3 Блок-схема работы сетевого моста

    Мост, имеющий более двух портов, называется переключателем. Первый переключатель был разработан фирмой Калпане в 1991 году. Иногда переключатели называются маршрутизаторами, тем более что некоторые из них поддерживают внутренние протоколы маршрутизации (например, RIP). Переключатели имеют внутреннюю параллельную магистраль очень высокого быстродействия (от десятков мегабайт до гигабайт в сек.). Эта магистраль позволяет переключателю совместить преимущества повторителя (быстродействие) и моста (разделение информационных потоков) в одном устройстве. Схемы реализации переключателей варьируются значительно, каких-либо единых стандартов не существует. Алгоритм работы с адресами здесь тот же, что и в случае мостов. На рис. 4.1.1.4.4 приведена схема 8-входового переключателя. В переключателе все входы идентичны, но внешняя информация, записанная в их память, делает входы неэквивалентными. Определенные проблемы возникают, когда к одному из входов переключателя подключен сервер, с которым работают пользователи подключенные к остальным входам. Если все ЭВМ, подключенные к переключателю, одновременно попытаются обратиться к серверу, переключатель перегрузится и все каналы будут на некоторое время блокированы (будет послан сигнал перегрузки - jam). При данной схеме вероятность таких событий значительна, так как несколько каналов с пропускной способностью 10 Мбит/с работают на один общий канал с той же полосой пропускания. Для преодоления проблем этого рода следует распределять нагрузки между портами переключателя равномерно, а также подключать серверы через полнодуплексные каналы. Полнодуплексные каналы полезны и для соединения переключателей между собой. Современные переключатели имеют много различных возможностей - SNMP поддержка, автоматическая настройка быстродействия и определения типа соединения (дуплексная/полудуплексная). Имеется возможность внешней загрузки программы работа переключателя. Способы проверки производительности переключателей описаны в документах RFC-1242 и RFC-1944 (тесты Бреднера, см. www.wiley.com/compbooks/fastethernet и www.tolly.com).

    Рис. 4.1.1.4.4. Схема 8-входового сетевого переключателя

    Существуют переключатели, работающие в режиме "на пролет" (cut through). Здесь первые биты пакета поступают на выход переключателя, когда последующие еще только приходят на вход. Задержка в этом случае минимальна, но переключатель пропускает через себя пакеты, поврежденные в результате столкновений. Альтернативой такому режиму является передача через буферную память (схема передачи SAF - Store And Forward). Поврежденные пакеты в этом режиме отбрасываются, но задержка заметно возрастает. Кроме того, буферная память должна иметься на всех входах (или общая многопортовая). При проектировании сетей следует иметь в виду, что переключатели превосходят маршрутизаторы по соотношению производительность/цена.

    При проектировании локальной сети следует учитывать то обстоятельство, что узлы с самым напряженным трафиком должны располагаться как можно ближе к повторителю (мосту или переключателю). В этом случае среднее число коллизий в единицу времени будет ниже. По этой причине сервер должен располагаться как можно ближе к повторителю или другому сетевому устройству (см. рис. 4.1.1.4.6).

    Схема внутренних связей переключателя может отличаться от приведенной на рис. 4.1.1.4.4 и иметь конфигурацию, показанную на рис. 4.1.1.4.5. Привлекательность такой схемы заключается в возможности реализации обмена по двум непересекающимся направлениям одновременно (См. LAN. Журнал сетевых решений, май 1998, том 4, N5, стр 21. Дмитрий Ганжа). От разделяемых к коммутируемым сетям). При этом эффективная пропускная способность многопортового переключателя может в несколько раз превосходить полосу пропускания сети, например, 10 Мбит/с.

    Рис. 4.1.1.4.5. Вариант схемы внутренних связей переключателя.

    Рис. 4.1.1.4.6 Схема подключения сервера к переключателю

    При использовании в сети большого числа мостов и/или переключателей может сформироваться топология связей, когда от одного сегмента к другому пакет может попасть более чем одним путем (см. рис. 4.1.1.4.7). Приведенная на рисунке схема неработоспособна и некоторые связи должны быть ликвидированы. В данном примере проблема может быть решена удалением мостов BR-2 и BR-3 или разрывом связей, помеченных символом "X".

    Проблему ликвидации связей, способных привести к зацикливанию, решает протокол STP (Spanning Tree Protocol; алгоритм предложен Пёлманом в 1992 году), который автоматически блокирует некоторые соединения, а в случае недоступности основного пути открывает эти заблокированные соединения, обеспечивая высокую надежность сети. STP является частью протокола мостов IEEE 802.1d.

    При использовании протокола STP каждой связи присваивается при конфигурации определенный вес (чем меньше, тем выше приоритет). Мосты периодически рассылают специальные сообщения (BPDU - Bridge Protocol Data Unit), которые содержат коды их уникальных идентификаторов, присвоенные им при изготовлении. Мост или переключатель с наименьшим значением такого кода становится корневым ("корень дерева"). Затем выявляется наикратчайшее расстояние от корневого моста/переключателя до любого другого моста в сети. Граф, описывающий дерево наикратчайших связей, и является "расширяющимся деревом". Такое дерево включает все узлы сети, но необязательно все мосты/переключатели. Этот алгоритм функционирует постоянно, отслеживая все топологические изменения.

    Современные мосты позволяют создавать виртуальные субсети (VLAN), увеличивающие сетевую безопасность. VLAN позволяет ограничить зону распространения широковещательных пакетов, улучшая эксплуатационные характеристики сети в целом.

    Рис. 4.1.1.4.7. Пример реализации алгоритма "расширяющееся дерево"

    Некоторые современные мосты используют так называемую маршрутизацию отправителя (source routing). Такая маршрутизация предполагает, что отправитель знает, находится ли адресат в пределах локальной сети и может оптимально определить путь доставки. При посылке кадра другой сети отправитель устанавливает старший бит своего адреса равным единице. Одновременно в заголовке кадра прописывается весь маршрут. Каждой сети присваивается 12-битовый идентификатор, а каждому мосту ставится в соответствие 4-битовый код, уникальный в контексте данной сети. Это означает, что мосты в пределах одной сети должны иметь разные идентификаторы, но их коды могут совпадать, если они находятся в разных сетях. Мост рассматривает только кадры с единицей в старшем бите адреса места назначения. Для этих кадров просматриваются коды сети в списке, записанном в заголовке. Если в списке содержится код, совпадающий с тем, который характеризует сеть, где находится мост, кадр переадресуется в эту сеть. Реализация алгоритма может осуществляться программно или аппаратно. Если путь до места назначения неизвестен, отправитель генерирует специальный пакет, посылаемый широковещательно (discovery frame) и достигающий всех мостов и всех субсетей. Когда приходит отклик от адресата, мосты записывают его идентификатор, а первичный отправитель фиксируют маршрут до адресата. Данный алгоритм достаточно прост, но сопряжен с лавинным размножением "исследовательских" пакетов особенно в случае, когда смежные сети соединяются через несколько мостов/переключателей.

    Маршрутизатор отличается от переключателя тем, что поддерживает хотя бы один протокол маршрутизации. Существуют внутренние и внешние протоколы маршрутизации. Если маршрутизатор осуществляет связь данной автономной системы с другими автономными системами, его называют пограничным (border). Маршрутизатор же, который имеет только один внешний канал связи, в литературе часто называют gateway (входной порт сети). Любой маршрутизатор может поддерживать в любой момент только один внутренний и один внешний протокол маршрутизации, выбор этих протоколов осуществляет администратор сети из имеющегося списка. Маршрутизаторы представляют собой наиболее сложные сетевые устройства. Главным достоинством маршрутизаторов в локальной сети является ограничение влияния потоков широковещательных сообщений.

    В последнее время заметное распространение получил гибрид маршрутизатора и моста - brouter. Некоторые протоколы (например, NetBIOS) не допускают маршрутизации. Когда необходимо использовать такие протоколы совместно с TCP/IP, необходим brouter. Широко используются такие приборы в сетях Token Ring.

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

    Если перед вами стоит задача создания локальной сети с выходом в Интернет, вам нужно последовательно решить ряд проблем помимо финансовых. Должны быть сформулированы задачи, ради которых эта сеть создается, определена топология сети, число сегментов и характер их связей, число ЭВМ-участников, определен сервис-провайдер, или провайдеры, если вам нужно обеспечить более высокую надежность и живучесть сети. Вам надо оценить требуемую загрузку сегментов сети и внешних каналов связи, выбрать программную среду. После этого вы можете приступить к составлению списка необходимого оборудования и программного обеспечения. Если ваша сеть является оконечной и она имеет только один внешний канал связи, вам не нужен маршрутизатор и вы можете ограничиться ЭВМ-портом (gateway), которая должна иметь необходимый интерфейс. Внешним каналом может стать коммутируемая телефонная сеть, выделенная телефонная линия, оптоволоконный кабель или радиорелейный канал. Во всех перечисленных случаях вам будет необходим соответствующий модем.

    Previous: 4.1.1.3 Интернет в Ethernet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.2 IEEE 802.5 (Token Ring)


    previous up down next index index
    Previous: 4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.3 IEEE 802.4 (Маркерная шина)

    4.1.2 IEEE 802.5 (Token Ring)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Сети Token Ring были разработаны фирмой IBM в 1970-х годах и рассчитана на скорость обмена 4.16 Мбит/c при числе сегментов до 250. По своей популярности она уступает лишь Ethernet/IEEE 802.3. Спецификация IEEE 802.5 практически идентична ей и полностью совместима (см. [13], или, например, bbs.uniinc.msk.ru/product/bay/routers/interf/toking.html или www.oil.unh.edu/training/vganylan/teach/vgconcept/frame/802.-5). Сеть Token Ring имеет топологию звезды, все оконечные станции которой подключаются к общему устройству ( MSAU - MultiStation Access Unit). В IEEE 802.5 топология не оговаривается, не регламентирована здесь и сетевая среда. В Token Ring сеть базируется на скрученных парах. Обе эти разновидности сети используют схему передачи маркера (небольшой пакет - token).

    В отличие от сетей с csma/cd доступом (например, Ethernet) в IEEE 802.5 гарантируется стабильность пропускной способности (нет столкновений). Сети Token Ring имеют встроенные средства диагностики, они более приспособлены для решения задач реального времени, но в то же время более дороги.

    Маркер содержит лишь поля стартового разделителя(sdel), управления доступом (AC) и оконечного разделителя (EDEL, всего 3 байта). Если узел получил маркер, он может начать передачу информации, в противном случае он просто передает маркер следующему узлу. Каждая станция может захватить маркер на определенное время. Станция, намеревающаяся что-то передать, захватывает маркер, меняет в нем один бит, который преобразует маркер во флаг начала кадра, вносит в кадр информацию, подлежащую пересылке, и посылает его следующей станции. Передающая станция ответственна за изъятие из кольца переданных ею кадров (станция не ретранслирует собственные кадры). Введенный в сеть кадр будет двигаться по сети, пока не попадет в узел, которому он адресован и который скопирует необходимую информацию. При этом устанавливается флаг копирования (FCI), что свидетельствует об успешной доставке кадра адресату. Кадр продолжает движение, пока не попадет в узел отправитель, где он будет уничтожен. При этом проверяется, подключена ли к сети станция-адресат. Это делается путем контроля API (индикатора распознавания кадра адресатом). Сеть Token Ring идеальна для приложений, где задержка получения информации должна быть предсказуемой, и требуется высокая надежность.

    Сетевые станции подключаются к MSAU, которые объединяются друг с другом, образуя кольцо. Если станция отключилась, MSAU шунтирует ее, обеспечивая проход пакетов. Стандарт Token Ring использует довольно сложную систему приоритетов, которая позволяет некоторым станциям пользоваться сетью чаще остальных. Кадры Token Ring имеют два поля, которые управляют доступом приоритет и резервирование. Только станции с приоритетом равным или выше, чем приоритет маркера, могут им завладеть. Если маркер уже захвачен и преобразован в информационный кадр, только станции с приоритетом выше, чем у станцииё отправителя, могут зарезервировать маркер на следующий цикл. Станции, которые подняли приоритет маркера, должны его восстановить после завершения передачи.

    Сети Taken Ring имеют несколько механизмов для обнаружения и предотвращения влияния сетевых сбоев и ошибок. Например, пусть одна из станций выбрана в качестве активного монитора. Эта станция работает как центральный источник синхронизации для других станций сети и выполняет ряд других функций. Одной из таких функция является удаление из кольца бесконечно циркулирующих кадров (маркеров). Если отправитель ошибся, установив, например ошибочный адрес места назначения, это может привести к зацикливанию кадра. Ведь кадр может быть поврежден в пути и отправитель его уже не узнает. А это в свою очередь блокирует работу остальных станций. Активный монитор должен обнаруживать такие кадры, удалять их и генерировать новый маркер. Функции активного монитора часто выполняют MSAU. Попутно msau может контролировать, какая из станций является источником таких дефектных кадров, и вывести ее из кольца. Если станция обнаружила серьезную неполадку в сети (например, обрыв кабеля), она посылает сигнальный кадр (beacon). Такой кадр несет в себе идентификатор отправителя и имя соседа-предшественника (NAUN - nearest active upstream neighbour). Такой кадр инициализирует процедуру автореконфигурации, при которой узлы в районе аварии пытаются реконфигурировать сеть так, чтобы ликвидировать влияние поломки. Топологическая схема сети ieee 802.5 представлена на рис. 4.1.2.1.

    Рис. 4.1.2.1 Топология сети Token Ring

    Периферийные ЭВМ подключаются к блокам msau по схеме звезда, а сами MSAU соединены друг с другом по кольцевой схеме. Возможна реализация схемы звезда и иным способом, показанным на рис. 4.1.2.2. Здесь объединяющую функцию выполняет блок концентратора.

    Рис. 4.1.2.2. Реализация Token Ring по схеме звезда

    Концентратор может шунтировать каналы, ведущие к ЭВМ, с помощью специальных реле при ее отключении от питания. Аналогичную операцию может выполнить и блок msau. Управление сетью возлагаются на пять функциональных станций, определенных протоколом. Некоторые контрольные функции выполняются аппаратно, другие реализуются с помощью загружаемого программного обеспечения. Каждая из функциональных станций имеет свои логические (функциональные) адреса. Функциональные станции должны реагировать как на эти функциональные, так и на свои собственные аппаратные адреса. Ниже в таблице представлен список функциональных станций и их функциональных адресов (таблица 4.1.2.1).

    Таблица 4.1.2.1 Типы и адреса функциональных станций

    Функциональная станция

    Адрес

    1. Активный монитор

    c0 00 00 00 00 01

    2. Резервный монитор

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

    3. Сервер конфигурации (необязательное устройство)

    c0 00 00 00 00 02

    4. Монитор ошибок (необязательное устройство)

    c0 00 00 00 00 08

    5. Сервер параметров кольца (необязательное устройство)

    c0 00 00 00 00 10

    В сети используются кадры управления доступом к среде (УДС, код типа кадра = 00) и информационные кадры (код типа кадра =01). Имеется 25 разновидностей УДС-кадров (см. приложение 10.6 Управление доступом). Сюда входят кадры инициализации, управления средой, сообщения об ошибках и кадры управления рабочими станциями. Общий формат заголовка кадра Token Ring представлен на рис. 4.1.2.3. Размер поля данных, следующего за адресом отправителя, может иметь произвольную длину, в том числе и нулевую. В это поле может быть вложен пакет другого протокола, например, LLC.

    Рис. 4.1.2.3. Формат информационного кадра для IEEE 802.5

    В начале поля данных может размещаться LLC-заголовок, который содержит в себе 3-8 байт. Собственно этот заголовок, да поле управления кадром и отличают информационный кадр от кадра управления доступом (см. рис. 4.1.2.4).

    Рис. 4.1.2.4. Формат кадра управления доступом для IEEE 802.5 (цифрами обозначены размеры полей в байтах)

    Вслед за адресом отправителя следует информация управления доступом к среде. Кадры управления доступом служат исключительно для целей управления сетью и не передаются через бриджи и маршрутизаторы. Управляющая информация включает в себя основной вектор и несколько субвекторов. Основной вектор задает тип УДС-кадра (или команду) и типы (или классы) станций отправителя и получателя, всего 4 байта. Субвекторы содержат информацию об адресе соседа-предшественника, номер физического отвода кабеля и пр. (3 и более байт). На рис. 4.1.2.5. представлен формат основного вектора.

    Рис. 4.1.2.5. Формат основного вектора

    Субполе длина определяет полную протяженность информационного поля УДС-кадра и равна сумме длин основного вектора и всех субвекторов. Субполе класс характеризует станции отправителя и получателя. Каждой из станций выделено по 4 двоичных разряда, которые описывают типы этих станций. Ниже в таблице 4.1.2.2 представлены эти коды и их значения.

    Таблица 4.1.2.2 Таблица кодов класса

    Код класса

    Функциональный тип станции

    0x0

    Рабочая станция кольца

    0x1

    Администратор канального уровня

    0x4

    Администратор сети или сервер конфигурации

    0x5

    Сервер параметров кольца

    0x6

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

    Субполе команда содержит код, передаваемой УДС-кадром команды (см. таблицу 10.6 в приложении Управление доступом). Кадр управления доступом может содержать любое, в том числе нулевое число субвекторов. Некоторые субвектора являются обязательными. Таблица обязательных субвекторов приведена в приложении 10.7 Типы субвекторов. В результате декодирования субвекторов можно локализовать нестабильную ошибку. Ниже на рис. 4.1.2.6 приведен формат субвектора.

    Рис. 4.1.2.6. Формат субвектора

    Поля длина определяет длину субвектора (ведь она переменная). Поля тип содержит код типа субвектора. Поле значение хранит данные, например, код 0x0b характеризует номер отвода и т.д..

    Разряды начального и конечного разделителей кадра содержат как обычные нули и единицы, так и закодированные дифференциальным манчестерским кодом. На рис. 4.1.2.7 приведен формат начального разделителя SDEL.

    Рис. 4.1.2.7. Формат начального разделителя SDEL

    "e" и "Н" - представляет собой единицу и нуль, закодированные манчестерским кодом. Оконечный разделитель (EDEL) имеет формат, показанный на рис. 4.1.2.8.

    Рис. 4.1.2.8. Формат оконечного разделителя EDEL

    Бит - индикатор промежуточного кадра (IF) равен нулю, если кадр является последним или единственным кадром в последовательности. Единица в этом бите указывает на то, что этот кадр не является последним. Бит индикатор обнаруженной ошибки (ED) устанавливается равным единице первой станцией, которая выявила ошибку в контрольной последовательности кадра (CRC). Таким образом, crc контролируется всеми станциями, через которые проходит пакет. crc - гарантирует корректность пересылке части кадра, начиная от поля управление кадром кончая полем данные. Последним полем кадра является октет состояния (рис. 4.1.2.9). Первые и последние четыре бита этого поля должны повторять друг друга, что повышает достоверность записанной там информации.

    Рис. 4.1.2.9. Формат поля состояния кадра

    Бит распознавания адреса (ARI) служит в качестве флага распознавания получателем своего адреса. Если распознавание произошло, получатель перед ретрансляцией кадра далее устанавливает этот бит в единичное состояние.

    Бит- индикатор копирования кадра (FCI) служит для индикации успешного копирования информации из полученного кадра. Если получатель распознал свой адрес, имеет достаточно место в буфере и благополучно скопировал туда информацию из полученного пакета, он устанавливает этот бит в единичное состояние. Биты ARI и FCI активно используются управляющими станциями кольца. Для отправителя они носят второстепенный характер, ибо решение о повторной пересылке при утере кадра принимается обычно на транспортном (более высоком) уровне. При недостатке буферного пространства в памяти станция не всегда может скопировать кадр, повторная же передача сокращает пропускную способность сети. Если же перегружающаяся станция является частью инфраструктуры сети (сервер), это может ухудшить свойства сети в целом. Улучшению ситуации может способствовать увеличение числа буферов на плате сетевого адаптера, увеличение быстродействия канала и расширения объема буферной памяти в самой ЭВМ.

    Флаг начала потока (SSD - start of stream delimiter) позволяет сетевому уровню, независящему от физической среды (PMI - physical media independent) детектировать начало потока кодов. Получение неверного SSD не прерывает прием данных, а передает сигнал ошибки субуровням MAC или RMAC.

    SSD высокого приоритета:

    0101 111100 000011

    SSD обычного приоритета:

    0101 100000 111110

    Флаг окончания потока (ESD - end of stream delimiter) позволяет сетевому уровню PMI завершить прием пакета и переслать полученные данные субуровню mac. Детектирование неверного IPM (invalid packet marker) разделителя приводит к ошибке на уровне MAC или RMAC.

    Правильный флаг окончания потока (ESD):

    esd высокого приоритета:

    111111 000011 000001

    esd обычного приоритета:

    000000 111100 111110

    Маркер неправильного пакета:

    110000 011111 110000

    Сигнатура преамбулы позволяет PMI определить место, с которого следует начинать прием данных. Код преамбулы имеет вид:

    010101 010101 010101 010101 010101 010101 010101 010101

    Рис. 4.1.2.10. Формат поля управления доступом

    Поле управления доступом служит для определения приоритета кадра, это единственное поле, которое присутствует в маркере (помимо SDEL и EDEL). Субполе приоритета (PPP) указывает на приоритет маркера в 802.5. Предусмотрено восемь уровней приоритета, начиная с 000 (низший) до 111 (высший). В 802.12 здесь записывается всегда 000. Субполе бит маркера позволяет отличить обычный кадр от маркера. Для маркера поле несет в себе 0, а для кадра 1 (802.5). Так как в 100VG-anylan передаются только маркерные кадры, этот бит всегда равен 1. Бит мониторинга препятствует бесконечной циркуляции кадра по кольцу. В исходный момент все кадры и маркеры имеют этот бит равный 0. Приемник игнорирует этот бит. Биты rrr разрешают приоритетным пакетам запрашивать маркер того же уровня приоритета. Стандарт 802.12 не использует непосредственно октет управления доступом, а для обеспечения совместимости с 802.5 по умолчания записывает туда 0001000.

    Рис. 4.1.2.11. Формат поля управления кадра

    Значения кодов субполя тип кадра представлено в таблице 4.1.2.3, они определяют формат данных информационного поля кадра. Для обычной передачи поле равно 01000yyy.

    Таблица 4.1.2.3 Коды типа кадра

    Код поля типа

    Функция

    00

    MAC-кадр (УДС)

    01

    LLC-кадр (данные)

    1x

    Резерв на будущее

    Поле физического управления (pcf) имеет смысл только для УДС-кадров и служит для оповещения станций о типе кадра управления средой. Это поле служит также для указания приоритета передачи кадра из буфера адаптера в ЭВМ. В таблице 4.1.2.4.

    Таблица 4.1.2.4 Коды поля pcf

    Описание

    Код поля pcf

    Нормальный буфер

    0

    Экспресс буфер

    1

    Очистка кольца

    2

    Требование маркера

    3

    Аварийная сигнализация

    4

    Наличие активного монитора

    5

    Наличие резервного монитора

    6

    Для llc-кадров поле резервированные биты и далее имеет формат rrryyy, где биты rrr зарезервированы для будущего использования (000), а yyy - код приоритета пакетов пользователя. (MAC-кадры не используются в IEEE 802.12). Формат поля адреса получателя отображен на рис. 4.1.2.12.

    Рис. 4.1.2.12. Формат адреса места назначения

    I/G =0 индивидуальный адрес (I); I/G=1 групповой адрес (g).
    U/L=0 универсальный адрес (U); U/L=1 локальный адрес (L).

    Индивидуальный адрес - адрес конечного узла, уникальный для данной локальной сети (в случае локального администрирования) или отличный от любого другого адреса в глобальной сети в случае универсального администрирования. Существует две разновидности индивидуального адреса: уникастный и нулевой. Уникастный адрес - индивидуальный адрес, идентифицирующий один из узлов сети. Нулевой адрес равен нулю и означает, что кадр не адресован ни одному из узлов сети. Такой адрес не может быть присвоен ни одному из оконечных узлов сети. Описываемые далее разновидности адресов используются только в полях адреса места назначения.

    Групповой адрес ассоциируется с (нулем или более) некоторым числом оконечных узлов данной сети, обычно это группа логически связанных узлов. Широковещательные и мультикастинг-адреса относятся к групповым адресам.

    Широковещательный адрес подразумевает обращение ко всем узлам данной сети, такой адрес содержит 1 во всех своих разрядах. Мультикастинг-адрес подразумевает обращение к некоторой, выделенной группе адресов данной локальной сети. Существуют также функциональные адреса (FA), которые идентифицируют некоторые известные функциональные объекты с помощью групповых адресов. Формат функционального адреса представлен на рис. 4.1.2.13.

    Рис. 4.1.2.13. Структура функционального адреса

    Ниже приведена таблица 4.1.2.5 некоторых зарезервированных функциональных адресов.

    Таблица 4.1.2.5. Зарезервированные функциональные адреса

    6-октетный адрес (fa)

    Назначение

    С0 00 00 00 00 01

    Активный монитор

    С0 00 00 00 00 02

    Кольцевой сервер параметров (rps)

    Функциональные адреса являются отличительной особенностью сетей Token Ring. В этих сетях маршрутная информация распределена между устройствами сети. Рабочие станции создают и поддерживают собственные маршрутные таблицы. Формат поле адреса отправителя показан на рис. 4.1.2.14.

    Рис. 4.1.2.14. Формат адреса отправителя

    Субполе RII является индикатором маршрутной информации, функция субполя U/L идентична с вариантом формата адреса получателя. Если RII=1, в поле данных содержится маршрутная информация.

    Формат поля маршрутной информации отображен на рис. 4.1.2.15.

    Рис. 4.1.2.15. Формат поля маршрутной информации (RI)

    Разновидности сетей, не использующие маршрутную информацию, берут код из субполя LTH (длина), чтобы обойти поле RI. Субполе RT (код типа маршрутизации) имеет 3 бита и говорит о том, должен ли данный кадр быть переадресован. Ниже приведена таблица (4.1.2.6) возможных значений кода rt.

    Таблица 4.1.2.6. Значения кола rt

    Код rt

    Описание

    0xx

    Передача по определенному маршруту

    10x

    Широковещательная передача по всем маршрутам

    11x

    Широковещательная передача по одному маршруту

    Субполе LTH (длина) имеет 5 бит и хранит в себе длину поля RI в октетах. LTH должно быть четным и лежать в пределах 2-30, включительно. Обычно маршрутная информация занимает от 2 до 16 байт (cпецификация IBM требует, чтобы кадр проходил не более 7 мостов). Если субполе бит направления (d) равно нулю, обход кольца маркером осуществляется в порядке записи дескрипторов маршрута, при d=1 - в обратном порядке (RDN, RDn-1, ... RD1). Субполе максимальная длина кадра (LF) имеет 3 бита и указывает наибольший размер информационного поля MAC. Значение поля устанавливается мостами при определении маршрута и указывает максимальную длину кадра, передаваемого мостом. Допустимы следующие значения:

    Таблица 4.1.2.7. Возможные значения поля LF

    Код поля lf

    Длина кадра в байтах

    000

    516

    001

    1500

    010

    2052

    011

    4472

    100

    8144

    101

    11407

    110

    17800

    Субполя дескрипторов маршрута состоят из 12 бит идентификатора сети (номер кольца, назначается сетевым администратором) за которым следует 4 бита номера моста. Эти дескрипторы определяют порядок обхода сети кадром. В сетях 100VG-anylan это поле не используется, так как порядок обхода задается аппаратно повторителями.

    При построении больших сетей token ring приходится использовать большое число колец. Отдельные кольца связываются друг с другом, как и в других сетях, с помощью мостов (рис. 4.1.2.16). Мосты бывают "прозрачными" (IEEE 802.1d) и с маршрутизацией от источника. Последние позволяют связать в единую сеть несколько колец, использующих общий сетевой IPX- или IP-адрес.

    Рис. 4.1.2.16 Соединение колец с помощью прозрачного моста

    Использование мостов позволяет преодолеть и ограничение на число станций в сети (260 для спецификации ibm и 255 для IEEE). Мосты могут связывать между собой фрагменты сетей, использующих разные протоколы, например, 802.5, 802.4 и 802.3. Пакеты из кольца 1 адресованные объекту этого же кольца никогда не попадут в кольцо 2 и наоборот. Через мост пройдут лишь пакеты, адресованные объектам соседнего кольца. Фильтрация пакетов осуществляется по физическому адресу и номеру порта. На основе этих данных формируется собственная база данных, содержащая информацию об объектах колец, подключенных к мосту. Схема деления сети с помощью мостов может способствовать снижению эффективной загрузки сети.

    Мосты с маршрутизацией от источника могут объединять только сети token ring, а маршрутизация пакетов возлагается на все устройства, посылающие информацию в сеть (отсюда и название этого вида мостов). Это означает, что в каждом из сетевых устройств должно быть загружено программное обеспечение, позволяющее маршрутизировать пакеты от отправителя к получателю (в случае netware это route.com). Эти мосты не создают собственных баз данных о расположении сетевых объектов и посылают пакет в соседнее кольцо на основе маршрутного указания, поступившего от отправителя самого пакета. Таким образом, база данных о расположении сетевых объектов оказывается распределенной между станциями, хранящими собственные маршрутные таблицы. Программы маршрутизации используют сетевой драйвер адаптера. Мосты с маршрутизацией от источника просматривают все поступающие кадры и отбирают те, которые имеют индикатор информации о маршруте RII=1. Такие кадры копируются, и по информации о маршруте определяется, следует ли их посылать дальше. Мосты с маршрутизацией от источника могут быть настроены на широковещательную передачу по всем маршрутам, либо на широковещательную передачу по одному маршруту. Формат информации о маршруте показан на рис. 4.1.2.15.

    В сетях со сложной топологией маршруты формируются согласно иерархическому протоколу STP (spanning tree protocol). Этот протокол организует маршруты динамически с выбором оптимального маршрута, если адресат достижим несколькими путями. При этом минимизируется транзитный трафик. Для решения задачи мосты обмениваются маршрутной информацией. Формат этих пакетов показан на рис. 4.1.2.17.

    Рис. 4.1.2.17. Формат кадра маршрутных данных, рассылаемых мостом

    Поле идентификатор протокола характеризует используемый мостом протокол (для STP это код равен 0x000). Поле версия протокола хранит текущую версию протокола. Поле тип протокольного блока данных моста может принимать следующие значения:

    0x00

    протокольный блок данных моста конфигурации;

    0x80

    протокольный блок данных моста объявления об изменении топологии.

    В настоящее время протоколом STP используются только два флага :

    0x01

    флаг изменения топологии;

    0x80

    флаг подтверждения изменения топологии.

    Поле идентификатор корня содержит идентификатор корневого моста. В поле метрика маршрута до корня хранится оценка маршрута до корневого моста. В поле идентификатор моста записывается 8-байтовый код-идентификатор моста, передающего протокольный блок данных. Содержимое двух старших байт задается администратором сети, остальные 6 байт хранят универсальный или локальный адрес порта моста. Идентификатор порта представляет собой двух-байтовый код, присвоенный порту моста. Поле возраст сообщения содержит время в секундах, прошедшее с момента формирования конфигурационного сообщения. При ретрансляции протокольного блока конфигурации каждый мост увеличивает код в этом поле на величину, заданную протоколом управления. Величину кода в поле максимальный возраст задает корневой мост так, чтобы все остальные мосты имели согласованные значения возраста информации о конфигурации. Поле период актуализации определяет длительность периода посылки протокольных блоков конфигурации в секундах. Поле задержки передачи указывает на заданную корневым мостом величину времени в секундах, в течение которого порт не должен начинать передачу кадров после окончания реконфигурации сети.

    Длина поля данных ограничивается временем, на которое станция может захватить маркер и не превышает 4502 октетов. Поле CRC служит для контроля целостности кадра при транспортировке. При расчете CRC используется образующий полином вида:

    x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

    Алгоритм вычисления аналогичен тому, что используется в сетях Ethernet, контрольное суммирование охватывает поля адрес места назначения, адрес отправителя, управление кадром, маршрутная информация и данные.

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

    На физическом сетевом уровне используется дифференциальный манчестерский код с уровнями сигналов положительной и отрицательной полярности в диапазоне 3,0-4,5 В (сравните с +0,85 и -0,85 В для IEEE 802.3).

    Previous: 4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.3 IEEE 802.4 (Маркерная шина)


    previous up down next index index
    Previous: 4.1.2 IEEE 802.5 (Token Ring)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)

    4.1.3 IEEE 802.4 (Маркерная шина)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Стандарт IEEE 802.4 описывает свойства сетей, известных под названием маркерная шина. С точки зрения правил предоставления доступа этот стандарт схож с token ring (см. [13], а также RFC-1042 и -1230). В качестве физической среды используется 75-омный кабель. При необходимости построения сети типа дерева, а также для увеличения длины сети используются повторители. Сеть способна обеспечить пропускную способность до 10 Мбит/с при полосе пропускания кабеля 12 МГц.

    Для доступа к сетевой среде станция должна получить пакет-маркер. Получив маркер, сетевое устройство может начать передачу данных, а завершив эту процедуру, устройство должно переслать маркер следующей сетевой станции. Передача маркера происходит до тех пор, пока он не достигнет младшей станции, после чего он возвращается первой станции. Формат кадра, пересылаемого по маркерной шине, имеет вид, представленный на рис. 4.1.3.1.

    Рис. 4.1.3.1. Формат кадров 802.4.

    SD - (Start Delimiter) - стартовый байт-разделитель =**0**000, где * - символ, кодируемый неманчестерским кодом; FC - (Frame Control) поле управления кадром = FFxxxxxx, где FF - субполе формата кадра, а xxxxxx - биты типа кадра, SA и DA адреса отправителя и получателя, соответственно. FSC - (Frame Control Sequence) контрольная сумма (4 байта). ED - (End Delimiter) оконечный разграничитель =**1**11E (правый бит является 8-ым). MMM=000 - запрос, не требующий подтверждения; MMM=001 - запрос, требующий подтверждения, MMM=010 - отклик на запрос. PPP - биты приоритета (111 - высший приоритет, а 000 - низший). Значения кодов поля FC приведены в таблицах 4.1.3.1 и 4.1.3.2 (цифрами обозначен порядок передачи разрядов).

    Таблица 4.1.3.1. Коды поля FC

    FF
    12

    xxxxxx
    345678

    Назначение

    00

    CCCCCC

    Кадр управления доступом к сетевой среде

    01

    MMMPPP

    Кадр управления логическим каналом

    01

    YYYYYY

    Кадр управления станцией

    11

    ZZZZZZ

    Зарезервировано на будущее

    Станции получают доступ к шине в результате соревновательной процедуры, называемой "окно откликов". Окно откликов представляет собой временной интервал, равный по длительности одному системному такту, который в свою очередь равен времени распространения сигнала по шине. Это время отсчитывается от момента окончания передачи кадра управления. В течение этого времени станция-инициатор ожидает отклика от других станций. Любая станция сети, будучи владельцем маркера, может запустить этот процесс с помощью посылки кадра поиск следующей станции. Запросы на подключение осуществляются путем отправки пакета установка следующей станции, в поле данных которого записывается адрес станции, запрашивающей доступ к шине. Адрес следующей соседней станции меньше адреса станции-отправителя (маркер движется в направлении убывания адресов). Обычно посылается кадр с одним окном откликов. При этом запросы могут посылать станции с адресами не меньше, чем адрес ближайшего соседа. Если процесс инициализирован станцией с наименьшим номером, то посылается пакет с двумя окнами откликов, одно для станции с номером меньше, чем у предшественника, другое с адресом больше чем у предшественника. После этого станция ждет ответа в течение одного такта. Если ответа нет, маркер передается следующей станции. Если же получен один ответ, инициализируется подключение станции с помощью пакета установка следующей станции. При получении более одного отклика возникает конфликт, для разрешения которого посылается пакет разрешение конфликта с четырьмя окнами. Станции заносят свои запросы в окна в соответствии с первыми двумя битами своего адреса. Если попытка разрешить конфликт при этом не удалась, пакет осылается повторно. В новой попытке участвуют только станции, участвовавшие в первом раунде, а для сравнения используются уже следующие два бита адреса. Процедура может завершиться подключением одной из станций или исчерпыванием числа попыток.

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

    При обнаружении потери маркера запускается процедура инициализации сети, при этом посылается пакет требование маркера. Станция, пославшая запрос, прослушивает шину и при обнаружении сетевой активности выбывает из соревнования (имеется станция с большим, чем у нее адресом). В сети определено 4 класса обслуживания (6, 4, 2, 0). Станция может передавать данные класса 6 в течение допустимого времени удержания маркера THT (для класса 6). При M станций в сети максимальное время ожидания будет равно THT*M. По завершении передачи данных класса 6 (или если они не передавались вовсе) можно передавать данные класса 4. Аналогично определено время обращения маркера для классов 4, 2 и 0.

    Таблица 4.1.3.2. Коды поля FC и типы кадров

    Код поля FC

    Тип кадра

    Поле данных

    0x0

    Запрос маркера

    Код арбитража

    0x1

    Поиск следующей станции (1 окно откликов)

    Отсутствует

    0x2

    Поиск следующей станции (два окна откликов)

    Адрес следующей станции

    0x3

    Кто следующий? (три окна откликов)

    Отсутствует

    0x4

    Разрешение конфликта (4 окна откликов)

    Отсутствует

    0x8

    Маркер

    Отсутствует

    0xD

    Установка следующей станции

    Адрес следующей станции

    Сети все шире внедряются в промышленность, науку, а в последнее время можно ожидать появления сетей и в наших жилищах (первые опыты по созданию информационных сетей на основе систем кабельного телевидения в США и Канаде уже успешно проведены). Для сбора измерительной информации уже более десятилетия используется магистрально-модульный стандарт GPIB (IEC-625, IEEE-488 или ГОСТ 26.003-80). Но этот стандарт ограничивает размер сети, имеет дорогостоящий интерфейс, недостаточно надежен и гибок. Применение для этой цели RS-232 не слишком перспективно, так как этот интерфейс предполагает соединение по схеме точка-точка. Возникла необходимость создания сетей с дешевой магистралью и интерфейсом с пропускной способностью 128-1024 Кбит/c. Примером такой сети можно считать CAN. Кто знает, возможно спустя несколько лет какая-то модификация этой сети будет использована для сетевого управления бытовой техникой в вашей квартире. Аппаратная реализация узлов комплексного управления бытовой техникой уже появились в продаже.

    Previous: 4.1.2 IEEE 802.5 (Token Ring)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)


    previous up down next index index
    Previous: 4.1.3 IEEE 802.4 (Маркерная шина)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.5 Локальные сети ArcNet

    4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Стандарт CAN (Controller Area Network - http://www.kvaser.se/can/protocol/index.htm или http://www.omegas.co.uk/can/canworks.htm, а также www.can-cia.de) был разработан в Германии компанией Robert Bosch gmbh для автомобильной промышленности (1970 годы). Сеть CAN ориентирована на последовательные каналы связи, выполненные из скрученных пар проводов (или оптических волокон), стандарт определяет протоколы физического уровня и субуровеней MAC и LLC. Все узлы сети равноправны и подключаются к общему каналу. Уровни сигналов протоколом не нормированы. В CAN использована кодировка типа NRZ (Non Return to Xero). Для распознавания сигнатур начала (SOF) и конца (EOF) кадра используется бит-стафинг. В настоящее время в ЕС разрабатывается новый протокол для сети автомобиля, который бы позволял передачу высококачественного стерео аудио и видео сигналов, обеспечивал работу с мобильными телефонными сетями и Интернет. Предполагается, что пропускная способность протокола составит 45 Мбит/c

    Высокая надежность и дешевизна сделала сети CAN привлекательными для промышленности и науки. Сеть предназначена для сбора информации и управления в реальном масштабе времени, но может быть использована и для других целей. Канал can реализует принцип множественного доступа с детектированием столкновений (CSMA/CD - Carrier Sense Multiple Access with Collision Detection, аналогично Ethernet). Сеть может содержать только один сегмент. В соответствии со стандартом ISO 11898 сеть способна работать при обрыве одного из проводов, при закоротке одного из проводов на шину питания или на землю. Скорость работы канала программируется и может достигать 1 Мбит/с. Недиструктивная схема арбитража позволяет сделать доступ к общему каналу существенно более эффективным, чем в случае Ethernet. В настоящее время действуют две версии стандарта с полями арбитража длиной в 11 бит (2.0a) и 29 бит (расширенная версия, 2.0b). Код арбитража одновременно является идентификатором кадра и задается на фазе инициализации сети. При одновременной попытке передачи кадров двумя узлами арбитраж выполняется побитно с использованием схемы проволочного "И", при этом доминантным состоянием является логический "0". Выигравший соревнование узел продолжает передачу, а проигравший ждет момента, когда канал освободится. Код-адрес объекта (узла CAN) задается с помощью переключателей на плате CAN при формировании сети.

    Когда канал свободен, любой из подключенных узлов, может начать передачу. Кадры могут иметь переменную, но конечную длину. Формат информационного кадра сети CAN, содержащего семь полей, показан на рис. 4.1.4.1.

    Рис. 4.1.4.1 Стандартный информационный кадр 1 2.0a CAN

    Кадр начинается с доминантного бита начала кадра (логический нуль, SOF - start of frame). Далее следует поле арбитража (идентификатор кадра), содержащее 11 бит (эти разряды носят имена id-28, ..., id-18) и завершающееся битом RTR (remote transmission request) удаленного запроса передачи. В информационном кадре RTR=0, для кадра запроса RTR=1. Семь наиболее значимых бит id-28 - id-22 не должны быть никогда все одновременно равными 1. Первым передается бит id28. Доминантные биты r0 и r1 (=0) зарезервированы для будущего использования (в некоторых спецификациях бит r1 называется IDE и относится для стандартных кадров к полю управления). Поле DLC (Data Length Code; биты поля имеют имена dcl3 - dcl0) несет в себе код длины поля данных в байтах. Поле данных, размещенное вслед за ним, может иметь переменную длину или вообще отсутствовать. CRC - циклическая контрольная сумма. В качестве образующего полинома при вычислении CRC используется x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1. Формально, следующий за контрольной суммой бит-разграничитель (=1) принадлежит полю CRC. Поле отклика (ack) содержит два бита, первый из которых первоначально имеет уровень 1, а узлы получатели меняют его значение на доминантное (логический 0). Бит используется для сообщения о корректности контрольной суммы. Второй бит поля всегда имеет уровень логической 1. Завершающее поле EOF (end of frame) содержит семь единичных бит. За этим полем следует поле-заполнитель (INT) из трех единичных бит, после него может следовать очередной кадр. Формат расширенного информационного кадра сети can показан на рис. 4.1.4.2.

    Рис. 4.1.4.2. Расширенный информационный кадр 2.0b CAN

    Однобитовое субполе SRR (substitute remote request) включено в поле арбитража (идентификатора кадра) и всегда содержит код 1, что гарантирует преимущество стандартного информационного кадра (2.0a) случае его соревнования с расширенным кадром (2.0b) (при равных 11 битах идентификатора). Субполе IDE (identifier extension) служит для идентификации расширенного формата и для этого типа кадра всегда имеет уровень логической 1. Вслед за IDE следует 18-битовое поле (биты имеют имена id-17, ..., id-0; первым передается бит id-28) расширения идентификатора кадра. Контроллеры 2.0b полностью совместимы с кадрами 2.0a и могут посылать и принимать пакеты обоих типов. Идентификаторы в пределах одной сети должны быть уникальными. Следует иметь в виду, что 18-битное поле расширения идентификатора можно при определенных условиях использовать и для передачи информации. Идентификатор не является адресом места назначения, а определяет назначение передаваемых данных (адресация по содержанию). По этой причине пакет может быть принят отдельным узлом, группой узлов, всеми узлами сети или не воспринят вообще. Предельное число различных идентификаторов для версии 2.0a составляет 2032, а для 2.0b превышает 500 миллионов.

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

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

    Протокол can имеет развитую систему диагностики ошибок. В результате вероятность не выявленной ошибки составляет менее 4.7 10-11. При выявлении ошибки кадр отбрасывается и его передача повторяется.

    Число узлов, подключенных к каналу, протоколом не лимитируется. Практически такое ограничение налагается задержкой или предельной нагрузкой канала.

    Любой модуль can может быть переведен в пассивный режим ("состояние сна"), при котором внутренняя активность прекращается, а драйверы отключаются от канала. Выход из этого режима возможен либо по внутренним причинам, либо вследствие сетевой активности. После "пробуждения" модуль ждет, пока стабилизируется его внутренний тактовый генератор, после чего производится синхронизация его работы с тактами канала (11 тактов). Благодаря синхронизации отдельные узлы не могут начать передачу асинхронно (со сдвигом на часть такта). Протокол предусматривает использование четырех типов кадров:

    • Информационный.
    • Удаленный запрос (требование присылки информационного кадра с тем же идентификатором, что и запрос).
    • Сообщение об ошибке.
    • Уведомление о перегрузке канала (требует дополнительной задержки до и после передач информационных кадров и удаленных запросов).

    Информационные кадры и удаленные запросы могут использовать как стандартные, так и расширенные форматы кадров (2.0a и 2.0b).

    Кадр удаленного запроса может иметь стандартный и расширенный форматы. В обоих случаях он содержит 6 полей: SOF, поле арбитража, поле управления, CRC, поля ACK и EOF. Для этого типа кадров бит RTR=1, а поле данных отсутствует вне зависимости от того, какой код содержится в субполе длины.

    Кадр сообщения об ошибке имеет только два поля - суперпозиция флагов ошибки и разграничитель ошибки. Флаги ошибки бывают активными и пассивными. Активный флаг состоит из шести нулевых бит, а пассивный - из шести единиц. Суперпозиция флагов может содержать от 6 до 12 бит. Разграничитель ошибки состоит из восьми единичных бит.

    Кадр перегрузки включает в себя два поля - перпозиция флагов перегрузки и разграничитель перегрузки (8 бит =1). В поле флаг ерегрузки записывается 6 бит, равных нулю (как и в поле флаг активной ошибки). Кадры ошибки или перегрузки не требуют межкадровых разделителей. Существует ряд условий перегрузки, каждое из которых вызывает посылку такого кадра:

    • внутренние обстоятельства приемника, которые требуют задержки передачи следующего кадра данных или запроса.
    • Детектирование доминантного бита в начале поля int.
    • Обнаружение узлом доминантного восьмого бита в поле разграничителя ошибки или разграничителя перегрузки.

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

    Поля SOF, идентификатор, управляющее поле, данные и CRC кодируются таким образом, что при появлении пяти идентичных бит подряд, в поток вставляется бит противоположного уровня. Так 0000000 преобразуется в 00000100, а 1111110 в 11111010. Это правило не распространяется на CRC-разделители, поля ACK и EOF, а также на кадры сообщения об ошибке или переполнении. Существует 5 разновидностей ошибок (таблица 3.3.4.1).

    Таблица 4.1.4.1 Разновидности ошибок.

    Тип ошибки

    Описание

    bit error

    Передающий узел обнаружил, что состояние шины не соответствует тому, что он туда передает

    stuff error

    Нарушено правило кодирования (вставка бита противоположного значения после 5 идентичных бит, см. абзац выше).

    CRC error

    Приемник обнаружил ошибку в контрольной сумме.

    form error

    Обнаружено нарушение формата кадра

    acknowledgment error

    Выявлен неверный уровень первого бита поля ack.

    Любой узел CAN должен регистрировать и по запросу сообщать число ошибок при передаче и приеме.

    Номинальное время, выделенное для передачи одного бита, включает в себя четыре временные области: sync_seg, prop_seg, phase_seg1, phase_seg2 (рис.3.4.4.3).

    Рис. 4.1.4.3 Временные зоны периода передачи одного бита

    Первая временная область (SYNC_SEG) служит для синхронизации работы различных узлов сети. Область PROP_SEG предназначена для компенсации временных задержек в сети и равна сумме времени распространения сигнала по каналу и задержки во входных компараторах. PHASE_SEG1 и PHASE_SEG2 служат для компенсации фазовых ошибок и могут увеличиваться или уменьшаться после синхронизации. T0 - минимальный квант времени, используемый для формирования временной шкалы в пределах периода передачи одного бита (длительность внутреннего такта может быть значительно короче). Момент стробирования определяет момент времени, когда проверяется состояние канала. Этот момент должен быть синхронным для всех узлов сети. Длительность этих временных областей может задаваться программно. Чем длиннее канал, тем меньшую скорость передачи информации он может обеспечить (см. табл. 3.3.4.2).

    Таблица 4.1.4.2 Зависимость пропускной способности канала от его длины

    Длина канала в метрах

    Пропускная способность сети в Кбит/с

    100

    500

    200

    250

    500

    125

    6000

    10

    В сетях CAN используются 9-, 6- и 5-контактные разъемы. Тип разъема, или какие либо его характеристики стандартом не регламентируются. Разъем определяется протоколом HLP (High Layer Protocol).

    Previous: 4.1.3 IEEE 802.4 (Маркерная шина)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.5 Локальные сети ArcNet


    previous up down next index index
    Previous: 4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.6 Сети FDDI

    4.1.5 Локальные сети ArcNet
    Семенов Ю.А. (ГНЦ ИТЭФ)

    ARCNET - (attached resource computing network - смотри также http://www.smc.com/network/arcnet) представляет собой стандарт на локальные сети, разработанный корпорацией datapoint в 1977 году. Эта сеть базируется на идее маркерной шины и может позволить реализовать топологию шины, кольца или звезды при скорости обмена 2,5Мбит/с. Сеть строится вокруг активных и пассивных повторителей (HUB). Активные повторители (обычно 8-канальные) могут соединяться друг с другом, с пассивными повторителями/разветвителями и оконечными ЭВМ (рабочими станциями). Длина таких соединений, выполняемых 93-омным коаксиальным кабелем (RG-62, разъемы BNC), может достигать 600м. Допускается применение скрученных пар (RS485) или оптического волокна. Пассивный 4-входовый повторитель позволяет подключать до трех рабочих станций кабелем длиной до 35 м, один из входов всегда занят соединением с активным повторителем. Пассивные повторители не могут соединяться друг с другом. Активные повторители могут образовывать иерархическую структуру. Максимальное число рабочих станций в сети равно 255. Предельная суммарная длина кабелей многосегментной сети составляет около 7 км. Схема соединений в сети arcnet показана на рис. 4.1.5.1 (пунктиром обозначены возможные связи с другими активными повторителями или маршрутизаторами).

    В настоящее время разработан стандарт arcnet plus, рассчитанный на скорость обмена до 20 Мбит/с, совместимый с прежней версией. Новый стандарт позволяет строить сети с числом станций в 8 раз больше, чем старый. Если в сети присутствуют узлы, рассчитанные на разную скорость обмена, выбор полосы пропускания осуществляется при установлении связи. Соединение с другими сетями (например, Ethernet, Token Ring или Интернет) возможно через специальные шлюзы, мосты или маршрутизаторы.

    Каждому узлу в сети присваивается уникальный адрес в диапазоне от 1 до 255. Стандарт arcnet поддерживает работу с пакетами двух длин: <253 или 506. Отличительной особенностью сети является низкая избыточность - заголовки пакетов имеют длину 3-4 байта. Все пакеты в arcnet начинаются с байта, содержащего единицы во всех разрядах. Всего в arcnet используется пять разновидностей пакетов:

    • Пакет маркер (itt-приглашение). Рабочая станция, получившая такой пакет, может что-нибудь послать.
    • Запрос свободного буфера (FBE - free buffer enquire). Служит для выяснения возможности приема данных получателем.
    • Подтверждение получения (ACK), посылается в ответ на FBE при корректном приеме.
    • Отрицательное подтверждение (NAK), посылается в случае приема с ошибкой.
    • Пакет, содержащий информацию, адрес получателя, отправителя и контрольную сумму.

    Сеть Arcnet допускает фрагментацию (ANSI 878.2) сообщений и инкапсуляцию (ansi 878.3) пакетов, отвечающих требованиям других протоколов.

    Рис. 4.1.5.1. Топологическая схема сети Arcnet

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

    Короткие кадры могут содержать от 0 до 249 байт полезной информации. Длинные кадры могут нести от 253 до 504 байт. Для того, чтобы иметь возможность работать с кадрами, содержащими 250, 251 или 252 байт информации, введен специальный формат (exception). Форматы этих кадров ARCNET представлены на рис. 4.1.5.2.

    Эти пакеты представлены так, как их видит программное прикладное обеспечение, по этой причине это представление иногда называется "буферным". Пакеты в сети выглядят несколько иначе: идентификатор места назначения дублируется, заполнитель между полем смещения и идентификатором протокола вообще не пересылается.

    arcnet позволяет делить длинные внешние пакеты или сообщения на ряд фрагментов, максимальное число которых может достигать 120.

    Поле флаг фрагментации указывает на наличие фрагментации пакета. Не фрагментированные пакеты имеют этот флаг равный нулю. Для первого пакета фрагментированного сообщения этот флаг равен ((t-2)*2)+1, где t - полное число фрагментов.

    Рис. 4.1.5.2 Форматы кадров ARCNET

    Пакеты, несущие в себе последующие части сообщения, имеют в этом поле код равный ((N-1)*2), где N - номер фрагмента. Так пятый фрагмент сообщения будет содержать в поле флага фрагментации код 8. Принимающая станция может идентифицировать последний фрагмент сообщения, так как он будет иметь флаг фрагментации больше, чем у первого фрагмента. Значения флага фрагментации более 0xEE запрещены.

    Значение флага фрагментации 0xFF используется для пометки кадров специального формата (exception). Все фрагменты одного и того же сообщения имеют идентичные поля номера по порядку.

    IP и ARP-дейтограммы инкапсулируются в соответствующие ARCNET пакеты. Если длина дейтограмм превосходит 504 октета, они делятся на фрагменты и пересылаются по частям. Взаимосвязь IP- и 8-битных ARCNET адресов осуществляется с помощью протокола ARP (см. RFC-826. Plammer D., "An Ethernet Address Resolution Protocol", MIT, Nov. 1982).

    Можно устроить так, чтобы младшие 8 бит IP-адреса совпадали с ARCNET адресом. В этом случае ARP-протокол не потребуется. Но этот путь не рекомендуется, так как он менее гибок. Все широковещательные и мультикастинг IP-адреса должны соответствовать ARCNET-адресу 0.

    Корпорация Datapoint использует следующие идентификаторы протоколов: 212 (десятичное) для IP, 213 - для ARP и 214 - для протокола RARP.

    Сети ARCNET отличаются дешевизной, простотой установки и эксплуатации. За последнее время в связи с резким удешевлением Ethernet-интерфейсов это преимущество несколько нивелировалось. Взаимодействие ARCNET и Интернет описано в документе STD-46.

    Previous: 4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.6 Сети FDDI


    previous up down next index index
    Previous: 4.1.5 Локальные сети ArcNet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.7 Параллельный сетевой интерфейс HIPPI

    4.1.6 Сети FDDI
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Одной из наиболее популярных сетей, использующих оптическое волокно, (не считая fast ethernet) является FDDI. FDDI (fiber distributed data interface, ISO 9314-1, rfc-1512, -1390, -1329, -1285 - смотри также http://iquest.com/~nmaller/fddi.htm) стандарт американского института стандартов (ansi), принятый без изменения ISO. Протокол рассчитан на физическую скорость передачи информации 100 Мбит/с и предназначен для сетей с суммарной длиной до 100км (40 км для мультимодовых волокон) при расстоянии между узлами 2 км или более. Частота ошибок в сети не превышает 10-9. В FDDI используется схема двойного кольцевого счетчика (рис. 4.1.6.1; буквами a,b,c,d и e обозначены станции-концентраторы). Кольцевая схема единственно возможное решение для оптического волокна (не считая схемы точка-точка). Для доступа к сети используется специальный маркер (развитие протокола IEEE 802.5 - Token Ring). Сети FDDI не имеют себе равных при построении опорных магистралей (backbone) локальных сетей, позволяя реализовать принципиально новые возможности - удаленную обработку изображений и интерактивную графику. Обычно устройства (DAS - dual attached station) подключаются к обоим кольцам одновременно. Пакеты по этим кольцам движутся в противоположных направлениях. В норме только одно кольцо активно (первичное), но при возникновении сбоя (отказ в одном из узлов) активизируется и второе кольцо, что заметно повышает надежность системы, позволяя обойти неисправный участок (схема соединений внутри станций-концентраторов на рис. 4.1.6.1 является сильно упрощенной). Предусмотрена возможность подключения станций и только к одному кольцу (SAS - single attached station), что заметно дешевле. К одному кольцу можно подключить до 500 das и 1000 sas. Сервер и клиент имеют разные типы интерфейсов.

    Рис. 4.1.6.1. Схема связей в двойном кольце FDDI

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

    FDDI позволяет работать с кадрами размером 4500 октетов, за вычетом места, занимаемого преамбулой, остается 4470 октетов для передачи данных. RFC-1188 резервирует 256 октетов для заголовков, оставляя для данных 4096 октетов. Маршрутизатор, поддерживающий протокол FDDI должен быть способен принимать такие длинные пакеты. Посылаться же должны дейтограммы не длиннее 576 октетов, если не ясно, сможет ли адресат принимать длинные кадры.

    Услуги информационного канала (data link service) реализуются через протокол IEEE 802.2 logical link control (LLC). В результате мы имеем следующий стек протоколов (рис. 4.1.6.2):

    IP/ARP

    802.2 llc

    FDDI MAC

    FDDI PHY

    FDDI PMD

    Рис. 4.1.6.2. Схема протокольных подуровней для FDDI

    Уровень MAC (media access control) определяет доступ к сетевой среде, включая формат кадров, адресацию, алгоритм вычисления crc и механизм исправления ошибок. Уровень PHY (physical layer protocol) задает процедуру кодирования/декодирования, синхронизацию, формирование кадров и пр. В качестве базовой используется кодировка 4b/5b (преобразование 4-битного кода в 5-битный), а в канале - NRZI. Уровень PMD (physical layer medium) определяет характеристики транспортной среды, включая оптические каналы, уровни питания, регламентирует частоту ошибок, задает требования к оптическим компонентам и разъемам. Блок схема интерфейса между уровнями MAC и PHY показана на рис. 4.1.6.3.

    Рис. 4.1.6.3. Схема физического интерфейса FDDI

    ip-дейтограммы, ARP-запросы и отклики, пересылаемые по сети FDDI, должны инкапсулироваться в пакеты 802.2 LLC и SNAP (subnetwork access protocol; см. рис. 4.1.6.4 и 4.1.6.5), а на физическом уровне в FDDI MAC. Протокол snap должен использоваться с организационными кодами, указывающими, что SNAP-заголовок содержит код Ethertype. 24-битовый организационный код (organization code) в snap должен быть равен нулю, а остальные 16 бит должны соответствовать Ethertype (см. assigned numbers, RFC-1700; IP=2048, ARP=2054).

    Все кадры должны пересылаться в соответствии со стандартом 802.2 LLC тип 1 (формат ненумерованной информации, с полями DSAP (destination service access point) и SSAP (source service access point) заголовка 802.2, равными предписанным значениям SAP (service access point) для SNAP.

    Рис. 4.1.6.4. Структура некоторых полей заголовков пакетов

    Полная длина LLC- и SNAP-заголовков составляет 8 октетов.

    Десятичное значение k1 равно 170 .
    k2 равно 0.
    Управляющий код равен 3 (ненумерованная информация).

    Для преобразования 16- или 48-разрядного FDDI-адреса в 32-разрядный IP-адрес используется протокол ARP. Операционный код равен 1 для запроса и 2 для отклика. Спецификация FDDI MAC определяет максимальный размер кадра равным 4500 октетам, включая 16-октетную преамбулу. Преамбула состоит из кодов 11111, стартовый разделитель имеет вид 1100010001, а оконечный разделитель - 0110101101 (во всех случаях применена 5-битовая нотация). Контрольная сумма CRC вычисляется для полей, начиная с поля управление по данные включительно.

    Рис. 4.1.6.5. Формат пакета протокола FDDI

    Вычитая 8 байт LLC/SNAP заголовка, получаем значения максимального размера пакета (MTU) 4470 (4478) октетов. Для совместимости размер пакетов для IP-дейтограмм и ARP-пакетов согласуется с требованиями конкретной сети. FDDI реализует маркерный доступ, формат пакета-маркера имеет вид, показанный на рис. 4.1.6.6. В зависимости от размера кольца в нем могут циркулировать несколько маркеров.

    Рис. 4.1.6.6. Формат кадра-маркера

    802.2 класс I LLC требует поддержки команд ненумерованная информация (UI), команд и откликов exchange identification (XID), а также test. Станции не обязаны уметь передавать команды XID и test, но должны быть способны посылать отклики.

    Командные кадры идентифицируются по нулевому младшему биту SSAP-адреса. Кадры-отклики имеют младший бит SSAP-адреса равный 1. UI-команды содержат в управляющем поле LLC код 3.

    Команды/отклики XID имеют код поля LLC, равный 175 (значение десятичное) при значении бита poll/final=0 или 191 при poll/final=1. Код управления LLC для команд/откликов test равен 227, если poll/final=0, и 243 при poll/final=1.

    Отклики и команды UI при poll=1 игнорируются. Команды UI, имеющие отличные от snap sap в DSAP- или SSAP-полях, не считаются пакетами IP или ARP.

    При получении команд XID или test должен быть послан соответствующий отклик. Отклик посылается, когда DSAP равен SNAP SAP (170), null SAP (0), или при global SAP (255). При других DSAP отклики не посылаются.

    При посылке отклика на команды XID или test, значение бита final отклика должно быть равно значению бита poll команды. Кадр отклика XID должен включать в себя информационное поле 802.2 XID 129.1.0, указывающее на класс услуг 1 (не требующих установления связи).

    Кадры отклика test должны соответствовать информационному полю кадра команды test.

    Для начала передачи станция должна получить в свое распоряжение маркер. Если станция находится в пассивном состоянии, она передает маркер следующей станции. Но из-за большой протяженности колец FDDI время задержки здесь заметно больше, чем в случае Token Ring. В кольце FDDI может находиться несколько кадров одновременно. Станция сама удаляет кадры из кольца, посланные ей самой. Все станции должны иметь таймер вращения маркера (TRT - token rotation time), который измеряет время с момента, когда станция последний раз принимала этот пакет. Имеется переменная TTRT (target token rotation time). Значение TRT сравнивается с TTRT и только приоритетные кадры могут быть переданы при TRT> TTRT. Обычная передача данных контролируется таймером THT (token hold timer). Когда станция получает маркер, она заносит TRT в таймер THT, который начинает обратный отсчет. Станция может посылать кадры до тех пор, пока THT остается больше TTRT. В действительности THT определяет максимальное число октетов (символов), которое может быть послано станцией в рамках одного кадра (THT задает предельное время, в течение которого станция может передавать данные).

    IEEE специфицирует числа как последовательности бит, где младший бит передается первым. В протоколах Интернет порядок бит другой, что может вызывать ошибки. Ниже приведена краткая таблица (4.1.6.1) соответствия для некоторых из чисел.

    Таблица 4.1.6.1

    Число

    ieee
    двоичное

    Интернет
    двоичное

    Интернет

    десятичное

    UI

    11000000

    00000011

    3

    SAP для SNAP

    01010101

    10101010

    170

    global SAP

    11111111

    11111111

    255

    null SAP

    00000000

    00000000

    0

    XID

    11110101

    10101111

    175

    XID poll/final

    11111101

    10111111

    191

    XID info

    129.1.0

    test

    11000111

    11100011

    227

    test poll/final

    11001111

    11110011

    243

    Оптоволокно особенно привлекательно для сетей, где ЭВМ размещены в далеко отстоящих друг от друга зданиях и при высоком уровне электромагнитных наводок. Оптоволокно является незаменимой средой для широкополосных каналов связей (вспомним теорему Шеннона). Привлекательна такая среда и с точки зрения надежности (бульдозеры, рвущие кабель, не в счет) и безопасности (отсутствие внешних излучений). Расстояние между станциями при использовании такого кабеля может достигать 8-9 км (а не 2 км, как в случае многомодового кабеля с полосой 500МГц/км). Зарубежные одномодовые кабели группы 1 допускают максимальное расстояние между узлами в 10 км, а группы 2 - 40 км при полосе пропускания 1 Гбит/с. Подключение к сети fddi производится обычно через фотооптические трансиверы (ФОТ), которые преобразуют оптический сигнал в электрический. Источником света является светоизлучающий диод с длиной волны 1350 или 1500 нм. Толщина передающего оптоволокна равна 50/125 или 62.5/125 микрон (числитель - диаметр несущего свет волокна; знаменатель - внешний диаметр клэдинга; числа относятся к мультимодовому волокну). При выборе того или иного кабеля следует иметь в виду, что ослабление более 11дБ не допустимо, при большем ослаблении число ошибок в процессе передачи становится слишком большим. Именно это ограничение ставит верхний предел на длину при использовании многомодового волокна (при длине 2 км ослабление достигает 10,5 дБ). Выбирая оптические разъемы, нужно помнить, что хороший разъем не должен вносить ослабление более 2 дБ. Там где это возможно, предпочтительнее сварка волокон, которая при качественном исполнении вносит ослабление сигнала не более 0,3 дБ. На случай выхода из строя оборудования или отключения питания удобно использовать обводящие оптические переключатели (но они вносят ослабление около 2.5-4 дБ). При их использовании предельное расстояние между узлами должно быть сокращено более чем вдвое. Если видно, что потери достигают критического уровня, следует выбирать кабель с волокном 62.5/125 микрон. При прокладке оптического кабеля нельзя допускать слишком малых радиусов перегибов (возможен обрыв волокна, увеличиваются потери света). Кабели, относящиеся к разным кольцам fddi, следует разнести, в этом случае один бульдозер не сможет оборвать сразу оба кабеля.

    FDDI-кадры используют заголовки, определяемые стандартом IEEE 802.2 (LLC - logical link control), который не имеет поля тип, присутствующий в Ethernet-заголовке. FDDI и ethernet имеют разный порядок передачи битов, поэтому мосты и маршрутизаторы между FDDI и Ethernet должны уметь выполнять соответствующие преобразования. В силу особенностей маршрутизаторов не все протоколы могут быть реализованы на стыке FDDI и Ethernet (например, DEC LAT работать не будет). Для решения проблемы созданы гибридные приборы (brouter), которые для одних протоколов работают как маршрутизаторы, являясь мостами для других. Эти приборы для одних пакетов прозрачны, другие же пересылаются с использованием инкапсуляции. Учитывая то, что FDDI может пересылать до 400000 пакетов в секунду, схемы распознавания адресов моста должна иметь соответствующее быстродействие.

    Нетрадиционным для других сетей является концентратор, используемый в FDDI. Он позволяет подключить несколько приборов SAS-типа к стандартному FDDI-кольцу, создавая структуры типа дерева. Но такие структуры несут в себе определенные ограничения на длины сетевых элементов, так при использовании повторителя удаление не должно превышать 1,5 км, а в случае моста 2,5 км (одномодовый вариант). Несмотря на эти ограничения и то, что базовой топологией сетей FDDI является кольцо, звездообразные варианты также имеют право на жизнь, допустимы и комбинации этих топологий. В пределах одного здания подключение целесообразно делать через концентратор, отдельные же здания объединяются по схеме кольцо. К кольцу FDDI могут также легко подключаться и субсети Token Ring (через мост или маршрутизатор).

    Концентраторы бывают двух типов: DAS и SAS. Такие приборы повышают надежность сети, так как не вынуждают сеть при отключении отдельного прибора переходить в аварийный режим обхода. Применение концентраторов снижает и стоимость подключения к FDDI. Концентраторы могут помочь при создании небольших групповых субсетей, предназначенных для решения специфических задач (например, CAD, CAM или обработка изображений).

    Новым устройством, используемым в FDDI-узлах, являются межузловые процессоры (internetwork nodal processor - INP), которые являются развитием идей front end processor (FEP). INP, благодаря модульности, может помочь пользователю адаптироваться к изменениям, постоянно происходящим в сетях, где он работает. INP может выполнять функции многопротокольного моста или маршрутизатора. Управление FDDI-оборудованием производится с помощью протокола SNMP и базы данных MIB. Предусмотрены некоторые дополнительные диагностические средства, которые выявляют не только аппаратные сбои, но и некоторые программные ошибки. Применение мостов для объединения FDDI-сетей позволяет обеспечить высокую степень сетевой безопасности и решить многие топологические проблемы, снять ограничения с предельного числа DAS-подключений (<500). Выбор между мостом и маршрутизатором определяется тем, что важнее, стоимость, гибкость системы илу высокая пропускная способность.

    На рис. 4.1.6.7 показан пример использования сети FDDI для доступа нескольких субсетей к общему серверу без взаимного влияния потоков данных. Сегменты 1 и 2 представляют собой субсети Ethernet (10 Мбит/с). Учитывая то, что FDDI имеет пропускную способность 100 Мбит/с, даже при подключении 10 субсетей взаимовлияние их будет практически отсутствовать. Два кольца FDDI, показанные на рис. 4.1.6.7, могут быть объединены друг с другом через мост или маршрутизатор. Сетям FDDI благодаря маркерному доступу не знакомы столкновения в том виде, в каком они существуют в Ethernet и это дает им определенное преимущество перед сетями равного быстродействия, например перед быстрым Ethernet (также 100 МГц). Существует версия FDDI приспособленная для передачи мультимедийной информации. Возможна реализация FDDI на скрученных парах проводов.

    Рис. 4.1.6.7. Схема использования кольца FDDI для расширения пропускной способности локальной сети

    При обрывах оптоволокна возможно частичное (при двух обрывах) или полное (при одном обрыве) восстановление связности сети.

    Рис. 4.1.6.8. Варианты связей в случае обрывов волокон

    Previous: 4.1.5 Локальные сети ArcNet    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.7 Параллельный сетевой интерфейс HIPPI


    previous up down next index index
    Previous: 4.1.6 Сети FDDI    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.8 Сети IEEE 802.11

    4.1.7 Параллельный сетевой интерфейс HIPPI
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Все рассматриваемые до сих пор системы передачи информации использовали исключительно последовательный код. На разных этапах эволюции телекоммуникаций предпочтение отдавалось и параллельному и последовательному методам обмена данными. В данный момент параллельный интерфейс сохранился только для подключения принтеров. Главным преимуществом последовательных схем передачи информации является экономия на кабелях. Ниже описан еще один стандарт, где применен параллельный интерфейс (начало разработки относится к 1987 году). HIPPI (high performance parallel interface, смотри ftp.network.com; http://www.cern.ch/hsi/hippi/spec/introduc.htm; RFC-2067, IP over HIPPI, J.Renwick; RFC-1374, IP and ARP on HIPPI, J.Renwick, ANSI x3t9.3/90-043, 1990 и X3t9.3/91-005) представляет собой быстродействующий параллельный интерфейс, рассчитанный на пропускную способность 800 Мбит/с (но возможны версии со 100, 200 400 и 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе. Позднее на базе этого интерфейса была подготовлена идеология сети.

    Длина кода, передаваемого за один такт в HIPPI, составляет 32 разряда (версия HIPPI, рассчитанная на скорость 1600 Мбит/с, имеет длину кода 64 бита). Все пересылки являются симплексными. Существует стандарт Superhippi (HIPPI-6400, 6,4 Гбайт/с), который описывает систему передачи данных в 8 раз более быстродействующую, чем HIPPI. Разработана версия последовательного HIPPI на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного кабеля (до 10км; версия HIPPI-FC - fiber channel). Максимальное расстояние между станцией и переключателем составляет 25 м. Максимальное дистанция между станциями (станция-переключатель-станция) равно 50 м. Предельное число станций зависит от типа используемых переключателей. Переключатели могут взаимодействовать друг с другом (HIPPI-SC), обеспечивая информационный обмен между станциями. Пример топологии сети hippi представлен на рис. 4.1.7.1.

    Рис. 4.1.7.1. Пример топологии сети hippi (П - переключатели, С - станции)

    HIPPI предполагает передачу данных по медному кабелю (или оптическому волокну) только в одном направлении по схеме связи точка-точка, но два канала HIPPI могут обеспечить и двунаправленный обмен данными. Передающий кабель может содержать 50/100 скрученных пар или соответствующее число оптических волокон. Длина пакета данных может варьироваться. Протокол HIPPI рассчитан на работу в реальном масштабе времени при суммарных длинах кабелей до десятков километров. Стандартный блок данных содержит 256 слов (1024 или 2048 байт). Для контроля корректности передачи предусмотрен контроль по четности для каждого байта на шине, кроме того, для каждого блока данных вычисляется "продольная" контрольная сумма (LLRC - length/longitudinal redundancy checkword). На рис. 4.1.7.2 показана схема передачи данных в рамках протокола HIPPI. На каждое соединение может быть передано любое число пакетов, пакет в свою очередь может содержать любое число блоков. Время между пакетами не регламентировано и может меняться, оно зависит от потока данных и протокола верхнего уровня.

    Рис. 4.7.1.2. Структура передаваемой информации (каждое слово содержит 32 или 64 бита)

    Каждый пакет содержит в конце субполе контроля четности. Все сигналы кроме соединения (interconnect) используют приемники и передатчики эмиттерно-связанной логики (ECL). Формат I-поля показан на рис 4.1.7.3.

    Рис. 4.1.7.3. Формат i-поля пакета HIPPI

    Поле L=1 - локально заданный формат; W=1 указывает на 64-битное соединение; D=1 отмечает смену положения адресов отправителя и получателя; PS - биты выбора пути (path selection); С - задержка вызова при занятой линии (camp-on; переключатель не разрывает соединения при занятом получателе, а ждет его освобождения). 12-битовые адреса отправителя и получателя часто делятся на 6-битовые секции, определяющие адрес переключателя и номер порта. HIPPI-IPI (intelligent peripheral interface) представляет собой быстродействующий интерфейс периферийных устройств, выполняющий команды SCSI. Расширение HIPPI-LE (link encapsulation) обеспечивает поддержку IEEE 802.2.

    При расстояниях до 25 метров используется кабель, содержащий 50 скрученных пар. Такты часов следуют с периодом 40 нсек. В сетях HIPPI предусмотрен транзит пакетов формата TCP/IP. Блок-схема канала HIPPI показана на рис. 4.1.7.4.

    Рис. 4.1.7.4. Блок-схема канала HIPPI

    Существуют документы, регламентирующие работу системы передачи информации HIPPI для основных уровней интерфейса, начиная с физического. Предусмотрена работа HIPPI с протоколами TCP/IP. Смотри также "ARP and IP Broadcast over HIPPI-800". J.-M. Pittet. May 2000, RFC-2834, "IP and ARP over HIPPI-6400 (GSN)". J.-M. Pittet. May 2000, RFC-2835.

    Previous: 4.1.6 Сети FDDI    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.8 Сети IEEE 802.11


    previous up down next index index
    Previous: 4.1.7 Параллельный сетевой интерфейс HIPPI    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.8.1 Мобильные телекоммуникации

    4.1.8 Сети IEEE 802.11
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Технология беспроводных сетей развивается довольно быстро. Эти сети удобны для подвижных средств в первую очередь. Наиболее перспективным представляется проект IEEE 802.11, который должен играть для радиосетей такую же интегрирующую роль как 802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе 802.11 используется тот же алгоритм доступа и подавления cтолкновений, что и в 802.3, но здесь вместо соединительного кабеля используются радиоволны (Рис. 4.1.8.1.)

    Рис. 4.1.8.1. Схема беспроводной локальной сети

    Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц при использовании 4FSK/2FSK FHSS модуляции, мощность передатчика 10мВт-1Вт. Максимальная пропускная способность сети составляет 2 Мбит/с.

    В 1992 году страны члены ЕС выделили диапазон частот 1,89-1,9 ГГц для целей построения сетей, базирующихся на применение радиосигналов (стандарт DECT - Digital European Cordless Telecommunications). Этот стандарт был разработан для целей передачи данных и голоса в системах сотовой связи. В США для этих же целей используются широкополосные системы с шумоподобным сигналом (SST - ШПС). Для подобных же целей выделены также частотные диапазоны 18 и 60ГГц (диапазон 2,4 ГГц сильно перегружен и "засорен" шумами). Существуют уже системы базирующиеся на Ethernet и Token Ring.

    При относительно малых расстояниях проблем обычно не возникает и работу беспроводной сети действительно можно аппроксимировать алгоритмом CSMA. Но в случае, когда расстояние между передатчиком и приемником сравнимо с радиусом надежной связи, отличие от традиционных сетей становится значительным. Ведь для радиосетей важна интерференция на входе приемника, а не на выходе передатчика (как в CSMA). Рассмотрим вариант сети, изображенный на рис. 4.1.8.2. Если передачу осуществляет узел А, узел С находится вне его радиуса действия и может решить, что можно начать передачу. Излучение передатчика С может вызвать помехи на входе узла В (проблема скрытой станции).

    Рис. 4.1.8.2. Схема взаимодействия узлов в беспроводной сети (MACA)

    В случае, когда передачу ведет узел В, узел С может решить, что начало передачи сообщения узлу D не возможно, так как в зоне С детектируется излучение станции В (проблема засвеченной станции). Таким образом, в радиосетях, прежде чем начать передачу данных надо знать, имеется ли радио активность в зоне приемника-адресата. В коротковолновых сетях возможна одновременная передача для нескольких адресатов, если они находятся в разных зонах приема.

    Ранние протоколы беспроводных локальных сетей базировались на схеме MACA (Multiple Access with Collision Avoidance), разработанной Ф. Карном в 1990 году. Эта схема является основой стандарта IEEE 802.11. В этой схеме отправитель запрашивает получателя послать короткий кадр, будучи принят соседями, предотвратит их передачу на время последующей передачи сообщения адресату. На рис. 4.1.8.2 узел В посылает кадр RTS (Request To Send) узлу C. Этот кадр имеет всего 30 октетов и содержит поле длины последующего сообщения. Узел C откликается посылкой кадра CTS (Clear To Send), куда копируется код длины последующего обмена из кадра RTS. После этого узел В начинает передачу. Окружающие станции, например D или E, получив CTS, воздерживаются от начала передачи на время, достаточное для передачи сообщения оговоренной длины. Станция A находится в зоне действия станции B, но не станции C и по этой причине не получит кадр CTS. По этой причине станция A может начинать передачу, если хочет и не имеет других причин, препятствующих этому. Несмотря на все предосторожности коллизия может иметь место. Например, станции A и C могут одновременно послать кадры RTS станции B. Эти кадры будут неизбежно потеряны, после псевдослучайной выдержки эти станции могут совершить повторную попытку (как в ETHERNET).

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

    К сожалению беспроводные, особенно мобильные каналы крайне ненадежны. Потери пакетов в таких каналах весьма вероятны. Понижение скорости передачи, как правило, не приводит к понижению вероятности потери. Кроме того, проходы от отправителя к получателю здесь неоднородны и могут включать в себя сегменты с различными методами транспортировки данных (проводные и беспроводные). В таких структурах бывает полезно разбить канал на две последовательные связи (indirect TCP). Преимуществом такой схемы является то, что оба виртуальных канала являются однородными. Таймауты в одном из соединений заставят отправителя замедлить темп передачи, в то время как таймауты во втором - могут ускорить обмен. Да и все остальные параметры связей могут оптимизироваться независимо. Основной недостаток этого приема заключается в нарушении базового принципа организации TCP-соединений на основе сокетов, здесь получение подтверждения отправителем не означает благополучной доставки. В 1995 году была предложена схема, не нарушающая TCP-семантику. В этой схеме вводится специальный агент-наблюдатель, который отслеживает состояние кэшей отправителя и получателя и посылает подтверждения. Этот агент при отсутствии своевременного подтверждения запускает процедуру повторной посылки сегмента, не информируя об этом первичного отправителя. Механизмы подавления перегрузки запускаются в этом варианте только при перегрузке проводной секции канала. При потерях реализуется выборочная пересылка сегментов.

    При работе с UDP также возникают некоторые трудности. Хотя известно, что UDP не гарантирует доставки, большинство программ, предполагает, что вероятность потери невелика. Программы используют такие способы преодоления потерь, которые при высокой вероятности потери просто не срабатывают. Многие приложения предполагают наличие достаточного запаса пропускной способности, чего в случае мобильной связи обычно нет.

    В последнее время в продажу поступили радио-интерфейсы (IEEE 802.11b) для персональных ЭВМ, которые позволяют создавать небольшие офисные сети. Пригодны они и для подключения к каналам Интернет, но в этом случае следует позаботиться о специальной антенне. Такие интерфейсы работают на несущей частоте 2,4-5,0 ГГц и обеспечивают пропускную способность 11-22Мбит/с при расстояниях 700-5000м. Особую привлекательность такие интерфейсы представляют для мобильных ЭВМ. См. LANline Spezial VII/2002, Nov/Dez s16; LANline

    Previous: 4.1.7 Параллельный сетевой интерфейс HIPPI    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.8.1 Мобильные телекоммуникации


    previous up down next index index
    Previous: 4.1.8 Сети IEEE 802.11    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.9 Сети DQDB (двойная шина с распределенной очередью)

    4.1.8.1 Мобильные телекоммуникации
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В 80-х - 90-х годах весьма активное развитие получила мобильная телефония. В последнее время услуги мобильной связи стали применяться и для передачи цифровых данных. Мобильные телекоммуникации использует диапазоны в интервале 50 МГц - 1 ГГц. Мобильные системы работают при малых выходных мощностях передатчика, что ограничивает размер зоны приема. Вне этой зоны другие передатчики могут функционировать независимо. Такие зоны называются сотами (ячейками). По аналогии с пчелиными сотами их часто изображают шестигранными, хотя реально они могут иметь самую причудливую форму в зависимости от профиля местности. Ячейки должны перекрываться, так как показано на рис. 4.1.8.1.1

    Рис. 4.1.8.1.1. Схема расположения ячеек при сотовой связи

    Светлыми кружками отмечены реальные границы ячеек, их перекрытие должно обеспечить перекрытие всей зоны телекоммуникаций. В центре ячейки находится базовая станция ретранслятор. Такая станция содержит в себе ЭВМ и приемо-передатчик, соединенный с антенной. Такие системы могут обслуживать пейджерную или мобильную телефонную сеть. Пейджерные каналы однонаправлены а телефонные двунапрвлены (см. рис. 4.1.8.1.2). Пейджинговые системы требуют небольшой полосы пропускания. А одно сообщение редко содержит более 30 байт. Большинство современных пейджигновых систем работает в частотном диапазоне 930-932 МГц (старые занимали 150-174 МГц).

    Рис. 4.1.8.1.2. Каналы пейджерной (слева) и мобильной телефонной сети (справа).

    В небольших системах все базовые станции соединены с MTSO(mobile telephone switching office). В больших сетях может потребоваться несколько MTSO, которые в свою очередь управляются mtso следующего уровня и т.д.. Узловая MTSO соединена со станцией коммутируемой телефонной сети. В любой момент времени каждый мобильный телефон логически находится в одной определенной ячейке и управляется одной базовой станцией. Когда телефон покидает ячейку, базовая станция обнаруживает падение уровня сигнала и запрашивает окружающие станции об уровне сигнала для данного аппарата. Управление аппаратом передается станции с наибольшим входным сигналом. Телефон информируется о смене управляющей станции, при этом предлагается переключиться на новый частотный канал (в смежных ячейках должны использоваться разные частотные каналы). Процесс переключения занимает около 300 мсек (handoff), что должно быть практически незаметно для пользователя. Присвоением частот управляет MTSO. Сигнал передатчика падает по мере удаления от центра ячейки, где он должен быть расположен. Там же должен находиться и приемник. В пределах ячейки предусмотрено несколько каналов для приема/передачи, разнесенные по частоте. Эти каналы управляются центральным коммутатором ячейки (MSC - mobile-service switching centre).

    В рамках американского стандарта первого поколения AMPS (advanced mobile phone service; 1982) формируется 40 МГц канал в интервале 800-900 МГц. Система использует 832 полнодуплексных каналов. Данный частотный диапазон делится пополам, 20 МГц выделяется для передачи и столько же для приема. Данные диапазоны делятся в свою очередь на 666 двусторонних каналов, каждый по 30 кГц. Эти каналы расщепляются на 21 субканал, сгруппированные по 3. Обычно, как показано на рис. 4.1.8.1.1, гексагональные ячейки группируются по 7 (центральная и 6 ее соседей). Имея 666 каналов, можно выделить три набора по 31 каналу для каждой ячейки. Такая схема удобна в случае возникновения необходимости увеличения числа каналов, для этого достаточно уменьшить размер ячейки - число ячеек увеличится и, как следствие, увеличится число каналов на единицу площади. В хорошо спланированной сети плотность ячеек пропорциональна плотности пользователей. AMPS для разделения каналов использует метод мультиплексирования по частоте.

    Каждый мобильный телефон в amps имеет 32-битовый серийный номер и телефонный номер, характеризуемый 10 цифрами. Телефонный номер представляется как код зоны (3 десятичные цифры) и номер подписчика (7 десятичных цифр). Когда телефон включается, он сканирует список из 21 управляющих каналов и находит тот, у которого наиболее мощный сигнал. Управляющая информация передается в цифровой форме, хотя сам голосовой сигнал является аналоговым. При нормальной работе мобильный телефон перерегистрируется в MTSO (mobile telephone switching office) каждые 15 мин.

    При осуществлении вызова пользователь набирает номер телефона и нажимает кнопку send. Аппарат посылает набранный номер и свой идентификационный код. Базовая станция принимает вызов и передает его MTSO. Если звонящий является клиентом mtso или ее партнером, ишется свободный канал и мобильный телефон переключается на него, ожидая когда адресат снимет трубку.

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

    Аналоговые сотовые телефоны не обеспечивают конфиденциальности. С помощью широкополосного сканера можно зафиксировать вызов и осуществить прослушивание. Другим недостатком является возможность кражи эфирного времени. Вседиапазонный приемник, подключенный к ЭВМ, может записать 32-битовый серийный номер и 34-битовый телефонный номер всех телефонов, работающих поблизости. Собрав такие данные вор может по очереди пользоваться любым из перехваченных номеров.

    AMPS базируется на аналоговой модуляции, существует еще полдюжины аналогичных не стыкуемых друг с другом систем. В последнее время аналоговая модуляция повсеместно вытесняется цифровой. В Европе принят единый стандарт для систем мобильной связи GSM (groupe special mobile, второе поколение мобильных средств связи). gsm использует диапазоны 900 и 1800 МГц. Это довольно сложный стандарт, его описание занимает около 5000 страниц. Идеологически система имеет много общего с ISDN (например, переадресацию вызовов). GSM имеет 200 полнодуплексных каналов на ячейку, с полосой частот 200 кГц, что позволяет ей обеспечить пропускную способность 270,833 бит/с на канал. Каждый из 124 частотных каналов делится в GSM между восемью пользователями (мультиплексирование по времени). Теоретически в каждой ячейке может существовать 992 канала, на практике многие из них недоступны из-за интерференции с соседними ячейками.

    Система мультиплексирования по времени имеет специфическую структуру. Отдельные временные домены объединяются в мультифреймы. Упрощенная схема структуры показана на рис. 4.1.8.1.3.

    Рис. 4.1.8.1.3. Структура кадров в GSM

    Каждый временной домен (TDM) содержит 148-битовый кадр данных, начинающийся и завершающийся последовательностью из трех нулей. Кадр имеет два 57-битовых поля данных, каждое из которых имеет специальный бит, который указывает на то, что лежит в кадре - голос или данные. Между информационными полями размещается поле синхронизации (Sync). Хотя информационный кадр имеет длительность 547 мксек, передатчику позволено передавать его лишь раз в 4615 мксек, так остальное время зарезервировано для передачи другими станциями. Если исключить накладные накладные расходы каждому соединению выделена полоса (без учета сжатия данных) 9600 кбит/с.

    Восемь информационных кадров образуют TDM-кадр, а 26 TDM-кадров объединяются в 128-микросекундный мультифрейм. Как видно из рисунка 4.1.8.1.2 позиция 12 в мультифрейме занята для целей управления, а 25-я зарезервирована для будущих применений. Существует также стандарт на 51-позиционный мультифрейм, содержащий больше управляющих вставок. Управляющий канал используется для регистрации, актуализации положения и формирования соединения. Каждая стационарная станция поддерживает базу данных, где хранится информация обо всех обслуживаемых в данный момент клиентах. Общий управляющий канал делится на три субканала. Первый служит для обслуживания вызовов (paging channel), второй (random access channel) реализует произвольный доступ в рамках системы ALOHA (устанавливаются параметры вызова). Третий субканал служит для предоставления доступа (access grant channel).

    Алгоритмы обслуживания мобильной связи достаточно нетривиальны. Из рисунка 4.1.8.1.1 видно, что области перекрываются (иначе бы существовали "мертвые" зоны без связи). Существуют даже субобласти, накрываемые тремя MSC. По это причине процедура должна четко определить, с каким из MSC клиент должен быть связан, и при каких условиях его следует переключить на соседний MSC, не прерывая связи. Система должна также компенсировать падение сигнала, иногда достаточно резкое, чтобы обеспечить комфортную связь и безошибочную передачу информации. По этой причине частота ошибок (BER) в таких сетях составляет 10-3 (против 10-6 для обычных стационарных цифровых каналов связи). Следует иметь в виду, что в условиях города сигнал падает пропорционально не квадрату, а четвертой степени расстояния. На распространение радиоволн в городе влияют ориентация улиц (до 20 дБ), туннели (до 30 дБ) и листва деревьев в сельской местности (до 18 дБ).

    GSM - система базирующаяся в основном на коммутации каналов. Применение модема на переносной ЭВМ позволяет подключиться к сети Интернет. Но здесь не все беспроблемно. Базовые станции временами теряют связь друг с другом (переключение с канала на канал), что может приводить к 300 миллисекундным потери данных. Как уже говорилось выше, здесь высока вероятность ошибок. Так, нажав клавишу "a", можно получить на экране букву "я". Да и расценка за минуту работы в Интернет здесь весьма высока. В связи с этим был разработан стандарт на цифровую систему коммутации пакетов CDPD (Cellular Digital Packet Data). Система работает поверх AMPS. Система обеспечивает информационную пропускную способность на уровне 9,6 кбит/с. CDPD довольно точно следует модели OSI. В CDPD определены три типа интерфейсов. Е-интерфейс (внешний по отношению CDPD-провайдеру) соединяют CDPD-область с определенной сетью. I-интерфейс (внутренний по отношению CDPD-провайдеру) соединяет CDPD-области друг с другом. A-интерфейс (эфирный) используется для связи базовой станции с мобильной ЭВМ. В функции этого интерфейса входит сжатие и шифрование данных, а также исправление ошибок. 274-битные блоки сжатой и зашифрованной информации вкладываются в 378-битовые блоки, предназначенные для коррекции ошибок согласно алгоритму Рида-Соломона. К каждому такому блоку добавляется семь 6-битовых флагов. Результирующие блоки имеют 420 бит и передаются в виде семи 60-битовых микроблоков. Эти микроблоки передаются к базовой станции со скоростью 19,2 кбит/с. Канал с аналогичным быстродействием создается для пересылки информации в противоположном направлении. При обмене применяется мультиплексирование с делением по времени. При этом временные домены имеют длительность 3,125 мсек (60 бит).

    Когда мобильная ЭВМ хочет что-то передать, прослушивается канал базовой станции и проверяется флаг, сообщающий, свободен ли входной канал базовой станции. Если канал занят, ЭВМ вместо ожидания до очередного временного домена, пропуская псевдослучайное число временных доменов, после чего повторяет попытку. Если повторная попытка неудачна, время ожидания увеличивается примерно вдвое. Когда, наконец, ЭВМ обнаруживает, что канал свободен, она начинает пересылку своих микроблоков. Предусмотрена процедура, препятствующая попытке всех ЭВМ, готовых к передаче, захватить канал, как только он оказался свободным. Этот алгоритм называется DSMA (Digital Sense Multiple Access). Но, несмотря на применение DSMA, столкновение все же возможно, так как две или более ЭВМ могут воспользоваться одним и тем же временным доменом для начала передачи. Для выявления столкновений предусмотрен специальный флаг, который позволяет судить, корректно ли доставлен предыдущий микроблок. К сожалению это происходит не мгновенно а лишь спустя несколько микроблоков. При обнаружении ошибки передача прерывается. Следует иметь в виду, что информационный обмен имеет более низкий приоритет по отношению передачи голосовых данных. Предусмотрена возможность создания выделенных CDPD-каналов.

    GSM использует довольно сложную комбинацию методик ALOHA, TDM и FDM. CDPD для передачи одиночных кадров не вполне согласуется с алгоритмом CSMA. Впрочем существует еще один метод формирования радио каналов - CDMA (Code Division Multiple Access).

    Метод CDMA принципиально отличается от описанных выше, которые использовали для дультиплексирования доступа FDM, TDM или ALOHA. CDMA позволяет каждой станции осуществлять передачу во всем частотном диапазоне постоянно. Множественные передачи реализуются с привлечением теории кодирования. Здесь предполагается, что сигналы, совпадающие по времени складываются линейно. В CDMA каждый бит-тайм делится на m коротких интервалов, называемых чипами. Обычно используется 64 или 128 чипов на бит. Каждой станции присваивается уникальный m-битный код (chip sequence). Чтобы передать 1 бит станция посылает свой чип-код. Для простоты далее будем предполагать, что m=8. Для того чтобы послать нулевой бит, посылается дополнение чип-кода по модулю один. Никакие другие кодовые последовательности не разрешены. Например, пусть станции 1 поставлен в соответствие чип-код 01010101, тогда при посылке логической 1 она отправляет код 01010101, а при отправке логического нуля - 10101010. Если имеется канал с полосой 1 МГц и 100 станций с FDM, то каждая из них получит по 10 КГц (10 кбит/c при 1 бите на Гц). При CDMA каждая станция использует весь частотный диапазон, так что будет получена скорость передачи 1 мегачип в секунду. При менее 100 чипов на бит CDMA обеспечивает большую пропускную способность, чем FDM. Для упрощения введем двуполярную нотацию, где нулю соответствует -1, а единице +1. Тогда чип-код станции 1 получит вид -1 +1 -1 +1 -1 +1 -1 +1. Каждая из станций получает уникальный чип-код. Чип-коды можно представить в виде m-компонентных векторов. Чип-коды выбираются так, что все они попарно ортогональны (не любой уникальный чип-код пригоден, так, если станция 1 имеет чип-код 01010101, то станция 2 не может иметь чип-код 10101001, но чип-код 10100101 вполне допустим). Математически это можно выразить следующим образом:

    ,

    где Hi и Gi компоненты векторов чип-кодов H и G. Это равенство указывает, что число разных компонентов равно числу равных. Если G и H ортогональны, то и =0. В то же время:

    [1]

    Когда сигналы от разных станций совпадают во времени и складываются, принимающая сторона легко может вычислить наличие соответствующей компоненты. Если компоненты суммарного сигнала Si, то компоненты Gi вычисляются с помощью произведения Si*H. Действительно, если:

    Здесь первые два слагаемых равны нулю в силу ортогональности выбранных чип-кодов. Последнее же слагаемое равно 1 согласно [1]. Во всех этих рассуждениях предполагалось, что все станции работают синхронно и начинают передачу чип-кодов одновременно.

    Для пояснения метода рассмотрим конкретный пример в выше предложенной нотации. присвоим станциям F, G, H, I ортогональные чип-коды:

    F=01010101 → -1 +1 -1 +1 -1 +1 -1 +1
    G=10100101 → +1 -1 +1 -1 -1 +1 -1 +1
    H=10011001 → +1 -1 -1 +1 +1 -1 -1 +1
    I=11111111 → +1 +1 +1 +1 +1 +1 +1 +1

    Теперь рассмотрим четыре варианта наложений:

    Только F → S1=[-1 +1 -1 +1 -1 +1 -1 +1]
    F+I → S2=[0 +2 0 +2 0 +2 0 +2]
    F+G+H → S3=[+1 -1 -1 +1 -1 +1 -3 +3]
    → S4=[-1 +1 -3 +3 +1 -1 -1 +1]

    Для выявления наличия компоненты G выполним операции "умножения" согласно описанным выше правилам.

    S1*G =[-1 -1 -1 -1 +1 +1 +1 +1]/8=0 (G отсутствует)
    S2*G =[0 -2 0 -2 - +2 0 +2]/8=0 (G отсутствует)
    S3*G =[+1 +1 -1 -1 +1 +1 +3 +3]/8=1 (G имеется - передана логическая 1)
    S4*G =[-1 -1 -3 -3 -1 -1 +1 +1]/8=-1 (G имеется - передан логический 0)

    Хотя теоретически здесь все прекрасно, наложение слишком большого числа чип-кодов может создать проблемы и, в конечном итоге, привести к ошибкам.

    Идеальная мобильная система связи представляется в виде телефонной трубки, которой человек пользуется дома, в автомобиле, в отпуске или командировке. При этом телефонный номер не меняется, где бы вы не находились. Такая система разрабатывается в настоящее время и называется PCS (Personal Communication Services) в США. В остальном мире эта система имеет имя PCN (Personal Communications Network). PCS использует технику сотовой телефонной сети. Но здесь размер ячейки лежит в пределах 50-100 м (против 20 км для AMPS). Это позволяет работать с малой выходной мощностью порядка 0,25 Вт и понизить вес аппарата. При этом для покрытия той же области требуется в 40000 раз больше ячеек и, следовательно, такая система будет значительно дороже даже с учетом более низкой цены одной ячейки. Некоторые телефонные компании осознали, что старомодные телеграфные столбы являются идеальным местом для размещения базовых станций новой системы (провода уже имеются!). Для системы PCS зарегервирован диапазон частот 1,7-2,3 ГГц.

    Previous: 4.1.8 Сети IEEE 802.11    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.9 Сети DQDB (двойная шина с распределенной очередью)


    previous up down next index index
    Previous: 4.1.8.1 Мобильные телекоммуникации    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.10 Сети с многокаскадными соединениями

    4.1.9 Сети DQDB (двойная шина с распределенной очередью)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Сети с двойной шиной и распределенной очередью (DQDB - distributed queue dual bus) используют алгоритм доступа, называемый распределенное переключение пакетов (QPSX - queued-packet distributed-switch). Здесь используется две несвязанные однонаправленные шины, сформированные из цепочки соединений точка-точка. Описание работы сети содержится в документе IEEE 802.6. Пропускная способность сети составляет 150 Мбит/с (планируется 600 Мбит/с). Максимально возможная длина сети составляет 160 км. Максимальное число узлов равно 512. В качестве транспортной среды можно использовать одно- и мультимодовое оптическое волокно (длина волны 1300 нм). Схема кодирования 8В/9В при представлении сигнала NRZI. средняя частота ошибок (BER) составляет 10-9. По сетям DQDB пересылаются также как и по ATM-каналам ячейки фиксированного размера (L=53 байта). Формат поля данных совместим с некоторыми типами AAL. Формат пакета показан на рис 4.1.9.1

    Рис. 4.1.9.1. Формат ячейки DQDB (цифры в верхней части рисунка характеризуют длины полей)

    Поле ST (segment type) характеризует тип сегмента. Поле MID (message identifier) представляет собой идентификатор сообщения. LEN -характеризует длину поля данных, а CRC - это контрольная сумма ячейки. Когда станция намерена передать ячейку, она должна знать, справа или слева от нее находится место назначения. Если место назначения справа, отправитель использует шину А, в противном случае передача производится по шине В. Для ввода данных на шину применяется схема проволочного ИЛИ. По этой причине обесточенная станция не вызовет отказа всего сегмента сети. Станция образуют очередь для передачи в порядке поступления заявок (fifo). Структура заголовка ячейки показана на рис. 4.1.9.2 она весьма схожа с той, что имеет ячейка atm.

    Рис. 4.1.9.2. Формат заголовка DQDB-пакета

    Поле ACF (access control field) служит для управления доступом. Поле VCI (virtual cannel identifier) - виртуальный идентификатор канала. Далее следуют поля:

    PT

    (payload type) 4 бита типа данных (коды аналогичны atm);

    CLP

    (cell loss priority) - уровень приоритета при потере пакета. Указывает на то, какой приоритет имеет ячейка, и будет ли она отброшена в случае переполнения канала (как и в ATM);

    HEC

    (header error control) поле контроля ошибок (crc заголовка).

    Ячейка DQDB отличается от ячейки ATM тем, что не содержит поля VPI (идентификатор виртуального пути), а поле VCI имеет на 4 бита больше. Упрощенная схема подключения узлов к сети показана на рис. 4.1.9.3. Шины А и Б служат для передачи ячеек в противоположных направлениях. Если станция намерена передать ячейку по шине Б, она должна выполнить резервирование заранее на шине А, осуществив запись 1 в бит request соответствующей ячейки.

    Рис. 4.1.9.3. Топология сети DQDB

    Каждый из узлов подключен к обеим шинам. По каждой из шин всегда циркулирует фиксированное число контейнеров. Содержимое контейнеров может передаваться с одной шины на другую. В сети DQDB используются следующие типы сегментов:

    • одиночный сегмент (не нужно никакой сегментации);
    • первый сегмент (первая ячейка сегментированного МАС-кадра);
    • промежуточный сегмент фрагментируемого mac-кадра;
    • последний сегмент (последняя ячейка сегментированного МАС-кадра)

    Поле MID остается идентичным для всех DQDB ячеек сегментированного МАС-кадра. Поле ACF содержит биты busy и request, которые используются в рамках механизма qpsx. Бит busy=1 указывает на то, что ячейка занята. Бит request=1 устанавливается узлом, который ждет возможности начать передачу. В каждом узле имеется счетчик запросов RC(request counter), который фиксирует число узлов, ожидающих передачи и стоящих в очереди впереди данного узла. Содержимое счетчика увеличивается всякий раз, когда по шине А проходит контейнер с битом busy=1. Счетчик декрементируется при появлении на шине Б контейнера со свободным битом request. Когда станция сама намеривается передать кадр, содержимое RC переносится в реверсивный счетчик DC, а в регистр RC заносится нуль. Код в DC уменьшается на единицу при получении контейнера с битом busy=1. DC определяет положение запроса в очереди (нуль соответствует началу очереди). Если получен контейнер с request=0 и DC=0, узел может передать ячейку по данной шине. Каждый узел может осуществлять передачу и прием по любой из шин А и Б. В сети DQDB предусмотрено 4 уровня приоритетов и каждый узел поддерживает до 5 очередей с RC и DC счетчиками для каждой из очередей. Для индикации приоритета в поле ACF предусмотрено 4 двоичных разряда (R1, R2, R3 и R4). Высшему приоритету соответствует R4. Схема сегментирования MAC-кадра при передаче с помощью DQDB ячеек показана на рис. 4.1.9.4.

    Рис. 4.1.9.4. Сегментация МАС-кадра

    Сети DQDB могут иметь размер до 160 км при скорости передачи данных 44,736 Мбит/с (Т3).

    Previous: 4.1.8.1 Мобильные телекоммуникации    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.10 Сети с многокаскадными соединениями


    previous up down next index index
    Previous: 4.1.9 Сети DQDB (двойная шина с распределенной очередью)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.11 Сети 100Base-VG

    4.1.10 Сети с многокаскадными соединениями
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Среди традиционных сетей особое положение занимают сети, базирующиеся на большом числе идентичных ключевых элементов. Это сети с многокаскадными связями (MIN - Multistage Interconnection Network). Идеология таких сетей используется при построении коммутаторов ATM. Из таких сетей наиболее известной является Delta Banyan (Batcher-switch). Эта сеть содержит регулярную структуру N*N переключателей с двух направлений на два. Сеть содержит log2N число каскадов, каждый из которых имеет N/2 переключателей. Для управления маршрутизацией сообщений в этой сети необходимо log2N бит информации. Схема 4-каскадной сети Delta-2 приведена на рис. 4.1.10.1.

    Рис. 4.1.10.1. Блок-схема 4-х каскадной сети Delta-2

    Previous: 4.1.9 Сети DQDB (двойная шина с распределенной очередью)    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.11 Сети 100Base-VG


    previous up down next index index
    Previous: 4.1.10 Сети с многокаскадными соединениями    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.12 Канальный протокол Fibre Channel

    4.1.11 Сети 100Base-VG
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Сети 100BASE-VG (Voice Grade) используют звездообразную схему сетевых объектов с помощью соединения типа точка-точка. Эта разновидность сети может работать через кабельную инфраструктуру стандартной сети 10BASE-T. Станции подключаются к сети через концентратор (Hub). Когда станция желает что-либо передать, она посылает сигнал определенной частоты. Начало обмена стартует только после получения разрешения (сигнал специальной частоты, посылаемый концентратором. Широковещательные и мультикатинг-запросы обслуживаются в соответствии со схемой "запомнить и передать". В одно и то же время допускается прием или передача только одного пакета. Для предоставления доступа используется карусельный принцип, что делает эту сеть весьма удобной для небольших рабочих групп и для решения задач управления в реальном масштабе времени. Имеется возможность и приоритетного обслуживания. В сети используется схема кодирования 5B/6B.

    Previous: 4.1.10 Сети с многокаскадными соединениями    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.12 Канальный протокол Fibre Channel


    previous up down next index index
    Previous: 4.1.11 Сети 100Base-VG    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.1.13 Коммутируемая мультимегабитная информационная служба SMDS

    4.1.12 Канальный протокол Fibre Channel
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Известно, что производительность микропроцессоров рабочих станций удваивается каждые 18 месяцев. Каждому миллиону операций в секунду процессора должна соответствовать пропускная способность ввода/вывода, равная мегабиту в секунду (закон Amdahl). По этой причине требования к широкополосности телекоммуникационных каналов уже сегодня лежит в диапазоне от 100 до 1000 Мбит/с. Наиболее популярные скоростные сети Fast Ethernet, FDDI и ATM соответствуют этим требованиям на пределе. Уже одно это заставляет обратить внимание на такие протоколы как гигабитный Ethernet и (стандарт ANSI). Fibre Channel сочетает в себе преимущества канальных и сетевых технологий. Работы по разработке стандарта FC начаты группой ANSI в 1988 году. К настоящему времени разработано более 20 регламентирующих документов. В настоящее время Fibre Channel конкурирует как с Ethernet, так и с SCSI. Смотри www.prz.tu-berlin.de/docs/html/EANTC/INFOSYS/fibrechannel/detail, http://www.fibrechannel.com/technology/physical.htm и http://www.ancor.com. http://www.iol.unh.edu/training/fc/fc_tutorial.html. Последний уже сейчас превосходит по быстродействию существующие сети в 10-100 раз. Он легко стыкуется с протоколами локальных и региональных сетей. Fibre Channel имеет уникальную систему физического интерфейса и форматы кадров, которые позволяют этому стандарту обеспечить простую стыковку с канальными протоколами IPI (Intelligent Peripheral Interface), SCSI, HIPPI, ATM, IP и 802.2. Это позволяет, например, организовать скоростной канал между ЭВМ и дисковой накопительной системой RAID. Быстродействие сетей Fibre Channel составляет n 100Мбайт/с при длинах канала 10 км и более. Предусмотрена работа и на меньших скоростях (например, 12,5 Мбайт/c). Предельная скорость передачи составляет 4,25 Гбод. В качестве транспортной среды может использоваться одномодовое или мультимодовое оптическое волокно. Допускается применение медного коаксиального кабеля и скрученных пар (при скоростях до 200 Мбайт/с). Fibre Channel имеет шесть независимых классов услуг (каждый класс представляет определенную стратегию обмена информацией), которые облегчают решать широкий диапазон прикладных задач:

    Класс 1

    Соединение с коммутацией каналов по схеме точка-точка (end-to-end) между портами типа n_port Класс удобен для аудио и видео приложений, например, видеоконференций. После установления соединения используется вся доступная полоса пропускания канала. При этом гарантируется, что кадры будут получены в том же порядке, в каком они были посланы.

    Класс 2

    Обмен без установления соединения с коммутацией пакетов, гарантирующий доставку данных. Так как соединение не устанавливается, порт может взаимодействовать одновременно с любым числом портов типа n_port, получая и передавая кадры. Здесь не может быть гарантии того, что кадры будут доставлены в том же порядке, в каком были переданы, (за исключением случаев соединения точка-точка или арбитражное кольцо). В этом классе допустимы схемы управления потоком буфер-буфер и точка-точка. Этот класс характерен для локальных сетей, где время доставки данных не является критическим.

    Класс 3

    Обмен дейтограммами без установления соединения и без гарантии доставки. Схема управления потоком буфер-буфер. Применяется для каналов scsi.

    Класс 4

    Обеспечивает выделение определенной доли пропускной способности канала с заданным значением качества обслуживания (QoS). Работает только с топологией структура (fabric), где соединяются два порта типа n_port. При этом формируется два виртуальных соединения, обслуживающих встречные потоки данных. Пропускная способность этих соединения может быть различной. Как и в классе 1, здесь гарантируется порядок доставки кадров. Допускается одновременное соединение более чем с одним портом типа n_port. Используется схема управления потоком буфер-буфер. Каждое виртуальное соединение управляется независимо с помощью сигнала-примитива fc_rdy.

    Класс 5

    Предполагает изохронное обслуживание. Регламентирующие документы находятся в процессе подготовки.

    Класс 6

    Предусматривает мультикастинг-обслуживание в рамках топологии типа структура (fabric). При этом используется стандартный адрес 0xfffff5. n_port становится членом мультикаст-группы путем регистрации по адресу 0xfffff8.

    fibre channel использует пакеты переменной длины (до 2148 байт), содержащие до 2112 байт данных. Такая длина пакета заметно снижает издержки, связанные с пересылкой заголовков (эффективность 98%). С этой точки зрения в наихудшем положении оказывается ATM(83% эффективность 48 байт данных при 53 байтном пакете). Только FDDI превосходит Fibre Channel по этому параметру (99%). В отличие от других локальных сетей, использующих 6-октетные адреса, fibre channel работает с 3-байтовыми адресами, распределяемыми динамически в процессе выполнения операции login. Адрес 0xffffff зарезервирован для широковещательной адресации. Адреса же в диапазоне 0xfffff0-0xfffffe выделены для обращения к "структуре" (fabric), мультикастинг-серверу и серверу псевдонимов (alias-server). n_port передает кадры от своего source_id (s_id) к destination_id (d_id). До выполнения операции fabric login s_id порта не определено. В случае арбитражного кольца применяются 3-октетные адреса al_pa, задаваемые при инициализации кольца. Для однозначной идентификации узлов используются 64-битовые имена-идентификаторы.

    Fibre Channel превосходит другие сети и по некоторым экономическим параметрам (см. табл. 4.1.12.1).

    Таблица 4.1.12.1 (www.ancor.com/ctspr97.html )

    Сеть

    Стоимость за Мбит/сек

    fddi

    109,1$ США

    Fast Ethernet

    12,8 $

    ATM

    23,8$

    Fibre Channel

    9,5$

    Цены вещь непостоянная, но здесь следует учитывать относительный их характер, да и в случае начала массового производства цены на fibre channel пожалуй будут падать быстрее, чем для других сетей (они этот этап уже прошли).

    Формат пакетов в сетях Fibre Channel показан на рис. 4.1.12.1. Здесь используются 24-битовые адреса, что позволяет адресовать до 16 миллионов объектов. Сеть может строить соединения по схеме точка-точка, допускается и кольцевая архитектура с возможностью арбитража (FC-al) и другие схемы (например, "ткань соединений" (fabric), допускающее большое число независимых обменов одновременно). Схема кольцевого соединения показана на рис. 4.1.12.2. К кольцу может быть подключено до 128 узлов. Протокол Fibre Channel предусматривает 5 уровней, которые определяют физическую среду, скорости передачи, схему кодирования, форматы пакетов, управление потоком и различные виды услуг. На физическом уровне (FC-ph 1993 год) предусмотрены три подуровня. FC использует оптические волокна диаметром 62,5, 50мкм и одномодовые. Для обеспечения безопасности предусмотрен опционный контроль подключенности оптического разъема (OFC). Для этого передатчик время от времени посылает короткие световые импульсы приемнику. Если приемник получает такой импульс, процесс обмена продолжается.

    FC-0 определяет физические характеристики интерфейса и среды, включая кабели, разъемы, драйверы (ECL, LED, лазеры), передатчики и приемники. Вместе с FC-1 этот уровень образует физический слой.
    FC-1 определяет метод кодирования/декодирования (8B/10B) и протокол передачи, где объединяется пересылка данных и синхронизирующей информации.
    FC-2 определяет правила сигнального протокола, классы услуг, топологию, методику сегментации, задает формат кадра и описывает передачу информационных кадров.
    FС-3 определяет работу нескольких портов на одном узле и обеспечивает общие виды сервиса.
    FC-4 обеспечивает реализацию набора прикладных команд и протоколов вышележащего уровня (например, для SCSI, IPI, IEEE 802, SBCCS, HIPPI, IP, ATM и т.д.)

    FC-0 и FC-1 образуют физический уровень, соответствующей стандартной модели ISO.

    Рис. 4.1.12.1. Формат пакета Fibre Channel

    Стандарт FC допускает соединение типа точка-точка, арбитражное кольцо и структура (верх, середина и низ рисунка 4.1.12.2). Кольцевая архитектура обеспечивает самое дешевое подключение. Система арбитража допускает обмен только между двумя узлами одновременно. Следует учесть, что кольцевая структура не предполагает применения маркерной схемы доступа. Когда подключенное к сети устройство готово передать данные, он передает сигнал-примитив ARBX, где X - физический адрес устройства в кольце арбитража (al_pa). Если устройство получит свой собственный сигнал-примитив ARBX, оно получает контроль над кольцом и может начать передачу. Инициатор обмена посылает сигнал-примитив open (OPN) и устанавливает связь с адресатом. Время удержания контроля над кольцом не лимитируется. Если контроль над кольцом одновременно пытаются захватить два устройства, сравниваются значения X сигналов ARB. Устройство с меньшим al_pa получает преимущество, прибор с большим al_pa блокируется.

    Прежде чем использовать кольцо его нужно инициализировать (процедура LIP), так чтобы каждый порт получил свой физический адрес (al_pa - один октет, что и определяет макcимальное число портов в кольце арбитража). Процедура инициализации начинается сразу после включения питания посылкой сигнала-примитива LIP через порт l_port. Затем осуществляется выбор устройства, которое будет управлять процессом выбора al_pa.

    Рис. 4.1.12.2. Типы топологии FC

    Перед передачей октеты преобразуются в 10-битовые кодовые последовательности, называемые символами передачи (кодировка IBM 8B/10B). Логической единице соответствует больший уровень световой энергии. В Fibre Channel предусмотрено два режима обмена буфер-буфер и точка-точка (end-to-end). Передача данных осуществляется только когда принимающая сторона готова к этому. Прежде чем что-либо посылать стороны должны выполнить операцию login. В ходе выполнения login определяется верхний предел объема пересылаемых данных (credit). Значение параметра credit задает число кадров, которые могут быть приняты. После передачи очередного кадра значение credit уменьшается на единицу. Когда значение этой переменной достигает нуля, дальнейшая передача блокируется до тех пор, пока получатель не обработает один или более кадров и будет готов продолжить прием. Здесь имеет место довольно тесная аналогия с окнами в протоколе TCP. Режим обмена буфер-буфер предполагает установление связи между портами N_Port и F_Port или между двумя N_Port. При установлении соединения каждая из сторон сообщает партнеру, сколько кадров она готова принять (значение переменной BB_Credit). Режим точка-точка (end-to-end) реализуется между портами типа N_Port. Предельное число кадров, которые сторона может принять, задается переменной EE_Credit. Эта переменная устанавливается равной нулю при инициализации, увеличивается на единицу при передаче кадра и уменьшается при получении кадра ACK Link Control. Кадр ACK может указывать на то, что порт получил и обработал один кадр, N кадров или всю последовательность кадров. Смотри также "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard". K. Teow. May 2000, RFC-2837.

    Previous: 4.1.11 Сети 100Base-VG    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.1.13 Коммутируемая мультимегабитная информационная служба SMDS


    previous up down next index index
    Previous: 4.1.12 Канальный протокол Fibre Channel    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети
        Next: 4.2 Наложенные сети

    4.1.13 Коммутируемая мультимегабитная информационная служба SMDS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Коммутируемая мультимегабитная информационная служба SMDS (Switched Multimegabit Data Service; RFC-1209, -1694) создана для объединения большого числа локальных сетей. Система была разработана в 80-е годы и реализована в начале 90-х годов. Система SMDS функционирует как высокоскоростная опорная сеть, транспортирующая пакеты от одной локальной сети к другой. SMDS рассчитана на большие краткосрочные всплески трафика. При N локальных сетях, соединенных выделенными каналами, полносвязная схема их соединения требует N(N-1)/2 каналов (см. рис. .1А). Для системы SMDS требуется только N каналов до ближайшего SMDS-маршрутизатора (рис. .1В).


    Рис. .1. Разные варианты объединения локальных сетей

    Быстродействие системы SMDS составляет 45 Мбит/с. Система SMDS использует передачу данных без установления соединения. Формат пакета SMDS показан на рис. .2.


    Рис. .2. Формат SMDS-пакета

    Адреса места назначения и отправителя состоят из 4-битного кода, за которым следует телефонный номер, содержащий до 15 десятичных чисел. Каждая цифра кодируется посредством четырех бит. Телефонный номер содержит код страны, код зоны и номер клиента-подписчика, что делает сеть SMDS международной. Длина поля данные является переменной. Когда пакет попадает в сеть SMDS, первый маршрутизатор проверяет, соответствует ли адрес отправителя номеру входной линии. При несоответствии пакет отбрасывается.

    Существенной особенностью SMDS является возможность мультикастинга. Пользователь может составить список номеров и присвоить ему специфический адрес. Отправка пакета по этому адресу вызовет его переадресацию всем клиентам, чьи адреса присутствуют в списке. Это воспроизведение на сетевом уровне возможности почтового списка рассылки.

    Другой особенностью адресации в SMDS является возможность использования списков доступа (screening) для входящих и исходящих пакетов. Кроме того, такая функция позволяет эффективно строить корпоративные сети типа Интранет. Поле данных может содержать в себе кадр Ethernet или пакет Token Ring, что также повышает эффективность и надежность работы сети, упрощая задачу интерфейсного оборудования.

    Работа в условиях всплесков загрузки осуществляется следующим образом. Маршрутизатор в каждом из интерфейсов содержит счетчик, который инкрементируется с постоянной частотой (например, раз в 10 мксек). Когда на вход маршрутизатора приходит пакет, осуществляется сравнение длины пакета в байтах с содержимым этого счетчика. Если содержимое счетчика больше, пакет немедленно пересылается, а содержимое счетчика уменьшается на длину пакета. Если длина пакета больше содержимого счетчика, такой пакет отбрасывается. В результате при данной частоте приращения счетчика в среднем допускается передача 100000 байт/сек. Но импульсная загрузка может существенно превышать это значение.

    Previous: 4.1.12 Канальный протокол Fibre Channel    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2 Наложенные сети    Next: 4.2 Наложенные сети


    previous up down next index index
    Previous: 4.1 Локальные сети (обзор)    UP: 4.1 Локальные сети (обзор)
    Down: 4.2 Наложенные сети
        Next: 4.1.1.1 Архитектура сетей Ethernet

    4.1.1 Ethernet (IEEE 802.3)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.1.1 Ethernet (IEEE 802.3)

    1

    1

    4.1.1.1 Архитектура сетей Ethernet

    11

    12

    4.1.1.2 Fast Ethernet

    10

    9

    4.1.1.3 Интернет в Ethernet

    9

    7

    4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы

    7

    7

    Сеть Ethernet разработана в 1976 году Меткальфом и Боггсом (фирма Ксерокс). Ethernet совместно со своей скоростной версией Fast Ethernet занимает в настоящее время абсолютно лидирующую позицию (а на подходе еще и гигабитный Ethernet). Единственным недостатком данной сети является отсутствие гарантии времени доступа к среде (и механизмов, обеспечивающих приоритетное обслуживание), что делает сеть малоперспективной для решения технологических проблем реального времени. Определенные проблемы иногда создает ограничение на максимальное поле данных, равное ~1500 байт.

    Previous: 4.1 Локальные сети (обзор)    UP: 4.1 Локальные сети (обзор)
    Down: 4.2 Наложенные сети    Next: 4.1.1.1 Архитектура сетей Ethernet


    previous up down next index index
    Previous: 4 Сети передачи данных. Методы доступа    UP: 4 Сети передачи данных. Методы доступа
    Down: 4.1.1 Ethernet (IEEE 802.3)
        Next: 4.1.1 Ethernet (IEEE 802.3)

    4.1 Локальные сети (обзор)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.1 Локальные сети (обзор)

    1

    1

    4.1.1 Ethernet (IEEE 802.3)

    1

    1

    4.1.2 IEEE 802.5 (Token Ring)

    12

    12

    4.1.3 IEEE 802.4 (Маркерная шина)

    3

    22

    4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)

    5

    75

    4.1.5 Локальные сети ArcNet

    4

    139

    4.1.6 Сети FDDI

    8

    328

    4.1.7 Параллельный сетевой интерфейс HIPPI

    4

    37

    4.1.8 Сети IEEE 802.11

    3

    58

    4.1.9 Сети DQDB (двойная шина с распределенной очередью)

    3

    29

    4.1.10 Сети с многокаскадными соединениями

    1

    19

    4.1.11 Сети 100Base-VG

    1

    4

    4.1.12 Канальный протокол Fibre Channel

    4

    35

    4.1.13 Коммутируемая мультимегабитная информационная служба SMDS

    2

    17

    В этом разделе речь идет о физической среде локальных сетей.

    Previous: 4 Сети передачи данных. Методы доступа    UP: 4 Сети передачи данных. Методы доступа
    Down: 4.1.1 Ethernet (IEEE 802.3)    Next: 4.1.1 Ethernet (IEEE 802.3)


    previous up down next index index
    Previous: 4.2 Наложенные сети    UP: 4.2 Наложенные сети
    Down: 4.3 Региональные сети
        Next: 4.2.1.1 IPX-протокол

    4.2.1 Протоколы Novell (IPX/SPX)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.2.1 Протоколы Novell (IPX/SPX)

    1

    5

    4.2.1.1 IPX-протокол

    4

    60

    4.2.1.2 SPX-протокол

    2

    26

    4.2.1.3 Протокол ядра NetWare (NCP)

    3

    18

    4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)

    3

    24

    4.2.1.5 Служба каталогов NetWare (NDS)

    4

    52

    Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, "Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, "Диалог-МИФИ", 1993), [13]) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу.

    Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol).

    Previous: 4.2 Наложенные сети    UP: 4.2 Наложенные сети
    Down: 4.3 Региональные сети    Next: 4.2.1.1 IPX-протокол


    previous up down next index index
    Previous: 4.2.1 Протоколы Novell (IPX/SPX)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.1.2 SPX-протокол

    4.2.1.1 IPX-протокол
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол IPX предназначен для передачи дейтограмм в системах, неориентированных на соединение (также как и IP или NETBIOS, разработанный IBM и эмулируемый в Novell), он обеспечивает связь между NetWare серверами и конечными станциями. Максимальный размер IPX-дейтограммы составляет 576 байт, из них 30 байта занимает заголовок. Предполагается, что сеть, через которую транспортируются эти дейтограммы, способна пересылать пакеты соответствующей длины. IPX-пакеты могут рассылаться широковещательно, для этого поле типа должно принять значение 0x14, адрес сети назначения должен соответствовать локальной сети, адрес узла назначения при этом принимает значение 0xFFFFFF.

    Оригинальный транспортный протокол Novell, на мой взгляд, не способствует успеху этой сети. Не успев своевременно переориентироваться на транспортные и маршрутные протоколы стека TCP/IP этот крайне популярный совсем недавно вид сетей в настоящее время имеет шансы исчезнуть.

    IPX-пакеты, передаваемые по сети Ethernet, могут иметь несколько разных форматов. Старейший из них носит в Novell название "802.3" (информацию об интеграции сетей Novell и Интернет можно найти в документах: RFC-1234, -1420, -1553, -1634, -1792) и используется по умолчанию в версиях вплоть до 3.11. В последующих версиях форматом по умолчанию является "802.2". Применим также и формат, называемый Ethernet II, который наиболее близок идеологии TCP/IP. Сеть в Netware - это логический канал, который используется совместно рядом узлов так, что они могут взаимодействовать друг с другом непосредственно. Так процессы, реализуемые на одном сервере, считаются подключенными к внутренней IPX-сети. Все пользователи сети типа Ethernet II образуют логическую сеть IPX. Все пользователи одной сети типа 802.3 рассматриваются как узлы различных сетей IPX. Сопоставление форматов пакетов для различных сетевых стандартов представлено на рис. 4.2.1.1.

    Рис. 4.2.1.1. Форматы сетевых пакетов

    Из рисунка видно, что различия непринципиальны и не препятствуют сосуществованию всех перечисленных форматов в пределах одной локальной сети. IPX-заголовок начинается сразу после поля Тип или Длина в зависимости от используемого протокола.

    Серверы Netware можно сконфигурировать так, чтобы они воспринимали пакеты разных типов, и поэтому могли иметь непосредственные связи с разными сетями. IPX-сервер может выполнять и функции маршрутизатора. Формат заголовка пакета IPX показан на рис. 4.2.1.2. За заголовком следуют данные, их объем определяется кодом поля Длина пакета (минус 30) и лежит в диапазоне от 0 до 546 байт.

    Рис. 4.2.1.2. Формат заголовка IPX-пакета

    Поле Контрольная сумма (2 байта) устанавливается ipx-драйвером равным 0xffff, это означает, что контрольного суммирования не производилось. Приложениям разрешено использовать поле контрольной суммы при работе с кадрами Ethernet II, ieee 802.2 и Ethernet SNAP и запрещено для работы с кадрами ieee 802.3. Данное ограничение можно легко понять, обратившись к рис. 4.2.1.1. Контрольная сумма служит лишь для контроля правильности IPX-заголовка и не имеет никакого отношения к полю данных IPX-дейтограммы. Для того чтобы работать с контрольными суммами на NetWare-сервере, следует выдать команду set enable IPX checksum=n, где n указывает на то, что контрольная сумма использована. Возможные значения n и их смысл приведены ниже в таблице 4.2.1.1.

    Таблица 4.2.1.1

    Код n

    Назначение в сервере

    0

    Контрольная сумма не используется

    1

    Контрольная сумма используется, если доступна клиенту

    2

    Контрольная сумма должна использоваться

    То же для клиента

    0

    Контрольная сумма не используется (по умолчанию)

    1

    Контрольная сумма используется, но лишена приоритета

    2

    Контрольная сумма используется и имеет приоритет

    3

    Контрольная сумма должна использоваться

    Поле Длина пакета (2 байта) содержит число байт в пакете, включая заголовок, и может лежать в пределах от 30 (только заголовок) до 576. В действительности максимальная длина IPX-пакета равна 1518 байт, но при прохождении пакетов через маршрутизаторы, когда не используется протокол LIP(large internet packet, протокол межсетевой пересылки больших пакетов) максимальная длина может быть равной лишь 576 байт (что и принято по умолчанию). Следует также иметь в виду, что согласно регламентациям Novell длина пакета может принимать только четные значения. Программист не должен беспокоиться о содержании этого поля, это за него сделает сам протокол IPX. Поле управление пересылкой (1 байт) устанавливается IPX-драйвером равным нулю перед посылкой пакета. Каждый маршрутизатор увеличивает значение этого поля на 1. Если пакет прошел через 15 маршрутизаторов, очередной - удалит пакет из сети (в некотором смысле это аналог поля время жизни - TTL в протоколах TCP/IP). Поле управление пересылкой можно использовать для оптимизации маршрутов в локальной сети. Если станция общается только с серверами соседней субсети, ее следует переключить туда и снизить тем самым нагрузку маршрутизатора. Контроль за содержимым этого поля выполняется протоколом IPX. Поле тип пакета (1 байт) устанавливается прикладной программой. При использовании протокола ipx это поле должно содержать нуль (или 4), в случае использования протокола SPX - 5, а для протокола NCP(Netware core protocol) -17. Поля адрес узла назначения и адрес узла отправителя содержат 12-байтовые структуры ipxaddr_1. Эта структура включает в себя 4 байта адреса сети (присваивается администратором сети при установке сети Novell), 6 байт адреса узла (физический адрес, задается изготовителем сетевого интерфейса) и 2 байта дескриптора соединителя (socket, необходим для адресации программы, принимающей пакеты, заполняется приложением). Пакеты, адресованные серверу в NetWare 3.x или 4.x содержат в поле адреса узла получателя код 0x00 00 00 00 00 01 (аналогичный код будет записан в поле адрес отправителя, если им является сервер). Адрес же узла получателя на уровне Ethernet или Token Ring будет равен физическому сетевому адресу интерфейса или локального маршрутизатора, если сервер размещен в другой субсети. Соединители (socket) служат для управления обработкой пакетов. Широковещательный пакет будет получен ЭВМ, если она имеет открытый соединитель для процесса, которому он адресован. По этой причине должны приниматься специальные меры, чтобы предотвратить возможность посылки двумя программами пакетов различного типа на один и тот же соединитель. Ряд номеров соединителей зарезервировано IPX-протоколом для определенных целей:

    2 - соединитель протокольных откликов; 3 - обработчик ошибок.

    Некоторые номера заняты под нужды Netware:

    0x451

    Протокол ядра NetWare (NCP - netware core protocol);

    0x452

    Протокол NetWare для оповещения об услугах (SAP - service advertising protocol);

    0x453

    Маршрутный протокол NetWare (RIP - routing information protocol);

    0x455

    Пакет протокола netbios;

    0x456

    Диагностический протокол NetWare;

    0x457

    Пакет сериализации (serialization).

    Дескрипторы соединителей для рабочих станций задаются динамически и их коды лежат в диапазоне 0x4000 - 0x8000. В отличии от протоколов TCP/IP IPX не имеют фиксированных адресов для сетей или интерфейсов, которые следует конфигурировать. Вместо этого рабочие станции получают свои сетевые номера от маршрутизатора, к которому они подсоединены, и используют Ethernet-адрес в качестве номера узла.

    Приложение должно устанавливать поля тип пакета и адрес узла назначения, а IPX-драйвер заполняет остальные поля. Возможные значения кода поля тип пакета представлены в таблице 4.2.1.2.

    Таблица 4.2.1.2 Коды типа IPX-пакета.

    Тип пакета

    Значение

    0

    Обычный IPX-пакет

    1

    Пакет с маршрутной информацией (RIP - routing information protocol)

    2

    Отклик

    3

    Ошибка

    4

    Информационный пакетный обмен (pep - packet exchange protocol)

    5

    Последовательный пакетный обмен (SPX - sequence packet exchange)

    17

    Протоколы ядра NetWare (NCP)

    20

    Именной пакет netbios (широковещательный)

    Программа, использующая IPX-протокол для передачи информации должна записывать в поле тип пакета код 4.

    Маршрутная информация передается между серверами и маршрутизаторами. Динамический маршрутный протокол RIP (routing information protocol, базируется на стандарте Xerox IP; cм. также RFC-1058) обеспечивает конечные станции информацией, которая необходима для динамического управления оптимизацией маршрутов. Рассылка маршрутной информации производится с помощью широковещательных пакетов. Как видим, сети Novell являются источником значительных потоков широковещательных пакетов. Аналогичным образом объекты сети оповещаются о других изменениях в сетевой среде, например, рассылка информации о доступных услугах (SAP - service advertisement protocol). Протокол SAP позволяет узлам, которые предлагают определенные услуги (например, файл-серверы или принт-серверы), сообщать о своих адресах и видах доступных услуг. Администратор может регулировать поток таких пакетов, задавая постоянные времени для таймеров обновления информации. Маршрутизаторы рассылают маршрутную информацию в пяти случаях:

    1. При инициализации.
    2. В случае, когда необходима исходная маршрутная информация (напр. в случае сбоя или порчи маршрутной таблицы).
    3. Периодически для обновления маршрутных таблиц.
    4. При изменении конфигурации маршрутов.
    5. При отказе или отключении маршрутизатора.

    Маршрутизация пакетов в сети достаточно проста. Каждому сетевому сегменту маршрутизатор присваивает номер в пределах от 1 до fffffffe. Каждой группе устройств присваивается "сетевой номер", который представляет эту группу во всех маршрутизаторах сети. Пакеты, посылаемые от одного члена группы другому, посылаются непосредственно. Пакеты от одного члена группы к объекту из другой группы будут пересланы через маршрутизаторы. Для выбора маршрута в пределах локальной сети используется маршрутный протокол RIP. Формат пакета NetWare RIP показан на рис. 4.2.1.3.

    Рис. 4.2.1.3. Формат RIP-пакета в NetWare

    Поле тип пакета содержит код 0x0001, если это запрос, и 0x0002, если отклик. В поле адреса сети записывается адрес сети места назначения, если пакет является запросом. Если в поле записан код 0xff ff ff ff, это означает, что запрос относится ко всем известным сетям. Поле число шагов до цели имеет смысл лишь в случае пакетов-откликов. В этом случае сюда заносится число маршрутизаторов, которые должен пройти пакет по дороге к сети назначения. Поле время в тиках имеет смысл для пакетов-откликов и указывает на время, необходимое для достижения сети адресата. Один тик равен 1/18 секунды. Сходный протокол маршрутизации используется в сетях appletalk (RTMP).

    Для межсетевой маршрутизации в Novell разработан протокол NLSP (NetWare link services protocol). NLSP базируется на той же идеологии, что и протокол IS-IS (intermediate system-to-intermediate system), созданный для сетей OSI и IP. В NLSP значение метрики маршрута задается вручную. nlsp-маршрутизаторы хранят полную карту сети, по которой принимаются решения о наилучших возможных маршрутах.

    На рис. 4.2.1.4 представлена схема соответствия протоколов Novell и 7-уровневой модели osi.

    Рис. 4.2.1.4. Схема соответствия протоколов Novell и модели osi

    Протокол SAP (service advertising protocol) служит для получения информации обо всех серверах, имеющихся в сети, и поддерживает следующие виды запросов и функции:

    • запрос SAP-сервиса;
    • оповещение об отключении сервера;
    • мониторинг откликов и некоторые другие.

    Каждому серверу NetWare присваивает номер, а некоторые сервера могут иметь и имя. Номер сервера и его имя хранятся в базе данных объектов bindary каждого сервера. Пакет запроса SAP-сервиса содержит 2 байта типа пакета и два байта типа сервера. Поле тип пакета определяет, является ли данный пакет общим запросом сервиса (код=0x0003), или запросом ближайших услуг (код=0x0001). Таблица кодов поля тип сервера приведена ниже (4.2.1.3).

    Таблица 4.2.1.3 Коды тип сервера (cм. также ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-numbers)

    Тип сервера

    Описание

    0x0001

    Пользователь

    0x0004

    Файл-сервер

    0x0005

    Сервер заданий

    0x0006

    Внешний сетевой порт (gateway)

    0x0007

    Принт-сервер

    0x0009

    Сервер архива

    0x000a

    Очередь задач

    0x0017

    Диагностика

    0x0020

    NetBios

    0x0021

    NAS SNA порт

    0x0027

    TCP/IP сервер порта

    0x0028

    Сервер моста x.25 точка-точка

    0x02e

    Динамический SAP

    0x0047

    Оповещающий принт-сервер

    0x004b

    vap 5.0

    0x004c

    SQL VAP

    0x007a

    TES-NetWare VMS

    0x0098

    Сервер доступа к NetWare

    0x009a

    Сервер именованных труб

    0x009e

    Портативный NetWare-Unix

    0x0107

    NetWare 386

    0x0111

    Тест-сервер

    0x0166

    Управление NetWare

    0x026a

    Управление NetWare

    0x026b

    Временная синхронизация

    0x0278

    Сервер каталогов NetWare

    SAP-пакеты-отклики (периодически рассылаемые пакеты) имеют следующий формат (рис. 4.2.1.5).

    Рис. 4.2.1.5. Формат пакета SAP

    Поле тип пакета принимает значение 0x0002 для SAP-откликов общего обслуживания (General Service Response) и 0x0004 для отклика ближайшего сервера. Запросы о ближайшем сервере используются для поиска в сети сервера конкретной разновидности (пакет запроса содержит лишь первые два поля). Реально отклик будет получен от всех серверов данного типа, а не только от ближайшего. Насколько данный сервер близок, определяется по числу маршрутизаторов до него. Эти запросы/отклики служат для составления списка доступных серверов. Поле тип сервера содержит код доступного вида услуг, а в поле наименование сервиса записывается имя услуги уникальное для данного сервера (длина поля на рис. 4.2.1.5 равна N). Поле адрес сети представляет собой 4-байтовое число, которое идентифицирует адрес сервера. Поле адрес узла характеризует адрес сервера в сети. Службы NetWare указывают адрес 0x00.00.00.00.00.01. Поле дескриптор соединителя характеризует код соединителя, который будет использовать сервер. Последнее поле - число шагов до сервера (число транзитных сетей) характеризует число маршрутизаторов между сервером и клиентом. При отключении сервера от сети он должен широковещательно разослать SAP-уведомление "Останов сервера". Уведомление содержит код сервера и его полный адрес.

    Previous: 4.2.1 Протоколы Novell (IPX/SPX)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.1.2 SPX-протокол


    previous up down next index index
    Previous: 4.2.1.1 IPX-протокол    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.1.3 Протокол ядра NetWare (NCP)

    4.2.1.2 SPX-протокол
    Семенов Ю.А. (ГНЦ ИТЭФ)

    SPX (Sequence Packet eXchange) и его усовершенствованная модификация SPX II представляют собой транспортные протоколы 7-уровневой модели ISO. Это протокол гарантирует доставку пакета и использует технику скользящего окна (отдаленный аналог протокола TCP). В случае потери или ошибки пакет пересылается повторно, число повторений задается программно. В протоколе SPX не предусмотрена широковещательная или мультикастинг-адресация. В SPX индицируется ситуация, когда партнер неожиданно прерывает соединение, например из-за обрыва связи. Пакеты SPX вкладываются в пакеты IPX. При этом в поле тип пакета IPX записывается код 5. Заголовок пакета SPX всегда содержит 42 байта, включая 30 байт заголовка IPX-пакета, куда он вложен (см. рис. 4.2.1.2.1).

    Рис. 4.2.1.2.1. Формат заголовка SPX-пакета

    Поле управления соединением определяет, является ли данный пакет системным или прикладным. Это поле содержит однобитовые флаги, используемые spx и spx ii для управления потоком данных в виртуальном канале.

    0x01 XHD

    Зарезервировано SPX II для расширения заголовков;

    0x02 RES1

    Назначение поля не определено, должно быть равно нулю;

    0x04 NEG

    SPX II (SIZ) согласует размер запроса/отклика, для spx должно быть равно нулю;

    0x08 SPX2

    Тип пакета SPX II, для spx должно быть равно нулю;

    0x10 EOM

    Устанавливается клиентом spx для индикации конца сообщения (end-of-message);

    0x20 ATN

    (attention) зарезервировано для специальных запросов (не поддерживается SPX);

    0x40 ACK

    Устанавливается для запроса подтверждения получения данного пакета. Запросы и отклики обрабатываются на уровне SPX (приложение не должно модифицировать этот код);

    0x80 SYS

    Устанавливается, если данный пакет является системным и служит для подтверждения. Приложения не используют пакеты этого типа.

    Поле тип потока данных характеризует тип данных, помещенных в пакет. Значения этого поля перечислены ниже:

    0x00-0x07

    определяется клиентом и может использоваться в приложениях;

    0x80-0xfb

    зарезервированы на будущее;

    0xfc

    spx ii, упорядоченное освобождение запроса;

    0xfd

    spx ii, упорядоченное освобождение подтверждения;

    0xfe

    указывает на окончание связи (end-of-connection). При закрытии канала spx-драйвер посылает клиенту пакет, где в поле тип потока записан данный код;

    0xff

    подтверждение получения сообщения об окончании связи (end-of-connection-acknowledgment). Этим кодом помечается пакет, подтверждающий закрытие канала, в прикладную программу такой пакет не передается

    Поля идентификатора отправителя и получателя содержат коды, определяющие участников информационного обмена, присваиваются SPX-драйвером в момент установления связи. В запросах на соединение это поле содержит код 0xffff. Данное поле служит для обеспечения демультиплексирования пакетов, поступающих на один и тот же соединитель (socket). Поле последовательный номер определяет число пакетов пересланных в одном направлении. Каждый из партнеров обмена имеет свой счетчик, который сбрасывается в ноль после достижения 0xffff, после чего счет может продолжаться. Для приложения это поле, также как и последующие два, неприкосновенно. spx-пакеты подтверждения содержат в этом поле порядковый номер последнего посланного пакета. Поле номер подтверждения характеризует последовательный номер следующего пакета, который spx ожидает получить. Любой пакет с порядковым номером меньше, чем задано в поле номера подтверждения, доставлен благополучно и не требует ретрансмиссии. Поле число буферов служит для указания числа доступных на станции буферов (буфера нумеруются, начиная с 0, один буфер способен принять один пакет) и используется для организации управления потоком данных между приложениями. Код этого поля информирует партнера о наибольшем порядковом номере пакета, который может быть послан. Протокол spx посылает пакеты до тех пор, пока локальный последовательный номер не станет равным числу-указателю на удаленной ЭВМ.

    SPX-протокол не посылает следующий пакет до тех пор, пока не получит подтверждение получения предшествующего. Хотя в протоколе SPX предусмотрен алгоритм скользящих окон (как и в TCP), практически он в настоящее время не используется, что вполне оправдано для локальных сетей. Следует заметить, что для достаточно больших LAN, где пакет проходит через несколько переключателей или маршрутизаторов, пренебрежение техникой окон становится непозволительной роскошью. На случай непредвиденных обрывов связи в spx имеется алгоритм "сторожевая собака". Этот алгоритм реализуется специальной программой, которая активируется лишь в случае, когда в течение определенного времени в канале отсутствует трафик в любом из направлений (машина все сделала, а оператор заснул). В этом случае программа посылает специальные пакеты и, если определенное число попыток "достучаться" до партнера не увенчается успехом, сессия прерывается. Если партнер не присылает отклик за оговоренное время (RTT), производится повторная посылка пакета, при этом RTT увеличивается на 50%. Значение RTT не должно превысить величины max_retry_delay, которая по умолчанию равна 5 секундам. Если связь не восстановилась, отправитель пытается найти другой маршрут до адресата. Если маршрут найден, счетчик попыток сбрасывается в ноль и процедура отправки запускается вновь. Допустимое число попыток может лежать в диапазоне 1-255 (по умолчанию - 10). При отсутствии успеха сессия прерывается.

    Значение RTT определяется по времени отклика ближайшего маршрутизатора, которое удваивается, а к полученной величине добавляется некоторая константа. Для каждой из сессий RTT определяется независимо. Многие временные константы задаются администратором сети.

    Протокол spx позволяет осуществить от 100 до 2000 соединений одновременно (по умолчанию это число равно 1000). Конфигурационные параметры SPX-протокола (и сети) хранятся в файлах shell.cfg и net.cfg.

    В 1992 году была разработана новая версия SPX - SPX II. Главное усовершенствование протокола связано с применением пакетов большего размера. Раньше длинные spx-пакеты фрагментировались и пересылались по частям, учитывая, что очередной пакет может быть послан лишь после получения подтверждения, нетрудно понять крайнюю неэффективность такой схемы. Стандарт spx позволяет обмен пакетами с размером, ограниченным только используемой сетевой средой. Так в Ethernet пакет SPX II может иметь длину 1518 байт. Кроме того, SPX II допускает использование технологии окон, то есть можно послать несколько кадров, не дожидаясь получения подтверждения на каждый из уже посланных. Размер окна устанавливается в соответствии с кодом, содержащимся в поле число-указатель (число буферов/пакетов). При необходимости администратор может задать размер окна раз и навсегда. Формат пакетов SPX II несколько отличается от SPX. В SPX II увеличено число допустимых кодов для поля управления соединением, введено дополнительное поле в заголовок подтверждения (два байта, имя поля "расширенное подтверждение"). Новое поле добавлено после поля число буферов. Алгоритм установление связи в SPX II отличатся от варианта spx тем, что необходимо согласовать размер пересылаемых пакетов.

    Рис. 4.2.1.2.2. Формат заголовка SPX-II

    Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB.

    Previous: 4.2.1.1 IPX-протокол    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.1.3 Протокол ядра NetWare (NCP)


    previous up down next index index
    Previous: 4.2.1.2 SPX-протокол    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)

    4.2.1.3 Протокол ядра NetWare (NCP)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на рис. 4.2.1.3.1.

    Рис. 4.2.1.3.1. Формат заголовка пакета NCP

    Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4).

    Таблица 4.2.1.3.1 Значения кодов поля тип запроса

    Код

    Описание запроса

    1111

    Создание канала обслуживания

    2222

    Запрос сервиса

    5555

    Ликвидация канала обслуживания

    7777

    Пересылка в пакетном режиме

    Поле номер по порядку используется для отслеживания последовательности связи между клиентом и сервером. Клиент записывает в это поле код, равный номеру по порядку плюс единица. В полях номера канала записан номер, присвоенный клиенту при его регистрации сервером. Поле номер задачи идентифицирует каждую из задач, сделавших запрос. Сервер следит за выполнением задачи и освобождает ресурсы при завершении выполнения. Номер задачи равный нулю говорит серверу, что все задания окончены. Старшая часть номера канала используется лишь при наличии более чем 1000 пользователей, в остальных вариантах это субполе содержит нуль. Сервер в своем отклике сообщает клиенту результаты выполнения его запроса. Отклик, также как и запрос, вкладывается в IPX/SPX-пакет. Формат пакета-отклика показан на рис. 4.2.1.3.2.

    Рис. 4.2.1.3.2. Формат заголовка NCP-отклика

    Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2):

    Таблица 4.2.1.3.2 Коды откликов

    Код типа отклика

    Описание

    3333

    Отклик

    7777

    Соединение для протокола Burst Mode

    9999

    Запрос обрабатывается

    Сервер отвечает на большую часть запросов, помещая код 3333 в поле типа отклика. Если запрос клиента помещен в очередь, а клиент по таймауту выдал еще один запрос, ему присылается отклик типа "Запрос обрабатывается". Станция клиента при этом сбросит таймер в исходное состояние, добавит 1 к счетчику попыток и продолжит ожидание. По умолчанию запрос можно повторить 20 раз. Поле код завершения указывает на характер завершения выполнения запроса клиента. Код нуль говорит об успешном завершении, любое другое число - об ошибке. Поле состояние канала содержит флаги, характеризующие статус канала, клиенты NetWare должны проверять код этого поля во всех пакетах, приходящих от сервера. Кроме заголовка (запросов и откликов) каждое NCP-сообщение должно содержать в себе код NCP-процедуры, характеризующий запрашиваемую услугу. Часто помимо кода процедуры необходимо указать и ее субкод. Перечень кодов процедур и их функций приведен в приложении.

    Помимо стандартных пакетов в среде Novell используются несколько вспомогательных видов пакетов. Это пакеты "сторожевая собака" (Watchdog), сериализации (serialization) и сообщения. Пакеты "сторожевая собака" после IPX-заголовка имеет поля номера канала и сигнатура. Поле номера канала отмечает канал станции, присвоенный ей при регистрации. Поле сигнатура содержит код 0x3F. Если отклика от рабочей станции нет, то сервер передает с интервалом 59 сек 10 аналогичных "собачих" пакетов. Если отклика добиться не удастся, связь со станцией будет разорвана. Период и число таких запросов администратор может изменять в широких пределах.

    Так как система NetWare продается для каждого сервера отдельно, чтобы контролировать случаи нелегальной загрузки, по сети рассылаются широковещательные пакеты сериализации. Цель такой рассылки - проверка наличия в сети нескольких копий одного и того же программного обеспечения. Пакеты сериализации содержат 36 байт, включая IPX-заголовок, и передаются раз в 66 сек. Эти пакеты помимо IPX-заголовка включают в себя только поле данных (6 байт), где содержится информация о серийном номере программного продукта. Пакеты сериализации всегда посылаются на вход соединителя (socket) с номером 0x0457. При обнаружении нелегальной копии всем пользователям рассылается уведомление "Copyright violation".

    Пользователи NetWare могут передавать сообщения рабочим станциям, группам и другим пользователям. Для каждой станции NetWare резервирует буфер для сообщений. Консоль отображает принятое сообщение немедленно, буфер же сохраняет сообщение и может уведомлять о нем пользователя. Для передачи сообщений используется команда SEND.

    Previous: 4.2.1.2 SPX-протокол    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)


    previous up down next index index
    Previous: 4.2.1.3 Протокол ядра NetWare (NCP)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.1.5 Служба каталогов NetWare (NDS)

    4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Новый протокол LIP (Large Internet Packet Protocol, 1992 год) разработан Novell для того, чтобы максимально эффективно реализовать возможности, предоставляемые внешними каналами связи. Для повышения производительности операций чтения и записи разработан также протокол пакетного режима (Burst Mode Protocol). Этот протокол позволяет рабочим станциям передавать один запрос на чтение или запись и получать в ответ до 64 Кбайт данных, не посылая дополнительных запросов (используется технология BNETX и VLM). Длина пакета является результатом соглашения между отправителем и получателем, которое достигается в результате диалога. При этом прикладные программы не должны поддерживать пакетный режим (он реализован в оболочке системы). При использовании протокола пакетного режима BNETX клиент и сервер должны быть соответственно подготовлены. На сервере загружается модуль NLM (PBURST.NLM). Согласование размера пакета реализуется путем посылки оболочкой пакетного режима специального запроса на установление соединения с сервером. Это в свою очередь накладывает ограничение на минимальный размер каждого из используемых буферов. Если совершается попытка клиента установить связь в пакетном режиме с сервером, который этот режим не поддерживает, то будет послано сообщение "NO Such Property", а обмен будет производиться в обычном режиме (NCP-запрос-отклик). Отличие пакетных режимов в BNETX и VLM заключается в управлении скользящим окном. VLM (VLM.EXE), в отличии от BNETX, не устанавливает верхнего предела размера окна. По умолчанию размер окна (число посланных пакетов без подтверждения получения) при чтении равно 16, а при записи - 10. Формат кадров протокола пакетного режима предполагает наличие IPX-заголовка, за которым следует NCP-заголовок пакетного режима. Далее следуют данные. Формат кадра пакетного режима показан на рис. 4.2.1.10. Поле тип запроса NCP-запроса или отклика содержит код 0x7777. Возможные значения флагов перечислены ниже (таблица 4.2.1.6).

    Таблица 4.2.1.4.1 Значения поля флаги

    Флаг

    Описание

    sys

    При равенстве 1 указывает на то, что это системный пакет и не несет в себе данных

    sak

    Пока не используется, но равенство 1 должно потребовать от получателя присылки списка утраченных фрагментов

    eob

    Равенство 1 показывает, что пакет содержит последнюю порцию данных, присланных отправителем.

    bsy

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

    abt

    Равенство 1 сообщает клиенту о том, что сессия прервана.

    Рис. 4.2.1.10 Формат кадра пакетного режима

    В скобках на рисунке указаны размеры полей в байтах. Поле тип потока в данное время может содержать только код 0x02 и означает, что передаются длинные блоки пакетов. Поле идентификатор отправителя является случайным числом и представляет собой уникальный идентификатор канала, работающего в пакетном режиме. Код этого поля формируется отправителем и не должен равняться нулю. Идентификатор канала получателя также случайное число, но задается адресатом и также не должно содержать нуль. Поле номер пакета по порядку служит для отслеживания текущей пакетной операции и увеличивается на единицу для каждого нового пакета. Поле время задержки передачи означает величину задержки между отправкой пакетов и измеряется в сотнях микросекунд. Поле номер блока пакетов идентифицирует принадлежность пакета к конкретному блоку (данные, посылаемые по запросу, образуют один блок). При установлении связи код этого поля делается равным нулю. В дальнейшем при выполнении каждого запроса его значение увеличивается на 1. Поле порядковый номер подтверждения содержит номер блока пакетов, ожидаемый следующим. Поле служит для контроля доставки блоков пакетов. Поле полная длина блока пакетов задает длину блока в байтах и равно сумме длин всех пакетов в блоке. Поле указатель блока пакетов определяет положение конкретного пакета, указатель равный нулю говорит о том, что это первый пакет. Поле длина блока задает длину блока пакетов в октетах. Поле элементы списка фрагментов задает число элементов, пропущенных в процессе реализации пакетной сессии. Если это число равно нулю, пропущенных фрагментов не было. Поле функция определяет разновидность операции (чтение или запись), реализуемой в данной сессии. Последующие поля служат для операций с файлами.

    Previous: 4.2.1.3 Протокол ядра NetWare (NCP)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.1.5 Служба каталогов NetWare (NDS)


    previous up down next index index
    Previous: 4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.2 AppleTalk

    4.2.1.5 Служба каталогов NetWare (NDS)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:

    • Главный эталонный временной сервер (устанавливает время для вторичных серверов и клиентов, время устанавливается супервизором, при наличии в сети таких серверов применение первичных и эталонных временных серверов не допускается);
    • Первичный сервер (синхронизует сетевое время, по крайней мере, с еще одним первичным или эталонным сервером, время устанавливается по выбранному сетевому времени);
    • Эталонный сервер (задает время для всех остальных серверов и клиентов, синхронизируется от внешнего источника, например, службы времени, первичные серверы должны согласовывать свое время с эталонным сервером);
    • Вторичный сервер (синхронизируется от главного эталонного, первичного или просто эталонного сервера).

    Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций. Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже.

    Таблица 4.2.1.5.1 Основные NCP-функции

    Вид сервиса

    Тип запроса

    Код операции

    Код субфункции

    ping для nds ncp (запрос о NDS)

    2222

    104

    01

    Посылка фрагментированного NDS запроса/отклика

    2222

    104

    02

    Закрытие NDS-фрагмента

    2222

    104

    03

    Возврат контекста bindary

    2222

    104

    04

    Мониторирование NDS-связи

    2222

    104

    05

    Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на рис. 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware. Таблица команд службы каталогов приведена в приложении (10.5) .

    В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).

    Рис. 4.2.1.5.1. Формат пакетов "Фрагментированный NDS-запрос/отклик"

    Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на рис. 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.

    Рис. 4.2.1.5.2. Формат диагностического запроса

    Структура пакета-отклика показана на рис. 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента:

    Таблица 4.2.1.5.1. Коды типа компонентов

    Код компонента

    Тип компонента

    Описание

    0

    IPX/SPX

    IPX/SPX-процесс или модуль на выделенном файл-сервере, маршрутизаторе или у клиента.

    1

    Драйвер маршрутизатора

    Процесс драйвера маршрутизации.

    2

    Драйвер локальной сети

    Процесс драйвера интерфейса локальной сети на файл-сервере или маршрутизаторе.

    3

    Оболочка

    Модуль-эмулятор или оболочка DOS на рабочей станции (netx.com)

    4

    vap

    Модуль-эмулятор или оболочка DOS на сервере netware 2.x или внешнем маршрутизаторе для поддержания VAP.

    5

    Маршрутизатор

    Маршрутизирующий компонент внешнего порта сети (gateway)

    6

    Файловый сервер/маршрутизатор

    Маршрутизирующий компонент файл-сервера (внутренний маршрутизатор или мост).

    7

    Невыделенный IPX/SPX

    IPX/SPX-процесс на невыделенном файл-сервере netware 2.x, внешнем порте сети или локальной сети версий 3.x.

    Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2).

    Таблица 4.2.1.5.2 Коды типа сети

    Код типа сети

    Компонент

    0

    Интерфейс локальной сети

    1

    Невыделенный файл-сервер

    2

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

    Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.

    Рис. 4.2.1.5.3 Формат пакета диагностического отклика

    Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов.

    Previous: 4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.2 AppleTalk


    previous up down next index index
    Previous: 4.2.1.5 Служба каталогов NetWare (NDS)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.2.3 NetBIOS

    4.2.2 AppleTalk
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Сеть APPLETALK разработана компанией apple computer inc. (ЭВМ Macintosh, 1987 г) Эти сети могут работать в среде Ethernet, Token Ring, FDDI и localtalk (собственная сеть apple, использующая скрученные пары). В AppleTalk специфицирован собственный стек протоколов, которые управляют потоком данных в сети. Для целей маршрутизации AppleTalk использует модифицированную версию внутреннего протокола маршрутизации IGRP. Стек протоколов appletalk phase ii включает в себя (схема структуры стека протоколов показана на рис. 4.2.2.1; смотри http://bbs-win.uniinc.msk.ru/product/bay/routers/protocol, а также RFC-1378, -1419, -1504, -1742):

    • Протокол доступа к каналу Tokentalk (TLAP - Tokentalk link access protocol)
    • Протокол доступа к каналу Ethertalk (ELAP - Ethertalk link access protocol)
    • Протокол доступа к каналу Localtalk (LLAP - Localtalk link access protocol)
    • Протокол доставки дейтограмм (DDP - datagram delivery protocol)
    • протокол поддержки маршрутных таблиц (RTMP - routing table maintenance protocol)
    • Протокол определения адресов Appletalk (AARP - appletalk address resolution protocol)
    • Протокол работы с именами (NBP - name binding protocol)
    • Протокол для работы с зонной информацией (ZIP - zone information protocol)
    • Протокол откликов в Appletalk (AEP - appletalk echo protocol)
    • Протокол актуализации маршрутной информации (AURP - Appletalk update routing protocol)
    • Протокол управления потоком данных (adsp - appletalk data stream protocol)
    • Протокол сессий (ASP - Appletalk session protocol)
    • Протокол доступа к принтеру (PAP - printer access protocol)
    • Протокол операций (ATP - Appletalk transaction protocol)
    • Файловый протокол (AFP - Appletalk filing protocol)

    Из рисунка 4.2.2.1 видно, что стек протоколов appletalk полностью согласуется с семиуровневой схемой OSI. DDP представляет собой протокол передачи данных, не ориентированный на соединение. Дейтограмма DDP использует 13-байтовый заголовок, который включает в себя:

    поле числа маршрутизаторов (число шагов), через которые прошел пакет; поле длины дейтограммы; поле контрольной суммы; поля сети назначения и отправителя и т.д. (см. рис. 4.2.2.2. - смотри http://www.stanford.edu/group/networking/adminatalk/atalk_3.html).

    Вслед за заголовком следует информация, которая может содержать до 586 байт. Максимальный размер пакета (MTU) равен 599 байтам. Число узлов в сети может достигать 16 миллионов.

    Рис. 4.2.2.1. Диаграмма стека протоколов appletalk

    Протокол adsp позволяет двум программам обмениваться потоками информации в полном дуплексном режиме с гарантией доставки. Протоколы TLAP, ELAP и LLAP служат для обеспечения сопряжения с соответствующими физическими протоколами (Token Ring, Ethernet и Arcnet), скрывая от программ других уровней специфические особенности используемого сетевого оборудования. Протокол ATP надежно передает запросы и отклики, детектирует ошибки и организует пакетный обмен. Этот протокол используется в свою очередь протоколами ZIP, ASP и PAP, что видно из рис. 4.2.2.1. Протокол AFP является протоколом поддержки приложений и позволяет пользователям ЭВМ Macintosh работать с общими файлами. Программное обеспечение Netware для Macintosh включает в себя файл AFP NLMtm, который обеспечивает поддержку Netware-серверов. Протокол AURP (appletalk update-based routing protocol) служит для целей маршрутизации, но в отличии от некоторых других протоколов передает маршрутную информацию только в случае изменения ситуации. Он поддерживает также IP-туннели.

    Рис. 4.2.2.2. Формат пакетов в сети Apple Talk Phase II (в скобках указаны размеры полей в байтах)

    Адрес отправителя и получателя имеют по 24 бита, из них 16 бит составляет адрес сети. Идентификатор узла назначения (локальная часть адреса) выбирается произвольно самой рабочей станции при установлении связи. ЭВМ берет случайное 8-битовое число в качестве локального адреса и посылает его в сеть. Если какая-то ЭВМ использует этот адрес, она откликается, тогда код меняется и делается повторная попытка. Процесс продолжается пока не будет найден свободный адрес. Протокол RTMP является протоколом маршрутизации, где в качестве метрики используется вектор расстояния до адресата, этот протокол собирает маршрутную информацию и предоставляет ее протоколу DDP для обеспечения транспортировки пакетов по сети. Маршрутные таблицы RTMP хранятся в каждом из маршрутизаторов AppleTalk и базируются на номерах сетей адресатов. Таблица содержит в себе расстояние до адресата, измеренное в шагах (hop), идентификатор порта маршрутизатора, через который достижим адресат, и статус маршрута.

    Маршрутизаторы AppleTalk формируют и актуализируют маршрутные таблицы, посылая регулярно (раз в 10 сек) широковещательные RTMP-пакеты соседним узлам и сетям. Запись в маршрутной таблице, своевременно не подтвержденная, спустя определенное время стирается. Записи в маршрутной таблице попадают в разряд "подозреваемых" при отсутствии отклика от них в течение 20 сек, в разряд "умирающих" - спустя 40 сек, в категорию "умерших" - через 60 сек. Запись удаляется из таблицы, если отклик не удается получить в течение 80 сек.

    Адреса сетевого уровня ставятся в соответствие адресам MAC-уровня с помощью адресного протокола AARP. Узлы сети Apple Talk хранят эту информацию в специальных таблицах (AMT - Address Mapping Table). Таблица просматривается всякий раз, когда AppleTalk посылает пакет. Если поиск не увенчался успехом, узел-отправитель посылает широковещательный AARP-запрос. При получении отклика на этот запрос вносятся коррективы в AMT-таблицу. Особенностью сети AppleTalk является согласование при присвоении локальных адресов объектам сети. При инициализации узла ему присваивается временный адрес. Протокол AARP проверяет, не принадлежит ли данный адрес кому-то еще, для этого он посылает 10 AARP-запросов. Если данный временный адрес уже используется, инициализируемому узлу присваивается новый временный адрес и процедура проверки повторяется до тех пор, пока узлу не будет присвоен уникальный адрес. Протокол NBP преобразует локальные AppleTalk адреса в имена, присвоенные сетевому объекту пользователем и наоборот. Это избавляет пользователя от необходимости помнить полный сетевой адрес принт- или файл-сервера, почтового сервера и т.д..

    Протокол ZIP допускает логическое группирование оконечных сетевых узлов в некоторые объединения, называемые зонами, что позволяет ЭВМ, принадлежащие к одному отделу, но расположенные в разных зданиях, находиться в одной зоне (субсети). Зона может представлять собой комбинацию локальных сетей, а в случае EtherTalk Phase II - часть локальной сети. Информация о зонах хранится в маршрутизаторах в виде специальных таблиц (ZIT - Zone Information Table). Таблица содержит по одной записи на сетевой сегмент. Запись включает в себя номер сетевого сегмента и список объектов, входящих в зону. Протокол ZIP отслеживает изменения в RTMP-таблицах и при появлении в них записей, относящихся к новым объектам или сетям, маршрутизатор посылает ZIP -запрос и на основе полученной информации корректирует ZIT-таблицу.

    Протокол AEP выполняет отладочные и диагностические функции, предоставляя возможность выполнения процедур ping (до какой-то степени это аналог протокола ICMP). При необходимости проверить состояние сети или какого-либо узла посылается AEP-дейтограмма, а зондируемый узел, который при ее получении должен послать отклик отправителю исходного запроса. Протокол позволяет проверить время распространения пакетов между узлами сети. Протокол может использоваться в начале любой сессии для проверки доступности того или иного сетевого объекта.

    Протокол AURP является внешним протоколом сетевой маршрутизации и служит для взаимодействия сетей AppleTalk c Интернет. Протокол поддерживает технологию IP-туннелей с использованием UDP/IP инкапсуляции. Рассылка сетевой информации осуществляется AURP только при возникновении каких-либо изменений в состоянии сети. Протокол AURP поддерживает гибкую систему переадресаций, исключая конфликты адресов при подключении новых сетей AppleTalk, и выявляет маршрутные петли. Существуют специальные фильтры, которые позволяют разделять пакеты по приоритетам, что бывает важно, например, при передаче мультимедиа информации. Сети AppleTalk хорошо согласуются с другими сетями, например, NetWare. Следует иметь в виду, что ЭВМ, работающие с протоколами Phase I и Phase II, могут работать друг с другом только через специальные мосты, так как форматы пакетов для этих протоколов не совместимы.

    Управление сетями Apple Talk осуществляется с помощью протокола SNMP и управляющей базы данных MIB.

    Previous: 4.2.1.5 Служба каталогов NetWare (NDS)    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.2.3 NetBIOS


    previous up down next index index
    Previous: 4.1.13 Коммутируемая мультимегабитная информационная служба SMDS    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2.1 Протоколы Novell (IPX/SPX)
        Next: 4.2.1 Протоколы Novell (IPX/SPX)

    4.2 Наложенные сети
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.2 Наложенные сети

    1

    6

    4.2.1 Протоколы Novell (IPX/SPX)

    1

    5

    4.2.2 AppleTalk

    4

    52

    4.2.3 NetBIOS

    5

    16

    В отличие от локальных наложенные сети не требуют использования специальных аппаратных средств для подключения. Так, если ЭВМ подключена к Ethernet (к ArcNet или Token Ring), нужны только соответствующие программные средства, чтобы она стала узлом сети Novell. Почтовая сеть (протоколы SMTP или UUCP) и сеть новостей (Usenet, протокол NNTP) относятся к наложенным сетям. Интернет (семейство протоколов TCP/IP) является также примером наложенной сети. Проблематика Интернет выделена в самостоятельный раздел лишь в силу объема и разнообразия материалов. Одна и та же ЭВМ может быть узлом нескольких разных наложенных сетей. Смешанные сети могут создавать проблемы для администраторов сетей, но для пользователей они дают лишь дополнительные возможности. В таких сетях неизбежно возникает проблема присвоения имен и установки соответствия между виртуальными и физическими адресами (в Интернет эта проблема решается с помощью протокола ARP).

    Previous: 4.1.13 Коммутируемая мультимегабитная информационная служба SMDS    UP: 4.1.1 Ethernet (IEEE 802.3)
    Down: 4.2.1 Протоколы Novell (IPX/SPX)    Next: 4.2.1 Протоколы Novell (IPX/SPX)


    previous up down next index index
    Previous: 4.2.2 AppleTalk    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети
        Next: 4.3 Региональные сети

    4.2.3 NetBIOS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48).

    Пакет NETBIOS (см. также ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.

    Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.

    Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.

    При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы netbios делятся на три типа:

    • Широковещательные ("b") узлы;
    • узлы точка-точка ("p");
    • узлы смешанного типа ("m").

    IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).

    В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.

    Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP.

    Формат кадра протокола NBFCP показан на рис. 4.2.3.1.

    Рис. 4.2.3.1. Формат кадра NBFCP

    Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов.

    Таблица 4.2.3.1 Коды класса партнера

    Код класса

    Описание

    1

    Зарезервировано

    2

    Сервер внешнего порта PPP NetBIOS

    3

    Зарезервировано

    4

    Сервер локального доступа PPP NetBIOS

    5

    Зарезервировано

    6

    Мост PPP NetBIOS

    7

    Зарезервировано

    8

    Терминальная система PPP

    Протокол WINS

    Протокол WINS разработан компанией MicroSoft для операционной среды Windows и предназначен для расширения возможностей NetBIOS.

    WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 1.

    Рис. 4.2.3.2. Формат запроса WINS

    В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, аналогичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 2.

    Рис. 4.2.3.2. Формат отклика WINS

    Поле флаги имеет следующую структуру:

    0 _ _ _

    _ _ _ _

    Команда

    _ 000

    0 _ _ _

    Запрос

    _ _ _ _

    _ _ 0 _

    Не укорочено

    _ _ _ _

    _ _ _ 0

    Рекурсия нежелательна

    _ _ _ _

    _ _ _ 0

    Рекурсия нежелательна

    1_ _ _

    _ _ _ _

    Отклик

    _ 000

    0 _ _ _

    Запрос

    _ _ _ _

    _ _ 0 _

    Не укорочено

    _ _ _ _

    _ 1 _ _

    Официальный ответ

    Для поля флаги имени характерна следующая структура

    0_ _ _

    _ _ _ _

    Уникальное имя NetBIOS

    _ 10 _

    _ _ _ _

    Узел М-типа

    _ _ _ _

    _ 1 _ _ _

    Активное имя

    _ _ _ _

    _ _ 0_

    Временное имя

    Для поля флагов имени группы характерно следующее назначение бит

    1 _ _ _

    _ _ _ _

    Имя группы NetBIOS

    _ 10 _

    _ _ _ _

    Узел М-типа

    _ _ _ _

    _ 1 _ _ _

    Активное имя

    _ _ _ _

    _ _ 0_

    Временное имя

    Протокол WINS весьма удобен для сбора данных о МАС-адресах ЭВМ в многоранговой сети, где получить эти данные с помощью ARP-запросов невозможно. Какие-то данные можно извлечь из кэша маршрутизаторов или таблиц сетевых переключателей, если они доступны с помощью SNMP-запросов. Но WINS может дать больше данных, если рабочая станция использует операционную систему Windows. Так что, когда, скажем, программа Black ICE Defender пришлет вам MAC-адрес атакера, сидящего на другом континенте, не удивляйтесь, на помощь был призван протокол WINS.

    Previous: 4.2.2 AppleTalk    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.3 Региональные сети    Next: 4.3 Региональные сети


    previous up down next index index
    Previous: 4.3.3 Интегрированные сети ISDN    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.5 Протоколы сетей ATM

    4.3.4 Протокол Frame Relay
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол Frame Relay (I.122 ITU-t; ANSI T1S1.2; RFC-1490, -1315, -1604; cм. также www.frforum.com/frame-relay/5000/approved/frf.3/frf.3.1/frf3.f.0.html) является одним из новых телекоммуникационных протоколов (1993 г.), он обеспечивает большую скорость передачи данных (1,5Мбит/с), меньшие задержки, но и меньшую надежность доставки информации. Frame Relay предназначен для межсетевого общения, ориентирован на соединение и использует два протокольных уровня модели OSI. Остальные уровни должны реализоваться программно. Такая схема заметно удешевляет интерфейс. Протокол вводит понятие committed information rates (CIR - оговоренные скорости передачи), обеспечивая каждому приложению гарантированную полосу пропускания. Если приложение не использует полностью выделенную полосу, другие приложения могут поделить между собой свободный ресурс. Frame Relay гарантирует большее быстродействие, чем X.25. Стандарт предусматривает 2-х, 3-х и 4-х байтовые форматы заголовков (ANSI T1.618 и ITU-T Q.922) и синхронную передачу данных. Применение инкапсуляции гарантирует транспортировку пакетов других протоколов через сети Frame Relay. Пакет Frame Relay начинается и завершается разграничительным байтом 0x7e (что соответствует и стандарту Х.25). Максимальный размер кадра 1600 октетов. Формат пакета показан на рис. 4.3.4.1.

    Рис. 4.3.4.1. Формат пакетов Frame Relay (цифры сверху - номера байт)

    NLPID - идентификатор протокола сетевого уровня (network layer protocol ID).

    FCS - двухбайтовая контрольная сумма кадра (frame control sum). Заполнитель является опционным и может отсутствовать.

    Различные форматы заголовков кадров Frame Relay показаны на рисунках 4.3.4.2, 4.3.4.3 и 4.3.4.4. В верхней части рисунка приведена нумерация бит.

    Рис. 4.3.4.2. 2-байтовый заголовок пакета Frame Relay (адрес)

    C/R

    бит command/response (Команда/Отклик).

    E/A

    бит extended address (Расширенный адрес) определяет, следует ли рассматривать следующий байт в качестве части адреса (E/A=0 заголовок продолжается в следующем октете).

    DLCI

    (data link control interface) адрес управляющего интерфейса информационного канала (имеет только локальный смысл). В двухбайтовой версии DLCI занимает в сумме 10 бит.

    FECN

    бит forward explicit congestion notification (указание на возможность реагирования на перегрузку при посылке пакетов). Сигнализирует отправителю о переполнении буферов на приеме.

    BECN

    бит backward explicit congestion notification (тоже для случая приема пакетов).

    DE

    бит discard eligibility (пометка пакета при перегрузке канала). Помеченный пакет может быть отброшен и потребуется его повторная пересылка.

    При возникновении перегрузки DCE-узел отправляет устройствам-адресатам пакет с FECN=1, а узлам, шлющим ему информацию, пакет с битом BECN=1. Большое число пакетов с такими битами говорит о перегрузке и отправитель должен снизить частоту посылки пакетов или вовсе ее прекратить.

    Рис. 4.3.4.3. 3-байтовый заголовок пакета Frame Relay

    D/C - бит data/control (данные/управление) определяет, является ли последующее поле младшей частью DLCI или его следует интерпретировать как управляющую информацию DL-core.

    Рис. 4.3.4.4. 4-байтовый заголовок пакета Frame Relay

    Первым передается младший бит байта. Для управления сетью используется протокол snmp и база данных MIB. Формат кадра Frame Relay показан на рис. 4.3.4.4.

    NLPID - (network layer protocol identifier) идентификатор протокола сетевого уровня. Это поле может содержать коды многих протоколов, включая IP, CCITT Q.933, ISO 8208, IEEE SNAP, CLNP (ISO 8473) и т.д. Это поле говорит получателю, какой тип протокола инкапсулирован. Коды nlpid стандартизованы документом ISO/IEC TR 9577. Некоторые допустимые коды этого поля приведены в таблице 4.3.4.1. Пользовательская информация располагается, начиная с поля управления, и содержит код 0x03 для случая пересылки без подтверждения (Q.922, UI). Для всех прочих видов обмена (кадры I- S-типов) подтверждение доставки является обязательным. Поле заполнитель предназначено для выравнивания границы полей на 2-байтовый уровень. Длина этого поля может быть равной нулю или одному байту. Поле адрес описано выше (см. рис. 4.3.4.1, 4.3.4.2, 4.3.4.3). Если за кодом NLPID следует 4 октета уровней 2 и 3, это указывает на то, что используется связь, ориентированная на соединение. Протокол Frame Relay предусматривает гибкую систему межсетевых соединения на основе мостов-шлюзов и маршрутизаторов. Все мосты и маршрутизаторы должны быть способны воспринимать и правильно интерпретировать как NLPID- так и SNAP-инкапсуляцию. Для обеспечения правильной интерпретации идентификатора протокола PID, предусмотрен 3-октетный уникальный идентификатор OUI (organizationally unique identifier). В пакетах для мостов и маршрутизатором в поле OUI предшествует двух-октетному полю PID.

    Рис. 4.3.4.5. Формат маршрутизуемого кадра Frame Relay

    Нетрудно видеть, что кадр Frame Relay имеет много общего с X.25 и ISDN. Здесь уже на протокольном уровне предусматривается мультикастинг.

    Таблица 4.3.4.1. Коды поля NLPID (идентификатор протокола сетевого уровня)

    Тип кадра

    Название протокола

    Код

    I-кадр (ISO 8208)

    N по модулю 8
    N по модулю 128

    0x01
    0x10

    UI-кадр

    ip
    clnp
    q.933
    snap
    q.922
    802.2
    Протокол, заданный пользователем (уровень 3)

    0xcc
    0x81
    0x08
    0x80
    0x4e
    0x4c
    0x70

    Код протокола SNAP используется и для протоколов 802.3, 802.4, 802.5, FDDI и 802.6. При вложении IP в кадры Frame Relay в поле управления записывается код 0x03, а в поле NLPID - 0xcc, начиная с байта 5 располагается тело IP-дейтограммы, за которой следует поле FCS. Формат маршрутизируемой IP-дейтограммы показан на рис. 4.3.4.5А.

    Рис. 4.3.4.5А. Формат маршрутизируемой IP-дейтограммы

    Аналогично осуществляется инкапсуляция пакетов протокола clnp, только здесь в поле NLPID записывается код 0x81. Для примера на рис. 4.3.4.6 и 4.3.4.7 показаны пакеты для мостов 802.3 и FDDI (см. "Multiprotocol Encapsulation over Frame Relay").

    Рис. 4.3.4.6 Формат мостового кадра Ethernet 802.3

    Рис. 4.3.4.7 Формат мостового кадра FDDI

    Весьма перспективным сетевым протоколом особенно для передачи мультимедийных данных является ATM. Его модификация может стать транспортным протоколом для цифрового кабельного телевидения.

    Previous: 4.3.3 Интегрированные сети ISDN    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.5 Протоколы сетей ATM


    previous up down next index index
    Previous: 4.3.4 Протокол Frame Relay    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.6 Синхронные каналы SDH/SONET

    4.3.5 Протоколы сетей ATM
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В настоящее время начинают широко внедряться каналы с пропускной способностью 150,52 и 622,08 Мбит/с. Эти каналы используются как для соединения локальных сетей, так и непосредственно для построения скоростных LAN. 150 Мбит/с может обеспечить любые современные телекоммуникационные услуги кроме телевидения высокого разрешения. Предусмотрен стандарт и на скорость передачи 2,48832 Гбит/c. Так как время доставки для многих видов сетевых услуг реального времени является крайне важной характеристикой, АТМ находит широкое применение в телефонии, кабельном телевидении и других областях. Следует учитывать, что оцифрованный видеосигнал качества VHS требует 100Мбит/с при отсутствии сжатия и 1,5-6 Мбит/c при использовании сжатия. Файл изображения 1000х1000 пикселей при 24 битах, характеризующих цвет, занимает 3 Мбайта. ATM справится с передачей такого кадра с учетом накладных расходов (заголовок) за ~0,2 сек. Понятно, что при использовании сжатия можно получить заметно большее быстродействие.

    Это не значит, что доступны лишь указанные скорости, интерфейсы позволяют мультиплексировать большое число каналов с самыми разными скоростями обмена. Но мультиплексирование на таких частотах представляет собой значительную проблему. Определенные трудности представляет то обстоятельство, что в ATM трудно реализовать обмен без установления соединения (аналог utp в Интернет)

    Протокол ATM (asynchronous transfer mode; см. также А.Н. Назаров, М.В. Симонов. "АТМ. Технология высокоскоростных сетей". ЭКО-Трендз, М. 1998) является широкополосной версией ISDN, работает на скорости 150,52 Мбит/с с пакетом постоянной длины и минимальным заголовком. Слово асинхронный в названии означает, что тактовые генераторы передатчика и приемника не синхронизованы, а сами ячейки передаются и мультиплексируются по запросам. При мультиплексировании используется статистическая технология. Асинхронная передача не предполагает упорядочивания ячеек по каналам при пересылке. ATM поддерживает аппаратную и пакетную коммутацию.

    Каждый пакет ATM имеет 53 байта (в англоязычной документации пакеты ATM носят название cell (ячейка), этот термин введен, чтобы отличить пакеты ATM от пакетов низкоскоростных каналов), из них 48 байт несут полезную информацию (что для случая передачи звука, соответствует 6 мс). Для выделения пакета из потока используются такие же, как в ISDN разделительные байты (0x7E). Заголовок пакета содержит лишь 5 байт и предназначен главным образом для того, чтобы определить принадлежит ли данный пакет определенному виртуальному каналу. Отсутствие контроля ошибок и повторной передачи на физическом уровне приводит к эффекту размножения ошибок. Если происходит ошибка в поле идентификатора виртуального пути или виртуального канала, то коммутатор может отправить ячейку другому получателю. Таким образом, один получатель не получит ячейку, а другой получит то, что ему не предназначалось.

    Виртуальный канал в ATM формируется также как и в ISDN. Формально эта процедура не является частью ATM-протокола. Сначала здесь формируется сигнальная схема, для этого посылается запрос с VPI=0 и VCI=5. Если процедура завершилась успешно, можно начинать формирование виртуального канала. При создании канала могут использоваться 6 разновидностей сообщений.

    • setup - запрос формирования канала.
    • call proceeding - запрос в процессе исполнения.
    • connect - запрос принят.
    • connect ACK - подтверждение получения запроса.
    • release - сообщение о завершении.
    • release compleate - подтверждение получения сообщения release.

    Схема обмена сообщениями при установлении (и разрыве) виртуального соединения показана на рис. 4.3.5.1. Предполагается, что между ЭВМ-инициализатором и ЭВМ-адресатом находится два ATM-переключателя. Каждый из узлов по пути к месту назначения при получении запроса setup откликается, посылая сообщение call proceeding. Адрес места назначения указывается в сообщении setup. В ATM используется три вида адресов. Первый - имеет 20 байт и имеет структуру OSI-адреса. Первый байт указывает на вид адреса (один из трех). Байты 2 и 3 указывают на принадлежность стране, а байт 4 задает формат последующей части кода адреса, которая содержит 3 байта кода администрации (authority), 2 байта домена, 2 байта области и 6 байтов собственно адреса. Во втором формате байты 2 и 3 выделены для международных организаций, а не стран. Остальная часть адреса имеет тот же формат, что и в варианте 1. Третий формат является старой формой (CCITT E.164) 15-цифровых десятичных телефонных номеров ISDN. В ATM не специфицировано никакого алгоритма маршрутизации. Для выбора маршрута (от коммутатора к коммутатору) используется поле VCP. VCI используется лишь на последнем шаге, когда ячейка посылается от переключателя к ЭВМ. Такой подход упрощает маршрутизацию отдельных ячеек, так как при этом анализируется 12- а не 28-битовые коды. В каждом коммутаторе (переключателе) формируются специальные таблицы, которые решают проблему переадресации ячеек.

    Следует обратить внимание на то, что виртуальный канал (circuit) и виртуальный проход (path) в данном контексте не тождественны. Виртуальный проход (маршрут) может содержать несколько виртуальных каналов. Виртуальные каналы всегда являются полностью дуплексными.

    Рис. 4.3.5.1. Обмен сообщениями при установлении и разрыве виртуального соединения

    Сети ATM допускают создание мультикастных каналов. Такой канал имеет одного отправителя и много получателей. Первый канал формируется обычным путем, последующие участники сессии подключаются позднее путем посылки сообщения add party.

    За видимую простоту ячеек приходится платить тем, что управляющая информация передается в общем информационном потоке. Высокая скорость передачи данных требует применения аппаратно реализованных маршрутных таблиц на каждом переключателе пакетов. На рис. 4.3.5.2 представлен формат заголовка пакета ATM. Заголовок обеспечивает два механизма маршрутизации пакетов:

    • VPI (virtual path identifier - виртуальный идентификатор маршрута) обеспечивает соединение точка-точка, но маршрут не является фиксированным и задается непосредственно перед началом пересылки с использованием сигнальных сообщений. Слово "виртуальный" означает, что пакеты передаются от узла к узлу в соответствии с VPI.
    • VCI (virtual call identifier - виртуальный идентификатор запроса) запросы осуществляются в соответствии с виртуальным маршрутом, заданным VPI.

    Эти два субполя вместе образуют поле маршрута, которое занимает 24 бита.

    Рис. 4.3.5.2 Формат заголовка ATM-пакета (сетевой интерфейс пользователя - UNI)

    Для интерфейса сеть-сеть (NNI) используется ячейка с несколько иным форматом заголовка. Там весь первый октет выделен для VPI, а поле GFC отсутствует.

    GFC

    Generic flow control (4 бита, смотри описание пакетов ISDN) - общее управление потоком.

    VPI

    Virtual path identifier (8 бит, служит для целей маршрутизации) - идентификатор виртуального пути.

    VCI

    Virtual call identifier (16 бит, служит для целей маршрутизации) - идентификатор виртуального канала.

    PT

    Payload type (2 бита, тип данных; это поле может занимать и зарезервированное субполе RES.)

    RES

    зарезервированный бит.

    CLP

    (Cell loss priority - уровень приоритета при потере пакета) указывает на то, какой приоритет имеет пакет (cell), и будет ли он отброшен в случае перегрузки канала.

    HEC

    header error control (8 бит, поле контроля ошибок)

    Ряд значений VCI и VPI имеют фиксированные значения, приведенные в таблице 4.3.5.1

    Таблица 4.3.5.1.

    vci

    vpi

    Назначение

    0

    только 0

    Неопределенная ячейка

    1

    все

    Мета управление

    3

    все

    Сетевое управление VP-каналом

    4

    все

    vp-управление для соединения между конечными точками

    5

    все

    Управление доступом по схеме точка-точка

    6

    все

    Ячейка управления ресурсами (для подавления перегрузки)

    16

    только 0

    UNI (snmp) управление сетью

    Некоторые значения поля pt зафиксированы, их значения представлены в таблице 4.3.5.2.

    Таблица 4.3.5.2. Заданные значения поля PT (payload type identifier)

    PT

    Назначение ячейки

    Взаимодействие пользователь-пользователь

    000

    Пользовательские данные (перегрузка отсутствует)

    Нет

    001

    Пользовательские данные (перегрузка отсутствует)

    Нет

    010

    Пользовательские данные (имеет место перегрузка)

    Да

    011

    Пользовательские данные (имеет место перегрузка)

    Да

    100

    Ячейка виртуального канала oam сегментного потока f5

    101

    Соединение точка-точка oam сегментного потока f5

    110

    Управление ресурсами

    111

    Зарезервировано

    OAM - эксплуатация и техническое обслуживание. ATM обеспечивает любые услуги в сети:

    • Передача голоса на скоростях 64 Кбит/с. Один ATM-пакет соответствует 6 мсек.
    • Передача музыки с использованием схемы кодирования MUSICAM.
    • Так как для случая изображения передается только переменная часть картинки, atm идеально подходит для решения такого рода задач.
    • Задачи управления решаются менее экономно, но, тем не менее, достаточно эффективно (предусмотрено несколько приоритетов для управления потоками данных).

    В ATM предусмотрено несколько категорий услуг (таблица 4.3.5.3).

    Таблица 4.3.5.3. Типы категорий ATM-услуг

    Класс

    Описание

    Пример

    cbr

    Постоянная скорость передачи

    Канал Т1

    rt-vbr

    Переменная скорость передачи (реальное время)

    Видеоконференции

    nrt-vbr

    Пременная скорость передачи (нереальное время)

    Мультимедиа по электронной почте

    abr

    Доступная скорость передачи

    Просмотр web-информации

    ubr

    Не специфицированная скорость передачи

    Пересылка файлов в фоновом режиме

    CBR не предусматривает контроля ошибок, управления трафиком или какой-либо другой обработки. Класс CBR пригоден для работы с мультимедиа реального времени.

    Класс VBR содержит в себе два подкласса - обычный и для реального времени (см. таблицу выше). ATM в процессе доставки не вносит никакого разброса ячеек по времени. Случаи потери ячеек игнорируются.

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

    Класс UBR хорошо пригоден для посылки IP-пакетов (нет гарантии доставки и в случае перегрузки неизбежны потери).

    atm использует исключительно модель с установлением соединения (здесь нет аналогий с UDP-протоколом). Это создает определенные трудности для управления трафиком с целью обеспечения требуемого качества обслуживания (QoS). Для решения этой задачи используется алгоритм GCRA (generic rate algorithm). Работа этого алгоритма проиллюстрирована на рис. 4.3.5.3.

    Рис. 4.3.5.3. Иллюстрация работы алгоритма GCRA

    gcra имеет два параметра. Один из них характеризует максимально допустимую скорость передачи (PCR - peak cell rate; T=1/PCR - минимальное расстояние между ячейками), другой - допустимую вариацию значения скорости передачи (CDVT=L). Если клиент не собирается посылать более 100000 ячеек в секунду, то Т=10 мксек. На рис. 4.3.5.3 представлены разные варианты следования ячеек. Если ячейка приходит раньше чем T-t, она считается неподтверждаемой и может быть отброшена. Ячейка может быть сохранена, но при этом должен быть установлен бит CLP=1. Применение бита CLP может быть разной для разных категорий услуг (смотри таблицу 4.3.5.3.). Данный механизм управления трафиком сходен с алгоритмом "дырявое ведро", описанным в разделе "Сети передачи данных".

    Можно вычислить число подтверждаемых ячеек N, которые могут быть переданы при пиковом потоке ячеек PCR=1/t. Пусть время ячейки в пути равно d. Тогда N = 1 + (l/(T-d)). Если полученное число оказалось нецелым, оно должно быть округлено до ближайшего меньшего целого.

    Трудно устранимой проблемой для atm является предотвращение перегрузки на промежуточных коммутаторах-переключателях. Коммутаторы могут иметь 100 внешних каналов, а загрузка может достигать 350000 ячеек/сек. Здесь можно рассматривать две задачи: подавление долговременных перегрузок, когда поток ячеек превосходит имеющиеся возможности их обработки, и кратковременные пиковые загрузки. Эти проблемы решаются различными способами: административный контроль, резервирование ресурсов и управление перегрузкой, привязанное к уровню трафика.

    В низкоскоростных сетях с относительно медленно меняющейся или постоянной загрузке администратор вмешивается лишь при возникновении критической ситуации и предпринимает меры для понижения скорости передачи. Очень часто такой подход не слишком эффективен, так как за время доставки управляющих команд приходят многие тысячи ячеек. Кроме того, многие источники ячеек в ATM работают с фиксированной скоростью передачи (например, видеоконференция). Требование понизить скорость передачи здесь достаточно бессмысленно. По этой причине в АТМ разумнее предотвращать перегрузку. Но для трафика типа CBR, VBR и UBR не существует никакого динамического управления перегрузкой и административное управление является единственной возможностью. Когда ЭВМ желает установить новый виртуальный канал, она должна охарактеризовать ожидаемый трафик. Сеть анализирует возможность обработки дополнительного трафика с учетом различных маршрутов. Если реализовать дополнительный трафик нельзя, запрос аннулируется. В отсутствии административного контроля несколько широкополосных пользователей могут блокировать работу массы узкополосных клиентов сети, например, читающих свою почту.

    Резервирование ресурсов по своей сути близко административному контролю и выполняется на фазе формирования виртуального канала. Резервирование производится вдоль всего маршрута (во всех коммутаторах) в ходе реализации процедуры setup. Параметрами резервирования может быть значение пикового значения полосы пропускания и/или средняя загрузка.

    Для типов сервиса CBR и VBR отправитель даже в случае перегрузки не может понизить уровень трафика. В случае UBR потери не играют никакой роли. Но сервис ABR допускает регулирование трафика. Более того, такое управление здесь весьма эффективно. Существует несколько механизмов реализации такого управления. Так предлагалось, чтобы отправитель, желающий послать блок данных, сначала посылал специальную ячейку, резервирующую требуемую полосу пропускания. После получения подтверждения блок данных начинает пересылаться. Преимуществом данного способа следует считать то, что перегрузки вообще не возникает. Но данное решение не используется из-за больших задержек (решение ATM-форума).

    Другой способ сопряжен с посылкой коммутаторами специальных ячеек отправителю в случае возникновения условий перегрузки. При получении такой ячейки отправитель должен понизить скорость передачи вдвое. Предложены различные алгоритмы последующего восстановления скорости передачи. Но и эта схема отвергнута форумом atm из-за того, что сигнальные ячейки могут быть потеряны при перегрузке. Действительно данный алгоритм не всегда можно признать разумным. Например, в случае, когда коммутатор имеет 10 каналов с трафиком по 50 Мбит/с и один канал с потоком в 100 кбит/c, глупо требовать понижения трафика в этом канале из-за перегрузки.

    Третье предложение использует тот факт, что граница пакета помечается битом в последней ячейке. Коммутатор просматривает входящий поток и ищет конец пакета, после чего выбрасывает все ячейки, относящиеся к следующему пакету. Этот пакет будет переслан позднее, а отбраcывание M ячеек случайным образом может вынудить повторение передачи m пакетов, что значительно хуже. Данный вариант подавления перегрузки был также не принят, так как выброшенный пакет совсем не обязательно послан источником, вызвавшим перегрузку. Но этот способ может быть использован отдельными производителями коммутаторов.

    Обсуждались решения, сходные с тем, что используется в протоколе TCP "скользящее окно". Это решение требует слишком большого числа буферов в коммутаторах (как минимум по одному для каждого виртуального канала). После длинных дискуссий был принят за основу совершенно другой метод.

    После каждых М информационных ячеек каждый отправитель посылает специальную RM-ячейку (resource management). Эта ячейка движется по тому же маршруту, что и информационные, но RM-ячейка обрабатывается всеми коммутаторами вдоль пути. Когда она достигает места назначения, ее содержимое просматривается и корректируется, после чего ячейка посылается назад отправителю. При этом появляются два дополнительных механизма управления перегрузкой. Во-первых, RM-ячейки могут посылаться не только первичным отправителем, но и перегруженными коммутаторами в направлении перегрузившего их отправителя. Во-вторых, перегруженные коммутаторы могут устанавливать средний PTI-бит в информационных ячейках, движущихся от первоисточника к адресату. Но даже выбранный метод подавления перегрузки не идеален, так как также уязвим из-за потерь управляющих ячеек.

    Управление перегрузкой для услуг типа abr базируется на том, что каждый отправитель имеет текущую скорость передачи (ACR - actual cell rate), которая лежит между MCR (minimum cell rate) и PCR (peak cell rate). Когда происходит перегрузка, ACR уменьшается, но не ниже MCR. При исчезновении перегрузки acr увеличивается, но не выше PCR. Каждая RM-ячейка содержит значение загрузки, которую намеривается реализовать отправитель. Это значение называется ER (explicit rate). По пути к месту назначения эта величина может быть уменьшена попутными коммутаторами. Ни один из коммутаторов не может увеличивать ER. Модификация ER может производиться как по пути туда, так и обратно. При получении RM-ячейки отправитель может скорректировать значение ACR, если это необходимо.

    С точки зрения построения интерфейса и точек доступа (T, S и R) сеть ATM сходна с ISDN (см. рис. 4.3.3.1 ).

    Для физического уровня предусмотрены две скорости обмена 155,52 и 622,08 Мбит/с. Эти скорости соответствуют уровням иерархии SDH STM-1 и 4*STM-1. При номинальной скорости 155.52 Мбит/с пользователю доступна реально скорость обмена 135 Мбит/c, это связано с издержками на заголовки и управление. Для ATM используются коаксиальные кабели, скрученные пары (<100м для обоих вариантов) и оптоволоконные кабели (~2км). Для канала связи рассматриваются два кода CMI (coded mark inversion) и скрэмблеры типа установка-сброс (set-reset). В CMI двоичный 0 передается как отрицательный импульс половинной длины, за которым следует положительный импульс той же длительности. Двоичная 1 представляется в виде отрицательного или положительного импульса полной длины, так чтобы уровень менялся для последовательно следующих 1 (система AMI, см. раздел 2.1). Это обеспечивает балансировку передающей линии по постоянному напряжению, но удваивает частоту переключения практически вдвое. Скрамблерный метод не меняет частоту переключения, но его эффективность зависит от передаваемой информации. CMI предпочтительней для 155 Мбит/с. В настоящее время используется две схемы передачи данных применительно к ATM: базирующийся на потоке пакетов (cell stream) и на SDH структурах. В первом случае мы имеем непрерывный поток 53-октетных пакетов, во втором эти пакеты уложены в STM-1 кадры. Управляющие сообщения располагаются в заголовках секции и пути кадра SDH. AAL (ATM adaptation layer) служит для адаптации различных видов сервиса к требованиям ATM-уровня. Каждый вид услуг требует своего AAL-протокола. Главной целью AAL является обеспечение удобства при создании и исполнении программ прикладного уровня. Для всех AAL определены два субуровня:

    SAR

    (segmentation and reassemble) делит пакеты высокого уровня, передает atm и наоборот (сборка сообщений из сегментов).

    CS

    (convergent sub-layer) зависит от вида услуг (обработка случаев потери пакета, компенсация задержек, мониторирование ошибок и т.д.). Этот подуровень может в свою очередь делиться на две секции: CPCS (common part convergence sublayer) - общая часть субуровня конвергенции и SSCS (service-specific convergence sublayer) - служебно-ориентированный подуровень конвергенции (последний может и отсутствовать).

    aal-протоколы управляются значениями следующих переменных:

    • Скорость обмена (постоянная или переменная)
    • Режим соединения (с установлением связи или без)
    • Синхронизация (требуется или нет синхронизация между отправителем и получателем)

    В настоящее время определены четыре класса услуг, которые могут требовать или нет синхронизации между отправителем и получателем, осуществлять обмен при постоянной или переменной частоте передачи бит, с установлением связи или без. Особенности этих видов услуг для адаптивного уровня систематизированы в таблице 4.3.5.4. Каждая из услуг имеет свой AAL протокол.

    Таблица 4.3.5.4. Особенности видов услуг для адаптивного уровня

    Класс a (AAL1)

    Класс b (AAL2)

    Класс c (AAL3/4 или 5)

    Класс d (AAL3/4 или 5)

    Синхронизация работы отправителя и получателя

    необходима

    необходима

    не нужна

    не нужна

    Частота следования битов

    Постоянная

    Переменная

    Переменная

    Переменная

    Режим соединения

    С соединением

    С соединением

    С соединением

    Без соединения

    Уровень адаптации 1-го уровня (AAL) выполняет для верхнего уровня следующие услуги (передача аудио- и видео- по каналам DS-1 и DS-3; постоянная скорость передачи):

    • синхронизацию передатчика и приемника;
    • передачу данных с фиксированной скоростью;
    • индикацию потери и искажения данных, если эти ошибки не устраняются на уровне адаптации;
    • передачу от отправителя получателю информации о структуре передаваемых данных.

    Для решения этих задач AAL первого уровня должен устранять разброс задержек, выявлять ячейки, доставленные не по адресу, и потерянные ячейки, сегментацию пакетов и последующее их восстановление, выполнять мониторирование ошибок в управляющей информации протокола AAL-PCI (protocol control information). Характер обмена здесь строго ориентирован на соединение. AAL-1 использует субуровни конвергенции и SAR. Субуровень конвергенции обеспечивает постоянство скорости передачи ячеек. AAL-1 конвергенции не имеет какого-то специфического протокольного заголовка. Этот субуровень разбивает входные сообщения на 46- или 47-байтные блоки и передает их субуровню SAR для пересылки.

    Структура протокольной части информационного поля ячейки SAR-pdu представлена на рис. 4.3.5.4

    CSI позволяет приемнику распознать уровень конвергенции. Подуровень SAR получает значение SN (порядковый номер) для каждого 47-октетного блока данных от подуровня конвергенции. Поле SNR (sequence number protection - контрольная сумма) служит для обнаружения и исправления ошибок в заголовке, в качестве производящего полинома используется G(x)= x3 + x + 1. Один из битов SNP- представляет собой бит четности. Если CSI=1, то после поля SNP следует однобайтовое поле указатель, которое используется для определения положения начала следующего сообщения (значения 0-92; старший бит поля указатель зарезервирован на будущее). Поле данных в этом варианте имеет 64 байт.

    Для сжатой аудио и видео информации скорость передачи может варьироваться в широких пределах. Ведь многие схемы предусматривают периодическую отправку полного видеокадра при последующей передаче транспортируются лишь отличия последовательных кадров. Уровень адаптации 2-го типа предоставляет вышестоящему уровню возможность синхронизовать передатчик и приемник, осуществлять обмен с изменяющейся скоростью, оповещение об ошибках и потерях ячеек. Структура ячейки AAL 2-го типа показана на рис. 4.3.5.5 (субуровень SAR). Из-за переменной скорости передачи заполнение ячеек может быть неполным.

    Рис. 4.3.5.4. Структура PDU подуровня SAR ATM 1-го типа (AAL1)

    CSI

    (convergence sublayer indicator) - индикатор подуровня конвергенции

    SN

    (sequence number) - номер по порядку

    SNP

    (sequence number protection) - защита номера последовательности

    Рис. 4.3.5.5. Структура PDU подуровня SAR ATM 2-го типа (AAL2)

    IT

    (information type) - тип данных. Служит для указания начала, продолжения или окончания сообщения

    LI

    (length indicator) - индикатор длины. Указывает число октетов в поле данных

    CRC

    Контрольная сумма

    Поля SN и IT имеют общую длину 1 байт, поля же LI и CRC вместе занимают 2 байта. Поле данных (PDU) в такой ячейке имеет длину 45 байт. Более детальной информации о длинах полей стандарт не оговаривает.

    Уровень адаптации 3/4 типов предназначен для передачи данных как в режиме с установлением соединения, так и без него. Раньше службам С и D были выделены разные типы уровня адаптации, позднее они были объединены. Определены два типа обмена: сообщение и поток. В первом случае блок данных передается в одном интерфейсном блоке (IDU). Сервисные блоки данных могут иметь переменную длину. В режиме поток сервисный блок данных передается через интерфейс уровня адаптации в одном или нескольких IDU. В этом режиме может быть реализована услуга "внутренний контейнер". Здесь допускается и прерывание передачи, частично переданный блок теряется. AAL3/4 допускает организацию нескольких сессий одновременно (например, несколько удаленных login). Структура протокольного блока данных подуровня SAR 3/4 типа представлена на рис. 4.3.5.6. Длина поля данных (PDU) составляет 44 байта. Заметим, что AAL3/4 имеет два уровня издержек - 8 байт добавляется для каждого сообщения и 4 избыточных байта приходятся на каждую ячейку, это достаточно много особенно для коротких сообщений.

    Рис. 4.3.5.6. Структура pdu подуровня SAR ATM 3/4-го типов

    ST

    (segment type) - тип сегмента. Начало сообщения - 10 (BOM - beginning of message), продолжение - 00 (COM - continuation of message), завершение сообщения - 01 (EOM - end of message), односегментное сообщение - 11;

    SN

    (sequence number) - номер по порядку;

    MID

    (multiplexing identifier) - идентификатор мультиплексирования для протокола 4-го уровня (позволяет мультиплексировать до 1024 пользователей для одного соединения). Поле служит для определения того, к какой из активных сессий принадлежит данная ячейка.

    li

    длина заполнения поля данных.

    При вычислении crc используется образующий полином G(x) = x11 + x9 + x5 + x4 + x +1. Подуровень конвергенции aal содержит общую часть подуровня CPCS (common path convergence sublayer) и служебную часть подуровня SSCS (service specific convergence sublayer). CPCS обеспечивает негарантированную доставку кадров любой длины в диапазоне 1-65535 байт. Данные пользователя передаются непосредственно на субуровень AAL. Формат протокольного блока данных подуровня конвергенции AAL 3/4-типа показан на рис. 4.3.5.7.

    Рис. 4.3.5.7. Формат блока данных подуровня конвергенции AAL 3/4-типа

    CPI

    (common part indicator) - однооктетный индикатор общей части, используется при интерпретации последующих полей;

    BTAG

    (beginning tag) - однооктетная метка начала, в сочетании с ETAG определяет границы протокольного блока данных (PDU);

    BAsize

    (buffer allocation size) - емкость буфера, сообщает получателю максимальный размер буфера. Поле занимает 2 байта;

    PAD

    заполнитель, обеспечивает кратность поля данных 4 октетам;

    AL

    (alignment) - выравнивание, заполняется нулями;

    ETAG

    (end tag) - метка конца (один октет);

    Длина

    задает протяженность cpcs-pdu;

    CPCS-PDU

    (common part convergence sublayer - protocol data unit) - протокольный блок данных общей части подуровня конвергенции

    Тип 3/4 имеет существенную избыточность (4 байта из 48 на каждый SAR-PDU). По этой причине был введен 5-ый тип. Этот уровень обеспечивает канал, ориентированный на соединение, с переменной скоростью обмена (VBR) в широковещательном режиме при минимальном контроле ошибок (или вовсе без него). IP-дейтограммы передаются через сети ATM через адаптационный уровень 5 (RFC-1577). Уровень AAL5 иногда называют SEAL (simple and efficient adaptation layer - простой и эффективный адаптационный уровень). AAL5 занимает в наборе протоколов семейства ATM нишу протокола udp стека TCP/IP. Формат ячейки SAR-PDU 5-го типа показан на рис. 4.3.5.8.

    Рис. 4.3.5.8. Формат ячейки SAR-PDU 5-го типа (AAL5)

    Рис. 4.3.5.8a. Формат сообщения AAL5 субуровня конвергенции

    UU

    (user to user) - поле необходимо для верхних уровней, чтобы обеспечить мультиплексирование;

    Длина

    двухоктетное поле длины поля данных (PDU);

    CRC

    4-октетная контрольная сумма;

    Однобайтовое поле, расположенное между полями UU и длина зарезервировано для использования в будущем. Так как здесь для переноса информации используется заголовок, работа AAL не является независимой от нижележащего уровня, что является нарушением эталонной модели. Инкапсулироваться в поля данных AAL5 могут блоки длиной до 216-1 октетов (65535). Выполнение операций здесь зависит от того, работает ли система в режиме сообщения или потока. На подуровне конвергенции для передачи протокольного блока данных используется 4-х байтовая CRC с образующим полиномом G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1, что обеспечивает высокую надежность корректности доставки. Положение адаптационного уровня в рамках эталонной модели показано на рис. 4.3.5.9. Следует впрочем заметить, что не вполне ясно, какой уровень занимает сам протокол ATM (транспортный или сетевой?).

    Рис. 4.3.5.9. Положение уровней ATM в универсальной модели

    Верхние уровни управления для ATM базируются на рекомендациях ccitt I450/1 (Q.930/1). В случае использования ATM для Интернет значение MTU по умолчанию равно 9180 (RFC-1626), так как фрагментация IP-дейтограмм крайне нежелательна (AAL). Работа протоколов TCP/IP поверх ATM описана в документах RFC-1483, -1577, -1626, -1680, -1695, -1754, -1755, -1821, -1926, -1932 (полужирным шрифтом выделены коды документов, являющиеся стандартами Интернет). Ниже на рис. 4.3.5.10 показано, как пакеты atm размещаются в кадрах STM-1 (виртуальный контейнер VC-4).

    Рис. 4.3.5.10. Размещение atm пакетов в STM-1 кадре

    В STM-1 для передачи ячеек выделяется полоса пропускания =150,3 Мбит/c. (9 рядов по 261 байту, передаваемые каждые 125 мксек)

    Форматы адресов согласно спецификации интерфейса "пользователь-сеть" представлены на рис. 4.3.5.11.

    Рис. 4.3.5.11. Формат DCC ATM с числовым кодом страны.

    AFI

    (authority and format identifier) - идентификатор формата и привилегий.

    DCC

    (data country code) - код данных страны (стандарт МОС 3166).

    DFI

    (DSP format identifier) - идентификатор формата DSP.

    DSP

    (domain specific part) - часть, зависящая от домена.

    AA

    (administrative authority) - административное субполе.

    RSVD

    (reserved) - резерв на будущее.

    RD

    (routing domain) - область маршрутизации.

    AREA

    идентификатор зоны.

    ESI

    (end system identifier) - идентификатор оконечной системы.

    SEL

    (selector) - селектор.

    IDI

    (initial domain identifier) - идентификатор исходной области.

    HO

    (higher order) - старшая часть.

    Формат ICD с указателем международного кода отличается от формата DCC тем, что в нем поле DCC заменено полем международного кода ICD (international code designator). Формат адреса Е.164 NSAP, где идентификатор исходной области является номером Е.164, представлен на рис. 4.3.5.12. Структура номера (15 десятичных цифр в кодировке BCD) места назначения отображена на рис. 4.3.5.13.

    Важную роль в управлении сетями АТМ играет информация OAM(operations and maintenance). Здесь осуществляется тесное взаимодействие с потоками управления sdh (F1-F5).

    F1 - поток данных oam уровня регенерационной секции SDH.
    F2 - поток данных oam цифровой мультиплексорной секции SDH.
    F3 - поток данных oam уровня пути обмена SDH.
    F4 - поток данных oam виртуального пути АТМ.
    F5 - поток данных oam виртуального канала АТМ.

    Рис. 4.3.5.12. Формат адреса Е.164 NSAP

    Рис. 4.3.5.13. Структура номеров

    Код страны (СС -country code) занимает от одной до трех цифр (из 15).

    Маршрутизация в atm отличается от аналогичных процессов в сетях с коммутацией пакетов. Сети АТМ в основном ориентированы на соединение. Ячейки транспортируются по уже выбранному маршруту через коммутаторы АТМ в соответствии со значениями идентификаторов виртуального пути и виртуального канала. Вычисление маршрута осуществляется на специальном сервере. Потоки информации F4 или F5 принимаются и обрабатываются устройствами, которые формируют виртуальные пути или каналы. Формат информационного поля ячейки oam показан на рис. 4.3.5.14. Поток информации oam F4 уровня виртуального пути для идентификации потока точка-точка использует идентификатор виртуального канала VCI=4, а для сегментных потоков VCI=3.

    Рис. 4.3.5.14. Формат ячейки OAM F4

    Поток ячеек OAM F5 уровня виртуального канала каких-либо специальных идентификаторов виртуальных путей не использует. В заголовках ячеек потока oam F5 типа точка-точка в поле типа данных (PT) записывается код 100, а для сегментных потоков виртуальных каналов PT=101. Значения кодов полей тип OAM и выполняемой функции приведены в таблице 4.3.5.5. Для решения проблем выявления и локализации отказов в сети АТМ используются ячейки AIS (alarm indication signal - аварийный сигнал), RDI/FERF (remote defect indication/far end reporting failure - указатель отказа на удаленном конце), контроля непрерывности (continuity check) и проверки с применением обратной связи (loopback). Для ячеек AIS и RDI поля тип отказа имеет 8 байт (по умолчанию во все октеты записывается 0х6А), а для указателя места отказа выделено 9 байт. Полезная часть поля данных в этих ячейках равна 45 байтам, из них 28 зарезервировано на будущее.

    Таблица 4.3.5.5.

    Код поля тип oam

    Назначение

    Код поля тип выполняемой функции

    Назначение

    0001

    Обнаружение и определение места отказов (fault management)

    0000

    Указание отказа (AIS)

    0001

    Указание на удаленный дефект (RDI/FERF)

    0100

    Проверка непрерывности (continuity check)

    1000

    Обратная связь (loopback)

    0010

    Контроль рабочих характеристик

    0000

    Прямой мониторинг (forward monitoring)

    0001

    Сообщение о предыстории (backward reporting)

    0010

    Мониторирование и предоставление результатов (monitoring and reporting)

    1000

    Активизация и завершение процессов oam

    0000

    Мониторинг рабочих характеристик (performance monitoring)

    0001

    Проверка непрерывности (continuity check)

    Контроль рабочих характеристик сети АТМ производится без нарушения соединений и без снижения качества обслуживания. Для запуска и остановки процесса измерения служат ячейки типа activation/deactivation. В ячейке oam для этих целей в поле данных выделено 45 байт. Формат субполей поля данных представлен на рис. 4.3.5.15.

    Рис. 4.3.5.15. Формат субполей поля данных oam activation/deactivation

    Субполе неиспользуемые октеты заполняется байтами 0х6А, а субполя блок РМ - кодами 0000. Значения кодов поля идентификатор сообщения приведены в таблице 4.3.5.6.

    Таблица 4.3.5.6.

    Код поля идентификатор сообщения

    Назначение

    000001

    Активация (запрос)

    000010

    Подтверждение активации

    000011

    Отвержение запроса активации

    000101

    Деактивация

    000110

    Подтверждение деактивации

    000111

    Отвержение запроса деактивации

    В субполе направление действия заносится код 10 при направлении от А к В и 01 при противоположном направлении. В поле размер записывается код 1000 при длине 1024 ячеек, 0100 - при 512, 0010 - при 256 и 0001 - при 128. Размеры блоков для направлений А ->b и В ->a могут быть и неравными. Мониторинг рабочих параметров может выполняться для А ->b, В ->a или для обоих направлений одновременно.

    Формат ячеек oam типа измерение рабочих характеристик представлен на рис. 4.3.5.16.

    Рис. 4.3.5.16. Формат ячеек oam типа измерение рабочих характеристик

    В субполя BIP-16 (bit interleaved parity) и счет потерянных ячеек в отсутствии прямого мониторинга по умолчанию заносится код 0х6А, аналогичный код записывается в субполя число ячеек пользователя и результаты анализа в отсутствие обратного мониторинга. В неиспользуемое поле записываются 1 во все биты, если не использована временная метка. Поле порядковый номер мониторинга (MSN - monitoring sequence number) содержит номер ячейки oam типа PM по модулю 256. Поле общее число ячеек пользователя (TUC - total user cell) записывается число пользовательских ячеек, отправленных после последней ячейки OAM типа PM.

    Один физический отказ может сгенерировать большое число ячеек OAM. Для блокировки такой возможности введено ограничение на период генерации таких ячеек (> нескольких секунд). Операции проверки тракта, выполняемые с помощью ячеек OAM типа loopback, позволяют выявить место возникновения неисправностей. Формат поля специальных функций ячейки OAM типа loopback отображен на рис. 4.3.5.17 (см. также рис. 4.3.5.14).

    Рис. 4.3.5.17. Формат ячейки oam типа loopback

    Поле неиспользуемое содержит во всех октетах по умолчанию код 0х6А. Поле индикатор шлейфа содержит 1 при посылке отправителем (остальные семь бит равны нулю), единица заменяется нулем в момент приема. При получении ячейки с индикатором шлейфа, равным нулю, она уничтожается. Поле корреляционная метка используется отправителем для идентификации отклика. Поле идентификатор места шлейфа определяет место, откуда ячейка должна быть послана назад. Если поле содержит все единицы, таким местом является адресат. Поле идентификатор источника служит для распознавания ячейки и ее уничтожения при возвращении.

    Предоставление услуг без установления соединения соответствует уровню выше чем АТМ и требует соединения каждого клиента с соответствующим сервером, решающим данную задачу. Большинство локальных и региональных сетей АТМ реализуют именно такой режим. Для передачи данных без установления соединения используется протокол доступа CLNAP (connectionless network access protocol), интерфейс CLAI (connectionless access interface) и сетевой протокол CLNIP (connectionless network interface protocol). Размер поля данных для CLNAP не является постоянным и составляет 9188 октетов, что подразумевает фрагментацию. Эти протоколы работают выше подуровня конвергенции. Соответствующая длина для CLNIP SDU равна 9236 октетам. Формат блока данных CLNIP показан на рис. 4.3.5.18.

    Рис. 4.3.5.18. Формат структуры данных протокола CLNIP

    PI

    (protocol identifier) - идентификатор протокола.

    PADLE

    (padding length) - длина заполнения.

    QoS

    (quality of service) - качество обслуживания

    С

    (CRC indication bit) - индикатор числа бит в контрольной сумме CRC.

    HEL

    (header extension length) - длина расширения заголовка.

    Проблему фрагментации и инкапсуляции этих длинных пакетов в АТМ ячейки берет на себя коммутатор доступа. Схема вложения и фрагментации для пакетов clnap отображена на рис. 4.3.5.19.

    Из рисунка видно, что на подуровне SAR происходит деление пакета на части и укладка полученных сегментов в поля данных ячеек (48 байт).

    Рис. 4.3.5.19. Схема вложения и фрагментации для пакетов CLNAP

    АН

    - (alignment header; 4 октета) - поле выравнивания.

    SAR

    - (segmentation and reassemble) - сегментация и сборка.

    CPCS

    - (common part convergence sublayer) общая часть подуровня конвергенции.

    Для использования одного и того же виртуального канала многими протоколами служит LLC-инкапсуляция (logical link control). LLC-заголовок укладывается в поле данных перед PDU и содержит в себе информацию, необходимую для того, чтобы корректно обработать AAL5 CPCS-PDU. Обычно такой заголовок имеет формат IEEE 802.2, за которым может следовать SNAP-заголовок IEEE 802.1a. LLC-заголовок, содержащий код 0xFE-fe-03, говорит о том, что далее следует маршрутизируемый pdu длиной 216-4 октетов. Одно-октетный код NLPID идентифицирует сетевой протокол. Значения кодов NLPID представлены в таблице 4.3.5.7.

    Таблица 4.3.5.7. Значения кодов NLPID

    Код nlpid

    Назначение

    0х00

    Нулевой сетевой уровень (в atm не используется)

    0х80

    SNAP

    0х81

    ISO CLNP

    0х82

    ISO ESIS

    0х83

    ISO ISIS

    0хСС

    Интернет (IP не является протоколом ISO)

    Формат PDU для маршрутизируемых данных при использовании протоколов, не принадлежащих ISO, представлен на рис. 4.3.5.20 (случай IP-дейтограммы).

    Рис. 4.3.5.20. Формат IP PDU при транспортировке с использованием AAL5 ATM

    Пропускная способность сети АТМ (150 Мбит/с) позволяет передавать немного более 360000 ячеек в секунду, что означает для ATM-переключателя время коммутации менее 2,7 мксек. Реальный переключатель может иметь от 16 до 1024 входных линий, что может означать коммутацию 16-1024 ячеек каждые 2,7 мксек. При быстродействии 622 Мбит/с новая порция ячеек поступает каждые 700 нсек. Постоянство длины ячеек упрощает конструкцию ключа. Все АТМ-ключи имеют целью обеспечить коммутацию с минимальной вероятностью потери и исключить возможность изменения порядка следования ячеек. Приемлемой считается вероятность потери ячейки не более 10-12. Это эквивалентно для большого коммутатора потери 1-2 ячеек в час. Уменьшению вероятности потери способствует создание буферов конвейерного типа. Если на вход переключателя приходят две ячейки одновременно, одна из них обслуживается, а вторая ставится в очередь (запоминается в буфере). Выбор ячеек может производиться псевдослучайно или циклически. При этом не должно возникать предпочтений для каких-то каналов. Если в один цикл на вход (каналы 1, 2, 3 и 4) коммутатора пришли четыре ячейки, предназначенные для выходных линий J+2, J, J+2 и J+1, соответственно, то на линии J+2 возникает конфликт. Предположим, что будет обслужена ячейка, поступившая по первой входной линии, а ячейка на входной линии 3 будет поставлена в очередь. В начале следующего цикла на выход попадут три ячейки. Предположим также, что в этот цикл на ходы коммутатора (1 и 3) придут ячейки адресованные для линий J+3 и J, соответственно. Ячейка, адресованная J, будет поставлена в очередь вслед за ячейкой, адресованной J+2. Все эти ячейки будут переданы только на 4-ом цикле. Таким образом, попадание в очередь на входе ячейки блокирует передачу последующих ячеек даже если выходные каналы для их передачи свободны. Чтобы исключить блокировку такого рода можно организовать очередь не на входе, а на выходе коммутатора. При этом для коммутатора с 1024 входами теоретически может понадобиться 1024 буфера на каждом выходе. Реально число таких буферов значительно меньше. Такая схема АТМ-коммутатора (8*8) показана на рис. 4.3.5.21.

    Рис. 4.3.5.21. Схема переключателя с организацией очередей на выходе

    Концентратор выбирает N ячеек для помещения в очередь (предполагается, что максимальная длина очереди может быть равна N). Выходной буфер уже заполнен, ячека может быть потеряна. При построении АТМ-коммутаторов часто используется схема сети с многокаскадными соединениями.

    Previous: 4.3.4 Протокол Frame Relay    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.6 Синхронные каналы SDH/SONET


    previous up down next index index
    Previous: 4.3 Региональные сети    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.2 Протоколы сетей X.25

    4.3.1 Эталонная сетевая модель ISO
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Международная организация по стандартизации (ISO) определила 7-уровневую эталонную сетевую модель для открытых систем (OSI), (Интернет использует 4-х уровневое подмножество). Ниже на рис. 4.3.1.1 показана схема этих уровней, справа записаны коды документов международного Телекоммуникационного союза (ITU), регламентирующих протоколы соответствующих уровней.

    Рис. 4.3.1.1. Семиуровневая эталонная модель ISO

    Разбиение совокупности (стека) сетевых протоколов по уровням связана с попыткой унификации аппаратного и программного обеспечения. Предполагается, что каждому из уровней соответствует определенная ункциональная программа с жестко заданными входным и выходным интерфейсами. Форматы данных на заданном уровне модели для отправителя и получателя должны быть идентичны. Физический уровень локальных сетей определен документами, например, Ethernet II, IEEE 802.3 и т.д. Модели ISO наиболее полно соответствуют сети X.25.

    Физический уровень X.25 определяет стандарт на связь между ЭВМ и сетевыми коммутаторами (X.21), а также на процедуры обмена пакетами между ЭВМ. X.21 характеризует некоторые аспекты построения общественных сетей передачи данных. Следует учитывать, что стандарт X.25 появился раньше рекомендаций ITU-T и опыт его применения был учтен при составлении новейших рекомендаций. На физическом уровне могут использоваться также протоколы X.21bis, RS232 или V.35.

    Канальный уровень определяет то, как информация передается от ЭВМ к пакетному коммутатору (HDLC - high data link communication, бит-ориентированная процедура управления), на этом уровне исправляются ошибки, возникающие на физическом уровне.

    Сетевой уровень определяет взаимодействие различных частей субсети, форматы пакетов, процедуры повторной передачи пакетов, стандартизует схему адресации и маршрутизации.

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

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

    Презентационный уровень обеспечивает прикладной уровень стандартными услугами (сжатие информации, поддержка ASN.1 (abstract syntax notation 1) управляющих протоколов и т.д.).

    Прикладной уровень - это все, что может понадобиться пользователям сетей, например X.400.

    Международным стандартом в процедуре HDLC определены два вида кадров:

    Рис. 4.3.1.2 Два вида кадров процедур HDLC

    Флаг f = 01111110 задает границы кадра, SCS - контрольная сумма. Поля информация может иметь переменную длину, кратную восьми бит. Для HDLC определены три класса кадров: информационные (I), управляющие (S -supervisory) и ненумерованные (U - unnumbered). (Эти форматы соответствуют канальному уровню протокола x.25). Формат поля управление I-кадра показан на рис. 4.3.1.3.

    Рис. 4.3.1.3. Формат поля управления I-кадра (нумерация по модулю 128)

    \

    N(S) и N(S) представляют собой поля номера кадров. N(R) - номер текущего кадра, а N(R) - номер следующего кадра, который отправитель текущего кадра ожидает получить. При несоответствии ожидаемого номера и полученного возникает ошибка. Если используется нумерация кадров по модулю 8, то максимальное число кадров, не получивших подтверждение не может превышать 7, а размер полей N(S) и N(R) равен трем бит. Это справедливо и для s-кадров. i, s и u-кадры могут иметь обычный (один байт) и расширенный (2 байта) форматы. Младший бит (1) расположен слева. Поле P/F - флаг опрос/окончание опроса. Информационный (I) кадр содержит поле информация (см. рис. 4.3.1.2). Формат S- кадра показан на рис. 4.3.1.4.

    Рис. 4.3.1.4. Формат поля управления s-кадра (расширенный вариант)

    Для однобайтовой версии s-кадра за полем s следует непосредственно поле P/F. Поле S определяет тип управляющего кадра (см. таблицу 4.3.1.1):

    Таблица 4.3.1.1. Коды поля S

    Код s-поля

    Назначение

    00

    RR-кадр (receiver ready) готов к приему

    01

    RNR-кадр (receiver not ready) не готов к приему

    10

    REJ-кадр (reject) отказ от приема

    11

    SREJ-кадр (selected reject) выборочный отказ от приема

    S-кадры служат для передачи сигналов подтверждения, запросов повторной передачи или прекращения посылки кадров из-за блокировки приема в местной станции. При получении кадра с неверным порядковым номером (напр., предшествующий кадр потерян), приемник посылает S-кадр REJ, что означает необходимость повторной посылки предшествующего кадра и всех последующих. Кадр SREJ(n) указывает на то, что все кадры до n-1, включительно, доставлены без ошибок, а при доставке кадра n допущена ошибка и он должен быть послан повторно. В отличии от rej запрашивается пересылка только одного кадра. Связь с терминалом является временной, если бит P/F равен 1. Если адрес места назначения равен 11111111, то обращение является широковещательным. Формат U-кадра представлен на рис. 4.3.1.5.

    Рис. 4.3.1.5. Формат поля управления U-кадра

    U-кадр используется для формирования канала, изменения режима работы и управления системой передачи данных. Существует версия, когда поле "0" размещается не в 8-ой позиции, а в 5-ой. В нижней части рисунка показана расширенная версия формата. Младшие разряды располагаются слева. Поле m может принимать значения, приведенные в таблице 3.5.1.2.

    Установление соединения начинается с передачи в канал команды SABM (или SABME). Если удаленной станцией эта команда принята правильно и имеется возможность установления соединения, то присылается отклик UA. При этом переменные состояния на удаленной станции V(S) и V(R) (аналоги полей N(S) и N(R) в пакетах) устанавливаются в нулевое состояние.

    Таблица 4.3.1.2. Коды поля M (U-кадр).

    Код поля М

    Мнемоника

    Назначение

    00000

    UI

    Ненумерованная информация

    00001

    SNRM

    Установка нормального отклика (set normal regime mode)

    00010

    DISC/RD

    Отсоединение (disconnect / request disconnect)

    00100

    up

    Ненумерованный запрос передачи (unnumbered poll)

    00110

    ua

    Ненумерованный отклик (unnumbered acknowledgment)

    00111

    test

    Тестирование системы передачи данных

    10000

    SIM/RIM

    Установка режима асинхронного отклика (set initialization mode / request initialization mode)

    10001

    FRMR

    Отклонение кадра (frame reject)

    11000

    SARM/DM

    Установка режима асинхронного отклика (set asynchronous acknowledgment regime mode / disconnect mode)

    11001

    RSET

    Сброс (возврат в исходное состояние)

    11010

    SARME

    SARM с расширенной нумерацией

    11011

    SNRME

    snrm с расширенной нумерацией

    11100

    SAMB

    Установка асинхронного сбалансированного режима

    11101

    XID

    Идентификация коммутатора (exchange identifier)

    11110

    SABME

    SABM с расширенной нумерацией

    После благополучного получения пакета ua локальной станцией соединение считается установленным и может начинаться обмен данными. Информацию несут кадры типа I, а также FRMR и UI-кадры типа U. В кадре ответа FRMR должно присутствовать информационное поле, содержащее обоснование присылки такого ответа. Структура этого поля для обычного и расширенного (внизу) форматов показана на рис. 4.3.1.6.

    Рис. 4.3.1.6. Структура информационного поля для FRMR-кадров

    Биты A, B, C и D определяют причину, по который кадр не был доставлен. Если бит равен 1, то это указывает на соответствующую причины недоставки. Бит A указывает на неверное значение N(R). Бит B =1 говорит о слишком большой длине информационного поля. Бит C - указывает на то, что поле управления неопределенно из-за наличия в кадре недопустимой для данной команды или отклика информационного поля, а D=1 означает, что поле управления принятого кадра не определено или же неприемлемо. V(R) и V(S) текущие значения переменных приема и передачи, соответственно. C/R (Command/Response) =1 означает, что ошибочное сообщение является откликом (=0 - командой). Большинство U-кадров интерпретируются как команды или отклики в зависимости от контекста и того, кто их послал. В некоторых случаях для разделения откликов и команд используется поле адреса. Одним из наиболее известных протоколов сетевого уровня, использующих HDLC, является X.25.

    Previous: 4.3 Региональные сети    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.2 Протоколы сетей X.25


    previous up down next index index
    Previous: 4.3.1 Эталонная сетевая модель ISO    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.3 Интегрированные сети ISDN

    4.3.2 Протоколы сетей X.25
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В 1976 году был принят стандарт X.25, который стал основой всемирной системы PSPDN (Packet-Switched Public Data Networks), базирующейся на 7-уровневой модели ISO OSI. Стандарт X.25 был усовершенствован в 1984. X.25 - протокол (ISO 8208:1989; RFC-887, -1381, -1382, -1461, -1598, -1613), который определяет синхронный интерфейс между терминальным оборудованием (DTE - Data Terminal Equipment) и оборудованием передачи данных (DCE - Data Communication Equipment) для терминалов, работающих в пакетном режиме. По существу это протокол связи оборудования с сетью. Главный недостаток протокола X.25 - большие задержки отклика (типовое значение 0.6 сек). Терминалом может служить ЭВМ или любая другая система, удовлетворяющая требованиям X.25. Соединение DTE - DTE осуществляется через DCE. В протоколе X.25 DCE и DTE используют статистическое мультиплексирование с делением по времени. Одновременно могут реализовываться несколько обменных процессов. Схема взаимодействия DTE и DCE выглядит как:

    DTE - <логический канал> - DCE <виртуальное соединение> - DCE - <логический канал> - DTE

    Асинхронный старт-стопный терминал подключается к сети коммутации пакетов через пакетный адаптер данных ПАД (PAD - packet assemble/disassemble) и отвечает рекомендациям X.3, X.28 и X.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинхронных терминалов. Пакет данных состоит обычно из 128 байтов, которые передаются по адресу, содержащемуся в пакете. Но длина пакета может лежать в пределах 64-4096 байтов. Размер пакета также как и величина окна (число пакетов, принимаемых без подтверждения) определяются на фазе установления канала. Прежде чем пакет будет передан, необходимо установить связь между исходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два вида соединений: коммутируемый виртуальный канал (SVC) и постоянный виртуальный канал (PVC). Предусмотрены две процедуры доступа к каналу:

    • Процедура доступа к каналу (LAP - link access procedure), в основе которой лежат симметричные операции режима асинхронного ответа (ARM - asynchronous response mode) протокола HDLC.
    • Балансная процедура доступа к каналу (LAPB - link access procedure balanced) на основе асинхронного балансного режима (ABM - asynchronous balanced mode) протокола HDLC. Сетевой уровень реализуется с использованием 14 различных типов пакетов.

    Виртуальный канал описывается в общем формате пакета, как "логический канал". Логический канал имеет идентификатор, состоящий из 12 бит. Этот идентификатор обычно состоит из номера группы (4 бита) и номера логического канала (8 бит). В группе может быть до 256 логических каналов (за исключением группы 0, которая может иметь только 255 логических каналов). Возможное число групп - 16, поэтому теоретически возможное число виртуальных каналов для каждого соединения x.25 равно 4095 (16x256-1).

    Постоянный виртуальный канал (PVC - permanent virtual circuit) является аналогом выделенного канала.

    Коммутируемый виртуальный канал (SVC - switched virtual circuit - напоминает традиционный телефонный вызов) реализует обмен данными. Имеются три типа коммутируемых виртуальных каналов, работающие в дуплексном режиме, но отличающиеся направлением устанавливаемых соединений: входящий SVC, двунаправленный SVC и выходящий SVC. Адресат каждого пакета распознается с помощью идентификатора логического канала (LCI) или номера логического канала (LCN).

    SVC используются только на время соединения и становятся доступными для повторного использования после разъединения. Все типы пакетов, за исключением пакетов запроса повторного пуска, содержат идентификатор логического канала. Пакет запрос соединения в SVC является единственным типом пакетов, которые содержат адреса в соответствии с рекомендацией X.121.

    Для установки выходящего соединения через svc ЭВМ выбирает логический канал с наибольшим номером в группе и посылает пакет запрос соединения, содержащий выбранный номер группы канала, адрес получателя (в соответствии с рекомендацией X.121) и в отдельных случаях свой собственный адрес. При установлении входящего соединения центр коммутации пакетов (ЦКП) выбирает свободный логический канал с наименьшим номером в группе каналов порта адресуемой ЭВМ и помещает этот логический номер группы и канала в пакет входящий запрос соединения. После того как соединение через svc установлено, ЭВМ направляют свои пакеты, используя номера своих логических групп/каналов, а ЦПК в сети осуществляет транспортировку пакетов и преобразование номеров логических групп/каналов. Как только установленное по svc логическое соединение разъединяется, номера логических групп/каналов на обоих концах соединения освобождаются и становятся доступными для повторного использования. Соответствие между ЦКП/портом, выделенным для терминального оборудования, адресами (согласно рекомендациям x.121) и номерами логических каналов известно в сети только ЦКП.

    Выбор ЭВМ свободного канала с наибольшим номером при каждом выходящем соединении и выбор в ЦКП свободного канала с наименьшим номером для каждого входящего позволяют избежать конфликтов. С этой же целью используются две логические группы: одна только для входящих соединений, а другая только для выходящих. Перед подключением к сети пользователь должен определить, сколько pvc и svc требуется на каждую точку физического интерфейса x.25. Асинхронные терминалы подключаются к сети коммутации пакетов через встроенные или удаленные пакетные адаптеры данных (ПАД).

    Встроенный ПАД обычно располагается вместе с ЦКП в его стойке. В этом случае каждый асинхронный терминал, расположенный в удаленном месте, подключается к своему встроенному ПАД через отдельный канал связи (протокол Х.28). В альтернативном случае удаленный ПАД (небольшое отдельное устройство) может быть расположен в удаленном месте и подключается к своему ЦКП через канал связи (X.25). С помощью удаленного ПАД к ЦКП подключается 8-16 асинхронных терминалов.

    Встроенный ПАД может быть совместно использован несколькими терминалами, расположенными в различных местах, в то время как удаленный ПАД обслуживает терминалы, расположенные обычно в одном месте. Существует еще один аспект размещения ПАД, связанный с помехами в каналах связи и использованием протоколов. Удаленный ПАД подключается к ЦКП на канальном уровне в соответствии с рекомендацией X.25. В качестве протокола канала данных в рекомендации X.25 реализуется подмножество HDLC, обеспечивающее автоматическую повторную передачу данных в случае их искажения при возникновении помех в линии. Асинхронный терминал использует для диалога с групповым ПАД процедуры, описанные в рекомендации X.28, в которых не предусмотрена возможность повторной передачи в случае ошибки. Поэтому канал между синхронным терминалом и групповым ПАД не защищен от возникновения ошибок данных в результате линейных помех. Процедуры ПАД определены в рекомендациях МККТТ (см. приложение 10.1).

    • Рекомендация X.3: "Пакетный адаптер данных (ПАД) в сети передачи данных общего пользования".
    • Рекомендация X.28: "Интерфейс между терминальным оборудованием и оборудованием передачи данных (DCE) для старт-стопного оконечного оборудования, осуществляющего доступ к пакетному адаптеру данных в сетях общего пользования".
    • Рекомендация X.29: "Процедуры обмена управляющей информацией между терминальным оборудованием пакетного типа и пакетным адаптером (ПАД)".

    Основные функции ПАД соответствуют рекомендациям X.3:

    • сборка символов (полученных от асинхронных терминалов) в пакеты;
    • разборка полей данных в пакетах и вывод данных на асинхронные терминалы;
    • управление процедурами установления виртуального соединения и разъединения, сброса и прерывания;
    • обеспечение механизма продвижения пакетов при наличии соответствующих условий, таких как заполнение пакета, получение символа (сигнала) на передачу пакета, истечение времени ожидания;
    • передача символов, включающих стартстопные сигналы и биты проверки на четность, по требованию подключенного асинхронного терминала;
    • обнаружение сигнала разрыв соединения от асинхронного терминала;
    • редактирование последовательностей команд ПАД.

    В постоянном запоминающем устройстве ПАД хранятся параметры. Эти параметры могут быть установлены либо асинхронным терминалом, подключенным к ПАД, либо любой ЭВМ в сети, которая удовлетворяет условиям рекомендации X.29. В рекомендации X.29 МККТТ эти параметры названы управляющей информацией. Поэтому необходимо квалифицировать данные, проходящие между ЭВМ и ПАД, либо как управляющую информацию (сообщения ПАД), либо как собственно данные от асинхронного терминала.

    Сеть X.25 предоставляет пользователю старт-стопного терминала средства, позволяющие выбрать параметры ПАД с заранее определенными значениями. Пользователь посылает в ПАД команду выбора профайла, которая включает идентификатор профайла. Этим определяется один из нескольких стандартных профайлов, хранящихся в ПАД.

    Идентификатор профайла и параметр 11 ПАД (скорость терминала) включаются в "поле данных пользователя" пакетов типа запрос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это поле, извлекая из него информацию о терминале, пославшем запрос.

    Пакетный терминал является интеллектуальным устройством (например, ЭВМ, или внешним ПАД'ом), которое обеспечивает синхронный обмен с сетью на скорости 2400, 4800, 9600 бит/c или 48 Кбит/с, используя трехуровневый протокол X.25. Возможная схема подключения терминальных устройств к сети X.25 показана на рис. 4.3.2.1.

    Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого терминального оборудования возможно как к встроенному, так и удаленному ПАД (протокол X.28), а также непосредственно к ЦКП (протокол X.25, X.29). Связи с удаленными объектами осуществляются через соответствующие модемы (на рисунке не показаны).

    Для международного соединения необходимо указать код страны из трех цифр, а также набрать одну цифру 9 перед сетевым адресом пользователя. Таким образом, всего требуется не более 15 цифровых символов. Для установления коммутируемого соединения оператор вначале вручную набирает номер ПАД и ждет подтверждения соединения с телефонным узлом общего пользования. Как только соединение установлено, оператор набирает 12-символьный код "сетевого идентификатора пользователя". ПАД обеспечивает операцию эхо-контроля, которая позволяет оператору терминала визуально проверять данные, посылаемые в ПАД. Наиболее серьезным недостатком встроенного ПАД является отсутствие какого-либо линейного протокола, предусматривающего устранение ошибок в данных, посылаемых от ПАД к терминалу. В удаленном ПАД предусмотрена процедура восстановления ошибочных данных, однако он подключается к сети как "пакетный терминал".

    Рис. 4.3.2.1. Возможная топология сети X.25

    Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4 - идентификатор сети передачи данных (3 - страна, 4 - сеть); 5-12 - национальный номер (5-7 местная область, 8-12 - местный номер). Международная система адресации для систем передачи данных общего пользователя описана в рекомендациях X.121 международного комитета по телефонии и телеграфии. Каждое подключение к сети коммутации пакетов имеет свой национальный номер. Протокол X.25 не определяет технику маршрутизации пакетов по сети. Для целей управления в сетях X.25 используется протокол snmp и база данных MIB (как и в сетях Интернет). Три базовых уровня протокола X.25 и схема потоков информации отображены на рис. 4.3.2.2.

    Для подключения по виртуальному каналу ЭВМ/ПАД посылается пакет (call request), содержащий сетевой адрес пользователя. После подтверждения соединения и передачи/приема данных виртуальное соединение может быть разорвано путем передачи пакета (clear request), инициатором в этом случае выступает удаленная ЭВМ. При невозможности установить связь clear request посылается сетью. Такой пакет содержит два информационных октета. Первый содержит код причины, второй является диагностическим кодом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки.

    Таблица 4.3.2.1. Коды причины ошибки

    Код причины

    Причина

    0x0

    Удаленный сброс (remote cleared)

    0x1

    Адресат занят (number busy)

    0x3

    Нелегальный запрос (invalid facility request)

    0x5

    Перегрузка сети (network congestion)

    0x9

    Нарушен порядок (out of order)

    0x11

    Ошибка при выполнении удаленной процедуры

    0xb

    Доступ блокирован (access barred)

    0xd

    Не доступно, нет в наличии (not obtainable)

    0x21

    Несовместимость у адресата (ошибка при выполнении удаленной процедуры)

    0x23

    Ошибка при выполнении местной процедуры

    0x29

    Сигнал быстрой выборки не воспринят (fast select not accepted)

    Один физический канал связи X.25 может поддерживать несколько коммутируемых виртуальных каналов. Постоянный виртуальный канал подобен выделенной линии - обмен возможен в любой момент. X.25 определяет первые три уровня соединения открытых систем (см. рис. 4.3.2.2).

    1. - физический x.21 (X.21bis)
    2. - канальный (HDLC - high data link communication - протокол высокого уровня управления каналом). Этот уровень и последующие реализуются программным образом.
    3. - сетевой (пакетный)

    X.21 - универсальный интерфейс между оконечным оборудованием (DTE) и аппаратурой передачи данных (DCE) для синхронного режима работы в сетях общего пользования. X.21bis - тоже, но для модемов, удовлетворяющих рекомендациям серии V. Для канального уровня используется подмножество протокола HDLC (являющегося развитием стандарта SDLC IBM), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.

    Рис. 4.3.2.2. Три уровня X.25

    Формат кадра для протокола HDLC показан на рис. 4.3.2.3 (байты передаются, начиная с младшего бита):

    Рис. 4.3.2.3. Формат кадра X.25

    Открывающий и закрывающий флаги для бит-ориентированного формата несут в себе код 0x7e. Когда не передается никакой информации, по каналу пересылается непрерывный поток флагов 01111110. Посылка более 6 единиц подряд воспринимается как флаг абортирования связи. Если необходимо передать информационную последовательность 01111110, после первых пяти единиц вводится дополнительный нуль, приемник восстанавливает истинную информацию, удаляя эти лишние нули. В случае байт-ориентированных кадров открывающий и завершающий флаги имеют по два байта [DLE (Символы кодов стандарта ISO 646-1973 (МТК-5, ГОСТ 13059-74). Здесь и далее используется русская терминология в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ETX, соответственно, для информационного кадра и DLE, STX и DLE, ETX для управляющего]. Адрес в пакете X.25 занимает всего один байт, что определяет предельное число терминальных устройств, подключаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый заголовок, содержащий байт адреса и байт типа. Для нумерации кадров на уровне 2 используется 3 бита. При работе со скользящим окном откликов это позволяет иметь до 7 кадров в очереди. При использовании спутниковых каналов с большими задержками можно переходить в режим расширенной нумерации (7 бит), где длина очереди может достигать 128. Если удаленный партнер не способен работать в режиме расширенной нумерации, он отклонит запрос соединения. При работе в режиме расширенной нумерации возможно применение 3-байтовых заголовков вместо двухбайтовых.

    Значения поля идентификатора общего формата (GFI - general format identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля (Q) используется в информационных пакетах как индикатор уровня передаваемых данных. Групповой номер логического канала и номер логического канала присваиваются по соглашению с администрацией сети во время постановки на обслуживание. Поля групповой номер логического канала и номер логического канала присутствуют во всех пакетах кроме пакетов регистрации и повторного пуска, где они принимают нулевое значение.

    Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)

    Тип пакета

    Модуль нумерации

    Номера битов

    8

    7

    6

    5

    Установка соединения

    8
    128

    0
    0

    x
    x

    0
    1

    1
    0

    Разрыв соединения, управление потоком, повторный пуск, регистрация, диагностика

    8
    128

    0
    0

    0
    0

    0
    1

    1
    0

    Данные

    8
    128

    x
    x

    x
    x

    0
    1

    1
    0

    Расширение

    -

    0

    0

    1

    1

    x - бит может принимать значения 0 или 1.

    Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3.

    Таблица 4.3.2.3. Значения кодов тип пакета

    Тип пакета

    Октет 3

    Биты

    8 7 6 5 4 3 2 1

    Запрос

    0 0 0 0 1 0 1 1

    Запрос принят

    0 0 0 0 1 1 1 1

    Запрос завершения

    0 0 0 1 0 0 1 1

    Подтверждение завершения

    0 0 0 1 0 1 1 1

    Данные

    x x x x x x x 0

    Прерывание

    0 0 1 0 0 0 1 1

    Подтверждение прерывания

    0 0 1 0 0 1 1 1

    Готовность к приему по модулю 8 (RR)

    x x x 0 0 0 0 1

    Готовность к приему по модулю 128 (RR)

    0 0 0 0 0 0 0 1

    Неготовность к приему по модулю 8 (RNR)

    x x x 0 0 1 0 1

    Неготовность к приему по модулю 128 (RNR)

    0 0 0 0 0 1 0 1

    Запрос повторной установки

    0 0 0 1 1 0 1 1

    Подтверждение повторной установки

    0 0 0 1 1 1 1 1

    Запрос повторного пуска

    1 1 1 1 1 0 1 1

    Подтверждение повторного пуска

    1 1 1 1 1 1 1 1

    Диагностика

    1 1 1 1 0 0 0 1

    Запрос регистрации

    1 1 1 1 0 0 1 1

    Подтверждение регистрации

    1 1 1 1 0 1 1 1

    x - отмечет разряды, которые могут принимать значения 0 или 1.

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

    Рис. 4.3.2.4. Формат кадра запроса на соединение и соединение установлено

    Поле опции содержит целое число октетов, но не более 109, следующее же поле может содержать до 128 байт. Опция типа fast select позволяет поместить до 64 байтов в информационном поле пользователя, во многих случаях этого оказывается достаточно и исключается необходимость переходить в режим пересылки данных.

    Если вызываемое DTE не присылает сообщения вызов принят или запрос завершения (установление связи отвергнуто) за отведенное для этого время, процедура завершается и процессу, инициализировавшему запрос, присылается соответствующий код ошибки. При успешной обработке запроса (прислано сообщение соединение установлено) система переходит в режим обмена данными. DTE может в любой момент инициировать процедуру разрыва связи, послав сообщение запрос завершения. DCE сообщает о завершении соединения путем присылки пакета индикация завершения, на который DTE должно прислать отклик подтверждение завершения. Формат пакетов запроса и подтверждения завершения отображен на рис. 4.3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны, так как они идентичны тому, что представлено на рис. 4.3.2.4.

    Рис. 4.3.2.5. Формат пакетов запроса завершения

    Коды причины завершения связи приведены в таблице 4.3.2.1. Однобайтовое поле диагностический код позволяет уточнить причину. В таблице 4.3.2.4 приведены коды причины повторного пуска. Формат пакетов подтверждения завершения представлен на рис. 4.3.2.6.

    Таблица 4.3.2.4. Коды причин повторного пуска

    Код причины

    Причина повторного пуска

    0x1

    Ошибка локальной процедуры

    0x3

    Перегрузка сети

    0x7

    Сеть работоспособна

    Рис. 4.3.2.6. Формат пакетов подтверждения завершения

    Для инициализации обмена информацией (первичного или повторного), а также для прерывания виртуальной связи и возвращения виртуальных каналов в исходное состояние используются запросы повторного пускаподтверждение повторного пуска). DTE может выдать запрос повторного пуска (к DCE) в любой момент времени, переводя логический канал в исходное состояние. DCE в ответ должно послать сообщение подтверждение повторного пуска. Инициатором повторного пуска может быть и dce, для этого оно посылает сообщение индикация повторного пуска. DTE в результате устанавливает логический канал в исходное состояние и посылает dce сообщение подтверждение повторного пуска. Форматы пакетов, несущих эти сообщения показаны на рис. 4.3.2.6 и 4.3.2.7. Эти пакеты не имеют полей группового номера логического канала и LCN (см. рис. 4.3.2.7 и .8). Процедура повторной установки во многом аналогична повторному пуску и используются всякий раз при выявлении сбоя, чтобы вернуть виртуальную связь или постоянный виртуальный канал в исходное состояние.

    Рис. 4.3.2.7. Формат пакета запроса повторного пуска (слева) и повторной установки

    Таблица 4.3.2.5. Коды причин повторной установки

    Причина повторной установки

    Код причины

    Установка по инициативе dte

    0x0

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

    0x1

    Ошибка при исполнении удаленной процедуры

    0x3

    Ошибка при выполнении локальной процедуры

    0x5

    Перегрузка сети

    0x7

    Удаленное DTE работоспособно (постоянный виртуальный канал)

    0x9

    Сеть работоспособна (постоянный виртуальный канал)

    0xf

    Несовместимость партнеров

    0x11

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

    Инициатором посылки запроса повторной установки может быть dte и dce. Коды причин повторной установки представлены в таблице 4.3.2.5.

    Рис. 4.3.2.8. Формат пакета подтверждения повторного пуска (слева) и повторной установки (справа)

    Пакеты данных передаются по постоянным виртуальным каналам или через виртуальные соединения после их создания. Пакеты данных распознаются по нулевому младшему биту (бит с номером 1) в третьем октете. Остальные биты этого октета используются для управления. Форматы пакетов данных показаны на рис. 4.3.2.9.

    Информационное поле начинается с четвертого байта (при расширенной нумерации с пятого) и может иметь длину 16-4096, хотя в рекомендациях стандарта x.25 оговорена величина 128 октетов. Если принимающая сторона не способна принять пакет данной длины, связь должна быть переустановлена, а стороне-инициатору соединения послано сообщение об ошибке. Каждому пакету данные присваивается порядковый номер N(S), значение которого при установлении соединения равно нулю.

    Рис. 4.3.2.9. Форматы пакетов данные. Слева - по модулю 8, справа - по модулю 128

    Q -бит определяет тип кадра-пакета, Q=1 - управляющий пакет для PAD, Q=0 - информационный пакет. Бит D используется для запроса специального отклика на пакет со стороны удаленного конца виртуального канала. Бит M указывает на то, что данный пакет является частью более крупного пакета, который должен быть воссоздан позднее.

    Индекс S (send) соответствует отправке, а индекс R - приему (receive). Если используется нумерация пакетов по модулю 8, N(S) занимает биты 2-4 включительно, при нумерации по модулю 128 для этого отводятся биты 2-8. Нумерация пакетов позволяет выявить потерю пакетов или изменение порядка их доставки. N(R) является номером пакета с принимающей стороны. Бит подтверждения доставки D (идентификатор формата) служит для указания необходимости сообщения о доставке данных получателем. Если D=1, то DTE обязано подтвердить доставку. Обязательность процедуры подтверждения определяется уже на фазе установления связи (сообщение запрос на установление связи принят). Если какой-либо узел по пути пересылки пакета не поддерживает процедуру подтверждения доставки, он пошлет сообщение запрос завершения (причина - несовместимость у адресата) и связь должна быть сформирована заново с учетом необходимости подтверждения во всех узлах-участниках. Размер поля данные в пакете может быть разным для разных узлов, участвующих в обмене. По этой причине число полученных пакетов может оказаться больше (или меньше) числа посланных. Для таких случаев предусмотрен флаг m (дополнительные данные). Возможность фрагментации и последующей сборки пакетов определяется управляющими битами M и D (см. таблицу 4.3.2.6).

    Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с помощью битов M и D

    Бит m

    Бит d

    Выполнение объединения с последующим пакетом (реализуется сетью)

    0

    0

    Нет

    0

    1

    Нет

    1

    0

    Да

    1

    1

    Нет

    Таким образом, при фрагментации исходного сообщения все пакеты кроме последнего должны иметь бит m=1. Нумерация пакетов по модулю 8 означает, что им последовательно присваиваются номера 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по модулю 128 - 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации пакетов определяет также размер "окна", то есть число пакетов, которые могут быть переданы, не дожидаюсь подтверждения получения. По умолчанию размер окна равен 2, другие значения могут быть согласованы на фазе установления соединения. Принцип использования окон при передаче пакетов более подробно описан в разделе "3.6.2 Протокол TCP".

    Для управления процессом передачи данных используются сообщения "готов к приему" и "не готов к приему". Форматы этих пакетов показаны на рис. 4.3.2.10 и 4.3.2.11.

    Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 8.

    Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 128.

    Код N(R) на входе DCE должен лежать в пределах между N(R) последнего принятого пакета и N(S) следующего пакета, который должен быть послан из DCE к DTE. При невыполнении этого условия связь будет переустановлена и передача повторена. Пакеты готовность к приему используются для сообщения о готовности принять пакеты, с номерами, начиная с номера N(R), приведенного в пакете. Пакеты неготовность к приему служат для того, чтобы сообщить о временной неспособности принять данные. При поступлении этого сообщения отправитель должен прервать передачу до получения сообщения готовность к приему. DTE может передавать данные удаленному DTE, не следуя правилам управления потоком данных. Для реализации такой возможности предусмотрена операция прерывания. Эта операция не влияет на передачу данных и управление. Формат пакета прерывание и подтверждение прерывания показан на рис. 4.3.2.12.

    Рис. 4.3.2.12. Формат пакетов прерывание и подтверждение прерывания

    Идентификатор формата равен 0x1 для нумерации по модулю 8 и 0x2 при нумерации по модулю 128. Передав сообщение прерывание, DTE должно ожидать получение пакета подтверждение прерывания. Максимальный размер поля данные пользователя в пакете прерывание не должен превышать 32 байт.

    Иногда в сетях для сообщения об ошибке используется пакет "диагностика". Этот пакет посылается DCE, адресуется DTE и несет информацию о неустранимых на уровне пакетов ошибках. Пакет диагностика посылается лишь один раз сразу после выявления ошибки. Подтверждения его получения не требуется. Формат пакета показан на рис. 4.3.2.13.

    Рис. 4.3.2.13. Формат пакета диагностика

    Поле код диагностики несет в себе информацию об ошибке, вызвавшей посылку этого пакета. Если же пакет диагностика передается в качестве отклика на пакет с ошибками от DTE, то поле уточнение диагностики содержит первые три байта пакета DTE.

    Современные сети создаются ради доступа к определенным услугам. В протоколе X.25 предусмотрена процедура, которая позволяет получить текущие значения параметров услуг (опций) и модифицировать их. Эта процедура называется регистрацией и не является обязательной. Форматы пакетов запроса регистрации и подтверждения регистрации показаны на рис. 4.3.2.14 и 4.3.2.15. Максимальный размер поля регистрация составляет 109 байт. Инициатором регистрации всегда является dte, которое передает запрос регистрации. В качестве отклика dce посылает пакет подтверждение регистрации, в котором содержатся информация о параметрах доступных услуг. Для выявления доступных услуг может быть послан запрос регистрации, не содержащий списка запрашиваемых услуг.

    Рис. 4.3.2.14. Формат пакетов запрос регистрации

    Рис. 4.3.2.15. Формат пакетов подтверждение регистрации

    Получив список доступных услуг из сообщения подтверждение регистрации, может поменять параметры некоторых из них. Если значение какого-либо параметра услуги (опции) не разрешено, DCE должно сообщить разрешенное значение параметра и максимальное и или минимальное разрешенное значение (в зависимости от того больше или меньше допустимого оказалось значение запрошенного параметра).

    Неисправность сети может привести к тому, что та или иная согласованная ранее услуга станет недоступной. В этом случае DCE должно инициировать процедуру повторного пуска, чтобы уведомить DTE о случившихся изменениях.

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

    Повторная передача пакетов согласуется на определенное время и может использоваться во всех логических каналах DTE-DCE. DTE запрашивает повторную передачу одного или нескольких пакетов данные путем посылки сообщения отказ reject), которое определяет логический канал и порядковый номер пакета N(R). Получив пакет отказ DCE, DTE начинает повторную передачу пакетов. Формат пакетов отказ для случаев нумерации по модулю 8 и 128 показан на рис. 4.3.2.16.

    Рис. 4.3.2.16. Форматы пакетов типа отказ для нумерации по модулю 8 (слева) и 128

    Программное обеспечение принимающей и передающей сторон должно иметь переменные состояния V(R) и V(S), содержащие, соответственно, номера пакетов, которые предстоит получить и послать (см. описание процедуры HDLC). После посылки очередного пакета с N(S) значение V(S) увеличивается на 1. Принимающая сторона сравнивает V(R) с N(S) полученного пакета, при совпадении укладывает N(S) в поле N(R) пакета-отклика и инкрементирует V(R). Отправитель при получении пакета проверяет равенство переменной V(S) и кода поля N(R) в пакете-отклике. Если при получении пакета выясняется, что V(R) не равно N(S), V(R) не инкрементируется, а принимающая сторона отправляет отклик с N(R)=V(R). Отправитель, получив этот отклик и обнаружив, что V(S) не равно N(R), узнает о происшедшем сбое. Номер логического канала (LCN) служит для того, чтобы определить соответствие межу DTE и местным DCE. LCN вместе с полем группового номера логического канала занимают 12 бит, что позволяет иметь до 4095 логических каналов (LCN=0 зарезервировано для использования DCE).

    4 бита первого байта управляющего пакета содержат в себе код типа сообщения (таблица 4.3.2.7):

    Таблица 4.3.2.7 Коды типов сообщений

    Код типа сообщения

    Команда PAD

    Отправитель

    0001

    Команда разъединения

    ЭВМ

    0010

    Установление параметров

    ЭВМ

    0011

    Индикация разъединения

    ЭВМ или PAD

    0100

    Чтение параметров

    ЭВМ

    0101

    Ошибка

    PAD

    0110

    Установка и чтение параметров

    ЭВМ

    В поле управляющего сообщения PAD может быть включено любое число параметров, которое допускает максимальный размер пакета. Каждый параметр имеет свой код-номер, за которым в пакете следует значение параметра (таблица 4.3.2.8):

    Таблица 4.3.2.8. Коды параметров PAD

    Код параметра

    Описание

    1

    Обращение к ПАД с использованием управляющего символа

    2

    Эхо-контроль

    3

    Выбор сигнала посылки пакета

    4

    Выбор продолжительности ожидания для таймера

    5

    Управление вспомогательным устройством

    6

    Подавление управляющих сигналов ПАД

    7

    Выбор действий ПАД при получении сигнала разрыва

    8

    Прерывание вывода

    9

    Кодовая последовательность после сигнала "возврат каретки"

    10

    Перенос строки, длина которой ограничена размерами экрана дисплея

    11

    Скорость работы старт-стопного терминала

    12

    Управление потоком ПАД

    13

    Вставка символа "перевод строки" после символа "возврат каретки"

    14

    Заполнение после сигнала "перевод строки"

    15

    Редактирование

    16

    Стирание символа

    17

    Стирание строки

    18

    Вывод строки на экран дисплея

    19

    Редактирование сигналов управления ПАД

    20

    Маскирование эхо-контроля

    21

    Обработка символов контроля на четность

    22

    Ожидание страницы

    При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS. Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей.

    Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25

    IP

    X.25

    IP

    X.25

    000

    00

    001

    01

    010

    10

    011 - 111

    11

    Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25.

    Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей.

    Previous: 4.3.1 Эталонная сетевая модель ISO    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.3 Интегрированные сети ISDN


    previous up down next index index
    Previous: 4.3.2 Протоколы сетей X.25    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.4 Протокол Frame Relay

    4.3.3 Интегрированные сети ISDN
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Название ISDN (integrated system digital network - интегрированные цифровые сети) было предложено группой XI CCITT в 1971 году (cм. П. Боккер, ISDN. Цифровая сеть с интеграцией служб. Понятия, методы, системы. "Радио и связь", М. 1991). Основное назначение ISDN - передача 64-кбит/с по 4-килогерцной проводной линии и обеспечение интегрированных телекоммуникационных услуг (телефон, факс, данные и пр.). Использование для этой цели телефонных проводов имеет два преимущества: они уже существуют и могут использоваться для подачи питания на терминальное оборудование. Выбор 64 Кбит/c стандарта определен простыми соображениями. При 4-килогерцной полосе, согласно теореме Найквиста-Котельникова, частота стробирований должна быть не ниже 8 кГц. Минимальное число двоичных разрядов для представления результатов стробирования голосового сигнала при условии логарифмического преобразования равна 8. Таким образом, в результате перемножения этих чисел и получается значение полосы B-канала ISDN. Базовая конфигурация каналов имеет вид 2*B + D = 2*64 +16 = 144 кбит/с. Помимо B-каналов и вспомогательного D-канала isdn может предложить и другие каналы с большей пропускной способностью, канал Н0 с полосой 384 Кбит/с, Н11 - 1536 и Н12 - 1920 Кбит/c (реальные скорости цифрового потока). Для первичных каналов (1544 и 2048 Кбит/с) полоса D-канала может составлять 64 Кбит/с.

    Ожидается, что к 2000 году в США будет 10000000 пользователей ISDN. Число же телефонных аппаратов в мире приближается к миллиарду. Существует около 10 разновидностей протоколов ISDN (national ISDN-1 (США); at&t custom; euro-ISDN (Net3) и т.д.

    ISDN предполагает, что по телекоммуникационным каналам передаются цифровые коды, следовательно аналоговые сигналы в случае телефона или факса должны быть преобразованы соответствующим образом, прежде чем их можно будет передать. При передаче цифровых сигналов используется кодово-импульсная модуляция (cм. раздел "Преобразование, кодирование и передача информации"), впервые примененная во время второй мировой войны. Широкое внедрение этого метода передачи относится к началу 60-х годов.

    Чтобы обеспечить пропускную способность 64 Кбит/с по имеющимся телефонным проводам, не нарушая теоремы Шеннона, надо ставить ретрансляторы на расстоянии 2 км друг от друга (ведь ослабление сигнала в стандартном кабеле составляет около 15дБ/км). Последние достижения в телекоммуникационных технологиях существенно ослабили это ограничение.). Унификация скоростей передачи данных в ISDN способствует уменьшению объема оборудования, так как исключает необходимость межсетевых интерфейсов, согласующих быстродействие отдельных частей сети. Одной из наиболее массовых приложений ISDN является цифровая телефония. Человеческий голос можно удовлетворительно закодировать, используя лишь 6 бит, но вариации уровня входного сигнала приводит к тому, что нужно не менее 8 бит (с учетом логарифмической характеристики аналого-цифрового преобразователя - АЦП). Значения кодов, полученных в результате последовательных преобразований звука человеческой речи, сильно коррелированны, а это открывает дополнительные возможности для сжатия информации.

    Сети ISDN дали толчок развитию сетевой технологии. На очереди интеграция Интернет с кабельным телевидением, а там, глядишь, появятся квартирные сети, объединяющие телевизор, ЭВМ, бытовую технику и телефон. Это неудивительно, когда цена хорошего телевизора почти сравнялась с ценой персональной ЭВМ, а многие бытовые устройства имеют встроенные процессоры. Здесь должно быть решено несколько проблем. С одной стороны телевизионные кабели имеют полосу пропускания достаточную для передачи как аналогового (заведомо более 10 каналов), так и цифрового телевидения. Проблема возникает при совмещении передачи телевизионного сигнала и цифрового (или PCM) канала Интернет (кабельные модемы пока достаточно дороги). Современные телевизионные системы обеспечивают порядка 50 каналов одновременно, что накладывает весьма жесткие требования на кабельную разводку между локальным распределительным узлом и оконечными пользователями. Распределительные узлы сегодня объединяются с помощью ATM-каналов (~150 Мбит/с, широкополосный ISDN), что уже сегодня недостаточно. По мере удешевления можно ожидать, что в ближайшем будущем в квартиры конечных пользователей будет осуществлен ввод оптоволоконных кабелей, что решит проблему радикально (не нужен не только телевизионный, но и телефонный кабель). Попутно это решит проблему и видеотелефона. На очереди разработка новых стандартов, которые позволят осуществить такую интеграцию.

    Так как первоначально ISDN создавалась для передачи голоса и изображения (факс), начнем именно с этих приложений. Для факсов сети ISDN особенно привлекательны, так как может обеспечить высокое разрешение (до 16 линий/мм и лучше) при разумном времени передачи.

    Для иллюстрации взаимодействия различных частей ISDN рассмотрим рис. 4.3.3.1.

    4.3.3.1 Традиционная схема сети ISDN

    Network termination 1 (NT-1) представляет собой прибор, который преобразует 2-проводную ISDN-линию (от телефонной компании), называемую u-интерфейсом, в 8-проводный S/T-интерфейс. Как правило, к точке Т может быть подключено только одно оконечное устройство. NT2 же предназначено для подключения большого числа разнотипного оборудования (функции NT1 и NT2 могут быть совмещены в одном приборе). Допускается объединение интерфейсов NT2 и TA; возможна работа нескольких NT1 с одним NT2. Интерфейс NT2 может обеспечивать внутриофисный трафик, образуя шину, к которой может подключаться несколько терминалов. Терминальное оборудование (TE) в режиме точка-точка может быть подключено к системе кабелем длиной до 1 км, реальным ограничением служит ослабление в 6 дБ на частоте 96 кГц. В режиме точка-мультиточка (до 8 терминалов) подсоединение производится параллельно, но длина шины в этом случае не должна превышать 200 м (по временным ограничениям). Терминалы, чтобы не вносить искажений, должны иметь входное сопротивление не ниже 2500 Ом. Шина согласуется 100 омным сопротивлением, как со стороны NT1, так с противоположного удаленного конца (это справедливо для принимающих и передающих пар проводов). Оборудование, следующее рекомендациям ISDN, может подключаться в точках S и T. Схемы кабелей, объединяющих интерфейсы ISDN с оконечным оборудованием, показаны на рис. 4.3.3.2.

    Рис. 4.3.3.2. Кабели и разъемы в каналах ISDN

    Точки s и t обеспечивают доступ к канальным услугам ISDN. В точке R (на рис. 4.3.3.2 TA - терминальный адаптер), в зависимости от типа терминального адаптера, доступны некоторые другие стандартные CCITT услуги (X.21 или X.25, V.35, RS-232 или V.24). Входы TE1 и TE2 предназначены для удаленных телекоммуникационных услуг. Все виды услуг могут быть разделены на три группы по форме доступа к 64кбит/с:

    1. Услуги, для которых меняется лишь скорость исполнения (например, файловый обмен или электронная почта).
    2. Принципиально новые услуги, которые недоступны при низких скоростях обмена, например, факсимильная передача со скоростью 3-4 секунды на страницу (против 20-30 сек при низких скоростях); видеотекст (напр., Prestel в Англии, Minitel во Франции или Bildschirmtext в Германии).
    3. Услуги, абсолютно невозможные при скоростях ниже 64кб/с. Например, видеотелефон или высококачественная передача звука (G.722; ADPCM - adaptive differential pulse code modulation). Телефония часто использует каналы со скоростью передачи 32кбит/с (G.721). Полоса звукового сигнала равна 50 Гц - 20 кГц.

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

    Рис. 4.3.3.3 Эталонная конфигурация системы передачи и приема сигналов, а также подачи питания на терминальное оборудование

    (*) Относится к полярности кадровых сигналов. (**) относится к полярности питающего напряжения. Используется напряжение питания V= 40 v, которое (если требуется для питания управляющей электроники) преобразуется в 5 В.

    Логика взаимодействия различных частей сети isdn показана на рис. 4.3.3.4.

    Рис. 4.3.3.4 Взаимодействие основных протоколов ISDN

    Процессом передачи информации между узлами управляет сигнальная система общего канала (CCS - common channel signaling system). В ISDN используется 7-я сигнальная система CCITT (рис. 4.3.1.1). Ее уровни сходны, но не идентичны OSI. На нижних уровнях используется MTP (message transfer part - система передачи сообщений), задачей которой является надежная пересылка сигнальных пакетов по сети. Пользовательские (прикладные) сообщения иерархически расположены над MTP, которая имеет три уровня.

    Терминальное оборудование подключается к NT через трансформатор (см. рис. 4.3.3.5). На входе трансиверов используются схемы защиты от переходных процессов в линиях связи.

    Рис. 4.3.3.5 Терминальный ISDN-интерфейс

    Нормальная амплитуда сигнала составляет 750 мВ. Формат кадра первого уровня показан на рис. 3.5.3.6, он содержит 48 бит и имеет длительность 250 мксек. Физическая скорость обмена составляет 192 Кбит/с (~5,2 мксек на бит). Блок-схема терминального ISDN-интерфейса показана на рис. 4.3.3.5. Питание интерфейса осуществляется через 4-проводный выходной кабель. На вход интерфейса подается импульсно-кодовый модулированный сигнал (ИКМ). Интерфейс обеспечивает доступ к B- и D-каналам. Номинальное смещение в начале кадра в случае обмена терминал-сеть, как показано на рис. 4.3.3.6, составляет 2 бита. В некоторых случаях оно может оказаться больше из-за задержек в кабеле. Кадр включает в себя несколько l-битов, которые служат для балансировки цуга по постоянному току. Для направления NT -> TE (связь сетевого оборудования с терминальным) первыми битами кадра являются F/L-пары (см. начало и конец диаграмм; временная ось направлена слева направо), нарушающие AMI-правила (чередование полярности сигнала при передаче логической единицы). Раз чередование нарушено, до завершения кадра должно присутствовать еще одно такое нарушение. Бит FA реализует это второе нарушение чередования полярности. A-бит используется в процедуре активации для того, чтобы сообщить терминалу о том, что система синхронизована. Активация может проводиться по инициативе терминала или сетевого оборудования, а деактивация может быть выполнена только сетью. Помимо B1, B2 (байты выделены стрелками) и D-каналов формируются также виртуальные E- и A-каналы. E-канал служит для передачи эхо от NT1 к TE в D-канале. Существует 10-битовое смещение (задержка) между D-битом, посылаемым терминалом, и E-битом эхо (отмечено стрелкой на рис. 4.3.3.6). M-бит используется для выделения мультифреймов (эта услуга недоступна в Европе). M-бит идентифицирует некоторые FA-биты, которые могут быть изъяты для того, чтобы сформировать канал управления (например, при проведении видеоконференций). S-бит является резервным. Назначения различных вспомогательных каналов собраны в таблице А.

    Таблица А

    A

    4-килогерцный аналоговый телефонный канал

    B

    Цифровой ИКМ-канал для голоса и данных с полосой 64 кбит/c

    C

    Цифровой канал с полосой 8 или 16 кбит/c

    D

    Цифровой канал для внедиапазонного управления с полосой 16 кбит/c

    E

    Цифровой канал isdn для внутреннего управления с полосой 64 кбит/c

    H

    Цифровой канал с полосой 384, 1536 или 1920 кбит/c

    Следует обратить внимание на то, что базовый ISDN-канал содержит два В-канала по 64 кбит/c и один D-канал с 16 кбит/c. Первичный же isdn-канал содержит 24 или 30 стандартных В-каналов и один D-канал с полосой 64 кбит/c.

    На первом уровне протокола разрешаются конфликты доступа терминалов к D-каналу. Активация и деактивация осуществляется сигналом <info>. info=0 означает отсутствие сигнала в линии. info=1 передает запрос активации от терминала к NT. info=2 передается от NT к TE с целью запроса активации или указывает, что NT активировано вследствие появления info=1.

    info=3 и info=4 представляют собой кадры, содержащие оперативную информацию, передаваемую из TE и NT, соответственно. nt активирует местную передающую систему, которая информирует коммутатор о начале работы пользователя. NT1 в ответ передает терминалу info=2, которое служит для синхронизации. TE откликаются, посылая пакетом info=3, который содержит оперативную информацию. Все терминалы активируются одновременно.

    Второй уровень решает проблему надежной передачи сообщений по схеме точка-точка. К каждому сообщению добавляется 16 контрольных чисел, включающих в себя идентификатор сообщения. Этот уровень описывает HDLC-процедуры (high level data link communication), которые обычно называются процедурами доступа для D-канала (LAP - link access procedure). LAP D базировался первоначально на рекомендациях X.25 слоя 2, но в настоящее время процедуры LAP D функционально обогатились (разрешено много LAP для одного и того же физического соединения, что позволяет 8-ми терминалам использовать один D-канал). Уровень 2 должен передать уровню 3 сообщения, лишенные ошибок. На уровне 2 решается проблема повторной передачи пакетов в случае их потери или доставки с ошибкой. LAP D базируется на LAP B рекомендаций X.25 для уровня 2. Кадры на уровне 2 представляют собой последовательности 8-битных элементов. Формат кадра второго уровня показан на рис. 4.3.3.7.

    Рис. 4.3.3.7 Структура кадра для слоя 2

    Стартовый и завершающие флаги передаются так, что к любым 5 единицам подряд добавляется нуль (чтобы избежать имитации сигнатуры в других, в том числе информационных полях). Принимающая сторона эти нули убирает. FSC- вычисляется по методике CRC, описанной в разделе 3.3.1.

    Каждый кадр начинается и завершается одной и той же последовательностью (сигнатура начала/конца кадра). Размер управляющего поля зависит от типа кадра (1 или 2 октета). Информационные элементы присутствуют только в кадрах, содержащих данные 3-го уровня. Формат двухбайтного поля адреса для уровня 2 показан на рис. 4.3.3.7. Адрес имеет лишь локальное значение и известен только участникам процедуры обмена. Формат байтов адреса показан на рис. 4.3.3.8.

    Рис. 4.3.3.8. Адресное поле кадра слоя 2

    ea

    бит расширения адресного поля;

    c/r

    бит поля команда/отклик;

    sapi

    service access point identifier - идентификатор точки доступа, служит для описания характера реализуемого сервиса:

    tei

    terminal endpoint identifier - идентификатор точки подключения терминала.

    SAPI=0 - запрос соединения по схеме коммутации каналов;
    SAPI=16 - переключение пакетов согласно протокола X.25;
    SAPI=63 административные или управленческие функции (опционно). Точка доступа к услугам представляет собой виртуальный интерфейс между слоем 2 и 3 (см. рис. 4.3.3.9).

    Рис. 4.3.3.9 Виртуальный интерфейс между слоями 2 и 3

    Как видно из рисунка в системе могут использоваться и идентичные коды TEI, если они относятся к разным видам услуг (несовпадающими должны быть лишь комбинации SAPI-TEI). Для кодирования сигналов в ISDN используется метод 2B1Q (2 binary into 1 quaternary), что соответствует

    Код

    Уровень

    10

    +2.5 v

    11

    +0.833 v

    01

    -0.833 v

    00

    -2.5 v

    Форматы полей управления для кадров различных модификаций представлены на рисунках 4.3.3.10, 4.3.3.11 и 4.3.3.12.

    Рис. 4.3.3.10 Формат поля управления информационных кадров

    N(S) - номер кадра, посылаемого отправителем (cм. также описание форматов для протокола X.25).
    N(R) - номер кадра, получаемого отправителем;
    P/F - флаг опроса, если кадр является командой, или флаг окончания, в случае отклика.

    Рис. 4.3.5.11 Формат поля управления управляющих кадров

    s - разряды кода управляющей функции;
    x - зарезервировано, должно быть равно нулю.

    Рис. 4.3.3.12 Формат поля управления ненумерованных кадров

    m - бит модификатора функции (см. таблицу 4.3.1.2).

    Мультиплексирование на уровне 2 осуществляется за счет использования отдельного адреса для каждого LAP (link access procedure) в системе. Адрес содержит два байта и определяет приемник командного кадра и адрес передатчика кадра-отклика. SAPI используется для идентификации типа услуг. Если наряду с цифровым телефоном используется обмен данными, то эти два терминала будут подключены к разным типам сервиса и, вообще говоря, к разным сетям. Для каждого вида услуг фиксируется определенный код SAPI. TEI (terminal endpoint identifier) обычно имеет определенное значение для каждого из терминалов пользователя.

    Комбинация SAPI и TEI однозначно описывает LAP (link access procedure) и определяет адрес второго уровня. Так как в системе не может быть двух идентичных TEI, коды TEI распределяются следующим образом:

    0-63

    коды tei, присваиваемые пользователем

    64-126

    коды tei, присваиваемые автоматически (сетью);

    127

    глобальный TEI (для широковещательных целей).

    TEIс кодом в диапазоне 0-63 не нуждаются в диалоге с сетью в процессе установления связи на уровне 2. Но пользователь должен следить сам, чтобы в системе не было двух TEI с идентичными кодами. Терминалы с TEI в диапазоне 64-126 должны договариваться с сетью о TEI при установлении связи на уровне 2. Широковещательный TEI=127 служит для обращения ко всем терминалам, имеющим тот же код SAPI. Прежде чем предложить услуги уровню 3 уровень 2 должен запустить LAP. Это производится путем обмена пакетами между драйвером терминала уровня 2 и соответствующим сетевым драйвером. Предварительно должен быть активирован интерфейс уровня 1. До установления LAP возможен обмен только ненумерованными кадрами.

    Этот процесс включает в себя передачу команды SET asynchronous balanced mode extended(SABME), адресат при этом должен откликнуться посылкой ненумерованного отклика (UA - unnumbered acknowledgment). После установления канала уровень 2 может передавать информацию для уровня 3. Ниже (рис. 4.3.3.13) приведена последовательность обмена кадрами на уровне 2:

    Рис. 4.3.3.13 Последовательность обмена кадрами на уровне 2

    Получение каждого информационного кадра (Iframe) должно быть в конце концов подтверждено (прислан пакет RR; см. таблицу 4.3.3.1). Число Iframe, которое может быть послано, не дожидаясь подтверждения получения (размер окна), может лежать в пределах 1-127. В случае телефонии это число равно 1. Если ресурс окна исчерпан, партнер вынужден задержать отправку очередного пакета до подтверждения получения посланного ранее кадра (RR). Для выявления потери кадров используется таймер. Таймер запускается всякий раз при посылке командного кадра и останавливается при получении подтверждения. Этого таймера достаточно, чтобы проконтролировать доставку, как команды, так и отклика. Если произошел таймаут, нельзя определить, какой из этих двух кадров потерян. Кадр, поврежденный на уровне 1, будет принят с неверной FCS (frame check sequence) и по истечении времени, заданного таймером, будет произведена посылка командного кадра с битом poll=1. Партнер при этом вынужден прислать значение системной переменной, характеризующей ситуацию. По этой переменной можно судить, был ли получен исходный кадр.

    Таким образом, можно идентифицировать факт потери информационного кадра (нужна ретрансмиссия) или отклика на него. После трех ретрансмиссий считается, что канал разорван, и предпринимается попытка его восстановить. FCS получается путем деления последовательности бит, начиная с адреса и кончая (но не включая) началом fcs, на образующий полином x16+x12+x5+1. Практически это делается с использованием сдвигового регистра, который в исходном состоянии устанавливается в единичное состояние. В конечном результате в регистре оказывается код остатка от деления. Дополнение по модулю 1 этого остатка и есть FCS.

    Рис. 4.3.3.14 Схема вычисления контрольной суммы (FCS/CRC)

    Другой возможной ошибкой является получение I-кадра с неверным номером N(S). Это возможно, когда LAP работает при ширине окна более 1. Если потерян кадр с номером N(s)=k, принимающая сторона не должна посылать подтверждение приема кадра k+1. Отклик при этом имеет тип REJ (см. таблица 4.3.3.1) с N(R)=k+1. Это укажет передающей стороне, что все кадры до k получены, но необходимо возобновить передачу, начиная с кадра k. При выявлении ошибки в N(R) связь прерывается, реинициализируются переменные состояния передающей и принимающей сторон, после чего канал восстанавливается, и обмен возобновляется с самого начала.

    Таблица 4.3.3.1. (См. также раздел о протоколе X.25)

     

    Кодировка байтов

    Команда

    Отклик

    8

    7

    6

    5

    4

    3

    2

    1

    Информационные кадры

    iframe

    -

    N(S)

    0

    Iframe

    -

    N(R

    P/td>

    Кадры управления (supervisory)

    RR

    RR

    0

    0

    0

    0

    0

    0

    0

    1

    RR

    RR

    N(R)

    P/F

    RNR

    RNR

    0

    0

    0

    0

    0

    1

    0

    1

    RNR

    RNR

    N(R)

    P/F

    REJ

    REJ

    0

    0

    0

    0

    1

    0

    0

    1

    REJ

    REJ

    N(R)

    P/F

    Ненумерованные кадры

    SABME

    -

    0

    1

    1

    p

    1

    1

    1

    1

    -

    DM

    0

    0

    0

    f

    1

    1

    1

    1

    UI

    -

    0

    0

    0

    p

    0

    0

    1

    1

    DISC

    -

    0

    1

    0

    p

    0

    0

    1

    1

    -

    UA

    0

    1

    1

    f

    0

    0

    1

    1

    -

    FRMR

    1

    0

    0

    f

    0

    1

    1

    1

    P/F

    poll=1 для команды, в противном случае конечный бит для отклика.

    Iframe

    (information frame) Информационный кадр

    DISC

    (disconnect) Отсоединить

    RR

    (receiver ready) Приемник готов

    UA

    (unnumbered acknowledge) Ненумерованное подтверждение

    RNR

    (receiver not ready) Приемник не готов

    FRMR

    (frame reject) Кадр отвергнут

    REJ

    (reject) Отказ

    DM

    (disconnect mode) Режим отключения

    SABME

    (set asynchronous balanced mode extended) Установка расширенного асинхронного сбалансированного режима

    UI

    (unnumbered information) Ненумерованная информация.

    Ниже на рис. 4.3.3.15 показана схема алгоритма восстановления после потери кадра RR.

    Рис. 4.3.3.15 Восстановление системы после потери кадра RR

    Сигнал RNR(получатель не готов) используется для запрета пересылки пакетов партнеру на уровне 2 и может использоваться при реализации приоритетных услуг. Другим пакетом, который специфицирован на уровне 2, является кадр frame reject (FRMR). Этот кадр может быть получен объектом второго уровня, но не может быть послан. При получении этого кадра система сбрасывается в исходное состояние. После завершения процедуры обмена разрыв канала производится путем посылки кадров DISC (disconnect) и отклика UA (unnumbered acknowledgment), с этого момента обмен кадрами I-типа не возможен. Кадр DM(disconnect mode) может выполнять те же функции, что и UA. Он используется в качестве отклика на SABME, если слой 2 не может установить связь, или отклика на disc, если связь уже разорвана.

    Для управления и контроля за выделяемыми идентификаторами TEI предназначен специальный драйвер, который имеет возможность выделять и удалять используемые TEI. Все сообщения, связанные с TEI, передаются с помощью пакетов SAPI (service access point identifier). Так как работа с TEI должна выполняться вне зависимости от состояния уровня 2, все TEI-сообщения являются ненумерованными (UI) и не требуют отклика. Надежность достигается путем многократной пересылки пакетов. Пока терминалу не присвоен TEI (terminal endpoint identifier), используется широковещательный метод обмена. Все терминалы пользователя должны воспринимать любые управляющие кадры. Кадры управления в процессе присвоения TEI терминалу рассылаются широковещательно. Схема присвоения TEI и установления связи показана ниже на рис. 4.3.3.16:

    Рис. 4.3.3.16 Алгоритм выделения TEI и формирования связи

    Третий уровень X.25 служит для доставки управляющих сообщений даже в случае отказа сети, именно здесь выполняется реконфигурация маршрута, если это необходимо. Сигнальный пакет 3-го уровня имеет формат (рис. 4.3.3.17):

    Рис. 4.3.3.17 Формат сигнального пакета уровня 3

    Эти пакеты следуют от терминала к коммутатору и наоборот. Первый октет (поле протокольный дискриминатор) дает D-каналу в будущем возможность поддержки нескольких протоколов. Приведенный код соответствует стандартному управляющему запросу пользователя. Третий октет (поле код запроса - call reference value) используется для идентификации запроса вне зависимости от типа коммуникационного канала, где этот запрос может быть реализован. Четвертый байт характеризует назначение пакета (например, Setup - запрос установления канала). Возможные типы сообщений перечислены в таблице 4.3.3.2. Длина сообщения зависит от его типа. Стандарт не регламентирует содержания полей, следующих за полем тип сообщения, и они могут использоваться по усмотрению пользователя для расширения функциональных возможностей системы.

    Таблица 4.3.3.2 Коды типов сообщений

    8

    7

    6

    5

    4

    3

    2

    1

    Значение сообщение

    0

    0

    0

    0

    0

    0

    0

    0

    Переход к определенным типам сообщений:

    0

    0

    0

    -

    -

    -

    -

    -

    Сообщения о состоянии:

     

     

     

    0

    0

    0

    0

    1

    Alerting (оповещение)

     

     

     

    0

    0

    0

    1

    0

    Call proceeding (состояние запроса)

     

     

     

    0

    0

    0

    1

    1

    Progress (прогресс)

     

     

     

    0

    0

    1

    0

    1

    Setup (начальная установка)

     

     

     

    0

    0

    1

    1

    1

    Connect (соединение)

     

     

     

    0

    1

    1

    0

    1

    Setup acknowledge (подтверждение начальной установки)

     

     

     

    0

    1

    1

    1

    1

    Connect acknowledge (подтверждение соединения)

    0

    0

    1

    -

    -

    -

    -

    -

    Сообщения фазы запроса информации:

     

     

     

    0

    0

    0

    0

    0

    User information (пользовательские данные)

     

     

     

    0

    0

    0

    0

    1

    Suspend reject (отложенный отказ)

     

     

     

    0

    0

    0

    1

    0

    Resume reject (отказ возобновления)

     

     

     

    0

    0

    1

    0

    1

    Suspend (откладывание выполнения)

     

     

     

    0

    0

    1

    1

    0

    Resume (возобновление)

     

     

     

    0

    1

    1

    0

    1

    Suspend acknowledge (подтверждение откладывания)

     

     

     

    0

    1

    1

    1

    0

    Resume acknowledge (подтверждение возобновления)

    0

    1

    0

    -

    -

    -

    -

    -

    Сообщения об устранении дефекта:

     

     

     

    0

    0

    1

    0

    1

    Disconnect (отсоединение)

     

     

     

    0

    0

    1

    1

    0

    Restart (повторный старт)

     

     

     

    0

    1

    1

    0

    1

    Release (освобождение)

     

     

     

    0

    1

    1

    1

    0

    Restart acknowledge (подтверждение повторного старта)

     

     

     

    1

    1

    0

    1

    0

    Release complete (освобождения завершено)

    0

    1

    1

    -

    -

    -

    -

    -

    Прочие сообщения:

     

     

     

    0

    0

    0

    0

    0

    Segment (сегмент)

     

     

     

    0

    0

    0

    1

    0

    Facility (возможность)

     

     

     

    0

    1

    1

    1

    0

    Notify (обращение внимания)

     

     

     

    1

    0

    1

    0

    1

    Status inquiry (запрос состояния)

     

     

     

    1

    1

    0

    0

    1

    Congestion control (управление перегрузкой)

     

     

     

    1

    1

    0

    1

    1

    Information (информация)

     

     

     

    1

    1

    1

    0

    1

    Status (состояние)

    * Цифрами в верхней части таблицы пронумерованы биты кодов

    В приведенной ниже таблице 4.3.3.3 представлены информационные элементы, которые могут содержаться в сообщениях Setup (это самый сложный тип сообщений).

    Таблица 4.3.3.3. Поля setup-сообщений

    Поле в пакете

    Длина (октеты)

    Комментарии

    Дискриминатор протокола

    1

     

    Код запроса

    2-3

     

    Тип сообщения

    1

     

    Передача завершена

    1

    Опционно, включается, если пользователь или сеть указывает, что вся информация включена в это сообщение Setup

    Возможности канала

    6-8

    Описывает CCITT телекоммуникационные услуги (BC)

    Идентификация канала

    2-?

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

    Специфические возможности сети

    2-?

    Опционно

    Дисплей

    2-82

    Опционно: IA5 (ASCII) символы для отображения на терминале

    keypad

    2-34

    Альтернатива для пересылки кода вызываемого объекта. keypad может использоваться и для другой информации

    Номер отправителя

    1-?

    Опционно

    Субадрес отправителя

    2-23

    Опционно

    Номер адресата

    2-?

    В случае направления пользователь-сеть является альтернативой keypad

    Субадрес адресата

    2-23

    Опционно

    Выбор транзитной сети

    2-?

    Опционно

    Совместимость с нижним уровнем (llc)

    2-16

    Опционно

    Совместимость с верхним уровнем (hlc)

    2-4

    Опционно

    Пользователь-пользователь

    2-131

    Опционно, когда вызывающий пользователь хочет передать информацию вызываемому

    Сигнальная система ISDN позволяет пользователю уже на фазе формирования канала с помощью запроса setup сформулировать требования к каналу, задав значение BC (bearer capability, см. таблицу 4.3.3.3), а также HLC (high layer compatibility) и LLC (low layer compatibility), характеризуя необходимый вид услуг. При этом проверяется совместимость запрашиваемых скоростей и имеющихся в распоряжении возможностей. HLC определяет тип сервиса или оборудования (телефон, факс группы 3 или 4, видеотекст), а LLC - быстродействие терминала пользователя, механизм адаптации к скорости передачи данных, контроль четности, синхронный/асинхронный интерфейс и т.д.). BC может принимать значения (например, "BC=speech"):

    BC=

    speech

    Означает, что используется обычная для этого вида услуг маршрутизация - может быть задействовано не более двух спутников, (G.711);

    3.1khz audio

    Не должно использоваться эхо-подавление и dcme - (digital circuit multiplication equipment - оборудование уплотнения), необходим m/a-адаптер

    7 khz

    Высококачественная телефония (рекомендации CCITT G.722/G.725), требует 64 Кбит/с;

     

    64kbit/s unrestricted

    Скоростной информационный обмен

    Услуги типа speech или 3.1 khz audio возможны и через общественную коммутируемую телефонную сеть (PSTN), остальные из перечисленных требуют 64-килобитного цифрового канала. Схема формирования запроса, получения доступа к определенному виду услуг показана ниже на рисунке 4.3.3.18. Помимо названных услуг существуют и другие, например, видео-телефония, видеоконференции и пр., список этот постоянно расширяется. При реализации 7кГц-телефонии должны быть выполнены следующие требования:

    • Должно использоваться терминальное оборудование, рассчитанное для работы с 3.1кГц, и обычные сетевые телефонные каналы.
    • Время реализации вызова должно быть приемлемо малым.
    • Система должна выдавать сообщение в случае, если в результате диалога реализуется 3.1кГц вместо 7.

    Видео телефония использует один или два B-канала. В Европе приняты следующие нормы (normes europeennes de telecommunication-net):

    Net3

    isdn с обычной (базовой) скоростью обмена

    Net5

    isdn с первичной скоростью обмена (64кбит/с)

    Net7

    терминальные адаптеры

    Net33

    цифровая телефония.

    Рис. 4.3.3.18 Последовательность сообщений при реализации стандартного вызова

    Вызываемый партнер получает setup-сообщение через широковещательное обращение. Все терминалы, соединенные с NT1 могут анализировать Setup-сообщение с тем, чтобы определить, соответствуют ли они вызывающей стороне. Соответствие определяется по возможностям канала и по совместимости информационных элементов нижнего уровня. Если терминал соответствует требованиям запроса, он посылает сети сообщение alerting (Оповещение). В то же время, если необходимо, терминал должен сформировать локальный сигнал вызова (напр. звонок). После получения всей необходимой информации сеть выдает сообщение call proceeding, которое указывает на то, что начата установка связи с объектом вызова. Когда терминал обнаружил, что на запрос получен отклик, он переадресует connect-сообщение сети. Сеть регистрирует запрос и выдает команду терминалу соединиться с соответствующим B-каналом, послав пакет connect acknowledge, содержащий код B-канала. В любой момент времени к В-каналу может иметь доступ только один терминал. Все остальные терминалы, которые откликнулись на запрос, получат от сети сообщение release, которое переводит их в пассивное состояние. Пользователь может отменить запрос в любое время, послав три сообщения: disconnet, release и release complete (см. рис. 4.3.3.19 и таблица 4.3.3.2).

    Рис. 4.3.3.19 Обмен сообщениями при разрыве связи

    Возможна временная пассивация терминала посредством сообщения suspend с последующим возобновлением прерванного режима с помощью сообщения resume. Каждое из этих сообщений требует подтверждения получения (suspend acknowledge и resume acknowledge, соответственно). При вызове может оказаться несколько терминалов, отвечающих запрашиваемым требованиям (например, телефонных аппаратов). Вызывающая сторона может выбрать один из них (зная, например, их положение). Существует два механизма обращения к заданному терминалу. Первый использует вспомогательную службу direct dialling-in (DDI), которая в случае реализации обычного доступа к ISDN называется multiple subscriber number (MSN). В DDI и MSN номер сети используется для целей маршрутизации в пределах локальной сети пользователя. Каждому терминалу в сети должен быть присвоен уникальный MSN-номер. Именно этот номер используется для идентификации при Setup-процедуре.

    Второй механизм адресации к заданному терминалу базируется на субадресации (subaddressing - SUB). В этом варианте дополнительная адресная информация передается от источника запроса к адресату. Этот адрес не является частью ISDN-номера, который используется для целей маршрутизации. Этот адрес может быть применен для обращения к некоторому процессу внутри терминала (не следует забывать, терминалом может быть ЭВМ) или к приложениям, которые не следуют стандартам OSI. Каждый терминал, подсоединенный к пассивной шине, нуждается в присвоении ему субадреса.

    Принципиальное различие между DDI/MSN и SUB методами адресации заключается в том, что для DDI/MSN адрес является частью ISDN номера, в то время как для SUB это не так.

    В этом случае каждому терминалу, подключенному к пассивной шине, должен быть присвоен такой субадрес. Процедура Setup должна содержать информацию о субадресе. Для выбора типа услуг и проверки терминальных возможностей используется обмен сообщениями alerting-connect.

    Для максимального удовлетворения запросов потребителей isdn должна поддерживать самые разные дополнительные виды услуг. Чтобы решить эти задачи на уровне 3 для интерфейса пользователь-сеть разработаны два протокола - функциональная и стимулирующая сигнальные процедуры. В случае стимулирующей сигнальной процедуры терминал не должен иметь какой-либо информации о вспомогательных видах услуг. Работа терминала контролируется сетью с помощью сигнальных сообщений уровня 3. Сеть и терминал работают по схеме клиент-сервер и от терминала не требуется особых аналитических способностей. Базовый формат управляющих сообщений соответствует типу information. Существуют две разновидности этого протокола: один использует управляющие последовательности символов, заключенные между * и #, для второго - сеть должна хранить специальный профайл для каждого терминала. Такой профайл может переопределять функцию некоторых клавиш терминала. Нажатие такой клавиши осуществляет вызов определенного вида услуг.

    В случае функциональной сигнальной процедуры терминал должен знать все о вспомогательном виде услуг и хранить всю необходимую информацию о них. Функциональный протокол использует информационные элементы facility (возможность, см. таблицу 4.3.5.4). Для пересылки этих информационных элементов используются сообщения типа register (см. описание протокола X.25). Функциональный протокол базируется на протоколе ROSE (remote operations service element). Этот протокол служит для поддержки приложений, где необходим интерактивный контроль сетевых объектов. Протокол ROSE обеспечивает запуск процесса, поддерживает процедуры подтверждения и последующее управление процессом. В таблице 4.3.5.4 приведен перечень дополнительных услуг, предоставляемых ISDN и поддерживаемых функциональным протоколом.

    Таблица 4.3.5.4. Дополнительные услуги сети ISDN

    • Определение вызывающего номера (более эффективный аналог АОН);
    • Ограничение (запрет) по вызывающим номерам;
    • Ожидание вызова;
    • Прямой набор номера;
    • Субадресация;
    • Переносимость терминала;
    • Телефонные конференции;
    • Безусловная переадресация вызовов;
    • Переадресация, если номер занят;
    • Переадресация вызова при отсутствии ответа;
    • Групповые номера (по одному и тому же номеру к серверу могут дозваниваться несколько модемов)

    Реально это лишь ядро списка, разные сети могут предоставлять и многие другие услуги.

    При установлении телефонного канала используется сообщение TUP (telephony user part). В ISDN определены также сообщения ISUP (integrated services user part), которые должны стать основой всех будущих разработок. Примерами ISUP могут служить следующие сообщения:

    IAM

    (initial address message) используется для инициализации канала, передачи маршрутной информации и параметров запроса.

    SAM

    (subsequent address message) посылается вслед за iam, когда необходимо передать дополнительную информацию о предстоящей сессии.

    INR

    (information request message) посылается коммутатором для получения информации по текущей сессии.

    INF

    (information message) передает информацию, запрошенную inr.

    ACM

    (address complete message) подтверждает получение всей необходимой маршрутной информации.

    CPG

    (call progress message) посылается адресатом вызывающей стороне и информирует о том, что имело место какое-то событие.

    ANM

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

    FAR

    (facility request message) посылается одним коммутатором другому для активации его состояния.

    FAA

    (facility accepted message) является позитивным откликом на запрос far.

    FRJ

    (facility reject message) отклик на запрос far, если он не может быть выполнен.

    USR

    (user-to-user information message) используется для обмена информацией между пользователями (помимо сигнальной информации).

    CMR

    (call modification request message) сообщение, которое может быть послано в любом направлении, для модификации сессии, например, для перехода от передачи данных к передаче голоса.

    CMC

    (call modification completed message) сообщение-отклик на запрос CMR, подтверждающее его исполнение.

    CMRJ

    (call modification reject message) сообщение-отклик на запрос cmr, оповещающее об отклонении этого запроса.

    REL

    (release message) сообщение, посылаемое в любом направлении и оповещающее о том, что система свободна и готова перейти в пассивное состояние при получении сообщения о завершении процедуры release.

    RLC

    (release complete message) - посылается в ответ на REL.

    В ISDN используются базовая (B-канал, 64 Кбит/с) и первичная (1,544/2,048 Мбит/с) скорости передачи информации. Сигнальный D-канал формируется на основе 24-го временного домена (timeslot) в случае 1,544 Мбит/с и 16-го для 2,048 Мбит/с. Характеристики первичных каналов ISDN приведены в таблице 4.3.3.5.

    Таблица 4.3.3.5. Характеристики первичных каналов ISDN

    Быстродействие первичного канала

    Кодировка

    Импеданс линии

    Временной домен d-канала

    Уровень сигнала

    1,544 Мбит/с

    B8ZS

    100 Ом

    24

    3 В

    2,048 Мбит/с

    HDB3

    120 Ом

    16

    3 В

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

    Для первичной скорости не предусматривается интерфейс многоточечного обмена в локальной сети пользователя; связь устанавливается между сетью и одним из PABX (public automatic branch exchange) или другим терминалом.

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

    Для базовой скорости передачи работает сигнальная цифровая система доступа DASS (digital access signaling system). Формат кадра при этом имеет вид (DASS2/DPNSS - digital private network signaling system):

    Рис. 4.3.3.20 DASS2/DPNSS-кадр уровня 2

    Этот формат не отличается от общепринятого для уровня 2 ISDN, за исключением числа байт управления (см. рис. 4.3.3.20 и 4.3.3.7), что допускается регламентирующими документами. Использование местной ISDN-АТС открывает дополнительные возможности. Помимо высококачественной локальной связи появляются коллективные (групповые) номера, что снимает ограничение на число пользователей, подключенных к узлу через обычные аналоговые модемы. Все пользовательские модемы дозваниваются по одному и тому же номеру, а коммутатор выполняет функцию пакетного мультиплексора. Емкость таких АТС легко наращивается, отдельные АТС могут объединяться друг с другом. Схема взаимодействия такой АТС (PTNX) с терминальным пользовательским оборудованием, другими ptnx и основной сетью ISDN показана на рис. 4.3.3.21. Местная АТС может предоставлять те же услуги, что и традиционная сеть ISDN, плюс запрограммированные локально виды сервиса (диалог между пользователями локальной сети, услуга типа "не беспокоить" и т.д.).

    Рис. 4.3.3.21 Связи местной ISDN-АТС

    Взаимодействие между ISDN и PSPDN регулируется стандартом ccitt x.31 (и i.462). x.31 позволяет использовать ISDN с существующими сетями x.25. Схема взаимодействия периферийного оборудования, ISDN и PSPDN показана на рисунке 4.3.3.22 (ISDN-коммутатор может и отсутствовать).

    Рис. 4.3.3.22 Схема взаимодействия сетей ISDN и X.25

    TA - терминальный адаптер; TE - терминальное оборудование; NT - сетевое терминальное оборудование

    Доступ к программам обработки пакетов возможен через B- или D-каналы. В зависимости от вида приложения доступ через D-канал иметь определенные преимущества. D-канал в отличии от B-канала принципиально не может быть заблокирован. Возможна работа одновременно с 8-ю терминалами, подключенными к пассивной ISDN-шине. Кроме того, работа с D-каналом оставляет B-канал свободным для задач, которые не решаемы через D из-за его малого быстродействия (16 Кбит/с). А согласно рекомендациям LAPD быстродействие D-канала не может быть увеличено (по этой же причине максимальная длина пакетов X.25 в данной схеме не может превышать 260 октетов (против 1024 для обычных каналов X.25). К недостаткам использования D-канала можно отнести возможное увеличение задержек из-за низкого быстродействия. Протокол X.25 был разработан довольно давно для "традиционных" приложений и его недостаточная гибкость (большие задержки откликов, таймауты и пр.) приводит к тому, что он совершенно не пригоден для некоторых новых приложений. Это вынудило разработку для ISDN новых режимов работы с пакетами. И первое что было сделано - это четкое разделение управляющих и информационных потоков.

    ISDN может рассматриваться как две логически независимые субсети - сигнальную субсеть и коммутируемую информационную сеть (в x.25 информация и управление осуществляется по одним и тем же каналам). В соответствии с этим разделением терминология CCITT различает плоскость управления (C-plane) и пользовательскую информационную плоскость (U-plane, см. рис. 4.3.3.23). В ISDN существует два режима: frame relaying (передача кадров, наиболее простой из режимов) и frame switching (коммутация кадров). Отличительной особенностью режима frame relaying является отсутствие подтверждений получения пакета при обмене данными между ISDN-терминалами (аналог UDP в TCP/IP сетях). Для обоих режимов используется одни и те же сигнальные процедуры (Q.933), но они отличаются протоколами U-плоскости при пересылке информации. Здесь используются протоколы передачи данных, базирующиеся на усовершенствованном стандартном сигнальном протоколе LAPD слоя 2, известном как LAPF - link access procedures for frame mode bearer services (Q.922). Пользователь может установить несколько виртуальных соединений и/или постоянных виртуальных связей одновременно с несколькими адресатами.

    Рис. 4.3.3.23 Услуги ISDN в режиме переключения (цифрами помечены уровни протоколов, в скобках приведены ссылки на документы ITU)

    На сигнальном уровне C-плоскости используются стандартные LAPD-процедуры слоя 2 (Q.921 или I.441), а для слоя 3 спецификация кадрового режима (Q.933). Но на U-плоскости сеть поддерживает только небольшую часть связного протокола:

    • разделение кадров с использованием HDLC-флагов;
    • проверка кадров по длине и контрольной сумме, выбрасывание кадров с ошибками;
    • мультиплексирование и демультиплексирование кадров, относящихся к разным виртуальным запросам, на основе их адресов слоя 2.

    В простейшем случае сеть посредством сигнальных процедур на фазе Setup формирует вход в маршрутную таблицу. На уровне 2 для каждого виртуального запроса выделяется адрес, который остается действительным только на время данного вызова. При пересылке данных сеть просто индексирует маршрутную таблицу, используя адреса слоя 2 поступающих кадров, и ставит их в очередь на передачу по соответствующему маршруту. На фазе передачи информации терминалы используют протоколы более высокого уровня по схеме точка-точка без привлечения сети. Схема протокола коммутации кадров показана ниже на рис. 4.3.3.24, здесь передача кадров происходит с подтверждением получения (до какой-то степени аналог протокола tcp). Сеть детектирует потери и случаи дублирования пакетов.

    Здесь на сигнальном уровне все процедуры следуют требованиям связного протокола ISDN в полном объеме в том числе и при передаче данных. Это подразумевает необходимость подтверждения получения каждого информационного кадра, пересылаемого от терминала к терминалу. Cеть контролирует доставку кадров и выявляет ошибки.

    Как и в предыдущем случае мультиплексирование и демультиплексирование выполняется с использованием адресов слоя 2. Адрес кадра может содержать 2-4 октетов, а информация занимать от 1 до 262 октетов. Последняя величина может быть и увеличена в результате переговоров между отправителем и получателем при формировании виртуального канала. Рекомендуется не использовать кадров с размером поля данных более 1600 октетов во избежании фрагментации и последующей сборки сообщений.

    Рис. 4.3.3.24 Режим переключения кадров

    ITU-T делит все канальные услуги на две категории. 8 типов услуг уже определены для случая коммутации каналов и три определены для коммутации пакетов. Три из восьми считаются определяющими и каждый ISDN-переключатель должен их поддерживать (ITU-T рекомендация I.230).

    Previous: 4.3.2 Протоколы сетей X.25    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.4 Протокол Frame Relay


    previous up down next index index
    Previous: 4.3.5 Протоколы сетей ATM    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.3.7 Модемы

    4.3.6 Синхронные каналы SDH/SONET
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Мультиплексирование потоков информации при формировании мощных региональных и межрегиональных каналов имеет два решения. Одно базируется на синхронном мультиплексировании и носит название синхронная цифровая иерархия (SDH, cм. Н.Н.Слепов, Синхронные цифровые сети SDH. ЭКО-ТРЕНДЗ, Москва, 1998), другое использует простой асинхронный пакетный обмен и носит название асинхронный режим передачи (ATM, см. предыдущую главу).

    Стандарт SDH (synchronous digital hierarchy) разработан в Европе, (предназначен для замены иерархии асинхронных линий E-1/E-3) используется в настоящее время многими сетями и представляет собой модификацию американского стандарта на передачу данных по оптическим каналам связи SONET (synchronous optical network). Несмотря на свое название SONET не ограничивается исключительно оптическими каналами. Спецификация определяет требования для оптического одно- и мультимодового волокна, а также для 75-омного коаксиального кабеля CATV 75. Пропускная способность SONET начинается с 51,84 Мбит/с STS-1 (synchronous transport signal-1). Более высокие скорости передачи информации в sonet кратны этому значению. Стандартизованы следующие скорости передачи, которые кратны скорости 64 Кбит/с.

    STS-1

    51,840

    STS-18

    933,120

    STS-3

    155,520

    STS-24

    1244,160

    STS-9

    466,560

    STS-36

    1866,240

    STS-12

    622,080

    STS-48

    2488,320

    Соответствие каналов SONET и SDH приведено ниже[W. Simpson RFC-1619 "PPP over SONET/SDH"] (и тот и другой могут использоваться для организации связей по схеме PPP):

    sonet

    sdh

    STS-3c

    STM-1

    STS-12c

    STM-4

    STS-48c

    STM-16

    sonet (стандарт ANSI, предназначенный для замены NADH - north american digital hierarchy) использует улучшенную PDH - (plesiochronous digital hierarchy - plesios - близкий (греч.)) схему мультиплексирования каналов. В плезиохронной (почти синхронной) иерархии используется мультиплексирование с чередованием бит, а не байт. Мультиплексор формирует из N входных потоков один выходной (сети, где разные часы сфазированы с разными стандартами, но все они привязаны к одной базовой частоте называются плезиохронными). Так как скорости разных каналов могут не совпадать и нет структур, которые могли бы определить позиции битов для каждого из каналов, используется побитовая синхронизация. Здесь мультиплексор сам выравнивает скорости входных потоков путем введения (или изъятия) соответствующего числа бит. Информация о введенных и изъятых битах передается по служебным каналам. Помимо синхронизации на уровне мультиплексора происходит и формирование кадров и мультикадров. Так для канала Т2 (6312кбит/с) длина кадра равна 789 бит при частоте кадров 8 кГц. Мультикадр содержит 12 кадров. Помимо европейской и американской иерархии каналов существует также японская. Каждая из этих иерархий имеет несколько уровней. Сравнение этих иерархий представлено в таблице 4.3.6.1.

    Таблица 4.3.6.1. Сравнение европейской и американской иерархии каналов

    Уровень иерархии

    Скорости передачи для иерархий

    Американская
    1544 Кбит/c

    Европейская
    2048 Кбит/c

    Японская
    1544 Кбит/c

    0

    64 (DS0)

    64

    64

    1

    1544 (DS1)

    2048 (Е1)

    1544 (DS1)

    2

    6312 (DS2)

    8448 (Е2)

    6312 (DS2)

    3

    44736 (DS3)

    34368 (Е3)

    32064 (DSJ3)

    4

    274176 (Не входит в рекомендации МСЭ-Т)

    139264 (Е4)

    97728 (DSJ4)

    Но добавление выравнивающих бит в PDH делает затруднительным идентификацию и вывод потоков 64 Кбит/с или 2 Мбит/с, замешанных в потоке 140 Мбит/с, без полного демультиплексирования и удаления выравнивающих бит. Если для цифровой телефонии PDH достаточно эффективна, то для передачи данных она оказалась недостаточно гибкой. Именно это обстоятельство определило преимущество систем SONET/SDH. Эти виды иерархических систем позволяют оперировать потоками без необходимости сборки/разборки. Структура кадров позволяет выполнять не только маршрутизацию, но и осуществлять управление сетями любой топологии. Здесь использован чисто синхронный принцип передачи и побайтовое, а не побитовое чередование при мультиплексировании. Первичной скоростью SONET выбрана 50688 Мбит/с (ОС1). Число уровней иерархии значительно расширено (до 48). Кратность уровней иерархии равна номеру уровня.

    CCITT выработал следующие рекомендации на эту тему: G.707, G.708 и G.709. CCITT разработал рекомендации для высокоскоростных каналов H:

    H0

    384 Кбит/с=4*64 Кбит/с. 3*h0=1,544 Мбит/с

    H1

    H11

    1536 Кбит/с

    H12

    1920 Кбит/с

    h4

    ~135 Мбит/с

    H21

    ~34 Мбит/с

    H22

    ~55 Мбит/с.

    На нижних уровнях SDH и SONET в некоторых деталях различаются. Внедрение стандарта SONET ликвидировало многие недостатки каналов T-1 (ограничения на размер максимальной полезной нагрузки, простота стыковки скоростных каналов связи). SONET хорошо согласуется с ATM и FDDI, что создает фундаментальный базис для широкополосных сетей ISDN (B-ISDN). Следует учитывать, что SONET сохраняет совместимость с уже существующими каналами, убирая лишь некоторые присущие им недостатки. Одним из базовых каналов сегодня является T-1 (1544 Кбит/с для США). Он содержит в себе 24 субканалов DS-0 (digital signal at zero level, 64 Кбит/с, США). Мультиплексирование 24 каналов DS-0 по времени формирует канал DS-1 (24 канала*64 Кбит/с)+8 Кбит/с=1544 Кбит/с, последнее слагаемое связано с заголовками информационных блоков). Этой величине соответствует в Европе 2048 Кбит/с (канал E-1 = 30*ds0). Два канала T-1 образуют канал T-1c, четыре канала T-1 формируют канал T-2, а семь T-2 (28 T-1) образуют T-3. Для оптических систем связи в качестве базового принят канал OC-1, равный по пропускной способности T-3. А кадр STS-1 выбран в качестве основного в системе SONET. Кадр STS-1 имеет 9 строк и 90 столбцов (810 байт). Кадры передаются с частотой 8 кГц, что дает для канала STS-1 51840 Кбит/с = 8000Гц*810байт*8бит. Эта цифра характеризует физическую скорость обмена, включающую в себя передачу служебной информации (заголовков), эффективная информационная пропускная способность равна 50112 Кбит/с. Быстродействие каналов более высокого уровня SONET получается умножением пропускной способности STS-1 (51,84 Мбит/с) на целое число. Так пропускная способность OC-3 будет равна 155,52 Мбит/с, а OC-24 - 1244,16 Мбит/с и т.д. Целью создателей SONET было прямая стыковка оптических каналов различных сервис-провайдеров (вспомним, что непосредственное соединение каналов T-1 и E-1 не возможно). SDH допускает сцепление нескольких контейнеров (в том числе и разных размеров), если в один контейнер данные не помещаются. Допускается объединение нескольких контейнеров равного размера в один большой. Хотя относительный размер заголовка виртуального контейнера невелик (~3,33%), его объем достаточен для передачи достаточно больших объемов служебной информации (до 5,184 Мбит/c).

    В SONET предусмотрено четыре варианта соединений: точка-точка, линейная цепочка (add-drop), простое кольцо и сцепленное кольцо (interlocking ring). Линейные варианты используются для ответвлений от основного кольца сети. Наиболее распространенная топология - самовосстанавливающееся кольцо (см. также FDDI). Такое кольцо состоит из ряда узлов, которые связаны между собой двухсторонними линиями связи, образующими кольцо и обеспечивающими передачу сообщений по и против часовой стрелки. Способность сетей SONET к самовосстановлению определяется не только топологией, но и средствами управления и контроля состояния. При повреждении трафик перенаправляется в обход, локально это приводит к возрастанию информационного потока, по этой причине для самовосстановления сеть должна иметь резерв пропускной способности (как минимум двойной). Но, проектируя сеть, нужно избегать схем, при которых основной и резервный маршрут проходят через одну и ту же точку, так как они могут быть, если не повезет, повреждены одновременно. Резервные пути могут использоваться для низкоприоритетных обменов, которые могут быть заблокированы при самовосстановлении.
    Сети SONET (и SDH) имеют 4 архитектурных уровня:

    • Фотонный (photonic) - нижний уровень иерархии. Этот уровень определяет стандарты на форму и преобразование оптических сигналов, на электронно-оптические связи.
    • Секционный (section) - предназначен для управление передачей STS-кадров (sonet) между терминалами и повторителями. В его функции входит контроль ошибок.
    • Линейный (line) - служит для синхронизации и мультиплексирования, осуществляет связь между отдельными узлами сети и терминальным оборудованием, например линейными мультиплексорами, выполняет некоторые функции управления сетью.
    • Маршрутный (path) - описывает реальные сетевые услуги (T-1 или T-3), предоставляемые пользователю на участке от одного терминального оборудования до другого.

    Существующие PDH-сети мультиплексируют каналы, используя каскадную схему, показанную на рис. 4.3.6.1.

    Рис. 4.3.6.1. pdh-мультиплесирование

    SDH-иерархия распространяется до 2500 Мбит/с и может быть расширена вплоть до 13 Гбит/с (ограничение оптического кабеля). SDH предоставляет существенно улучшенную схему мультиплексирования каналов для быстродействующих интерфейсов с полосой 150 Мбит/с и выше:

    • обеспечивается единый стандарт для мультиплексирования и межсетевого соединения;
    • прямой доступ к низкоскоростным каналам без необходимости полного демультиплексирования сигнала;
    • простая схема управления сетью;
    • возможность использования новых протоколов, по мере их появления (напр. atm)

    При передаче по сети SDH информация вкладывается в специальные структуры, называемые виртуальными контейнерами (VC). Эти контейнеры состоят из двух частей:

    1. Собственно контейнер (C), где лежит передаваемая информация;
    2. Заголовок (path overhead - POH), который содержит вспомогательную информацию о канале, управляющую информацию, связанную с маршрутом передачи.

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

    Таблица 4.3.6.2. Виды виртуальных контейнеров

    Виртуальный контейнер

    Поддерживаемые услуги

    VC-11

    1.544 Мбит/с североамериканские каналы

    VC-12

    2.048 Мбит/с европейские каналы

    VC-2

    6.312 Мбит/с каналы (используются редко). VC-2 могут также объединяться для достижения больших скоростей

    VC-3

    34.368 Мбит/с и 44.736 Мбит/с каналы

    VC-4

    139.264 Мбит/с каналы и другие высокоскоростные услуги

    В схеме мультиплексирования применены следующие обозначения:

    С-n

    Контейнер уровня n (n=1,2,3,4);

    VC-n

    Виртуальный контейнер уровня n (n=1,2,3,4);

    TU-n

    Трибные блоки уровня n (n=1,2,3);

    TUG-n

    Группа трибных блоков n (n=2,3);

    AU-n

    Административные блоки уровня n (n=3,4);

    AUG

    Группа административных блоков (стандарт G.709).

    Контейнеры С-n используются для инкапсуляции сигналов каналов доступа или трибов, при этом уровни n соответствуют уровням PDH. Контейнер С-1 может нести в себе контейнер С-11, который содержит триб Т1=1,54 Мбит/с, и контейнер С-12, несущий триб Е1=2 Мбит/с. Контейнер С-2 разбивается на контейнер С-21, содержащий триб Т2=6 Мбит/с и контейнер С-22 с трибом Е2=8Мбит/с. Контейнер С-3 разбивается на контейнер С-31 (триб Е3=34 Мбит/с) и контейнер С-32 с трибом Т3=45Мбит/с. С-4 не имеет подуровней и несет в себе триб Е4=140 Мбит/с.

    Виртуальный контейнер VC-3 делится на два виртуальных контейнера VC-31 и VC-32, полезная нагрузка VC-3 образуется из одного контейнера С-3 или с помощью мультиплексирования нескольких групп TUG-2.

    Виртуальный контейнер VC-4 с полезной нагрузкой в виде контейнера С-4 или путем мультиплексирования нескольких групп TUG-2 и TUG-3.

    Административный блок AU-3 разбивается на подуровни AU-31 и AU-32, поле данных которых формируется из виртуального контейнера VC-31 или VC-32 соответственно.

    Административный блок AU-4 не имеет подуровней, его поле данных формируется из виртуального контейнера VC-4 или комбинаций других блоков: 4*VC-31 или 3*VC-32 или 21*TUG-21 или 16*TUG-22.

    Рис. 4.3.6.2 Иерархия мультиплексирования SDH

    На рис. 4.3.6.2 отображена иерархия мультиплексирования потоков информации в SDH. На рисунке не показана возможность вложения контейнера VC-11 в TU-12. SDH-сигнал состоит из STM-1 кадров (synchronous transport module уровень 1; рис. 4.3.6.3). Этот сигнал обеспечивает интерфейс для обмена со скоростью 155.52 Мбит/c, что является базовым блоком, из которого строятся интерфейсы с более высоким быстродействием. Для более высоких скоростей может быть использовано n STM-1 кадров с перекрытием байтов (byte interleave, см. рис. 4.3.6.6). Согласно требованиям CCITT n может принимать значения 1, 4 и 16, предоставляя интерфейс для каналов с полосой 155.52, 622.08 и 2488 Мбит/с. Каждый STM-1 кадр содержит 2430 байтов, передаваемых каждые 125 мксек. Для удобства такой кадр можно отобразить в виде блока, содержащего 9 строк по 270 байт.

    Рис. 4.3.6.3 Структура кадра STM-1

    Первые 9 колонок кадра, исключая строку 4, используются в качестве заголовка. Регенераторная часть служит для передачи сигнала между линейным оборудованием и несет в себе флаги разграничения кадров, средства для обнаружения ошибок и управления телекоммуникационным каналом.

    Мультиплексорный заголовок используется мультиплексорами, обеспечивая детектирование ошибок и информационный канал с пропускной способностью 576 Кбит/с. AU (administrative units) - предлагает механизм эффективной транспортировки информации STM-1. Административный блок перераспределяет информацию внутри виртуального контейнера. Начало виртуального контейнера индицируется указателем au, в котором содержится номер байта, с которого начинается контейнер. Таким образом, начала STM-1 и VC не обязательно совпадают.

    Рис. 4.3.6.5. VC-4, плавающий в AU-4

    VC-4 (см. рис. 4.3.6.5) позволяет реализовать каналы с быстродействием 139.264 Кбит/с. Более высокая скорость обмена может быть достигнута путем соединения нескольких VC-4 вместе. Для более низких скоростей (около 50 Мбит/с) предлагается структура AU-3.

    Три VC-3 помещаются в один кадр STM-1, каждый со своим au-указателем. Когда три VC-3 мультиплексируются в один STM-1, их байты чередуются, то есть за байтом первого VC-3 следует байт второго vc-3, а затем третьего. Чередование байтов (byte interleaving) используется для минимизации задержек при буферизации. Каждый VC-3 имеет свой AU-указатель, что позволяет им произвольно размещаться в пределах кадра STM-1.

    Рис. 4.3.6.6. Три VC-3 в STM-1 кадре

    Каждому VC-3 при занесении в STM-1 добавляется 2 колонки заполнителей, которые размещаются между 29 и 30, а также между 57 и 58-ой колонками контейнера VC-3. VC, соответствующие низким скоростям, сначала вкладываются в структуры, называемые TU (tributary units - вложенные блоки), и лишь затем в более крупные - VC-3 или VC-4. TU-указатели позволяют VC низкого уровня размещаться независимо друг от друга и от VC высокого уровня.

    VC-4 может нести в себе три VC-3 непосредственно, используя TU-3 структуры, аналогичные AU-3. Однако транспортировка VC-1 и VC-2 внутри vc-3 несколько сложнее. Необходим дополнительный шаг для облегчения процесса мультиплексирования VC-1 и VC-2 в структуры более высокого уровня (см. рис. 4.3.6.7).

    Рис. 4.3.6.7. Транспортировка VC при низких скоростях с использованием TU-структур

    Так как VC-1 и VC-2 оформляются как TU, они вкладываются в TUG (Tributary Unit Group). TUG-2 имеет 9 рядов и 12 колонок, куда укладывается 4 VC-11, 3 VC-12 или один VC-2. Каждый TUG-2 может содержать VC только одного типа. Но TUG-2, содержащие различные VC, могут быть перемешаны произвольным образом. Фиксированный размер TUG-2 ликвидирует различия между размерами VC-1 и VC-2, упрощая мультиплексирование виртуальных контейнеров различных типов и их размещение в контейнерах более высокого уровня. Данная схема мультиплексирования требует более простого и дешевого оборудования для осуществления мультиплексирования, чем PDH.

    Если в SDH управление осуществляется на скоростях в несколько килобайт, в ATM оно реализуется на скорости канала, что влечет за собой определенные издержки.

    Для управления SDH/SONET используется протокол SNMP (см. RFC-1595, "Definitions of Managed Objects for the SONET/SDH Interface Type") и база данных MIB.

    Архитектура сети, базирующейся на SDH, может иметь кольцевую структуру или схему точка-точка.

    Previous: 4.3.5 Протоколы сетей ATM    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.3.7 Модемы


    previous up down next index index
    Previous: 4.2.3 NetBIOS    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.4 Интернет
        Next: 4.3.1 Эталонная сетевая модель ISO

    4.3 Региональные сети
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.3 Региональные сети

    1

    5

    4.3.1 Эталонная сетевая модель ISO

    5

    68

    4.3.2 Протоколы сетей X.25

    18

    213

    4.3.3 Интегрированные сети ISDN

    25

    451

    4.3.4 Протокол Frame Relay

    6

    77

    4.3.5 Протоколы сетей ATM

    21

    254

    4.3.6 Синхронные каналы SDH/SONET

    9

    165

    4.3.7 Модемы

    10

    126

    Региональные сети (WAN - Wide Area Network) с точки зрения архитектуры и протоколов практически не отличаются от глобальных. В региональных сетях обычно не используются трансокеанские кабели, но это отличие не может рассматриваться как принципиальное. Региональные сети решают проблему формирования из LAN (локальных сетей) сетей регионов и целых стран и даже наднациональных сетей (например, E-BONE для Европы). Как правило, эти сети строятся с использованием протоколов SDH, ATM, ISDN, Frame Relay или X.25. Архитектурно такие сети формируются из каналов со схемой точка-точка и мощных коммутаторов-мультиплексоров. Из таких фрагментов формируются и опорные сети (BackBone), которые позволяют сократить число шагов от узла к узлу. В этих сетях в основном используются оптоволоконные транспортные системы, а там где это нерентабельно, спутниковые или радиорелейные каналы.

    С появлением корпоративных сетей типа Интранет понятия локальной и региональной сетей стало частично перекрываться. Для пользователя Интранет все узлы такой сети являются локальными, хотя и могут отстоять на сотни или даже тысячи километров друг от друга. По существу сети Интранет являются наложенными сетями по отношению к региональным сетям (WAN). Интернет также следует отнести к числу наложенных сетей по отношению к WAN.

    Previous: 4.2.3 NetBIOS    UP: 4.2.1 Протоколы Novell (IPX/SPX)
    Down: 4.4 Интернет    Next: 4.3.1 Эталонная сетевая модель ISO


    previous up down next index index
    Previous: 4.3.6 Синхронные каналы SDH/SONET    UP: 4.3 Региональные сети
    Down: 4.4 Интернет
        Next: 4.4 Интернет

    4.3.7 Модемы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Само название этого прибора происходит от имеющихся в нем модулятора и демодулятора. Современный модем можно отнести к числу устройств с наибольшим числом современных технологий на кубический сантиметр. Разнообразие модемов огромно. Они различаются по конструкции, по используемым протоколам, по характеру интерфейсов и т.д. Основное назначение модема оптимальное преобразование цифрового сигнала в аналоговый для передачи его по каналу связи и, соответственно, обратное преобразование на принимающей стороне. Под "оптимальным преобразованием" понимается такое, которое обеспечивает надежность связи, улучшает отношение сигнал шум и как следствие пропускную способность канала. Это преобразование необходимо для обеспечения улучшения отношения сигнал-шум. В качестве канала передачи данных может быть использована городская телефонная сеть, выделенная линия или радио-канал. Схема взаимодействия модемов показана на рис. 4.3.7.1.

    Рис. 4.3.7.1. Схема соединения двух модемов (М1 и М2) через канал

    В качестве последовательного интерфейса может выступать RS-232, V.35, G.703 и т.д.. Все модемы содержат в себе управляющий микропроцессор, постоянную память (ROM), куда записано фирменное программное обеспечение и интерпретатор команд, энергонезависимую память (NVRAM - non-volatile RAM), которая хранит конфигурационные профайлы модема, телефонные номера и т.д., буфер ввода/вывода (128-256 байт), сигнальный процессор (DSP), включающий в себя модулятор и демодулятор, интерфейс для связи с ЭВМ (RS-232) и оперативную память.

    Первоначально модемы использовались для связи через традиционные коммутируемые телефонные линии. Так как такие линии содержат только два провода, а информационный обмен должен происходить в обоих направлениях одновременно, возникает проблема отделения передаваемого сигнала от приходящего из вне (подавление эхо; см. раздел 2.1). Для выделенных четырехпроводных линий эта проблема значительно упрощается, здесь прием и передача осуществляется по разным скрученным парам и эхо возникает лишь из-за перекрестных наводок (NEXT). Модемы подключаются к последовательным интерфейсам ЭВМ (COM-порт, RS-232), иногда для подключения модема используется специальная плата расширения, которая имеет дополнительные буферы и помогает достичь большего сжатия информации, существуют модемы, подключаемые и к параллельному порту ЭВМ. Модемы (микромодемы) могут работать не только через общедоступную телефонную сеть, они могут найти применение при соединении терминалов или ЭВМ в пределах организации, если расстояние между ними исчисляются сотнями метров (а иногда и километрами). В этом случае они помогают повысить надежность связи и исключить влияние разностей потенциалов между земляными шинами соединяемого оборудования. Микромодемы не требуют подключения к сети переменного тока, так как получают питание через разъем последовательного интерфейса (RS-232).

    Все протоколы модемов утверждаются международным телекоммуникационным союзом (ITU), ранее за это был ответственен Консультативный комитет CCITT. Асинхронные модемы поддерживают определенный набор команд, который был впервые применен фирмой hayes в модеме smartmodem 1200. Модемы, придерживающиеся этого стандарта, называются Hayes-совместимыми. Совместимость предполагает идентичность функций первых 28 управляющих регистров модема (всего модем может иметь более сотни регистров). Почти все внутренние команды начинаются с символов AT (attention) и имеют по три символа. По этой причине их иногда называют AT-командами. Hayes-совместимость гарантирует, что данный модем будет работать со стандартными терминальными программами. Реально набор команд для модемов разных производителей варьируется в широких пределах. Для синхронных модемов набор команд регламентируется стандартом V.25bis. Ниже (таблица 4.3.7.1) приводится перечень стандартных модемных протоколов и стандартов.

    Таблица 4.3.7.1. Основные протоколы модемов

    Название

    Тип модуляции

    Назначение протокола

    V.21

    FSK

    Дуплексный модем на 300 бит/с для телефонных сетей общего назначения, используется факс-аппаратами и факс-модемами

    V.22

    DPSK

    Дуплексной модем для работы при скоростях 600/1200бит/с

    V.22bis

    QAM

    Дуплексной модем для работы при скоростях 1200/2400бит/с

    V.23

    FSK

    Асинхронный модем на частоту 600/1200бит/с (сети videotex), несовместим с V.21, V.22 и V.22bis

    V.24

    Стандарт на схемы сочленения DTE и DCE

    V.26

    Модем для работы на выделенную линию на частотах 2400/1200бит/с

    V.27

    Модем для работы на частотах 4800бод/с

    V.27bis

    Модем для работы на выделенную линию на частотах 2400/4800бит/с

    V.27ter

    DPSK

    Модем с набором телефонного номера на частоту 2400/4800бит/с (fax)

    V.29

    QAM

    Модем на частоту 9600бит/с для 4-проводных выделенных линий (fax)

    V.32

    QAM
    tcm

    Семейство 2-проводных модемов, работающих на частотах до 9600бит/с

    V.32bis

    TCM

    Модем, работающий на выделенную линию для частот 7200, 12000 и 14400бит/с

    V.33

    TCM

    Модем на частоту 14.4кбит/с для выделенных линий

    V.34

    Модем на частоту 28.8кбит/с, использован новый протокол установления связи

    V.34bis

    Модем на частоту 32 кбит/с

    V.35

    Модем, работающий на выделенную линию с частотами до 9600бит/с

    V.42bis

    Стандарт для сжатия данных в модемах (4:1)

    Начиная с модемов V.32bis, стала использоваться динамическая регулировка скорости в ходе телекоммуникационной сессии в зависимости от состояния линии связи. Качество линии отслеживается по отношению сигнал/шум или по проценту блоков, переданных с ошибкой за определенный период времени.

    Важным свойством модемов является возможность коррекции ошибок и сжатия информации. Ошибки корректируются путем повторной пересылки ошибочных блоков (ARQ - automatic repeat request). Ошибки контролируются с использованием CRC (cyclic redundancy check). Этим целям отвечает стандарт V.42, принятый еще в 1988 году, он включает в себя протокол LAPM (link access procedure for modems) и один из протоколов mnp (microcom networking protocol). В V.42 применен алгоритм сжатия информации Lempel-Ziv. При установлении связи между модемами определяется, какой из протоколов коррекции и сжатия они оба поддерживают. Если это V.42, то они сначала пытаются работать с использованием протокола LAPM. При неудаче (один из модемов не поддерживает V.42) используется протокол MNP. Перечисленные ниже алгоритмы коррекции ошибок и сжатия информации работают только для асинхронных модемов. Для синхронных модемов известен алгоритм сжатия SDS (synchronous data compression) фирмы motorola (коэффициент упаковки ~3.5, что для модемов V.34 может довести скорость обмена до 100кбит/с).

    Ниже приведена таблица основных протоколов детектирования ошибок и сжатия информации, все протоколы mnp совместимы снизу вверх. При установлении связи между модемами используется наивысший протокол, поддерживаемый с обеих сторон канала.

    Таблица 4.3.7.2. Протоколы mnp

    MNP-1

    Асинхронная полудуплексная передача данных с побайтовой организацией. Эффективность 70% (2400Кбит/с -> 1680Кбит/c).

    MNP-2

    Асинхронная дуплексная передача данных с побайтовой организацией. Эффективность 84% (2400кбит/с -> 2000кбит/c)

    MNP-3

    Синхронная дуплексная передача данных с побитовой организацией. Эффективность 108%.

    MNP-4

    Адаптивная сборка передаваемых блоков (вариация размера блока) и оптимизация фазы. Эффективность 120%

    MNP-5

    Помимо новшеств MNP-4 применено сжатие данных. Эффективность 200%. Используется только совместно с MNP-2-4

    MNP-6

    Снабжен адаптивностью скорости передачи, рассчитан на работу до 9.6кбит/с. Имеется возможность автоматического переключения из дуплексного режима в полудуплексный и обратно с учетом ситуации

    MNP-7

    Усовершенствованный алгоритм сжатия данных. Эффективность до 300%.

    MNP-8,9

    Еще более мощные алгоритмы сжатия

    MNP-10

    Протокол, ориентированный на работу в сетях с высоким уровнем шумов (сотовые сети, сельские и междугородние линии), надежность достигается благодаря многократным попыткам установить связь, вариации размера пакета и подстройки скорости передачи

    Рис. 4.3.7.2 Схема подключения модема

    Модем подключается к ЭВМ (см. рис. 4.3.7.2) через последовательный интерфейс RS-232c (существуют версии модемов, способных работать и с параллельным интерфейсом, который обладает почти в 3 раза большим быстродействием). Ниже в таблице представлена разводка для 9- и 25- контактных разъемов (таблица 4.3.7.3), используемых для последовательных интерфейсов (синхронные модемы используют только 25-контактный разъем).

    Таблица 4.3.7.3. Разводка стандартных разъемов модема

    Сигнал

    Номер контакта (db-9)

    Номер контакта (db-25)

    Назначение

    DCD

    1

    8

    Несущая обнаружена (data carrier detected)

    RXD

    2

    2

    Передача данных от DCE к DTE(received data)

    TXD

    3

    3

    Передача данных от DTE к DCE(transmit data)

    DTR

    4

    20

    Данные для передачи готовы (data transfer ready )

    GND

    5

    7

    Земляной контакт

    DSR

    6

    6

    Готовность dce к работе (data set ready)

    RTS

    7

    4

    Готовность DTE к передаче (request to send)

    CTS

    8

    5

    Готовность DCE к передаче (clear to send)

    RI

    9

    22

    Индикатор звонка (ring indicator)

    В персональных ЭВМ может быть 2 или 4 последовательных портов (интерфейсов), которые имеют логические имена COM1-COM4, им соответствуют следующие прерывания и адреса:

    COM1,3

    IRQ4

    0x3f8

    COM2,4

    IRQ3

    0x2f8

    К телефонной сети модем подключается с помощью 6-х контактного разъема RJ11 (используется 4 контакта).

    Модем может находиться в режиме данных (режим по умолчанию) и в командном режиме. Последний используется для реконфигурации модема и подготовки его к работе. Реконфигурация и управление возможны из локальной ЭВМ через последовательный порт, с передней панели модема, или при установленной связи через удаленный модем, если такой режим поддерживается. Переключение в командный режим производится с помощью ESC-последовательности (по умолчанию это три символа "+" с предшествующей и последующей секундной паузой).

    При использовании большого числа модемов они для удобства обслуживания объединяются в группы (пулы). Модемный пул представляет в себя стандартный каркас, где размещается какое-то количество бескорпусных модемов. На передней панели находится, как правило, только индикация, выходы в телефонную сеть и разъемы последовательного интерфейса подключаются через заднюю панель. Такой пул содержит в себе обычно управляющий процессор. Так как в настоящее время не существует стандартов на организацию модемных пулов, они ориентированы на использование модемов только определенной фирмы. К пулу может подключаться дисплей, который отображает текущее состояние всех модемов. Процессор может контролировать состояние модемов, устанавливать их режим работы, а в некоторых случаях и выполнять функцию маршрутизатора, управляя встроенным многоканальным, последовательным интерфейсом. В последнем случае такой пул подключается непосредственно к локальной сети (например, Ethernet), а не к ЭВМ. Пул позволяет предотвращать "повисание" и отключение телефонных линий, что заметно повышает надежность системы. Некоторые модемы (например, фирмы Penril) имеют независимые узкополосные (~300 бит/с), дополнительные каналы для дистанционного управления. Такие каналы обладают повышенной устойчивостью, что позволяет сохранять целостность системы даже при временных отключеньях электропитания.

    Таблица 4.3.7.4. Протоколы передачи файлов

    xmodem

    Протокол (1977г, В. Кристенсен для ОС CP/M). Алгоритм:
    • принимающая ЭВМ посылает символ NAK (ASCII 021)
    • передающая ЭВМ посылает блок информации
    • принимающая ЭВМ проверяет контрольную сумму и, если все в порядке, посылает код ASCII 06 (ACK), в противном случае NAK
    • далее следует повтор передачи при ошибке или посылка следующего блока данных при успехе. Формат блока данных: номер пакета, 128 байт данных и 2 байта контрольной суммы. В Xmodem на принимающей стороне приходится вручную указывать имя файла

    Kermit

    Наиболее распространенный протокол, использующий блоки переменной длины с максимальным размером 94 байта (программы написаны на Си или ФОРТРАН). Является пакетным протоколом, позволяя пересылать за один раз несколько файлов, для повышения эффективности пересылки использует предварительную архивацию и коррекцию ошибок (Колумбийский университет, 1981г.).

    Modem7

    Усовершенствованная версия xmodem для работы по коммутируемым телефонным каналам (передается имя файла).

    Xmodem/1024

    Разновидность Xmodem с размером блока данных 1024 байта.

    Xmodem/CRC

    Разновидность xmodem, использующая 16 битовую crc.

    Telink

    Передается кроме имени файла, дата, время, можно передать несколько файлов за одну сессию.

    Практически все выше перечисленные протоколы устарели.

    Ymodem

    Протокол использует CRC-16, передает имена файлов, размер, дату создания и время, в зависимости от условий передачи размер блока варьируется от 128 до 1024 байт (Чак Форсберг, 1984-85).

    Sealink

    Модификация протокола ymodem.

    Zmodem

    Протокол использует CRC-32 (или CRC-16), динамическое изменение размера блока (32-1024 байта), автоматический выбор протокола обмена, сжатие файлов при пересылке, возобновление передачи с прерванного места в случае разрыва связи. На сегодня это самый совершенный протокол.

    Передача файлов возможна с использованием терминальной программы, это особенно полезно для удаленных терминалов, не поддерживающих протоколы TCP/IP. Терминальные программы используют один из перечисленных выше протоколов, например, Zmodem. В качестве терминальной программы можно воспользоваться одной из: Term95 (Norton commander 5.0), Bitcom, Teleview, Telix, procomm plus (для DOS и Windows), Mtez, MTE, Zstem-240, Pctalk, Crosstalk (эта и следующие для Windows), Dataline, Hyperaccess.

    Чтобы обеспечить безопасность и исключить несанкционированный доступ к сети, можно воспользоваться методом "обратного телефонного вызова", некоторые модемы реализуют его аппаратно. Метод предполагает, что после установления связи и проверки авторизации связь прерывается, а входной модем сети производит набор номера клиента, который хранится в памяти, и устанавливает связь повторно. Такая схема исключает передачу входного пароля друзьям или знакомым, так как это становится бессмысленным - модем будет пытаться установить связь по номеру вашего домашнего телефона.

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

    MR

    Модем включен и готов к работе (modem ready);

    TR

    "Терминал готов" (terminal ready) - включается, когда модем обнаруживает сигнал tdr (data terminal ready), передаваемый вашим программным обеспечением;

    HS

    Индикатор включается, когда модем работает на максимальной для него скорости (high speed).

    CD

    Обнаружен несущий сигнал (carrier detected), гаснет лишь тогда, когда "партнер положит трубку";

    AA

    Модем включен в режим авто-ответа (auto answer);

    OH

    Модем занял линию - "трубка снята" (off-hook);

    RD

    Индикатор мигает (receive data), когда ЭВМ принимает данные из своего модема.

    SD

    Индикатор (send data) мигает при передаче данных из ЭВМ в модем.

    RL

    Индикатор (reliable link) указывает на то, что модем договорился с партнером о типе протокола MNP.

    RD

    Принимаются данные (receive data). Индикатор мигает при передаче данных в ЭВМ.

    TS

    Модем находится в режиме самотестирования.

    PWR

    Включено питание модема.

    В современных ЭВМ имеется возможность совместить функции модема и факс-аппарата. Для решения этой задачи используются так называемые факс-модемы. Эти приборы работают в полудуплексном режиме. Ниже перечислены протоколы, используемые в этих аппаратах (кроме протоколов передачи данных факс-модемы поддерживают стандарты T.4 и T.30):

    V.17

    9.6 или 14.4 Кбит/с

    V.21

    200 бит/с (используется только на этапе установления связи)

    V.27ter

    2.4 или 4.8 Кбит/с

    V.29

    7.2 или 9.6 Кбит/с

    V.527ter

    2400 или 4800 бит/с

    Для обеспечения работы факс-модема пригодны программы: Bitfax, Winfax, Quicklink или любая другая, поставляемая вместе с приобретенным вами модемом. Следует иметь в виду, что для пересылки через факс-модем традиционного документа, подготовленного на типографском бланке, написанного от руки и т.д., вам потребуется сканнер. В перспективе факс-технология будет вытеснена электронной почтой, которая эффективнее и, при необходимости, может обеспечить большую безопасность.

    В настоящее время технология модемов продолжает развиваться, появились и активно внедряются кабельные модемы, много усилий тратится на развитие ADSL (см. http://www.adsl.com/general_tutorial.html (asymmetric digital subscriber line), SDSL (single line digital subscriber line), hdsl (high data rate digital subscriber line), VDSL (very high data rate digital subscriber line) и некоторых других технологий, связанных с передачей мультимедиа данных. (См. XDSL. atg's communications & networking technology guide series. pairgain, copperoptics company; http://www.techguide.com/). Эти технологии предназначены для обеспечения широкополосного канала между провайдером и конечным пользователем (проблема последней мили). [Должен заметить, что миля мера иностранная и российским 1,853 км, если речь идет о телефонных кабелях, не соответствует. Провода у нас другого качества и наша миля как бы длиннее, если судить по искажениям сигнала и шумам]. Здесь используются три метода модуляции (2B1Q, CAP и DMT). ADSL позволяет приспособить обычные телефонные линии для мультимедийных приложений и для высокоскоростной передачи данных (до 6 Мбит/с). Два ADSL-модема, соединенные скрученной парой проводов образуют три информационных канала: скоростной однонаправленный (нисходящий) канал (1,5-6,1 Мбит/с), среднескоростной дуплексный канал (16-640 Кбит/с) и POTS-канал (plain old telephone service). POTS сохраняет работоспособность даже при отказе ADSL. Каждый из этих каналов может мультиплексироваться, образуя каналы меньшего быстродействия. ADSL-модемы могут работать и с ATM-сетями, но следует учитывать их принципиальную асимметричность - передача в одном направлении и в другом имеет разную скорость. Для передачи данных в сети Интернет это не удобно. Но для транспортировки телевизионного сигнала такая схема представляется вполне эффективной.

    Для провода длиной 5,5 км при диаметре сечения 0,5 мм (стандартные условия для isdn) пропускная способность составляет 1,5 - 2,0 Мбит/с (верхний край полосы пропускания около 1 МГц). При организации дуплексного канала весь частотный диапазон делится пополам и одна из частей используется для передачи данных в одном направлении, другая - в противоположном. Каждый из частотных диапазонов в свою очередь делится на части и для каждой из них используется техника эхо-подавления. Для POTS-канала выделяется 4 кГц в низкочастотной части диапазона.

    HDSL представляет собой способ передачи потоков T1 или E1 по скрученным парам проводов с использованием улучшенной техники модуляции (для передачи 1,544-2,048 Мбит/с достаточно полосы 80-240 кГц). SDSL представляет собой версию HDSL с одной скрученной парой. Ниже в таблице 4.3.7.5 приведены сравнительные данные для различных систем передачи информации.

    Таблица 4.3.7.5. Свойства различных систем (модемов) передачи информации.

    Название

    Расшифровка

    Длина канала при 24 awg (0,5мм)

    Быстродействие

    Применение

    V.22
    V.32
    V.34

    Модемы голосового диапазона

    12 км

    1200 бит/c
    28800 бит/c

    Передача данных

    DSL

    digital subscriber line

    5,4 км

    160 Кбит/с

    Услуги ISDN, передача данных и голоса

    HDSL

    high data rate digital subscriber line

    3,6 км

    1,544 Мбит/с
    2,048 Мбит/с

    t1/e1 каналы, локальные и региональные сети.

    SDSL

    single line digital subscriber line

    -

    1,544 Мбит/с
    2,048 Мбит/с

    t1/e1 каналы, локальные и региональные сети

    ADSL

    asymmetric digital subscriber line

    3,6/5,4 км

    1,5-9 Мбит/с или
    16-640 Кбит/c

    Доступ к Интернет, видео, интерактивное мультимедиа.

    VDSL

    very high data rate digital subscriber line

    -

    13-52 Мбит/с или
    1,5-2,3 Мбит/с

    То же, что и ADSL плюс HDTV

    Верхние значения в третей колонке для ADSL и VDSL соответствуют нисходящему (асимметричный канал) и дуплексному потокам. HDTV - телевидение высокого разрешения.

    Рис. 4.3.7.3. Ограничения пропускной способности для разных типов канала

    DSL представляет собой канал ISDN-BRI (Basic Rate Interface; 2*64 + 16 Кбит/c), совместимый с POTS, ISDN и DDS. На рис. 4.3.7.3 показаны области применимости различных канальных технологий.

    • Для 5 Мбит/с при симметричной нагрузке можно работать до расстояний 1500 м (VDSL).
    • Для 10 Мбит/с при симметричной нагрузке можно работать до расстояний 1200 м.
    • Для 15 Мбит/с при симметричной нагрузке можно работать до расстояний 1000 м.

    Метод модуляции 2B1Q характеризуется четырьмя уровнями амплитудной модуляции (4-PAM; +3, +1, -1 и -3). CAP-модуляция (Carrierless Amplitude and Phase) характеризуется четырьмя уровнями амплитуды и четырьмя фиксированными значениями фазы, что дает в плоскости амплитуда-фаза 16 независимых состояний. DTM-модуляция (Discrete Multi-tone) предполагает использование нескольких смежных, узких частотных диапазонов. На рис. 4.3.7.2 показана схема подключения оборудования ADSL для различных оконечных терминалов.

    Рис. 4.3.7.4. Схема подключения оборудования ADSL (IF - ADSL/Ethernet интерфейс)

    В качестве внешней сети на рис. 4.3.7.4 может использоваться практически любая достаточно быстродействующая среда, например ATM. Выбор того или иного внешнего канала зависит от стоящей задачи. Так файл размером 30 Кбайт (среднего размера электронное сообщение) будет передан через модем V.34 за 8,3 сек, по каналу ISDN - за 1,9 сек, по каналу HDSL - за 0,16 сек, а по каналу VDSL - быстрее 0,04 сек. В большинстве случаев вполне приемлемым можно считать уже первые два варианта. Деловой электронный документ имеет размер порядка 250 Кбайт. Здесь для пересылки его указанными способами потребуется уже, соответственно: 69,4; 15,6; 1,3 и 0,3 секунды. Более чем минутное время доставки (в реальности это обычно больше) в некоторых случаях не будет признано удовлетворительным. Время пересылки рентгенограммы (~5 Мбайт) будет пропорционально больше (23 мин, 5,2 мин, 26 сек и 6,5 сек). Считается, что приемлемым временем отклика на команду следует считать 3 секунды, а до 80% трафика локальной сети составляет внешний поток данных. Если же стоит задача организации видеоконференции (384 Кбит/с), то решение проблемы возможно уже только с использованием каналов xDSL. Учитывая стремительный рост потребной пропускной способности каналов, не трудно предсказать перспективность внедрения технологии xDSL.

    Пример использования модема ADSL для подключения телевизора и модема к широкополосному каналу представлен на рис. 4.3.7.5. Управляющий канал на 16 кбит/с может использоваться для целей интерактивного телевидения (смотри раздел "Методы преобразования и передачи изображения").

    Рис. 4.3.7.5. Схема подключения телевизора и телефона через модем ADSL

    Previous: 4.3.6 Синхронные каналы SDH/SONET    UP: 4.3 Региональные сети
    Down: 4.4 Интернет    Next: 4.4 Интернет


    previous up down next index index
    Previous: 4.4 Интернет    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.1.1 Адресация IPv6

    4.4.1 IP-протокол
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.

    Рис. 4.4.1.1. Формат дейтограммы Интернет

    Поле версия характеризует версию IP-протокола (например, 4 или 6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса слишком тяжелых последствий это не вызовет. Понятно также, что значение поля версия во избежании непредсказуемых последствий должно контролироваться программой. HLEN - длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (HLEN=5, без опций и заполнителя). Поле полная длина определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные. Одно-октетное поле тип сервиса (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей:

    Субполе Приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

    0 Обычный уровень
    1 Приоритетный
    2 Немедленный
    3 Срочный
    4 Экстренный
    5 ceitic/ecp
    6 Межсетевое управление
    7 Сетевое управление

    Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. Так D=1 требует минимальной задержки, T=1 - высокую пропускную способность, R=1 - высокую надежность, а C=1 - низкую стоимость. TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP). В таблице 4.4.1.1 приведены рекомендуемые значения TOS.

    Табл. 4.4.1.1. Значения TOS для разных протоколов

    Процедура Минимал. задержка Максим. пропускная способность Максим. надежность Минимал. стоимость Код TOS

    FTP управление

    FTP данные

    1

    0

    0

    0

    0x10

    0

    1

    0

    0

    0x08

    TFTP

    1

    0

    0

    0

    0x10

    DNS

    UDP

    tcp

    1

    0

    0

    0

    0

    0

    0

    0

    0x10

    0

    0

    0

    0

    0x00

    telnet

    1

    0

    0

    0

    0x10

    ICMP

    0

    0

    0

    0

    0x00

    IGP

    0

    0

    1

    0

    0x04

    SMTP управление

    SMTP данные

    1

    0

    0

    0

    0x10

    0

    1

    0

    0

    0x08

    SNMP

    0

    0

    1

    0

    0x04

    NNTP

    0

    0

    0

    1

    0x02

    Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) - надежность.

    До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 4.4.1.1a. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).


    Рис. 4.4.1.1a. Формат поля DSCP.

    Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.

    Селектор класса DSCP
    Приоритет 1 001000
    Приоритет 2 010000
    Приоритет 3 011000
    Приоритет 4 100000
    Приоритет 5 101000
    Приоритет 6 110000
    Приоритет 7 111000

    На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

    Маршрут транспортировки IP-дейтограммы нельзя знать заранее, это связано с поэтапным (по-шаговом) принятием решения о пути каждого пакета. Это свойство маршрутизации обусловлено тем, что IP является протоколом передачи данных без установления соединения.

    Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset) управляют процессом фрагментации и последующей "сборки" дейтограммы. Идентификатор представляет собой уникальный код дейтограммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтограмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 - фрагментация разрешена; 1 - запрещена), бит 2 определяет, является ли данный фрагмент последним (0 - последний фрагмент; 1 - следует ожидать продолжения). Поле время жизни (TTL - time to live) задает время жизни дейтограммы в секундах, т.е. предельно допустимое время пребывания дейтограммы в системе. При каждой обработке дейтограммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтограмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет структуру поля данные (см. табл. 4.4.1.2).

    Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтограммы. Поле опции не обязательно присутствует в каждой дейтограмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, используется заполнитель. Структура октета кода опции отражена на рис. 4.4.1.2.

    Таблица 4.4.1.2. Коды протоколов Интернет

    Код протокола Интернет Сокращенное название протокола Описание

    0

    -

    Зарезервировано

    1

    ICMP

    Протокол контрольных сообщений [rfc792]

    2

    IGMP

    Групповой протокол управления [rfc1112]

    3

    GGP

    Протокол маршрутизатор-маршрутизатор [RFC-823]

    4

    IP

    IP поверх IP (инкапсуляция/туннели)

    5

    ST

    Поток [rfc1190]

    6

    TCP

    Протокол управления передачей [RFC-793]

    7

    UCL

    UCL

    8

    EGP

    Протокол внешней маршрутизации [RFC-888]

    9

    IGP

    Протокол внутренней маршрутизации

    10

    BBN-MON

    BBN-RCC мониторирование

    11

    NVP-II

    Сетевой протокол для голосовой связи [RFC-741]

    12

    PUP

    PUP

    13

    ARGUS

    argus

    14

    Emcon

    emcon

    15

    Xnet

    Перекрестный сетевой отладчик [IEN158]

    16

    Chaos

    Chaos

    17

    UDP

    Протокол дейтограмм пользователя [RFC-768]

    18

    MUX

    Мультиплексирование [IEN90]

    19

    DCN-MEAS

    DCN измерительные субсистемы

    20

    HMP

    Протокол мониторирования ЭВМ (host [RFC-869])

    21

    PRM

    Мониторирование при передаче пакетов по радио

    22

    XNS-IDP

    Xerox NS IDP

    23

    Trunk-1

    Trunk-1

    24

    Trank-2

    Trunk-2

    25

    Leaf-1

    Leaf-1

    26

    Leaf-2

    Leaf-2

    27

    RDP

    Протокол для надежной передачи данных [RFC-908]

    28

    IRTP

    Надежный TP для Интернет [RFC-938]

    29

    ISO-TP4

    iso транспортный класс 4 [RFC-905]

    30

    Netblt

    Массовая передача данных [RFC-969]

    31

    MFE-NSP

    Сетевая служба MFE

    32

    Merit-INP

    Межузловой протокол Merit

    33

    SEP

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

    34

    не определен

    35

    IDRP

    Междоменный протокол маршрутизации

    36

    XTP

    Xpress транспортный протокол

    37

    DDP

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

    38

    IDPR-CMTP

    IDPR передача управляющих сообщений

    39

    TP++

    TP++ транспортный протокол

    40

    IL

    IL-транспортный протокол

    41

    SIP

    Простой Интернет-протокол

    42

    SDRP

    Протокол маршрутных запросов для отправителя

    43

    SIP-SR

    SIP исходный маршрут

    44

    SIP-Frag

    SIP-фрагмент

    45

    IDRP

    Интер-доменный маршрутный протокол

    46

    RSVP

    Протокол резервирования ресурсов канала

    47

    GRE

    Общая инкапсуляция маршрутов

    49

    BNA

    BNA

    50

    SIPP-ESP

    SIPP ESЗ

    52

    I-NLSP

    Интегрированная система безопасности сетевого уровня

    53

    Swipe

    IP с кодированием

    54

    NHRP

    nbma протокол определения следующего шага

    55-60

    не определены

    61

    Любой внутренний протокол ЭВМ

    62

    CFTP

    CFTP

    63

    Любая локальная сеть

    64

    Sat-Expak

    Satnet и Expak

    65

    MIT-Subn

    Поддержка субсетей MIT

    66

    RVD

    Удаленный виртуальный диск MIT

    67

    IPPC

    IPPC

    68

    Любая распределенная файловая система

    69

    Sat-Mon

    Мониторирование Satnet

    70

    не определен

    71

    IPCV

    Базовая пакетная утилита

    75

    PVP

    Пакетный видео-протокол

    76

    BRsat-Mon

    Резервное мониторирование Satnet

    78

    Wb-mon

    Мониторирование Expak

    79

    Wb-expak

    Широкополосная версия Expak

    80

    ISO-IP

    iso Интернет протокол

    88

    IGRP

    IGRP (Cisco) - внутренний протокол маршрутизации

    89

    OSPFIGP

    OSPFIGP - внутренний протокол маршрутизации

    92

    MTP

    Транспортный протокол мультикастинга

    101-254

    не определены

    255

    зарезервировано

    Рис. 4.4.1.2. Формат описания опций

    Флаг копия равный 1 говорит о том, что опция должна быть скопирована во все фрагменты дейтограммы. При равенстве этого флага 0 опция копируется только в первый фрагмент. Ниже приведены значения разрядов 2-битового поля класс опции:

    Значение поля класс опции Описание

    0

    Дейтограмма пользователя или сетевое управление

    1

    Зарезервировано для будущего использования

    2

    Отладка и измерения (диагностика)

    3

    Зарезервировано для будущего использования

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

    Класс опции

    Номер опции

    Длина описания

    Назначение

    0

    0

    -

    Конец списка опций. Используется, если опции не укладываются в поле заголовка (смотри также поле "заполнитель")

    0

    1

    -

    Никаких операций (используется для выравнивания октетов в списке опций)

    0

    2

    11

    Ограничения,связанные с секретностью (для военных приложений)

    0

    3

    *

    Свободная маршрутизация. Используется для того, чтобы направить дейтограмму по заданному маршруту

    0

    7

    *

    Запись маршрута. Используется для трассировки

    0

    8

    4

    Идентификатор потока. Устарело.

    0

    9

    *

    Жесткая маршрутизация. Используется, чтобы направить дейтограмму по заданному маршруту

    2

    4

    *

    Временная метка Интернет

    * в колонке "длина" - означает - переменная.

    Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут создает дейтограмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, утилита traceroute). Формат опции записать маршрут в дейтограмме представлен ниже на рис. 4.4.1.3:

    Рис. 4.4.1.3 Формат опций записать маршрут

    Поле код содержит номер опции (7 в данном случае). Поле длина определяет размер записи для опций, включая первые 3 октета. Указатель отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса). Интересную возможность представляет опция маршрут отправителя, которая открывает возможность посылать дейтограммы по заданному отправителем маршруту. Это позволяет исследовать различные маршруты, в том числе те, которые недоступны через узловые маршрутизаторы. Существует две формы такой маршрутизации: Свободная маршрутизация и Жесткая маршрутизация. Форматы для этих опций показаны ниже:

    Рис. 4.4.1.3а. Формат опций маршрутизации

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

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

    Просмотр маршрутной таблицы происходит в три этапа:

    1. Ищется полное соответствие адресу места назначения. В случае успеха, пакет посылается соответствующему маршрутизатору или непосредственно интерфейсу адресата. Связи точка-точка выявляются именно на этом этапе.
    2. Ищется соответствие адресу сети места назначения. В случае успеха система действует также как и в предшествующем пункте. Одна запись в таблице маршрутизации соответствует всем ЭВМ, входящим в данную сеть.
    3. Осуществляется поиск маршрута по умолчанию и, если он найден, дейтограмма посылается в соответствующий маршрутизатор.

    Для того чтобы посмотреть, как выглядит простая маршрутная таблица, воспользуемся командой netstat -rn (ЭВМ Sun. Флаг -r выводит на экран маршрутную таблицу, а -n отображает IP-адреса в цифровой форме. С целью экономии места таблица в несколько раз сокращена).

    routing tables destination gateway flags refcnt use interface
    193.124.225.72 193.124.224.60 ughd

    0

    61 le0
    192.148.166.1 193.124.224.60 ughd

    0

    409 le0
    193.124.226.81 193.124.224.37 ughd

    0

    464 le0
    192.160.233.201 193.124.224.33 ughd

    0

    222 le0
    192.148.166.234 193.124.224.60 ughd

    1

    3248 le0
    193.124.225.66 193.124.224.60 ughd

    0

    774 le0
    192.148.166.10 193.124.224.60 ughd

    0

    621 le0
    192.148.166.250 193.124.224.60 ughd

    0

    371 le0
    192.148.166.4 193.124.224.60 ughd

    0

    119 le0
    145.249.16.20 193.124.224.60 ughd

    0

    130478 le0
    192.102.229.14 193.124.224.33 ughd

    0

    13206 le0
    default 193.124.224.33 ug

    9

    5802624 le0
    193.124.224.32 193.124.224.35 u

    6

    1920046 le0
    193.124.134.0 193.124.224.50 ugd

    1

    291672 le0

    Колонка destination - место назначение, Default - отмечает маршрут по умолчанию; Gateway - IP-адреса портов подключения (маршрутизаторов); REFCNT (reference count) - число активных пользователей маршрута; USE - число пакетов, посланных по этому маршруту; interface - условные имена сетевых интерфейсов. Расшифровка поля FLAGS приведено ниже:

    u Маршрут работает (up).

    g

    Путь к маршрутизатору (gateway), если этот флаг отсутствует, адресат доступен непосредственно.

    h

    Маршрут к ЭВМ (host), адрес места назначения является полным адресом этой ЭВМ (адрес сети + адрес ЭВМ). Если флаг отсутствует, маршрут ведет к сети, а адрес места назначения является адресом сети.

    d Маршрут возник в результате переадресации.
    m Маршрут был модифицирован с помощью переадресации.

    Опция временные метки работает также как и опция запись маршрута. Каждый маршрутизатор на пути дейтограммы делает запись в одном из полей дейтограммы (два слова по 32 разряда; смотри раздел 4.4.15). Формат этой опции отображен на рисунке 4.4.1.4.

    Рис. 4.4.1.4 Формат опции "временные метки"

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

    Таблица 4.4.1.3.

    Значение флага

    Назначение

    0

    Записать только временные метки; опустить ip-адреса.

    1

    Записать перед каждой временной меткой ip-адрес (как в формате на предыдущем рисунке).

    3

    ip-адреса задаются отправителем; маршрутизатор записывает только временные метки, если очередной IP-адрес совпадает с адресом маршрутизатора

    Временные метки должны содержать время в миллисекундах, отсчитанное от начала суток.

    Взаимодействие других протоколов с IP можно представить из схемы на рис. 4.4.1.5. В основании лежат протоколы, обеспечивающие обмен информацией на физическом уровне, далее следуют протоколы IP, ICMP, ARP, RARP, IGMP и протоколы маршрутизаторов. Чем выше расположен протокол, тем более высокому уровню он соответствует. Протоколы, имена которых записаны в одной и той же строке, соответствуют одному и тому же уровню. Но все разложить аккуратно по слоям невозможно - некоторые протоколы занимают промежуточное положение, что и отражено на схеме, (области таких протоколов захватывают два уровня. Здесь протоколы IP, ICMP и IGMP помещены на один уровень, для чего имеется не мало причин. Но иногда последние два протокола помещают над IP, так как их пакеты вкладываются в IP-дейтограммы. Так что деление протоколов по уровням довольно условно. На самом верху пирамиды находятся прикладные программы, хотя пользователю доступны и более низкие уровни (например, ICMP), что также отражено на приведенном рисунке (4.4.1.5).

    Рис. 4.4.1.5. Распределение протоколов Интернет по уровням

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

    Previous: 4.4 Интернет    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.1.1 Адресация IPv6


    previous up down next index index
    Previous: 4.4.1 IP-протокол    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.1.2 IP-туннели

    4.4.1.1 Адресация IPv6
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1. Терминология
    2. Формат заголовка IPv6
    3. IP версия 6 архитектуры адресации
    4. Модель адресации
    4.1. Представление записи адресов (текстовое представление адресов)
    4.2. Представление типа адреса
    4.3. Уникастные адреса
    4.3.1. Примеры уникастных адресов
    4.4. Неспецифицированный адрес
    4.5. Адрес обратной связи
    4.6. IPv6 адреса с вложенными IPv4 адресами
    4.7. NSAP адреса
    4.8. IPX Адреса
    4.9. Провайдерские глобальные уникаст-адреса
    4.10. Локальные уникаст-адреса IPv6
    4.11. Эникаст-адреса
    4.12. Мульткаст-адреса
    4.12.1. Предопределенные мультикаст-адреса
    4.13. Необходимые адреса узлов
    5. Заголовки расширения IPv6
    5.1. Порядок заголовков расширения
    6. Опции
    6.1. Опции заголовка hop-by-hop (шаг за шагом)
    7. Маршрутный заголовок
    8. Заголовок фрагмента

    9.

    Заголовок опций места назначения

    10. Отсутствие следующего заголовка
    11. О размере пакетов
    12. Метки потоков
    13. Приоритет
    14. О протоколе верхнего уровня
    14.1 Контрольные суммы верхнего уровня
    15. Максимальное время жизни пакета
    16. Максимальный размер поля данных для протоколов высокого уровня
    17. Приложение A. Рекомендации по формированию опций
    18. Соображения безопасности
    19. Расширение DNS для поддержки IP версии 6
    19.1. Определение новой ресурсной записи и домена
    19.2. Модификации существующих типов запроса

    20.

    Протокол управляющих сообщений (ICMPv6) для спецификации IPv6

    20.1. ICMPv6 (ICMP для IPv6)
    20.2. Общий формат сообщений
    20.3. Сообщения об ошибках ICMPv6
    20.4. Информационные сообщения icmpv6

    В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: "TCP and UDP with Bigger Addresses (TUBA)"; "Common Architecture for the Internet (CatnIP)" и "Simple Internet Protocol Plus (SIPP) [смотри "Протоколы и ресурсы Интернет" Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

    Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).

    IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера.

    Передача адресного пространства от IANA не является необратимым. Если по мнению IANA распорядитель адресного пространства допустил серьезные ошибки, IANA может аннулировать выполненное ранее выделение.

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

    Оплата за распределение адресов должна использоваться исключительно на деятельность, непосредственно связанную с выделением адресов, поддержанием соответствующих баз данных и т.д. Адресное пространство само по себе не должно стоить ничего.

    Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям.

    IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

    • Расширение адресации

    В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.

    • Спецификация формата заголовков

    Некоторые поля заголовка IPv4 отбрасываются или делаются опционными, уменьшая издержки, связанные с обработкой заголовков пакетов с тем, чтобы уменьшить влияние расширения длины адресов в IPv6.

    • Улучшенная поддержка расширений и опций

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

    • Возможность пометки потоков данных

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

    • Идентификация и защита частных обменов

    В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации.

    Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.

    1. Терминология

    Узел

    Оборудование, использующее IPv6.

    Маршрутизатор

    Узел, который переадресует пакеты ipv6, которые не адресованы ему непосредственно.

    ЭВМ

    Любой узел, который не является маршрутизатором.

    Верхний уровень

    Протокольный уровень, расположенный непосредственно поверх. В качестве примеров можно привести транспортные протоколы TCP и UDP, протокол управления ICMP, маршрутные протоколы типа OSPF (RFC-2740), а также интернетовские или другие протоколы нижнего уровня инкапсулированные в IPv6, например, IPX, Appletalk, или сам IPv6.

    Канал

    Средство коммуникации или среда, через которую узлы могут взаимодействовать друг с другом на связном уровне, т.е., уровень непосредственно под IPv6. Примерами могут служить Ethernet; PPP; X.25, Frame Relay, или ATM; а также Интернет "туннели", такие как туннели поверх IPv4 или IPv6.

    Соседи

    Узлы, подключенные к общему каналу.

    Интерфейс

    Средство подключения узла к каналу.

    Адрес

    Идентификатор IPv6-уровня для интерфейса или набора интерфейсов.

    Пакет

    Заголовок и поле данных IPv6.

    MTU канала

    Максимальный размер пакета в канале

    MTU пути

    Минимальный MTU канала для пути от узла источника до получателя.

    Эникастный адрес

    Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по такому адресу, доставляется ближайшему интерфейсу (согласно метрики маршрутного протокола) из числа идентифицированных этим адресом.

    Замечание: допустимо (хотя и необычно), что устройство с несколькими интерфейсами может быть сконфигурировано для переадресации пакетов, приходящих через один или несколько интерфейсов. Пакеты, приходящие через остальные интерфейсы, могут при этом отбрасываться. Такие устройства должны выполнять требования протоколов маршрутизации. При получении пакетов, адресованных этому устройству, оно должно вести себя как обычная ЭВМ.

    2. Формат заголовка IPv6

    Рис. 4.4.1.1.1. Формат заголовка пакета IPv6

    Версия

    4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6)

    Приор.

    4-битный код приоритета

    Метка потока

    24-битный код метки потока (для мультимедиа)

    Размер поля данных

    16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций.

    Следующий заголовок

    8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700].

    Предельное число шагов

    8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется.

    Адрес отправителя

    128-битовый адрес отправителя пакета. См. RFC-1884.

    Адрес получателя

    128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884.

    В документе RFC-2460, который появился спустя три года после RFC-1883, поле приоритет заменено на поле класс трафика . Это поле имеет 8 бит (против 4 в поле приоритет). При этом размер поля метка потока сократился до 20 бит. Это было продиктовано требованиями документа RFC-2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", ориентированного на решение задач управления QoS.

    3. IP версия 6 архитектуры адресации

    Существует три типа адресов:

    unicast:

    Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе.

    anycast:

    Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации).

    multicast:

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

    В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам.

    В IPv6, все нули и все единицы являются допустимыми кодами для любых полей, если не оговорено исключение.

    4. Модель адресации

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

    IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:

    1. Одиночный адрес может приписываться нескольким физическим интерфейсам, если приложение рассматривает эти несколько интерфейсов как единое целое при представлении его на уровне Интернет.
    2. Маршрутизаторы могут иметь ненумерованные интерфейсы (например, интерфейсу не присваивается никакого IPv6 адреса) для соединений точка-точка, чтобы исключить необходимость вручную конфигурировать и объявлять (advertise) эти адреса. Адреса не нужны для соединений точка-точка маршрутизаторов, если эти интерфейсы не используются в качестве точки отправления или назначения при посылке IPv6 дейтограмм. Маршрутизация здесь осуществляется по схеме близкой к используемой протоколом CIDR в IPv4.

    IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей.

    4.1. Представление записи адресов (текстовое представление адресов)

    Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк:

    1. Основная форма имеет вид x:x:x:x:x:x:x:x, где 'x' шестнадцатеричные 16-битовые числа.
    2. Примеры:

      fedc:ba98:7654:3210:FEDC:BA98:7654:3210
      1080:0:0:0:8:800:200C:417A

      Заметьте, что ненужно писать начальные нули в каждом из конкретных полей, но в каждом поле должна быть, по крайней мере, одна цифра (за исключением случая, описанного в пункте 2.).

    3. Из-за метода записи некоторых типов IPv6 адресов, они часто содержат длинные последовательности нулевых бит. Для того чтобы сделать запись адресов, содержащих нулевые биты, более удобной, имеется специальный синтаксис для удаления лишних нулей. Использование записи "::" указывает на наличие групп из 16 нулевых бит. Комбинация "::" может появляться только при записи адреса. Последовательность "::" может также использоваться для удаления из записи начальных или завершающих нулей в адресе. Например:
    4. 1080:0:0:0:8:800:200c:417a уникаст-адрес
      ff01:0:0:0:0:0:0:43 мультикаст адрес
      0:0:0:0:0:0:0:1 адрес обратной связи
      0:0:0:0:0:0:0:0 неспецифицированный адрес

      может быть представлено в виде:

      1080::8:800:200c:417a уникаст-адрес
      ff01::43 мультикаст адрес
      ::1 адрес обратной связи
      :: не специфицированный адрес
    5. Альтернативной формой записи, которая более удобна при работе с ipv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где 'x' шестнадцатеричные 16-битовые коды адреса, а 'd' десятичные 8-битовые, составляющие младшую часть адреса (стандартное IPv4 представление). Например:

    0:0:0:0:0:0:13.1.68.3
    0:0:0:0:0:FFFF:129.144.52.38

    или в сжатом виде:

    ::13.1.68.3
    ::FFFF:129.144.52.38

    4.2. Представление типа адреса

    Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix - FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1.1):

    Таблица 4.4.1.1.1

    Назначение Префикс (двоичный) Часть адресного пространства
    Зарезервировано

    0000 0000

    1/256

    Не определено

    0000 0001

    1/256

    Зарезервировано для NSAP

    0000 001

    1/128

    Зарезервировано для IPX

    0000 010

    1/128

    Не определено

    0000 011

    1/128

    Не определено

    0000 1

    1/32

    Не определено

    0001

    1/16

    Не определено

    001

    1/8

    Провайдерские уникаст-адреса

    010

    1/8

    Не определено

    011

    1/8

    Зарезервировано для географических уникаст-адресов

    100

    1/8

    Не определено

    101

    1/8

    Не определено

    110

    1/8

    Не определено

    1110

    1/16

    Не определено

    1111 0

    1/32

    Не определено

    1111 10

    1/64

    Не определено

    1111 110

    1/128

    Не определено

    1111 1110 0

    1/512

    Локальные канальные адреса

    1111 1110 10

    1/1024

    Локальные адреса (site)

    1111 1110 11

    1/1024

    Мультикаст-адреса

    1111 1111

    1/256

    Замечание: Не специфицированные адреса, адреса обратной связи и IPv6 адреса со встроенными IPv4 адресами, определены вне "0000 0000" префиксного пространства.

    Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы). Пятнадцать процентов адресного пространства уже распределено. Остальные 85% зарезервированы.

    Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного пространства, и синтаксически неотличимы от них.

    4.3. Уникастные адреса

    IPv6 уникастный адреса, сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Class-less InterDomain Routing - CIDR).

    Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Site-local-use адрес, Link-local-use адрес и IPv4-compatible host address. В будущем могут быть определены дополнительные типы адресов.

    Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры. То есть представляет собой 128 битовый неструктурированный образ.

    ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:

    Рис. 4.4.1.1.2

    Более сложные ЭВМ могут использовать и другие иерархические границы в уникастном адресе. Хотя простейшие маршрутизаторы могут не знать о внутренней структуре IPv6 уникастных адресов, маршрутизаторы должны знать об одной или более иерархических границах для обеспечения работы протоколов маршрутизации. Известные границы для разных маршрутизаторов могут отличаться и зависят от того, какое положение занимает данный прибор в иерархии маршрутизации.

    4.3.1. Примеры уникастных адресов

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

    Рис. 4.4.1.1.3

    Где 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 mac адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса не доступны, могут использоваться другие типы адресов связного уровня, такие как E.164 адреса, в качестве идентификаторов интерфейсов.

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

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

    Рис. 4.4.1.1.4

    Эта схема может быть развита с тем, чтобы позволить локальной сети или организации добавлять новые уровни внутренней иерархии. Может быть, желательно использовать идентификатор интерфейса меньше чем 48-разрядный IEEE 802 MAC адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации.

    4.4. Не специфицированный адрес

    Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.

    Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтограмм или в IPv6 заголовках маршрутизации.

    4.5. Адрес обратной связи

    Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться для посылки IPv6 дейтограмм самому себе. Его нельзя использовать в качестве идентификатора интерфейса.

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

    4.6. IPv6 адреса с вложенными IPv4 адресами

    Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 4.4.1.1.5:

    Рис. 4.4.1.1.5

    Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат показанный на рис. 4.4.1.1.6:

    Рис. 4.4.1.1.6

    4.7. NSAP адреса

    Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):

    Рис. 4.4.1.1.7

    4.8. IPX Адреса

    Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:

    Рис. 4.4.1.1.8

    4.9. Провайдерские глобальные уникаст-адреса

    Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 4.4.1.1.9:

    Рис. 4.4.1.1.9. Глобальный адрес провайдера

    Старшая часть адреса предназначена для определения того, кто определяет часть адреса провайдера, подписчика и т.д.

    Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID).

    Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера.

    Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая идентификатор подписчика.

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

    4.10. Локальные уникаст-адреса IPv6

    Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.4.1.1.10:

    Рис. 4.4.1.1.10. Локальный адрес канала

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

    Рис. 4.4.1.1.11. Локальный адрес сети

    Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или "красть" префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика.

    Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя.

    4.11. Эникаст-адреса

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

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

    Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен, как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p.

    Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим.

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

    Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:

    • Эникастный адрес не может использоваться в качестве адреса отправителя в ipv6 пакете.
    • Эникастный адрес не может быть приписан ЭВМ IPv6, таким образом, он может принадлежать только маршрутизатору.

    4.11.1. Необходимые эникаст-адреса

    Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:

    Рис. 4.4.1.1.12

    Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю.

    Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.

    Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети. Например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его "домашней" субсети.

    4.12. Мульткаст-адреса

    Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.4.1.1.13):

    Рис. 4.4.1.1.13

    11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.

    Рис. 4.4.1.1.14

    Старшие 3 флага зарезервированы и должны быть обнулены.

    t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет.

    T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient").

    Поле scope представляет собой 4-битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения:

    0 зарезервировано
    1 Область действия ограничена локальным узлом
    2 Область действия ограничена локальным каналом
    3 (не определено)
    4 (не определено)
    5 Область действия ограничена локальной сетью
    6 (не определено)
    7 (не определено)
    8 Область действия ограничена локальной организацией
    9 (не определено)
    A (не определено)
    B (не определено)
    C (не определено)
    D (не определено)
    E глобальные пределы (global scope)
    F зарезервировано

    Идентификатор группы идентифицирует мультикастинг-группы, постоянной или переходной (transient), в пределах заданных ограничений (scope).

    Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда:

    ff01:0:0:0:0:0:0:43 означает, что все ntp серверы одного и того же узла рассматриваются как отправители.
    FF02:0:0:0:0:0:0:43 означает, что все NTP серверы работают с тем же каналом, что и отправитель.
    FF05:0:0:0:0:0:0:43 означает, что все NTP серверы принадлежат той же сети, что и отправитель.
    FF0E:0:0:0:0:0:0:43 означает, что все NTP серверы находятся в Интернет.

    Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID.

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

    4.12.1. Предопределенные мультикаст-адреса

    Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):

    ff00:0:0:0:0:0:0:0
    FF01:0:0:0:0:0:0:0
    FF02:0:0:0:0:0:0:0
    FF03:0:0:0:0:0:0:0
    FF04:0:0:0:0:0:0:0
    FF05:0:0:0:0:0:0:0
    FF06:0:0:0:0:0:0:0
    FF07:0:0:0:0:0:0:0
    FF08:0:0:0:0:0:0:0
    FF09:0:0:0:0:0:0:0
    FF0A:0:0:0:0:0:0:0
    FF0B:0:0:0:0:0:0:0
    FF0C:0:0:0:0:0:0:0
    FF0D:0:0:0:0:0:0:0
    FF0E:0:0:0:0:0:0:0
    FF0F:0:0:0:0:0:0:0

    Перечисленные выше мультикаст-адреса зарезервированы и не будут присваиваться каким-либо мультикаст-группам.

    Адреса для обращения ко всем узлам:

    FF01:0:0:0:0:0:0:1
    FF02:0:0:0:0:0:0:1

    Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы).

    Адреса всех маршрутизаторов:

    FF01:0:0:0:0:0:0:2
    FF02:0:0:0:0:0:0:2

    Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).

    DHCP server/relay-agent: FF02:0:0:0:0:0:0:C

    Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).

    Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx

    Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:

    ff02:0:0:0:0:1:0000:0000
    до
    FF02:0:0:0:0:1:FFFF:FFFF

    Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.

    4.13. Необходимые адреса узлов

    ЭВМ должна распознавать следующие адреса, как обращенные к нему:

    • Её локальный адрес канала для каждого из интерфейсов
    • Выделенные уникаст-адреса
    • Адрес обратной связи
    • Мультикастинг-адрес для обращения ко всем узлам
    • Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов
    • Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.

    Маршрутизатор должен распознавать следующие адреса (as identifying itself):

    • Его локальный адрес канала для каждого из интерфейсов
    • Выделенные уникаст-адреса
    • Адрес обратной связи
    • Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.
    • Все другие эникастные адреса, которые использовались при маршрутизации.
    • Мультикастинг-адрес для обращения ко всем узлам
    • Мультикастинг-адрес для обращения ко всем маршрутизаторам
    • Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.
    • Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.

    Приложение должно предопределить только следующие адресные префиксы:

    • Не специфицированный адрес
    • Адрес обратной связи
    • Мультикаст-префикс (ff)
    • Локально используемые префиксы (link-local и site-local)
    • Предопределенные мультикаст-адреса
    • Префиксы, совместимые с IPv4

    Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса).

    5. Заголовки расширения IPv6

    В IPv6, опционная информация уровня Интернет записывается в отдельных заголовках, которые могут быть помещены между IPv6 заголовком и заголовком верхнего уровня пакета. Существует небольшое число таких заголовков, каждый задается определенным значением кода поля следующий заголовок. В настоящее время определены заголовки: маршрутизации, фрагментации, аутентификации, инкапсуляции, опций hop-by-hop, места назначения и отсутствия следующего заголовка. Как показано в примерах ниже, IPv6 пакет может нести нуль, один, или более заголовков расширения, каждый задается предыдущим полем следующий заголовок (рис. 4.4.1.1.15):

    Рис. 4.4.1.1.15. Структура вложения пакетов для IPv6

    Заголовки расширения не рассматриваются и не обрабатываются узлами по пути доставки. Содержимое и семантика каждого заголовка расширения определяет, следует или нет обрабатывать следующий заголовок. Следовательно, заголовки расширения должны обрабатываться строго в порядке их выкладки в пакете. Получатель, например, не должен просматривать пакет, искать определенный тип заголовка расширения и обрабатывать его до обработки предыдущих заголовков.

    Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути доставки, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок заголовка IPv6.

    Если в результате обработки заголовка узлу необходимо перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered " - встретился нераспознаваемый тип следующего заголовка) и поле - указатель на не узнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка равный нулю в заголовке, отличном от IPv6-заголовка.

    Каждый заголовок расширения имеет длину кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е., поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8.

    IPv6 включает в себя следующие заголовки расширения:

    Опции hop-by-hop
    Маршрутизация (routing;тип 0)
    Фрагмент
    Опции места назначения
    Проверка прав доступа (authentication)
    Поле безопасных вложений (encapsulating security payload)

    Последние два описаны в RFC-1826 и RFC-1827.

    5.1. Порядок заголовков расширения

    Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:

    IPv6 заголовок
    Заголовок опций hop-by-hop
    Заголовок опций места назначения (destination options header, (1) )
    Заголовок маршрутизации
    Заголовок фрагмента
    Заголовок authentication (2)
    Заголовок безопасных вложений (encapsulating security payload, (2) )
    Заголовок опций места назначения (destination options header (3) )
    Заголовок верхнего уровня.

    (1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.

    (2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.

    (3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута.

    Каждый заголовок расширения должен встречаться не более одного раза, исключение представляет собой заголовок опций места назначения, который должен быть представлен дважды (один раз перед заголовком маршрутизации и второй раз перед заголовком верхнего уровня).

    Если заголовок верхнего уровня представляет собой еще один IPv6 заголовок (в случае туннелирования IPv6 или инкапсуляции в IPv6), за ним может следовать его собственный заголовок расширения.

    Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком.

    6. Опции

    Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):

    Рис. 4.4.1.1.16 Формат опций

    Тип опции

    8-битовый идентификатор типа опции.

    Длина опции

    8-битовое целое число без знака. Длина поля данных опции в октетах.

    Данные опции

    Поле переменной длины. Данные зависят от типа опции.

    Последовательность опций в заголовке должна обрабатываться строго в соответствии с их порядком записи.

    Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:

    00

    обойти эту опцию и продолжить обработку заголовка.

    01

    выбросить данный пакет.

    10

    выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции.

    11

    выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции.

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

    0 - Данные опции не меняют маршрута
    1 - Информация опции может изменить маршрут.

    Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:

    2n

    означает любое двухоктетное смещение от начала заголовка.

    8n+2

    означает любое 8-октетное смещение от начала заголовка плюс 2 октета.

    Существует две опции заполнения, которые используются, когда необходимо выровнять последующие опции и вывести границу заголовка на значение кратное 8 октетам. Эти заполняющие опции должны распознаваться всеми приложениями IPv6:

    Опция Pad1 (выравнивание не требуется)

    Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.

    Опция padn (выравнивание не требуется)

    Рис. 4.4.1.1.17

    Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов

    6.1. Опции заголовка Hop-by-Hop (шаг за шагом)

    Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):

    Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop

    Следующий заголовок

    8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком опций hop-by-hop. Использует те же значения поля протоколов, что и IPv4 [RFC-1700]

    HDR EXT LEN

    8-битовое число без знака. Длина заголовка поля опций hop-by-hop в октетах, исключая первые 8 октетов.

    Опции

    Поле переменной длины. Содержит один или более TLV-закодированных опций.

    В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:

    Опция Jumbo Payload

    (необходимо выравнивание: 4n + 2)

    Рис. 4.4.1.1.19.

    Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload.

    Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции.

    Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента.

    Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных).

    7. Маршрутный заголовок

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

    Следующий заголовок

    8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].

    hdr ext len

    8-битовое целое без знака. Длина заголовка маршрутизации выражается в 8-октетных блоках, и не включает в себя первые 8 октетов.

    Тип маршрутизации

    8-битовый идентификатор конкретного варианта маршрутизации

    Оставшиеся сегменты

    8-битовое число без знака. Число остающихся сегментов пути, т.e. число промежуточных узлов, которые должны быть посещены пакетом по пути к месту назначения.

    Данные, зависящие от типа

    Поле переменной длины, формат зависит от кода поля тип маршрутизации, а длина определяется заголовком маршрутизации и кратна 8 октетам.

    Если в процессе обработки входного пакета встретится заголовок маршрутизации с не узнанным полем тип маршрутизации, то поведение узла зависит от содержимого поля число оставшихся сегментов пути.

    1. Если число оставшихся сегментов пути равно нулю, узел должен проигнорировать заголовок маршрутизации и продолжить работу со следующим заголовком, чей тип указан в поле следующий заголовок заголовка маршрутизации.
    2. Если число оставшихся сегментов пути не равно нулю, узел должен выбросить пакет и послать сообщение ICMP (parameter problem, код 0) с указателем на поле не узнанного типа маршрутизации. Заголовок маршрутизации типа 0 имеет следующий формат (рис. 4.4.1.1.20):

    Рис. 4.4.1.1.20. Формат заголовка маршрутизации типа 0

    Следующий заголовок

    8-битовый селектор. Идентифицирует тип заголовка, следующего непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].

    hdr ext len

    8-битовое целое без знака. Длина заголовка маршрутизации в 8-октетных блоках, исключая первые 8 октетов. Для заголовков маршрутизации типа 0 hdr ext len равна удвоенному числу адресов в заголовке, должно быть четным числом меньше или равным 46.

    Тип маршрутизации

    0.

    Оставшиеся сегменты

    8-битовое целое без знака. Число оставшихся сегментов пути, т.e., число узлов, которые следует посетить на пути к месту назначения. Максимально допустимое число = 23

    Резерв

    8-битовое поле резерва. Инициализируется нулем при передаче и игнорируется при приеме.

    strict/loose bit map

    24-битовый код-маска, биты пронумерованы, начиная с 0 до 23, слева направо. Для каждого из сегментов пути указывает должен ли следующий узел быть соседом: 1 означает strict (должен быть соседом), 0 означает пропустить (не должен быть соседом).

    Адрес[1..n]

    Вектор 128-битовых адресов, пронумерованных с 1 до n.

    Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0.

    Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения.

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

    Заголовок маршрутизации не рассматривается и не анализируется до тех пор, пока пакет не достигнет места назначения, указанного в поле IPv6 заголовка. Узел, указанный в поле следующий заголовок заголовка, которому принадлежит модуль заголовка маршрутизации, реализует следующий алгоритм:

    Если оставшееся число сегментов = 0
    { продолжить обработку следующего заголовка пакета, чей тип задан полем следующий заголовок заголовка маршрутизации }

    else если HDR ext len является нечетным или больше 46,
    {посылается сообщение ICMP (parameter problem, код 0) с указателем на поле HDR #EXT LEN, пакет выбрасывается}

    else
    { вычислить n, число адресов в заголовке маршрутизации, для этого код HRD EXT LEN делится на 2

    Если число оставшихся сегментов пути больше n,
    {послать сообщение ICMP (parameter problem, код 0) с указанием на поле числа оставшихся сегментов пути }

    else

    { уменьшить число оставшихся сегментов пути на 1;

    Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n

    Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми

    { выбросить пакет }

    else { поменять местами адрес места назначения IPv6 и адрес[i]

    если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа

    { послать сообщение ICMP destination unreachable -- not a neighbor
    и выбросить пакет }

    else если код IPv6 hop limit меньше или равен 1
    {послать сообщение icmp time exceeded -- hop limit exceeded in transit message и выбросить пакет }

    else { уменьшить hop limit на 1
    повторно направить пакет модулю IPv6 для отправки новому адресату }
    }
    }
    }

    В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения:

    При движении пакетов от S к I1:

    Адрес отправителя = S

    Hdr Ext Len = 6

    Адрес получателя = I1

    Число оставшихся сегментов пути = 3

    Адрес[1] = I2

    Если бит 0 bit map равен 1,
    s и i1 должны быть соседями;
    это проверяется узлом S

    Адрес[2] = I3
    Адрес[3] = d

    При движении пакетов от I1 к I2:

    Адрес отправителя = s

    Hdr Ext Len = 6

    Адрес получателя = I2

    Число оставшихся сегментов пути = 2

    Адрес[1] = I1

    Если бит 1 bit map равен 1,
    I1 и I2 должны быть соседями;
    это проверяется узлом I1

    Адрес[2] = i3
    Адрес[3] = D

    При движении пакетов от I2 к I3:

    Адрес отправителя = S

    Hdr Ext Len = 6

    Адрес получателя = I3

    Число оставшихся сегментов пути = 1
    Адрес[1] = I1

    Если бит 2 bit map равен 1,
    I2 и I3 должны быть соседями; это проверяется узлом I2

    Адрес[2] = I2

    Адрес[3] = D

    При движении пакетов от I3 к D:

    Адрес отправителя = S

    Hdr Ext Len = 6

    Адрес получателя = D

    Число оставшихся сегментов пути = 0
    Адрес[1] = I1

    Если бит 3 bit map равен 1, I3 и D должны быть соседями; это проверяется узлом I3

    Адрес[2] = I2
    Адрес[3] = i3

    8. Заголовок фрагмента

    Заголовок фрагмента используется отправителем IPv6 для посылки пакетов длиннее, чем MTU пути до места назначения. (Замечание: в отличие от IPv4, фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами вдоль пути доставки). Заголовок фрагментации идентифицируется кодом поля следующий заголовок, равным 44 и имеет следующий формат (рис. 4.4.1.1.21):

    Рис. 4.4.1.1.21. Формат заголовка фрагментации

    Следующий заголовок

    8-битовый селектор. Идентифицирует тип исходного заголовка фрагментируемой части исходного пакета. Использует те же коды протоколов, что и IPv4 [RFC-1700].

    Резерв

    8-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме.

    Fragment offset

    13-битовое число без знака. Смещение в 8-октетном блоке, для данных, которые следуют за этим заголовком, началом отсчета является начало фрагментируемой части исходного пакета.

    Резерв (второй)

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

    m флаг

    1 = есть еще фрагменты; 0 = последний фрагмент.

    Идентификация

    32 бита

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

    Для каждого пакета, который должен быть фрагментирован, узел-отправитель генерирует код идентификации. Этот код должен отличаться от аналогичных кодов идентификации, используемых для других фрагментируемых пакетов, которые пересылаются в данный момент. Под "данным моментом" подразумевается период времени жизни пакета, включая время распространения кадра от источника до получателя и время, необходимое для сборки исходного (оригинального) пакета получателем. Однако не предполагается, чтобы отправитель знал максимальное время жизни пакета. Скорее предполагается, что данное требование будет удовлетворено с помощью простого 32-разрядного счетчика, инкрементируемого всякий раз, когда очередной пакет должен быть фрагментирован. Схема реализации генератора кода идентификации оставляется на усмотрение приложения. Если присутствует заголовок маршрутизации, под адресом получателя подразумевается конечное место назначения.

    Под исходным большим, не фрагментированным пакетом подразумевается "оригинальный" пакет. Предполагается, что он состоит из двух частей, как показано на рисунке 4.4.1.1.22:

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

    Рис. 4.4.1.1.22.

    Не фрагментированная часть состоит из IPv6 заголовка плюс любых заголовков расширения, которые должны быть обработаны узлами по пути до места назначения. Таким образом, нефрагментированная часть включает в себя все заголовки вплоть до заголовка маршрутизации, если таковой присутствует, или до заголовка опций hop-by-hop, если он присутствует.

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

    Фрагментируемая часть оригинального пакета делится на фрагменты с длиной кратной 8 октетам. Фрагменты пересылаются независимо с помощью пакетов-фрагментов. Как показано на рис. Рис. 4.4.1.1.23

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

    Пакеты-фрагменты:
    o
    o
    o

    Рис. 4.4.1.1.23.

    Каждый пакет-фрагмент состоит из:

    (1) Не фрагментируемой части оригинального пакета, с длиной поля данных оригинального IPv6 заголовка, измененной для того чтобы соответствовать длине фрагмента пакета (исключая длину самого IPv6-заголовка), а код поля следующий заголовок последнего заголовка не фрагментируемой части меняется на 44.

    (2) Заголовка фрагмента, включающего в себя:

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

    Смещение фрагмента, выражаемое в 8-октетных блоках и отсчитываемое от начала фрагментируемой части оригинального пакета. Смещение первого фрагмента (самого левого) равно нулю.

    Код M-флага равен нулю, если фрагмент является последним (самым правым), в противном случае флаг равен 1.

    (3) Сам фрагмент.

    Длина фрагментов должна выбираться такой, чтобы пакеты-фрагменты соответствовали значению MTU для маршрута к месту назначения (назначений). В узле места назначения из пакетов-фрагментов восстанавливается оригинальный пакет в не фрагментированной форме.

    Восстановленный оригинальный пакет:

    Рис. 4.4.1.1.24.

    В процессе восстановления должны выполняться следующие правила:

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

    Не фрагментируемая часть восстанавливаемого пакета состоит из всех заголовков вплоть до (но не включая) заголовок фрагмента первого пакета-фрагмента (пакет со смещением равным нулю). При этом производятся следующие изменения:

    Поле следующий заголовок последнего заголовка не фрагментируемой части берется из поля следующий заголовок заголовка первого фрагмента.

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

    pl.orig = pl.first - fl.first - 8 + (8 * fo.last) + fl.last

    где

    pl.orig - поле длины данных восстановленного пакета.
    pl.first - поле длины данных первого пакета-фрагмента.
    fl.first - длина фрагмента, следующего за заголовком первого пакета-фрагмента.
    fo.last - Поле смещения фрагмента в заголовке последнего пакета-фрагмента.
    fl.last - длина фрагмента, следующего за заголовком фрагмента последнего пакета-фрагмента.

    Фрагментируемая часть восстановленного пакета состоит из частей, следующих за заголовками в каждом из пакетов-фрагментов. Длина каждого фрагмента вычисляется путем вычитания из длины поля данных длины заголовков, размещенных между IPv6 заголовком и самим фрагментом. Их относительное положение в фрагментируемой части вычисляется на основе значения смещения фрагмента. Заголовок фрагмента отсутствует в восстановленном пакете.

    В процессе сборки могут возникнуть следующие ошибки:

    Если в пределах 60 секунд после прихода первого фрагмента получено недостаточно фрагментов для завершения сборки, процедура сборки должна быть прервана и все полученные фрагменты выкинуты. Если первый фрагмент (т.e., пакет с нулевым смещением) получен, посылается ICMP сообщение "Time exceeded -- Fragment reassemble time exceeded".

    Если длина фрагмента, полученная из поля длины данных пакета, не является кратным 8 октетам, а M флаг фрагмента равен 1, фрагмент должен быть выброшен и должно быть послано сообщение ICMP (parameter problem, код 0) с указателем на поле длины данных пакета-фрагмента.

    Если длина и смещение фрагмента таковы, что восстановленная длина поля данных фрагмента превосходит 65,535 октетов, фрагмент выбрасывается, посылается сообщение ICMP (parameter problem, код 0) с указателем на поле смещения фрагмента пакета-фрагмента.

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

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

    Значение поля следующий заголовок в заголовках фрагментов различных фрагментов исходного пакета могут отличаться. Для последующей сборки используется только значение из пакета-фрагмента с нулевым смещением.

    9. Заголовок опций места назначения

    Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 60 предшествующего заголовка и имеет формат (рис. 4.4.1.1.25):

    Рис. 4.4.1.1.25. Формат заголовка опции места назначения

    Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700].

    Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов.

    Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций.

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

    • если желательно, чтобы узел назначения уничтожил пакет и, если адрес места назначения не является мультикастинговым, отправителю посылается сообщение ICMP unrecognized type, затем информация может быть закодирована в отдельном заголовке или в опции места назначения с кодом типа опции, равным 11 в старших двух битах. Выбор может зависеть от таких факторов как число необходимых октетов, проблема выравнивания или более простой анализ пакета.
    • если желательна какая-либо иная операция, информация должна быть закодирована в виде опции места назначения с типом опции 00, 01 или 10 в старших двух битах.

    10. Отсутствие следующего заголовка

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

    11. О размере пакетов

    Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

    Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

    Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.

    Для того чтобы послать пакет длиннее чем MTU канала, узел может использовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где используется настройка по измеренному значению MTU пути.

    Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать.

    В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.

    Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел "думает", что адресат находится на том же канале что и сам узел.

    Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.

    12. Метки потоков

    24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

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

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

    Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - ffffff. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.

    Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

    Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными.

    Режим обработки пакетов с использованием кэш должен быть аннулирован не позднее 6 секунд после своей установки вне зависимости от того, продолжают ли поступать пакеты данного потока. Если приходит другой пакет от того же отправителя с той же меткой после того как кэш режим отменен, он подвергается обычной обработке (как если бы имел нулевую метку), такая ситуация может быть причиной повторного формирования кэш режима.

    Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд.

    Отправитель не должен использовать старую метку для нового потока в пределах времени жизни любого потока. Так как режим обработки потока на 6 секунд может быть установлен для любого потока, минимальный интервал между последним пакетом одного потока и первым пакетом нового, использующего ту же метку, должно быть равно 6 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше.

    Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.

    Не требуется, чтобы все или даже большинство пакетов принадлежали потокам с ненулевыми метками. Например, было бы неумно сконструировать маршрутизатор так, чтобы он работал только с пакетами, принадлежащими к тому или иному потоку, или создать схему сжатия заголовков, которая работает только с помеченными потоками.

    13. Приоритет

    4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов "реального времени", посылаемых с постоянной частотой.

    Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 4.4.1.1.2).

    Таблица 4.4.1.1.2. Значения кодов приоритета

    Код приоритета

    Назначение

    0

    Нехарактеризованный трафик

    1

    Заполняющий трафик (например, сетевые новости)

    2

    Несущественный информационный трафик (например, электронная почта)

    3

    Резерв

    4

    Существенный трафик (напр., FTP, HTTP, NFS)

    5

    Резерв

    6

    Интерактивный трафик (напр. telnet, x)

    7

    Управляющий трафик Интернет (напр., маршрутные протоколы, snmp)

    Предполагается, что чем больше код, тем выше приоритет данных, тем быстрее они должны быть доставлены. Так для передачи мультимедийной информации, где управление скоростью передачи не возможно, уровень приоритета должен лежать в пределах 8-15. Практически, уровни приоритета выше или равные 8 зарезервированы для передачи данных в реальном масштабе времени.

    Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.

    14. О протоколе верхнего уровня
    14.1 Контрольные суммы верхнего уровня

    Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):

    Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP

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

    • Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.
    • В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.
    • В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на ffff для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.

    IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.

    15. Максимальное время жизни пакета

    В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.

    16. Максимальный размер поля данных для протоколов высокого уровня

    При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

    17. Приложение a. Рекомендации по формированию опций

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

    • Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.
    • Другим желательным требованием является минимальное место, занимаемое hop-by-hop или опциями места назначения, а длина заголовка должна быть кратной 8 октетам.
    • Можно предположить, что когда присутствует какой-то заголовок, содержащий опции, он несет в себе небольшое число опций, обычно одну.

    Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:

    Пример 1

    Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):

    Рис. 4.4.1.1.27.

    Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):

    Рис. 4.4.1.1.28

    Пример 2

    Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):

    Рис. 4.4.1.1.29

    Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):

    Рис. 4.4.1.1.30

    Пример 3

    Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):

    Рис. 4.4.1.1.31

    Рис. 4.4.1.1.32

    18. Соображения безопасности

    Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825].

    19. Расширение DNS для поддержки IP-версии 6 (DNS Extensions to Support IP Version 6. S. Thomson. RFC-1886)

    Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес.

    Для того чтобы запоминать IPv6-адреса, определены следующие расширения:

    • Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.
    • Определен новый домен, предназначенный для обработки запросов по новым адресам.
    • Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.

    Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние осуществования IPv4 и IPv6-адресов обсуждается в [4].

    19.1. Определение новой ресурсной записи и домена

    Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.

    Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).

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

    Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.

    Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.

    Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.

    IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу

    4321:0:1:2:3:4:567:89ab

    будет выглядеть как

    b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.

    19.2. Модификации существующих типов запроса

    Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.

    20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 (a. conta. internet control message protocol (ICMPv6) for the internet protocol version 6 (IPv6) specification. RFC-1885)

    Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58.

    20.1. ICMPv6 (ICMP для IPv6)

    ICMPv6 используется узлами IPv6 для сообщений об ошибках при обработке пакетов, и для выполнения других функций уровня Интернет, таких как диагностика (ICMPv6 "ping") и сообщение об участии в мультикастинг группах. Протокол ICMPv6 является интегрированной частью IPv6 и должен реализовываться каждым узлом, поддерживающим IPv6.

    20.2. Общий формат сообщений

    Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.

    В данном документе определены форматы для следующих сообщений ICMPv6:

    Сообщения об ошибках ICMPv6:

    1 destination unreachable (место назначения недоступно)
    2 packet too big (пакет слишком велик)
    3 time exceeded (время превышено)
    4 parameter problem (проблема с параметрами)

    Информационные сообщения ICMPv6:

    128 echo request (Запрос эхо)
    129 echo reply (Эхо-отклик)
    130 group membership query (запрос участия в группе)
    131 group membership report (отчет об участии в группе)
    132 group membership reduction (сокращение числа участников в группе)

    Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)

    Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):

    Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6

    Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.

    Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

    Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:

    1. Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.
    2. Если сообщение является откликом на мультикаст- или эникаст-сообщение группе, в которую входит данный узел, адресом отправителя должен стать никастный адрес интерфейса, откуда пришло сообщение-первопричина отклика.
    3. Если сообщение является откликом на сообщение, посланное по адресу, который не принадлежит данному узлу, в качестве адреса отправителя следует выбрать уникаст адрес, принадлежащий узлу и обещающий наибольшую диагностическую полезность. Например, если сообщение является откликом на операцию переадресации пакета, которая не может быть завершена успешно, в качестве адреса отправителя должен быть взят уникаст-адрес интерфейса, переадресация на который не удалась.
    4. В противном случае, должна быть просмотрена таблица маршрутизации узла и выяснено, какой интерфейс должен быть использован для достижения места назначения сообщения. Уникастный адрес этого интерфейса и должен быть выбран в качестве адреса отправителя.

    Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

    Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

    1. Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.
    2. Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.
    3. Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.
    4. В тех случаях, когда протокол интернет-уровня нуждается в передаче сообщения об ошибке ICMPv6 вышерасположенному уровню, тип протокола верхнего уровня извлекается из исходного пакета (содержащегося в теле сообщения об ошибке ICMPv6) и используется для выбора соответствующего протокола верхнего уровня при последующей обработке сообщения об ошибке.
    5. Если исходный пакет имеет необычно большое число заголовков расширения, возможно, что тип протокола верхнего уровня может отсутствовать в сообщении ICMPv6, из-за укорочения исходного пакета до уровня 576 октетов. В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6.

    6. Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

    (e.1) сообщения об ошибке ICMPv6, или

    (e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) - чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

    (e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

    (e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

    (e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.

    (f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.

    Существует много способов ограничения частоты посылки сообщений, например:

    (f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

    (f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

    Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).

    20.3. Сообщения об ошибках ICMPv6

    Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата

    Поля IPv6:

    Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.

    Поля ICMPv6:

    Тип = 1
    Код = 0 - нет маршрута до места назначения
    1 - связь с адресатом административно запрещена
    2 - не сосед
    3 - адрес не достижим
    4 - порт не достижим

    Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

    Описание

    Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).

    Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).

    Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.

    Если причиной потери пакета является то, что следующий узел в маршрутной таблице не является соседом данного узла, то поле код принимает значение 2.

    Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.

    Узел места назначения может посылать сообщение "адресат не достижим" с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.

    Узел, получивший сообщение ICMPv6 "адресат не достижим" должен уведомить об этом протокол вышележащего уровня.

    Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)

    Поля IPv6:

    Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.

    Поля ICMPv6:

    Тип 2
    Код 0
    mtu mtu следующего шага.

    Описание

    Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].

    Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.

    Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33).

    Поля ICMPv6:

    Тип 3
    Код 0 - при передаче превышен лимит числа шагов
    1 - превышено время восстановления сообщения из фрагментов.

    Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

    Описание

    Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.

    Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d).

    Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.

    Рис. 4.4.1.1.36. Сообщение о конфликте параметров

    Поля ICMPv6:

    Тип 4
    Код 0 - встретилась ошибка в поле заголовка
    1 - встретился неопознанный код поля следующий заголовок
    2 - встретилась неопознанная опция IPv6
    Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.

    Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.

    Описание

    Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.

    Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.

    20.4. Информационные сообщения ICMPv6

    Рис. 4.4.1.1.37. Сообщение запрос эхо

    Поля IPv6:

    Адрес места назначения - любой легальный IPv6-адрес

    Поля ICMPv6:

    Тип 128
    Код 0

    Идентификатор. Идентификатор, который помогает друг с другом связать запрос эхо и эхо-отклик. Может равняться нулю.

    Номер по порядку

    Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

    Информация. Нуль или более октетов произвольных данных.

    Описание

    Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

    Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).

    Поля IPv6:

    Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

    Поля ICMPv6:

    Тип 129
    Код 0

    Идентификатор. Идентификатор из исходного запроса эхо (echo request).
    Номер по порядку. Номер по порядку из исходного запроса эхо.
    Информация. Данные из исходного запроса эхо.

    Описание

    Каждый узел должен иметь встроенную функцию отклика ICMPv6, которая получает запросы эхо и посылает соответствующие эхо-отклики. Узел должен также реализовать интерфейс прикладного уровня для посылки запросов эхо и получения эхо-откликов для диагностических целей.

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

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

    Информация, полученная в ICMPv6 сообщении запроса эхо, должна быть полостью возвращена без модификации в ICMPv6 эхо-отклике, если эхо-отклик не превысит MTU обратного прохода, в противном случае пакет укорачивается.

    Оповещение верхнего уровня

    Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня.

    Сообщение о членстве в группе имеет следующий формат:

    Рис. 4.4.1.1.38. Сообщения участия в группе

    Поля IPv6:
    Адрес места назначения

    В сообщении-запросе о членстве в группе запрашивается мультикаст-адрес группы.

    В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы.

    Поле Hop Limit = 1 (предельное число шагов)
    Поля ICMPv6:

    Тип 130 - Запрос членства в группе
    131 - Отчет о членстве в группе
    132 - Сокращение членства в группе
    Код 0
    Максимальное время отклика

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

    Не используется. Отправитель записывает нуль, получатель игнорирует.
    Мультикаст-адрес

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

    Описание

    Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].

    Литература

    [1]

    Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987.

    [2]

    Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

    [3]

    Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

    [4]

    Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress.

    [ALLOC]

    Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, cisco Systems, December 1995

    [ANYCST]

    Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, BBN, November 1993.

    [CIDR]

    Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.

    [IPV6]

    Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995.

    [IPv6-ADDR]

    Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

    [IPv6-DISC]

    Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Work in Progress

    [MULT]

    Deering, S., "Host Extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989

    [NSAP]

    Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and TP over IPv6", Work in Progress.

    [RFC-791]

    Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

    [RFC-792]

    Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981

    [RFC-1112]

    Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

    [RFC-1122]

    Braden, R., "Requirements for Internet Hosts -Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989

    [RFC-1191]

    Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, DECWRL, Stanford University, November 1990.

    [RFC-1661]

    Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

    [RFC-1700]

    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

    [RFC-1825]

    Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.

    [RFC-1826]

    Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995.

    [RFC-1827]

    Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC 1827, Naval Research Laboratory, August 1995

    [RFC-1885]

    Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995.

    [RFC-1884]

    Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995

    [RFC-1933]

    Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark. April 1996

    [RFC-1970]

    Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark & W. Simpson. August 1996.

    [RFC-1971]

    IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August 1996.

    [RFC-1972]

    A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996.

    [RFC-2019]

    Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996.

    [RFC-2030]

    Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996.

    [RFC-2080]

    RIPng for IPv6. G. Malkin, R. Minnear. January 1997.

    [RFC-2133]

    Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997.

    Previous: 4.4.1 IP-протокол    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.1.2 IP-туннели


    previous up down next index index
    Previous: 4.4.1.1 Адресация IPv6    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)

    4.4.1.2 IP-туннели
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Особенность IP-протокола (опция принудительной маршрутизации) позволяет переадресовывать IP-дейтограммы определенным узлам сети. На первый взгляд эта возможность может показаться совершенно бесполезной, ведь существуют механизмы динамической маршрутизации, которые несравненно эффективнее и надежней обеспечивают обмен данными. Но тем не менее существуют приложения, где принудительная маршрутизация на IP-уровне представляет возможности недоступные для традиционных решений. Это прежде всего сети, работающие с использованием протоколов IPX/SPX (Novell), где традиционная маршрутизация не предусмотрена. Для подключений удаленных серверов, находящихся вне локальной сети, здесь используется технология так называемых IP-туннелей. При реализации этой технологии IPX-пакеты инкапсулируются в IP-дейтограммы и доставляются в соответствие с протоколами TCP/IP. Процедура инкапсуляции осуществляется специальным драйвером (IPtunnel; использует протокол IPxodi), который работает так, как если бы он был драйвером аппаратного сетевого интерфейса. При этом необходимо модифицировать конфигурационный файл net.cfg (См., например, www2.ncsu.edu/cc-consult/usinglwp/tunnel.html ).

    ;Техника IP-туннелей может оказаться иногда полезной и при администрировании маршрутизации, так как метрика внешних протоколов маршрутизации может не учитывать пропускную способность каналов и некоторые другие факторы, например, QoS. В этом случае IP-дейтограммы вкладываются в IP-дейтограммы отправителем (начало туннеля) и извлекаются оттуда в конце туннеля. Конец туннеля не обязательно совпадает с местом назначения пакетов. Такая простая схема туннелирования может порождать некоторые проблемы (см. рис. 4.4.1.2.1).

    Рис. 4.4.1.2.1 Схема туннелирования пакетов. Квадратными скобками отмечено вложение пакетов. В числителе приводится адрес места назначения, в знаменателе адрес отправителя. Адрес вне скобок - адрес места назначения.

    Из рисунка видно, что простой туннель может породить асимметричный маршрут, при котором путь туда и обратно не совпадают. Чтобы такого не произошло, применяется техника "маскарада" (masquerading). Для этого "маршрутизатор конца туннеля" должен извлечь вложенный пакет (как это он делает и на рис. 4.4.1.2.1) и вложить его в пакет с адресом места назначения IP3, указав при этом в качестве отправителя себя (IP3/IP2[IP3/IP1]). Тогда конечный адресат IP3 будет посылать отклики по адресу IP2, а не IP1. А уже маршрутизатор конца туннеля будет пересылать их первоисточнику запроса IP1.

    В последнее время техника туннелей нашла применение при построении так называемых прокси-серверов, популярность которых связана с возможностью заметно сократить внешний (часто зарубежный) трафик за счет запоминания в дисковом буфере файлов, наиболее часто запрашиваемых клиентами. Заметно упрощает решение данной задачи многие современные маршрутизаторы, которые могут отфильтровывать запросы по определенным портам и переадресовывать их прокси-серверу (см. рис. 4.4.1.2.2).

    Рис. 4.4.1.2.2. Схема транспортировки запросов при использовании прокси-сервера

    Схема с "невидимым" прокси-сервером работает следующим образом. Сначала запрос поступает в маршрутизатор, там он анализируется и, если выясняется что это HTTP или FTP-запросы, переадресуется прокси-серверу. Если запрашиваемый файл находится в буфере сервера, заказ клиента удовлетворяется локально. В противном случае запрос снова посылается маршрутизатору. Запросы прокси-сервера маршрутизатор переправляет во внешнюю сеть. В случае использования персональной ЭВМ в качестве прокси-сервера можно ее снабдить двумя сетевыми интерфейсами для приема и посылки запросов, что сделает работу более эффективной. Если маршрутизатор не поддерживает описанный режим, то при конфигурации сетевого программного обеспечения клиента можно явно прописать адрес прокси-сервера и все соответствующие запросы пойдут непосредственно туда.

    Туннели широко используются и при передаче мультимедийных данных.

    Previous: 4.4.1.1 Адресация IPv6    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)


    previous up down next index index
    Previous: 4.4.1.2 IP-туннели    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.2 Протокол UDP

    4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    (W. Townsley, A. Valencia, A., Rubens, G. Pall, G. Zorn, B. Palter, Layer Two Tunneling Protocol "L2TP". RFC-2661, August 1999. Перевод Семенова Ю.А.)

    1.0. Введение

    Протокол PPP [RFC1661] определяет механизм инкапсуляции для транспортировки мультипротокольных пакетов для соединений точка-точка сетевого уровня L2. Обычно, пользователь получает соединение L2 с сервером доступа NAS (Network Access Server) посредством одной из следующих технологий: посредством модема через коммутируемую телефонную сеть, ISDN, ADSL, и т.д. Далее через это соединение реализуется протокол PPP. В такой конфигурации терминальная точка L2 и сессии PPP находится в одном и том же физическом устройстве (NAS). Разрабатывается версия протокола для безопасного удаленногго доступа через L2TP (RFC-2888).

    Протокол L2TP расширяет модель PPP, позволяя размещение терминальных точек L2 и PPP в различных физических устройствах, подключенных к сети с коммутацией пакетов. В L2TP, пользователь имеет соединение L2 с концентратором доступа (например, модемным пулом, ADSL DSLAM, и т.д.), а концентратор в свою очередь туннелирует индивидуальные PPP-кадры в NAS. Это позволяет разделить обработку PPP-пакетов и реализацию шлюза L2.

    Очевидным преимуществом такого разделения является то, что вместо требования завершения соединения L2 в NAS, соединение может завершаться в локальном концентраторе, который затем продлевает логический канал PPP через общую инфраструктуру, такую как, например, Интернет. C точки зрения пользователя нет никакой разницы между завершением туннеля на уровне L2 в NAS или через L2TP.

    Многоканальный PPP [RFC1990] требует, чтобы все каналы, образующие многоканальную связь, были объединены в группу с помощью одного NAS. Благодаря возможности формирования сессий PPP с оконечными адресами, отличными от точки присоединения, L2TP может использоваться для схем, когда все каналы приходят на вход одного NAS.

    1.1. Терминология

    Аналоговый канал

    Коммуникационный канал, который обычно обеспечивает при передаче голоса полосу 3.1 кГц в обоих направлениях.

    Пары атрибут

    значение AVP (Attribute Value Pair) Объединение уникального атрибута (представляемого в виде целого числа) и действительного значения этого атрибута. Пара AVP имеет переменную длину. Несколько AVP образуют управляющие сообщения, которые используются при установлении, поддержке и ликвидации туннеля.

    Вызов

    Соединение (или попытка соединения) между удаленной системой и LAC (L2TP Access Concentrator). Например, телефонный вызов через обычную коммутируемую телефонную сеть PSTN. Вызов (входящий или исходящий), который успешно осуществил связь между удаленной системой и LAC, реализуется в ходе L2TP-сессии при условии, что туннель между LAC и LNS (L2TP Network Server) уже создан. (Смотри также: сессия, входящий вызов, исходящий вызов).

    Вызванный номер

    Телефонный номер, использованный для связи с получателем вызова.

    Вызывающий номер

    Телефонный номер, откуда пришел вызов.

    CHAP

    Challenge Handshake Authentication Protocol [RFC1994], криптографический PPP-протокол для аутентификации вызова/отклика, в котором пароль не передается открытым текстом.

    Управляющее соединение

    Управляющее соединение работает в пределах имеющейся полосы туннеля и служит для установления, аннулирования и поддержания сессий и самого туннеля.

    Управляющие сообщения

    Управляющими сообщениями обмениваются LAC и LNS, работающие в пределах имеющейся полосы туннеля. Управляющие сообщения контролируют сам туннель и реализуемые через него сессии.

    Цифровой канал

    Коммутируемый канал, по которому передаются цифровые данные в обоих направлениях.

    DSLAM

    Digital Subscriber Line (DSL) Access Module (модуль доступа клиентов к цифровым линиям). Сетевой прибор, используемый для реализации DSL-сервиса. Это обычно концентратор индивидуальных DSL-линий, размещенный в центральном офисе (CO), или местный коммутатор.

    Входящий вызов

    Вызов, полученный LAC для туннелирования в LNS (смотри Вызов, Исходящий вызов).

    Концентратор доступа L2TP (LAC)

    Узел, который действует в качестве одной из сторон L2TP-туннеля и является партнером для LNS (L2TP Network Server). LAC размещается между LNS и удаленной системой, переадресуя им пакеты. Пакеты, посланные от LAC к LNS, требуют туннелирования с помощью протокола L2TP, как это определено в данном документе. Соединение между LAC и удаленной системой является локальным (смотри: клиент LAC) или осуществляется через канал PPP.

    Сетевой сервер L2TP (LNS)

    Узел, который работает в качестве одного из концов L2TP туннеля, и является партнером для LAC (L2TP Access Concentrator). LNS является логической терминальной точкой PPP-сессии, которая организует туннель между удаленной системой и LAC.

    Домен управления (MD)

    Сеть или сети, управляемые общей администрацией administration, политикой или системой. Например, доменом управления LNS может быть корпоративная сеть, которую он обслуживает. Доменом управления LAC может быть сервис-провайдер Интернет, которым он управляет.

    Сервер доступа к сети (NAS)

    Прибор, предоставляющий доступ к локальной сети для пользователей удаленной сети, такой как общедоступная коммутируемая телефонная сеть (PSTN). NAS может выполнять функцию LAC, LNS или и того и другого.

    Исходящий вызов

    Вызов, сделанный LAC, для туннелирования в LNS (смотри вызов, входящий вызов).

    Партнер

    При использовании в контексте L2TP, партнер относится к LAC или LNS. Партнером LAC является LNS и наоборот. При использовании в контексте PPP, партнером является любая из сторон PPPсоединения.

    POTS

    Plain Old Telephone Service (обычная телефонная служба).

    Удаленная система

    Оконечная система или маршрутизатор, соединенный с удаленной сетью (т.e. PSTN), которая является инициатором или получателем вызова. Относится также к клиенту, подключающемуся через коммутируемую телефонную сеть (dial-up).

    Сессия

    Протокол L2TP ориентирован на соединение. LNS и LAC поддерживают состояния для каждого вызова, который инициирован или воспринят LAC. Сессия L2TP формируется между LAC и LNS, когда создано соединение точка-точка PPP между удаленной системой и LNS. Дейтограммы, относящиеся к соединению PPP, пересылаются по туннелю, организованному между LAC и LNS. Существует полное соответствие между сессиями L2TP и сопряженными с ними вызовами. (Смотри также: вызов).

    Туннель

    Туннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более сессий L2TP. Туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS.

    Сообщение с нулевой длиной тела (ZLB)

    Управляющий пакет, имеющий только заголовок L2TP. ZLB-сообщения используются в качестве откликов в управляющем канале.

    2. Топология

    На диаграмме (рис. 1.) показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.

    Рис. 1. Схема работы протокола L2TP

    Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN. LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, посредством чего осуществляется доступ к исходной LAN (Home LAN). Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккоунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.

    LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC. В этом случае, ЭВМ, содержащая программу LAC клиента, уже имеет соединение с Интернет. Затем создается "виртуальное" PPP-соединение и локальная программа L2TP LAC формирует туннель до LNS. Как и в выше описанном случае, адресация, аутентификация, авторизация и аккоунтинг будут обеспечены областью управления исходной LAN.

    3. Обзор протокола

    L2TP использует два вида пакетов, управляющие и информационные сообщения. Управляющие сообщения используются при установлении, поддержании и аннулировании туннелей и вызовов. Информационные сообщения используются для инкапсуляции PPP-кадров пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку (смотри раздел 5.1). Информационные сообщения если происходит их потеря, не пересылаются повторно.

    PPP кадры

    L2TP Информационные сообщения

    L2TP Управляющие сообщения

    L2TP Информационный канал (ненадежный)

    L2TP Канал управления (надежный)

    Транспортировка пакетов (UDP, FR, ATM, etc.)

    Рис. 2.0. Структура протокола L2TP

    На рис. 2.0 показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д.. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта.

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

    3.1. Формат заголовка L2TP

    Пакеты L2TP для контрольного и информационного каналов используют один и тот же формат заголовка. Заметим, что поля длина, Ns и Nr - опционные для информационных пакетов, являются обязательными для всех управляющих сообщений.

    Заголовок имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 31

    T

    L

    x

    x

    S

    x

    O

    P

    x

    x

    x

    x

    Версия

    Длина (опц)

    ID туннеля

    ID сессии

    Рис. 3. Формат заголовка L2TP

    Бит тип (T) характеризует разновидность пакета. Он устанавливается равным 0 для информационных сообщений и 1 - для управляющих.

    Если бит длины (L) равен 1, поле длина присутствует. Для управляющих сообщений этот бит должен быть равен 1.

    Биты x зарезервированы для будущих применений. Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих.

    Если бит последовательности (S) равен 1, поля Ns и Nr присутствуют. Бит S для управляющих сообщений должен быть равен 1.

    Если бит смещения (O) равен 1, поле величины смещения присутствует. Бит O для управляющих сообщений должен быть равен 0.

    Если бит приоритета Р равен 1, это информационное сообщение должно обслуживаться с предпочтением при обработке очередей и передаче. Запрос эхо LCP (Link Control Protocol) используется для канала, в качестве контроля keepalive, его следует посылать с битом приоритета равным 1. Без этого, временные периоды локальной перегрузки могут вызвать интерференцию с сообщениями keepalive и потерю связи. Эта особенность характерна только для информационных сообщений. Бит P должен быть равен 0 для всех управляющих сообщений.

    Поле Ver должно быть равно 2, указывая версию заголовка информационного сообщения L2TP. Значение 1 зарезервировано для детектирования пакетов L2F [RFC-2341], в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver должны отбрасываться. Поле длина указывает общую длину сообщения в октетах.

    ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID-туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID-туннеля выбираются при формировании туннеля.

    ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение. ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии.

    Ns определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 216) для каждого посланного сообщения. Смотри разделы 5.8 и 5.4.

    Nr содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс один (по модулю 216). В информационных сообщениях, Nr зарезервировано и, если присутствует (как это определяется S- битом), должно игнорироваться при получении. Смотри раздел 5.8.

    Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения.

    3.2. Типы управляющих сообщений

    Тип сообщения AVP (смотри раздел 4.4.1) определяет специфический тип посылаемого управляющего сообщения.

    В данном документе определены следующие типы управляющих сообщений (смотри разделы 6.1 - 6.14):

    Управление контрольным соединением

    0

    (зарезервировано)

    1

    (SCCRQ)

    Start-Control-Connection-Request

    2

    (SCCRP)

    Start-Control-Connection-Reply

    3

    (SCCCN)

    Start-Control-Connection-Connected

    4

    (StopCCN)

    Stop-Control-Connection-Notification

    5

    (зарезервировано)

    6

    (HELLO)

    Hello

    Управление вызовами (Call Management)

    7

    (OCRQ)

    Outgoing-Call-Request

    8

    (OCRP)

    Outgoing-Call-Reply

    9

    (OCCN)

    Outgoing-Call-Connected

    10

    (ICRQ)

    Incoming-Call-Request

    11

    (ICRP)

    Incoming-Call-Reply

    12

    (ICCN)

    Incoming-Call-Connected

    13

    (зарезервировано)

    14

    (CDN)

    Call-Disconnect-Notify

    Сообщения об ошибках

    15

    (WEN)

    WAN-Error-Notify

    Управление сессией PPP

    16

    (SLI)

    Set-Link-Info

    4. Пары значений-атрибутов управляющих сообщений

    4.1. Формат AVP

    Каждая AVP кодируется следующим образом:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    M

    H

    rsvd

    Длина

    ID производителя

    Тип атрибута

    Значение атрибута

    Продолжение поля значение атрибута до границы, заданной полем длина

    Рис. 4.

    Первые 6 бит представляют собой битовую маску, характеризующую атрибуты AVP.

    Два бита определены в этом документе, остальные - зарезервированы на будущее. Зарезервированные биты должны равняться нулю. AVP, полученная с зарезервированным набором бит равным 1, должна рассматриваться как не узнанная AVP.

    Обязательный бит M (Mandatory) контролирует реакцию системы на получение нераспознанной AVP. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном с определенной сессией, эта сессия должна быть немедленно завершена. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном со всем туннелем, этот туннель (и все его сессии) должен быть ликвидирован. Если бит M =0, нераспознанную AVP следует игнорировать. Управляющие сообщения должны обрабатываться при этом так, как если бы AVP не было.

    Бит сокрытия (H). Идентифицирует скрываемые данные в поле значения атрибута AVP. Эта возможность может использоваться, чтобы исключить передачу важных данных, например пароля пользователя, в незашифрованном тексте AVP. В разделе 4.3 описана процедура выполнения сокрытия AVP.

    Длина. Число октетов (включая поля полной длины и маски) в AVP. Длина может быть вычислена как 6 + длина поля значения атрибута в октетах. Поле имеет 10 бит, позволяя закодировать до 1023 октетов в одной AVP. Минимальный код длины AVP равен 6. Если длина равна 6, поле значения атрибута отсутствует.

    ID производителя (Vendor ID). IANA определила значения кодов производителей (SMI Network Management Private Enterprise Codes) [RFC1700]. Значение 0, соответствующее атрибутам, адаптированным для IETF, используется для всех AVP, определенных в данном документе. Любой производитель, желающий реализовать свое собственное расширение L2TP, может использовать свой код Vendor ID вместе с частными значениями атрибута, гарантирующие отсутствие столкновений с любыми расширениями других производителей, или будущими расширениями IETF. Заметим, что для ID-производителя выделено 16 бит, что ограничивает максимальное число производителей цифрой 65,535.

    Тип атрибута: 2-октетное значение с уникальной интерпретацией для совокупности AVP данного ID-производителя.

    Значение атрибута. Действительное значение атрибута для заданного Vendor ID и типа атрибута. Оно следует немедленно после поля типа атрибута, и занимает все пространство октетов, отведенное значением поля длина (т.e., длина минус 6 октетов заголовка). Это поле отсутствует, если длина равна 6.

    4.2. Обязательные AVP

    Получение неизвестной AVP, которая имеет бит M=1, является катастрофическим для сессии или туннеля, с которым она ассоциирована. Таким образом, бит M должен быть определен только для AVP, которые критичны для нормальной работы сессии или туннеля. Далее, в случае, когда LAC или LNS получают неизвестную AVP с M-битом равным 1 и закрывают сессию или туннель, ответственность за это полностью несет партнер, пославший обязательную AVP. Прежде чем определить AVP с M=1, в особенности AVP специфичное для данного производителя, убедитесь в том, что вы именно этого хотите.

    Когда имеется адекватная альтернатива использованию M-бита, ей следует воспользоваться. Например, вместо того, чтобы посылать AVP с M=1 для определения существования специфического расширения, можно решить проблему путем посылки AVP в сообщении-запросе в расчете на получение соответствующего AVP в отклике.

    Использование M-бита с новыми AVP (не определенными в этом документе) должно предоставить возможность сконфигурировать программу так, чтобы AVP либо не посылалась, или посылалась с M-битом равным нулю.

    4.3. Сокрытие значений атрибутов AVP

    Бит H в заголовке каждой AVP предлагает механизм указания принимающему партнеру, представлено ли содержимое AVP скрытым или открытым текстом. Эта возможность применяется, чтобы скрыть важную информацию управляющих сообщений, такую как пароль пользователя или его ID.

    Бит H должен быть равен 1, если имеется общий ключ для LAC и LNS. Этот ключ является тем же ключом, который использовался для аутентификации туннеля (смотри раздел 5.1.1). Если бит H =1 в любой AVP в данном управляющем сообщении, там должен также присутствовать случайный вектор AVP и должен предшествовать первому AVP, имеющему H = 1.

    Сокрытие значения AVP делается за несколько шагов. Сначала берутся поля длины и значения оригинала (открытый текст) AVP и кодируются согласно субформата скрытого AVP:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 31

    Длина значения оригинала

    Значение оригинала атрибута

    Продолжение значения оригинала атрибута

    Заполнитель

    Рис 5. Субформат скрытого AVP

    Исходная длина значения атрибута. Это длина кода исходного значения атрибута, которое следует закрыть, в октетах. Необходимо определить исходную длину значения атрибута, так как ее значение теряется при добавлении заполнителя.

    Исходное значение атрибута. Значение атрибута, которое должно быть скрыто.

    Заполнитель. Произвольные дополнительные октеты, используемые для того, чтобы скрыть длину значения атрибута, когда необходимо скрыть само значение.

    Чтобы замаскировать размер скрытого поля данных, используемый субформат может быть дополнен некоторым количеством произвольных октетов. Заполнитель не меняет значения поля, но изменяет величину поля длина AVP, которое было сформировано. Например, если значение атрибута, которое необходимо скрыть, занимает 4 октета, исходная длина AVP будет равна 10 октетам (6 + длина поля значения атрибута). После операции сокрытия, длина AVP станет равной 6 + длина атрибута + размер поля длины исходного значения атрибута + длина заполнителя. Таким образом, если заполнитель имеет 12 октетов, длина AVP будет равна 6 + 4 + 2 + 12 = 24 октетам. Далее, производится хэширование (MD5) для полученного объединения:

    + 2 октета номера атрибута AVP
    + общий секретный ключ
    + случайный вектор произвольной длины

    Значение случайного вектора, используемого в этом хэше, передается в поле случайный вектор AVP. Этот случайный вектор AVP должен быть помещен в сообщение отправителем до любого скрытого AVP. Тот же самый случайный вектор может быть использован для более чем одного скрытого AVP сообщения. Если для сокрытия последующих AVP используется другой случайный вектор, тогда новый случайный вектор AVP должен быть помещен в командное сообщение до первого его использования.

    Значение хэша MD5 затем объединяется с помощью операции XOR с первыми 16 октетами сегмента субформата скрытого AVP и помещается в поле значения атрибута скрытого AVP. Если субформат скрытого AVP имеет менее 16 октетов, субформат преобразуется так, как если бы поле значения атрибута было дополнено до 16 октетов перед операцией XOR, но модифицируются только действительные октеты, присутствующие в субформате, а длина AVP не изменяется.

    Если субформат длиннее 16 октетов, вычисляется второй хэш MD5 для потока октетов, состоящего из общего секретного ключа, за которым следует результат первой операции XOR. Этот хэш объединяется с помощью операции XOR со вторым 16 октетным (или менее) сегментом субформата, а результат помещается в соответствующие октеты поля значения скрытого AVP.

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

    Метод сокрытия был адаптирован из RFC 2138 [RFC2138], который был взят из секции "Mixing in the Plaintext" книги "Network Security" Кауфмана, Пелмана и Спенсера [KPS]. Ниже дается детальное пояснение метода:

    Берется общий секретный ключ S, случайный вектор RV и значение атрибута AV. Поле значение делится на секции по 16 октетов p1, p2 и т.д.. Последняя секция дополняется до границы в 16 октетов специальным заполнителем. Вычисляются блоки шифротекста c(1), c(2), и т.д.. Мы также определяем промежуточные значения b1, b2, и т.д.

    b1 = MD5(AV + S + RV)

    c(1) = p1 xor b1

    b2 = MD5(S + c(1))

    c(2) = p2 xor b2

    .

    .

    .

    .

    .

    .

    bi = MD5(S + c(i-1))

    c(i) = pi xor bi

    строка будет содержать c(1)+c(2)+...+c(i) где + означает объединение.

    По получение, случайный вектор берется из AVP, включенного в сообщение до AVP, подлежащего сокрытию. Описанный выше процесс реверсируется с целью получения исходного значения.

    4.4. Обзор AVP

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

    4.4.1. AVP, применимые для всех управляющих сообщений

    Тип сообщения (все сообщения)

    Тип сообщения AVP, тип атрибута 0, идентифицируют управляющее сообщение и определяет контекст, в котором будет определено точное значение последующих AVP. Поле значения атрибута для этой AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

    Тип сообщения

    Рис. 6

    Тип сообщения характеризуется целым 2-октетным числом без знака.

    Тип сообщения AVP должен быть первым AVP в сообщении, который следует непосредственно сразу за заголовком управляющего cообщения (определено в разделе 3.1). Список типов управляющих сообщений и их идентификаторов смотри в разделе 3.2.

    Обязательный бит (M) в типе сообщения AVP имеет специальное назначение. Этот бит служит скорее не для указания того, следует ли игнорировать саму AVP, если бы она не распознана, а указанием того, что при не распознании следует игнорировать управляющее сообщение. Таким образом, если M-бит равен 1 в типе сообщения AVP, а тип сообщения неизвестен программе, туннель должен быть ликвидирован. Если бит M=0, тогда программа может игнорировать сообщения неизвестных типов. M-бит должен быть сделан равным 1 для всех типов сообщений определенных в данном документе. Эта AVP не может быть скрытой (H-бит должен быть равен нулю 0). Длина этого AVP равна 8.

    Случайный вектор (все сообщения)

    Случайный вектор AVP, тип атрибута 36, используются для разрешения сокрытия значения атрибута AVP.

    Случайная последовательность октетов может иметь произвольную длину, хотя для случайного вектора рекомендуется длина, по крайней мере, 16 октетов. Строка содержит случайный вектор для использования при вычислении хэша MD5 чтобы извлечь или скрыть значение атрибута скрытого AVP (смотри раздел 4.2).

    В сообщении может быть более одного случайного вектора AVP. Эта AVP должна предшествовать первому AVP с битом H =1.

    M-бит для этого AVP должно быть равно 1. Это AVP не должно быть скрыто (H-бит должен быть равен 0). Длина этого AVP равно 6 плюс длина случайной строки октетов.

    4.4.2. Коды результата и ошибки

    Результирующий код (CDN, StopCCN)

    Результирующий код AVP, тип атрибута - 1, индицируют причину завершения работы управляющего канала или сессии. Поле значения атрибута AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Код результата

    Код ошибки (опц.)

    Сообщение об ошибке (опц.)

    Рис. 7. Формат поля значения атрибута AVP

    Результирующий код представляет собой целое число без знака длиной в 2 октета. Опционный код ошибки представляет собой 2-октетное целое число без знака. Опционное сообщение об ошибке поясняет код ошибки. Присутствие кода ошибки и сообщения определяется полем длины AVP. Сообщение об ошибке содержит произвольную строку текста, пригодного для чтения, характеризующего ситуацию. Читабельный текст во всех сообщений об ошибке должен быть представлен в кодировке UTF-8, для языка по умолчанию [RFC2277].

    Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина равна 8, если в сообщении нет кода ошибки и нет сообщения об ошибке, 10, если имеется код ошибки, но нет сообщения об ошибке, или 10 + длина сообщения об ошибке, если имеется код и сообщение об ошибке. Определенные значения кодов результата для сообщения StopCCN перечислены ниже:

    • 0 - Зарезервировано
    • 1 - Общий запрос ликвидации управляющего соединения
    • 2 - Общая ошибка - код ошибки указывает на разновидность возникшей проблемы
    • 3 - Управляющий канал уже существует
    • 4 - Источник запроса не авторизован для формирования управляющего канала
    • 5 - Версия протокола источника запроса не поддерживается. Код ошибки указывает на более высокую поддерживаемую версию
    • 6 - Источник запроса прекратил работу (shutdown)
    • 7 - Ошибка машины конечных состояний

    Определены следующие значения кодов результата для сообщений CDN:

    0 - Зарезервировано
    1 - Вызов прерван из-за потери несущей.
    2 - Вызов прерван по причине, указанной в коде ошибки
    3 - Вызов прерван по административным причинам
    4 - Вызов не прошел из-за отсутствия необходимых условий (временная причина)
    5 - Вызов не прошел из-за отсутствия необходимых условий (постоянная причина)
    6 - Неверное место назначения
    7 - Вызов не прошел из-за невозможности детектировать несущую
    8 - Вызов не прошел из-за регистрации сигнала "занято"
    9 - Вызов не прошел из-за отсутствия постоянного гудка (разрешение набора номера)
    10 - Вызов не состоялся в пределах временного интервала, выделенного LAC
    11 - Вызов реализовал соединение, но не обнаружено соответствующих кадров

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

    • 0 - Отсутствие ошибки.
    • 1 - Пока нет контрольного соединения для данной пары LAC-LNS.
    • 2 - Длина не корректна.
    • 3 - Одно из значений полей находится вне допустимых пределов или зарезервированное поле имеет ненулевое значение.
    • 4 - Недостаточно ресурсов для осуществления операции
    • 5 - ID-сессии не верно в данном контексте
    • 6 - Произошла ошибка в LAC, специфическая для оборудования производителя.
    • 7 - Испробовать другое место назначение. Если LAC знает о других возможных местах назначения LNS, следует попробовать одно из них. Это может быть использовано для управления LAC, базирующемся на LNS-политике, например, в случае существования многоканальных PPP.
    • 8 - Сессия или туннель были аннулированы (shutdown) из-за получения неизвестной AVP с битом M=1 (смотри раздел 4.2). Сообщение об ошибке должно содержать атрибут некорректного AVP в читаемой текстовой форме.

    Когда используется код общей ошибки = 6, дополнительная информация об ошибке должна быть помещена в поле сообщения об ошибке.

    4.4.3. AVP управления контрольным соединением

    Версия протокола (SCCRP, SCCRQ)

    Версия протокола AVP, тип атрибута - 2, указывает на версию протокола L2TP отправителя. Поле значения атрибута для данной AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

    Ver

    Rev

    Рис. 8. Поле значения атрибута для AVP управления контрольным соединением

    Поле Ver характеризуется целым числом без знака длиной в один октет и содержит код 1. Поле Rev характеризуется целым числом без знака длиной в один октет и содержит код 0. Так характеризуется версия протокола L2TP 1, и модификация версии 0. Заметим, что это не тот же код версии, что включается в заголовок каждого сообщения.

    Эта AVP не должна быть скрытой (бит H должен быть равен 0). Бит M для данной AVP должен быть равен 1. Длина этой AVP равна 8.

    Возможность работы с кадрами (SCCRP, SCCRQ)

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

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано для будущих определений типа кадрового обмена

    A

    S

    Рис. 9. Поле значения атрибута для AVP возможности работы с кадрами

    Поле значения атрибута представляет собой 32-битовую маску, с двумя определенными битами. Если бит A=1, поддерживается асинхронный обмен кадрами. Если бит S=1, поддерживается синхронный обмен кадрами.

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

    Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) равна 10.

    Возможности носителя (SCCRP, SCCRQ)

    AVP возможностей носителя, тип атрибута - 4, предоставляют партнеру указание на типы носителя, поддерживаемые аппаратным интерфейсом отправителя для исходящих вызовов. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано для будущих определений типа несущей среды

    A

    D

    Рис. 10. Поле значения атрибута для AVP возможности носителя

    Это 32-битная маска, с двумя определенными битами. Если бит A =1, поддерживается аналоговый доступ. Если бит D =1, поддерживается цифровой доступ.

    LNS не должен запрашивать исходящих вызовов, специфицирующих значение в AVP типа носителя для приборов, неуказанных в AVP типа носителя, полученных от LAC при установлении управляющего соединения. Такая попытка приведет к тому, что вызов будет отвергнут. Эти AVP должны присутствовать, если отправитель может осуществлять исходящие вызовы, когда это требуется.

    Заметим, что LNS, который не может работать как LAC, а также не поддерживает оборудование для обработки входящих и исходящих вызовов, должен установить биты A и D этого AVP равными 0, или не должен вообще посылать AVP. LNS, который может работать в качестве LAC, и направлять исходящие вызовы, должен устанавливать биты A или D так, как это нужно. Присутствие этого сообщения не гарантирует того, что данный исходящий вызов будет направлен отправителем, если это потребуется, хотя такая возможность и существует.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) равна 10.

    Арбитр конфликта (Tie Breaker (SCCRQ))

    AVP арбитра конфликта, тип атрибута - 5, указывает, что отправитель желает иметь один туннель между заданной парой LAC-LNS.

    Значение Tie Breaker характеризуется 8-октетным кодом, который используется для выбора одного туннеля, когда LAC и LNS требуют формирования туннеля одновременно. Получатель SCCRQ должен проверить, был ли послано партнеру SCCRQ и, если это так, должен сравнить свое значение Tie Breaker с полученным. Более низкое значение "wins" и "loser" должно вызвать молчаливую ликвидацию туннеля. В случае, когда код арбитра присутствует на обеих сторонах и значения равны, обе стороны должны ликвидировать туннели. Если получен tie breaker, а невыполненный просроченный SCCRQ не имеет значения tie breaker, инициатор, который включает AVP Tie Breaker "выигрывает". Если ни одна из сторон не посылает Tie Breaker, тогда открываются два туннеля.

    Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этого AVP должен быть равен 0. Длина этой AVP равна 14.

    Фирменная версия (Firmware Revision) (SCCRP, SCCRQ)

    Фирменная версия AVP, тип атрибута 6, указывает на фирменную версию прибора, пославшего сообщение.

    Поле фирменная версия имеет 2 октета и представляется целым числом без знака, закодированным в формате, который определяется фирмой.

    Для приборов, которые не имеют кода фирменной версии (универсальные ЭВМ, где, например, работают программные модули L2TP), вместо этого может быть сообщена модификация программных модулей L2TP.

    Эта AVP может быть скрыта (H-бит может быть равен 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 8.

    Имя ЭВМ (SCCRP, SCCRQ)

    AVP имени ЭВМ, тип атрибута 7, указывает на имя ЭВМ, реализующей функцию LAC или LNS.

    Имя ЭВМ имеет переменную длину, но должно иметь, по крайней мере, один октет. Это имя должно быть максимально уникальным; для ЭВМ, участвующих в DNS [RFC1034], следует выбирать полное имя домена.

    Эта AVP не должна быть скрыта (H-бит должен быть 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 6 плюс длина имени ЭВМ.

    Имя производителя (SCCRP, SCCRQ)

    AVP имени производителя, тип атрибута 8, содержит специфическую для производителя строку, которая характеризует тип используемого LAC или LNS.

    Имя производителя представляет собой строку октетов произвольной длины. Для обеспечения читаемости текст этой AVP должен быть представлен с помощью символьного набора UTF-8 на языке, выбранном по умолчанию [RFC2277].

    Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для данной AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина имени производителя.

    ID, присвоенное туннелю (SCCRP, SCCRQ, StopCCN)

    AVP ID, присвоенного туннелю, тип атрибута 9, несет в себе ID, присвоенное туннелю отправителем.

    ID, присвоенное туннелю, содержит в себе 2-октетное целое неравное нулю число без знака.

    AVP ID, присвоенное туннелю, определяет код, используемый при мультиплексировании и демультиплексировании в случае работы с несколькими туннелями между LNS и LAC. Партнер L2TP должен помещать этот код в поле заголовка ID-туннеля всех управляющих и информационных сообщений, пересылаемых через туннель. Пока от партнера не получена AVP с присвоенным ID-туннеля, управляющие сообщения должны посылаться этому партнеру со значением ID-туннеля = 0.

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

    Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

    Размер приемного окна (Receive Window Size (SCCRQ, SCCRP))

    Размер приемного окна AVP, тип атрибута 10, специфицирует размер приемного окна, которое предлагает удаленный партнер. Размер окна характеризуется 2-октетным целым числом без знака.

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

    Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 8.

    Приглашение (Challenge (SCCRP, SCCRQ))

    AVP приглашения, тип атрибута 11, указывает, что отправивший его партнер хочет аутентифицировать концы туннеля, используя CHAP-стиль аутентификационного механизма. Вызов содержит один или более октетов произвольной информации.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина приглашения (challenge).

    Отклик на приглашение (Challenge Response (SCCCN, SCCRP))

    AVP отклика, тип атрибута 13, направляет ответ на полученное сообщение.

    Поле отклик содержит 16 октетов, соответствуя CHAP-стилю [RFC1994] отклика на вызов.

    Эта AVP должна присутствовать в SCCRP или SCCCN, если приглашение было получено в предыдущем SCCRQ или SCCRP. Для целей вычисления значения ID в CHAP-отклике используется код типа сообщения AVP для этого кадра (например, 2 для SCCRP, и 3 для SCCCN).

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 22.

    4.4.4. AVP управления вызовом

    Q.931 код причины (CDN)

    AVP, тип атрибута 12, используется, чтобы предоставить дополнительную информацию в случае непреднамеренного разрыва соединения. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Код причины

    Сообщение причины

    Сообщение-рекомендация

    Рис. 11. Поле значения атрибута для AVP кода причины Q.931

    В качестве кода причины присылается код Q.931, а в качестве сообщения причины - сообщение Q.931 (например, DISCONNECT), ассоциированное с кодом причины. Оба кода присылаются в их исходных кодировках ITU [DSS1]. Дополнительный ASCI-текст сообщения-рекомендации может быть включен (присутствие определяется с помощью кода длины AVP) для дальнейшего уточнения причины отсоединения.

    Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 9, плюс размер сообщения Advisory.

    ID, присвоенное сессии (CDN, ICRP, ICRQ, OCRP, OCRQ)

    AVP ID, присвоенного сессии, тип атрибута 14, содержит ID, присвоенное сессии отправителем сообщения. ID, присвоенное сессии, представляет собой 2-октетное целое, ненулевое число без знака.

    AVP ID, присвоенного сессии, определяет код, который используется для мультиплексирования и демультиплексирования данных, посылаемых через туннель между LNS и LAC. Партнер L2TP должен поместить этот код в поле заголовка ID-сессии всех управляющих и информационных сообщений, которые пересылаются по туннелю в рамках данной сессии. До того как от партнера придет AVP ID, присвоенного сессии, управляющие сообщения должны посылаться партнеру с ID-сессии, равным нулю.

    В управляющем сообщении CDN, используется первое AVP ID-сессии, полученное партнером, позволяя партнеру идентифицировать соответствующий туннель, даже если CDN послано до получения ID, присвоенное сессии.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

    Порядковый номер вызова (ICRQ, OCRQ)

    AVP порядкового номера вызова, тип атрибута 15, несет в себе идентификатор, присвоенный данному вызову LAC или LNS. Порядковый номер вызова представляет собой 32-битовый код.

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

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

    Максимальный BPS (OCRQ)

    AVP максимального BPS, тип атрибута 16, характеризует минимальную приемлемую скорость передачи канала для данного вызова.

    Максимальный BPS представляет собой 32-битовый код, характеризующий скорость передачи в битах в секунду.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

    Максимальный BPS (OCRQ)

    AVP максимального BPS, тип атрибута 17, характеризует максимальную приемлемую скорость канала для данного вызова.

    Максимальный BPS представляет собой 32-битный код, характеризующий скорость передачи в битах в секунду.

    Эта AVP может быть скрытым (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) этого AVP равна 10.

    Тип носителя (ICRQ, OCRQ)

    AVP типа носителя, тип атрибута 18, характеризует тип носителя для входящего или исходящего вызовов. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано для будущих определений типа несущей среды

    A

    D

    Рис. 12. Поле значения атрибута для AVP типа носителя

    Тип носителя представляет собой 32-битовую маску, которая характеризует возможности несущей среды для вызова (ICRQ) или требования к среде для данного вызова (OCRQ). Если бит A=1, то вызов относится к аналоговому каналу. Если бит D=1, то вызов относится к цифровому каналу. Могут быть установлены оба бита, что может означать, что тип канала не определен, или допустима работа, как с аналоговым, так и цифровым каналами.

    Биты в поле значение данной AVP должны устанавливаться LNS для OCRQ, если они были установлены в AVP возможностей носителя, полученной от LAC в период установления управляющего соединения.

    Можно не устанавливать ни A, ни D-биты в ICRQ. Такая установка может означать, что вызов не был получен по физическому каналу (например, если LAC и PPP находятся в той же подсистеме).

    Эта AVP может быть скрыта (H-бит может быть 0 или 1). M-бит этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

    Тип кадрового обмена (ICCN, OCCN, OCRQ)

    AVP типа кадрового обмена, тип атрибута 19, характеризует тип кадров для входящих и исходящих вызовов. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано для будущих определений типа кадрового обмена

    A

    S

    Рис. 13. Поле значения атрибута для AVP типа кадрового обмена

    Тип кадрового обмена представляет собой 32-битовую маску, которая указывает тип кадрового обмена PPP, запрошенный для OCRQ, или тип кадрового обмена PPP, согласованный для OCCN или ICCN. Тип кадрового обмена может быть использован как указание PPP на LNS, какую из канальных опций использовать для согласования с LCP [RFC1662].

    Бит A указывает на асинхронный обмен кадрами. Бит S указывает на синхронный обмен кадрами. Для OCRQ могут быть установлены оба бита, что будет означать допустимость обоих типов кадрового обмена.

    Биты в поле значение этой AVP должны устанавливаться только LNS для OCRQ, если они были установлены в AVP возможностей кадрового обмена, полученной от LAC в процессе установления управляющего соединения. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

    Вызванный номер (Called Number (ICRQ, OCRQ))

    AVP вызванного номера, тип атрибута 21, характеризует телефонный номер, куда посылается вызов для OCRQ.

    Вызванный номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.

    Вызывающий номер (Calling Number (ICRQ))

    AVP вызывающего номера, тип атрибута 22, содержит телефонный номер входящего вызова.

    Вызывающий номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.

    Субадрес (ICRQ, OCRQ)

    AVP субадреса, тип атрибута 23, несет в себе дополнительную информацию по вызову.

    Субадрес является ASCII-строкой. Может быть, необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина субадреса.

    Скорость канала (Tx) (Connect Speed (ICCN, OCCN))

    AVP скорости канала (Tx) BPS, тип атрибута 24, характеризует быстродействие устройства, выбранного для попытки установления соединения. Скорость канала (Tx) BPS содержит 4 октета и характеризует скорость обмена в битах в секунду.

    Когда присутствует опционная AVP скорости соединения Rx, значение этой AVP представляет быстродействие канала с точки зрения LAC (например, скорость передачи данных, передаваемых от LAC в удаленную систему). Когда опционная AVP скорости соединения Rx отсутствует, быстродействие канала между удаленной системой и LAC предполагается симметричным и представляется одной величиной этой AVP.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

    Скорость соединения Rx (Connect Speed (ICCN, OCCN))

    AVP скорости соединения Rx, тип атрибута 38, представляет скорость канала с точки зрения LAC (например, информация, передаваемая от удаленной системы в LAC). Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    BPS (H)

    BPS (L)

    Рис. 14. Поле значения атрибута для AVP скорости соединения Rx

    BPS имеет 4 октета, характеризующие скорость обмена в битах в секунду. Присутствие этой AVP означает, что быстродействие канала может быть асимметричным с учетом скорости передачи, заданной в AVP скорости соединения Rx.

    Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

    ID физического канала (ICRQ, OCRP)

    AVP ID физического канала, тип атрибута 25, представляет код физического канала, присвоенный ему производителем, и используемый при вызове. ID физического канала имеет 4 октета и служит только для целей регистрации.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

    ID частной группы (ICCN)

    AVP ID частной группы, тип атрибута 37, используется LAC для индикации того, что этот вызов ассоциируется с определенной группой клиентов. ID частной группы представляет собой строку октетов произвольной длины.

    LNS может воспринимать PPP-сессию, а также сетевой трафик в рамках сессии специальным образом, определенным партнером. Например, если LNS соединен с несколькими частными сетями, использующими незарегистрированные адреса, эта AVP может быть включена LAC, чтобы индицировать, что данный вызов должен быть ассоциирован с одной из частных сетей.

    ID частной группы представляет собой строку, соответствующую таблице в LNS, которая определяет конкретные характеристики выбранной группы. LAC может определить ID частной группы из отклика RADIUS, локальной конфигурации, или некоторых других источников.

    Эта AVP может быть скрытой (H-бит может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина ID частной группы.

    Необходима нумерация (Sequencing Required (ICCN, OCCN))

    AVP Sequencing Required, тип атрибута 39, сообщает LNS, что порядковые номера должны всегда присутствовать в информационном канале. Эта AVP не имеет поля значения атрибута.

    Эта AVP не должна быть скрытой (H-бит должен быть 0). M-бит этой AVP должен быть равен 1. Длина этой AVP равна 6.

    4.4.5. AVP прокси LCP и аутентификации

    LAC может откликнуться на вызов и согласовать LCP с удаленной системой, возможно для того чтобы установить идентичность системы. В этом случае, эти AVP могут быть включены для индикации свойств канала, которые запросила удаленная система в исходном состоянии, свойства, согласованные удаленной системой и LAC после согласования, а также аутентификационная информация PPP, полученная LAC. Эта информация может быть использована, чтобы инициировать PPP LCP и аутентификационные системы в LNS, позволяя PPP продолжить работу без повторного согласования параметров с LCP.

    LCP CONFREQ, полученный в исходном состоянии (ICCN)

    В AVP, полученного в исходном состоянии LCP CONFREQ, тип атрибута 26, предоставляет LNS исходное сообщение CONFREQ, полученное LAC от партнера PPP.

    LCP CONFREQ является копией тела полученного исходного CONFREQ, начиная с первой опции тела сообщения LCP. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

    Последний посланный LCP CONFREQ (ICCN)

    В AVP последнего посланного LCP CONFREQ, тип атрибута 27, предоставляет LNS последнего CONFREQ, посланного LAC партнеру PPP.

    LCP CONFREQ является копией тела финального CONFREQ, посланного клиенту с целью завершения LCP-согласования, начиная с первой опции тела LCP-сообщения. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

    Последний полученный LCP CONFREQ (ICCN)

    AVP последнего полученного LCP CONFREQ, тип атрибута 28, предоставляет LNS последнего CONFREQ, полученного концентратором LAC от PPP-партнера.

    LCP CONFREQ является копией тела последнего CONFREQ, полученного от клиента с целью завершения процедуры согласования LCP, начиная с первой опции тела LCP-сообщения.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

    Тип прокси Authen (ICCN)

    AVP типа прокси Authen, тип атрибута 29, определяет, должна ли использоваться прокси аутентификация. Тип Authen представляет собой 2-октетное целое число без знака.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 8. Определенные значения типа Authen:

    0 - Зарезервировано
    1 - Текстовой обмен имя пользователя/пароль
    2 - PPP CHAP
    3 - PPP PAP
    4 - Никакой аутентификации
    5 - Microsoft CHAP версия 1 (MSCHAPv1)

    Эта AVP должна присутствовать, если должна использоваться прокси аутентификация. Если она отсутствует, тогда предполагается, что этот партнер не может выполнить прокси аутентификацию, необходимую для повторного запуска фазы аутентификации в LNS, если клиент уже вошел в эту фазу с LAC (который может быть определен AVP Proxy LCP, если имеется). Далее описаны соответствующие AVP для каждого типа аутентификации.

    Имя прокси Authen (ICCN)

    AVP имени прокси Authen, тип атрибута 30, специфицирует имя аутентифицируемого клиента при использовании прокси аутентификации.

    Имя Authen является строкой октетов произвольной длины. Оно содержит имя, специфицированное в отклике аутентификации клиента.

    Эта AVP должна присутствовать в сообщениях, содержащих AVP типа Proxy Authen с типом Authen 1, 2, 3 или 5. Может быть, желательно применить AVP-сокрытие для защиты имени, представленного открытым текстом. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 6 плюс длина имени.

    Приглашение прокси Authen (ICCN)

    AVP приглашения прокси Authen, тип атрибута 31, специфицирует приглашение, посланное LAC партнеру PPP при использовании прокси аутентификации. Приглашение представляет собой строку из одного или более октетов.

    Эта AVP должна присутствовать для типов прокси Authen 2 и 5. Поле приглашения содержит приглашение CHAP, предлагаемое LAC клиенту.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6, плюс длина приглашения.

    ID прокси Authen (ICCN)

    AVP ID прокси Authen, тип атрибута 32, специфицирует код ID PPP-аутентификации, которая реализуется между LAC и PPP-партнером, когда используется прокси аутентификация. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

    Зарезервировано

    ID

    Рис. 15. Поле значения атрибута для AVP ID прокси Authen

    ID представляет собой 2-октетное целое число без знака, старший октет которого должен быть равен нулю.

    AVP прокси Authen ID должна присутствовать для типов Proxy authen 2, 3 и 5. Для 2 и 5, поле ID содержит значение ID-байта переданное LAC клиенту в его приглашении (Challenge). Для 3 - это значение идентификатора Authenticate-Request. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0.

    Отклик прокси Authen Response (ICCN)

    AVP отклика прокси Authen, тип атрибута 33, специфицирует отклик аутентификации PPP, полученный LAC от PPP-партнера, когда используется прокси аутентификация. Отклик представляет собой строку октетов произвольной длины.

    Эта AVP должна присутствовать для типов прокси authen 1, 2, 3 и 5. Поле отклика содержит отклик клиента на приглашение. Для типов прокси authen 2 и 5, это поле содержит значение отклика, полученное LAC. Для типов 1 или 3, оно несет в себе открытый текст пароля, полученного LAC от клиента. В случае паролей с открытым текстом рекомендуется AVP-сокрытие.

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина отклика.

    4.4.6. AVP статуса вызова

    Ошибки вызова (WEN)

    AVP ошибок вызова, тип атрибута 34, используется LAC для посылки LNS информации об ошибке. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано

    Ошибка CRC (H)

    Ошибка CRC (L)

    Ошибка в формате кадра (H)

    Ошибка в формате кадра (L)

    Аппаратное переполнение (H)

    Аппаратное переполнение (L)

    Переполнение буфера (H)

    Переполнение буфера (L)

    Ошибка таймаута (H)

    Ошибка таймаута (L)

    Ошибка выравнивания (H)

    Ошибка выравнивания (L)

    Рис. 16. Поле значения атрибута для AVP ошибок вызова

    Определены следующие поля:

    Зарезервировано

    Не используется, должно равняться нулю 0

    Ошибки CRC

    Число PPP-кадров, полученных с CRC-ошибками с момента реализации вызова

    Ошибки формата кадров

    Число полученных PPP-пакетов с неверным форматом

    Аппаратное переполнение

    Число переполнений аппаратного буфера с момента реализации вызова

    Число переполнений буфера

    Число зарегистрированных переполнений буфера с момента реализации вызова

    Число ошибок таймаутов

    Число таймаутов с момента реализации вызова

    Ошибки выравнивания

    Число ошибок выравнивания с момента реализации вызова

    Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 32.

    ACCM (SLI)

    AVP ACCM, тип атрибута 35, используется LNS, чтобы проинформировать LAC о ACCM, согласуемом LNS с PPP-партнером. Поле значения атрибута для этого AVP имеет следующий формат:

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    Зарезервировано

    Послать ACCM (H)

    Послать ACCM (L)

    Получить ACCM (H)

    Получить ACCM (L)

    Рис. 17. Поле значения атрибута для AVP ACCM

    Посланное ACCM и полученное ACCM имеют по 4 октета, перед которыми размещаются 2 октета зарезервированного количества. Значение посланного ACCM должно использоваться LAC для обработки пакетов, которые он отправляет через канал. Значение полученного ACCM должно использоваться LAC для обработки пакетов, которые он получает через канал. Значения по умолчанию, используемые LAC для обоих этих полей равны 0xFFFFFFFF. LAC должен учитывать значения этих полей, если только нет конфигурационной информации, которая указывает, что запрошенная маска должна быть модифицирована, чтобы разрешить операцию.

    Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 16.

    5. Протокольные операции

    Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:

    1. Установление управляющего канала для туннеля, и

    2. Формирование сессии в соответствии с запросом входящего или исходящего вызова.

    Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.

    Рис. 18. PPP-туннелирование

    5.1. Установление контрольного соединения

    Управляющее соединение является первичным, которое должно быть реализовано между LAC и LNS, прежде чем запускать сессию. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т.д.. Для установления управляющего соединения осуществляется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

    LAC или LNS LAC или LNS

    SCCRQ ->

    <- SCCRP

    SCCCN ->

    <- ZLB ACK

    Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

    5.1.1. Аутентификация туннеля

    L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено.

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

    5.2. Установление сессии

    После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.

    5.2.1. Установление входящего вызова

    Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

    LAC LNS
    (Обнаружен вызов)
    ICRQ ->
    <- ICRP
    ICCN ->
    <- ZLB ACK

    Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

    5.2.2. Установление исходящего вызова

    Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

    LAC LNS

    <- OCRQ

    OCRP ->
    (Выполнить операцию вызова)
    OCCN ->

    <- ZLB ACK

    Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

    5.3. Переадресация кадров PPP

    Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков, и т.д., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет, и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.

    Отправитель сообщения, ассоциированный с определенной сессией и туннелем, помещает ID сессии и туннеля (специфицированные партнером) в соответствующие поля заголовка всех исходящих сообщений. Таким способом, PPP-кадры мультиплексируются и демультиплексируются через общий туннель для данной пары LNS-LAC. Для заданной пары LNS-LAC может быть реализовано несколько туннелей, а для любого туннеля несколько сессий.

    Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля.

    5.4. Использование порядковых номеров в канале данных

    Порядковые номера определены в заголовке L2TP для управляющих сообщений и опционно для информационных (смотри раздел 3.1). Они используются для организации надежной транспортировки управляющих сообщений (смотри раздел 5.8) и опционно информационных сообщений. Каждый партнер поддерживает отдельную нумерацию для управляющего соединения и для каждой информационной сессии в пределах туннеля.

    В отличие от канала управления L2TP, информационный канал L2TP не использует нумерацию сообщений для повторной пересылки. Скорее информационные сообщения могут использовать порядковые номера для детектирования потерь пакетов и/или восстановления исходной последовательности пакетов, которые могут быть перемешаны при транспортировке. LAC может потребовать, чтобы порядковые номера присутствовали в информационных сообщениях, посредством AVP необходимого упорядочения (смотри раздел 4.4.6). Если эта AVP присутствует при установлении сессии, порядковые номера должны присутствовать всегда. Если эта AVP отсутствует, упорядочивание сообщений находится под управлением LNS. Сервер LNS управляет разрешением и запрещением использования порядковых номеров путем посылки информационных сообщений с или без порядковых номеров на протяжении всей сессии. Таким образом, если LAC получает информационное сообщение без порядкового номера, он должен прекратить посылку сообщений с порядковыми номерами. Если LAC получает информационное сообщение с порядковым номером, он должен начать посылку информационных сообщений с порядковыми номерами. Если LNS разрешает нумерацию сообщений после предыдущего запрещения в ходе сессии, порядковые номера устанавливаются в соответствии с состоянием их последнего применения.

    LNS может инициировать запрет нумерации сообщений в любое время в ходе сессии (включая первое информационное сообщение). Рекомендуется, чтобы для соединений, где возможна потеря или изменение порядка пакетов, нумерация сообщений была всегда разрешена. Запрещение нумерации возможно, только когда риск ошибки считается приемлемым. Например, если PPP-сессия при туннелировании не использует каких-либо посторонних протоколов или сжатия данных и работает только с IP (как это определено в ходе процедуры инициализации), тогда LNS может запретить нумерацию пакетов так как IP сам следит за их порядком.

    5.5. Keepalive (Hello)

    Механизм keepalive используется L2TP, для того чтобы разделять простои туннеля от длительных периодов отсутствия управления или информационной активности в туннеле. Это выполняется путем введения управляющих сообщений Hello (смотри раздел 6.5) после специфицированного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. Как для любого другого управляющего сообщения, при недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путем введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля.

    5.6. Прерывание сессии

    Прерывание сессии может быть инициировано LAC или LNS и выполняется путем посылки управляющего сообщения CDN. После того как последняя сессия прервана, управляющее соединение может быть также разорвано. Ниже приводится типовой обмен управляющими сообщениями:

    LAC или LNS LAC или LNS
    CDN ->
    (Clean up)

    <- ZLB ACK

    (Clean up)

    5.7. Разрыв контрольного соединения

    Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN. Получатель StopCCN должен послать ZLB ACK, чтобы подтвердить получение сообщения, и поддерживает состояние управляющего соединения на уровне достаточном для корректного приема StopCCN, а также повторения цикла, если ZLB ACK потеряно. Рекомендуемое время повторения цикла равно 31 секунде (смотри раздел 5.8). Ниже приводится типовой обмен управляющими сообщениями:

    LAC или LNS LAC или LNS
    StopCCN ->
    (Clean up)

    <- ZLB ACK

    (Wait)

    (Clean up)

    Программа может ликвидировать туннель и все сессии туннеля путем посылки StopCCN. Таким образом, не нужно прерывать каждую сессию, если разорван туннель.

    5.8. Надежная доставка управляющих сообщений

    L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений. Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле.

    Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK.

    Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB.

    Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB.

    Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения.

    Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы.

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

    Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений. Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым.

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

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

    6. Протокольная спецификация контрольного соединения

    Следующие сообщения управляющего соединения используются для установления, ликвидации и поддержания L2TP-туннелей. Вся информация посылается в порядке, определенном для сети (старший октет первый). Любые "резервные" или "пустые" поля для обеспечения протокольной масштабируемости должны содержать 0.

    6.1. Start-Control-Connection-Request (SCCRQ)

    Start-Control-Connection-Request (SCCRQ) является управляющим сообщением, используемым для инициализации туннеля между LNS и LAC. Оно посылается LAC или LNS в процессе установления туннеля. Следующие AVP должны присутствовать в SCCRQ:

    AVP типа сообщения (Message Type AVP)
    Версия протокола (Protocol Version)
    Имя ЭВМ (Host Name)
    Возможности кадрового обмена (Framing Capabilities)
    Присвоенный туннелю ID (Assigned Tunnel ID)

    Следующие AVP могут присутствовать в SCCRQ:

    Возможности канала (Bearer Capabilities)
    Размер премного окна (Receive Window Size)
    Приглашение (Challenge)
    Арбитр конфликта (Tie Breaker)
    Фирменная версия (Firmware Revision)
    Имя производителя (Vendor Name)

    6.2. Start-Control-Connection-Reply (SCCRP)

    Start-Control-Connection-Reply (SCCRP) является управляющим сообщением, посланным в ответ на сообщение SCCRQ. SCCRP используется для индикации того, что SCCRQ было принято и установление туннеля должно быть продолжено. Следующие AVP должны присутствовать в SCCRP:

    Тип сообщения (Message Type)
    Версия протокола (Protocol Version)
    Framing Capabilities
    Имя ЭВМ (Host Name)
    Присвоенный туннелю ID (Assigned Tunnel ID)

    Следующие AVP могут присутствовать в SCCRP:

    Возможности несущего канала (Bearer Capabilities)
    Фирменная версия (Firmware Revision)
    Имя производителя (Vendor Name)
    Размер приемного окна (Receive Window Size)
    Приглашение (Challenge)
    Отклик на приглашение (Challenge Response)

    6.3. Start-Control-Connection-Connected (SCCCN)

    Start-Control-Connection-Connected (SCCCN) является управляющим сообщением, посылаемым в ответ на SCCRP. SCCCN завершает процесс установления туннеля.

    Следующее AVP должно присутствовать в SCCCN:

    Message Type

    Следующее AVP может присутствовать в SCCCN:

    Challenge Response

    6.4. Stop-Control-Connection-Notification (StopCCN)

    Stop-Control-Connection-Notification (StopCCN) является управляющим сообщением, посылаемым LAC или LNS для информирования своего партнера о том, что туннель закрывается (shutdown) и управляющий канал должен быть разорван. Кроме того, все активные сессии закрываются (без посылки каких-либо управляющих сообщений). Причина для отправки этого запроса указывается в AVP кода результата. Явно отклик на это сообщение не посылается, используется отклик ACK, который используется для обеспечения надежной связи для управляющего соединения транспортного уровня

    Следующие AVP должны присутствовать в StopCCN:

    Тип сообщения (Message Type)
    Присвоенный туннелю ID (Assigned Tunnel ID)
    Результирующий код (Result Code)

    6.6. Запрос входящего вызова ICRQ (Incoming-Call-Request)

    Incoming-Call-Request (ICRQ) является управляющим сообщением, посылаемым LAC к LNS, когда зарегистрирован входящий вызов. Это первое из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.

    ICRQ используется для индикации того, что для данного вызова должна быть установлена сессия между LAC и LNS, и предоставляет LNS параметры сессии. LAC может отложить ответ на вызов, до тех пор пока он не получит ICRP от LNS, указывающий, что должна быть запущена сессия. Этот механизм позволяет LNS получить достаточно информации о вызове, прежде чем будет определено, следует ли на него отвечать. В качестве альтернативы LAC может ответить на вызов, согласовать аутентификацию LCP и PPP, и использовать информацию, полученную для выбора LNS. В этом случае, к моменту получения сообщения ICRP на вызов уже получен ответ; в этом случае LAC просто разыгрывает шаги "call indication" и "call answer". Следующие AVP должны присутствовать в ICRQ:

    Тип сообщения
    ID, Присвоенный сессии (Assigned Session ID)
    Call Serial Number

    Следующие AVP могут присутствовать в ICRQ:

    Тип носителя (Bearer Type)
    ID физического канала (Physical Channel ID)
    Вызывающий номер (Calling Number)
    Вызванный номер (Called Number)
    Субадрес (Sub-Address)

    6.7. Отклик входящего вызова ICRP (Incoming-Call-Reply)

    Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.

    ICRP используется для индикации того, что ICRQ успешен, и для LAC, чтобы ответить на вызов, если это еще не было сделано. Оно позволяет также LNS индицировать необходимые параметры для L2TP-сессии. Следующие AVP должны присутствовать в ICRP:

    Тип сообщения (Message Type)
    ID, присвоенный сессии (Assigned Session ID)

    6.8. Incoming-Call-Connected (ICCN)

    Incoming-Call-Connected (ICCN) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение ICRP. Оно является третьим сообщением из трех сообщений обмена, используемых для установления сессий в пределах L2TP-туннеля.

    ICCN используется для индикации того, что ICRP принято, на вызов получен ответ, а L2TP-сессия должна перейти в состояние "установлена". Оно также предоставляет дополнительную информацию LNS о параметрах, используемых для вызова, на который получен ответ (параметры, которые не всегда быть доступны в момент посылки ICRQ).

    Следующие AVP должны присутствовать в ICCN:

    Тип сообщения (Message Type)
    Скорость обмена в канале ((Tx) Connect Speed)
    Тип кадрового обмена (Framing Type)

    Следующие AVP могут присутствовать в ICCN:

    Initial Received LCP CONFREQ
    Последнее посланное LCP CONFREQ
    Последнее полученное LCP CONFREQ
    Тип Proxy Authen
    Имя Proxy Authen
    Приглашение Proxy Authen
    Прокси Authen ID
    Отклик прокси Authen
    ID частной группы
    Скорость обмена соединения (Rx Connect Speed)
    Необходима нумерация (Sequencing Required)

    6.9. Запрос исходящего вызова OCRQ (Outgoing-Call-Request)

    Outgoing-Call-Request (OCRQ) является управляющим сообщением, посылаемым от LNS к LAC для индикации того, что необходимо осуществить исходящий вызов LAC. Оно является первым сообщением из трех, которые используются для установления сессии в пределах L2TP-туннеля.

    OCRQ используется для индикации того, что сессия для данного вызова между LNS и LAC установлена и предоставляет LAC параметры L2TP-сессии и вызова.

    LNS должен получить от LAC AVP Bearer Capabilities (возможностей носителя) на фазе установления туннеля, для того чтобы послать LAC исходящий вызов. Следующие AVP должны присутствовать в OCRQ:

    Тип сообщения (Message Type)
    ID, присвоенное сессии (Assigned Session ID)
    Call Serial Number
    Минимальный BPS
    Максимальный BPS
    Тип несущего канала (Bearer Type)
    Тип кадрового обмена (Framing Type)
    Телефонный номер адресата (Called Number)

    Следующие AVP могут присутствовать в OCRQ:

    Sub-Address

    6.10. Отклик исходящего вызова OCRP (Outgoing-Call-Reply)

    Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ. Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP:

    Тип сообщения (Message Type)
    Assigned Session ID

    Следующие AVP могут присутствовать в OCRP:

    Physical Channel ID

    6.11. Outgoing-Call-Connected (OCCN)

    Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля.

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

    Тип сообщения (Message Type)
    Скорость обмена ((Tx) Connect Speed)
    Тип кадрового обмена (Framing Type)

    Следующие AVP могут присутствовать в OCCN:

    Скорость обмена (Rx Connect Speed)
    Необходима нумерация (Sequencing Required)

    6.12. Call-Disconnect-Notify (CDN)

    Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции.

    Следующие AVP должны присутствовать в CDN:

    Message Type
    Код результата (Result Code)
    Assigned Session ID

    Следующие AVP могут присутствовать в CDN:

    Код причины Q.931

    6.13. WAN-Error-Notify (WEN)

    Сообщение WAN-Error-Notify является L2TP управляющим сообщением, посылаемым от LAC к LNS для индикации условий ошибки WAN (условия, которые реализовались в интерфейсе, поддерживающим PPP). Счетчики в этом сообщении являются накопительными. Это сообщение должно посылаться, только когда произошла ошибка, и не чаще чем раз в 60 секунд. Счетчики сбрасываются, когда реализуется новый вызов. Следующие AVP должны присутствовать в WEN:

    Тип сообщения (Message Type)
    Ошибки вызова (Call Errors)

    6.14. Set-Link-Info (SLI)

    Сообщение Set-Link-Info является управляющим сообщением L2TP, посланным от LNS к LAC для установления согласуемых опций PPP. Эти опции можно изменять в любое время на протяжении реализации вызова, таким образом, LAC должен быть способен обновлять свою собственную информацию вызова и поведение на протяжении активной PPP-сессии. Следующие AVP должны присутствовать в SLI:

    Тип сообщения (Message Type)
    ACCM

    7. Машины состояний управляющего соединения

    Управляющие сообщения, определенные в разделе 6 пересылаются в соответствии с таблицами состояний, описанными в данном разделе. Таблицы определены для входящих вызовов, исходящих вызовов, а также для инициации самого туннеля. Таблицы состояний не задают таймауты и поведение при повторной передаче, так как это определяется механизмами, рассмотренными в секции 5.8.

    7.1. Протокольные операции контрольного соединения

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

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

    Некорректное управляющее сообщение определяется как сообщение, которое содержит тип сообщения, помеченное как обязательное (смотри раздел 4.4.1) и неизвестное программе управляющее сообщение, которое получено в правильной последовательности (например, в ответ на SCCRQ послано SCCCN).

    Примеры управляющих сообщений с некорректным форматом включают те, которые имеют неверное значение в своем заголовке, содержат AVP, сформированную некорректно или чье значение находится вне допустимых пределов, или сообщение, которое не имеет необходимого AVP. Управляющее сообщение с некорректным заголовком должно быть отброшено. Управляющее сообщение с некорректным AVP должно проверить M-бит для этого AVP, чтобы определить, является ли ошибка исправимой или нет.

    Неверно сформатированное, но исправимое необязательное (M-бит равен нулю) AVP в управляющем сообщении должно рассматриваться, также как нераспознанное необязательное AVP. Таким образом, если получена AVP с неверным форматом и битом M=1, сессия или туннель должны быть разорваны с соответствующим кодом результата или ошибки. Если M-бит не равен 1, AVP должно игнорироваться (за исключением записи об ошибке в местном журнале).

    Это не должно рассматриваться, как разрешение посылать неверно сформатированные AVP, а лишь как указание на то, как реагировать на неверно сформатированное сообщение в случае его получения. Невозможно перечислить все возможные ошибки в сообщениях и дать совет, как с ними обходиться. Примером исправимой неверно сформатированной AVP может быть случай, когда получена AVP скорости соединения Rx, атрибут 38, с полем длина 8, а не 10 и BPS с двумя, а не четырьмя октетами. Так как Rx Connect Speed не является обязательным, такое условие не может рассматриваться как катастрофическое. Как таковое, управляющее сообщение должно быть воспринято, как если бы AVP не было получено (за исключением записи в локальный журнал ошибок). В нескольких случаях в последующих таблицах, посылается протокольное сообщение, а затем случается "сброс". Заметим, что, несмотря на ликвидацию туннеля одним из партнеров, в течение определенного времени механизм надежной доставки должен быть сохранен (смотри раздел 5.8) вплоть до окончательного закрытия туннеля. Это позволяет сообщениям управления туннеля надежно доставляться партнеру.

    7.2. Состояния контрольного соединения

    Протокол управляющего соединения L2TP не отличим от LNS и LAC, но различен для отправителя и получателя. Партнером инициатором является тот, кто первым формирует туннель (в конфликтной ситуации, это победитель). Так как LAC или LNS может быть инициатором, может произойти столкновение. Смотри Tie Breaker AVP в разделе 4.4.3, где описано разрешение такого конфликта.

    7.2.1. Установление контрольного соединения

    Состояние

    Событие

    Действие

    Новое состояние

    Idle

    Local Open request

    Послать SCCRQ

    wait-ctl-reply

    Idle

    Получить SCCRQ,

    приемлемо

    Послать SCCRP

    wait-ctl-conn

    idle

    Получить SCCRQ,

    не приемлемо

    Послать StopCCN,

    Clean up

    idle

    idle

    Получить SCCRP

    Послать StopCCN

    Clean up

    idle

    Idle

    Получить SCCCN

    Clean up

    idle

    wait-ctl-reply

    Получить SCCRP,

    приемлемо

    Послать SCCCN,

    Послать tunnel-open

    ожидающей сессии

    established

    wait-ctl-reply

    Получить SCCRP,

    не приемлемо

    Послать StopCCN,

    Clean up

    idle

    wait-ctl-reply

    Получить SCCRQ,

    проигрыш tie-breaker

    Clean up,

    Re-queue SCCRQ

    для состояния idle

    idle

    wait-ctl-reply

    Получить SCCCN

    Послать StopCCN

    Clean up

    idle

    wait-ctl-conn

    Получить SCCCN,

    приемлемо

    Послать tunnel-open

    ожидающей сессии

    established

    wait-ctl-conn

    Получить SCCCN,

    не приемлемо

    Послать StopCCN,

    Clean up

    idle

    wait-ctl-conn

    Получить SCCRP,

    SCCRQ

    Послать StopCCN,

    Clean up

    idle

    Established

    Local Open request

    (новый вызов)

    Послать tunnel-open

    ожидающей сессии

    established

    Еstablished

    Административное

    закрытие туннеля

    Послать StopCCN

    Clean up

    idle

    Established

    Получить SCCRQ,

    SCCRP, SCCCN

    Send StopCCN

    Clean up

    idle

    Idle

    wait-ctl-reply,

    wait-ctl-conn,

    established

    Получить StopCCN

    Clean up

    idle

    Состояниями, ассоциированными с LNS или LAC для установления управляющего соединения, являются:

    Idle (пассивно)

    Инициатор и получатель начинают функционирование из этого состояния. Инициатор посылает SCCRQ, в то время как получатель остается в пассивном состоянии вплоть до получения SCCRQ.

    wait-ctl-reply (ожидание управляющего отклика)

    Инициатор проверяет, не поступил ли запрос на установление еще одного соединения от того же самого партнера, и если это так, реагирует на столкновение, как это описано в разделе 5.8.

    Когда получено SCCRP, оно проверяется на совместимость версии. Если версия отклика ниже версии посланного запроса, должна использоваться более старая (низшая) версия. Если версия отклика более ранняя, и она поддерживается, инициатор переходит в состояние "установлено". Если версия более ранняя и не поддерживается, партнеру должно быть послано StopCCN, а инициатор переходит в исходное состояние и разрывает туннель.

    wait-ctl-conn (ожидание управляющего соединения)

    Состояние, когда ожидается SCCCN; после получения, проверяется отклик приглашения. Туннель оказывается установленным, или разорванным, если не прошла аутентификация.

    Established (установлено)

    Установленное соединение может быть аннулировано по местным причинам или в результате получения Stop-Control-Connection-Notification. В случае местного разрыва инициатор должен послать Stop-Control-Connection-Notification и ликвидировать туннель.

    Если инициатор получает Stop-Control-Connection-Notification, он должен разорвать туннель.

    7.3. Временные соображения

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

    7.4. Входящие вызовы

    Сообщение Incoming-Call-Request генерируется LAC, когда зарегистрирован входящий вызов (например, звонки в телефонной линии). LAC выбирает ID-сессии и порядковый номер и индицирует тип носителя вызова. Модемы должны всегда индицировать аналоговый тип вызова. Вызовы ISDN должны индицировать цифровой тип вызова, когда доступно цифровое обслуживание и используется настройка скорости обмена, и аналоговый, если применен цифровой модем. Вызывающий номер, вызываемый номер и субадрес могут быть включены в сообщение, если они доступны через телефонную сеть.

    Раз LAC посылает Incoming-Call-Request, он ждет отклика от LNS, но необязательно отвечает на вызов из телефонной сети. LNS может решить не воспринять вызов если:

    • Нет ресурсов для поддержки новых сессий;
    • Поля вызывающего, вызываемого и субадреса не соответствуют авторизованному пользователю;
    • Сервис носителя не авторизован или не поддерживается.

    Если LNS решает принять вызов, он откликается посылкой Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается подключить вызов. Последнее сообщение о подключении от LAC к LNS указывает, что статус вызова для LAC и LNS должнен перейти в состояние "установлено". Если вызов завершается до того, как LNS успел принять его, LAC посылает Disconnect-Notify, чтобы индицировать эту ситуацию.

    Когда телефонный клиент вешает трубку, LAC посылает сообщение Call-Disconnect-Notify. Если LNS хочет аннулировать вызов, он посылает сообщение Call-Disconnect-Notify и ликвидирует свою сессию.

    7.4.1. Состояния LAC входящих вызовов

    Состояние

    Событие

    Действие

    Новое состояние

    Idle

    Bearer Ring или
    Готов индицировать
    входящее соединение

    Инициировать локальное открытие туннеля

    wait-tunnel

    Idle

    Получить ICCN, ICRP, CDN

    Clean up

    idle

    wait-tunnel

    Разрыв канала или локальный запрос закрытия

    Clean up

    idle

    wait-tunnel

    tunnel-open

    Послать ICRQ

    wait-reply

    wait-reply

    Получить ICRP, приемлемо

    Послать ICCN

    established

    wait-reply

    Получить ICRP,
    Не приемлемо

    Послать CDN,
    Clean up

    idle

    wait-reply

    Получить ICRQ

    Послать CDN
    Clean up

    idle

    wait-reply

    Получить CDN ICCN

    Clean up

    idle

    wait-reply

    Локальный запрос закрытия или потеря несущей

    Послать CDN,

    Clean up

    idle

    Established

    Получить CDN

    Clean up

    idle

    Established

    Получить ICRQ,
    ICRP, ICCN

    Послать CDN,
    Clean up

    idle

    Established

    Потеря несущей или локальный запрос закрытия

    Послать CDN,
    Clean up

    idle

    Состояниями, ассоциированными с LAC, для входящих вызовов являются:

    idle

    LAC детектирует входящий вызов на одном из своих интерфейсов. Обычно это означает, что по аналоговой линии получены звонки или ISDN TE зарегистрировало входное сообщение Q.931 SETUP. LAC инициализирует свою машину состояния, формирующую туннель, и переходит в состояние ожидания подтверждения существования туннеля.

    wait-tunnel

    В этом состоянии сессия ожидает открытия соединения или верификации того, что туннель уже открыт. Как только получено уведомление о том, что туннель открыт, может быть начат обмен управляющими сообщениями сессии. Первым таким сообщением будет Incoming-Call-Request.

    wait-reply

    LAC получает CDN-сообщение, указывающее, что LNS не хочет воспринимать вызов и переходит назад в состояние idle (пассивен), или получает сообщение Incoming-Call-Reply, означающее, что вызов принят, LAC посылает сообщение Incoming-Call-Connected и переходит в состояние "установлен".

    established

    Через туннель передаются данные. Вызов может быть аннулирован после:

    • Событие на подключенном интерфейсе: LAC посылает сообщение Call-Disconnect-Notify
    • Получение сообщения Call-Disconnect-Notify: LAC переходит в исходное состояние, аннулируя вызов.
    • Локальная причина: LAC посылает сообщение Call-Disconnect-Notify.

    7.4.2. Состояния LNS входящих вызовов

    Состояние

    Событие

    Действие

    Новое состояние

    Idle

    Получение ICRQ,
    Приемлемо

    Послать ICRP

    wait-connect

    idle

    Получение ICRQ,
    Не приемлемо

    Послать CDN,
    Clean up

    idle

    idle

    Получение ICRP

    Послать CDN
    Clean up

    idle

    Idle

    Получение ICCN

    Clean up

    idle

    wait-connect

    Получение ICCN
    Приемлемо

    Подготовиться для приема данных

    established

    wait-connect

    Получение ICCN
    Не приемлемо

    Послать CDN,
    Clean up

    idle

    wait-connect

    Получение ICRQ, ICRP

    Послать CDN
    Clean up

    idle

    idle,
    wait-connect,
    established

    Получение CDN

    Clean up

    idle

    wait-connect
    established

    Локальный запрос закрытия

    Послать CDN,
    Clean up

    idle

    established

    Получение ICRQ, ICRP, ICCN

    Послать CDN
    Clean up

    idle

    Состояниями, ассоциированными с LNS для входящих вызовов являются:

    idle

    Получено сообщение Incoming-Call-Request. Если запрос неприемлем, посылается Call-Disconnect-Notify LAC и LNS остается в состоянии idle. Если сообщение Incoming-Call-Request приемлемо, посылается Incoming-Call-Reply. Сессия переходит в состояние wait-connect.

    wait-connect

    Если сессия все еще подключена к LAC, он посылает сообщение Incoming-Call-Connected LNS, который затем переходит в состояние "установлено". LAC может послать Call-Disconnect-Notify для индикации того, что источник входящего запроса не может быть подключен. Это может произойти, например, если пользователь телефона случайно устанавливает в LAC стандартный голосовой режим, что приводит прерыванию диалога с модемом.

    established

    Сессия завершается при получении сообщения Call-Disconnect-Notify от LAC или путем посылки Call-Disconnect-Notify. Сброс системы в базовое состояние происходит на обеих сторонах вне зависимости от действий инициатора операции.

    7.5. Исходящие вызовы

    Исходящие вызовы инициируются LNS и заставляют LAC реализовать вызов. Для исходящих вызовов используется три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply, и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, специфицирующий телефонный номер партнера, субадрес и другие параметры. LAC должен реагировать на сообщение Outgoing-Call-Request откликом Outgoing-Call-Reply, так как LAC определяет, что имеется возможность реализовать вызов, который должен быть административно авторизован. Например, разрешено ли LNS осуществлять международные телефонные вызовы? Если для исходящего вызова осуществлено соединение, LAC посылает LNS сообщение Outgoing-Call-Connected, характеризующее окончательный результат попытки вызова.

    7.5.1. Состояния LAC исходящих вызовов

    Состояние

    Событие

    Действие

    Новое состояние

    Idle

    Получение OCRQ,
    Приемлемо

    Послать OCRP,
    Open bearer

    wait-cs-answer

    idle

    Получение OCRQ,
    Не приемлемо

    Послать CDN,
    Clean up

    idle

    idle

    Получение OCRP

    Послать CDN
    Clean up

    idle

    Idle

    Получение OCCN, CDN

    Clean up

    idle

    wait-cs-answer

    Bearer answer,
    framing detected

    Послать OCCN

    established

    wait-cs-answer

    Bearer failure

    Послать CDN,
    Clean up

    idle

    wait-cs-answer

    Получение OCRQ,

    OCRP, OCCN

    Послать CDN
    Clean up

    idle

    Established

    Получение OCRQ,
    OCRP, OCCN

    Послать CDN
    Clean up

    idle

    wait-cs-answer, established

    Получение CDN

    Clean up

    idle

    established

    Потеря несущей,
    локальный запрос закрытия

    Послать CDN,
    Clean up

    idle

    Состояниями, ассоциированными с LAC, для исходящих вызовов являются:

    idle

    Если Outgoing-Call-Request получен с ошибкой, посылается отклик Call-Disconnect-Notify. В противном случае, выделяется физический канал и посылается Outgoing-Call-Reply. Производится исходящий вызов и LAC переходит в состояние wait-cs-answer.

    wait-cs-answer

    Если вызов не завершен или произошел таймаут ожидания завершения вызова, посылается Call-Disconnect-Notify с соответствующими кодами ошибки и происходит переход в состояние idle. Если устанавливается соединение с коммутацией каналов и зафиксирован обмен кадрами, посылается Outgoing-Call-Connected, отмечающий успешную реализацию вызова и LAC переходит в состояние "установлено".

    established

    Если LAC получил Call-Disconnect-Notify, вызов должен быть аннулирован через соответствующий механизм и сессия закрыта. Если вызов аннулирован клиентом или интерфейсом, через который был осуществлен вызов, должно быть послано LNS сообщение Call-Disconnect-Notify. Отправитель сообщения Call-Disconnect-Notify переходит в состояние idle.

    7.5.2. Состояние исходящего вызова LNS

    Состояние

    Событие

    Действие

    Новое состояние

    Idle

    Локальный запрос открытия

    Инициировать локально
    tunnel-open

    wait-tunnel

    idle

    Получение OCCN,
    OCRP, CDN

    Clean up

    idle

    wait-tunnel

    tunnel-open

    Послать OCRQ

    wait-reply

    wait-reply

    Получение OCRP,
    Приемлемо

    никакого

    wait-connect

    wait-reply

    Получение OCRP,
    Не приемлемо

    Послать CDN
    Clean up

    idle

    wait-reply

    Получение OCCN, OCRQ

    Послать CDN
    Clean up

    idle

    wait-connect

    Получение OCCN

    none

    established

    wait-connect

    Получение OCRQ, OCRP

    Послать CDN
    Clean up

    idle

    Idle,
    wait-reply,
    wait-connect,
    established

    Получение CDN,

    Clean up

    idle

    established

    Получение OCRQ,
    OCRP, OCCN

    Послать CDN
    Clean up

    idle

    wait-reply,
    wait-connect,
    established

    Локальный запрос закрытия

    Послать CDN
    Clean up

    idle

    wait-tunnel

    Локальный запрос закрытия

    Clean up

    idle

    Состояниями, ассоциированными с LNS, для исходящих вызовов являются:

    idle, wait-tunnel

    Когда инициирован исходящий вызов, сначала создается туннель. Когда туннель создан, посылается сообщение Outgoing-Call-Request LAC и сессия переходит в состояние wait-reply.

    wait-reply

    Если получено Call-Disconnect-Notify, произошла ошибка, и сессия переводится в исходное состояние idle. Если получено сообщение Outgoing-Call-Reply, вызов находится в развитии и сессия переходит в состояние wait-connect.

    wait-connect

    Если получено Call-Disconnect-Notify, вызов не состоялся; сессия возвращается в исходное состояние idle. Если получено Outgoing-Call-Connected, вызов прошел, и сессия может осуществлять обмен данными.

    established

    Если получено Call-Disconnect-Notify, вызов был аннулирован по причине, указанной в кодах результата и причины; сессия возвращается в состояние idle. Если LNS решает завершить сессию, он посылает LAC сообщение Call-Disconnect-Notify и затем переводит сессию в исходное состояние idle.

    7.6. Ликвидация туннеля

    Разрыв туннеля происходит в случае посылки партнером сообщения Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать определенное время отклика на это сообщение, прежде чем ликвидировать управляющую информацию, имеющую отношение к туннелю. Получатель этого уведомления должен послать подтверждение получения этого сообщения и затем ликвидировать управляющую информацию.

    Конкретная программная реализация может использовать определенный алгоритм принятия решения о разрыве управляющего соединения. Некоторые реализации могут оставить туннель открытым на некоторое время. Другие могут решить закрыть туннель немедленно после разрыва последнего соединения пользователей.

    8. Реализация L2TP через специфическую среду

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

    8.1. L2TP через UDP/IP

    L2TP использует зарегистрированный UDP-порт 1701 [RFC1700]. Весь L2TP-пакет, включая поле данных и L2TP-заголовок, пересылается внутри UDP-дейтограммы. Создатель L2TP-туннеля выбирает доступный UDP-порт (который может быть или не быть 1701), и посылает пакет по нужному адресу места назначения с номером порта 1701. Получатель выбирает свободный номер порта в своей системе (который может быть или не быть 1701), и посылает отклик инициатору по его номеру порта и адресу. Раз номера портов отправителя и получателя определены, они должны оставаться неизменными в течение всей жизни туннеля.

    Может происходить IP-фрагментация, так как L2TP-пакет путешествует через Интернет. Протокол L2TP не предпринимает каких-то специальных усилий, чтобы оптимизировать этот процесс.

    По умолчанию для любых реализаций L2TP должно быть активизировано контрольное суммирование UDP как для управляющих, так и информационных сообщений. Реализация L2TP может предоставить опцию, способную блокировать контрольное суммирование UDP-дейтограмм для информационных сообщений. Рекомендуется, чтобы контрольные суммы UDP были всегда активированы для управляющих сообщений.

    Порт 1701 используется как пакетами L2F [RFC2341], так и L2TP. Поле версия в каждом из заголовков может использоваться, чтобы отличить пакеты этих двух типов (L2F использует значение 1, а версия L2TP, описанная в этом документе, использует 2). Реализация L2TP, работающая в системе, которая не поддерживает L2F, должна отбрасывать все L2F-пакеты.

    Для PPP-клиентов, использующих туннель L2TP-поверх-UDP/IP, PPP-связь имеет возможность менять порядок или отбрасывать пакеты. В первом случае могут нарушаться протоколы, отличные от IP и использующие для транспортировки PPP. Во втором - могут нарушаться протоколы, в которых предполагается по пакетный контроль ошибок, такой как TCP со сжатием заголовков. Контроль порядка можно осуществить, используя номера информационных L2TP-сообщений, если какой-то протокол, транспортируемый через PPP-туннель, не способен справиться с изменением порядка пакетов.

    Молчаливое отбрасывание пакетов может оказаться проблематичным для некоторых протоколов. Если в PPP разрешена надежная доставка [RFC1663], никакой выше расположенный протокол не может столкнуться с потерей пакетов. Если в L2TP разрешена нумерация пакетов, L2TP может контролировать потерю пакетов. В случае LNS, PPP и L2TP стеки присутствуют в LNS, и потеря пакета может регистрироваться, как если бы пакет получен с неверной CRC. Когда клиенты LAC и PPP физически различны, возможна аналоговая сигнализация, реализуемая путем посылки PPP-клиенту пакета с неверной контрольной суммой. Заметим, что это сильно усложнит отладку канальных программ клиента, так как статистика клиента не сможет отличить истинные ошибки транспортной среды от ошибок, инициированных LAC. Эта техника нереализуема на аппаратном уровне.

    Если используется VJ-сжатие, и не разрешена ни надежная доставка в PPP, ни нумерация пакетов, каждый потерянный пакет будет приводить к вероятности 2-16 того, что сегмент TCP будет переадресован с неверным содержимым [RFC1144]. Там где вероятность потери велика, не следует использовать сжатие заголовков TCP-сегментов.

    8.2. IP

    При работе в IP-среде протокол L2TP должен обеспечить UDP-инкапсуляцию, описанную в 8.1. Другие конфигурации (возможно соответствующие формату со сжатием заголовков) могут быть определены и доступны в качестве конфигурируемой опции.

    9. Соображения безопасности

    Протокол L2TP сталкивается при своей работе с несколькими проблемами безопасности. Ниже рассмотрены некоторые подходы для решения этих проблем.

    9.1. Безопасность на конце туннеля

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

    Для реализации аутентификации LAC и LNS должны использовать общий секретный ключ. Каждая из сторон использует один и тот же ключ, когда выполняет роль аутентификатора и аутентифицируемого. Так как используется только один ключ, AVP аутентификации туннеля несут в себе разные значения полей в CHAP ID для вычисления дайджеста каждого сообщения, чтобы противостоять атакам воспроизведения.

    Assigned Tunnel ID и Assigned Session ID (смотри раздел 4.4.3) должны быть выбраны непредсказуемым образом. Такая методика препятствует деятельности хакеров, которые не имеют доступа к пакетам, которыми обмениваются LAC и LNS.

    9.2. Безопасность пакетного уровня

    Обеспечение безопасности L2TP требует, чтобы транспортная среда могла обеспечить шифрование передаваемых данных, целостность сообщений и аутентификацию услуг для всего L2TP-трафика. Этот безопасный транспорт работает с пакетом L2TP в целом и функционально независим от PPP и протокола, вложенного в PPP. Как таковой, L2TP ответственен за конфиденциальность, целостность и аутентифицированность L2TP-пакетов внутри туннеля (LAC и LNS).

    9.3. Безопасность от начала до конца

    Защищая поток L2TP-пакетов, так как это делает безопасный транспорт, мы защищаем данные, передаваемые по PPP-туннелю от LAC к LNS. Такая защита не должна рассматриваться как замена для безопасности точка-точка при передаче данных между ЭВМ или приложениями.

    9.4. L2TP и IPsec

    При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне за счет ESP и/или AH. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы Ipsec, как обычные информационные UDP/IP-пакеты.

    Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на пакетном уровне, выполняемые режимом туннеля IPsec и средства L2TP, поддержанные IPsec предоставляют эквивалентные уровни безопасности.

    IPsec определяет также средства контроля доступа, которые необходимы для приложений, поддерживающих IPsec. Эти средства позволяют фильтровать пакеты, на основе характеристик сетевого и транспортного уровней, таких как IP-адрес, порт, и т.д.. В модели L2TP-туннеля, аналогичная фильтрация выполняется на PPP-уровне или сетевом уровне поверх L2TP. Эти средства управления доступом на сетевом уровне могут быть реализованы в LNS за счет механизма авторизации, специфицированного производителем, или на сетевом уровне, используя транспортный режим IPsec точка-точка между взаимодействующими ЭВМ.

    9.5. Аутентификация прокси PPP

    L2TP определяет AVP, которые могут пересылаться в процессе установления сессии с целью передачи PPP аутентификационной информации, полученной в LAC, для перепроверки в LNS (смотри раздел 4.4.5). Это предполагает полное доверие между LAC и LNS. Если LNS решит использовать прокси аутентификацию, она должна быть конфигурируема, требуя нового цикла PPP-аутентификации по инициативе LNS (который может включать или нет новый раунд согласования параметров с LCP).

    10. Соображения IANA

    Этот документ определяет ряд "магических" числе, которые определяются IANA. Эта секция объясняет критерии, которые должна использовать IANA при присвоении дополнительных чисел в каждый из этих списков. Следующие субсекции описывают политику присвоения для пространства имен, определенных в данном документе.

    10.1. Атрибуты AVP

    Как это определено в разделе 4.1, AVP содержат поля ID производителя, атрибута и значения. Для ID производителя значение 0 IANA поддерживает регистр присвоенных атрибутов, а в некоторых случаях и значений. Атрибуты 0-39 присвоены согласно тому, как это описано в разделе 4.4. Остальные значения доступны для присвоения при согласовании с IETF [RFC 2434].

    10.2. Значения типа сообщения AVP

    Как определено в разделе 4.4.1, AVP типа сообщения (тип атрибута 0) имеет значение поддерживаемое IANA. Значения 0-16 определены в разделе 3.2, остальные - могут присваиваться по согласованию с IETF [RFC 2434]

    10.3. Значения результирующих кодов AVP

    Как это определено в разделе 4.4.2, результирующий код AVP (тип атрибута 1) содержит три поля. Два из них (поля кодов результата и ошибки) имеют значения, обслуживаемые IANA.

    10.3.1. Значения поля кода результата

    AVP кода результата может быть включено в сообщения CDN и StopCCN. Допустимые значения поля кода результата AVP зависят от значения типа сообщения AVP. Для сообщения StopCCN, значения 0-7 определены в разделе 4.4.2; для сообщения StopCCN, значения 0-11 определены в том же разделе. Оставшиеся значения поля кода результата для обоих сообщений доступны для присвоения через согласование с IETF [RFC 2434].

    10.3.2. Значения поля кода ошибки

    Значения 0-7 определены в разделе 4.4.2. Значения 8-32767 доступны для присвоения через согласование с IETF [RFC 2434]. Оставшиеся значения поля кода ошибки доступны для присвоения в соответствии с алгоритмом "первый пришел - первым обслужен" [RFC 2434].

    10.4. Framing Capabilities & Bearer Capabilities

    AVP Framing Capabilities и Bearer Capabilities (определенные в разделе 4.4.3) содержат 32-битовые маски. Дополнительные биты могут быть определены через стандартную процедуру [RFC 2434].

    10.5. Значения типов прокси аутентификации AVP

    AVP типа прокси Authen (тип атрибута 29) имеет ассоциированное значение, поддерживаемое IANA. Значения 0-5 определены в разделе 4.4.5, оставшиеся значения доступны для присвоения по схеме "первым пришел - первым обслужен" [RFC 2434].

    10.6. Биты заголовка AVP

    Имеется 4 резервных бита в заголовке AVP. Дополнительные биты должны присваиваться через стандартную процедуру [RFC 2434].

    11. Ссылки

    [DSS1]

    ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998

    [KPS]

    Kaufman, C., Perlman, R., и Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1

    [RFC791]

    Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

    [RFC1034]

    Mockapetris, P., "Domain Names - Concepts и Facilities", STD 13, RFC 1034, November 1987.

    [RFC1144]

    Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.

    [RFC1661]

    Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

    [RFC1662]

    Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

    [RFC1663]

    Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.

    [RFC1700]

    Reynolds, J. и J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Смотри также: http://www.iana.org/numbers.html

    [RFC1990]

    Sklower, K., Lloyd, B., McGregor, G., Carr, D. и T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

    [RFC1994]

    Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

    [RFC1918]

    Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. и E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

    [RFC2119]

    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2138]

    Rigney, C., Rubens, A., Simpson, W. и S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

    [RFC2277]

    Alvestrand, H., "IETF Policy on Character Sets и Languages", BCP 18, RFC 2277, January 1998.

    [RFC2341]

    Valencia, A., Littlewood, M. и T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.

    [RFC2401]

    Kent, S. и R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

    [RFC2434]

    Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

    [RFC2637]

    Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. и G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.

    [STEVENS]

    Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9

    Приложение A:

    Медленный старт в управляющем канале и подавление перегрузки

    Хотя каждая из сторон указала максимальный размер окна приема, рекомендуется, чтобы при передаче управляющих пакетов использовался медленный старт и метод подавления перегрузки. Методы, описанные здесь, базируются на TCP-алгоритме подавления перегрузки, как это описано в разделе 21.6 книги "TCP/IP Illustrated", том I, написанной W. Richard Stevens [STEVENS].

    Медленный старт и подавление перегрузки используют несколько переменных. Окно перегрузки (CWND) определяет число пакетов, которые отправитель может послать, не дожидаясь подтверждения. Размер CWND расширяется и сокращается так, как это описано ниже. Заметим, однако, что CWND никогда не должно превышать размера окна, полученного из AVP приемного окна (далее предполагается, что любое увеличение ограничивается размером приемного окна). Переменная SSTHRESH определяет, когда отправитель переходит от медленного старта к подавлению перегрузки. Медленный старт используется, когда CWND меньше SSHTRESH.

    Отправитель начинает работу с фазы медленного старта. Начальный размер CWND равен одному пакету, а уровень SSHTRESH в начальный момент определяется размером окна (полученным из AVP приемного окна). Отправитель передает один пакет и ждет подтверждения получения. Когда подтверждение получено, окно перегрузки увеличивается на единицу и становится равным двум. Во время медленного старта, размер CWND увеличивается на единицу при получении каждого ACK. Увеличение CWND на 1 при получении ACK приводит к удвоению CWND за время RTT, что эквивалентно экспоненциальному росту. Когда значение CWND достигает SSHTRESH, фаза медленного старта завершается и начинается подавление перегрузки.

    При подавлении перегрузки, CWND расширяется более медленно. В частности, оно увеличивается на 1/CWND для каждого полученного подтверждения ACK. Расширение окна на фазе подавления перегрузки является линейным, с увеличением CWND на 1 за время RTT.

    Когда происходит перегрузка (индицируемая повторной передачей пакета) половина CWND записывается в SSTHRESH, а CWND делается равным 1. Отправитель после этого возвращается в режим медленного старта.

    Приложение B: Примеры управляющих сообщений

    B.1: Установление туннеля Lock-step

    В этом примере, LAC формирует туннель, при этом реализуется обмен сообщениями в обоих направлениях. В этом примере показано, что окончательное подтверждение посылается в сообщении ZLB ACK. Альтернативой может быть подтверждение, пришедшее в сообщении, посланном в ответ на ICRQ или OCRQ, которые направляются стороной, инициировавшей формирование туннеля.

    LAC или LNSLNS или LAC
    SCCRQ ->
    Nr: 0, Ns: 0
    <- SCCRP
    Nr: 1, Ns: 0
    SCCCN ->
    Nr: 1, Ns: 1
    <- ZLB

    Nr: 2, Ns: 1

    B.2: Потеря пакета и повторная передача

    Существующий туннель имеет новую сессию, запрошенную LAC. Пакет ICRP потерян и должен быть послан LNS повторно. Заметим, что потеря ICRP несет в себе две проблемы: это не только блокирует машину состояний высокого уровня, но и лишает LAC своевременного прихода подтверждения его ICRQ на нижнем уровне.

    LAC LNS
    ICRQ ->
    Nr: 1, Ns: 2
    (пакет потерян) <- ICRP
    Nr: 3, Ns: 1
    (пауза; таймер LAC запускается первым, поэтому первым и срабатывает)
    ICRQ ->
    Nr: 1, Ns: 2

    (Понимая, что он уже видел этот пакет, LNS отбрасывает его и посылает ZLB)
    <- ZLB
    Nr: 3, Ns: 2
    (срабатывает таймер повторной передачи LNS)
    <- ICRP
    Nr: 3, Ns: 1
    ICCN ->
    Nr: 2, Ns: 3
    <- ZLB
    Nr: 4, Ns: 2

    Previous: 4.4.1.2 IP-туннели    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.2 Протокол UDP


    previous up down next index index
    Previous: 4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.3 Протокол TCP

    4.4.2 Протокол UDP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол UDP (user datagram protocol, RFC-768) является одним из основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтограмм, но не требует подтверждения их получения. Протокол UDP не требует соединения с удаленным модулем UDP ("бессвязный" протокол). К заголовку IP-пакета udp добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина udp-дейтограммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне ip для определения места доставки пакета используется адрес, на уровне UDP - номер порта.

    Примерами сетевых приложений, использующих UDP, являются NFS(network file system), TFTP(trivial file transfer protocol, RFC-1350), RPC (remote procedure call, RFC-1057) и SNMP (simple network management protocol, RFC-1157). Малые накладные расходы, связанные с форматом UDP, а также отсутствие необходимости подтверждения получения пакета, делают этот протокол наиболее популярным при реализации приложений мультимедиа, но главное его место работы - локальные сети и мультимедиа.

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

    Например, сервер snmp всегда ожидает сообщения, адресованного в порт 161. Если клиент snmp желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP. Общеизвестные номера портов определяются стандартами Internet (см. табл. 4.4.2.1).

    Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 5 записей в порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. Формат UDP-сообщений представлен ниже на рис. 4.4.2.1:

    Рис. 4.4.2.1 Формат UDP-дейтограмм

    Длина сообщения равна числу байт в UDP-дейтограмме, включая заголовок. Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля данные. Не трудно видеть, что этот протокол использует заголовок минимального размера (8 байт). Таблица номеров UDP-портов приведена ниже (4.4.2.1). Номера портов от 0 до 255 стандартизованы и использовать их в прикладных задачах не рекомендуется. Но и в интервале 255-1023 многие номера портов заняты, поэтому прежде чем использовать какой-то порт в своей программе, следует заглянуть в RFC-1700. Во второй колонке содержится стандартное имя, принятое в Internet, а в третей - записаны имена, принятые в unix.

    Таблица 4.4.2.1 Номера UDP-портов (более полный перечень в RFC-1700; Если какой-то номер порта в перечне отсутствует, это не означает, что он не зарезервирован и его можно использовать, просто я сэкономил место)

    Десятич. номер порта Обозначение порта Описание
    в Интернет

    в Unix

    0
    -
    -
    Зарезервировано
    1
    TCPmux
    -
    tcp Мультиплексор
    2
    Compressnet
    -
    Программа управления
    3
    Compressnet
    -
    Процесс сжатия
    5
    RJE
    -
    Вход в удаленную задачу
    7
    Echo
    echo
    Эхо
    9
    Discard
    discard
    Сброс
    11
    Users
    systat
    Активные пользователи
    13
    Daytime
    daytime
    Время дня
    15
    -
    Netstat
    Кто работает или netstat
    19
    Chargen
    chargen
    Генератор символов
    20
    FTP-data
    ftp-data
    FTP (данные)
    21
    FTP
    ftp
    Протокол пересылки файлов (управление)
    23
    telnet
    telnet
    Подключение терминала
    24
    -
    -
    Любая частная почтовая система
    25
    SMTP
    smtp
    Протокол передачи почтовых сообщений
    31
    MSG-auth Распознавание сообщения (аутентификация)
    35
    -
    -
    Любой частный принт-сервер
    37
    Time
    time
    Время
    39
    RLP
    -
    Протокол поиска ресурсов
    41
    Graphics Графика
    42
    nameserver
    name
    Сервер имен
    43
    Nicname
    whois
    Кто это? (whois-сервис)
    45
    MPM
    -
    Блок обработки входных сообщений
    46
    MPM-snd
    -
    Блок обработки выходных сообщений
    48
    Auditd
    -
    Демон цифрового аудита
    49
    login
    -
    Протокол входа в ЭВМ
    50
    RE-mail-ck
    -
    Протокол удаленного контроля почтовым обменом
    53
    Domain
    nameserver
    Сервер имен доменов (dns)
    57
    -
    -
    Любой частный терминальный доступ
    59
    -
    -
    Любой частный файл-сервер
    64
    covia
    -
    Коммуникационный интегратор (ci)
    66
    SQL*net
    -
    Oracle SQL*net
    67
    Bootps
    Bootps
    Протокол загрузки сервера
    68
    Bootpc
    bootpc
    Протокол загрузки клиента
    69
    TFTP
    tftp
    Упрощенная пересылка файлов
    70
    Gopher
    -
    Gopher (поисковая система)
    71
    -
    Netrjs-1
    Сервис удаленных услуг
    77
    -
    rje
    Любой частный RJE-сервис
    79
    Finger
    finger
    finger
    80
    WWW-HTTP World Wide Web HTTP
    81
    Hosts2-NS
    -
    Сервер имен 2
    87
    -
    -
    Любая частная терминальная связь
    88
    Kerberos Kerberos
    92
    NPP
    -
    Протокол сетевой печати
    93
    DCP
    -
    Протокол управления приборами
    95
    Supdup
    supdup
    Supdup протокол
    97
    Swift-rvf
    -
    swift-протокол удаленных виртуальных файлов
    101
    Hostname
    hostnames
    Сервер имен ЭВМ для сетевого информационного центра
    102
    ISO-Tsap
    iso-tsap
    ISO-Tsap
    103
    GPPitnp Сети точка-точка
    104
    ACR-nema ACR-nema digital IMAG. & comm. 300
    108
    Snagas sna-сервер доступа
    109
    POP2
    -
    Почтовый протокол pop2
    110
    POP3
    -
    Почтовый протокол POP3
    111
    SUNRPC
    sunrpc
    SUN microsystem RPC
    113
    Auth
    auth
    Служба распознавания
    114
    Audionews Аудио-новости
    115
    SFTP Простой протокол передачи файлов
    117
    UUCP-path
    uucp-path
    Служба паролей uucp
    118
    SQLserv SQL-сервер
    119
    NNTP
    NNTP
    Протокол передачи новостей
    123
    NTP
    NTP
    Сетевой протокол синхронизации
    129
    PWDgen Протокол генерации паролей
    130-132
    Cisco
    133
    Statsrv Сервер статистики
    134
    Ingres-net Ingres-net-сервис
    135
    LOC-srv Поисковый сервис
    137
    Netbios-SSN
    -
    Служба имен Netbios
    138
    Netbios-DGM Служба дейтограмм netbios
    139
    Netbios-SSN Служба сессий Netbios
    147
    ISO-IP ISO-IP
    150
    SQL-net SQL net
    152
    BFTP Протокол фоновой пересылки файлов
    156
    SQLsrv SQL-сервер
    158
    PCmail-srv PC почтовый сервер
    161
    -
    SNMP
    Сетевой монитор SNMP
    162
    -
    SNMP-trap
    SNMP-ловушки
    170
    Print-srv postscript сетевой сервер печати
    179
    BGP Динамический протокол внешней маршрутизации
    191
    Prospero Служба каталогов Prospero
    194
    IRC Протокол Интернет для удаленных переговоров
    201-206
    Протоколы сетей Apple talk
    213
    IPX ipx
    348
    CSI-SGWP Протокол управления cabletron
    396
    Netware-IP Novell-Netware через IP
    398
    Kryptolan Kryptolan
    414
    Infoseek Infoseek (информационный поиск)
    418
    Hyper-g Hyper-g
    444
    SNPP Простой протокол работы со страницами
    512
    -
    biff (exec)
    Unix Comsat (удаленное исполнение)
    513
    -
    Who
    Unix Rwho daemon
    514
    -
    syslog
    Дневник системы
    515
    Printer Работа с буфером печати (spooler)
    525
    -
    Timed
    Драйвер времени

    Зарегистрировано ряд портов для стандартного применения и в диапазоне 1024-65535. Например:

    Номер порта Обозначение Назначение
    1397 Аudio-activmail Активная звуковая почта
    1398 Video-activmail Активная видео-почта
    5002 RFE Радио-Ethernet
    6000-6063 X11 Система X Windows
    7008 AFS3-update Сервер-сервер актуализация

    Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтограмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдо-заголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае IP-дейтограммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.

    Рис. 4.4.2.2. Псевдозаголовок, используемый при расчете контрольной суммы

    Если контрольная сумма правильная (или равна 0), то проверяется порт назначения, указанный в заголовке дейтограммы. Если прикладной процесс подключен к этому порту, то прикладное сообщение, содержащиеся в дейтограмме, становится в очередь к прикладному процессу для прочтения. В остальных случаях дейтограмма отбрасывается. Если дейтограммы поступают быстрее, чем их успевает обрабатывать прикладной процесс, то при переполнении очереди сообщений поступающие дейтограммы отбрасываются модулем UDP. Следует учитывать, что во многих посылках контрольное суммирование не охватывает адреса отправителя и места назначения. При некоторых схемах маршрутизации это приводит к зацикливанию пакетов в случае повреждения его адресной части (адресат не признает его "своим").

    Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее. Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768.

    Previous: 4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.3 Протокол TCP


    previous up down next index index
    Previous: 4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.6 Протокол преобразования адресов ARP

    4.4.5 Протокол XTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Транспортный протокол XTP (xpress transport protocol; http://www.ca.sandia.gov/xtp/) разработан в 1992 году, является протоколом нового поколения и имеет целью преодолеть недостатки такого популярного протокола как TCP (медленный старт, неэффективная работа при возникновении потерь пакетов). В XTP функции обеспечения надежной передачи данных и управления разделены, протокол допускает управление пропускной способностью канала и успешно справляется с перегрузкой канала. Принципиальной особенностью XTP является независимость от числа участников информационного обмена (обычный режим эквивалентен мультикастингу, по этой причине XTP может использоваться и как мультикастинг-протокол) и возможность работы с MAC, IP или AAL5. Протокол призван в перспективе заменить TCP, UDP, Appletalk и IPX. Мультикастинг в XTP в отличии от других протоколов может гарантировать доставку информации, что может оказаться важным при многоточечном управлении или в некоторых распределенных базах данных.

    При передаче больших массивов информации последовательные пакеты нумеруются. В случае потери принимающая сторона посылает отправителю список не доставленных пакетов (TCP повторяет пересылку всех пакетов, начиная с потерянного). Именно алгоритм селективной ретрансмиссии и позволяет повысить эффективность использования канала. Длина пакетов XTP кратна 64 бит. Совокупность информации, описывающей состояние XTP, называется контекстом. Каждый контекст управляет как входящим, так и исходящим потоками данных. Два активных контекста и поток данных образуют ассоциацию. В исходном состоянии контекст оконечной системы пассивен и находится в состоянии ожидания. Первый передаваемый пакет содержит полную адресную информацию. После получения первого пакета контекст становится активным. С этого момента ассоциация сформирована и обмен может происходить в обоих направлениях. Каждый последующий пакет несет в себе ключевой код, определяющий его принадлежность к данному контексту. При завершении передачи устанавливаются соответствующие биты опций, связь разрывается, а контексты возвращаются в пассивное состояние. Все виды XTP-пакетов имеют один и тот же формат заголовков. Управление контекстом осуществляется с помощью флагов, содержащихся в заголовке. Всего предусмотрено 15 флагов.

    На рис. 4.4.5.1 показана зависимость пропускной способности канала для сети ATM при использовании транспортных протоколов TCP и XTP, в обоих случая использовался в качестве базового протокол IP. Измерения производились для приложений типа FTP. Из рисунка видно, что даже 1% потерянных или поврежденных пакетов понижает пропускную способность на 30% при работе с протоколом TCP. XTP требует только три пакета, чтобы сформировать виртуальный канал, в то время как XTP требует для тех же целей семь пакетов. Благодаря своей простоте XTP может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.

    Рис. 4.4.5.1. Зависимость пропускной способности канала при использовании протоколов TCP и XTP ( www.mentat.com/xtp.xtp.html и xtpdata.html XTP 95-20, Xpress Transport Protocol Specification (XTP revision 4.0), 1995, XTP Forum, Santa Barbara, CA 93108 USA )

    При 5% потерях пакетов XTP обеспечивает в 6 раз большую пропускную способность, чем TCP. В таблице 4.4.5.1 приведены сравнительные результаты измерения пропускной способности канала ATM (155 Мбит/с) при использовании протоколов TCP, UDP и XTP (использовались пакеты длиной 8190 байт).

    Таблица 4.4.5.1. Сравнительные характеристики протоколов TCP, UDPи XTP

    Название протокола

    Пропускная способность в Мбит/с

    TCP

    89-93

    UDP

    93-94

    XTP

    112-115

    Из таблицы видно, что в нормальных условиях протокол XTP гарантирует пропускную способность на 25% выше, чем TCP или UDP.

    Все поля в XTP-пакетах передаются так, что наиболее значимый байт передается первым (порядок байт - "big-endian"). Формат заголовка XTP-пакета показан на рис. 4.4.5.2. Поле ключ определяет принадлежность пакета к тому или иному контексту, поле команда (CMD) задает процедуру обработки пакета. Поле длина (DLEN) определяет объем данных в пакете, а поле номер по порядку (SEQ) представляет собой порядковый номер пакета в последовательности. Поля контрольная сумма и синхронизация используются для проверки корректности доставки. Старший бит поля ключ (RTN - возврат, рис. 4.4.5.3) зарезервирован в качестве флага, указывающего на контекст передающей (=0) или принимающей стороны (принимающая сторона, посылая пакеты, ставит RTN=1). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.

    Рис. 4.4.5.2 Формат кадра протокола XTP

    Рис. 4.4.5.3 Структура поля ключ

    32-разрядное поле команды содержит в себе субполе опции. Названия различных бит этого поля показаны на рис. 4.4.5.4.

    Рис. 4.4.5.4. Формат поля команда

    btag=1

    указывает на то, что первые восемь байт сегмента данных стали полем btag (beginning tag field - начальная метка). Служит для постановки меток для прикладных программ. BTAG имеет смысл только для информационных пакетов и должен быть обнулен для всех остальных.

    dreq=1

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

    edge

    при получении пакета значение этого бита сравнивается с со значение бита edge предыдущего пакета. Если их величины отличаются, посылается управляющий пакет. Отправитель может изменять значения этого бита, чтобы вызвать присылку управляющего пакета, не привлекая механизма SREQ или DREQ.

    end=1

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

    EOM

    служит для обозначения границ сообщения в потоке данных. Если EOM=1, то этот пакет завершает сообщение. Управляющие пакеты не должны иметь EOM=1. Этот бит устанавливается прикладной, а не протокольной программой.

    fastnak

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

    multi=1

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

    noerr=1

    информирует получателя о том, что отправитель не будет повторно присылать пакеты и рекомендует получателю отключить контроль ошибок.

    Nocheck=1

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

    Noflow=1

    указывает на то, что отправитель не следит за ограничениями потока данных (например, игнорирует значение alloc).

    RES=1

    позволяет режим резервирования. Устанавливая его, отправитель обращает внимание получателя на то, что значение alloc, присланные получателем в контрольных пакетах, должно соответствовать реальному объему свободного буферного пространства.

    Sort=1

    указывает, что значение кода в поле sort заголовка должно интерпретироваться и использоваться для приоритетного отбора пакетов.

    sreq=1

    указывает получателю, что он должен немедленно послать контрольный пакет. Бит SREQ устанавливается отправителем в соответствии со своей политикой подтверждений или в случае возникновения ошибок.

    Wclose и Rclose

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

    XTP-передатчик контролирует все биты поля опции для каждого пакета. Некоторые дополнительные данные о битах субполя опции можно найти в таблице 4.4.5.2.

    Таблица 4.4.5.2. Значения битов субполя опции

    Бит поля опции

    Маска

    Возможность изменения

    Использование

    Описание

     

    0x800000

        Не используется, должно обнуляться

    nocheck

    0x400000

    по-пакетно

    Раз на контекст Отключение контрольной суммы

    edge

    0x200000

    по-пакетно

     

    Пограничный запрос статуса

    noerr

    0x100000

    по-пакетно

    Раз на контекст

    Отключение контроля ошибок

    multi

    0x080000

    Раз на ассоциацию  

    Режим мультикастинга

    res

    0x040000

    по-пакетно

    Раз на контекст

    Режим резервирования

    Sort

    0x020000

    по-пакетно

    Раз на контекст

    Допускает сортировку

    Noflow

    0x010000

    по-пакетно

    Раз на контекст

    Отключает управление потоком данных

    Fastnack

    0x008000

    по-пакетно

    Раз на контекст

    Разрешает жесткий контроль ошибок

    SRREQ

    0x004000

    по-пакетно

     

    Запрос статуса

    DREQ

    0x002000

    по-пакетно

     

    Запрос доставки статуса

    Rclose

    0x001000

    по-пакетно

     

    Получатель отключен

    Wclose

    0x000800

    по-пакетно

     

    Отправитель отключен

    EOM

    0x000400

    по-пакетно

     

    Конец сообщения

    End

    0x000200

    один раз

     

    Конец контекста или ассоциации

    Btag

    0x000100

    по-пакетно

     

    Начало метки поля данных

    "По-пакетно" означает, что бит может изменяться от пакета к пакету. "Раз на ассоциацию" означает, что все контексты ассоциации должны иметь этот бит идентичным. "Один раз" означает, что бит может быть установлен один раз за время жизни контекста

    Таблица 4.4.5.3. Коды типов пакетов XTP (Pformat)

    Формат пакета

    Код типа

    Описание

    data

    0

    Информационный пакет пользователя

    cntl

    1

    Пакет управления состоянием

    first

    2

    Исходный пакет ассоциации (содержит адресный сегмент)

    ecntl

    3

    Пакет управления (ошибка)

    tcntl

    5

    Пакет управления трафиком

    join

    6

    Мультикастинг-пакет включения в группу

    diag

    8

    Диагностический пакет

    Младший байт поля команда содержит субполе типа пакета (ptype). Биты 0-4 этого субполя содержат код формата пакета (Pformat, см. таблицу 4.4.5.3). Биты 5-7 определяют версию протокола (ver). Для XTP 4.0 код версии равен 001.

    Поле DLEN содержит число байт в массиве данных пакета, следующем непосредственно за заголовком. Так как информационные пакеты с нулевым объемом данных запрещены, код dlen не может быть равен нулю.

    Поле Check содержит контрольную сумму. Если бит nochek=1, то в поле записана контрольная сумма только заголовка, в противном случае - всего пакета.

    Поле приоритет (sort) предназначено для задания приоритета пересылаемой информации. Это поле интерпретируется лишь в случае, если бит sort=1. При sort=0 поле приоритет должно быть обнулено. Контексты с приоритетным трафиком посылают пакеты с sort=1 и с определенным кодом в поле приоритет. Бесприоритетные контексты шлют пакеты с sort=0 и нулевым полем приоритета. На приемной стороне информация доставляется в соответствии с кодом приоритета. Поле приоритет характеризуется беззнаковым 16-разрядным числом. Код приоритет, равный нулю, указывает на самый низкий приоритет, чем больше этот код, тем выше приоритет. XTP обслуживает активные контексты в соответствии с присвоенными им приоритетами. Высокоприоритетная информация посылается раньше низкоприоритетной. Аналогичный порядок обслуживания работает и на принимающей стороне.

    32-битовое поле синхронизация (Sync) служит для синхронизации диалога. Каждый контекст хранит код последнего посланного значения Sync в переменной Saved_sync. Когда пакет послан с Sreq=1, значение переменной Saved_sync увеличивается на единицу и этот код заносится в поле Sync отправляемого пакета. Получатель запоминает последний полученный код Sync в контекстной переменной Rcvd_sync. Значение этой переменной записывается в поле эхо каждого посылаемого управляющего пакета. Когда управляющий пакет получен, код поля sync сравнивается со значением Rcvd_sync. Если sync Ё Rcvd_sync, то управляющий пакет обрабатывается нормально. В противном случае управляющий пакет содержит информацию, которая старее полученной с предыдущими пакетами, и обрабатываться не должен.

    Поле номер по прядку (SEQ) характеризуется 64-разрядным числом без знака и представляет собой порядковый номер байта в передаваемом потоке. Для первого пакета (first) поле SEQ характеризует объем буферов для потока откликов, а для пакетов Join это поле содержит дентификатор получателя (ключ контекста). Join-пакет отклик на запрос содержит в поле SEQ порядковый номер байта для текущей ассоциации. Диапазон значений поля номер по порядку для информационных пакетов начинается с SEQ и простирается вплоть до SEQ+ DLEN - 1. Для DIAG пакетов поле SEQ содержит код SEQ входного пакета, который вызвал ошибку. Если посылка пакета DIAG вызвана не входным пакетом, код SEQ должен быть равен нулю.

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

    Управляющие сегменты несут в себе информацию о состоянии контекста, его приславшего. XTP пакеты, содержащие управляющие сегменты называются контрольными пакетами. Управляющие сегменты содержат пакеты типа Cntl, Ecntl и Tcntl. Управляющий сегмент Cntl-пакета несет в себе информацию об управлении обменом. Ecntl-пакеты включают в себя сегменты управления ошибками, а Tcntl-пакеты - сегменты управления трафиком. Формат управляющего сегмента показан на рис. 4.4.5.5.

    Рис. 4.4.5.5 Формат общего управляющего сегмента пакета XTP

    Три поля общего управляющего сегмента представляют статусную информацию и содержатся во всех трех типах контрольных пакетов. Первые два поля RSEQ и alloc являются параметрами управления обменом. Поле Echo используется для идентификации контрольных пакетов, которые являются откликом на пакеты с битом SREQ=1. Поле RSEQ содержит в себе номер очередного байта, подлежащего пересылке, и определяет начало окна, управляющего обменом. Поле Alloc интерпретируется, когда разрешено управление обменом. Код поля Alloc определяет объем данных, который отправитель может послать (а получатель принять). Если бит RES=1, то поле Alloc задает размер буфера, зарезервированного для данной ассоциации. Поле Echo используется для установления соответствия между запросом статуса и контрольными пакетами. Код поля Echo равен наибольшему значению sync для полученных пакетов. Это значение хранится в контекстной переменной rcvd_sync. Когда формируется контрольный пакет, значение rcvd_sync заносится в поле Echo этого пакета.

    Формат сегмента управления ошибками показан на рис. 4.4.5.6. Этот сегмент включает в себя все поля общего управляющего сегмента, дополнительно использовано только два поля Nspan и Spans, которые сообщают о том, какие пакеты потеряны.

    Рис. 4.4.5.6 Формат сегмента управления ошибками

    Сегмент управления ошибками используется в пакетах Ecntl. Поле Nspan определяет число Spans в Ecntl-пакете. Так как пакет Ecntl посылается только в случае потери информации, поле Nspan несет в себе код не меньше 1. Поле Spans содержит в себе Nspan пар чисел, которые характеризуют интервалы номеров байт, переданных корректно. Речь здесь идет о данных, имеющих номера больше того, который указан в поле RSEQ. На основании этих данных можно вычислить, какая именно информация потеряна.

    Формат сегмента управления трафиком показан на рис. 4.4.5.7. Помимо полей общего управляющего сегмента здесь присутствуют поля RSVD и XKEY, а также спецификация трафика. Поле RSVD является резервным и должно содержать нуль. Поле XKEY является обязательной принадлежностью всех Tcntl-пакетов, величина этого поля должна равняться значению ключа для контекста, посылающего пакет (бит RTN=1). Спецификация трафика используется в пакетах типа first и Tcnnl. Пакет first предлагает параметры режима обмена, а Tcntl несет в себе отклик на это предложение.

    Рис. 4.4.5.7 Формат сегмента управления трафиком

    Поле tlen определяет длину спецификации трафика, включая 4-байтовый дескриптор (tlen Ё ). Поле service используется для задания типа транспортного сервиса на фазе установления режима обмена. Коды доступных видов сервиса представлены в таблице 4.4.5.4. Эта информация передается в пакете типа first.

    Таблица 4.4.5.4. Коды поля тип сервиса (service)

    Код типа сервиса

    Описание

    0x00

    Не специфицировано

    0x01

    Традиционная передача дейтограмм без подтверждения

    0x02

    Передача дейтограмм с подтверждением

    0x03

    Реализация транзакций

    0x04

    Традиционная передача потока данных с гарантированной доставкой

    0x05

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

    0x06

    Мультикастинг режим передачи потока данных с гарантированной доставкой

    Поле tformat определяет формат поля traffic. Код tformat=0 используется тогда, когда не нужно ни какой спецификации трафика, в 4-байтовое поле traffic в этом случае записываются нули. В противном случае используется код tformat=0x01. Формат поля traffic для этого арианта показан на рис. 4.4.5.8.

    Рис. 4.4.5.8 Формат поля traffic

    Поле maxdata несет в себе код максимального размера информационного сегмента, который отправитель может послать за время жизни ассоциации. Поля inrate и inburst представляют собой параметры, определяющие входной поток данных. Поля outrate и outburst являются параметрами, задающими выходной поток данных.

    Информационный сегмент включает в себя пользовательскую и другую протокольную и диагностическую информацию. XTP-пакеты, содержащие информационный сегмент, называются информационными пакетами. К их числу относятся пакеты типа data, first, join и diag. Информационные пакеты могут включать в себя сегмент данных, адресный сегмент, спецификатор трафика и диагностический сегмент. Формат полей адресного сегмента показан на рис. 4.4.5.9.

    Рис. 4.4.5.9 Формат полей адресного сегмента

    Адресный сегмент используется в пакетах типа first и join. Протокол XTP использует параметрическую схему адресации, возможны несколько форматов адресов отправителя и места назначения. Поле Alen определяет полную длину адресного сегмента. Поле Adomain представляет собой адресный демультиплексор, допуская работу с несколькими адресными доменами. Поле Adomain используется в частности для того, чтобы обеспечить совместимость с протоколами UDP и TCP (для TCP Adomain=6, для UDP 17, а для XTP 36). Поле Aformat идентифицирует адресный синтаксис в соответствии с таблицей 4.4.5.5.

    Таблица 4.4.5.5. Значения кодов поля Aformat

    Код поля aformat

    Синтаксис адреса

    0x00

    Нулевой адрес

    0x01

    ip-адрес

    0x02

    ISO адрес протокольного сетевого уровня для передачи без установления связи

    0x03

    Адрес сети Ксерокс

    0x04

    IPX-адрес

    0x05

    Локальный адрес

    0x06

    IP-адрес версии 6

    Поле адрес несет в себе адреса отправителя и получателя пакетов, форматы которых заданы полем Aformat.

    Формат полей сегмента данных показан на рис. 4.4.5.10. Эти сегменты предназначены для применения на прикладных пользовательских уровнях и программами поддержки протокола XTP не интерпретируются. Сегмент включается в пакеты типа first и data.

    Рис. 4.4.5.10 Формат полей сегмента данных

    Размер поля Data имеет произвольное значение, первые 8 байт (поле Btag) представляют собой специальную метку (если бит опций заголовка btag=1). При Btag=0 метка отсутствует. Интерпретация поля Btag осуществляется исключительно прикладной программой и для XTP его значение безразлично.

    Формат полей диагностического сегмента показан на рис. 4.4.5.11. Этот сегмент используется пакетами типа DIAG для информирования протокольной или прикладной программы о случаях ошибок. Поле Code определяет тип и категорию ошибки, вызвавшей отправку пакета типа DIAG. Поле val позволяет уточнить причину ошибки. Поле message является опционным и может иметь произвольную длину. Обычно это поле содержит текстовую интерпретацию полей Code и VAL.

    Рис. 4.4.5.11 Форматы полей диагностического сегмента

    Previous: 4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.6 Протокол преобразования адресов ARP


    previous up down next index index
    Previous: 4.4.6 Протокол преобразования адресов ARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.8 Протокол обратного адресного преобразования RARP

    4.4.7 Прокси-ARP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Еще одна разновидность протокола ARP служит для того, чтобы один и тот же сетевой префикс адреса можно было использовать для двух сетей. Этот протокол называется смешанным протоколом ARP (proxy). Предположим, мы имеем сеть из четырех ЭВМ (1-4; рис. 4.4.7.1), которую бы мы хотели соединить с другой сетью из четырех ЭВМ (5-8), причем так, чтобы машины взаимодействовали друг с другом так, будто они принадлежат одной сети. Решить эту проблему можно, соединив эти сети через маршрутизатор M, работающий в соответствии со смешанным протоколом ARP (функционально это IP-мост). Маршрутизатор знает, какая из машин принадлежит какой физической сети. Он перехватывает широковещательные ARP-запросы из сети 1, относящиеся к сети 2, и наоборот. Во всех случаях в качестве физического адреса маршрутизатор возвращает свой адрес. В дальнейшем, получая дейтограммы, он маршрутизирует их на физические адреса по их IP-адресам.

    Рис. 4.4.7.1. Использование протокола proxy ARP

    Не трудно видеть, что в смешанном протоколе ARP нескольким IP-адресам ставится в соответствие один и тот же физический адрес. Поэтому системы, где предусмотрен контроль за соответствием физических и IP-адресов, не могут работать со смешанным протоколом ARP. Главным преимуществом этого протокола является то, что он позволяет путем добавления одного маршрутизатора (Gateway) подключить к Интернет еще одну сеть, не изменяя таблиц маршрутизации в других узлах. Этот протокол удобен для сети, где есть ЭВМ, не способная работать с субсетями. Протокол используется при построении сетей Интранет.

    Previous: 4.4.6 Протокол преобразования адресов ARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.8 Протокол обратного адресного преобразования RARP


    previous up down next index index
    Previous: 4.4.7 Прокси-ARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9 Протокол IGMP

    4.4.8 Протокол обратного адресного преобразования RARP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Обычно IP-адреса хранятся на диске, откуда они считываются при загрузке системы. Проблема возникает тогда, когда необходимо инициализировать рабочую станцию, не имеющую диска. Бездисковые системы часто используют операции типа TFTP для переноса из сервера в память образа операционной системы, а это нельзя сделать, не зная IP-адресов сервера и ЭВМ-клиента. Записывать эти адреса в ПЗУ не представляется целесообразным, так как их значения зависят от точки подключения ЭВМ и могут меняться. Для решения данной проблемы был разработан протокол обратной трансляции адресов (RARP - Reverse Address Resolution Protocol, RFC-0903, смотри также ниже описание протокола BOOTP). Форматы сообщений RARP сходны с ARP (см. рис. 4.4.8.1), хотя сами протоколы принципиально различны. Протокол RARP предполагает наличие специального сервера, обслуживающего RARP-запросы и хранящего базу данных о соответствии аппаратных адресов протокольным. Этот протокол работает с любой транспортной средой, в случае же кадра Ethernet в поле тип будет записан код 803516 (смотри таблицу 4.4.6.2).

    Рис. 4.4.8.1. Формат RARP-сообщения

    Здесь обозначения те же, что и в описании ARP-формата. Значение n определяется числом, записанным в поле HA-Len, а m - числом из поля PA-Len. Для Internet PA-Len=4 и тип протокола=2048, а для Ethernet равно HA-Len=6 и тип оборудования=1. В RARP используется два кода операции. Код операции=3 используется для RARP-запросов, а код операции=4 - для RARP-откликов. В первом случае поле протокольный адрес отправителя и протокольный адрес адресата не определены. Обычно локальная сеть имеет несколько RARP-серверов, что позволяет загрузиться бездисковым машинам, даже если какой-то из серверов выключен или не исправен.

    Previous: 4.4.7 Прокси-ARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9 Протокол IGMP


    previous up down next index index
    Previous: 4.4.8 Протокол обратного адресного преобразования RARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.1 Мультикастинг и MBONE

    4.4.9 Протокол IGMP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Передача мультимедийных данных по сетям Интернет является одним из наиболее важных направлений. Этот вид информации передается обычно в режиме без установления соединения (протокол UDP-RTP). Наиболее типичной схемой в этом случае является наличие одного передатчика и большого числа приемников. Эта схема реализуется с использованием мультикастинг-адресации. Мультикастинг-адресация может осуществляться на IP- и MAC-уровнях. В Ethernet для этих целей зарезервирован блок адресов в диапазоне от 01:00:5E:00:00:00 до 01:00:5E:7F:FF:FF. Первый байт адреса, равный 01, указывает на то, что адрес является мультикастным. Данная схема резервирования адресного пространства позволяет использовать 23 бита Ethernet-адреса для идентификации группы рассылки при IP-мультикастинге (см. рис. 4.4.9.1.).

    Рис. 4.4.9.1. Соотношение мультикастинговых MAC- и IP-адресов

    Область из 5 бит в IP-адресе, отмеченная *****, не используется при формировании Ethernet-адреса. Так как соотношение IP и MAC-адресов не является однозначным, драйверы должны обеспечивать обработку адресов с тем, чтобы интерфейсы получали только те кадры, которые действительно им предназначены. Для того чтобы информировать маршрутизатор о наличии участников мультикастинг-обмена в субсети, связанной с тем или иным интерфейсом, используется протокол IGMP.

    Протокол IGMP (internet group management protocol, RFC-1112) используется для видеоконференций, передачи звуковых сообщений, а также группового исполнения команд различными ЭВМ. Этот протокол использует групповую адресацию (мультикастинг).

    Групповая форма адресации нужна тогда, когда какое-то сообщение или последовательность сообщений необходимо послать нескольким (но не всем) адресатам одновременно. При этой форме адресации ЭВМ имеет возможность выбрать, хочет ли она участвовать в этой процедуре. Когда группа ЭВМ хочет взаимодействовать друг с другом, используется один групповой (мультикастинг) адрес. Групповая адресация может рассматриваться как обобщение обычной системы адресов, а традиционный IP-адрес - частный случай группового обращения при числе ЭВМ, равном 1.

    При групповой адресации один и тот же пакет может быть доставлен заданной группе ЭВМ. Членство в этой группе может динамично меняться со временем. Любая ЭВМ может войти в группу и выйти из группы в любое время по своей инициативе. В то же время ЭВМ может быть членом большого числа таких групп. ЭВМ может посылать пакеты членам группы, не являясь им сама. Каждая группа имеет свой адрес класса D (рис. 4.4.9.2, см. также рис. 4.4.9.1).


    Рис. 4.4.9.2. Формат группового адреса

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

    Таблица 4.4.9.1. Коды мультикастинг-процессов

    Уровень мультикастинг-процесса

    Описание

    0

    ЭВМ не может ни посылать, ни принимать данные

    1

    ЭВМ может только посылать пакеты в процессе IP-мултикастинга

    2

    ЭВМ в режиме мультикастинга может передавать и принимать пакеты

    Ряд мультикастинг-адресов зарезервировано строго для определенных целей.

    Таблица 4.4.9.2. Зарезервированные мультикастинг-адреса

    Мультикастинг адрес

    Описание

    224.0.0.0

    Зарезервировано

    224.0.0.1

    Все системы данной субсети

    224.0.0.2

    Все маршрутизаторы данной субсети

    224.0.0.4

    Все DVMRP-маршрутизаторы

    224.0.0.5-224.0.0.6

    OSPFIGP (MOSPF)

    224.0.0.9

    Маршрутизаторы RIP2

    224.0.0.10

    IGRP маршрутизаторы

    224.0.1.0

    VMTP-группа менеджеров

    224.0.1.1

    NTP-network time protocol - сетевая службы времени

    224.0.1.6

    NSS - сервер имен

    224.0.1.7

    Audionews - audio news multicast (аудио служба новостей)

    224.0.1.9

    MTP (multicast transport protocol) - транспортный протокол мультикастинга

    224.0.1.10

    IETF-1-low-audio

    224.0.1.11

    IETF-1-audio

    224.0.1.12

    IETF-1-video

    224.1.0.0-224.1.255.255

    ST мультикастинг-группы

    224.2.0.0-224.2.255.255

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

    232.0.0.0-232.255.255.255

    VMTP переходные группы

    Для того чтобы участвовать в коллективных обменах в локальной сети ЭВМ должна быть снабжена программой, которая поддерживает этот режим. При этом сервер локальной сети (gateway) информируется о намерении использовать мультикастинг. Сервер передает эту информацию другим внешним серверам IP-сети. Следует иметь в виду, что мультикастинг также как и широковещательный режим, заметно загружает сеть. IGMP для передачи своих сообщений использует IP-дейтограммы (IGMP-пакеты инкапсулируются в них). Для подключения к группе сначала посылается IGMP-сообщение "всем ЭВМ" о включении в группу, при этом локальный мультикаст-сервер подготавливает маршрут. Локальный мультикаст-сервер время от времени проверяет ЭВМ и определяет, не покинули ли они группу (ЭВМ не подтверждает свое членство в группе). Все обмены между ЭВМ и мультикаст-сервером производятся в режиме ip-мультикастинга, те есть, любое сообщение адресуется всем ЭВМ группы. ЭВМ, не принадлежащая группе, IGMP-сообщений не получает, что сокращает загрузку сети. Формат сообщений в протоколе IGMP имеет вид, показанный ниже на рис. 4.4.9.3.

    Рис. 4.4.9.3. Формат IGMP-сообщений

    Поле версия определяет используемую версию протокола, поле тип=1 говорит о том, что это запрос, отправленный мультикастинг-маршрутизатором, тип=2 указывает, что этот отклик послан ЭВМ. ЭВМ использует групповой адрес, чтобы сообщить о своем подключении к группе. Контрольная сумма вычисляется по тому же алгоритму, что и для ICMP. IGMP-сообщения используются мультикастинг-маршрутизаторами для того, чтобы отслеживать членство в группе каждой из сетей, подключенных к нему. В группе может участвовать несколько активных процессов в одной и той же ЭВМ, но при этом посылается только один запрос для регистрации. Когда какой-то процесс покидает группу, ЭВМ не шлет сообщения об этом, даже в случае, когда это последний из процессов - членов группы на данной ЭВМ. Просто при очередном запросе ЭВМ не подтвердит членство в группе. Мультикастинг-маршрутизатор регулярно посылает запросы с требованием подтвердить участие в группе. ЭВМ посылает отклик- подтверждение для каждой из групп, если у нее есть хотя бы один процесс - член группы. На основе этих запросов-откликов мультикастинг-маршрутизатор составляет и поддерживает таблицу интерфейсов, которые имеют одну или более ЭВМ, входящих в мультикастинг-группы.

    Протокол IGMP используется при организации мультикастинг-туннелей для передачи звуковой и видеоинформации. Для решения проблем мультимедиа в сетях Интернет используется идея MBONE.

    По умолчанию мультикаст-дейтограммы имеют значение поля TTL=1, что ограничивает их распространение одной субсетью. Приложения могут увеличивать значение TTL. Первая дейтограмма, тем не менее, всегда имеет TTL=1. Если получение этой дейтограммы не подтверждается сервером, посылается вторая - с TTL=2 и т.д. Таким образом попутно измеряется и число шагов между клиентом и сервером. Для случая, когда число шагов не более 1, зарезервирован блок адресов 224.0.0.0 - 224.0.0.255. Маршрутизатор не обрабатывает пакеты с такими адресами вне зависимости от кода поля TTL.

    При использовании мультикастинга MAC-переключатели переадресуют пакеты через все имеющиеся интерфейсы, что заметно ухудшает эффективность сети. Чтобы решить эту проблему компания CISCO разработала протокол CGMP (Cisco Group Management Protocol), который позволяет взаимодействовать маршрутизаторам и переключателям, что позволяет передавать мультикаст-пакеты только на те интерфейсы, где имеются активные члены группы.

    Previous: 4.4.8 Протокол обратного адресного преобразования RARP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.1 Мультикастинг и MBONE


    previous up down next index index
    Previous: 4.4.9 Протокол IGMP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.2 Протокол реального времени RTP

    4.4.9.1 Мультикастинг и MBONE
    Семенов Ю.А. (ГНЦ ИТЭФ)

    MBONE - это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются "туннелями". Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году.

    IP-мультикастинг-пакеты инкапсулируются при передаче через туннели так, что они выглядят как обычные IP-уникаст-пакеты.

    Мультикастинг-маршрутизатор при посылке пакета через туннель подготавливает IP-пакет с заголовком, который содержит адрес маршрутизатора-партнера на другом конце туннеля, при этом поле IP-протокола содержит код 4 (IP). Маршрутизатор-приемник извлекает вложенный мультикастинг-пакет и направляет далее, если это требуется.

    MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с.

    Каждый туннель имеет определенный порог для переменной времени жизни пакета (time-to-live - TTL). Согласно договоренности (IETF) широкополосная видео-информация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видео-пакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, существующему в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами. Следует помнить, что маршрутизатор не откликнется ICMP-сообщением "время истекло", когда TTL достигнет нуля, так как вообще дейтограммы с мультикастинг-адресами не вызывают ICMP-откликов. Увеличивая TTL, прикладной процесс может расширять "зону взаимодействия". Сначала дейтограмма может посылаться с TTL=1, если отклика не получено, c TTL=2 и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает.

    Конфигурация системы в режиме мультикастинга производится автоматически. Для того чтобы изменить конфигурацию системы, или добавить еще один туннель используются специальные конфигурационные команды, которые записываются в /etc/mrouted.conf. Существует два типа таких команд:

    phyint <local-addr> [disable] [metric <m>] [threshold <t>]

    tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>]

    Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<local-addr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Последняя команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1.

    Специфика мультикастинг-туннелей требует принципиально новых решений задачи маршрутизации, первой попыткой разрешить эту проблему был протокол DVMRP. Следует иметь в виду, что DVMRP может решить лишь часть задачи, хотя бы потому, что это внутренний протокол. Главной особенностью мультикастинг-маршрутизации является то, что нужно проложить маршруты от источника к совокупности адресатов, от которых пришли запросы участия в процессе. Режим мультикастинга поддерживается не всеми маршрутизаторами Интернет. Возможны конфликты при решении задачи маршрутизации, когда транзитный маршрутизатор не имеет "своих" участников группы (а должен выделить заметный ресурс каналов для удовлетворения внешних запросов).

    Previous: 4.4.9 Протокол IGMP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.2 Протокол реального времени RTP


    previous up down next index index
    Previous: 4.4.9.1 Мультикастинг и MBONE    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.3 Транспортный протокол реального времени RTCP

    4.4.9.2 Протокол реального времени RTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В Интернет, также как и в некоторых других сетях, возможна потеря пакетов изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. Мультимедийные приложения накладывают достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями Интернет был разработан протокол RTP. Протокол RTP (См. RFC-2205, -2209, -2210, -1990, -1889; "RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предложенных Кларком и Тенненхаузом [1], и предназначен для доставки данных в реальном масштабе времени (например, аудио- или видео). При этом определяется тип поля данных, производится нумерация посылок, присвоение временных меток и мониторирование доставки. Приложения обычно используют RTP поверх протокола UDP для того, чтобы использовать его возможности мультиплексирования и контрольного суммирования. Но RTP может использоваться и поверх любой другой сетевой транспортной среды. RTP поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем.

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

    На практике протокол RTP не отделим от протокола RTCP (RTP control protocol). Последний служит для мониторинга qos и для передачи информации об участниках обмена в ходе сессии.

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

    При организации аудио-конференции каждый участник должен иметь адрес и два порта, один для звуковых данных, другой для управляющих RTCP-пакетов. Эти параметры должны быть известны всем участникам конференции. При необходимости соблюдения конфиденциальности информация и пакеты управления могут быть зашифрованы. При аудио конференциях каждый из участников пересылает небольшие закодированные звуковые фрагменты длительностью порядка 20 мсек. Каждый из таких фрагментов помещается в поле данных RTP-пакета, который в свою очередь вкладывается в UDP-дейтограмму.

    Заголовок пакета RTP определяет, какой вид кодирования звука применен (PCM, ADPCM или LPC), что позволяет отправителю при необходимости сменить метод кодирования, если к конференции подключился новый потребитель с определенными ограничениями или сеть требует снижения скорости передачи.

    При передаче звука весьма важным становится взаимное положение закодированных фрагментов во времени. Для решения задачи корректного воспроизведения заголовки пакетов RTP содержат временную информацию и порядковые номера. Порядковые номера позволяют не только восстановить правильный порядок фрагментов, но и определить число потерянных пакетов-фрагментов.

    Так как участники конференции могут появляться и исчезать по своему усмотрению, полезно знать, кто из них присутствует в сети в данный момент, и как до них доходят передаваемые данные. Для этой цели периодически каждый из участников транслирует через порт RTCP мультикастинг-сообщение, содержащее имя участника и диагностические данные. Узел-участник конференции шлет пакет BUY (RTCP), если он покидает сессию.

    Если в ходе конференции передается не только звук но и изображение, они передаются как два независимых потока с использованием двух пар UDP-портов. RTCP-пакеты посылаются независимо для каждой из этих двух сессий.

    На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же канонические имена участников.

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

    Смеситель преобразует поток аудио-пакетов в следовательность пакетов, которая соответствует возможностям узкополосного канала. Эти пакеты могут быть уникастными (адресованными одному получателю) или мультикастными. Заголовок RTP включает в себя средства, которые позволяют мультиплексорам идентифицировать источники, внесшие вклад. Так что получатель может правильно идентифицировать источник звукового сигнала.

    Некоторые участники конференции, использующие широкополосные каналы, не доступны для IP-мультикастинга (например, находятся за Firewall). Для таких узлов смесители не нужны, здесь используется другой RTP-уровень передачи, называемый трансляцией. Устанавливается два транслятора по одному с каждой из сторон Firewall. Внешний транслятор передает мультикастинг-пакеты по безопасному каналу внутреннему транслятору. Внутренний же транслятор рассылает их подписчикам локальной сети обычным образом.

    Смесители и трансляторы могут выполнять и другие функции, например, преобразование IP/UDP пакетов в ST-II при видео конференциях.

    Определения

    Поле данных RTP: Информация, пересылаемая в пакете RTP, например фрагменты звука или сжатые видео данные.

    Пакет RTP: Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет, но это требование не является обязательным. Поле источников информации может быть пустым.

    Пакет RTCP: Управляющий пакет, содержащий фиксированный заголовок сходный с RTP, за которым следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня.

    Транспортный адрес: Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

    Сессия RTP: Период с момента установления группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.

    Источник синхронизации (SSRC): Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации образуют часть с идентичной временной привязкой и нумерацией. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Участник сессии не должен использовать один и тот же SSRC-идентификатор для всех RTP-сессий мультимедийного набора. Если участник формирует несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), каждый участник должен быть снабжен уникальным SSRC-идентификатором.

    Информационный источник CSRC (contributing source): Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

    Оконечная система: Приложение, которое генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Оконечная система может выступать в качестве одного или нескольких источников синхронизации для конкретной сессии.

    Смеситель: Промежуточная система, которая получает RTP-пакеты от одного или нескольких источников, при необходимости меняет их формат, объединяет и пересылает их адресатам. Так как временная привязка входных пакетов может отличаться, смеситель осуществляет их синхронизацию и генерирует свой собственный поток RTP-пакетов. Таким образом все посылаемые пакеты имеют в качестве источника синхронизации смеситель.

    Транслятор: Промежуточная система, которая переадресует RTP-пакеты, не изменяя их идентификаторы источника синхронизации. Такие устройства используются для преобразования системы кодирования, перехода от мультикастинг- к традиционной уникаст-адресации или при работе с Firewall.

    Монитор: Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

    Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [3]. Если не оговорено обратного все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4. Октеты-заполнители содержат нули.

    Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 [4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит целочисленная часть и 16 бит дробная).

    Заголовок RTP-пакета имеет следующий формат (см. рис. 4.4.9.2.1).

    Рис. 4.4.9.2.1. Заголовок пакета RTP

    Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:

    v (Версия): 2 бита

    Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 - в аудио приложении "vat".

    p (Заполнитель): 1 бит

    Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

    x (Расширение): 1 бит

    Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.

    CC(CSRC count - число CSRC): 4 бита

    Число CSRC содержит код количества csrc-идентификаторов, которые записаны в пакете.

    M (маркер): 1 бит

    Интерпретация маркера определяется профайлом. Предполагается разрешить выделять в потоке пакетов существенные события, такие как границы кадра. Профайл может определить дополнительные маркерные биты или специфицировать отсутствие маркерных битов путем изменения числа битов в поле PT.

    PT(Тип данных): 7 бит

    Это поле идентифицирует формат поля данных RTP-пакета и определяет интерпретацию его приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft draft-ietf-avt-profile, и может быть расширен в следующих редакциях стандарта assigned numbers (RFC-1700) [5].

    Номер по порядку: 16 бит

    Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [6].

    Временная метка: 32 бита

    Временная метка соответствует времени стробирования для первого октета в информационном RTP-пакете. Время стробирования должно быть получено от часов, показания которых увеличиваются монотонно и линейно, чтобы обеспечить синхронизацию и вычисление временного разброса. Разрешающая способность часов должна быть достаточной для обеспечения приемлемой точности синхронизации (одного тика на видео кадр обычно не достаточно). Частота часов зависит от формата данных и задается статически в профайле, в спецификации поля данных, или динамически средствами, выходящими за пределы спецификации протокола RTP. Если RTP-пакеты генерируются периодически, используется временная привязка, определенная задающим генератором стробирования, а не показаниями системных часов.

    Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к и тому же видео кадру).

    SSRC: 32 бита

    Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

    CSRC-список: от 0 до 15 элементов, по 32 бита каждый

    CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

    Для эффективной реализации протокола число точек мультиплексирования должно быть минимизировано. В RTP, мультиплексирование осуществляется по транспортным адресам мест назначения, которые определены RTP-сессией. Использование пакетов с различным типом поля данных но с идентичным ssrc создает определенные проблемы:

    1. Если один из типов данных будет изменен в ходе сессии, нет универсальных средств для определения, какое из старых значений следует заменить на новое.

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

    3. RTCP-сообщения отправителя и получателя могут описать только одно пространство номеров и временных меток для каждого SSRC и не имеют поля типа данных.

    4. RTP-смеситель не сможет объединять перекрывающиеся потоки при условии их несовместимости.

    5. Работа со многими средами в пределах одной RTP-сессии предполагает: использование различных сетевых путей или разного размещения сетевых ресурсов; приема только одного субнабора, например аудио, когда видео недоступно из-за недостатка широкополосности.

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

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

    • Бит маркера и поле типа данных содержат информацию, задаваемую профайлом, но они размещаются в стандартном заголовке, так как нужны многим приложениям. Октет, где размещаются эти поля, может быть переопределен профайлом. При любом числе маркерных битов один должен размещаться в старшем разряде октета, так как это необходимо для мониторирования потока.
    • Дополнительная информация, которая необходима для конкретного формата поля данных, такая как тип видео-кодирования, должна транспортироваться в поле данных пакета. Это может быть заголовок, присутствующий в начале поля данных.
    • Если конкретное приложение нуждается в дополнительных возможностях, которые не зависят от содержимого поля данных, профайл данного приложения должен определить дополнительные фиксированные поля, следующие непосредственно после поля SSRC существующего заголовка пакета. Эти приложения смогут получить доступ к этим дополнительным полям, при этом сохраняются все стандартные средства контроля и мониторинга, так как они базируются на первых 12 октетах заголовка.

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

    Расширения заголовка предназначены для ограниченного использования. И многие приложения лучше реализовать, используя профайл. Формат реализации расширений показан на рис. 4.4.9.2.2.

    Рис. 4.4.9.2.2. Формат расширения заголовка

    Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список csrc. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Для того чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров. Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение.

    Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

    RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, ip/udp), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий.

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

    • Каждая из областей, соединенных транслятором или смесителем, участвующих в одной RTP-сессии должна отличаться от всех других, по крайней мере, одним параметром (протоколом, адресом, портом) или должна быть изолирована от других на сетевом уровне.
    • Следствием первого правила является то, что области не должны быть соединены более чем одним смесителем или транслятором.

    Аналогично все оконечные системы RTP, которые взаимодействуют через один или более трансляторов или смесителей, принадлежат одной и той же ssrc-области, т.е., ssrc-идентификаторы должны быть уникальными для задействованных оконечных систем. Существует большое разнообразие трансляторов и смесителей, спроектированных для решения различных задач и приложений. Некоторые служат для шифрования/дешифрования несущих дейтограмм. Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители объединяют несколько потоков в один.

    Транслятор . Переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Это позволяет получателям идентифицировать отдельные источники, даже если пакеты от всех источников проходят через один общий транслятор и имеют сетевой адрес транслятора. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки. Приемник не может заметить присутствия транслятора.

    Смеситель . Принимает потоки RTP-данных от одного или нескольких источников, может изменять формат данных, определенным образом объединяет потоки и затем формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Смеситель является источником синхронизации. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести свои SSRC-идентификаторы в список CSRC-идентификаторов, который следует за фиксированным RTP-заголовком пакета. Смеситель, который, кроме того, вносит в общий поток свою составляющую, должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета.

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

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

    Рис. 4.4.9.2.3 Пример RTP сети с оконечными системами, смесителями и трансляторами

    Некоторый набор смесителей и трансляторов представлен на рис. 4.4.9.2.3. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены желтым цветом. Трансляторы обозначены буквами TRS (на рисунке овалы голубого цвета) и смесители обозначены как MUX (прямоугольники сиреневого цвета). Запись "M1:13(1,17)" обозначает пакет отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2.

    Последовательное включение смесителей

    В RTP-сессии могут быть задействованы несколько смесителей и трансляторов, как это показано на рис. 4.4.9.2.3. Если два смесителя включены последовательно, так как MUX2 и MUX3, пакеты полученные смесителем могут быть уже объединены и включать CSRC-список со многими идентификаторами. Cмеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36). Если число идентификаторов в списке CSRC превышает 15, остальные не могут быть туда включены.

    SSRC-идентификаторы в RTP-заголовках и в различных полях RTCP-пакетов являются случайными 32-битовыми числами, которые должны быть уникальными в рамках RTP-сессии. Очень важно, чтобы одни и те же числа не были использованы несколькими участниками сессии.

    Недостаточно использовать в качестве идентификатора локальный сетевой адрес (такой как IPv4), так как может быть не уникальным. Так как RTP трансляторы и смесители допускают работу с сетями, использующими различные адресные пространства, это допускает их случайное совпадение с большей вероятностью, чем в случае использования случайных чисел.

    Не приемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации.

    Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N число источников, а L длина идентификатора (в нашем случае, 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [8]) составляет 1 - exp(-N2 / 2(L+1)). Для N=1000, вероятность примерно равна 10-4.

    Типовое значение вероятности столкновения много меньше худшего случая, рассмотренного выше. Рассмотрим случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L длина идентификатора, вероятность столкновения равна N / 2L. Для N=1000, вероятность составит около 2*10 -7.

    Вероятность столкновения уменьшается еще больше в случае, когда новый источник получает пакеты других участников до того, как передаст свой первый пакет. Если новый источник отслеживает идентификаторы других участников, он легко может устранить вероятность конфликта.

    Преодоление столкновений и детектирование петель

    Хотя вероятность столкновения идентификаторов SSRC довольно мала, все RTP реализации должны быть готовы обнаруживать столкновения и предпринимать адекватные меры для их преодоления. Если источник обнаруживает в какой-либо момент, что другой источник использует тот же идентификатор SSRC, он посылает пакет RTCP BYE для старого идентификатора и выбирает новый. Если получатель обнаруживает, что два других источника имеют равные идентификаторы (столкновение), он может воспринимать пакеты от одного и игнорировать от другого до тех пор, пока это не будет зарегистрировано отправителями или CNAME.

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

    • Транслятор может некорректно переадресовать пакет некоторой мультикастинг-группе, откуда этот пакет получен. Это может быть сделано непосредственно или через цепочку трансляторов. В этом случае один и тот же пакет появится несколько раз, приходя от разных сетевых источников.
    • Два транслятора некорректно поставленные в параллель, т.е., с одними и теми же мультикастными группами на обеих сторонах будут направлять пакеты от одной мультикастной группы к другой. Однонаправленные трансляторы могут создать две копии; двунаправленные трансляторы могут образовать петлю.
    • Смеситель может замкнуть петлю путем посылки пакета по адресу, откуда он был получен. Это может быть выполнено непосредственно, через смеситель или через транслятор.

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

    Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор с тем, чтобы ситуация не была интерпретирована, как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако, столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола RTCP).

    Для того чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако, когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание. Это требуется для того, чтобы избежать потока пакетов BYE.

    Этот алгоритм зависит от равенства транспортных адресов для RTP и RTCP пакетов источника. Алгоритм требует модификации приложений, которые не отвечают этому ограничению.

    Этот алгоритм требует наличия таблицы транспортных адресов источников, упорядоченных по их идентификаторам. В таблицу заносятся адреса, откуда данный идентификатор был впервые получен. Каждый SSRC или CSRC идентификатор, полученный с информационным или управляющим пакетом ищется в этой таблице, для того чтобы корректно обработать полученные данные. Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC, или когда достаточно долго не приходит вообще никаких пакетов.

    Для того чтобы отслеживать зацикливание собственных пакетов участников, необходимо также завести отдельный список транспортных адресов источников, которые считаются конфликтными. Заметим, что это должен быть короткий список, обычно пустой. Каждый элемент этого списка хранит адрес источника и время, когда был получен последний конфликтный пакет. Элемент может быть удален из списка, когда за время 10 периодов посылки RTCP сообщений-отчетов не прибыло ни одного конфликтного пакета.

    Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников.

    IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:

    THEN создать новую запись и внести туда транспортный адрес источника и SSRC или
    CSRC вместе с кодом состояния.
    CONTINUE (продолжить) обычную процедуру обработки.
    Идентификатор найден в таблице
    IF транспортный адрес источника из пакета совпадает с одним из записанных в таблице:
    THEN CONTINUE Продолжить обычную процедуру обработки.
    Обнаружено столкновение идентификаторов или зацикливание
    IF идентификатор источника не совпадает с собственным идентификатором участника:
    THEN IF идентификатор источника совпадает с тем, что содержится в фрагменте RTCP SDES содержащем элемент CNAME, который отличается от CNAME из рекорда таблицы:
    THEN (опционно) Случилось столкновение посторонних идентификаторов.
    ELSE (опционно) Случилось зацикливание.
    ABORT Прервать обработку информационного или управляющего пакета.
    Столкновение для идентификатора участника или зацикливание его пакетов
    IF транспортный адрес найден в списке конфликтных адресов:
    THEN IF идентификатор источника не найден во фрагменте RTCP SDES, содержащем CNAME, или если CNAME принадлежит участнику:
    THEN (опционно) случилось зацикливание собственного трафика.
    Записать текущее время в соответствующую запись таблицы конфликтных адресов.
    ABORT (прервать) обработку информационного или управляющего пакета.
    Зафиксировать факт столкновения.
    Внести новую запись в таблицу конфликтных адресов и зафиксировать время записи.
    Послать пакет RTCP BYE с идентификатором SSRC.
    Выбрать новый идентификатор.
    Внести новую запись в таблицу идентификаторов источников со старым SSRC, транспортным адресом источника обработанного пакета.
    CONTINUE Продолжить обычную процедуру обработки.

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

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

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

    Когда необходимо шифрование RTP или RTCP, все октеты будут инкапсулированы в одну дейтограмму нижележащего уровня и зашифрованы как единое целое. Для RTCP в начало последовательности перед шифрованием добавляется 32-битное случайное число, чтобы предотвратить возможные атаки. В случае RTP никаких префиксов не требуется, так как порядковый номер и временная метка и без того являются случайными числами.

    Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC 1423 [9], за исключением того, что используется заполнение кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10]. Приложения, которые используют шифрование должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио и видео приложениями в Интернет. Возможно применение и других криптографических средств.

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

    Для обеспечения демультиплексирования RTP полагается на нижележащий протокольный уровень. Для UDP и сходных с ним протоколов, RTP использует четные номера портов, а соответствующие RTCP-потоки используют нечетные номера портов. Если приложению предлагается использовать нечетный номер RTP-порта, этот номер должен быть заменен на ближайший четный меньше исходного.

    Информационные RTP-пакеты не имеют поля длины или каких-либо других средств ограничения размеров пакета, по этой причине RTP полагается на нижележащий протокол при задании размера поля данных. Максимальная длина RTP-пакетов ограничена размером используемых транспортных пакетов (например, UDP).

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

    Механизм вложения может быть определен в профайле даже в случае, когда для транспортировки RTP используется не поточный протокол, это позволяет укладывать несколько RTP-пакетов в одну дейтограмму транспортного протокола (например, UDP). Передача нескольких RTP-пакетов в одном транспортном уменьшает издержки, связанные с заголовком и может упростить синхронизацию различных потоков.

    Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом а не самим протоколом. Однако, значение октета RTP-заголовка, который содержит бит(ы) маркера не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), для того чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.

    Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, использования различных расширений (см. рис. 4.4.9.2.2) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.

    В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный):

    Заголовок поля данных RTP. Октет RTP заголовка, содержащий маркер тип поля данных, может быть переопределен с помощью профайла (например, можно изменить число маркерных битов).

    Типы поля данных. Профайл обычно определяет набор форматов поля данных (напр., типов кодирования исходных данных) и соответствие между этими форматами и кодами типа поля данных. Для каждого описанного типа поля данных должна быть определена частота временных меток.

    Дополнения к заголовку RTP. К стандартному RTP-заголовку могут быть добавлены новые поля, расширяющие функциональность приложения.

    Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. рис. 4.4.9.2.2).

    Безопасность. Профайл может специфицировать, какие услуги и алгоритмы безопасности должно обеспечить приложение.

    Установка соответствия между строкой и ключом. Профайл может специфицировать, какому ключу шифрования соответствует введенный пользователем пароль.

    Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов.

    Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам.

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

    Не предполагается, что для каждого приложения требуется свой профайл. В пределах одного класса приложений целесообразно использовать расширения одного и того же профайла. Простое расширение, такое как введение дополнительного типа поля данных или нового типа RTCP-пакета, может быть выполнено путем регистрации их через комитет по стандартным числам Интернет и публикации их описаний в приложении к профайлу.

    Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC-1889 на примере кодов, написанных на языке СИ.

    Нижеприведенные определения заимствованы целиком из RFC, ссылка на который приведена в начале данного раздела. Все цифра представлены в формате, где первым является старший октет. Предполагается, что битовые поля размещаются без заполнителей в том же порядке, что и октеты.

    /*
    * rtp.h -- Файл заголовка RTP (RFC 1889)
    */
    #include <sys/types.h>
    /*
    * Нижеприведенные определения предполагают 32-битовое представление, а в случаях
    * 16- или 64-битового представлений необходимы соответствующие модификации.
    */
    typedef unsigned char u_int8;
    typedef unsigned short u_int16;
    typedef unsigned int u_int32;
    typedef short int16;
    /*
    * Текущая версия протокола.
    */
    #define RTP_VERSION 2
    #define RTP_SEQ_MOD (1<<16)
    #define RTP_MAX_SDES 255 /* максимальная длина текста для SDES */
    typedef enum {
    RTCP_SR = 200,
    RTCP_RR = 201,
    RTCP_SDES = 202,
    RTCP_BYE = 203,
    RTCP_APP = 204
    } rtcp_type_t;
    typedef enum {
    RTCP_SDES_END = 0,
    RTCP_SDES_CNAME = 1,
    RTCP_SDES_NAME = 2,
    RTCP_SDES_EMAIL = 3,
    RTCP_SDES_PHONE = 4,
    RTCP_SDES_LOC = 5,
    RTCP_SDES_TOOL = 6,
    RTCP_SDES_NOTE = 7,
    RTCP_SDES_PRIV = 8
    } rtcp_sdes_type_t;
    /*
    * Заголовок RTP-пакета
    */
    typedef struct {
    unsigned int version:2; /* версия протокола */
    unsigned int p:1; /* флаг заполнителя */
    unsigned int x:1; /* Флаг расширения заголовка */
    unsigned int cc:4; /* число CSRC */
    unsigned int m:1; /* Бит маркера */
    unsigned int pt:7; /* тип поля данных */
    u_int16 seq; /* номер по порядку */
    u_int32 ts; /* временная метка */
    u_int32 ssrc; /* источник синхронизации */
    u_int32 csrc[1]; /* опционный список CSRC */
    } rtp_hdr_t;
    /*
    * Общее слово RTCP-заголовка
    */
    typedef struct {
    unsigned int version:2; /* версия протокола */
    unsigned int p:1; /* флаг заполнителя */
    unsigned int count:5; /* варьируется в зависимости от типа пакета */
    unsigned int pt:8; /* тип пакета RTCP */
    u_int16 length; /* Длина пакета в словах */
    } rtcp_common_t;
    /*
    * Маска версии, бита заполнителя и типа пакета
    */
    #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
    #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
    /*
    * Блок отчета о приеме
    */
    typedef struct {
    u_int32 ssrc; /* Источник, для которого составлен отчет */
    unsigned int fraction:8; /* доля потерянных пакетов с момента последнего SR/RR */
    int lost:24; /* полное число потерянных пакетов */
    u_int32 last_seq; /* номер последнего полученного пакета */
    u_int32 jitter; /* разброс времени прихода пакетов */
    u_int32 lsr; /* последний SR-пакет от этого источника */
    u_int32 dlsr; /* задержка с момента последнего SR пакета */
    } rtcp_rr_t;
    /*
    * элемент SDES
    */
    typedef struct {
    u_int8 type; /* тип элемента (rtcp_sdes_type_t) */
    u_int8 length; /* Длина элемента (в октетах) */
    char data[1]; /* текст */
    } rtcp_sdes_item_t;
    /*
    * One RTCP packet
    */
    typedef struct {
    rtcp_common_t common; /* общий заголовок */
    union {
    /* sender report (SR) */
    struct {
    u_int32 ssrc; /* Отправитель, генерирующий этот отчет */
    u_int32 ntp_sec; /* временная метка NTP */
    u_int32 ntp_frac;
    u_int32 rtp_ts; /* временная метка RTP */
    u_int32 psent; /* послано пакетов */
    u_int32 osent; /* послано октетов */
    rtcp_rr_t rr[1]; /* список переменной длины */
    } sr;
    /* Отчет о приеме (RR) */
    struct {
    u_int32 ssrc; /* приемник, формирующий данный отчет */
    rtcp_rr_t rr[1]; /* список переменной длины */
    } rr;
    /* описание источника (SDES) */
    struct rtcp_sdes {
    u_int32 src; /* первый SSRC/CSRC */
    rtcp_sdes_item_t item[1]; /* список элементов SDES */
    } sdes;
    /* BYE */
    struct {
    u_int32 src[1]; /* список источников */
    /* can't express trailing text for reason */
    } bye;
    } r;
    } rtcp_t;
    typedef struct rtcp_sdes rtcp_sdes_t;
    /*
    * Информация состояния источников
    */
    typedef struct {
    u_int16 max_seq; /* наибольший зарегистрированный номер */
    u_int32 cycles; /* shifted count of seq. number cycles */
    u_int32 base_seq; /* основной порядковый номер */
    u_int32 bad_seq; /* последний 'плохой' порядковый номер + 1 */
    u_int32 probation; /* sequ. packets till source is valid */
    u_int32 received; /* пакетов получено */
    u_int32 expected_prior; /* пакет, ожидаемый в последнем интервале */
    u_int32 received_prior; /* пакет, полученный за последний интервал */
    u_int32 transit; /* относительное время передачи для предыдущего пакета */
    u_int32 jitter; /* оценка временного разброса */
    /* ... */
    } source;

    Получатель RTP-пакета должен проверить корректность заголовка. Здесь следует учитывать, что пакет может быть зашифрован. Если пакет не пройдет данную проверку (например, неверно дешифрован, ошибка в адресе или обнаружен неизвестный тип поля данных), должно быть выработано соответствующее сообщение. Ограниченная проверка допустима только для нового источника:

    • В поле версии RTP должен быть записан код 2.

    • Тип поля данных должен быть из числа известных, в частности он не должен быть равным SR или RR.

    • Если бит P=1, тогда последний октет пакета должен содержать правильное число октетов, в частности оно должно быть меньше полной длины пакета минус размер заголовка.

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

    • Длина пакета должна согласовываться с CC и типом поля данных (если длина поля данных известна).

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

    Программа update_seq, приведенная ниже гарантирует, что источник декларирован правильно после получения MIN_SEQUENTIAL последовательно пронумерованных пакетов. Она также проверяет номера пакетов SEQ и актуализует состояние источника пакетов в структуре, на которую указывает S.

    Когда новый источник дает о себе знать впервые (т.е. его SSRC-идентификатор отсутствует в таблице), и для описания его состояния выделено место в памяти, S->probation должно быть сделано равным числу последовательных пакетов, которые должны быть зарегистрированы до того, как источник будет объявлен легальным (параметр MIN_SEQUENTIAL ), а переменной s->max_seq присваивается значение SEQ-1. s->probation помечает источник как еще нелегальный, так что описание его состояния может быть выброшено после короткой выдержки.

    После того как источник признан легальным, номер по порядку считается корректным, если он не больше чем на MAX_DROPOUT впереди S->max_seq и не больше на MAX_MISORDER после.

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

    Приведенные типовые значения параметров базируются на максимальном времени сбоя нумерации равном 2 секундам при скорости 50 пакетов/сек и времени таймаута 1 минута. Параметр таймаута MAX_DROPOUT должен соответствовать небольшой доле от 16-битового диапазона нумерации. Таким образом, после рестарта новый номер пакета с большой вероятностью не должен попасть в допустимый диапазон.

    void init_seq(source *s, u_int16 seq)
    {
    s->base_seq = seq - 1;
    s->max_seq = seq;
    s->bad_seq = RTP_SEQ_MOD + 1;
    s->cycles = 0;
    s->received = 0;
    s->received_prior = 0;
    s->expected_prior = 0;
    /* other initialization */
    }
    int update_seq(source *s, u_int16 seq)
    {
    u_int16 udelta = seq - s->max_seq;
    const int MAX_DROPOUT = 3000;
    const int MAX_MISORDER = 100;
    const int MIN_SEQUENTIAL = 2;
    *
    * Источник нелегален до тех пор, пока не будет получено MIN_SEQUENTIAL пакетов
    * с последовательно нарастающими номерами.
    */
    if (s->probation) {
    /* пакет соответствует последовательности */
    if (seq == s->max_seq + 1) {
    s->probation--;
    s->max_seq = seq;
    if (s->probation == 0) {
    init_seq(s, seq);
    s->received++;
    return 1;
    }
    } else {
    s->probation = MIN_SEQUENTIAL - 1;
    s->max_seq = seq;
    }
    return 0;
    } else if (udelta < MAX_DROPOUT) {
    /* в порядке, с допустимым зазором */
    if (seq < s->max_seq) {
    /*
    * Порядковый номер переполнен - начинаем новый 64K цикл.
    */
    s->cycles += RTP_SEQ_MOD;
    }
    s->max_seq = seq;
    } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
    /* порядковый номер изменился слишком сильно */
    if (seq == s->bad_seq) {
    /*
    * Два последовательных пакета - предполагается, что другая сторона рестартовала, не
    * предупредив нас об этом. re-sync (т.е., считаем, что получили первый пакет).
    */
    init_seq(s, seq);
    }
    else {
    s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
    return 0;
    }
    } else {
    /* задублированные пакеты или пакеты с перепутанным порядком прихода */
    }
    s->received++;
    return 1;
    }

    Проверка корректности может быть и жестче, требуя более двух пакетов с последовательными номерами подряд. Недостатком такого подхода будут трудности, связанные с каналами, где вероятность потери пакета велика. Однако, так как проверка корректности заголовка RTCP-пакета достаточно строга, можно ограничиться требованием двух последовательных информационных пакетов. Если начальная потеря данных в течение нескольких секунд приемлема, приложение может выбрасывать все информационные пакеты до тех пор, пока не будет получен от источника корректный RTCP-пакет.

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

    Для того чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов получается простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета (s->max_seq) и номером первого пакета в последовательности (S->base_seq). При этом нужно учитывать то, что номера имеют 16 бит, и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles).

    extended_max = s->cycles + s->max_seq;
    expected = extended_max - s->base_seq + 1;

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

    lost = expected - s->received;

    Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета.:

    expected_interval = expected - s->expected_prior;
    s->expected_prior = expected;
    received_interval = s->received - s->received_prior;
    s->received_prior = s->received;
    lost_interval = expected_interval - received_interval;
    if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
    else fraction = (lost_interval << 8) / expected_interval;

    Результирующее значение доли равно 8-битовому числу с фиксированной запятой, расположенной слева.

    Генерирование псевдослучайных 32-битовых идентификаторов

    Ниже приведенная подпрограмма (заимствована из RFC-1889) генерирует псевдослучайные 32-битовые идентификаторы, используя программы MD5, опубликованные в RFC-1321 [11]. Системные программы могут и не присутствовать во всех операционных системах, но они помогают понять, какого рода информация может использоваться.

    o getdomainname() ,
    o getwd() , или
    o getrusage()

    "Живые" видео или аудио сигналы могут быть также не плохим источником случайных числе, при этом только следует позаботиться о том, чтобы микрофон не был отключен, а объектив камеры не был закрыт [7].

    Использование этой или другой подобной программы предполагает определенную процедуру инициализации, которая нужна для получения первых псевдослучайных чисел. Так как эта программа заметно загружает процессор, ее непосредственное использование для генерации RTCP-периодов нельзя считать приемлемым. Следует заметить, что данная программа выдает один и тот же результат при последовательных вызовах до тех пор, пока не изменится показание системных часов или не будет задано другое значение аргумента type.

    /*
    * Генерация псевдослучайного 32-битового числа.
    */
    #include <sys/types.h> u_long */
    #include <sys/time.h> /* gettimeofday() */
    #include <unistd.h> /* get..() */
    #include <stdio.h> /* printf() */
    #include <time.h> /* clock() */
    #include <sys/utsname.h> /* uname() */
    #include "global.h" /* from RFC 1321 */
    #include "md5.h" /* from RFC 1321 */
    #define MD_CTX MD5_CTX
    #define MDInit MD5Init
    #define MDUpdate MD5Update
    #define MDFinal MD5Final
    static u_long md_32(char *string, int length)
    {
    MD_CTX context;
    union {
    char c[16];
    u_long x[4];
    } digest;
    u_long r;
    int i;
    MDInit (&context);
    MDUpdate (&context, string, length);
    MDFinal ((unsigned char *)&digest, &context);
    r = 0;
    for (i = 0; i < 3; i++) {
    r ^= digest.x[i];
    }
    return r;
    } /* md_32 */
    /*
    * Полученный результат - 32-битовое число без знака. Используйте аргумент 'type' если вам
    * нужно получить несколько разных величин подряд.
    */
    u_int32 random32(int type)
    {
    struct {
    int type;
    struct timeval tv;
    clock_t cpu;
    pid_t pid;
    u_long hid;
    uid_t uid;
    gid_t gid;
    struct utsname name;
    } s;
    gettimeofday(&s.tv, 0);
    uname(&s.name);
    s.type = type;
    s.cpu = clock();
    s.pid = getpid();
    s.hid = gethostid();
    s.uid = getuid();
    s.gid = getgid();
    return md_32((char *)&s, sizeof(s));
    } /* random32 */

     

    Библиография

    [1]

    D. D. Clark и D. L. Tennenhouse, "Architectural considerations for a new generation of protocols," in SIGCOMM Symposium on Communications Architectures и Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20(4), Sept. 1990.

    [2]

    D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.

    [3]

    Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

    [4]

    Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL, March 1992.

    [5]

    Reynolds, J., и J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

    [6]

    Eastlake, D., Crocker, S., и J. Schiller, "Randomness Recommendations for Security", RFC 1750, DEC, Cybercash, MIT, December 1994.

    [7]

    J.-C. Bolot, T. Turletti, и I. Wakeman, "Scalable feedback control for multicast video distribution in the internet," in SIGCOMM Symposium on Communications Architectures и Protocols, (London, England), pp. 58--67, ACM, Aug. 1994.

    [8]

    Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, и Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.

    [9]

    V. L. Voydock и S. T. Kent, "Security mechanisms in high-level network protocols," ACM Computing Surveys, vol. 15, pp. 135--171, June 1983.

    [10]

    Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science и RSA Data Security, Inc., April 1992.

    [11]

    S. Stubblebine, "Security services for multimedia conferencing," in 16th National Computer Security Conference , (Baltimore, Maryland), pp. 391--395, Sept. 1993.

    [12]

    S. Floyd и V. Jacobson, "The synchronization of periodic routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 122-136, April 1994.

    Previous: 4.4.9.1 Мультикастинг и MBONE    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.3 Транспортный протокол реального времени RTCP


    previous up down next index index
    Previous: 4.4.9.2 Протокол реального времени RTP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP

    4.4.9.3 Транспортный протокол реального времени RTCP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Управляющий протокол RTCP (RTP control protocol; см. RFC-1889 "RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и используется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции:

    1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [1,2], но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.

    2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.

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

    4. Четвертая опционная функция служит для передачи минимальной управляющей информации, например идентификаторов участников, для графического интерфейса пользователя. Это полезно для "слабо управляемых" сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения.

    Функции 1-3 являются обязательными, когда RTP используется в среде с IP мультикастингом, и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в уникастном режиме.

    Формат пакетов RTCP

    Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации:

    sr:

    Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями

    rr:

    Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями

    sdes:

    Элементы описания источника, включая cname

    bye:

    Отмечает прекращение участия в группе

    app:

    Специфические функции приложения

    Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами, за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета.

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

    • Статистика приема (в SR или RR) должна посылаться так часто, как это позволяют ограничения пропускной способности, так что каждый периодически посылаемый составной пакет включает в себя пакет отчета.
    • Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname.
    • Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено.

    Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:

    Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.

    SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye.

    Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.

    SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала.

    Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.

    Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 4.4.9.3.1. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.

    Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).

    Рис. 4.4.9.3.1. Пример составного пакета RTCP (#: SSRC/CSRC)

    Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, при аудио конференциях информационный поток всегда ограничен (сколько бы не было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако, трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.

    Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP).

    Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола - переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.

    Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:

    o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.

    o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.

    o Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников [3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.

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

    Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.

    Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.

    Участник может пометить другой узел как пассивный, или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута.

    Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин.

    Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, специфического для конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не посылать более никакой дополнительной информации. name может быть присвоен более высокий приоритет чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как Email может отображаться только при запросе. При каждой RTCP рассылке, должны посылаться RR- и SDES-пакеты. Последний содержит элемент Cname. Для небольших сессий, работающих с минимальными периодами рассылки, это будет делаться в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент name, и каждый восьмой раз (2 минуты) это будет элемент Email.

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

    RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственным различием между формами отчета отправителя (SR) и получателя (rr), помимо кода типа пакета, является то, что отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отправляется пакет RR.

    Как SR так и RR-формы включают в себя нуль или более блоков отчетов о приеме, один для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.

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

    Версия (v): 2 бита

    Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.

    Заполнитель (p): 1 бит

    Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.

    Рис. 4.4.9.3.2. Формат RTCP пакета сообщения отправителя

    Число отчетов о приеме (RC): 5 бит

    Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль.

    Тип пакета(pt): 8 бит

    Содержит константу 200 для пакетов RTCP SR.

    Длина: 16 бит

    Длина rtcp-пакета в 32-битных словах минус один, включая заголовок и заполнитель.

    ssrc: 32 бит

    Идентификатор источника синхронизации для отправителя sr-пакета.

    Вторая секция информации из 20 октетов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения:

    Временная метка NTP: 64 бита

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

    Временная метка rtp: 32 бита

    Соответствует тому же времени, что и временная метка ntp, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может быть использовано получателями, независящими от среды для оценки номинальной задающей частоты RTP. Заметьте, что в большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах.

    Число пакетов отправителя: 32 бита

    Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор.

    Число октетов отправителя: 32 бита

    Полное число октетов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Это поле может быть использовано для оценки среднего потока данных.

    Третья секция состоит из нуля или более блоков отчета о приеме в зависимости от числа источников, пакеты от которых приняты с момента последнего отчета. Каждый блок отчета о приеме несет в себе статистику получения RTP-пакетов, поступающих от одного из источников синхронизации. Получатель не сохраняет статистику, когда источник изменяет свой ssrc-идентификатор.

    ssrc_n (идентификатор источника): 32 бита

    ssrc-идентификатор источника, к которому относится информация, содержащаяся в блоке отчета о получении.

    Доля потерянных (пакетов): 8 бит

    Часть информационных RTP-пакетов от источника ssrc_n потерянная с момента посылки предыдущего SR или RR-пакетов, представленная в виде числа с фиксированной запятой, помещенной слева. Это эквивалентно целому, полученному после умножения данного числа на 256. Эта доля получается в результате деления числа потерянных пакетов на ожидаемое число пакетов. Если потери из-за дубликатов оказались отрицательны, доля потерянных пакетов объявляется равной нулю. Заметим, что от источника, все пакеты которого были потеряны при транспортировке отчета о приеме послано не будет.

    Суммарное число потерянных пакетов: 24 бита

    Полное число информационных RTP-пакетов от источника SSRC_n, которые были потеряны с момента начала передачи. Это число определяется как разность между ожидаемым и полученным числами пакетов, где число полученных включает в себя и дубликаты. Таким образом, пакеты, пришедшие с опозданием, не считаются потерянными, а число потерянных пакетов может оказаться отрицательным, если получены дубликаты пакетов. Число ожидаемых пакетов определяется как разность между номером последнего полученного пакета и номером первого пакета.

    Наибольший номер из числа полученных пакетов: 32 бита

    Младшие 16 бит содержит наибольший порядковый номер полученного от источника SSRC_n информационного RTP-пакета. Старшие 16 бит несут в себе число циклов нумерации (переполнения счетчика номеров пакетов). Заметим, что различные получатели в рамках одной и той же сессии генерируют разные коды циклов нумерации (расширений), если они начали свою работу в разное время.

    Разброс времени доставки: 32 бита

    Оценка статистической вариации периода прихода RTP-пакетов, измеряемого с помощью временных меток и характеризуемого целым числом. Разброс периода прихода пакетов j определяется как усредненное отклонение разности D расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов.

    Если si равно временной метке i-го пакета RTP, а ri - время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как

    di,j =(rj-ri)-(sj-si)=(rj-sj)-(ri-si)

    Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле

    j=j+(|d i-1,i |-j)/16

    Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Это алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4].

    Последняя временная метка (LSR) (last SR): 32 бита

    Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль.

    Задержка с момента последнего SR (DLSR- delay of last sr): 32 бита

    Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от ssrc_n пока не получено, в поле DLSR заносится нуль.

    Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить циклическую задержку маршрута RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A - LSR- DLSR). Это проиллюстрировано на рис. 4.4.9.3.3.

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

    rr: rtcp-пакет отчета о приеме (RFC-1889)

    [10 nov 1995 11:33:25.125]           [10 nov 1995 11:33:36.5]
    n sr(n) a=b710:8000 (46864.500 s)
    ---------------------------------------------------------------->
    v ^
    ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
    ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
    (3024992016.125 s) v ^
    r v ^ rr(n)
    ---------------------------------------------------------------->
    |<-dlsr->|
    (5.250 s)
    a 0xb710:8000 (46864.500 s)
    dlsr -0x0005:4000 ( 5.250 s)
    lsr -0xb705:2000 (46853.125 s)
    -------------------------------
    delay 0x 6:2000 ( 6.125 s)

    Рис. 4.4.9.3.3. Пример вычисления rtt

    Рис. 4.4.9.3.4. Формат пакета отчета о приеме (RR)

    Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.

    Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0).

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

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

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

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

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

    Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на рис. 4.4.9.3.5 информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.

    Рис. 4.4.9.3.5. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

    SDES: RTCP-пакет описания источника

    Рис. 4.4.9.3.6. Формат пакета SDES

    Пакет SDES состоит из заголовка и нескольких фрагментов, каждый из которых содержит элементы описания источника, соответствующего данному фрагменту (число фрагментов может быть равно нулю).

    Поля версия (v), заполнитель (p) и длина имеют то же назначения что и в случае SR-пакетов.

    Тип пакета (pt): 8 бит

    Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES.

    Число источников (SC): 5 бит

    Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно.

    Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов.

    Текст кодируется согласно требованиям UTF-2, описанным в стандарте 10646 [5,6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", "X/open preliminary specification", документ номер P316 и "Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1.

    Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны.

    Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31.

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

    cname: Канонический идентификатор конечной системы (рис. 4.4.9.3.7).

    Рис. 4.4.9.3.7. Формат Cname

    Идентификатор cname имеет следующие свойства:

    • Так как характеризуемый случайным числом идентификатор ssrc может измениться, если обнаруживается конфликт или если программа перезапускается, элемент cname должен обеспечить связь между идентификатором SSRC и источником, которая должна оставаться неизменной.
    • Подобно идентификатору SSRC, идентификатор cname должен быть уникальным для каждого из участников RTP-сессии.
    • Чтобы обеспечить связь между мультимедийными средствами, используемыми одним и тем же участником в наборе взаимосвязанных RTP-сессий, cname должно быть зафиксировано для данного участника.
    • Для того чтобы обеспечить независимый мониторинг, Cname должно быть удобным средством идентификации источника как для программы, так и для человека.

    Следовательно, cname должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию следует использовать описанный ниже формат, если другой синтаксис или семантика не задана. Элемент cname должен иметь формат "user@host", или "host", если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов, "host" является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9]; или стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена. Например, стандартное ASCII-представление IP-адреса (версия 4) в "точечно-цифровом" виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно получить. Примерами могут служить "dwarf@sleepy.beauty.com" или "dwarf@192.166.148.9" для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить "sleepy.beauty.com" или "192.166.148.9".

    Имя пользователя должно иметь форму, которая может быть использована в запросах "Finger" или "Talk", т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника.

    Этот синтаксис не обеспечит уникальность имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника, или на профайл, для которого приложение должно будет специфицировать синтаксис идентификаторов cname.

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

    Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10]) может привести к появлению имен дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [11].) Для того чтобы разрешать такие конфликты приложение должно иметь средства для выработки и присвоения уникальных имен cname.

    Name: Имя пользователя (рис. 4.4.9.3.8).

    Рис. 4.4.9.3.8. Формат элемента Name

    Это настоящее имя, используемое для описания источника, напр., "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо cname. Такой приоритет может быть установлен профайлом. Значение name предполагается неизменным, по крайней мере в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.

    Email: Адрес электронной почты (рис. 4.4.9.3.9).

    Рис. 4.4.9.3.9. Формат элемента Email

    Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822 [12], например, "yuri.semenov@itep.ru". Значение элемента Email предполагается неизменным в пределах сессии.

    phone: Телефонный номер

    Рис. 4.4.9.3.10. Формат элемента phone

    Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, , "+7 095 129 9442" для номера в России.

    LOC: Географический адрес пользователя

    Рис. 4.4.9.3.11. Формат элемента LOC

    Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 322, itep bl 180". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.

    TOOL: Имя приложения или программного средства

    Рис. 4.4.9.3.12. Формат элемента TOOL

    Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, напр., "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.

    Note: Уведомление/статус

    Рис. 4.4.9.3.13. Формат элемента Note

    Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент note предназначен для сообщений, характеризующих текущее состояние источника, напр., "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.

    Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме cname), такие как Name, может быть уменьшена с тем, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент note передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако, получатели должны рассматривать элемент Note потерявшим актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.

    PRIV: Элемент частного расширения SDES

    Рис. 4.4.9.3.14. Формат элемента расширения PRIV

    Этот элемент используется, для того чтобы определить экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента, и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным и никакой другой элемент priv не может иметь такое же. Разработчик приложения может выбрать имя приложения плюс, если необходимо, дополнение.

    Заметьте, что префикс занимает некоторое место, из числа 255 октетов элемента, по этой причине желательно, чтобы он был короче.

    Префиксы SDESpriv не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи.

    Bye: Пакет завершения сессии RTCP

    Рис. 4.4.9.3.15. Формат пакета Bye

    Пакет Bye указывает на то, что один или более источников покинули сессию.

    Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов

    Тип пакета (PT): 8 бит

    Содержит код 203, который указывает на то, что это RTCP пакет Bye.

    Число источников (SC): 5 бит

    Число фрагментов SSRC/CSRC, содержащихся в данном bye-пакете. Значение нуль допустимо, но бесполезно.

    Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.

    app: RTCP-пакет, определенный приложением

    Рис. 4.4.9.3.16. Формат пакета, задаваемого приложением

    Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета.

    Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов.

    Субтип: 5 бит

    Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения.

    Тип пакета (PT): 8 бит

    Содержит код 204, который указывает на то, что это RTCP пакет APP.

    Имя: 4 октета

    Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.

    Поле информация, зависящая от приложения имеет переменную длину.

    Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.

    Обработка RTCP в трансляторах

    Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя.

    Транслятор, который не модифицирует информационные пакеты, например такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации, так чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.

    Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.

    Блоки отчетов о приеме SR/RR: Транслятор переадресует доклады о приеме, полученные из одной области сети в другие. Заметим, что эти сообщения движутся в направлении противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет, и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.

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

    SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии. Но они могут, например, решить отфильтровывать некоторую информацию, если этого требуют ограничения пропускной способности. Транслятор, который генерирует свои собственные RR-пакеты, должен посылать SDES CNAME-информацию о самом себе в область сети, куда он шлет эти RR-пакеты.

    BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации.

    APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.

    Обработка RTCP в смесителях

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

    Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток.

    Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.

    SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут отфильтровывать любую SDES-информацию помимо CNAME в случае ограничения полосы пропускания. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. (Идентификатор в списке CSRC, сгенерированный смесителем может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой.) Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.

    Так как смесители не переадресуют SR или RR пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR или RR пакет, посылаемый смесителем.

    Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обоих сетевых областей оказываются независимыми.

    BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.

    APP. Обработка APP-пакетов смесителями зависит от вида приложения.

    Таблица 4.4.9.3.1. Типы пакетов RTCP

    Сокращенное название

    Имя

    Значение

    SR

    sender report - сообщение отправителя

    200

    RR

    receiver report - сообщение получателя

    201

    SDES

    source description - описание источника

    202

    BYE

    goodbye - завершение

    203

    APP

    application-defined - определен приложением

    204

    Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных равному 1 (так как статические типы поля данных обычно лежат в младшей половине).

    Другие константы определены IANA. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет.

    Таблица 4.4.9.3.2. Типы SDES

    Сокращенное название

    Имя

    Значение

    END

    Конец списка SDES

    0

    CNAME

    Каноническое имя

    1

    NAME

    Имя пользователя

    2

    EMAIL

    Электронный адрес пользователя

    3

    PHONE

    Телефонный номер пользователя

    4

    OC

    geographic user location

    5

    TOOL

    Имя приложения или программного средства

    6

    NOTE

    notice about the source

    7

    PRIV

    Частные расширения

    8

    Типы пакетов RTCP. Могут быть определены и зарегистрированы IANA новые, специфические для определенных классов приложений типы пакетов RTCP.

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

    Расширения SR/RR. Секция расширения может быть определена для RTCP SR и RR пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.

    Проверка корректности заголовка RTCP

    Пакеты RTCP подвергаются следующим проверкам.

    • RTP поле версии должно быть равно 2.
    • Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
    • Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP пакета, так как заполнитель может присутствовать только в последнем.
    • Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

    Фрагмент приведенной ниже программы выполняет все рассмотренные проверки (текст взят из ссылки, приведенной в начале раздела). Тип пакета для последующих пакетов не проверяется, так как не известный тип пакета должен игнорироваться.

    u_int32 len; /* Длина составного RTCP пакета в словах */
    rtcp_t *r; /* заголовок RTCP */
    rtcp_t *end; /* Конец составного RTCP пакета */
    if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
    /* что-то не в порядке с форматом пакета */
    }
    end = (rtcp_t *)((u_int32 *)r + len);
    do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
    while (r < end && r->common.version == 2);
    if (r != end) {
    /* что-то не в порядке с форматом пакета */
    }

    Генерирование пакетов SDES RTCP

    Эта функция формирует фрагмент SDES, состоящий из элементов argc, взятых из массивов type, в буфере b.

    char *rtp_write_sdes(char *b, u_int32 src, int argc,
    rtcp_sdes_type_t type[], char *value[],
    int length[])
    {
    rtcp_sdes_t *s = (rtcp_sdes_t *)b;
    rtcp_sdes_item_t *rsp;
    int i;
    int len;
    int pad;
    /* SSRC header */
    s->src = src;
    rsp = &s->item[0];
    /* SDES items */
    for (i = 0; i < argc; i++) {
    rsp->type = type[i];
    len = length[i];
    if (len > RTP_MAX_SDES) {
    /* неверная длина, возможно нужны другие действия */
    len = RTP_MAX_SDES;
    }
    rsp->length = len;
    memcpy(rsp->data, value[i], len);
    rsp = (rtcp_sdes_item_t *)&rsp->data[len];
    }
    /* завершить конечным маркером и заполнителем на очередной 4-октетной границе */
    len = ((char *) rsp) - b;
    pad = 4 - (len & 0x3);
    b = (char *) rsp;
    while (pad--) *b++ = RTCP_SDES_END;
    return b;
    }

    Разбор пакетов RTCP SDES

    Эта функция осуществляет разбор пакета SDES, вызывая функции find_member() для поиска указателя на информацию для члена сессии с идентификатором SSRC и member_sdes() для запоминания новой информации SDES для этого участника. Этой функции необходим указатель на заголовок пакета RTCP.

    void rtp_read_sdes(rtcp_t *r)
    {
    int count = r->common.count;
    rtcp_sdes_t *sd = &r->r.sdes;
    rtcp_sdes_item_t *rsp, *rspn;
    rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
    ((u_int32 *)r + r->common.length + 1);
    source *s;
    while (--count >= 0) {
    rsp = &sd->item[0];
    if (rsp >= end) break;
    s = find_member(sd->src);
    for (; rsp->type; rsp = rspn ) {
    rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
    if (rspn >= end) {
    rsp = rspn;
    break;
    }
    member_sdes(s, rsp->type, rsp->data, rsp->length);
    }
    sd = (rtcp_sdes_t *)
    ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
    }
    if (count >= 0) {
    /* некорректный формат пакета */
    }
    }

    Вычисление периода рассылки RTCP

    Следующая функция в качестве результата выдает время между посылками RTCP-пакетов, измеренное в секундах. Она должна вызываться после посылки одного составного RTCP-пакета для вычисления времени до посылки следующего пакета. Эта функция должна также вызываться для вычисления времени посылки первого RTCP-пакета при запуске. Это исключает любые кластеры RTCP-пакетов, если приложение запущено в нескольких узлах одновременно, например, в результате объявления об открытии сессии.

    Параметры имеют следующий смысл:

    rtcp_bw: Предельная полоса RTCP, т.е., полная пропускная способность, которая будет использоваться для RTCP-пакетов всеми участниками сессии, выраженная в октетах в секунду. Она должна быть порядка 5% от "полосы сессии", этот параметр задается при конфигурировании приложения.

    senders: Число активных отправителей на момент посылки последнего отчета, известно из конструкции отчетов получателя.

    members: Оценка числа членов сессии, включая нас самих. Инкрементируется, когда мы обнаруживаем новых членов сессии при получении RTP или RTCP-пакетов, и декрементируется, когда какой-либо участник покидает сессию (послав RTCP BYE) или он объявлен таковым по тайм-ауту (рекомендуемое время 30 минут). При первом вызове этот параметр должен иметь значение 1.

    we_sent: Флаг, который равен true, если мы послали данные за время последних двух интервалов RTCP. Если флаг равен true, составной только что посланный пакет RTCP содержит SR пакет.

    packet_size: Размер составного только что посланного пакета RTCP, в октетах, включая сетевую инкапсуляцию (напр., 28 октетов для UDP поверх IP).

    avg_rtcp_size: Указатель оценщика размера составных пакетов RTCP; инициализируется и актуализуется для только что посланного пакета этой функцией, актуализуется также идентичной строкой программы приема пакетов RTCP для каждого пакета RTCP, полученного от другого участника сессии.

    initial: Флаг, который равен true для первого вызова при инициализации с целью вычисления момента посылки первого отчета.

    #include
    double rtcp_interval(int members,
    int senders,
    double rtcp_bw,
    int we_sent,
    int packet_size,
    int *avg_rtcp_size,
    int initial)
    {
    /*
    * Минимальное время между пакетами RTCP от данного узла (в секундах). Это время
    * предотвращает группирование отчетов, когда в сессии участвует малое число
    * участников. Это препятствует чрезмерному уменьшению интервалов межу отчетами.
    */
    double const RTCP_MIN_TIME = 5.;
    /*
    * Доля полосы RTCP, которая должна быть поделена между активными участниками.
    * (Эта доля была выбрана так, чтобы в типовой сессии с одним или двумя
    * активными отправителями, вычисленный период посылки отчетов был примерно
    * равен минимальному интервалу между отчетами. Доля получателя должна равняться
    * 1 - доля отправителя.
    */
    double const RTCP_SENDER_BW_FRACTION = 0.25;
    double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
    /*
    * Коэффициент преобразования (сглаживающая константа) для полосового
    * фильтра, который используется при оценке среднего размера RTCP пакетов.
    */
    double const RTCP_SIZE_GAIN = (1./16.);
    double t; /* интервал */
    double rtcp_min_time = RTCP_MIN_TIME;
    int n; /* число участников, используемое при вычислении */
    /*
    * Самый первый вызов приложения использует вдвое меньшую
    * минимальную задержку для ускорения оповещения, в то же время оставляя
    * некоторое время до отчета для рэндомизации и получения информации
    * о других источниках. Таким образом, установление корректного периода
    * отчетов произойдет быстрее. Средний размер RTCP пакета
    * устанавливается в начальный момент равным 128 октетам
    * (предполагается, что все остальные генерируют SR вместо RR:
    * 20 IP + 8 UDP + 52 SR + 48 SDES CNAME октетов).
    */


    if (initial) {
    rtcp_min_time /= 2;
    *avg_rtcp_size = 128;
    }
    /*
    * Если имелись активные отправители, надо им дать
    * по крайней мере минимальную долю полосы RTCP.
    * В противном случае все участники будут делить полосу RTCP поровну
    */
    n = members;
    if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {
    if (we_sent) {
    rtcp_bw *= RTCP_SENDER_BW_FRACTION;
    n = senders;
    } else {
    rtcp_bw *= RTCP_RCVR_BW_FRACTION;
    n -= senders;
    }
    }
    /*
    * Актуализация оценки среднего размера пакета отчета с учетом
    * только что посланного пакета.
    */
    *avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;

    /*
    * Эффективное число узлов, умножаем на средний размер пакета отчета
    * и получаем полное число посланных октетов, если каждый из узлов
    * посылает отчет. Деля это число на эффективную полосу,
    * получаем средний временной интервал посылки пакетов-отчетов.
    */

    t = (*avg_rtcp_size) * n / rtcp_bw;
    if (t < rtcp_min_time) t = rtcp_min_time;

    /*
    * Для того чтобы избежать всплесков трафика из-за непреднамеренной
    * синхронизации с другими узлами мы выбираем следующий интервал
    * отчета равным случайному числу с равномерным распределением в
    * диапазоне 0.5*t - 1.5*t.
    */
    return t * (drand48() + 0.5);
    }

    Библиография

    [1]

    I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996.

    [2]

    S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [24]

    [3]

    J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987

    [4]

    International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993

    [5]

    The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991

    [6]

    Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987

    [7]

    Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987

    [8]

    Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989

    [9]

    Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994

    [10]

    Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994

    [11]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982

    [12]

    W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968

    Previous: 4.4.9.2 Протокол реального времени RTP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP


    previous up down next index index
    Previous: 4.4.9.3 Транспортный протокол реального времени RTCP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.5 Протокол PIM

    4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    DVMRP - (Distance Vector Multicast Routing Protocol) мультикастинг-протокол, где в качестве метрики применен вектор расстояния (см. также описание RIP, RFC-1058). DVMRP использует идеологию документа RFC-1054, а также алгоритм TRPB (Truncated Reverse Path Broadcasting). При получении первого пакета маршрутизатор не имеет информации о группе. Он посылает полученный пакет через все интерфейсы, кроме того, через который этот пакет получен. Если пакет пришел не через интерфейс, который используется маршрутизатором для посылки пакетов отправителю мультикаст-информации, полученный пакет выбрасывается. При получении пакета маршрутизатором, в зоне ответственности которого нет членов группы, он посылает сообщение об исключении (prun-команда). Эти сообщения используются для отсечения от дерева маршрутов веток, не содержащих членов группы. По истечении определенного времени "отрезанные" ветки дерева маршрутов "отрастают" вновь и снова могут быть отсечены (протокол TRPB). В настоящее время этот протокол рассматривается в качестве экспериментального и его широкое применение не рекомендуется. DVMRP относится к внутренним протоколам маршрутизации, пригодным для использования в пределах автономной системы.

    Протокол DVMRP используется для построения дерева мультикасинг-маршрутов. Предполагается, что в дальнейшем принцип "вектора расстояния" может быть заменен алгоритмом "состояния канала" (MOSPF аналог OSPF). Целью протокола DVMRP является описание обратного пути к источнику мультикастинг-дейтограмм. Протоколы состояния канала предполагают широковещательную рассылку информации о членстве в группе. При получении мультикаст-пакета маршрутизатор определяет дерево кратчайших маршрутов.

    DVMRP-дейтограмма состоит из небольшого заголовка фиксированного размера и длинного списка записей. Заголовок DVMRP-сообщений имеет формат IGMP (рис. 4.4.9.4.1):

    Рис. 4.4.9.4.1 Формат заголовка DVMRP-сообщений

    Поле версия равно 1. Поле тип содержит всегда код 3. А поле субтип может принимать значения:

    1 = Отклик; сообщение о маршрутах до некоторого (-ых) мест(а) назначения.
    2 = Запрос; поиск маршрутов до определенного места назначения;
    3 = Сообщение о выходе из членов группы;
    4 = Отмена заявки о выходе из группы.

    Контрольная сумма вычисляется также как и в других IP-протоколах. Отдельные записи в указанном списке выполняют роль команд и их размер должен быть кратен 16 бит (их границы соответствующим образом выравниваются). Максимальная длина DVMRP-сообщения, включая заголовок, не может превышать 512 байт.

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

    Таблица 4.4.9.4.1. Значения TTL для различных приложений

    Вид мультикастинг-туннеля

    TTL

    Порог

    IETF канал 1 GSM-аудио (~18кб/с)

    255

    224

    IETF канал 2 GSM-аудио

    223

    192

    IETF канал 1 видео

    127

    96

    IETF канал 2 видео

    95

    64

    Местное аудио

    63

    32

    Местное видео

    31

    1

    Мультикастинг-дейтограмма с исходным TTL=64 доступна для достаточно обширной области, а мультикастинг-дейтограмма с исходным TTL=128 доступна для целого континента, дейтограмма же с исходным TTL=255 дойдет до любой точки сети Интернет. Понятия "узкий регион" и "обширная область" достаточно неопределенные и будут уточняться позднее.

    Маршрутные сообщения, посылаемые конкретному физическому интерфейсу, также как и запросы подтверждения членства в мультикастинг-группе должны иметь TTL=1. Цикл обмена маршрутной информацией между мультикастинг- маршрутизаторами (FULL_UPDATE_RATE) равен 60 сек. Подтверждение членства в группе должно посылаться каждые 120 сек (QUERY_RATE). Если подтверждение не получено в течение 2*QUERY_RATE+20 секунд, то членство в данной группе аннулируется. Соседний мультикастинг-маршрутизатор считается работающим при отсутствии подтверждений (UPDATE-сообщений) в течение 4*FULL_UPDATE_RATE.

    Описанные выше протоколы DVMRP и MOSPF имеют общий недостаток - широко используют широковещательные режимы рассылки пакетов и требуют каналов с высокой пропускной способностью. Они удобны для компактных групп (например, все члены группа находятся в пределах одной автономной системы). Для обслуживания более широких групп предложен протокол PIM.

    Previous: 4.4.9.3 Транспортный протокол реального времени RTCP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.5 Протокол PIM


    previous up down next index index
    Previous: 4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.6 Протокол резервирования ресурсов RSVP

    4.4.9.5 Протокол PIM
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол PIM (Protocol Independent Multicast) призван решить проблемы маршрутизации для произвольного числа и расположения членов группы и для произвольного числа отправителей информации. В настоящее время протокол не является стандартом.

    Главным преимуществом данного протокола является эффективная поддержка работы "рассеянных" мультикастинг-групп. Такие группы могут включать не только членов из разных автономных систем, но и находящихся на разных континентах. Протоколы MOSPF и DVMRP хороши для сетей, где нет ограничений по пропускной способности каналов.

    PIM базируется на традиционных маршрутных протоколах, конкретно не связан ни с каким из них, им используются сформированные этими протоколами маршрутные таблицы. Существует два режима работы протокола - DM (для компактных групп) и SM (Protocol Independent Multicast-Sparse Mode (PIM-SM)). Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, RFC-2117, June 1997) (для рассеянных групп). В режиме DM протокол PIM строит дерево маршрутов аналогично DVMRP.

    В режиме SM маршрутизаторы, имеющие членов мультикастинг-группы, посылают сообщения о присоединении к дереву рассылки в узлы, которые называются точками встречи (RP). Отправители используют RP для объявления о своем существовании, а получатели, чтобы узнать о новых отправителях. В качестве RP может использоваться любой маршрутизатор, поддерживающий протокол PIM.

    Когда какой-то клиент хочет подключиться к некоторой группе, ближайший к нему маршрутизатор посылает специальное сообщение о включении в группу (PIM-joint) узлу, объявленному для данной группы точкой встречи (RP). Число RP в сети может быть произвольным. Узел RP пересылает сообщение о включении узлу-отправителю (или отправителям). Если маршрутизатор не имеет информации о RP, включается схема, работающая для компактных групп. При обработке сообщения о включении в группу промежуточные маршрутизаторы формируют часть дерева мультикастинг-маршрутов между RP и получателем. При отправке мультикастинг-пакета соответствующий маршрутизатор посылает узлу RP регистрационное сообщение (PIM-register), куда вкладывается информационный пакет. Если используется несколько RP, отправитель должен посылать пакеты всем RP. Получатель же должен быть подключен лишь к одному из RP. В случае, когда сообщение о включении достигнет отправителя раньше, чем RP, подключение осуществляется, минуя RP. Если необходимо оптимизировать дерево доставки пакетов, маршрутизаторы-получатели должны послать сообщение о включении самому отправителю. После этого дерево соединений видоизменяется, некоторыми узлами, если требуется, посылается сообщение об отключении. Ниже приведен пример взаимодействия узлов при формировании дерева маршрутов в режиме SM-PIM (рис. 4.4.9.5.1).

    Следует заметить, что большинство протоколов для маршрутизации мультимедийной информации формируют маршрут не от отправителя к получателю, а в обратном направлении. Это имеет под собой веские причины. Дерево рассылки должно быть построено так, чтобы поток отправителя как можно дольше и меньше разветвлялся. Желательно, чтобы разветвления происходили как можно ближе к получателю. Это соображение проиллюстрировано на рис. 4.4.9.5.2. На рисунке условно, в виде сетки маршрутизаторов (желтые кружочки) показан фрагмент сети Интернет. Зеленым прямоугольником отмечен передатчик, а голубыми кружочками приемники - члены группы. Маршруты от передатчика к приемникам можно проложить индивидуально (выделены зеленым цветом), а можно и "коллективно" (синий цвет). От передатчика до маршрутизатора отмеченного красным цветом следует один поток для всех приемников. Такое решение приводит к минимизации сетевой загрузки, ведь всем приемникам посылаются одни и те же пакеты. Чем позже их пути разойдутся, тем лучше. Именно этот алгоритм и реализует протокол PIM. Точки разветвления потоков на рис. 4.4.9.5.2 отмечены крестами (RP).

    Рис. 4.4.9.5.1. Иллюстрация реализации протокола мультикастинг маршрутизации PIM

    Получатель посылает PIM-joint пакет в RP, устанавливая канал от RP до получателя. Из рисунка видно, что исходный маршрут d-c-b-a длиннее оптимального d-b-a. Последний может быть реализован после посылки PIM-joint команды от a к d.

    При решении транспортных задач в мультимедиа чаще используется протокол UDP (малая избыточность и отсутствие подтверждений).

    Рис. 4.4.9.5.2.

    Ниже приводится более подробное, хотя и неполное описание протокола pim.

    Используемые сокращения и термины

    Assert

    Сообщения assert используются для принятия решения, какой из параллельных маршрутизаторов, подключенных к локальной сети с множественным доступом, должен быть ответственным за ретрансляцию пакетов в LAN.

    bootstrap

    Сообщения, посылаемые от узла к узлу в пределах домена. Все маршрутизаторы воспринимают эти сообщения для получения RP-информации. За рассылку сообщений в пределах домена bootstrap ответственен маршрутизатор BSR.

    BSR

    bootstrap router - маршрутизатор, ответственный за рассылку сообщений bootstrap

    C-RP

    candidate RP - кандидат в маршрутизаторы RP

    DR

    designated router - специально выделенный маршрутизатор для рассылки мультикастинг данных.

    (*,g)

    wild card мультикастная запись для группы g

    Graft

    Сообщение, используемое в режиме PIM для компактных групп.

    Hello

    Соседние маршрутизаторы шлют друг другу сообщения hello. Маршрутизатор с наибольшим IP-адресом выбирается в качестве dr.

    IGMP

    internet group management protocol - протокол управления группами

    IIF

    input interface - входной интерфейс

    Join

    Подключение к дереву маршрутов

    MBR

    Пограничный мультикастинг маршрутизатор

    OIF

    output interface - выходной интерфейс

    PMBR

    PIM multicast border router

    Prune

    Отключение от дерева маршрутов

    Register

    Когда источник отправляет данные группе в первый раз, его DR посылает уникастные сообщения register, в которые вкладывает информационные пакеты.

    RP

    rendezvous point - маршрутизатор разветвления маршрута для потока данных

    (*,*,rp)

    cпециальный тип маршрутных записей для поддержки совместной работы DVMRP и PIM. Запись (*,*,rp) представляет собой объединение всех групп, которые работают через данную RP.

    RPF

    reverse path forwarding - переадресация по пути возврата

    RPT

    RP-tree - дерево точек встречи

    (s,g)

    Маршрутная запись, характеризующее состояние системы группа-отправитель (source-group)

    SPT

    shortest pass tree - дерево кратчайших маршрутов

    SP

    shortest pass - кратчайший путь (обозначение фрагмента дерева маршрутов)

    WC

    wild card

    Целью протокола PIM является построение дерева маршрутов для рассылки мультикастных сообщений.

    Маршрутизатор получает сообщения join/prune от соседних маршрутизаторов, которые обслуживают группы пользователей. Он переадресует информационные пакеты, адресованные группе G, только через те интерфейсы, через которые ранее было получено сообщение join.

    Специальный маршрутизатор DR (designated router) рассылает периодически сообщения join/prune в точки встречи (RP) для каждой группы, в которой имеются активные участники. Для описания дерева маршрута используются маршрутные записи, содержащие адрес отправителя, групповой адрес, номер входного интерфейса, через который принимаются пакеты, список интерфейсов, через которые осуществляется рассылка, таймеры, флаги и пр. Выходные интерфейсы указывают на соседние маршрутизаторы, через которые пролегает путь к RP. В центре этого маршрутного дерева, включающего в себя всех членов группы, находится RP. Когда источник информации посылает что-то группе в первый раз, его DR отправляет уникастное сообщение register в RP.

    Для того чтобы присоединиться к мультикатинг-группе G, ЭВМ передает IGMP-сообщение (или ICMP в случае IPv6). При этом предполагается, что ЭВМ будет выполнять функции получателя (R).

    Когда DR получает уведомление о членстве новой группы от IGMP G, он просматривает соответствующие RP. DR формирует запись мультикастинг-маршрута для группы (*,g) [wild card мультикастная запись для группы G, определяющая ее состояние]. Адрес RP включается в специальное поле маршрутной записи, содержащейся в периодически рассылаемых сообщениях join/prune (см. рис. 4.4.9.5.9). При этом в список выходных интерфейсов включается тот, к которому подключен новый член группы, а в качестве входного интерфейса указывается тот, через который посылаются уникастные пакеты к RP.

    Когда не остается ни одного непосредственно подключенного члена группы, протокол IGMP уведомляет об этом DR. Если DR не имеет ни локальных, ни удаленных получателей, запись (*,g) ликвидируется.

    Запись (*,g), инициирует формирование DR сообщения join/prune с RP-адресом в его join-списке и установленными битами WC и RPT. Равенство WC=1 говорит о том, что согласно этой записи будут пересылаться пакеты любого отправителя. Список удаления (prune) остается пустым. Когда бит RPT=1, это указывает на то, что подключение осуществлено через общее RP-дерево и, следовательно, сообщение join/prune будет идти по этому RP-дереву. Когда бит WC= 1, это означает, что адрес принадлежит RP, а получатели предполагают получать пакеты от всех отправителей.

    Каждый маршрутизатор, расположенный по пути к отправителю, создает и отслеживает изменения маршрутной записи для (*,g), когда он получает сообщения join/prune с RPT=WC=1. Интерфейс, через который получено сообщение join/prune, добавляется к списку выходных интерфейсов (OIF) для (*,g). На основе этой записи каждый маршрутизатор по пути между получателем и RP посылает сообщение join/prune, в котором RP включен в список join. Поле данных этого пакета содержит мультикаст-адрес=G, join=RP, wc-бит, RPT-бит, prune=null.

    Когда ЭВМ начинает посылать мультикастинг-пакеты группе, сначала DR должен доставить их в RP для последующей раздачи по дереву RP. DR отправителя в начале инкапсулирует каждый информационный пакет в сообщение register (см. рис. 4.4.9.5.7) и отправляет его по уникастному адресу RP данной группы. RP извлекает каждое сообщение register и переадресует вложенные информационные пакеты вдоль RP-дерева.

    Если поток данных позволяет использовать дерево кратчайшего пути до отправителя (SPT), RP может сформировать новую маршрутную запись для дерева мультикаст-маршрута, специфичного для данного отправителя (SP-дерево).

    DR отправителя прекратит инкапсуляцию информация в пакеты registers, когда он получит сообщение register-stop от RP. RP отравляет сообщения register-stop в качестве отклика на сообщение registers, если RP не имеет более активных членов группы.

    Новый приемник может подключиться к существующему RP-дереву, для которого установлено обрезание (prune state) (например, из-за того, что другие получатели переключились на SP-деревья). В этом случае состояние обрезания аннулируется с тем, чтобы обеспечить доставку данных новому получателю.

    В стабильном состоянии каждый маршрутизатор периодически посылает сообщения join/prune для каждой маршрутной записи PIM. Сообщения join/prune посылаются соседу, указанному в соответствующей записи. Такие сообщения позволяют отследить изменения состояния системы и топологию членства в группе.

    Для того чтобы получить информацию о RP, все маршрутизаторы в пределах PIM-домена собирают сообщения bootstrap. Сообщения bootstrap пересылаются от узла к узлу в пределах домена. За организацию рассылки этих сообщений несет ответственность специальный маршрутизатор BSR (bootstrap router). Сообщения bootstrap используются для выполнения динамического выбора BSR, когда это необходимо, а также для получения информации об RP. Домен в этом контексте представляет собой набор смежных маршрутизаторов, поддерживающих PIM, и сконфигурированных для совместной работы в рамках границ, определенных пограничными маршрутизаторами PMBR (PIM multicast border router), соединяющими PIM-домен с остальным Интернет.

    Маршрутизаторы используют набор доступных RP (называемый {RP-set}), для того чтобы осуществить связь отдельных групп с соответствующими RP. Некоторое число маршрутизаторов в домене конфигурируется как кандидаты для выполнения функций BSR. Для назначения BSR в домене существуют простые правила выбора. Часть маршрутизаторов в домене конфигурируются также как кандидаты для работы в качестве RP (C-RP); как правило, это те же маршрутизаторы, что и кандидаты в BSR. Кандидат в RP периодически посылает BSR домена уникастное сообщение candidate-rp-advertisement (C-RP-ADVS). C-RP-ADVS включает в себя адрес C-RP, а также опционный групповой адрес и поле длины маски. BSR включает набор этих кандидатов в RP (набор RP), вместе с соответствующим групповым префиксом периодически рассылаемых сообщений.

    Маршрутизаторы получают и запоминают содержимое сообщений bootstrap. Когда DR получает указание о членстве в группе от IGMP, DR использует хэш-функцию для установления соответствия между групповым адресом и одним из C-RP, чей префикс включает в себя данную группу. Для конкретной группы G, хэш-функция использует только те C-RP, чьи групповые префиксы покрывают G. Когда соответствие установлено, DR посылает сообщение join/prune (или уникастный пакет register) соответствующему rp.

    Сообщения bootstrap информирует о работоспособности точек встречи (rp), обслуживающих сессию. Если RP включен в сообщение, он считается рабочим, в то время как отсутствие rp в сообщении, приводит к удалению его из списка, с которым работает алгоритм. Каждый маршрутизатор продолжает использовать содержимое, полученное в последнем сообщении bootstrap, пока не будет получено новое сообщение bootstrap.

    Если зона PIM-домена теряют доступ к старому BSR, они выберут новый BSR, который разошлет RP-набор, содержащий RP, доступные в пределах данной зоны. Любая область в любой заданный момент времени обслуживается только одним BSR, который и осуществляет посылку сообщений bootstrap.

    Для того чтобы обеспечить совместимость с сетями, работающими в режиме DM, с протоколами типа DVMRP, все пакеты, генерируемые в области PIM-SM, должны быть переправлены мультикастным пограничным маршрутизаторам области PMBR (multicast border router) и переадресованы в сеть DVMRP. Маршрутизатор PMBR размещается на границе домена PIM-SM и взаимодействует с другими типами мультикаст-маршрутизаторов, например, такими, которые поддерживают протокол DVMRP. Таким образом, PMBR должен поддерживать оба протокола. Для поддержки совместной работы все маршрутизаторы должны поддерживать специальный тип маршрутных записей, обозначаемых (*,*,rp).

    Информационные пакеты, соответствуют записи (*,*,rp), если нет никаких других записи, например, (s,g) или (*,g), групповой адрес места назначения пакета согласуется с RP, указанным в записи (*,*,rp). В этом смысле запись (*,*,rp) представляет собой объединение всех групп, которые работают через данную точку встречи RP. PMBR инициализируют состояние (*,*,rp) для каждой RP в каждом доменном наборе RP. Состояние (*,*,rp) заставляет pmbr посылать сообщения (*,*,rp) join/prune каждой активной RP в домене. В результате деревья рассылки строятся так, что передают все пакеты, возникающие в пределах PIM-домена (и ретранслируются в точки встречи) в направлении пограничных маршрутизаторов PMBR.

    PMBR осуществляют также доставку внешних пакетов маршрутизаторам в пределах PIM-домена. Для решения этой задачи эти маршрутизаторы инкапсулируют внешние пакеты, полученные через интерфейсы DVMRP, в сообщения register, после чего уникастным образом переадресуют их в точку встречи RP PIM-домена. Сообщение register имеет бит, указывающий на то, что пакет сформирован пограничным маршрутизатором.

    Информационные пакеты обрабатываются также как и при других мультикаст-схемах. Маршрутизатор сначала проверяет адреса отправителя и группы. Затем определяется адрес RP, если непосредственная передача невозможна. Если пути доставки не существует, пакет выбрасывается. При наличии пути выясняется интерфейс, через который должна производиться передача, и пакет переадресуется.

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

    Когда имеется несколько маршрутизаторов, соединенных с сетью, имеющей много каналов доступа, один из них должен быть выбран в качестве ретранслятора (DR; обычно это маршрутизатор с наибольшим IP-адресом). Это справедливо для любой точки сети в любое время. Процедуре выбора предшествует обмен сообщениями Hello.

    При наличии параллельных проходов к источнику или RP для выбора маршрута применяются сообщения assert. Используя сообщения assert, адресованные `224.0.0.13' (группа all-pim-routers) в локальной сети, вышестоящий маршрутизатор может узнать, где осуществляется переадресация сообщений. Нижестоящие маршрутизаторы, получая сообщения assert, узнают, какой маршрутизатор выбран в качестве ретранслятора, и куда следует посылать сообщение join. Обычно это тот же нижележащий маршрутизатор-сосед (reverse path forwarding), но иногда это может быть и не так, например, когда в локальной сети используется несколько протоколов маршрутизации. RPF-сосед для конкретного отправителя или RP является следующим маршрутизатором, которому переправляются пакеты по пути к отправителю или RP. По этой причине он может рассматриваться как хорошая промежуточная инстанция для пересылки пакетов отправителем.

    Когда приходит пакет в выходной интерфейс, маршрутизатор посылает сообщение assert в локальную сеть с множественным доступом, указывая, какую метрику он использует для достижения отправителя информационных пакетов. Маршрутизатор с наименьшим значением метрики и станет базовым ретранслятором. Все прочие вышестоящие маршрутизаторы вычеркнут этот интерфейс из своего списка выходных интерфейсов. Нижестоящие маршрутизаторы также производят сравнение, если ретранслятором не является RPF-сосед.

    С понятием метрики связано и значение предпочтения метрики. Оно введено, чтобы решать проблемы в случае, когда вышестоящие маршрутизаторы использует другие уникастные протоколы маршрутизации. Численно меньшее значение предпочтения соответствует более высокому приоритету. Значение предпочтения рассматривается в качестве старшей части метрики при сравнении, которое осуществляется при обработке сообщений assert. Предпочтение может быть присвоено уникастному протоколу маршрутизации и должно быть взаимосогласованным для всех маршрутизаторов локальной сети с множественным доступом.

    Сообщения assert нужны для маршрутных записей (*,g), так как деревья RP и SP для некоторых групп могут возникать зоны перекрытия в сетях с множественным доступом. Когда assert посылается для записи (*,g), RPT-бит устанавливается равным 1. Первый бит поля предпочтения всегда устанавливается равным 1, для того чтобы отметить, что проход соответствует RP-дереву. RPT-бит всегда обнуляется для предпочтения, которое относится к записям SP-деревьев. Это приводит к тому, что проход через SP-дерево выглядит всегда редпочтительнее, чем проход через RP-дерево. Когда деревья SP и RP перекрываются для какой-то LAN, этот механизм устраняет дублирование для данной сети.

    DR может уступить процесс (*,g) assert другому маршрутизатору LAN, если существует несколько проходов к rp через lan. В этом случае DR не является более "ближайшим" маршрутизатором для местных получателей и он удаляет LAN из своего (*,g) списка выходных интерфейсов. Маршрутизатор-победитель становится "ближайшим" и ответственным за рассылку сообщений (*,g) join для RP.

    Подавление join/prune может использоваться в локальных сетях с множественным доступом, для того чтобы сократить число дублирующих управляющих сообщений. Для нормальной работы протокола этого не требуется. Если получено сообщение join/prune, которое соответствует существующим маршрутным записям (s,g), (*,g) или (*,*,rp) для данного входного интерфейса, а поле holdtime сообщения join/prune больше, чем join/prune-holdtime получателя, может быть запущен таймер (join/prune-suppression-таймер) маршрутной записи получателя с тем, чтобы заблокировать последующие сообщения join/prune. После завершения работы таймера получатель отправляет сообщение join/prune, и возобновляет периодическую посылку join/prune, для данной записи. Таймер join/prune-suppression должен перезапускаться каждый раз, когда приходит сообщение join/prune с большим значением holdtime.

    Когда уникастная маршрутизация претерпевает изменения, RPF производит проверку активных маршрутных записей (s,g), (*,g) и (*,*,rp) и вносит необходимые поправки. В частности, если в списке выходных интерфейсов появляется новый принимающий интерфейс, то он удаляется из этого списка. Предшествующий входной интерфейс может быть добавлен в список выходных интерфейсов с помощью последующих сообщений join/prune, поступающих от нижестоящих узлов. Сообщения join/prune, полученные текущим входным интерфейсом, игнорируются, а сообщения, полученные новыми или существующими выходными интерфейсами, обрабатываются. Остальные выходные интерфейсы останутся в прежнем состоянии до тех пор, пока не будут отключены нижележащими маршрутизаторами или по таймауту из-за отсутствия соответствующих сообщений join/prune. Если маршрутизатор имеет запись (s,g) с установленным битом spt, а обновленная запись IIF(s,g) не отличается от IIF(*,g) или IIF(*,*,rp), тогда маршрутизатор переводит бит SPT в нулевое состояние.

    Соседи-маршрутизаторы, поддерживающие протокол pim, периодически обмениваются сообщениями Hello (см. рис. 4.4.9.5.6). Сообщения Hello могут также рассылаться мультикастным образом с использованием адреса 224.0.0.13 (группа all-pim-routers). Пакет содержит значение holdtime (время сохранения информации).

    Когда маршрутизатор получает сообщение hello, он запоминает IP-адрес соседа, устанавливает таймер отправки на время, соответствующее holdtime, заключенное в Hello, и определяет выделенный маршрутизатор (DR) для данного интерфейса. В качестве DR выбирается объект с наибольшим Ip.

    Когда маршрутизатор, который является активным DR, получает Hello от нового соседа (например, от IP-адреса, которого нет в таблице DR), DR уникастным образом передает RP-информацию новому соседу.

    PIM-соседи, от которых в течение определенного времени не поступало сообщений Hello, считаются отключившимися. Если DR отключился, выбирается новый DR из числа соседей с наибольшим IP-адресом.

    Сообщения join/prune служат, для того чтобы подключить или удалить ветвь мультикастинг-дерева рассылки. Сообщение содержит как join-, так и prune-списки, любой из них может иметь нулевую длину. Эти сообщения содержат все подключенные и отсоединенные источники данных, достижимые через данный узел адресат сообщения. Период отправки сообщений join/prune определяется значением [join/prune-period].

    Маршрутизатор периодически посылает сообщения join/prune каждому конкретному RPF-соседу, соответствующему каждой маршрутной записи (s,g), (*,g) и (*,*,rp). Сообщения join/prune посылаются только тогда, когда RPF-сосед является PIM-соседом.

    Кроме периодически рассылаемых сообщений некоторые из join/prune пакетов могут генерироваться как следствие следующих событий:

    1. создана новая маршрутная запись или
    2. список выходных интерфейсов изменился из нулевого в ненулевое состояние или наоборот.

    Может так случиться, что размер сообщения join/prune превысит MTU сети. В этом случае сообщение может быть фрагментировано, информация, относящаяся к различным группам, будет послана в разных пакетах. Однако, если сообщение join/prune должно быть фрагментировано, полный prune-список, соответствующий группе G, должен быть включен в одно сообщение join/prune согласно RP-дереву join для G. Если такая семантическая фрагментация невозможна, при транспортировке пакетов от соседа к соседу должна использоваться IP-фрагментация.

    Для любой новой записи (s,g), (*,g) или (*,*,rp), сформированной входящим сообщение join/prune, бит SPT сбрасывается.

    Если запись имеет таймер join/prune-suppression, полученное сообщение join/prune не указывает на маршрутизатор в качестве места назначения, тогда принимающий маршрутизатор рассматривает join- и prune-списки, с тем чтобы выяснить, нет ли там адресов полностью соответствующих существующим состояниям (s,g), (*,g) или (*,*,rp), для которых принимающий маршрутизатор осуществляет рассылку сообщений join/prune. Элемент join- или prune-списка полностью соответствует маршрутной записи, только тогда, когда их IP-адреса и RPT-флаги тождественны. Если приходящее сообщение join/prune полностью соответствует существующим записям (s,g), (*,g) или (*,*,rp), а сообщение join/prune приходит на входной интерфейс для данной записи, маршрутизатор сравнивает holdtime сообщения со своим собственным значением join/prune-holdtime. Если его значение join/prune-holdtime меньше, запускается таймер join/prune-suppression. Если join/prune-holdtime равно holdtime сообщения, коллизия разрешается в пользу отправителя сообщения join/prune, который имеет больший ip-адрес. Когда время join/prune таймера истекает, маршрутизатор отправляет сообщение join/prune для соответствующей маршрутной записи.

    Когда отправитель начинает отправку данных группе, его пакеты инкапсулируются в сообщения register и посылаются в RP. Если скорость передачи гарантируется каналом, RP устанавливает соответствующее состояние для отправителя и начинает посылать сообщения (s,g) join/prune отправителю с S в join-списке.

    Когда DR получает сообщение register-stop, он перезапускает таймер register-suppression в соответствующей записи (s,g) на register-suppression-timeout секунд. Если имеются данные, которые должны быть зарегистрированы, DR может послать RP сообщение register нулевой длины, за probe-time секунд до истечения времени таймера register- suppression.

    Сообщения assert используются для принятия решения, какой из параллельных маршрутизаторов, подключенных к локальной сети с множественным доступом, должен быть ответственным за ретрансляцию пакетов в LAN.

    Все управляющие сообщения PIM имеют номер протокола 103. Сообщения PIM являются либо уникастными (например, registers и register-stop), либо мультикастными для группы `all-pim-routers' `224.0.0.13' (например, join/prune, asserts, и т.д.). Формат заголовка пакета протокола PIM показан на рис. 4.4.9.5.3.

    Рис. 4.4.9.5.3. Формат заголовка сообщения PIM

    Поле OIM VER - версия протокола (в настоящее время = 2). Поле тип характеризует PIM-сообщение. Возможные значения поля тип представлены в таблице 4.4.9.5.1.

    Таблица 4.4.9.5.1. Коды типа сообщений

    Код поля тип

    Тип сообщения pim

    0

    hello

    1

    register

    2

    register-stop

    3

    join/prune

    4

    bootstrap

    5

    assert

    6

    graft (используется только в pim-dm)

    7

    graft-ack (используется только в pim-dm)

    8

    candidate-rp-advertisement

    Поле длина адреса характеризует длину кода адреса в байтах. Поле контрольная сумма вычисляется методом суммирования всего pim-сообщения по модулю 1, это поле имеет длину 16 бит. Формат закодированного группового адреса показан на рис. 4.4.9.5.4.

    Рис. 4.4.9.5.4. Формат закодированного группового адреса

    Поле длина маски имеет 8 бит. Значение поля определяет число последовательных бит, выровненных по левому краю, которые определяют адрес. Маска равна или меньше длины адреса * 8 (то есть 32 бита для IPv4 и 128 для IPv6). Поле групповой мультикаст адрес содержит адрес группы и имеет число байт, равное указанному в поле длина адреса. Формат кодированного адреса отправителя показан на рис. 4.4.9.5.5.

    Рис. 4.4.9.5.5. Формат кодированного адреса отправителя

    Поле бит s (бит рассеянности) содержит 1 для PIM-SM. Этот бит используется для обеспечения совместимости с PIM v.1.

    Поле бит W (бит WC). Бит WC =1, если подключение (join) или удаление (prune) используются для маршрутной записи (*,g) или (*,*,rp). Если wc=0, join или prune используются для маршрутной записи (s,g), где s - адрес отправителя. Сообщения join и prune, посылаемые в RP, должны иметь этот бит равным 1.

    Поле бит R (бит RPT). Бит RPT=1, если информация о (s,g) послана в RP. Если RPT=0, информация должна быть послана S, где S - адрес отправителя.

    Поле длина маски имеет длину 8 бит. Значение этого поля охарактеризовано выше в комментарии к рисунку 4.4.9.5.4.

    Поле адрес отправителя имеет длину, определяемую полем заголовка длина адреса. Для IPv4, она равна 4 октетам. Формат сообщения Hello показан на рис. 4.4.9.5.6.

    Первые два байта представляют собой заголовок PIM-сообщения. Поле optiontype определяет тип опции, значение которой задано в поле optionvalue. Поле optionlength задает длину поля optionvalue в байтах. Поле optionvalue имеет переменную длину и содержит значение опции. Поле опция может содержать следующие значения:

    Рис. 4.4.9.5.6. Формат сообщения Hello

    optiontype = 1; optionlength = 2; optionvalue = holdtime; где holdtime равно времени в секундах, в течение которого получатель должен сохранять доступность к соседу. Если holdtime установлено равным `0xFFFF', получатель этого сообщения никогда не прервет соединение с соседом по таймауту. Это может использоваться для каналов ISDN, для того чтобы избежать поддержания канала путем периодической посылки сообщений Hello. Более того, если holdtime= 0, информация объявляется устаревшей немедленно. Диапазон значений optiontype 2 - 16 зарезервирован на будущее. Сообщение register посылается DR или PMBR в RP, когда необходимо передать мультикаст-пакет по rp-дереву. IP-адрес отправителя при этом равен адресу DR, а адрес места назначения - адресу RP. Формат сообщения register показан на рис. 4.4.9.5.7. Постоянная часть заголовка здесь идентична, показанной на рис. 4.4.9.5.3.

    Рис. 4.4.9.5.7. Формат сообщения register

    Поле B - (бит border) пограничный бит. B=1, если маршрутизатор непосредственно соединен с отправителем. Поле N - бит нулевого регистра. n устанавливается DR равным 1 при тестировании RP до истечения времени регистрации (register-suppression timer). Поле информационный мультикаст-пакет представляет собой оригинальное сообщение, посланное отправителем.

    Сообщение register-stop является уникастным, направляемым от RP к отправителю сообщения register. IP-адрес отправителя является адресом, к которому направлялось сообщение регистрации. IP-адрес места назначения равен адресу отправителя сообщения register. Формат сообщения register-stop показан на рис. 4.4.9.5.8.

    Рис. 4.4.9.5.8. Формат сообщения register-stop

    Поле закодированный групповой адрес имеет тот же смысл, что и на рис. 4.4.9.5.4. Для сообщений register-stop поле длины маски содержит длину адреса * 8 (32 для IPv4), если сообщение послано для одной группы.

    Поле уникастный адрес отправителя представляет собой IP-адрес ЭВМ отправителя из мультикастного информационного пакета. Длина этого поля в байтах задано полем длина адреса. Значение (0.0.0.0) может быть использовано для обозначения любого адреса.

    Сообщение join/prune посылается маршрутизаторами в направлении вышестоящих отправителей и RP. Сообщения join служит для построения совместно используемых маршрутных деревьев (RP-деревьев) или деревьев отправителей (SPT). Сообщения prune посылаются для отключения деревьев отправителей, когда участники покидают группу, а также для отправителей, которые не используют общее дерево. Формат сообщения join/prune показан на рис. 4.4.9.5.9.

    Рис. 4.4.9.5.9. Формат сообщения join/prune

    Поле адрес вышестоящего соседа представляет собой IP-адрес RPF или вышестоящего соседа. Поле holdtime характеризует время в секундах, в течение которого получатель должен поддерживать активное состояние join/prune. Если holdtime сделано равным `0xffff', получатель сообщения отключает таймаут для данного выходного интерфейса. Если holdtime сделано равным `0', таймаут происходит немедленно. Поле число групп равно количеству мультикаст-групп, содержащихся в сообщении.

    Поле закодированный мультикастный групповой адрес имеет формат, показанный на рис. 4.4.9.5.4. Произвольная группа (wildcard) (*,*,rp) характеризуется адресом 224.0.0.0 и `4' в поле длина маски. Подключение (*,*,rp) имеет биты WC и RPT равные 1.

    Поле число подключенных отправителей равно количеству адресов подключенных отправителей для данной группы. Поля адрес подключенного отправителя -1 .. N представляют собой список отправителей, которым посылающий маршрутизатор переправляет мультикастные дейтограммы при получении их через интерфейс, на который пришло данное сообщение. Формат полей кодированного адреса отправителя следует описанию на рис. 4.4.9.5.5.

    Рис. 4.4.9.5.10. Формат сообщения bootstrap

    Сообщения bootstrap пересылаются мультикастным способом группе `all-pim-routers', через все интерфейсы, имеющие PIM-соседей (за исключением того, через который получено сообщение). Сообщения bootstrap генерируются в BSR и посылаются с TTL=1. Формат сообщения bootstrap показан на рис. 4.4.9.5.10.

    Сообщение bootstrap делится на семантические фрагменты, если исходное сообщение превосходит предельный размер пакета. Формат этих фрагментов представлен ниже (см. также рис. 4.4.9.5.10):

    Поле метка фрагмента является случайным числом и служит для идентификации фрагментов принадлежащих одному и тому же сообщению. Фрагменты одного и того же сообщения имеют идентичные метки фрагмента. Поле длина хэш>-маски - это длина маски хэш функции в битах. Для IPv4 рекомендуется значение 30, а для IPv6 - 126. Поле BSR-приоритет содержит значение BSR-приоритета для включенного BSR. Это поле рассматривается как старший байт при сравнении BSR-адресов. Поле уникастный BSR-адрес является IP-адресом маршрутизатора (bootstrap) домена. Размер этого поля в байтах специфицирован в поле длина адреса. Поля закодированный групповой адрес -1..n является групповым префиксом (адрес и маска), с которым ассоциируются кандидаты RP. Поля число RP -1..N равны числу адресов кандидатов RP, включенных в сообщение bootstrap для соответствующего группового префикса. Маршрутизатор не замещает старый RP-набор для данного группового префикса до тех пор, пока не получит новое число RP-адресов для этого префикса. Адреса могут содержаться в нескольких фрагментах. Если получена только часть RP-набора для данного префикса, маршрутизатор эту часть выбрасывает, не изменяя RP-набора. Поля FRAG RP-cnt-1..m представляет собой число адресов кандидатов RP, включенных в этот фрагмент сообщения bootstrap, для соответствующего группового префикса. Поле ` FRAG RP-cnt ' облегчает разбор RP-набора для данного группового префикса, когда он размещается в более чем одном фрагменте. Поля уникастные rp-адреса -1..m представляют собой адреса кандидатов RP, для соответствующего группового префикса. Длина поля в байтах специфицировано полем длина адреса. Поля rp1..m-holdtime характеризуют значения holdtime для соответствующих RP. Это поле копируется из поля `holdtime' RP, записанного в BSR.

    Сообщение assert посылается когда мультикастный информационный пакет получен выходным интерфейсом, соответствующим (s,g) или (*,g), относящимся к отправителю. Формат такого сообщения представлен на рис. 4.4.9.5.11.

    Рис. 4.4.9.5.11. Формат сообщения assert

    Поле закодированный групповой адрес характеризует групповой адрес места назначения пакетов, который явился причиной посылки сообщения assert. Поле уникастный адрес отправителя содержит IP-адрес отправителя из дейтограммы, вызвавшей посылку мультикастного пакета Assert. Длина поля в байтах определена полем длины адреса. Поле R представляет собой RPT-бит. Если IP мультикастинг дейтограмма, вызвавшая посылку пакета assert направляется вниз по RP-дереву, тогда RPT-бит равен 1. Если маршрутизация осуществляется вдоль SPT, бит равен 0. Поле предпочтение несет в себе значения кода предпочтения, присвоенного уникастному протоколу маршрутизации, который организует проход до ЭВМ. Поле метрика содержит значение метрики для таблицы маршрутизации. Единицы измерения должны соответствовать требованиям маршрутного протокола.

    Сообщения кандидата RP посылаются периодически C-RP способом и уникастно адресуются к BSR. Формат таких сообщений показан на рис. 4.4.9.5.12.

    Рис. 4.4.9.5.12. Формат сообщения кандидата RP (C-RP)

    Поле # префиксов (Prefix-Cnt) содержит количество кодированных групповых адресов, включенных в сообщение, указывая групповые префиксы, для которых производится C-RP оповещение. Значение поля Prefix-Cnt = `0' предполагает использование префикса 224.0.0.0 с длиной маски 4, что означает - все мультикастные группы. Если C-RP не снабжена информацией о групповом префиксе, C-RP заносит в поле значение по умолчанию равное `0'. Поле A характеризует бит указания. Этот бит указывает, что BSR не должен переписывать информацию о групповых префиксах, приведенную в C-RP оповещении. В большинстве случаев C-RP устанавливает этот бит, равным 0. Поле Holdtime содержит значение времени, в течение которого оповещение корректно. Это поле позволяет определить время, когда оповещение устареет. Поле уникастный RP-адрес представляет собой адрес интерфейса, который объявляется кандидатом в RP. Длина этого поля в байтах определена полем длина адреса. Поле закодированный групповой адрес -1..n является групповым префиксом, для которого производится уведомление кандидатом в RP.

    Литература

    1

    Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast (pim) : Motivation and architecture. Work in Progress.

    2

    Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. The PIM architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996.

    3

    Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast-dense mode (pim-dm): Protocol specification. Work in Progress.

    4

    Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112.

    5

    Fenner, W. Internet group management protocol, version 2. Work in Progress.

    6

    Atkinson, R. Security architecture for the internet protocol, August 1995. RFC-1825.

    7

    Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993.

    Previous: 4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.6 Протокол резервирования ресурсов RSVP


    previous up down next index index
    Previous: 4.4.9.5 Протокол PIM    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.9.7 Протокол COPS (Common Open Policy Service)

    4.4.9.6 Протокол резервирования ресурсов RSVP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP используется также маршрутизаторами для доставки QOS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг. RSVP-запросы обеспечивают резервирование определенных сетевых ресурсов, которые нужны, чтобы обеспечить конкретный уровень QOS вдоль всего маршрута транспортировки данных. Функция этого протокола крайне важна и многообразна, именно по этой причине это один из самых сложных протоколов.

    RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных.

    RSVP предназначен для работы с существующими и будущими маршрутными протоколами, управляющими как обычными, так и мультикастными потоками. В последнем случае ЭВМ сначала посылает IGMP-запрос, для того чтобы подключиться к мультикастинг-группе, а затем уже RSVP-сообщение для резервирования ресурсов по маршруту доставки.

    Механизм обеспечения QOS включает в себя классификацию пакетов, административный контроль и диспетчеризацию. Классификатор пакетов определяет QoS класс (а иногда и маршрут движения) для каждого пакета. В процессе реализации резервирования RSVP-запрос проходит два местных управляющих модуля: "контроль доступа" и "управление политикой". Контроль доступа определяет, имеет ли узел достаточно ресурсов для удовлетворения поступившей заявки. Управление политикой определяет, имеет ли пользователь административное разрешение сделать данное резервирование. Если обе проверки завершились успешно, параметры передаются классификатору пакетов и интерфейсу канального уровня (диспетчеру пакетов). Если же какой-либо из тестов не прошел, программа RSVP присылает прикладному процессу сообщение об ошибке.

    Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:

    • RSVP выполняет резервирование для уникастных и мультикастных приложений, динамически адаптируясь к изменениям членства в группе вдоль маршрута.
    • RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.
    • RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока.
    • RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов.
    • RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов.
    • RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP.
    • RSVP обеспечивает несколько моделей резервирования или стилей, для того чтобы удовлетворить требованиям различных приложений.
    • RSVP обеспечивает прозрачность операций для маршрутизаторов, которые его не поддерживают.
    • RSVP может работать с IPv4 и IPv6.

    Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Схема работы процесса RSVP показана на рис. 4.4.9.6.1.

    Рис. 4.4.9.6.1. RSVP в ЭВМ и маршрутизаторе

    1. Потоки данных

    RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.

    Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId [, DstPort]. DestAddress - IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId - идентификатор IP протокола. Опционный параметр DstPort - обобщенный порт места назначения, т.е., еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.

    Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.

    Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка.

    2. Модель резервирования

    Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра - для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS.

    Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

    1. "Rspec", который определяет желательное значение QoS, и
    2. "Tspec", который описывает информационный поток.

    Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

    Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

    1. Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC-2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.
    2. IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.
    3. IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.

    Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации. В каждом промежуточном узле запрос резервирования запускает две процедуры:

    A. Резервирование канала

    Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec.

    Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS.

    Б. Переадресация запроса назад

    Запрос резервирования посылается от получателя отправителю (или отправителям) данных. Запрос резервирования, который переадресуется узлом дальше может отличаться от того, который он получил по двум причинам. Механизм управления трафиком модифицирует flowspec от узла к узлу. Что более важно, запросы резервирования, поступающие от получателей мультикастинг-дерева должны объединяться по мере продвижения процесса резервирования в направлении отправителя данных.

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

    Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

    3. Стили резервирования

    Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

    • Стиль WF (Wildcard-Filter)

    Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая "труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.

    Символически можно представить запрос резервирования стиля WF как:

    WF( * {Q}),

    где звездочка представляет произвольную подстановку при выборе отправителя, а Q - спецификация flowspec

    • Стиль FF (Fixed-Filter)

    Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как:

    FF(S{Q}),

    где S - выбранный отправитель, а Q - соответствующая спецификация flowspec; эта пара параметров образуют дескриптор потока. RSVP позволяет применение нескольких простых стилей резервирования FF одновременно, при этом формируется список дескрипторов потоков:

    FF(S1{Q1}, S2{Q2}, ...)

    Полное резервирование в канале для данной сессии характеризуется суммой Q1, Q2, ... для всех отправителей, куда посланы запросы.

    • Стиль SE (Shared Explicit)

    Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" (explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей. Запрос резервирования SE, содержащий flowspec Q и список отправителей S1, S2, ... можно представить в символьной форме как:

    SE((S1,S2,...){Q} )

    Разделенное резервирование, выполненное с применением стилей WF и SE, пригодно для мультикастных приложений, где несколько источников данных редко осуществляют передачу одновременно. Пакетная передача голоса может служить примером разделенного резервирования, так как лишь ограниченное число людей говорят одновременно. Каждый получатель может направить запрос резервирования WF или SE на удвоенную полосу пропускания, необходимую одному отправителю, позволяя тем самым говорить обоим партнерам одновременно. С другой стороны стиль FF, который осуществляет четкое резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов.

    Правила RSVP не позволяют объединять разделенные резервирования с четкими резервированиями, так как эти модели абсолютно несовместимы. Не допускается также объединение явного и произвольного (wildcard) выбора отправителей, так как это может вызвать предоставление незаказанных услуг получателю, который указал тип услуг явно. Таким образом, стили WF, SE и FF не совместимы.

    Можно моделировать эффект WF резервирования, используя стиль SE. Когда приложение запрашивает WF, процесс RSVP получателя может использовать местный статус для выполнения эквивалентного резервирования SE, которое в явном виде перечисляет всех отправителей. Однако резервирование SE вынуждает классификатор пакетов в каждом узле в явном виде выбрать каждого отправителя из списка, в то время как WF позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью "wild card". Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE.

    4. Примеры стилей

    На рис. 4.4.9.6.2. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1 (S2 и S3), подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1 (R2 и R3), которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.

    Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на рис. 4.4.9.6.2. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 4.4.9.6.3, 4.4.9.6.4 и 4.4.9.6.5 проиллюстрированы стили резервирования WF, FF и SE, соответственно.

    Рис. 4.4.9.6.2. Конфигурация маршрутизатора

    Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" показывает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" показывает результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует" каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.

    Рис. 4.4.9.6.3, демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение.

    1. Каждый из двух узлов, следующих за интерфейсом IГ посылают независимые запросы резервирования RSVP, эти два запроса должны быть объединены в одну спецификацию flowspec (3B), которая используется для выполнения резервирования в интерфейсе IГ.
    2. Резервирования для интерфейсов IB и IГ должны быть объединены, для того чтобы осуществить переадресацию запросов резервирования далее и получить спецификацию flowspec (4B).

    Рис. 4.4.9.6.3. Пример резервирования WF (Wildcard-Filter)

    На рис. 4.4.9.6.4 проиллюстрирован стиль резервирования FF (Fixed-Filter). Для каждого выходного интерфейса, имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различных дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF( S1{4B} ), который посылается предыдущему узлу (IА).

    На рис. 4.4.9.6.5 показан пример стиля резервирования SE. Когда резервирования стиля SE объединяются, результирующая спецификация фильтра является объединением исходных спецификаций, а результирующая спецификация flowspec равна наибольшей из flowspec.

    Рис. 4.4.9.6.4. Пример резервирования FF (Fixed-Filter)

    Рис. 4.4.9.6.5. Пример резервирования SE (Shared-Explicit)

    Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть рис. 4.4.9.6.2 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, напр., из-за того что сеть обеспечивает более короткий путь для пакетов отправителя к R1. Рис. 4.4.9.6.3 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.

    5. Механизмы протокола RSVP
    5.1. Сообщения RSVP

    Рис. 4.4.9.6.6. Маршрутизатор, использующий RSVP

    На рис. 4.4.9.6.6 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ. Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений (Resv) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком.

    Каждая ЭВМ отправитель передает RSVP сообщения "Path" вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Это состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит помимо этого следующую информацию:

    • Шаблон отправителя

    Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.

    Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.

    • Спецификация Tspec отправителя

    Сообщения Path должны содержать спецификацию отправителя Tspec, которая определяет характеристики информационного трафика, формируемого отправителем. Спецификация Tspec используется для предотвращения избыточного резервирования.

    • Спецификация Adspec

    Сообщение Path может нести в себе пакет данных оповещения OPWA, известный, как "Adspec". Пакет Adspec, полученный с сообщением Path, передается системе управления трафиком, которая присылает скорректированную версию Adspec. Последняя пересылается далее в виде сообщения Path.

    Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP.

    6. Объединение Flowspecs

    Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является "наибольшей" из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные.

    Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec.

    Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной. Например, если один запрос требует высокой пропускной способности, а другой - жесткого ограничения задержек, один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна быть способна сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound). В некоторых случаях спецификация flowspec по крайне мере настолько мала насколько возможно; это наибольший верхний предел GLB (Greatest Lower Bound).

    Для вычисления эффективного значения flowspec (Re, Te), инсталлируемого в интерфейс, используются следующие шаги [RFC 2210]. Здесь Te - эффективная спецификация Tspec, а Re - эффективная спецификация Rspec.

    1. Определяется эффективная спецификация flowspec для выходного интерфейса. В зависимости от технологии канального уровня, это может требовать объединения спецификаций flowspecs различных последующих узлов. Это означает вычисление эффективной спецификации flowspec, как LUB flowspecs. Какие спецификации следует объединять, определяется средой канального уровня, в то время как процедура объединения определяется используемой моделью обслуживания [RFC 2210]. В результате получается спецификация flowspec, которая непрозрачна для RSVP, но в действительности состоит из пары (Re, Resv_Te), где Re является эффективной спецификацией Rspec, а Resv_Te - эффективная спецификация Tspec.
    2. Производится вычисление спецификации Path_Te, зависящей от приложения и представляющей собой сумму всех Tspecs, которые были присланы в сообщениях Path, пришедших от различных предшествующих узлов (напр., некоторые или все узлы A, Б, и Б' на рис. 4.4.9.6.6).
    3. (Re, Resv_Te) и Path_Te передаются системе управления трафиком. Управление трафиком вычислит эффективную спецификацию flowspec, как минимум Path_Te и Resv_Te.

    7. Гибкое состояние

    RSVP использует подход "soft state" (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения "teardown" (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.

    Сообщения Path и Resv практически эквивалентны (idempotent). Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние же на неиспользованном в данный момент сегменте маршрута будет аннулировано по таймауту. Следовательно, определение того, является ли сообщение "новым" или "обновляющим" принимается отдельно для каждого узла в зависимости от его текущего состояния.

    Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP сообщений. Если таймаут удаления установлен равным K периодам обновления, тогда RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP, чтобы предотвратить их потерю из-за перегрузки канала.

    Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, неиспользуемые состояния будут аннулированы по таймауту, если не поступит прямых указаний по их ликвидации до этого.

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

    Состояние, которое получено через конкретный интерфейс I* никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I* должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на рис. 4.4.9.6.7, на котором показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 4.4.9.6.7 "Получает" и "Отправляет" подразумевает внешнее направление по отношению к маршрутизатору).

    Интерфейс IА

    Интерфейс IБ

    Получает

    Отправляет

    Получает

    Отправляет

    WF (* {4B})

    WF (* {3B})

    WF (* {3B})

    WF(*{4B})

    Резервирует

    * {4B}

    * {3B}

    Рис. 4.4.9.6.7. Независимые резервирования

    Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io.

    8. Аннулирование (Teardown)

    Сообщения RSVP "аннулирование" удаляет проход или состояние резервирования. Хотя прямое уничтожение старого резервирования не является обязательным, оно настоятельно рекомендуется, так как ускоряет переходные процессы в сети.

    Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

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

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

    Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

    Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

    9. Ошибки

    Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.

    Однако для синтаксически верных запросов резервирования имеется много способов быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема "резервирования килера", в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.

    1. Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0. Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.
    2. Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняется даже в случае не прохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю, установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.

    Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, "состояние блокады", в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным.

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

    • Имеется две возможные причины получателю настаивать на резервировании:
    1. Заказываемый ресурс доступен по всей длине пути, или
    2. Нужно получить желаемый уровень QoS вдоль оговоренного пути так далеко, как это возможно. Конечно, во втором случае, а может быть и в первом, получатель захочет настаивать на резервировании, осуществленном вплоть до точки блокировки.
    • Если бы эти резервирования в предыдущих узлах не были сохранены, реагирование RSVP на некоторые переходные отказы станет хуже. Например, предположим, что маршрут переключился на альтернативный, который сильно перегружен, так что существующие резервирования не могут быть удовлетворены, и система возвращается к исходному маршруту. Состояние блокады в каждом из маршрутизаторов до узкого места не должно быть немедленно удалено, так как не позволит системе быстро восстановиться.
    • Если бы мы не обновляли резервирование в предшествующих узлах каждые Tb секунд, они могли бы быть удалены по таймауту (Tb время таймаута состояния блокады).

    10. Подтверждение

    Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос.

    Этот механизм подтверждения имеет следующую последовательность:

    • Новый запрос резервирования со спецификацией flowspec больше чем любая из действующих в данной точке спецификаций сессии обычно вызывает либо сообщение ResvErr, либо ResvConf, отправляемое получателю каждым из отправителей данных. В этом случае, сообщение ResvConf будет подтверждением, относящимся ко всему пути.
    • Получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и он может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.

    11. Управление политикой

    Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Такого рода обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя.

    Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования.

    На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.

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

    12. Безопасность

    При использовании протокола RSVP возникают определенные проблемы безопасности.

    • Целостность сообщений и аутентификация узлов

    Повреждение или фальсификация запросов резервирования может привести к получению услуг неавторизованными пользователями или к отказам в услугах. RSVP осуществляет защиту против таких атак с помощью механизма аутентификации, действующего в каждом из узлов и использующего шифрование с применением хэш-функций. Механизм поддерживается объектами INTEGRITY, которые могут быть включены в любое сообщение RSVP. Эти объекты используют технику криптографических дайджестов, которая предполагает, что соседи RSVP совместно владеют секретом шифрования (см. [Baker96]).

    • Аутентификация пользователя

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

    • Безопасные потоки данных

    Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя.

    Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207].

    13. Области, не поддерживающие RSVP

    Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP вероятно никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако, если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг реального времени.

    Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие RSVP так и не поддерживающие RSVP маршрутизаторы переадресуют сообщения Path в соответствие с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему RSVP-маршрутизатору на пути к отправителю.

    Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP' и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210].

    При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.

    14. Модель ЭВМ

    Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

    H1

    Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress.

    H2

    Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress.

    H3

    Приложение получателя принимает сообщение Path.

    H4

    Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков.

    H5

    Приложение отправителя получает сообщение Resv.

    H6

    Отправитель начинает посылать информационные пакеты.

    Существует несколько соображений, касающихся синхронизации.

    • H1 и H2 могут произойти в любом порядке.
    • Предположим, что новый отправитель начинает отправку данных (H6), но пока нет мультикастинг маршрутов, так как ни один получатель не подключился к группе (H1). Тогда данные будут выбрасываться в некотором узловом маршрутизаторе (какой это будет узел, зависит от используемого протокола маршрутизации), пока не появится хотя бы один получатель.
    • Предположим, что новый отправитель начинает рассылку сообщений Path (H2) и данных (H6) одновременно, и имеется некоторое число получателей, но сообщения Resv пока не достигли отправителя (напр., потому что его сообщения Path еще не дошли до получателей). Тогда исходные данные могут прийти к получателю без желаемого уровня QoS. Отправитель может немного облегчить эту проблему, подождав прибытия первого сообщения Resv (H5). Однако получатели, которые достаточно далеко, могут еще не получить необходимого резервирования.
    • Если получатель начинает посылать сообщения Resv (H4) до получения какого-либо сообщения Path (H3), RSVP пришлет получателю сообщение об ошибке.

    Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.

    15. Функциональная спецификация RSVP
    15.1. Формат сообщений RSVP

    Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.

    16. Общий заголовок

    Рис. 4.4.9.6.8. Формат общего заголовка

    В общем заголовке имеются следующие поля:

    Vers. 4 бита - Номер версии протокола. В данном описании = 1.
    Флаги: 4 бита - 0x01-0x08. Зарезервированы.
    Флаги пока не определены.
    Тип Msg. Тип сообщения (8 бит).
    1 = Path
    2 = Resv
    3 = PathErr
    4 = ResvErr
    5 = PathTear
    6 = ResvTear
    7 = ResvConf
    Контрольная сумма RSVP: 16 бит

    Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.

    Send_TTL: 8 бит

    Значение TTL для протокола IP, с которым было послано сообщение.

    Длина RSVP: 16 бит

    Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.

    17. Форматы объектов

    Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 4.4.9.6.9:

    Рис. 4.4.9.6.9. Формат объекта

    Заголовок объекта имеет следующие поля:

    Длина в байтах

    16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4.

    Class-Num

    Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы:

    NULL

    Объект NULL имеет код Class-Num равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется.

    SESSION

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

    RSVP_HOP

    Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). Этот класс характеризует предшествующий узел (previous hop).

    TIME_VALUES

    Содержит значение периода обновления R, используемого отправителем сообщения. Необходим в каждом сообщении Path и Resv.

    STYLE

    Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Необходим в каждом сообщении Resv.

    FLOWSPEC

    Определяет желательный уровень QoS, в сообщениях Resv.

    FILTER_SPEC

    Определяет субнабор информационных пакетов сессии, которые должны получить желательный уровень QoS (специфицированный объектом FLOWSPEC), в сообщениях Resv.

    SENDER_TEMPLATE

    Содержит IP-адрес отправителя и, может быть, некоторые дополнительную информацию, идентифицирующую отправителя. Необходим в сообщениях Path.

    SENDER_TSPEC

    Определяет характеристики информационного трафика отправителя. Необходим в сообщениях Path.

    ADSPEC

    Несет в себе данные OPWA, в сообщении Path.

    ERROR_SPEC

    Специфицирует ошибку в сообщениях PathErr, ResvErr, или подтверждение в сообщении ResvConf.

    POLICY_DATA

    Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr.

    INTEGRITY

    Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного документа.

    SCOPE

    Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear.

    RESV_CONFIRM

    Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf.

    C-Type

    Тип объекта, уникален в пределах класса Class-Num.

    Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно, как 16-битовое число, для определения уникального типа для каждого из объектов.

    Старшие два бита Class-Num используются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.

    18. Сообщения Path

    Каждая ЭВМ-отправитель периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA).

    Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP. Формат сообщения Path имеет следующий вид:

    <Path Message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <RSVP_HOP>
    <TIME_VALUES>
    [ <POLICY_DATA> ... ]
    [ <sender descriptor> ]
    <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
    [ <ADSPEC> ]

    Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным.

    Объект PHOP (т.е., RSVP_HOP) каждого сообщения Path содержит адрес предшествующего узла, напр., IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH).

    Каждый узел, поддерживающий RSVP, вдоль пути перехватывает сообщение Path и обрабатывает его, с тем чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path.

    Периодически процесс RSVP в узле сканирует состояние прохода, чтобы сформировать новые сообщения Path для посылки их получателям. Каждое сообщение содержит дескриптор, характеризующий одного отправителя, несет в себе IP-адреса отправителя и его источника.

    Процесс RSVP переадресует и размножает (если требуется, например при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP адрес, сообщения Path, посланные разными интерфейсами содержат отличные адреса PHOP. Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов.

    Состояние пути для данной сессии и отправителя не обязательно должны иметь уникальные PHOP или уникальный входной интерфейс. Существует два случая, соответствующие мультикастной и уникастной сессиям.

    • Мультикастные сессии

    Мультикастинговая маршрутизация позволяет иметь стабильное дерево распределения, в котором сообщения Path от одного и того же отправителя приходят от более чем одного PHOP, и RSVP должен быть готов поддерживать все такие состояния пути. RSVP не должен пересылать сообщения Path, которые прибывают через входной интерфейс, отличный от указанного в маршрутной таблице.

    • Уникастные сессии

    В течение короткого периода времени, следующего после изменения уникастного маршрута, узел может получать сообщения Path от нескольких PHOP для данной сессии и отправителя. Узел не может надежно определить, какой из PHOP является правильным, хотя узел будет получать одновременно только один из PHOP. Одним из вариантов реализации RSVP является игнорирование PHOP и допущение для PHOP переключаться между имеющимися кандидатами. Другим вариантом является поддержание состояния пути для каждого PHOP и посылка сообщения Resv всем таким PHOP. В любом варианте ситуация является переходной, неиспользуемые состояния пути все равно будут удалены (явно или по таймауту).

    19. Сообщения Resv

    Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат:

    <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <RSVP_HOP>
    <TIME_VALUES>
    [ <RESV_CONFIRM> ] [ <SCOPE> ]
    [ <POLICY_DATA> ... ]
    <STYLE> <flow descriptor list>
    <flow descriptor list> ::= <empty> |
    <flow descriptor list> <flow descriptor>

    Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны следовать требованиям записанных в BNF.

    Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.

    Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.

    Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.

    • Стиль WF:

    <flow descriptor list> ::= <WF flow descriptor>
    <WF flow descriptor> ::= <FLOWSPEC>

    • Стиль FF:

    <flow descriptor list> ::=
    <FLOWSPEC> <FILTER_SPEC> |
    <flow descriptor list> <FF flow descriptor>
    <FF flow descriptor> ::=
    [ <FLOWSPEC> ] <FILTER_SPEC>

    Каждый запрос стиля FF описывается одной парой (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.

    • Стиль SE:

    <flow descriptor list> ::= <SE flow descriptor>
    <SE flow descriptor> ::=
    <FLOWSPEC> <filter spec list>
    <filter spec list> ::= <FILTER_SPEC>
    | <filter spec list> <FILTER_SPEC>

    Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом:

    • Явный выбор отправителя

    Резервирование переадресуется всем отправителям, чьи объекты SENDER_TEMPLATE, записанные в состоянии прохода соответствуют объекту FILTER_SPEC.

    • Произвольный выбор отправителей (wildcard)

    Запрос с произвольным выбором отправителя соответствует всем отправителям, которые маршрутизированы на данный выходной интерфейс.

    Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте.

    Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, больше чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле.

    20. Сообщения отмены прохода

    Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки.

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

    Сообщение PathTear должно маршрутизоваться в точности также как соответствующие сообщения Path. Следовательно, его IP-адрес места назначения должен совпадать с DestAddress, а его IP-адрес источника должен быть адресом отправителя из состояния прохода.

    <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <RSVP_HOP>
    [ <sender descriptor> ]
    <sender descriptor> ::= (see earlier definition)

    Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться.

    Удаление состояния прохода в результате получения сообщения PathTear или таймаута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Если стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрования, соответствующей отправителю S, должно быть удалено; если стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений.

    21. Сообщения отмены Resv

    Получение сообщения ResvTear (reservation teardown) удаляет соответствующие состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.

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

    Сообщение ResvTear должно маршрутизироваться аналогично соответствующим сообщениям Resv, а его IP-адрес места назначения является уникастным адресом предыдущего узла.

    <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
    <SESSION> <RSVP_HOP>
    [ <SCOPE> ] <STYLE>
    <flow descriptor list>
    <flow descriptor list> ::= (see earlier definition)

    Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.

    В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 4.4.9.6.4.

    • Если получатель R2 посылает сообщение ResvTear для резервирования S3{B}, соответствующее резервирование удаляется из интерфейса (IГ) и посылается ResvTear для S3{B} интерфейсу (IБ).
    • Если получатель R1 посылает ResvTear для резервирования S1{4B}, соответствующее резервирование удаляется из интерфейса (IВ) и немедленно посылается модифицированное сообщение Resv FF( S1{3B} ) интерфейсу (IА).
    • Если получатель R3 посылает сообщение ResvTear для S1{B}, никаких изменений резервирования не происходит и никаких сообщений далее не посылается.

    22. Сообщения об ошибке прохода

    Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя.

    <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <ERROR_SPEC>
    [ <POLICY_DATA> ...]
    [ <sender descriptor> ]
    <sender descriptor> ::= (see earlier definition)

    Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA.

    23. Сообщения об ошибках Resv

    Сообщения ResvErr (reservation error) сообщают об ошибках при обработке сообщений Resv, или о спонтанном нарушении резервирования, напр., в результате административного вмешательства.

    Сообщения ResvErr направляются соответствующим получателям, они маршрутизируются от узла к узлу с использованием состояния резервирования. В каждом из узлов в качестве IP-адреса места назначения используется уникастный адрес следующего узла.

    <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <RSVP_HOP>
    <ERROR_SPEC> [ <SCOPE> ]
    [ <POLICY_DATA> ...]
    <STYLE> [ <error flow descriptor> ]

    Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv.

    Следующие правила, зависящие от стиля, определяют структуру ошибки дескриптора потока.

    • Стиль WF:

    <error flow descriptor> ::= <WF flow descriptor>

    • Стиль FF:

    <error flow descriptor> ::= <FF flow descriptor>

    Каждый дескриптор потока в сообщении Resv стиля FF должен обрабатываться независимо и для каждого из них, имеющего ошибку, должно посылаться отдельное сообщение ResvErr.

    • Стиль SE:

    <error flow descriptor> ::= <SE flow descriptor>

    Сообщение ResvErr стиля SE может представит список субнабора спецификаций фильтрации, которые вызвали ошибки, в соответствующем сообщении Resv.

    Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF) может быть причиной N сообщений ResvErr.

    Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки. Конкретнее:

    • Узел, который обнаружил ошибку в запросе резервирования посылает сообщение ResvErr узлу, от которого получен ошибочный запрос резервирования.

    Это сообщение ResvErr должно содержать информацию, необходимую для определения ошибки и для маршрутизации сообщения об ошибке последующим узлам. Такое сообщение, следовательно, включает в себя объект ERROR_SPEC, копию объекта STYLE и соответствующий дескриптор потока, где зафиксирована ошибка. Если ошибка является результатом отказа при попытке увеличить резервирование, тогда существующее резервирование должно быть сохранено и должен быть установлен бит-флаг InPlace в ERROR_SPEC сообщения ResvErr.

    • Узлы переадресуют сообщение ResvErr последующим узлам, которые имеют локальное состояние резервирования. Для резервирования с произвольным выбором отправителей имеется дополнительное ограничение на пересылку сообщений ResvErr, связанное с блокировкой возможных циклических маршрутов. Существует строгое правило рассылки сообщений при ошибке, связанной с разрешением доступа. Сообщение ResvErr, которое посылается, должно нести в себе спецификацию FILTER_SPEC соответствующего состояния резервирования.
    • Когда сообщение ResvErr достигает получателя, приложение должно принять объект STYLE, список дескрипторов потока и объект ERROR_SPEC (включая его флаги).

    24. Сообщения подтверждения

    Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM.

    <ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
    <SESSION> <ERROR_SPEC>
    <RESV_CONFIRM>
    <STYLE> <flow descriptor list>
    <flow descriptor list> ::= (see earlier definition)

    Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address). Равенство кода ошибки и значения (Value) нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение.

    25. Использование портов

    Сессия RSVP определяется в норме тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения.

    RSVP допускает любое значение для ProtocolId. Однако, реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и в частности значения для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:

    • специфицирует ненулевое значение DstPort для протокола, который не имеет портов типа UDP/TCP, или
    • специфицирует нулевое значение DstPort для протокола, который имеет порты, специфицированные для UDP/TCP.

    Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP.

    1. Порты назначения должны быть взаимосогласованными.

    Состояния прохода и резервирования для одного и того же DestAddress и ProtocolId должны иметь свои значения DstPort, которые все равны нулю или все не равны нулю. Нарушение этого условия в узле является ошибкой "конфликт портов назначения (Conflicting Dest Ports)".

    2. Правило портов назначения.

    Если DstPort в описании сессии равен нулю, все поля SrcPort, используемые для этой сессии, также должны быть равны нулю. При этом предполагается, что протокол не имеет портов типа UDP/TCP. Нарушение этого условия в узле вызовет ошибку "Bad Src Ports".

    3. Порты источников должны быть взаимосогласованы.

    ЭВМ-отправитель не должна посылать состояния прохода со значением SrcPort равным так и неравным нулю. Нарушение этого условия вызовет ошибку "Conflicting Sender Port". Заметим, что протокол не допускает произвольного назначения номеров портов (wildcard), т.е., нулевой порт не может соответствовать ненулевому порту.

    26. Посылка сообщений RSVP

    Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.

    Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.

    По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой.

    Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий:

    • Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).
    • Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.

    RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание. Если RSVP-пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов.

    Некоторые мультикастные протоколы маршрутизации обеспечивают туннели, которые организуют IP-инкапсуляцию мультикастных пакетов и их транспортировку через маршрутизаторы, которые не поддерживают мультикастную маршрутизацию. RSVP может работать через такие мультикастные туннели следующим образом:

    1. Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.
    2. Следующий узел N' запоминает значение LIH в своем состоянии прохода.
    3. Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP).
    4. Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.

    27. Исключение циклов сообщений RSVP

    Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель "автоматического обновления". Такие петли автоматического обновления сохраняют состояние "вечно", даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов.

    Рассмотрим каждый тип сообщения.

    • Сообщения Path. Эти сообщения направляются точно тем же путем, что и информационные IP-пакеты. Следовательно, не должно возникать циклов для сообщений типа Path (за исключением циклов, связанных с переходными процессами установления маршрута).
    • Сообщения PathTear. Эти сообщения используют ту же маршрутизацию, что и сообщения Path и, следовательно, не могут образовывать циклов.
    • Сообщения PathErr. Так как сообщения Path не образуют циклов, они формируют состояние прохода, которое описывает обратный маршрут для каждого из отправителей, который не может иметь петель. Сообщения PathErr всегда направлены определенному отправителю и, следовательно, не могут образовывать циклов.
    • Сообщения Resv. Эти сообщения направлены определенному отправителю и не могут иметь циклов. Однако, сообщения Resv с произвольным выбором отправителя (wildcard) (стиль WF) имеет потенциал для запуска циклов обновления.
    • Сообщения ResvTear. Хотя сообщения ResvTear маршрутизируются также как и сообщения Resv. При повторном проходе по петле состояние будет отсутствовать (аннулировано), и любое сообщение ResvTear будет отброшено.
    • Сообщения ResvErr. Эти сообщения для стиля резервирования WF могут вызывать зацикливание по той же причине, что и для сообщений Resv.
    • Сообщения ResvConf. Эти сообщения направляются фиксированному уникастному получателю и не могут приводить к циклам.

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

    Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:

    1. Образуется объединение наборов IP-адресов отправителей, перечисленных во всех объектах SCOPE состояния резервирования данной сессии. Если состояние резервирования от некоторых NHOP не содержит объектов SCOPE, должен быть создан заменяющий список отправителей, который и помещается в указанное объединение. Для сообщения, которое получено выходным интерфейсом OI, список замен представляет собой набор отправителей, которые маршрутизированы на этот OI.
    2. Любые локальные отправители (т.е., любое приложение отправителя в данном узле) удаляются из этого списка.
    3. Если объект SCOPE должен быть послан PHOP, следует удалить из набора любого отправителя, который не присылает данные через PHOP.

    На рис. 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.

    >

    Интерфейс IА

    Интерфейс IБ

    Интерфейс IВ

    Получает

    Отправляет

    Получает

    Отправляет

    Получает

    Отправляет

    WF([S1,S2,S3])

    WF([S4])

    WF([S2,S3,S4])

    WF([S1])

    WF([S4,S1])

    WF([S2,S3])

    Рис. 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF

    Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:

    1. Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, соответствующего состоянию резервирования или сообщению, которое вызвало ошибку.
    2. Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.

    28. Состояние блокады

    Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии "состояния блокады", возникшего из-за сообщений ResvErr при решении проблемы KR-II.

    Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

    Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады (Qb(S),Tb(S)), где S - отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

    Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше чем Qi. Например, предположим, что LUB (least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты j, Qb[j] ≤ Qi[j].

    Предположим, что узел получает сообщение ResvErr от предыдущего узла P (или, если стиль выбора отправителя S является явным) в результате ошибки доступа. Тогда:

    1. Для P (или S) создается элемент состояния блокады, если он не существует.
    2. Qb(P) (или Qb(S)) делается равным flowspec Qe из сообщения ResvErr.
    3. Запускается (или перезапускается) соответствующий таймер блокады Tb(P) (или Tb(S)) на время Kb*R. Здесь Kb является фиксированным множителем, а R равно интервалу времени обновления состояния резервирования. Kb можно варьировать.
    4. Если имеется локальное состояние резервирования, которое не заблокировано, немедленно генерируется обновление резервирования для P (или S).
    5. Сообщение ResvErr переадресуется последующим узлам. Если бит InPlace=0, сообщение ResvErr направляется всем последующим узлам, где имеется состояние резервирования. Если бит InPlace=1, сообщение ResvErr направляется только следующим узлам, чьи Qi блокированы спецификацией Qb.

    В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

    • Если имеются какие-либо локальные запросы резервирования Qi, которые не заблокированы, они объединяются путем вычисления их LUB. Заблокированные резервирования игнорируются. Это позволяет требовать меньшее резервирование, которое имеет шанс на успех, после того как большее резервирование не удалось.
    • В противоположном случае (все локальные запросы Qi блокированы), они объединяются путем взятия GLB (Greatest Lower Bound) спецификаций Qi.

    Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

    На рис. 4.4.9.6.11 приведен пример использования состояния блокады для совместного резервирования (стиль WF). Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b). Рисунок показывает оконечное состояние после меньшего резервирования 2B пришедшего позднее из (d). Это стабильное состояние нарушается каждые Kb*R секунд, когда состояние блокады удаляется по таймауту. Следующее обновление (4B), посылаемое предыдущему узлу (a), предположительно будет отвергнуто, путем посылки сообщения ResvErr, которое восстановит состояние блокады, возвращая ситуацию к тому, что изображено на рисунке. В то же самое время сообщение ResvErr будет направлено следующему узлу (c) и всем получателям, ответственным за резервирование 4B.

    Рис. 4.4.9.6.11. Блокада для стиля WF

    29. Локальное восстановление

    Когда маршрут изменяется, следующее сообщение обновления Path или Resv установит проход или состояние резервирования (соответственно) вдоль нового маршрута. Чтобы обеспечить быструю адаптацию к изменениям маршрута, не вводя чрезмерно коротких периодов обновления, местный модуль протокола маршрутизации может сообщить процессу RSVP об изменении маршрута до определенных мест назначения. Процесс RSVP должен использовать эту информацию для запуска обновления в соответствующих областях с учетом изменения маршрута.

    При этом используются следующие правила спецификации:

    • Когда маршрутизация обнаруживает изменение набора выходных интерфейсов для места назначения G, RSVP должен обновить состояние прохода, подождать короткий период W и затем послать сообщение обновление Path всем сессиям G/* (т.е., любой сессии с местом назначения G, вне зависимости от порта назначения). Короткая выдержка перед рассылкой сообщения обновления Path нужна, чтобы позволить завершиться переходным процессам в маршрутном протоколе. В настоящее время предлагается W = 2 сек; однако, эта величина должна быть задана при конфигурировании каждого интерфейса.
    • Когда приходит сообщение Path с адресом предыдущего узла, который отличается от записанного в состоянии прохода, RSVP должен немедленно послать сообщение обновления Resv этому PHOP.

    30. Временные параметры

    Существует два временных параметра, соответствующие каждому элементу прохода или состоянию резервирования RSVP в узле: период обновления R между последовательными коррекциями состояния соседнего узла и время жизни локального состояния L. Каждое сообщение RSVP Resv или Path может содержать объект TIME_VALUES, специфицирующий значение R, которое было использовано при генерации данного сообщения обновления. Эта величина R затем используется для определения значения L. Величины R и L могут варьироваться от узла к узлу.

    Более подробно:

    1. Флойд и Джакобсон [FJ94] показали, что периодические сообщения, генерируемые независимыми сетевыми узлами, могут взаимно синхронизоваться. Это может привести к деградации сетевых услуг, так как периодические сообщения могут сталкиваться с другими сетевыми пакетами. Так как RSVP периодически посылает сообщения обновления, он должен избегать синхронизации сообщений и гарантировать, чтобы любая возникшая синхронизация не была стабильной. По этой причине таймер обновления должен быть рэндомизован в диапазоне [0.5R, 1.5R].
    2. Чтобы избежать преждевременной потери состояния, L должно удовлетворять условию L ≥ (K + 0.5)*1.5*R, где K небольшое целое число. Тогда в худшем случае, K-1 последовательных сообщений могут быть потеряны без ликвидации состояния. Чтобы вычислить время жизни L для комбинации состояний с различными R R0, R1, ..., заменяем R на max(Ri). В настоящее время по умолчанию K = 3. Однако может быть необходимо установить большее значение K для узлов с высокой вероятностью потерь. K может устанавливаться при конфигурации интерфейса вручную или с помощью какой-либо адаптивной процедуры.
    3. Каждое сообщение Path или Resv несет в себе объект TIME_VALUES, содержащий время обновления R, использованное при генерации обновлений. Узел получателя использует это R для определения времени жизни L записанного состояния, созданного или обновленного данным сообщением.
    4. Время обновления R выбирается локально для каждого из узлов. Если узел не использует локального восстановления резервирования, нарушенного в результате изменения маршрута, меньшее значение R ускоряет адаптацию к изменениям маршрута, но увеличивает издержки RSVP. Узел может настраивать эффективное значение R динамически, чтобы контролировать уровень издержек, связанных с сообщениями обновления. В настоящее время по умолчанию выбирается R = 30 секундам. Однако значение по умолчанию Rdef должно выбираться индивидуально для каждого интерфейса.
    5. Когда R меняется динамически, существует предел того, как быстро оно может расти. Отношение величин R2/R1 не должно превосходить 1 + Slew.Max. В настоящее время, Slew.Max равно 0.30. При K = 3, один пакет может быть потерян без таймаута состояния, в то время как R увеличивается на 30% за период обновления.
    6. Чтобы улучшить надежность, узел может временно после изменения состояния посылать сообщения обновления более часто.
    7. Значения Rdef, K и Slew.Max, используемые в приложении, должны легко модифицироваться для каждого интерфейса.

    31. Политика в области трафика и узлы с не интегрированными услугами

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

    1. Краевые точки сети.
    2. Точки объединения данных от многих отправителей.
    3. Точки ветвления, где трафик в различных ветвях может требовать различных уровней резервирования.

    RSVP знает, где такие точки находятся, и должен обеспечивать этими данными механизм управления трафиком. С другой стороны, RSVP не интерпретирует информацию в flowspec и, следовательно, не знает, использованы ли рекомендации управления в каждом конкретном случае.

    Процесс RSVP передает управлению трафиком специальный флаг политики для каждой из трех указанных выше ситуаций.

    • E_Police_Flag - управление входом

    Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю, флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION.

    • M_Police_Flag - управление объединением

    Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя.

    • B_Police_Flag -управление ветвлением

    Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION.

    RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS. Эта информация передается получателям в спецификации Adspecs [RFC 2210].

    При обычной IP-переадресации, RSVP может обнаружить узлы без поддержки RSVP путем сравнения значения IP TTL, с которым послано сообщение Path, с полученным TTL. Для этой цели TTL помещается в общий заголовок. Однако, TTL не всегда является надежным индикатором узлов без поддержки RSVP, и для этих целей иногда используются другие средства. Например, если маршрутный протокол использует туннели с IP-инкапсуляцией, этот протокол должен проинформировать RSVP о наличии узлов, лишенных поддержки RSVP. В отсутствии автоматических механизмов осуществляется ручная конфигурация.

    32. ЭВМ с несколькими сетевыми интерфейсами

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

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

    • Посылка данных

    Приложение отправителя использует API вызов для декларации характеристик его информационного потока для RSVP. Этот вызов может опционно включать локальный IP-адрес отправителя. Если он установлен приложением, этот параметр должен быть адресом интерфейса для отправки информационных пакетов, в противном случае, используется системный интерфейс по умолчанию.

    Процесс RSVP ЭВМ посылает затем приложению сообщения Path только через специфицированный интерфейс.

    33. Выполнение резервирования

    Приложение-получатель использует вызов API для запроса резервирования RSVP. Этот вызов может опционно включать локальный IP-адрес получателя, т.е., адрес интерфейса для получения информационных пакетов. В случае мультикаст-сессий это интерфейс, к которому подключилась группа. Если этот параметр опущен, система использует значение по умолчанию.

    Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс. Однако, когда приложение исполняется в маршрутизаторе, а сессия является мультикастной, возникает более сложная ситуация. Предположим, что в этом случае приложение получателя присоединяется к группе через интерфейс Iapp, который отличается от Isp - ближайшего интерфейса по пути к отправителю. Теперь имеется два возможных пути для мультикастной маршрутизации при доставке информационных пакетов приложению. Процесс RSVP должен определить, какой вариант выбрать, просмотрев состояние прохода и решив, какой из входных интерфейсов следует использовать для посылки сообщений.

    1. Протокол мультикастной маршрутизации может создавать отдельные ветви дерева доставки к Iapp. В этом случае будет иметься состояние прохода для обоих интерфейсов Isp и Iapp. Состояние прохода в Iapp должно только соответствовать резервированию локального приложения. Оно должно быть помечено процессом RSVP как "Local_only". Если существует состояние прохода "Local_only" для Iapp, сообщение Resv должно посылаться через Iapp. Заметим, что имеется возможность для блоков состояния прохода Isp и Iapp иметь один и тот же следующий узел, если в маршрут вклинивается область, не поддерживающая RSVP.
    2. Протокол мультикастной маршрутизации может переадресовать данные в пределах маршрутизатора от Isp к Iapp. В этом случае Iapp появится в списке выходных интерфейсов состояния прохода Isp и сообщения Resv должны будут посылаться через Isp.
    3. Когда сообщения Path и PathTear переадресованы, состояние прохода, помеченное как "Local_Only", должно игнорироваться.

    34. Будущая совместимость

    В будущем для существующих классов могут быть описаны новые объекты C-Типа, а могут быть определены и новые классы объектов. Крайне желательно использовать такие объекты Интернет в рамках старых приложений, которые их не распознают. К сожалению, это возможно с заметными ограничениями. Здесь нужно придерживаться следующих правил (`b' означает бит).

    1. Неизвестный класс

    Существует три возможных способа, чтобы приложение RSVP могло работать с объектом неизвестного класса. Этот выбор определяется двумя старшими битами октета Class-Num.

    • Class-Num = 0bbbbbbb. Все сообщение должно быть отброшено и возвращена ошибка "Unknown Object Class" (неизвестный класс объекта).
    • Class-Num = 10bbbbbb. Узел должен игнорировать объект без дальнейшей пересылки или отправки сообщений об ошибке.
    • Class-Num = 11bbbbbb. Узел должен игнорировать объект, но может переадресовать его далее без модификации со всеми сообщениями, вызванными данным запросом.

    Ниже приведены более детализированные правила для работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb:

    1. Такие объекты неизвестного класса, включенные в сообщения PathTear, ResvTear, PathErr или ResvErr, должны немедленно переадресовываться в рамках того же сообщения.
    2. Такие объекты неизвестного класса, включенные в сообщения Path или Resv, должны быть записаны в соответствующие состояния и посланы в сообщениях обновления, сопряженных с указанным состоянием.
    3. Когда формируется обновление Resv путем объединения нескольких запросов резервирования, сообщение обновления должно включать в себя объединение объектов неузнанных классов всех компонентов запроса. В этом объединении каждый такой объект может присутствовать только один раз.
    4. Исходный порядок таких объектов необязательно сохранять. Однако формируемое сообщение должно подчиняться общим правилам в отношении упорядочения объектов.

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

    2. Неизвестный C-Тип для известного класса

    Появление объекта с неизвестным C-типом приведет к выбрасыванию всего сообщения и генерации сообщения об ошибке (ResvErr или PathErr). Сообщение об ошибке будет включать Class-Num и C-тип, который был не распознан. Оконечная система, которая отправила нераспознанное сообщение может использовать эту информацию, чтобы попытаться повторить попытку с объектом другого C-типа.

    Объекты определенных классов (FLOWSPEC, ADSPEC и POLICY_DATA) не прозрачны для RSVP, который просто передает их системе управления трафиком или другим модулям управления. В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-Тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке.

    35. Интерфейсы RSVP

    RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ - интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен).

    35.1. Интерфейс приложения RSVP

    Структура реального интерфейса может зависеть от операционной системы. Некоторые из вызовов предполагают асинхронную присылку информации.

    • Регистрация сессии

    Вызов: SESSION( DestAddress , ProtocolId, DstPort
    [ , SESSION_object ]
    [ , Upcall_Proc_addr ] ) -> Session-id

    Этот вызов инициирует RSVP обработку сессии, заданной DestAddress, ProtocolId и, возможно, номером порта DstPort. В случае успеха вызов SESSION возвращает локальный идентификатор сессии Session-id, который может использоваться при последующих вызовах.

    Параметр Upcall_Proc_addr определяет адрес вызова процедуры получения кода ошибки или информации о событии. Параметр SESSION_object включен для организации механизма поддержки более общего описания сессии ("обобщенный порт назначения"). Обычно SESSION_object опускается.

    • Определение отправителя

    Вызов: SENDER( Session-id
    [ , Source_Address ] [ , Source_Port ]
    [ , Sender_Template ]
    [ , Sender_Tspec ] [ , Adspec ]
    [ , Data_TTL ] [ , Policy_data ] )

    Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к SENDER для регистрации сессии как `Session-id' заставит RSVP начать рассылку сообщений Path для данной сессии; последующие вызовы будут модифицировать информацию о проходе.

    Параметры SENDER интерпретируются следующим образом:

    • Source_Address. Это адрес интерфейса через который будут посылаться данные. Если этот параметр пропущен, будет использоваться интерфейс по умолчанию. Этот параметр необходим для ЭВМ с двумя и более сетевыми интерфейсами.
    • Source_Port. Это UDP/TCP порт, через который будут посылаться данные.
    • Sender_Template. Этот параметр включен для поддержки механизма более общего описания отправителя ("обобщенный порт источника"). Обычно этот параметр может быть опущен.
    • Sender_Tspec. Этот параметр описывает трафик потока; смотри [RFC 2210].
    • Adspec. Этот параметр может быть специфицирован для инициализации вычисления свойств QoS вдоль пути; смотри [RFC 2210].
    • Data_TTL. Это IP TTL параметр, который несут в себе информационные пакеты. Он необходим, чтобы гарантировать условие, при котором сообщения Path не будут попадать за пределы зоны мультикастинг-сессии.
    • Policy_data. Это опционный параметр несет в себе управляющую информацию для отправителя. Эта информация может задаваться системной службой и для приложения может быть недоступной.
    • RESERVE

    Вызов: RESERVE( session-id, [ receiver_address , ]
    [ CONF_flag, ] [ Policy_data, ]
    style, style-dependent-parms )

    Получатель использует этот вызов, для того чтобы осуществить или модифицировать резервирование для сессии `session-id'. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений.

    Опционный параметр `receiver_address' может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр `Policy_data' специфицирует управляющие данные получателя, в то время как параметр `style' указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.

    • Отбой

    Вызов: RELEASE( session-id )

    Этот вызов удаляет состояние RSVP для сессии, указанной в session-id. Узел затем шлет соответствующие сообщения отмены (teardown) и прекращает рассылку сообщений обновления для session-id.

    • Вызовы Error/Event (ошибка/событие)

    Общая форма вызова имеет вид:

    Обращение: <Upcall_Proc>( ) -> session-id, Info_type,
    information_parameters

    "Upcall_Proc" представляет собой процедуру, чей адрес был дан при вызове SESSION. Это обращение может произойти асинхронно в любое время после вызова SESSION до вызова RELEASE и служит для индикации ошибки или события.

    В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа.

    1. Info_type = PATH_EVENT

    Обращение Path Event приводит к тому, что получение первого сообщения Path для данной сессии, указывает приложению получателя на наличие, по крайней мере, одного отправителя или на изменение состояние прохода.

    Обращение (отклик): <Upcall_Proc>( ) -> session-id,
    Info_type = PATH_EVENT,
    Sender_Tspec, Sender_Template
    [ , Adspec ] [ , Policy_data ]

    Это обращение выдает спецификации Sender_Tspec, Sender_Template, Adspec и управляющую информацию из запроса Path.

    2. Info_type = RESV_EVENT

    Обращение Resv Event запускается в результате получения первого сообщения RESV, или как следствие модификации предшествующего состояния резервирования для данной сессии.

    Обращение (отклик): <Upcall_Proc>( ) -> session-id,
    Info_type = RESV_EVENT,
    Style, Flowspec, Filter_Spec_list
    [ , Policy_data ]

    `Flowspec' - эффективное значение QoS, которое получено. Заметим, что сообщение Resv (стиль FF) может вызвать несколько обращений RESV_EVENT, по одному для каждого дескриптора потока.

    3. Info_type = PATH_ERROR

    Событие Path Error индицирует ошибку в информации отправителя, которая была специфицирована в запросе SENDER.

    Обращение (отклик): <Upcall_Proc>( ) -> session-id,
    Info_type=PATH_ERROR,
    Error_code , Error_value ,
    Error_Node , Sender_Template
    [ , Policy_data_list ]

    Параметр Error_code определяет ошибку, а Error_value может нести в себе некоторую дополнительную (возможно системно-зависимую) информацию об ошибке. Параметр Error_Node специфицирует IP-адрес узла, который обнаружил ошибку. Параметр Policy_data_list, если он присутствует, содержит любые объекты POLICY_DATA из неудачного сообщения Path.

    4. Info_type = RESV_ERR

    Событие Resv Error указывает на ошибку в сообщении резервирования, в формирование которого приняло участие данное приложение.

    Обращение (отклик): <Upcall_Proc>( ) -> session-id,
    Info_type = RESV_ERROR,
    Error_code , Error_value ,
    Error_Node , Error_flags ,
    Flowspec, Filter_spec_list
    [ , Policy_data_list ]

    Параметр Error_Node специфицирует IP-адрес узла, который обнаружил данное событие.

    Имеется два флага Error_flags:

    - InPlace

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

    - NotGuilty

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

    Filter_spec_list и Flowspec содержат соответствующие объекты из ошибки дескриптора потока. List_count специфицирует число FILTER_SPECS в списке Filter_spec_list. Параметр Policy_data_list содержит любые объекты POLICY_DATA из сообщения ResvErr.

    5. Info_type = RESV_CONFIRM

    Событие Подтверждение указывает, что получено сообщение ResvConf.

    Обращение (отклик): <Upcall_Proc>( ) -> session-id,
    Info_type = RESV_CONFIRM,
    Style, List_count,
    Flowspec, Filter_spec_list
    [ , Policy_data ]

    Параметры интерпретируются также как и для отклика Resv Error.

    Хотя сообщения RSVP, указывающие на события path или resv могут приходить периодически, API должно послать соответствующие асинхронные отклики приложению только на первое из них или при изменении полученной информации. Все события, сопряженные с ошибками или подтверждениями должны доводиться до сведения приложения.

    36. Интерфейс управления трафиком RSVP

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

    Объединение RSVP-резервирований необходимо из-за мультикастной доставки данных, при которой информационные пакеты размножаются для отправки последующим узлам. В каждой такой точке размножения, RSVP должен объединять запросы резервирования от последующих узлов путем выбора "максимума" их спецификаций flowspecs. В данном маршрутизаторе или ЭВМ может присутствовать несколько таких точек объединения/размножения.

    1. IP-уровень

    Мультикастная IP рассылка выполняет разветвление потока на IP-уровне. В этом случае RSVP должен объединять резервирования, соответствующих выходных интерфейсов для последующей отправки запроса резервирования далее.

    2. Сеть

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

    3. Драйвер канального уровня

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

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

    • Выполнение резервирования

    Вызов: TC_AddFlowspec( Interface, TC_Flowspec,
    TC_Tspec, TC_Adspec, Police_Flags )
    -> RHandle [, Fwd_Flowspec]

    Параметр TC_Flowspec определяет желательное значение QoS для управления доступом;. Его значение вычисляется как максимум совокупности спецификаций flowspecs для последующих узлов (см. ниже описание вызова Compare_Flowspecs). Параметр TC_Tspec определяет эффективное значение спецификации отправителя Tspec Path_Te. Параметр TC_Adspec задает спецификацию Adspec. Параметр Police_Flags несет в себе три флага E_Police_Flag, M_Police_Flag и B_Police_Flag.

    Если данный вызов оказался успешным, он устанавливает новый канал резервирования, соответствующий RHandle; в противном случае, он возвращает код ошибки. Код RHandle используется вызывающей программой для будущих ссылок на это резервирование. Если служба управления трафиком модифицирует flowspec, вызов вернет модифицированный объект Fwd_Flowspec.

    • Модификация резервирования

    Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
    TC_Tspec, TC_Adspec, Police_flags )
    [ -> Fwd_Flowspec ]

    Этот вызов используется для модификации существующего резервирования. TC_Flowspec передается блоку контроля разрешения. Если разрешения нет, текущая спецификация flowspec остается в силе. Соответствующие спецификации фильтров, если таковые имеются, остаются не затронутыми. Другие параметры определены также как и в TC_AddFlowspec. Если система модифицирует flowspec, вызов вернет также модифицированный объект Fwd_Flowspec.

    • Уничтожение спецификации Flowspec

    Вызов: TC_DelFlowspec( Interface, RHandle )

    Этот вызов ликвидирует существующее резервирование, включая спецификацию flowspec и все сопряженные спецификации фильтров.

    • Добавление спецификации фильтра

    Вызов: TC_AddFilter( Interface, RHandle,
    Session , FilterSpec ) -> FHandle

    Этот вызов добавляет новую спецификацию фильтра для резервирования, заданного RHandle. Запрос посылается после успешного вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтра FHandle.

    • Уничтожение спецификации фильтра

    Вызов: TC_DelFilter( Interface, FHandle )

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

    • Модификация OPWA

    Вызов: TC_Advertise( Interface, Adspec,
    Non_RSVP_Hop_flag ) -> New_Adspec

    Этот вызов используется при OPWA и служит для вычисления выходной спецификации New_Adspec для заданного интерфейса. Битовый флаг Non_RSVP_Hop_flag должен устанавливаться в случае, когда демон RSVP обнаруживает, что предшествующий узел содержит один или более маршрутизаторов, не поддерживающих RSVP. TC_Advertise вставит эту информацию в New_Adspec для оповещениястить обнаружения такого узла.

    • Запрос резервирования

    Обращение (отклик): TC_Preempt() -> RHandle, Reason_code

    Для того чтобы выдать новый запрос резервирования, модули контроля разрешения и управления могут осуществить выделение квот для одного или двух существующих резервирований. Это вызовет отклик TC_Preempt() на каждое привилегированное RSVP резервирование, отправляя дескриптор резервирования RHandle и субкод причины.

    37. Интерфейс маршрутизации RSVP

    Реализация RSVP нуждается в следующей поддержке со стороны механизма маршрутизации узла.

    • Запрос маршрута

    Для пересылки сообщений Path и PathTear процесс RSVP должен быть способен запрашивать процесс маршрутизации с целью получения маршрутных данных.

    Ucast_Route_Query( [ SrcAddress, ] DestAddress,
    Notify_flag ) -> OutInterface
    Mcast_Route_Query( [ SrcAddress, ] DestAddress,
    Notify_flag )
    -> [ IncInterface, ] OutInterface_list

    В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Если флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет.

    Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение `No such route' (такой маршрут отсутствует) возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.

    • Сообщение об изменении маршрута

    При маршрутном запросе с флагом Notify_flag = True, процесс маршрутизации может послать асинхронное сообщение процессу RSVP, который уведомляет об изменении определенного маршрута.

    Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
    OutInterface
    Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
    [ IncInterface, ] OutInterface_list

    • Обнаружение списка интерфейсов

    RSVP должен быть способен запоминать, какой реальный и виртуальный интерфейсы являются активными, а также их IP-адреса.

    Должна быть предусмотрена возможность логической дезактивации интерфейса для RSVP. Когда интерфейс дезактивирован, сообщения Path не должны проходить через данный интерфейс, если сообщение RSVP получено, оно должно быть отброшено (возможно, с соответствующей записью в журнале операций).

    38. Пакетные I/O интерфейсы RSVP

    Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.

    • Неизбирательный режим приема сообщений RSVP

    Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.

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

    • Спецификация выходного канала

    RSVP должен уметь обеспечить посылку дейтограммы через специальный выходной интерфейс (реальный или виртуальный) в обход обычного механизма маршрутизации. Виртуальным каналом может быть, например, мультикастный туннель.

    • Спецификация адреса источника и TTL

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

    • Оповещение маршрутизатора

    RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).

    39. Манипуляции, зависящие от вида услуг

    Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Для того чтобы манипулировать этими объектами процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.

    • Сравнение спецификаций потоков

    Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
    result_code

    Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te.

    • Сравнение LUB Flowspecs

    LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
    Flowspec_LUB

    • Вычисление GLB Flowspecs

    GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
    Flowspec_GLB

    • Сравнение Tspecs

    Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

    Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны.

    • Сумма Tspecs

    Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

    Этот вызов используется для вычисления Path_Te.

    40. Приложение A. Определения объектов

    C-типы определены для двух семейств адресов Интернет IPv4 и IPv6. Для работы с другими адресными семействами можно легко определить новый C-тип. Все неиспользуемые поля должны заполняться нулями и игнорироваться при получении .

    Класс сессии
    Класс сессии = 1.

    • Объект IPv4/UDP SESSION: Класс = 1, C-тип = 1

    Объект IPv6/UDP SESSION: Класс = 1, C-тип = 2

    DestAddress

    Уникастный или мультикастный IP-адрес места назначения сессии. Это поле не должно быть равно нулю.

    Протокол Id

    Идентификатор IP-протокола для потока данных. Это поле не должно быть равно нулю.

    Флаги

    0x01 = E_Police flag

    Флаг E_Police используется в сообщениях Path для определения эффективного "края" сети, с целью организации управления трафиком. Если ЭВМ отправитель сама не способна осуществлять управление трафиком, она установит этот бит в сообщениях Path, которые посылает. Первый узел, где RSVP имеется возможность управления трафиком (если это требуется), установит этот флаг равным нулю.

    >DstPort

    UDP/TCP порт места назначения сессии. Допустимо значение нуль, означающее отсутствие порта.

    Класс RSVP_HOP

    RSVP_HOP класс = 3.

    Объект IPv4 RSVP_HOP: Класс = 3, C-Тип = 1

    Объект IPv6 RSVP_HOP: Класс = 3, C-Тип = 2

    Этот объект несет в себе IP-адрес интерфейса, через который последний RSVP-узел переслал это сообщение. Дескриптор логического интерфейса LIH (Logical Interface Handle) используется, для того чтобы различать логические выходные интерфейсы. Узел, получая LIH в сообщении Path, запоминает его величину и возвращает его в объектах HOP последующих сообщений Resv, посланных узлу, который сформировал LIH. LIH должен быть тождественно равен нулю, если не существует дескриптора логического интерфейса.

    Класс INTEGRITY

    INTEGRITY класс = 4.

    Класс TIME_VALUES

    TIME_VALUES класс = 5.

    • Объект TIME_VALUES: Класс = 5, C-Тип = 1

    Период обновления

    Период таймаута обновления R, использованного для генерации этого сообщения (в миллисекундах).

    Класс ERROR_SPEC

    ERROR_SPEC класс = 6.

    • Объект IPv4 ERROR_SPEC: Класс = 6, C-тип = 1
    • Объект IPv6 ERROR_SPEC: Класс = 6, C-тип = 2

    Поле адрес узла, где произошла ошибка является IP-адресом (IPv4 или Ipv6).

    Флаги

    0x01 = InPlace

    Это значение поля флаги используется только для объектов ERROR_SPEC в сообщении ResvErr. Если флаг = 1, это указывает, что в узле, где произошла ошибка, установлено резервирование.

    0x02 = NotGuilty

    Это значение поля флаги используется только для объекта ERROR_SPEC в сообщении ResvErr. Это значение устанавливается для интерфейса в прикладной программе получателя. Если флаг имеет такой код, спецификация FLOWSPEC, которая вызвала ошибку, больше запрошенной получателем.

    Код ошибки.Одно-октетное поле кода описания ошибки.

    Значение ошибки

    Двухоктетное поле, содержащее дополнительную информацию об ошибке. Его содержимое зависит от типа ошибки. Значения поля код ошибки и значение ошибки приведены в приложении B (см. ниже).

    Класс SCOPE = 7.

    Этот объект содержит список IP-адресов, использованных для сообщений маршрутизации с произвольным выбором отправителей (wildcard) без петель. Адреса должны быть перечислены в возрастающем порядке.

    • Объект IPv4 SCOPE: Класс = 7, C-тип = 1

    Объект Ipv6 SCOPE: Класс = 7, C-тип = 2

    Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.

    Класс STYLE = 8.

    • Объект STYLE: Класс = 8, C-тип = 1

    Поле Флаги: 8 бит. (Пока не определены)

    Вектор опций: 24 бита

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

    19 бит: Зарезервировано
    2 бита: контроль совместного использования
    00b: Зарезервировано
    01b: Явное резервирование
    10b: Распределенное резервирование
    11b: Зарезервировано

    3 бита: Управление выбором отправителя
    000b: Зарезервировано
    001b: Произвольный выбор (Wildcard)
    010b: Прямой выбор (Explicit)
    011b - 111b: Зарезервировано

    Младшие биты вектора опций определяются стилем:

    WF 10001b
    FF 01010b
    SE 10010b

    Класс FLOWSPEC

    Класс FLOWSPEC = 9.

    • Зарезервировано (устарело) объект flowspec: Класс = 9, C-Тип = 1
    • Объект Inv-serv Flowspec: Класс = 9, C-тип = 2

    Содержимое и правила кодирования этого объекта описаны в документах, подготовленных рабочей группой int-serv [RFC 2210].

    Класс FILTER_SPEC = 10.

    • Объект IPv4 FILTER_SPEC: Класс = 10, C-тип = 1

    Объект IPv6 FILTER_SPEC: Класс = 10, C-тип = 2

    Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.

    • Объект IPv6 Flow-label FILTER_SPEC: Класс = 10, C-тип = 3

    SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ отправителя. Его значение не должно быть равно нулю.

    SrcPort. UDP/TCP номер порта отправителя, или нуль, указывающий на отсутствие порта.

    Метка потока. 24-битовое поле метки потока, определенной в IPv6. Этот код может использоваться классификатором пакетов для эффективной идентификации кадров, принадлежащих определенному потоку данных (отправитель-> место назначения).

    Класс SENDER_TEMPLATE = 11.

    • Объект IPv4 SENDER_TEMPLATE: Класс = 11, C-тип = 1

    Определение то же, что и для объекта IPv4/UDP FILTER_SPEC.

    • Объект IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 2

    Определение то же, что и для объекта IPv6/UDP FILTER_SPEC.

    • Объект метки потока IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 3

    Класс SENDER_TSPEC = 12.

    • Объект Intserv SENDER_TSPEC: Класс = 12, C-тип = 2

    Содержимое и правила кодирования для этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

    Класс ADSPEC = 13.

    • Объект Intserv ADSPEC: Класс = 13, C-тип = 2

    Содержимое и формат этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

    Класс POLICY_DATA = 14.

    • Объект POLICY_DATA: Класс = 14, C-тип = 1

    Содержимое этого объекта будет определено в будущем.

    Класс Resv_CONFIRM = 15.

    • Объект IPv4 RESV_CONFIRM: Класс = 15, C-тип = 1

    Объект характеризует 4-байтовый IP-адрес получателя (Ipv4).

    • Объект IPv6 RESV_CONFIRM: Класс = 15, C-тип = 2

    Объект характеризует 15-байтовый IP-адрес получателя (Ipv6).

    41. Приложение B. Коды и значения ошибки

    Нижеприведенные коды ошибок могут встретиться в объектах ERROR_SPEC, и предназначены для пересылки оконечным системам. За исключением специально оговоренных случаев эти коды могут использоваться только в сообщениях ResvErr.

    • Код ошибки = 00: Подтверждение.

    Это код зарезервирован для использования в объекте ERROR_SPEC сообщения ResvConf. Значение ошибки также будет равно нулю.

    • Код ошибки = 01: Отказ системы управления допуском.

    Запрос резервирования отвергнут системой управления допуском из-за недостатка ресурсов. Для этого кода ошибки 16 бит поля значение ошибки имеют формат:

    ssur cccc cccc cccc

    где биты имеют следующие значения:

    ss = 00: Младшие 12 бит содержат глобально-определенный субкод (значение приведены ниже).

    ss = 10: Младшие 12 бит содержат организационно-специфический субкод. Предполагается, что RSVP интерпретирует этот код как обычное число.

    ss = 11: Младшие 12 бит содержат субкод, зависящий от вида услуг. Предполагается, что RSVP интерпретирует этот код как обычное число.

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

    u = 0: RSVP отвергает сообщение без модификации локального состояния

    u = 1: RSVP может использовать сообщение для модификации локального состояния и для последующей пересылки. Это означает, что сообщение является информационным.

    r: зарезервированный бит, должен быть равен нулю.

    cccc cccc cccc: 12 битовый код.

    Следующие глобально-заданные субкоды могут появиться в младших 12 битах, когда ssur = 0000:

    - Субкод = 1: Предел (bound) по задержке не может быть обеспечен.
    - Субкод = 2: Запрашиваемая полоса пропускания недоступна.
    - Субкод = 3: MTU в flowspec больше чем MTU интерфейса.

    • Код ошибки = 02: Policy Control failure

    Сообщение резервирования или path было отвергнуто по административным причинам, например, не выполнены условия аутентификации, недостаточная квота и т.д.. Этот код ошибки может появиться в сообщении PathErr или ResvErr.

    Содержимое поля значение ошибки должно быть определено в будущем.

    • Код ошибки = 03: Нет информации о проходе для этого сообщения Resv. Нет состояния прохода для данной сессии. Сообщение Resv не может быть переслано.
    • Код ошибки = 04: Нет информации отправителя для этого сообщения Resv. Имеется состояние прохода для этой сессии, но оно не включает в себя записи отправителя, соответствующей дескриптору потока, который содержится в сообщении Resv. Сообщение Resv не может быть переслано.
    • Код ошибки = 05: Конфликт со стилем резервирования. Стиль резервирования конфликтует со стилем существующего состояния резервирования. Поле значение ошибки содержит младшие 16 бит вектора опций существующего стиля, с которым произошел конфликт. Сообщение Resv не может быть переслано.
    • Код ошибки = 06: Неизвестный стиль резервирования. Стиль резервирования неизвестен. Сообщение Resv не может быть переслано.
    • Код ошибки = 07: Конфликт портов места назначения. Появились сессии для одного и того же адреса места назначения с нулевым и ненулевым значением полей порта назначения. Этот код ошибки может появиться в сообщении PathErr или ResvErr.
    • Код ошибки = 08: Конфликт портов отправителя. Для одной и той же сессии имеются нулевые и ненулевые порты отправителя в сообщениях Path. Этот код ошибки может появиться только в сообщении PathErr.
    • Код ошибки = 09, 10, 11: (зарезервировано)
    • Код ошибки = 12: Привилегированное обслуживание. Запрос обслуживания, определенный объектом STYLE, и дескриптор потока были административно перехвачены.

    Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

    ssur cccc cccc cccc

    Ниже приведены значения старших бит ssur, как они определены при коде ошибки 01. Глобально-заданные субкоды, которые могут появиться в младших 12 битах, когда ssur = 0000 должны быть определены в будущем.

    • Код ошибки = 13: Неизвестный класс объекта. Этот код ошибки содержит 16-битовое слово, состоящее из (Class-Num, C-тип) неизвестного объекта. Эта ошибка должна быть послана только в случае, когда RSVP намеревается отвергнуть сообщение, как это определено старшими битами Class-Num. Этот код ошибки может появиться в сообщении PathErr или ResvErr.
    • Код ошибки = 14: Неизвестный объект C-типа. Значение ошибки содержит 6-битовый код, состоящий из (Class-Num, C-тип) объекта.
    • Код ошибки = 15-19: (зарезервировано)
    • Код ошибки = 20: Зарезервировано для API. Поле значение ошибки содержит код ошибки API, которая была обнаружена асинхронно и о которой необходимо уведомить систему соответствующим откликом.
    • Код ошибки = 21: Ошибка управления трафиком. Запрос управления трафиком не прошел из-за формата или содержимого параметров запроса. Сообщения Resv или Path, которые инициировали вызов, не могут быть пересланы, повторные вызовы бесполезны.

    Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

    ss00 cccc cccc cccc

    Ниже представлены значения старших бит ss, как это определено для кода ошибки 01.

    Следующие глобально-заданные субкоды могут появляться в младших 12 битах (cccc cccc cccc), когда ss = 00:

    • Субкод = 01: Конфликт сервиса. Попытка объединить два несовместимых запроса обслуживания.
    • Субкод = 02: Сервис не поддерживается. Управление трафиком не может обеспечить запрашиваемый сервис или его приемлемую замену.
    • Субкод = 03: Плохое значение Flowspec. Запрос неверного формата или неприемлемые требования.
    • Субкод = 04: Плохое значение Tspec. Запрос неверного формата или неприемлемых требований.
    • Субкод = 05: Плохое значение Adspec. Запрос неверного формата или неприемлемые требования.
    • Код ошибки = 22: Ошибка системы управления трафиком. Модули управления трафиком обнаружели системную ошибку. Значение ошибки будет содержать специфический для системы код, предоставляющий дополнительную информацию об ошибке. Предполагается, что RSVP не может интерпретировать его значение.
    • Код ошибки = 23: Системная ошибка RSVP

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

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

    Единственными ошибками формата сообщений, которые доводятся до сведения оконечной системы, являются несоответствия версии.

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

    • Неверная длина сообщения: Поле длины RSVP не соответствует реальной длине сообщения.
    • Неизвестная или неподдерживаемая версия RSVP.
    • Ошибка в контрольной сумме RSVP
    • Ошибка в INTEGRITY
    • Нелегальный тип сообщения RSVP
    • Нелегальная длина объекта: не кратна 4, или меньше 4 байт.
    • Адрес предыдущего/следующего узла в объекте HOP является нелегальным.
    • Неверный номер порта источника: Порт источника не равен нулю в спецификации фильтра или шаблоне отправителя для сессии с нулевым портом назначения.
    • Отсутствует необходимый класс объекта
    • Нелегальный класс объекта для данного типа сообщения.
    • Нарушение регламентируемого порядка объектов
    • Неверное число дескрипторов потока для данного типа сообщения или стиля
    • Неверный дескриптор логического интерфейса
    • Неизвестный объект Class-Num.
    • Адрес места назначения сообщения ResvConf не согласуется с адресом получателя в объекте RESV_CONFIRM.

    42. Приложение C. UDP-инкапсуляция

    Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы.

    Базовая схема UDP-инкапсуляции использует два предположения:

    1. Все ЭВМ способны посылать и получать мультикастные пакеты, если требуется поддержка мультикастных адресов назначения.
    2. Маршрутизаторы первого/последнего узлов должны поддерживать RSVP.

    Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов.

    Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов.

    В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'.

    Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'.

    В таблицах используются следующие символы.

    • D является портом назначения (DestAddress) конкретной сессии.
    • G* является стандартным групповым адресом формата 224.0.0.14, т.е., группа ограничена пределами локальной сети.
    • Pu и Pu' являются стандартными UDP-портами для UDP-инкапсуляции RSVP, с номерами 1698 и 1699.
    • Ra равен IP-адресу интерфейса маршрутизатора `a'.
    • Интерфейс маршрутизатора `a' локально доступен для Hu и Hr.

    Таблица 4.4.9.6.1. Правила UDP-инкапсуляции для уникастных сообщений Path и Resv
    (D - уникастный адрес места назначения; R - маршрутизатор; Raw - режим произвольных операций сетевого ввода/вывода.)

    Узел

    RSVP посылает

    RSVP получает

    Hu

    UDP(D/Ra,Pu) [1]

    UDP(D,Pu) и UDP(D,Pu') [2]

    Hr

    Raw(D)
    и, если (UDP),
    тогда UDP(D, Pu')

    RAW()
    и UDP(D, Pu) [2]
    (игнорировать Pu')

    R (интерфейс а)

    Raw(D)
    и, если (UDP),
    тогда UDP(D, Pu')

    RAW()
    и UDP(Ra, Pu)
    (игнорировать Pu')

    [1]

    Hu посылает уникастные сообщения Path либо по адресу D, если D является локальным, либо по адресу Ra маршрутизатора первого узла. Ra предполагается известным.

    [2]

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

    [3]

    Это предполагает, что приложение присоединилось к группе D.

    Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path

    Узел

    RSVP посылает

    RSVP получает

    Hu

    UDP(G*,Pu)

    UDP(D,Pu') [3] и UDP(G*,Pu)

    Hr

    Raw(D,Tr) и,
    если (UDP),
    тогда UDP(D, Pu')

    RAW()
    и UDP(G*, Pu)

    (игнорировать Pu')

    R (интерфейс а)

    Raw(D,Tr)
    и, если (UDP),
    тогда UDP(D, Pu')

    RAW()
    и UDP(G*, Pu)
    (игнорировать Pu')

    Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора.

    Когда получен UDP-инкапсулированный пакет, в большинстве систем TTL не доступно для приложения. Процесс RSVP, который получает UDP-инкапсулированное сообщение Path или PathTear должен использовать поле Send_TTL общего RSVP-заголовка для извлечения значения TTL. В тех случаях, когда это по каким-либо причинам не приемлемо, значение TTL может быть задано вручную при конфигурации.

    Мы предположили, что первый маршрутизатор, поддерживающий RSVP, подключен непосредственно к локальной сети. Существует несколько подходов в случае, когда это не так.

    1. Hu может запускать как уникастные, так и мультикастные сессии в UDP(Ra,Pu) с TTL=Ta. Здесь Ta должно быть достаточным, чтобы достичь R. Если Ta слишком мало, сообщение Path не дойдет до R. Если Ta слишком велико, R и последующие маршрутизаторы могут переправлять UDP-пакет до тех пор, пока не иссякнет запас по TTL. Это включит UDP-инкапсуляцию между маршрутизаторами в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Hu должна быть непосредственно сконфигурирована с использованием Ra и Ta.
    2. Конкретная ЭВМ локальной сети, соединенная с Hu может считаться "транспортной ЭВМ RSVP". Транспортная ЭВМ будет прослушивать (G*,Pu) и переправлять любое сообщение Path непосредственно R, хотя это и не будет маршрутом передачи данных. Транспортная ЭВМ должна быть сконфигурирована с использованием Ra и Ta.

    Библиография

    [Baker96]

    Baker, F., "RSVP Cryptographic Authentication", Work in Progress.

    [RFC 1633]

    Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994.

    [FJ94]

    Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994.

    [RFC 2207]

    Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.

    [RFC-2208]

    "Resource Reservation Protocol (RSVP) - Version 1. Applicability Statement".

    [RFC-2209]

    "Resource Reservation Protocol (RSVP) - Version 1.Message Processing Rules"

    [RFC 2113]

    Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997.

    [RFC 2210]

    Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997.

    [RFC-2211]

    "Specification of the Controlled-Load Network Element Service"

    [RFC-2212]

    "Specification of Guarantied Quality of Service"

    [PolArch96]

    Herzog, S., "Policy Control for RSVP: Architectural Overview". Work in Progress.

    [OPWA95]

    Shenker, S. and L. Breslau, "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.

    Previous: 4.4.9.5 Протокол PIM    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.9.7 Протокол COPS (Common Open Policy Service)


    previous up down next index index
    Previous: 4.4.9.7 Протокол COPS (Common Open Policy Service)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

    4.4.10 Протокол загрузки BOOTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В больших сетях некоторые рабочие станции (например, Х-терминалы) могут не иметь системного диска, а операционная система и сетевое программное обеспечение загружается через сеть. Для этого рабочая станция должна иметь стартовую программу, записанную в ПЗУ. Такое постоянное запоминающее устройство часто производится на фирме, изготовившей эту рабочую станцию, и по этой причине не содержат информации ни об адресе сервера, ни даже о своем IP-адресе. Выше был описан протокол RARP, который способен решать подобные задачи для случая, когда сервер находится в пределах данной локальной сети. Ведь RARP выдает широковещательный запрос на связном уровне, а он не ретранслируется маршрутизаторами. Более мощным средством для загрузки бездисковых станций является протокол BOOTP (Bootstrap протокол, RFC-951, -1048, -1532). BOOTP пригоден и для загрузки бездисковых маршрутизаторов. BOOTP в качестве транспортного использует UDP-протокол. ЭВМ-клиент (порт=68), которая хочет воспользоваться BOOTP, посылает широковещательное сообщение (по адресу = 255.255.255.255). Сервер (порт=67) в отличии от случая RARP не обязательно должен находиться в пределах данной локальной сети. В поле IP-адрес клиента будет записано 0.0.0.0, так как клиент пока не знает своего адреса. Получив запрос через порт 67, маршрутизатор помещает свой IP-адрес в поле IP-адрес маршрутизатора (см. формат запроса на рис. 4.4.10.1) и пересылает запрос действительному BOOTP-серверу, увеличив на 1 значение поля Hop#. По пути к серверу может быть несколько маршрутизаторов (но обычно не больше 3). Сервер не знает физического адреса клиента. Воспользоваться ARP-запросом он не может, так как клиент пока не знает своего IP-адреса и на ARP-запрос не откликнется. У сервера, получившего запрос, имеется две возможности.

    1. Проанализировать пакет, извлечь из него физический адрес клиента и скорректировать ARP-таблицу.
    2. Послать отклик, используя широковещательный адрес.

    Так как программа загрузки находится на прикладном уровне, и ей запрещено исправлять ARP-таблицы, реально доступен только второй путь. Использование разных номеров портов для сервера и клиента делает работу системы более эффективной. Когда отклик сервера является широковещательным, это позволяет не прерывать работу прикладных программ, работающих с номерами портов, отличными от 68 (порт Bootp-клиента). В Bootp ответственность за надежность связи лежит на ЭВМ-клиенте. При отсутствии отклика в отведенное время клиент повторяет Bootp-запрос. На IP-уровне, где данные не имеют контрольной суммы, целостность сообщения не гарантирована. Bootp требует, чтобы проверка контрольной суммы обязательно проводилась на UDP-уровне (следует заметить, что обычно это не является обязательным). Сервер читает UDP-дейтограммы через порт 67. Для повышения надежности обменов, как правило, блокируется фрагментация дейтограмм.

    Загрузка рабочих станций часто запускается броском напряжения сетевого питания. При этом несколько Bootp-процессов стартуют одновременно. Для того чтобы снизить вероятность столкновений, величина времени тайм-аута выбирается случайно в интервале 0-4сек. После каждого повторного запроса это время удваивается. Верхнее значение тайм-аута равно 60сек. Для справок время загрузки бездискового x-терминала при благоприятных условиях может составлять около 20 сек.

    bootp осуществляет загрузку в два этапа. На первом этапе bootp лишь снабжает клиента информацией, где лежит нужные ему данные. Далее ЭВМ-клиент использует протокол RFTP для получения искомого загружаемого файла. Bootp-сервер не обязательно должен работать на той же машине, где хранятся загружаемые файлы, но он должен знать их имена. Формат Bootp-сообщений представлен на рис. 4.4.10.1.

    Рис. 4.4.10.1. Формат сообщений BOOTP

    Поле операция=1 говорит о том, что данное сообщение запрос, а значение операция=2 указывает на то, что сообщение является откликом. Поля H-тип и Hlen определяют тип используемого оборудования и длину аппаратного адреса (для Ethernet H-тип=1, а HLen=6). ЭВМ-клиент кладет в поле Hop# (число шагов) нуль. Если BOOTP-сервер, получив запрос, решит передать его другой ЭВМ, он увеличит значение этого поля на 1, и так далее. Поле идентификатор операции содержит целое число, которое на бездисковых машинах позволяет связать в пары запросы и отклики. Поле секунды хранит время с момента начала процедуры загрузки (BOOT).

    ЭВМ-клиент заполняет все последующие поля, если она этой информацией владеет, в противном случае поля обнуляются. Возможность указания имени BOOT(загрузочного)-файла позволяет учесть индивидуальность конфигурации конкретной ЭВМ и пожелания относительно загружаемой операционной системы. Поле специфическая информация поставщика содержит информацию, которая передается от сервера к ЭВМ-клиенту. Первые 4 октета этого поля носят название "волшебное печенье" (magic cookie) и определяют формат остальных субполей. Если в указанном поле имеется информация, субполе волшебное печенье имеет значение 99.130.83.99. Вслед за этим субполем следует последовательность субполей, содержащих один октет тип, опционный октет длина и многооктетное субполе значение. Стандарт предусматривает следующие разновидности субполей:

    Таблица 4.4.10.1 Разновидности субполей и их коды (BOOTP)

    Тип субполя

    Код субполя

    Длина субполя в октетах

    Содержимое субполя

    Заполнитель

    0

    -

    Нули - используются для заполнения неиспользуемых полей

    Маска субсети

    1

    4

    Маска субсети в локальной сети

    Время дня

    2

    4

    Время дня по универсальной шкале

    Маршрутизаторы

    3

    N

    Список IP-адресов N/4 маршрутизаторов

    Временные серверы

    4

    N

    IP-адреса N/4 временных серверов

    IEN116 сервер

    5

    N

    IP-адреса N/4 IEN116 серверов

    Домейн-сервер

    6

    N

    IP-адреса N/4 DNS-серверов

    Log-сервер

    7

    N

    IP-адреса N/4 log-серверов

    Сервер квот

    8

    N

    IP-адреса N/4 серверов квот

    Сервер принтера

    9

    N

    IP-адреса N/4 серверов печати

    Impress

    10

    N

    IP-адреса N/4 impress-серверов

    RLP-сервер

    11

    N

    IP-адреса N/4 RLP серверов

    Имя ЭВМ

    12

    N

    N байтов имени ЭВМ-клиента

    Размер Boot-файла

    13

    2

    2-октетный размер boot-файла

    Зарезервировано

    128-254

    -

    Зарезервировано для местного применения

    Конец

    255

    -

    Конец списка

    Определены и другие субполя (RFC-1533), субполе конец (255) помечает конец поля. Хотя маска субсети может быть получена с помощью ICMP-запроса, стандарт требует, чтобы маска присылалась BOOT-сервером в ответ на каждый запрос, что исключает лишние ICMP-сообщения. Маска субсети может быть записана в поле специфическая информация поставщика, как это видно из таблицы. Время дня (тип=2) отсчитывается в секундах от 1-го января 1900 года. В новом протоколе DHCP (Dynamic Host Configuration Protocol, RFC-1531, протокол динамического конфигурирования системы) размер поля специфическая информация поставщика расширен до 312 байт.

    Previous: 4.4.9.7 Протокол COPS (Common Open Policy Service)    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)


    previous up down next index index
    Previous: 4.4.10 Протокол загрузки BOOTP    UP: 4.4 Интернет
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.1 Внутренний протокол маршрутизации RIP

    4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

    10

    86

    4.4.11.1 Внутренний протокол маршрутизации RIP

    5

    5

    4.4.11.2 Протокол OSPF (алгоритм Дикстры)

    16

    164

    4.4.11.3 Протокол IGRP

    7

    28

    4.4.11.4 Внешний протокол BGP

    10

    89

    4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)

    1

    4

    4.4.11.6 Автономные системы

    1

    4

    4.4.11.7 Маршрутная политика

    5

    17

    4.4.11.8 Язык описания маршрутной политики RPSL

    46

    196

    Основная задача сетей - транспортировка информации от ЭВМ-отправителя к ЭВМ-получателю. В большинстве случаев для этого нужно совершить несколько пересылок. Проблему выбора пути решают алгоритмы маршрутизации. Если транспортировка данных осуществляется дейтограммами, для каждой из них эта задача решается независимо. При использовании виртуальных каналов выбор пути выполняется на этапе формирования этого канала. В Интернет с его IP-дейтограммами реализуется первый вариант, а в ISDN - второй.

    Алгоритм маршрутизации должен обладать вполне определенными свойствами: надежностью, корректностью, стабильностью, простотой и оптимальностью. Последнее свойство не так прозрачно, как это может показаться на первый взгляд, все зависит от того, по какому или каким параметрам производится оптимизация. Эта задача иногда совсем не проста даже для сравнительно простых локальных сетей (смотри, например, рис. 4.4.11.1). Предположим, что поток данных между ЭВМ b и d, соединенных через концентратор (К) весьма высок, что окажет ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне это проявится лишь как повышенная задержка и пониженная пропускная способность участка А-С.

    Рис. 4.4.11.1

    Среди параметров оптимизации может быть минимальная задержка доставки, максимальная пропускная способность, минимальная цена, максимальная надежность или минимальная вероятность ошибки.

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

    Практически все методы маршрутизации базируются на следующем утверждении (принцип оптимальности). Если маршрутизатор M находится на оптимальном пути от маршрутизатора I к маршрутизатору J, тогда оптимальный путь от М к J проходит по этому пути. Чтобы убедиться в этом обозначим маршрут I-M R1, а m-j - R2. Если существует маршрут оптимальнее, чем R2, то он должен быть объединен с R1, чтобы образовать более оптимальный путь I-J, что противоречит исходному утверждению об оптимальности пути J-J. Следствием принципа оптимальности является утверждение, что оптимальные маршруты от всех отправителей к общему месту назначения образуют дерево, лишенное циклов (см. разделы "Протокол ospf" и "Элементы теории графов"). Такое дерево (называется sink tree) может быть не единственным, могут существовать другие деревья с теми же длинами пути. А это, в свою очередь означает, что любой пакет будет доставлен за строго ограниченное время, пройдя однократно определенное число маршрутизаторов

    Главным параметром при маршрутизации пакета в Интернет является ip-адрес его места назначения. Проблема оптимальной маршрутизации в современном Интернет, насчитывающем уже более десяти миллионов узлов, весьма сложна. Полная таблица маршрутов может содержать 107! записей (здесь ! означает знак факториала, а не выражение эмоций), что не по плечу не только сегодняшним ЭВМ.

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

    IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ (host), последние, как правило, не рассылают свои маршрутные таблицы. Предполагается, что маршрутизатор владеет исчерпывающей информацией о правильных маршрутах (хотя это и не совсем так). Обычная ЭВМ имеет минимальную маршрутную информацию (например, адрес маршрутизатора локальной сети и сервера имен). Автономная система может содержать множество маршрутизаторов, но взаимодействие с другими as она осуществляет только через один маршрутизатор, называемый пограничным (border gateway, именно он дал название протоколу bgp). Пограничный маршрутизатор нужен лишь тогда, когда автономная система имеет более одного внешнего канала, в противном случае его функции выполняет порт внешнего подключения (gateway). Если адресат достижим более чем одним путем, маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина - оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие - по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях часто используется вектор расстояния, исключающий субъективность оценок метрики.

    Помимо классической схемы маршрутизации по адресу места назначения, часто используется вариант выбора маршрута отправителем (данный вариант получил дальнейшее развитие при введении стандарта IPv6). В этом случае IP-пакет содержит соответствующий код опции и список промежуточных адресов узлов, которые он должен посетить по пути к месту назначения.

    Существуют и другие схемы, например, использующие широковещательные методы адресации (flooding), где каждый приходящий пакет посылается по всем имеющимся исходящим каналам, за исключением того, по которому он получен. С тем чтобы исключить беспредельное размножение пакетов в заголовок вводится поле-счетчик числа шагов. В каждом узле содержимое поле уменьшается на единицу. Когда значение поля становится равным нулю, пакет ликвидируется. Исходное значение счетчика определяется размером субсети. Предпринимаются специальные меры против возможного зацикливания пакетов. Существует усовершенствованная версия широковещательной маршрутизации, называемая селективной широковещательной рассылкой. В этом алгоритме рассылка производится не по всем возможным направлениям, а только по тем, которые предположительно ведут в правильную сторону. Широковещательные методы не относятся к широко применимым. Но они используются там, где нужна предельно возможная надежность, например в военных приложениях, когда весьма вероятно повреждение тех или иных каналов. Данные методы могут использоваться лишь при формировании виртуального канала, ведь они всегда обеспечивают наикратчайший путь, так как перебираются все возможности. Если путь записывается в пакете, получатель может выбрать оптимальный проход и уведомить об этом отправителя.

    Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flow-based routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета. Исходными данными при расчете считается описание топологии связей, матрица трафика для всех узлов Ti,j (в пакетах в секунду) и матрица пропускных способностей каналов Bi,j в битах в секунду. Задержка t для каждой из связей оценивается по формуле

    t i,j = 1/(p*bi,j - ti,j),

    где 1/Р - среднее значение ширины пакета в битах, произведение p*bi,j выражается в пакетах в секунду, а t измеряется в мсек. Сформировав матрицу t i,j, можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает.

    Статические протоколы (примером реализации статических протоколов может служить первая версия маршрутизатора Netblazer) предполагают, что любые изменения в маршрутные таблицы вносит администратор сети. Рассмотрим для примера сеть, изображенную на рис. 4.4.11.2.

    Рис. 4.4.11.2 Схема для иллюстрации методики составления маршрутных таблиц.
    g1, g2, g3 - Маршрутизаторы

    Примитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора g2):

    Сеть-адресат

    Маршрут к этой сети

    193.0.0.0

    Прямая доставка

    193.148.0.0

    Прямая доставка

    192.0.0.0

    Через адрес 193.0.0.1

    192.166.0.0

    Через адрес 193.148.0.7

    Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала ищется маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может повлечь серьезные последствия. Экономия на памяти для маршрутных таблиц - дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США, я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который используется лишь для формирования маршрутной таблицы. Описание алгоритма выбора маршрута представлено ниже:

    Извлечь IP-адрес (ID) места назначения из дейтограммы.

    Вычислить IP-адрес сети назначения (IN)
    IF INсоответствует какому-либо адресу локальной сети, послать дейтограмму по этому адресу;
    else if in присутствует в маршрутной таблице, то послать дейтограмму к серверу, указанному в таблице;
    else if описан маршрут по умолчанию, то послать дейтограмму к этому серверу;
    else выдать сообщение об ошибке маршрутизации.

    Если сеть включает в себя субсети, то для каждой записи в маршрутной таблице производится побитная операция <И> для ID и маски субсети. Если результат этой операции совпадет с содержимым адресного поля сети, дейтограмма посылается серверу субсети. На практике при наличии субсетей в маршрутную таблицу добавляются соответствующие записи с масками и адресами сетей.

    Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет backbone (опорная сеть), к которой подключаются узловые маршрутизаторы. Любая as подключается к backbone через узловой маршрутизатор.

    "Прозрачные" backbone не работают с адресами класса С (все объекты такой сети должны иметь один адрес, а для c-класса число объектов слишком ограничено). "Прозрачные" мосты трудно диагностировать, так как они не следуют протоколу ICMP (команда ping не работает, в последнее время такие объекты снабжаются snmp-поддержкой). За то они позволяют перераспределять нагрузку через несколько маршрутизаторов, что невозможно для большинства протоколов.

    Рис. 4.4.11.3.

    В примере, приведенном на рис. 4.4.11.3, задача маршрутизации достаточно сложна. ЭВМ1,2 и ЭВМ6,1 можно связать многими путями: ЭВМ1,2 - GW1 - ЭВМ6,1; ЭВМ1,2 - GW2 - ЭВМ6,1; ЭВМ1,2 - GW3 - ЭВМ6,1; ЭВМ1,2 - GW4 - ЭВМ6,1; ЭВМ1,2 - GW1 - GW2 - GW3 - ЭВМ6,1; и т.д. Трафик между двумя географически близкими узлами должен направляться кратчайшим путем, вне зависимости от направления глобальных потоков. Так ЭВМ1,2 и ЭВМ1,1 должны соединяться через GW1. Маршрутизация через опорные сети (backbone) требует индивидуального подхода для каждого узла. Администраторы опорных сетей должны согласовывать свои принципы маршрутизации. Ситуация, когда узел не владеет исчерпывающей маршрутной информацией, в сочетании с использованием маршрутов по умолчанию может привести к зацикливанию пакетов. Например, если маршрут по умолчанию в GW1 указывает на GW2, а в GW2 на GW1, то пакет с несуществующим адресом будет циркулировать между gw1 и gw2 пока не истечет ttl (время жизни пакета), полностью блокируя канал. По этой причине желательно иметь полную таблицу маршрутизации, и, если не вынуждают обстоятельства, избегать использования маршрутов по умолчанию.

    Рис. 4.4.11.4.

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

    Динамические протоколы (обычно используются именно они, наиболее известным разработчиком является компания CISCO):

    В маршрутизаторе с динамическим протоколом (например, BGP-4) резидентно загруженная программа-драйвер изменяет таблицы маршрутизации на основе информации, полученной от соседних маршрутизаторов. В ЭВМ, работающей под UNIX и выполняющей функции маршрутизатора, эту задачу часто решает резидентная программа gated или routed (демон). Последняя - поддерживает только внутренние протоколы маршрутизации.

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

    Любая автономная система (AS, система маршрутизаторов, ЭВМ или сетей, имеющая единую политику маршрутизации) может выбрать свой собственный протокол маршрутизации.

    Внутренний протокол маршрутизации IGP (Interior Gateway Protocol) определяет маршруты внутри автономной системы. Наиболее популярный IGP - RIP (Routing Information Protocol, RFC-1058), разработан Фордом, Фулкерсоном и Белманом (фирма XEROX). Существует более новый протокол OSPF (Open Shortest Pass First, RFC-1131, -1245, -1247, -1253). Наиболее старые системы (IGP) используют протокол HELLO. Протокол HELLO поддерживался фирмой DEC, в качестве метрики он использует время, а не число шагов до цели. Для взаимодействия маршрутизаторов используются внешние протоколы (EGP - Exterior Gateway Protocols).

    Одной из разновидностей EGP является протокол BGP (Border Gateway Protocol, RFC-1268 [BGP-3], RFC-1467 [BGP-4]).

    Протокол IGRP (Interior Gateway Routing Protocol) разработан компанией CISCO для больших сетей со сложной топологией и сегментами, которые обладают различной полосой пропускания и задержкой. Это внутренний протокол маршрутизации имеет некоторые черты сходства с OSPF.

    IGRP использует несколько типов метрики, по одной на каждый вид QOS. Метрика характеризуется 32-разрядным числом. В однородных средах этот вид метрики вырождается в число шагов до цели. Маршрут с минимальным значением метрики является предпочтительным. Актуализация маршрутной информации для этого протокола производится каждые 90 секунд. Если какой-либо маршрут не подтверждает своей работоспособности в течение 270 сек, он считается недоступным. После семи циклов (630 сек) актуализации такой маршрут удаляется из маршрутных таблиц. IGRP аналогично OSPF производит расчет метрики для каждого вида сервиса (TOS) отдельно.

    Протокол IDPR (InterDomain Policy Routing Protocol, RFC-1477, -1479) представляет собой разновидность BGP-протокола. Протокол IS-IS (Intermediate System to Intermediate System Protocol, RFC-1195, -1142) является еще одним внутренним протоколом, который используется для маршрутизации CLNP (Connectionless Network Protocol, RFC-1575, -1561, -1526). IS-IS имеет много общего с OSPF. Смотри также бесклассовый протокол маршрутизации CIDR .

    Сразу после включения маршрутизатор не имеет информации о возможностях соседних маршрутизаторов. Статичесикие маршрутные таблицы могут храниться в постоянной памяти или загружаться из какого-то сетевого сервера. По этой причине первейшей задачей маршрутизатора является получение маршрутной информации от соседей, а для начала выявление наличия соседей и их адресов. Для этой цели посылается специальный пакет Hello через каждый из своих внешних интерфейсов. В ответ предполагается получить отклик, содержащий идентификационную информацию соответствующего маршрутизатора. Когда два или более маршрутизаторов объединены через локальную сеть, ситуация несколько усложняется. Смотри рис. 4.4.11.5. Маршрутизаторы E, F, G и H подключены непосредственно к локальной сети, некоторые из них имеют связи с другими маршрутизаторами (сети, которые они обслуживают, на рисунке не показаны).

    Одним из способов смоделировать локальную сеть - рассматривать маршрутизаторы E, F, G и H, как соединеные непосредственно, введя виртуальный узел сети L (выделен зеленым цветом). На правой части рисунка показан граф такой сети. Возможность прохода из узла F к G обозначена путем FLG. Для протоколов, учитывающих состояние канала, желательно иметь исчерпывающую информацию о нем (загрузка, задержка, пропускная способность, надежность, стоимость и т.д.). Некоторые из перечисленных параметров довольно легко измерить, например, задержку. Для этого вполне пригоден протокол ICMP. К сожалению многие из указанных параметров довольно сильно коррелированы и подвержены флуктуациям. В частности результаты измерения задержки зависят от загрузки канала (вариация времени ожидания в очереди).

    Рис. 4.4.11.5. Маршрутизаторы, подключенные к локальной сети

    Рассмотрим трафик на пути А-Н. Допустим на основании анализа состояния канал выбран путь через узел Е. В этом случае он может оказаться перегружен, что приведет к большим задаржкам пакетов на пути А-Н. Последующий анализ ситуации может привести к тому, что более оптимальным может оказаться маршрут через узел F. Если будет принято решение переключить трафик на маршрут ACFH, может перегрузиться участок АСF и история повторится. Данный сценарий описывает типичную ситуацию с осцилляциями маршрута. Осцилляции маршрутов не так безобидны, как это может показаться. Маршрутные таблицы в маршрутизаторах актуализуются вдоль пути с заметными задержками и отнюдь не синхронно. Такие осцилляции могут в разы понизить пропускную способность сети, что необходимо учитывать, выбирая параметры протоколов маршрутизации.

    К сожалению многие современные протоколы маршрутизации не имеют встроенных средств аутентификации (контроля доступа), что делает их уязвимыми для различных злоупотреблений.

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

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

    Предполагается, что все эти пользователи имеют свою постоянную приписку к какой-то сети и соответствующий постоянный IP-адрес. (см. RFC-2794 "Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000). На рис. 4.4.11.6 показана схема подключения подвижных пользователей к Интернет. В этой схеме предполагается наличие в каждой области сети Интернет внешнего агента, обеспечивающего доступ к этой зоне подвижных ЭВМ (на рисунке такой агент помечен надписью "чужая LAN"). Доступ может осуществляться через мобильную телефонную сеть. Предполагается также наличие соответствующего агента в "домашней" LAN, куда стационарно приписана данная ЭВМ. Домашний агент отслеживает все перемещения своих пользователей, в том числе и тех, кто подключается к "чужим" LAN.

    Рис. 4.4.11.6. Схема подключения к Интернет подвижных объектов

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

    1. Каждый внешний агент периодически широковещательно рассылает пакет-сообщение, содержащее его IP-адрес. "Вновь прибывшая ЭВМ" может подождать такого сообщения или сама послать широковещательный запрос наличия внешнего агента.
    2. Мобильный пользователь регистрируется внешним агентом, сообщая ему свой IP- и MAC-адрес, а также некоторые параметры системы безопасности.
    3. Внешний агент устанавливает связь с LAN постоянной приписки зарегистрированного мобильного пользователя, сообщая необходимую адресную информацию и некоторые параметры аутентификации.
    4. Домашний агент анализирует параметры аутентификации и, если все в порядке, процедура установления связи будет продолжена.
    5. Когда внешний агент получает положительный отклик от домашнего агента, он сообщает мобильной ЭВМ, что она зарегистрирована.

    Когда пользователь покидает зону обслуживания данной LAN или MAN, регистрация должна быть анулирована, а ЭВМ должна быть автоматически зарегистрирована в новой зоне. Когда посылается пакет мобильному пользователю, "домашняя LAN", получив его, маршрутизирует пакет внешнему агенту, зарегистрировавшему данного пользователя. Этот агент переправит пакет адресату.

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

    В локальных или корпоративных сетях иной раз возникает необходимость разослать некоторую информацию всем остальным ЭВМ-пользователям сети (штормовое предупреждение, изменение курса акций и т.д.). Отправителю достаточно знать адреса всех N заинтересованных пользователей и послать им соответствующее сообщение. Данная схема крайне не эффективна, ведь обычная широковещательная адресация предлагает решение в N раз лучше с точки зрения загрузки сети (посылается одно а не N сообщений). Широковещательная адресация сработает, если в локальной сети нет маршрутизаторов, в противном случае широковещательные адреса МАС-типа заменяются на IP-адреса (что, впрочем, не слишком изящное решение) или применяется мультикастинг адресация. Маршрутизация для мультикастинга представляет собой отдельную задачу. Ведь здесь надо проложить маршрут от отправителя к большому числу получателей. Традиционные методы маршрутизации здесь применимы, но до крайности не эффективны. Здесь для целей выбора маршрута можно с успехом применить алгоритм "расширяющееся дерево" (spanning tree; не имеет циклических структур). Когда на вход маршрутизатора приходит широковещательный пакет, он проверяет, является ли интерфейс, через который он пришел, оптимальным направлением к источнику пакета. Если это так, пакет направляется через все внешние интерфейсы кроме того, через который он пришел. В противном случае пакет игнорируется (так как скорее всего это дубликат). Этот алгоритм называется Reverse Path Forwarding (переадресация в обратном направлении). Пояснение работы алгоритма представлено на рис. 4.4.11.7 (прямоугольниками на рис. обозначены маршрутизаторы). Секция I характеризует топологию сети. Справа показано дерево маршрутов для маршрутизатора I (sink tree). Секция III демонстрирует то, как работает алгоритм Reverse Path Forwarding. Сначала I посылает пакеты маршрутизаторам B, F, H, J и L. Далее посылка пакетов определяется алгоритмом.

    Рис. 4.4.11.7. Алгоритм Reverse Path Forwarding

    При передаче мультимедиа информации используются принципиально другие протоколы маршрутизации. Здесь путь прокладывается от получателя к отправителю, а не наоборот. Это связано с тем, что там при доставке применяется мультикастинговый метод. Здесь, как правило, один отправитель посылает пакеты многим потребителям. При этом важно, чтобы размножение пакета происходило как можно ближе к кластеру адресатов. Такая стратегия иной раз удлинняет маршрут, но всегда снижает результирующую загрузку сети. Смотри описания протоколов DVMRP и PIM.

    В последнее время конфигурирование сетевого оборудования (маршрутизаторов, DNS и почтовых серверов усложнилось нкастолько, что это стало составлять заметную часть издержек при формировании коммуникационного узла. Заметного упрощенияи удешевления маршрутизаторов можно ожидать при внедрении IPv6. Следующим шагом станет внедрение объектно-ориентированного языка описания маршрутной политики RPSL (Routing Policy Specification Language). Здесь конфигурирование маршрутизатора будет осуществляться на основе описанной маршрутной политики.

    Теперь немного подробнее о наиболее популярных протоколах маршрутизации - RIP, OSPF, IGRP и BGP-4. Начнем с внутреннего протокола маршрутизации RIP.

    Previous: 4.4.10 Протокол загрузки BOOTP    UP: 4.4 Интернет
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.1 Внутренний протокол маршрутизации RIP


    previous up down next index index
    Previous: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.2 Протокол OSPF (алгоритм Дикстры)

    4.4.11.1 Внутренний протокол маршрутизации RIP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC Unix (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:

    IP-адрес места назначения.
    Метрика маршрута (от 1 до 15; число шагов до места назначения).
    IP-адрес ближайшего маршрутизатора (gateway) по пути к месту назначения.
    Таймеры маршрута.

    Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначение - направление; метрика - модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:

    1. Циклические маршруты. Так как в протоколе нет механизмов выявления замкнутых маршрутов, необходимо либо слепо верить партнерам, либо принимать меры для блокировки такой возможности.
    2. Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (<16).
    3. Медленное распространение маршрутной информации по сети создает проблемы при динамичном изменении маршрутной ситуации (система не поспевает за изменениями). Малое предельное значение метрики улучшает сходимость, но не устраняет проблему.

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


    Рис. 4.4.11.1. Иллюстрация, поясняющее возникновение циклических маршрутов при использовании вектора расстояния.

    На верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети в соответствии со стрелками. На нижней части связь на участке GW1 <Сеть a> оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. При этом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так после очередного обмена путь от gw2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, а это займет слишком много циклов обмена маршрутной информацией.

    Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки, перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации. Но все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть. Именно малая скорость установления маршрутов в RIP (и других протоколах, ориентированных на вектор расстояния) и является причиной их постепенного вытеснения другими протоколами.

    Но даже усовершенствование, изложенное выше, не всегда срабатывает. На рис. 4.4.11.1а приведен пример, когда переходной процесс, несмотря на усовершенствование будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г, характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности".


    Рис. 4.4.11.1а. Пример топологии, где переходной процесс осуществляется медленно, даже при усовершенствовании алгоритма.

    В RIP сообщения инкапсулируются в udp-дейтограммы, при этом передача осуществляется через порт 520. В качестве метрики RIP использует число шагов до цели. Если между отправителем и приемником расположено три маршрутизатора (gateway), считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.

    Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом, блокируется возможность осцилляции между двумя или более равноценными маршрутами. Формат сообщения протокола RIP имеет вид, показанный на рис. 4.4.11.2. Поле команда определяет выбор согласно следующей таблице:

    Таблица 4.4.11.1. Значения кодов поля команда

    Команда

    Значение

    1

    Запрос на получение частичной или полной маршрутной информации;

    2

    Отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя;

    3

    Включение режима трассировки (устарело);

    4

    Выключение режима трассировки (устарело);

    5-6

    Зарезервированы для внутренних целей sun microsystem.

    Поле версия для RIP равно 1 (для RIP-2 двум). Поле набор протоколов сети i определяет набор протоколов, которые используются в соответствующей сети (для Интернет это поле имеет значение 2). Поле расстояние до сети i содержит целое число шагов (от 1 до 15) до данной сети. В одном сообщении может присутствовать информация о 25 маршрутах. При реализации RIP можно выделить следующие режимы:

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

    Получен запрос. В зависимости от типа запроса высылается адресату полная таблица маршрутизации, или проводится индивидуальная обработка.

    Получен отклик. Проводится коррекция таблицы маршрутизации (удаление, исправление, добавление).

    Рис. 4.4.11.2. Формат сообщения RIP.

    Регулярные коррекции. Каждые 30 секунд вся или часть таблицы маршрутизации посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению не лишенный недостатков:

    1. RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли не нулевая часть cубсетевым ID, или полным IP-адресом.
    2. RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы.
    3. Число шагов важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.

    Протокол RIP-2 (RFC-1388, 1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей. На рис. 4.4.11.3 представлен формат сообщения для протокола RIP-2. Поле маршрутный демон является идентификатором резидентной программы-маршрутизатора. Поле метка маршрута используется для поддержки внешних протоколов маршрутизации, сюда записываются коды автономных систем. При необходимости управления доступом можно использовать первые 20 байт с кодом набора протоколов сети 0xFFFF и меткой маршрута =2. Тогда в остальные 16 байт можно записать пароль.

    Рис. 4.4.11.3 Формат сообщений протокола RIP-2

    Проблемы аутентификации в протоколе RIP-2 c использованием дайджестов MD5 обсуждаются в документе RFC-2082

    Previous: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.2 Протокол OSPF (алгоритм Дикстры)


    previous up down next index index
    Previous: 4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.7 Маршрутная политика

    4.4.11.6 Автономные системы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Базовым элементом технологии Интернет является модуль IP. Его центральной частью является таблица маршрутов, используемая для принятия решения о направлении IP-пакета по тому или иному пути. Формат таблицы маршрутов задается используемым протоколом маршрутизации, а содержание - определяет администратор сети. Прямая маршрутизация имеет место при обмене пакетами между машинами, входящими в одну сеть. Большинство современных протоколов маршрутизации являются динамическими, то есть такими, где таблицы маршрутизации изменяются по мере изменения структуры и параметров окружающей сети. Такие протоколы заметно повышают надежность сети в целом, так как при выходе из строя какого-либо узла или канала связи поток пакетов может быть автоматически направлен в обход по резервному маршруту. При этом пользователи сети не должны ожидать момента, когда администратор сети вернется из отпуска, проснется или вернется из кафетерия и сам внесет необходимые коррективы.

    Автономной системой называют такую локальную сеть или систему сетей, которые имеют единую администрацию и общую маршрутную политику.

    Пользователь, связанный только с одним сервис-провайдером, должен принадлежать к общей с ним AS. Автономная система должна обязательно создаваться, когда оператор сети связан с более чем одной AS с отличной от его маршрутной политикой. Если же пользователь обращается к услугам двух или более сервис-провайдеров, придерживающихся различных маршрутных политик, то он должен создать свою независимую AS. Общим правилом является использование максимально возможного числа маршрутов. Это повышает надежность и способствует перераспределению нагрузки между каналами.

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

    Previous: 4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.7 Маршрутная политика


    previous up down next index index
    Previous: 4.4.2 Протокол UDP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)

    4.4.3 Протокол TCP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол TCP (transmission control protocol, RFC-793, -1323) в отличии от udp осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установлением соединения. Протокол TCP применяется в тех случаях, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимости таймаутов и повторных передач для обеспечения надежности. Для отслеживания подтверждения доставки в TCP реализуется алгоритм "скользящего" окна. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (file transfer protocol - протокол передачи файлов) и telnet. Кроме того, TCP используют системы SMTP, HTTP, X-windows, RCP (remote copy), а также "r"-команды. Внутренняя структура модуля TCP гораздо сложнее структуры UDP. Подобно UDP прикладные процессы взаимодействуют с модулем TCP через порты (см. таблицу 4.4.2.1 в предыдущей главе). Под байтовыми потоками здесь подразумевается то, что один примитив, например, read или write (см. раздел "Программирование для сетей") может вызвать посылку адресату последовательности сегментов, которые образуют некоторый блок данных (сообщение).

    Примером прикладного процесса, использующего ветвь TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль согласно коду, записанному в поле протокола данного IP-пакета. Формат сегмента (пакета) tcp представлен ниже на рис. 4.4.3.1.

    Если IP-протокол работает с адресами, то TCP, также как и UDP, с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента. Поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя. При значении флага syn=1 в этом поле лежит код isn (смотри ниже описание процедуры установления связи). Поле HLEN - определяет длину заголовка сегмента, которая измеряется в 32-разрядных словах. Далее следует поле резерв, предназначенное для будущего использования, в настоящее время должно обнуляться. Поле размер окна сообщает, сколько октетов готов принять получатель (флаг ACK=1). Окно имеет принципиальное значение, оно определяет число сегментов, которые могут быть посланы без получения подтверждения. Значение ширины окна может варьироваться во время сессии (смотри описание процедуры "медленного старта"). Значение этого поля равное нулю также допустимо и указывает, что байты вплоть до указанного в поле номер октета, который должен прийти следующим, получены, но адресат временно не может принимать данные. Разрешение на посылку новой информации может быть дано с помощью посылки сегмента с тем же значением поля номер октета, который должен прийти следующим, но ненулевым значением поля ширины окна. Поле контрольная сумма предназначено для обеспечения целостности сообщения. Контрольное суммирование производится по модулю 1. Перед контрольным суммированием к TCP-сегменту добавляется псевдозаголовок, как и в случае протокола udp, который включает в себя адреса отправителя и получателя, код протокола и длину сегмента, исключая псевдозаголовок. Поле указатель важной информации представляет собой указатель последнего байта, содержащий информацию, которая требует немедленного реагирования. Поле имеет смысл лишь при флаге URG=1, отмечающем сегмент с первым байтом "важной информации". Значение разрядов в 6-битовом коде (флаги) описано в таблице 4.4.3.1. Если флаг ACK=0, значение поля номер октета, который должен прийти следующим, игнорируется. Флаг urg=1 в случае нажатия пользователем клавиш Del или Ctrl-c.

    Таблица 4.4.3.1 Значения бит поля флаги

    Обозначение битов (слева на право) поля флаги

    Значение бита, если он равен 1

    urg

    Флаг важной информации, поле Указатель важной информации имеет смысл, если urg=1.

    ack

    Номер октета, который должен прийти следующим, правилен.

    psh

    Этот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее.

    rst

    Прерывание связи.

    syn

    Флаг для синхронизации номеров сегментов, используется при установлении связи.

    fin

    Отправитель закончил посылку байтов.

    Рис. 4.4.3.1 Формат TCP-сегмента

    Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер переменен и дополняется до кратного 32-бит с помощью поля заполнитель. Формат поля опции представлен на рис. 4.4.3.2. В настоящее время определены опции:

    0 Конец списка опций.
    1 Никаких операций. Используется для заполнения поля опции до числа октетов, кратного 4.
    2 Максимальный размер сегмента (MSS).

    В поле вид записывается код опции, поле LEN содержит число октетов в описании опции, включая поля вид и LEN. Определены также опции со значением вид=4,5,6,7. В предложении T/TCP (RFC-1644) описаны опции 11, 12 и 13.

    Рис. 4.4.3.2. Формат опций для TCP-сегментов

    Поле данные в TCP-сегменте может и отсутствовать, характер и формат передаваемой информации задается исключительно прикладной программой, максимальный размер этого поля составляет в отсутствии опций 65495 байт. TCP является протоколом, который ориентируется на согласованную работу ЭВМ и программного обеспечения партнеров, участвующих в обмене информацией. Установление связи клиент-сервер осуществляется в три этапа:

    1. Клиент посылает SYN-сегмент с указанием номера порта сервера, который предлагается использовать для организации канала связи (active open).
    2. Сервер откликается, посылая свой SYN-сегмент, содержащий идентификатор (ISN - initial sequence number). Начальное значение isn не равно нулю. Процедура называется passive open.
    3. Клиент отправляет подтверждение получения syn-сегмента от сервера с идентификатором равным ISN (сервера)+1.

    Стандартная процедура установления связи представлена на рисунке 4.4.3.3 (под словом "стандартная" подразумевается отсутствие каких-либо отклонений от штатного режима, например, одновременного открывание соединения со стороны сервера и клиента). Если же соединение одновременно инициируется клиентом и сервером, в конечном итоге будет создан только один виртуальный канал.

    Рис. 4.4.3.3. Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения (см. также рис. 4.4.3.4)

    Префикс S на рисунке указывает на сервер, а С - на клиента. Параметры в скобках обозначают относительные значения ISN. После установления соединения ISN(S) = s_seq_1, а ISN(C) = c_seq_1.

    Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д.; см. также RFC-793), переход между которыми строго регламентирован. Машина состояний для протокола TCP может быть описана диаграммой, представленной на рис. 4.4.3.4. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd.

    В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind - ширина окна для сервера; см. рис. 4.4.3.5). Аналогичный диапазон isn для клиента выглядит как: c_ack, c_ack+c_wind (c_wind - ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены.

    Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/cis694q). Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения показан ниже (см. рис. 4.4.3.3):

    c -> s:syn(isnc)
    s -> c:syn(isns), ack(isnc)
    c -> s: ack(isns) (Связь установлена)
    c -> s: данные
    и/или
    s -> c: данные

    isn - идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав syn серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет не существует. В этом читатель, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных попыток (это, слава богу, не война и все обходится без людских жертв).

    Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает s syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол tcp допускает и другие виды атак (некоторые из них описаны в разделе "Сетевая безопасность"), там же рассмотрены алгоритмы задания и изменения ISN.

    Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва связи проще его рассматривать как два полудуплексных канала, каждый из которых каналов ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN, сообщая этим партнеру, что не намерен более что-либо передавать. Когда получение этого сегмента будет подтверждено (ACK), данное направление передачи считается ликвидированным. При этом передача информации в противоположном направлении может беспрепятственно продолжаться. Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По получении отклика ACK виртуальный канал считается окончательно ликвидированным. Таким образом, для установление связи требуется обмен тремя сегментами, а для разрыва - четырьмя. Но протокол допускает совмещение первого ACK и второго FIN в одном сегменте, сокращая полное число закрывающих сегментов с четырех до трех.

    Машина состояний для протокола TCP не предусматривает изменения состояний при посылке или получении обычных пакетов, содержащих данные.

    Рис. 4.4.3.4. Машина состояний для протокола tcp (W.R. Stivens, TCP/IP Illustrated. V1. Addison-Wesley publishing company. 1993.)

    Когда оператор, работая в диалоговом режиме, нажимает командную клавишу, сегмент, в который помещается эта управляющая последовательность, помечается флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще какой-либо информации. Сходную функцию выполняет флаг URG. URG позволяет выделить целый массив данных, так как активизирует указатель последнего байта важной информации. Будет ли какая-либо реакция на эту "важную" информацию определяет прикладная программа получателя. urg-режим используется для прерываний при работе с FTP, telnet или rlogin. Если до завершения обработки "важной" информации придет еще один сегмент с флагом URG, значение старого указателя конца "важного" сообщения будет утеряно. Это обстоятельство должно учитываться прикладными процессами. Так telnet в командных последовательностях всегда помещает префиксный байт с кодом 255.

    В режиме удаленного терминала (telnet) при нажатии любой клавиши формируется и поcылается 41-октетный сегмент (здесь не учитываются издержки ethernet), который содержит всего один байт полезной информации. Эффективность работы может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предложил при однобайтовом обмене посылать первый байт, а последующие буферизовать до прихода подтверждения получения посланного. После этого посылаются все буферизованные октеты, а запись в буфер вводимых кодов возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот алгоритм позволяет заметно понизить загрузку канала. Встречаются, впрочем, случаи, когда алгоритм Нагля желательно отключить, например, при работе в Интернет в режиме Х-терминала, где сигналы перемещения мышки должны пересылаться немедленно, чтобы не ввести в заблуждение пользователя относительно истинного положения маркера.

    Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня.

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

    Предполагается, что получатель пакета практически всегда посылает отправителю пакет-отклик. Отправитель может послать очередной пакет, не дожидаясь получения подтверждения для предшествующего. Таким образом, может быть послано k пакетов, прежде чем будет получен отклик на первый пакет (протокол "скользящего окна"). В протоколе tcp "скользящее окно" используется для регулировки трафика и препятствия переполнения буферов. Идея скользящего окна отображена на рис. 4.4.3.5. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).

    Рис. 4.4.3.5. Схема использования скользящего окна

    После прихода отклика на пакет <1> окно смещается вправо на одну позицию. Теперь отправитель может послать и пакет <8>. Если порядок прихода откликов нарушается, сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением:

    window > RTT*B/MSS,

    где B - полоса пропускания канала в бит/с, а MSS - максимальный размер сегмента в битах, а window - в сегментах.

    Для протокола TCP механизм скользящего окна может работать на уровне октетов или сегментов. В первом случае нужно учитывать каждый раз размер поля данных переданного и подтвержденного сегмента. В TCP-протоколе используется три указателя (стрелки на рис. 4.4.3.3б):

    Первый указатель определяет положение левого края окна, отделяя посланный сегмент, получивший подтверждение, от посланного сегмента, получение которого не подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент, который может быть послан до получения очередного подтверждения. Третий указатель помечает границу внутри скользящего окна между уже посланными сегментами и теми, которые еще предстоит послать. Получатель организует аналогичные окна для обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2, отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два полученных сегмента.

    Регулирование трафика в TCP подразумевает существование двух независимых процессов: контроль доставки, управляемый получателем с помощью параметра window, и контроль перегрузки, управляемый отправителем с помощью окна перегрузки cwnd (congestion window) и ssthreth (slow start threshold). Первый процесс отслеживает заполнение входного буфера получателя, второй - регистрирует перегрузку канала, а также связанные с этим потери и понижает уровень трафика. В исходный момент времени при установлении соединения cwnd делается равным одному MSS, а ssthreth=65535 байтам. Программа, управляющая пересылкой, никогда не пошлет больше байт, чем это задано cwnd и объявленным получателем значением window. Когда получение очередного блока данных подтверждено, значение cwnd увеличивается. Характер этого увеличения зависит от того, осуществляется медленный старт или реализуется процедура подавления перегрузки. Если cwnd меньше или равно ssthreth, выполняется медленный старт, в противном случае осуществляется подавление перегрузки. В последнем случае cwndi+1 = cwndi + MSS/8 +(MSS*MSS)/cwnd. Если возникает состояние перегрузки канала значение cwnd снова делается равным одному MSS.

    В качестве модуля приращения cwnd используется MSS. При получении подтверждения (ACK) окно перегрузки увеличивается на один сегмент ("медленный старт", CWNDi+1 = CWNDi + размер_сегмента, последнее слагаемое нужно, если размер окна задан в октетах, в противном случае вместо него следует использовать 1) и теперь отправитель может послать, не дожидаясь ACK, уже два сегмента и т.д.. Ширина окна, в конце концов, может стать настолько большой, что ошибка доставки в пределах окна станет заметной. Тогда будет запущена процедура "медленного старта" или другой алгоритм, который определит новое, уменьшенное значение окна. Окно перегрузки позволяет управлять информационным потоком со стороны отправителя, блокируя возможные перегрузки и потери данных в промежуточных узлах сети (о других методах подавления перегрузки канала смотри раздел "Сети передачи данных"). Если переполнения не происходит, CWND становится больше окна, объявленного получателем, и именно последнее будет ограничивать поток данных в канале. Размер окна, объявленный получателем, ограничивается произведением полосы пропускания канала (бит/с) на RTT (время распространения пакета туда и обратно). Максимально допустимый размер окна в TCP равен 65535 байт (задается размером поля). Конечной целью регулирования трафика является установление соответствия между темпом передачи и возможностями приема. Причиной перегрузки может быть не только ограниченность размера буфера, но и недостаточная пропускная способность какого-то участка канала. С учетом этого обстоятельства каждый отправитель формирует два окна: окно получателя и окно перегрузки (ширина этого окна равна cwnd). Каждое из этих окон задает число байтов, которое может послать отправитель. Реальное число байтов, которое разрешено послать, равно минимальному из этих окон. При инициализации соединения окно перегрузки имеет ширину равную максимальному сегменту, который может быть использован в данном канале. Отправитель посылает такой сегмент. Если будет прислано подтверждение до истечения времени таймаута, размер окна перегрузки удваивается и посылается два сегмента максимальной длины. При получении подтверждения доставки каждого из сегментов окно перегрузки увеличивается на один сегмент максимальной длины. Когда ширина окна перегрузки становится равной B сегментов и все B посланных сегментов получают подтверждение, окно перегрузки возрастает на число байт, содержащихся в этих сегментах. Таким образом, ширина окна перегрузки последовательно удваивается, пока доставка всех сегментов подтверждается. Рост ширины окна перегрузки при этом имеет экспоненциальный характер. Это продолжается до тех пор, пока не наступит таймаут или окно перегрузки не сравняется с окном получателя. Именно эта процедура и называется медленным стартом (Джекобсон, 1988).

    Как было сказано выше, помимо окон перегрузки и получателя в TCP используется третий параметр - порог (иногда он называется порогом медленного старта ssthresh). При установлении соединения ssthresh=64 Kбайт. В случае возникновения таймаута значение ssthresh делается равным CWND/2, а само значение CWND приравнивается MSS (см. рис. 4.4.3.6). Далее запускается процедура медленного старта, чтобы выяснить возможности канала. При этом экспоненциальный рост cwnd осуществляется вплоть до значения ssthresh. Когда этот уровень cwnd достигнут, дальнейший рост происходит линейно с приращением на каждом шагу равным MSS (рис. 4.4.3.6).

    Рис. 4.4.3.6. Эволюция ширины окна при медленном старте

    Здесь предполагается, что MSS=1 Кбайт. Началу диаграммы соответствует установка значения ssthresh=16 Kбайт. Данная схема позволяет более точно выбрать значение cwnd. После таймаута, который на рисунке произошел при передаче c номером 12, значение порога понижается до 12 Кбайт (=cwnd/2). Ширина окна cwnd снова начинает расти от передачи к передаче, начиная с одного сегмента, вплоть до нового значения порога ssthresh=12 Кбайт. Стратегия с экспоненциальным и линейным участками изменения ширины окна переполнения позволяет несколько приблизить среднее его значение к оптимальному. Для локальных сетей, где значение RTT невелико, а вероятность потери пакета мала, оптимизация задания cwnd не так существенна, как в случае протяженных внешних (например, спутниковых) каналов. Ситуация может поменяться, если в локальной сети имеется фрагмент, где вероятность потерь пакетов велика. Таким фрагментом может быть МАС-бридж (или переключатель), один из каналов которого подключен к сегменту Fast Ethernet, а другой к обычному Ethernet на 10 Мбит/c. Если такой мост не снабжен системой подавления перегрузки (до сих пор такие приборы не имели подобных систем), то каждый из пакетов будет потерян в среднем 9 раз, прежде чем будет передан (здесь предполагается, что передача идет из сегмента FE). При этом cwnd будет практически все время равно MSS, что крайне неэффективно при передаче по каналам Интернет. Такие потери вызовут определенные ошибки при вычислении среднего значения и дисперсии RTT, а как следствие и величин таймаутов. Применение в таких местах маршрутизаторов или других приборов, способных реагировать на перегрузку посредством ICMP(4), решает эту проблему.

    Для взаимного согласования операций в рамках TCP-протокола используется четыре таймера:

    1. Таймер повторных передач (retransmission; RTO) контролирует время прихода подтверждений (ACK). Таймер запускается в момент посылки сегмента. При получении отклика ACK до истечения времени таймера, он сбраcывается. Если же время таймера истекает до прихода ACK, сегмент посылается адресату повторно, а таймер перезапускается.
    2. Таймер запросов (persist timer), контролирующий размер окна даже в случае, когда приемное окно закрыто. При window=0 получатель при изменении ситуации посылает сегмент с ненулевым значением ширины окна, что позволит отправителю возобновить свою работу. Но если этот пакет будет потерян, возникнет тупик, тогда каждая из сторон ждет сигнала от партнера. Именно в этой ситуации и используется таймер запросов. По истечении времени этого таймера отправитель пошлет сегмент адресату. Отклик на этот сегмент будет содержать новое значение ширины окна. Таймер запускается каждый раз, когда получен сегмент с window=0.
    3. Таймер контроля работоспособности (keepalive), который регистрирует факты выхода из строя или перезагрузки ЭВМ-партнеров. Время по умолчанию равно 2 часам. Keepalive-таймер не является частью TCP-спецификации. Таймер полезен для выявления состояний сервера half-open при условии, что клиент отключился (например, пользователь выключил свою персональную ЭВМ, не выполнив LOGOUT). По истечении времени таймера клиенту посылается сегмент проверки состояния. Если в течение 75 секунд будет получен отклик, сервер повторяет запрос 10 раз с периодом 75 сек, после чего соединение разрывается. При получении любого сегмента от клиента таймер сбрасывается и запускается вновь.
    4. 2MSL-таймер (Maximum Segment Lifetime) контролирует время пребывания канала в состоянии TIME_WAIT. Выдержка таймера по умолчанию равно 2 мин (FIN_WAIT-таймер). См. рис. 4.4.3.4. и RFC-793. Таймер запускается при выполнении процедуры active close в момент посылки последнего ACK.

    Важным параметром, определяющим рабочие параметры таймеров, является RTT (время путешествия пакета до адресата и обратно). TCP-агент самостоятельно измеряет RTT. Такие измерения производятся периодически и по их результатам корректируется среднее значение RTT:

    RTTm = a*RTTm + (1-a)*RTTi ,

    где RTTi - результат очередного измерения, RTTm - величина, полученная в результате усреднения предыдущих измерений, а - коэффициент сглаживания, обычно равный 0.9. RFC-793 рекомендует устанавливать время таймаута для ретрансмиссии (повторной передачи), значение RTO - Retransmission TimeOut равно RTO=RTTm*b, где b равно 2. От корректного выбора этих параметров зависит эффективная работа каналов. Так занижение времени ретрансмиссии приводит к неоправданным повторным посылкам сегментов, перегружая каналы связи. Для более точного выбора RTO необходимо знать дисперсию RTT. Несколько более корректную оценку RTO можно получить из следующих соотношений:

    RTTm = RTTm + g(RTTi-RTTm)
    D = D + d(|RTTi - RTTm| - D)
    RTO = RTTm + 4D,

    где D - среднее отклонение RTT от равновесного значения, а коэффициенты g = 0,125, D = 0,25. Чем больше g, тем быстрее растет RTO по отношению к RTT. Это хорошо работает до тех пор, пока не произойдет таймаут и ретрансмиссия. В этом случае, получив ACK, трудно решить, какому сегменту соответствует это подтверждение, первому или второму. На эту проблему впервые обратил внимание Фил Карн. Решением проблемы является приостановка коррекции RTTm при таймауте и ретрансмиссиях. Значение RTO зависит от пропускной способности канала и от специфических задержек, например в случае спутниковых каналов. В основном RTO лежит в секундном диапазоне (5-15 сек). Наиболее вероятная причина потери пакетов - это перегрузка канала на участках между отправителем и приемником. Указанием на то, что пакет потерян, может служить таймаут или получение дубликата сегмента ACK. Если произошел таймаут, система переходит в режим "медленного старта" (ширина окна перегрузки делается равной 1 сегменту, а значение порога медленного старта - ssthresh делается равным двум сегментам). При инициализации канала переменная ssthresh обычно равна 65535. Дублирование ACK индицирует потерю пакета до наступления таймаута. В этом случае сначала меняется алгоритм приращения величины окна перегрузки cwnd (замедляется темп его роста). После прихода очередного ACK новое значение cwnd вычисляется по формуле:

    cwndi+1 = cwndi + (размер_сегмента*размер_сегмента)/cwndi + размер_сегмента/8

    Если же в этот момент величина окна перегрузки меньше или равна некоторому порогу (ssthresh - slow start threshold, обычно измеряется в байтах), осуществляется "медленный старт". Следует помнить, что TCP требует посылки немедленного подтверждения (дублированного ACK) при обнаружении прихода сегментов с нарушением порядка следования. Причиной нарушения порядка следования может быть флуктуация задержки в сети или потеря пакета. Если получено три или более задублированных ACK, это является убедительным указанием на потерю пакета и, не дожидаясь таймаута, осуществляется его повторная передача. Перехода в режим медленного старта в этом случае не производится, но понижаются значения cwnd и ssthresh (почти вдвое).

    Когда TCP-канал закрывается и за время сессии переслано более 16 полых окон, а адресат достижим не через маршрут по умолчанию, то в таблицу маршрутизации заносится следующая информация: усредненное значение RTT, значение дисперсии RTT и ssthresh.

    Если в ходе TCP-сессии получено сообщение ICMP(4) (переполнение канала - quench), требующее снижения потока данных, то cwdn делается равным одному сегменту, а величина порога медленного старта ssthresh не изменяется. На ICMP-сообщения о недостижимости сети или ЭВМ программы TCP-уровня не реагируют вообще.

    Нулевой размер окна блокирует посылку информации и этим система время от времени пользуется. Что произойдет, если получатель послал сегмент, объявляющий окно ненулевым, а подтверждение получения этого сегмента не прошло? TCP-протокол не предусматривает посылки ACK на само подтверждение. Адресат ждет в этом случае данных, так как он уже объявил о существовании ненулевого окна с помощью соответствующего ACK, а отправитель ждет этого недошедшего ACK, чтобы начать передачу данных. Для разрешения этой тупиковой ситуации используется таймер запросов, который периодически посылает зондирующие сегменты получателю. Цель этого зондирования - выяснение существования окна ненулевой ширины. Таймер запросов запускается при получении информации об обнулении ширины окна приемником. Если за определенное время не поступает сегмента, сообщающего об изменении размера окна, таймер начинает посылать зондирующие сегменты. Таймер запросов использует базовую временную шкалу с периодом в 500 мсек, а период посылки зондирующих сегментов лежит в диапазоне 5-60 сек. Такой сегмент содержит только один байт данных. Таймер запросов не прерывает своей работы до тех пор, пока не будет подтверждено открытие окна или пока прикладная задача не завершит свою работу, выключив канал связи.

    Будучи однажды создан, канал TCP может существовать "вечно". Если клиент и сервер пассивны, они не заметят того, например, что какой-то бульдозер оборвал кабель или спутник связи покоится на дне океана. Чтобы это обнаружить, либо клиент либо сервер должны попытаться послать какую-то информацию. Чтобы информировать систему об этих и подобных им жизненных неурядицах, предусмотрен таймер контроля работоспособности (keepalive). Многим читателям, возможно, приходилось легкомысленно выключать питание своего персонального компьютера, не позаботившись о корректном logout из процедуры telnet или FTP. Если бы не существовало этого таймера, включив ЭВМ, вы бы обнаружили, что "находитесь" в заморском депозитарии, где были вчера. Но таймер контроля работоспособности может и прервать сессию, если какой-то промежуточный маршрутизатор произвел перезагрузку или был вынужден поменять маршрут. Принцип работы таймера работоспособности предельно прост. Если канал пассивен, например, 2 часа, сервер посылает клиенту сегмент-зонд. При этом ЭВМ-клиент может быть в одном из четырех состояний.

    • Работоспособен и достижим для сервера. Отклик от клиента сбросит таймер работоспособности в ноль (начало отсчета очередных двух часов).
    • Вышел из строя, выключен или перезагружается. Сервер посылает 10 запросов с интервалом 75 сек. Если отклика нет, канал закрывается и со стороны сервера.
    • Перезагрузился. Сервер получит отклик типа RESET и канал будет закрыт.
    • Работоспособен, но не достижим для сервера. Случай тождественен, описанному во втором по порядку пункте.

    Временная постоянная таймера keepalive является системной переменной единой для всех пользователей ЭВМ или даже локальной сети.

    Расширение пропускной способности и надежности телекоммуникационных каналов делает актуальной совершенствование протоколов. Так как TCP является основным транспортным протоколом, попытки усовершенствовать его предпринимаются, начиная с 1992 года (RFC-1323, Якобсон, Браден и Борман). Целью этих усовершенствований служит повышение эффективности и пропускной способности канала, а также обеспечение безопасности. При этом рассматриваются следующие возможности:

    • увеличение MTU (максимальный передаваемый блок данных);
    • расширение окна за пределы 65535 байт;
    • исключение "трех-сегментного" процесса установления связи и "четырехсегментного" ее прерывания (T/TCP, RFC-1644);
    • совершенствование механизма измерения RTT.
    • оптимизация отслеживания CWND.

    Оптимальный выбор MTU позволяет минимизировать или исключить фрагментацию (и последующую сборку) сегментов. Верхняя граница на MTU налагается значением MSS (максимальный размер сегмента). Разумно находить и запоминать оптимальные значения MTU для каждого конкретного маршрута. Так как в современных системах используются динамические протоколы маршрутизации, поиск оптимального MTU рекомендуется повторять каждые 10 мин (RFC-1191).

    Как уже отмечалось, размер TCP-окна определяется произведением полосы канала (в бит/с) на RTT в сек. Для Ethernet c полосой 10 Мбит/с и RTT=3 мсек это произведение равно 3750 байт, а для канала ИТЭФ-ДЕЗИ с пропускной способностью 1,5 Мбит/с и RTT=710 мсек (спутник) - 88750 байт, а это отнюдь не предел современной телекоммуникационной технологии. Но уже эти примеры говорят о том, что максимально возможный размер окна должен быть увеличен в раз 10-100 уже сегодня. Протокол же разрешает 65535 байт. Появление столь мощных каналов порождает и другие проблемы - потеря пакетов в них обходится слишком дорого, так как "медленный старт" и другие связанные с этим издержки сильно снижают пропускную способность. В последнее время алгоритм медленного старта заменяется более эффективными алгоритмами.

    Простое увеличение ширины окна до тех пор, пока не произойдет сбой, плохая стратегия при использовании традиционного медленного старта, так как заметную часть времени ширина окна будет неоптимальной - то слишком большой, то слишком малой. Оптимальная стратегия должна включать в себя прогнозирование оптимальной ширины окна. В новых версиях модулей TCP реализуются именно такие алгоритмы. В 1994 году Бракмо предложил вариант стратегии изменения параметров передачи, который на 40-70% повышает пропускную способность TCP-канала.

    Существуют и другие, могущие показаться забавными проблемы. Каждый сегмент в TCP-протоколе снабжается 32-битным идентификатором. Время жизни IP-пакета (TTL) определяется по максимуму 255 шагами или 255 секундами в зависимости оттого, что раньше наступит. Трудно предсказуемая ситуация может произойти, когда канал ликвидирован, затем создан снова (для той же комбинации IP-адресов и портов), а какой-то пакет из предшествующей сессии, погуляв по Интернет, придет уже во время следующей. Есть ли гарантия, что он будет верно идентифицирован? Одной из мер, упомянутых ранее, можно считать использование ограничения по максимальному времени жизни сегмента (MSL) или TTL, хотя снижение значения TTL не всегда возможно - ведь IP-пакетами пользуется не только TCP-протокол и нужна очень гибкая система задания его величины. Во многих приложениях MSL=30 сек (рекомендуемое значение 2 мин слишком велико). Технический прогресс ставит и некоторые новые проблемы. Высокопроизводительные каналы (1 Гбит/с) уже сегодня могут исчерпать разнообразие идентификационных кодов пакетов за один сеанс связи. Появление же двух пакетов с равными идентификаторами может породить неразрешимые трудности. Для передачи мегабайтного файла по гигабитному каналу требуется около 40 мсек (при этом предполагается, что задержка в канале составляет 32 мсек (RTT=64 мсек)). Собственно передача этой информации занимает 8 мсек. Из этих цифр видно, что традиционные протоколы, размеры окон и пр. могут свести на нет преимущества скоростного (дорогостоящего) канала. Пропускная способность такого канала определяется уже не его полосой, а задержкой. Понятно также, что необходимо расширить поле размера окна с 16 до 32 бит. Чтобы не изменять формат TCP-сегментов, можно сделать код размера окна в программе 32-разрядным, сохранив соответствующее поле в сегменте неизменным. Размер окна в этом случае задается как бы в формате с плавающей запятой. При установлении канала определяется масштабный коэффициент n (порядок) лежащий в интервале 0-14. Передача этого коэффициента (один байт) осуществляется сегментом SYN в поле опций. В результате размер окна оказывается равным 65535*2n. Если один из партнеров послал ненулевой масштабный коэффициент, но не получил такого коэффициента от своего партнера по каналу, то n считается равным нулю. Эта схема позволит сосуществовать старым и новым системам. Выбор n возлагается на TCP-модуль системы.

    Для того чтобы точнее отслеживать вариации RTT, предлагается помещать временные метки в каждый посылаемый сегмент. Так как в TCP используется одно подтверждение ACK на несколько сегментов, правильнее будет сказать, что RTT измеряется при посылке каждого ACK. Способность и готовность партнеров работать в таком режиме временных меток определяется на фазе установления канала. Более точное вычисление RTT позволяет не только корректно выбрать временные постоянные для таймеров, правильно вычислить задержку TIME_WAIT (TIME_WAIT=8*RTO), но и отфильтровать "старые" сегменты. Идеология временных меток используется и в алгоритме PAWS (Protection Against Wrapped Sequence Numbers) для защиты против перепутывания номеров сегментов.

    Предлагаемое усовершенствование TCP - T/TCP модифицирует алгоритмы выполнения операций. T/TCP вводит новую 32-битную системную переменную - число соединений (CC). СС позволяет сократить число пересылаемых сегментов при установлении канала, а также отфильтровывать "старые" сегменты, не принадлежащие данной сессии (установленной связи). Время отклика клиента в рамках указанных алгоритмов сокращается до суммы RTT и времени обработки запроса процессором. Данные пришедшие до SYN-сегмента должны буферизоваться для последующей обработки, а не отбрасываться.

    Ethernet (10 Мбит/c) в идеальных условиях позволяет осуществить обмен в рамках протокола TCP (например, при FTP-сессии) со скоростью 1,18 Мбайт/с.

    Как уже отмечалось, максимальная длина сегмента (MSS - Maximum Segment Size) в TCP-обменах величина переменная. Длина сегмента определяет длину кадра, в который он вложен. Для локальных Ethernet-сетей MSS=1460 октетов. Чем длиннее кадр, тем выше пропускная способность сети (меньше накладные расходы на заголовок кадра). С другой стороны, при передаче дейтограмм по внешним каналам, где размер пакета не столь велик, большое значение MSS приведет к фрагментации пакетов, которая замедлит обмен, поэтому администратор сети должен взвешивать последствия, задавая значения размера сегментов. Если MSS явно не задан, устанавливается значение по умолчанию (536 байт), что соответствует 576-байтной IP-дейтограмме. Для нелокальных адресов - это, как правило, разумный выбор.

    Ликвидация связи требует посылки четырех сегментов. TCP-протокол допускает возможность, когда один из концов канала объявляет о прекращении посылки данных (посылает FIN-сегмент), продолжая их получать (режим частичного закрытия - half-close). Посылка сегмента FIN означает выполнение операции active close. Получатель FIN-сегмента должен послать подтверждение его получения. Когда противоположный конец, получивший FIN, закончит пересылку данных, он пошлет свой FIN-сегмент. Прием подтверждения на получение этого сегмента означает закрытие данного канала связи. Возможно прерывание связи и с помощью посылки RST-сегмента. В этом случае все буферы и очереди очищаются немедленно и часть информации будет потеряна.

    Previous: 4.4.2 Протокол UDP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)


    previous up down next index index
    Previous: 4.4.3 Протокол TCP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.5 Протокол XTP

    4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол передачи команд и сообщений об ошибках (ICMP - internet control message protocol, RFC-792, - 1256) выполняет многие и не только диагностические функции, хотя у рядового пользователя именно этот протокол вызывает раздражение, сообщая об его ошибках или сбоях в сети. Именно этот протокол используется программным обеспечением ЭВМ при взаимодействии друг с другом в рамках идеологии TCP/IP. Осуществление повторной передачи пакета, если предшествующая попытка была неудачной, лежит на TCP или прикладной программе. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице будет восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтограммах, но не дает информации об ошибках в самих ICMP-сообщениях. icmp использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтограмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP-протокол осуществляет:

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

    ICMP-сообщения об ошибках никогда не выдаются в ответ на:

    • icmp-сообщение об ошибке.
    • При мультикастинг или широковещательной адресации.
    • Для фрагмента дейтограммы (кроме первого).
    • Для дейтограмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

    Эти правила призваны блокировать потоки дейтограмм, посылаемым в отклик на мультикастинг или широковещательные ICMP-сообщения.

    ICMP-сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 4.4.4.1.

    Рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр

    Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений). Код уточняет функцию ICMP-сообщения. Таблица этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные - являются запросами):

    Таблица 4.4.4.1. Типы и коды ICMP-сообщений.

    icmp-сообщение

    Описание сообщения
    Тип Код

    0

      Эхо-ответ (ping-отклик)

    3

      Адресат недостижим

    0

    * Сеть недостижима

    1

    * ЭВМ не достижима

    2

    * Протокол не доступен

    3

    * Порт не доступен

    4

    * Необходима фрагментация сообщения

    5

    * Исходный маршрут вышел из строя

    6

    * Сеть места назначения не известна

    7

    * ЭВМ места назначения не известна

    8

    * Исходная ЭВМ изолирована

    9

    * Связь с сетью места назначения административно запрещена

    10

    * Связь с ЭВМ места назначения административно запрещена

    11

    * Сеть не доступна для данного вида сервиса

    12

    * ЭВМ не доступна для данного вида сервиса

    13

    * Связь административно запрещена с помощью фильтра.

    14

    * Нарушение старшинства ЭВМ

    15

    * Дискриминация по старшинству

    4

    0

    * Отключение источника при переполнении очереди

    5

      Переадресовать (изменить маршрут)

    0

    Переадресовать дейтограмму в сеть (устарело)

    1

    Переадресовать дейтограмму на ЭВМ

    2

    Переадресовать дейтограмму для типа сервиса (tos) и сети

    3

    Переадресовать дейтограмму для типа сервиса и ЭВМ

    8

    0

    Эхо запроса (ping-запрос).

    9

    0

    Объявление маршрутизатора

    10

    0

    Запрос маршрутизатора

    11

      Для дейтограммы время жизни истекло (ttl=0):

    0

    *при передаче

    1

    * при сборке (случай фрагментации).

    12

      * Проблема с параметрами дейтограммы

    0

    * Ошибка в ip-заголовке

    1

    * Отсутствует необходимая опция

    13

      Запрос временной метки

    14

      Временная метка-отклик

    15

      Запрос информации (устарел)

    16

      Информационный отклик (устарел)

    17

      Запрос адресной маски

    18

      Отклик на запрос адресной маски

    Процедура "отключение источника" (quench, поле тип ICMP=4) позволяет управлять потоками данных в каналах Интернет. Не справляясь с обработкой дейтограмм, ЭВМ-адресат может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 4.4.4.2) представлен формат эхо-запроса (ping) и отклика для протокола ICMP.

    Рис. 4.4.4.2. Формат эхо-запроса и отклика ICMP

    Поля идентификатор и номер по порядку служат для того, чтобы отправитель мог связать в пары запросы и отклики. Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP-сообщения, начиная с поля тип. Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхо-запрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP-пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета (RTT - round trip time). Размер поля данные не регламентирован и определяется предельным размером IP-пакета.

    Время распространения ICMP-запроса, вообще говоря, не равно времени распространения отклика. Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными.

    Когда маршрутизатор не может доставить дейтограмму по месту назначения, он посылает отправителю сообщение "адресат не достижим" (destination unreachable). Формат такого сообщения показан ниже (на рис. 4.4.4.3).

    Рис. 4.4.4.3. Формат ICMP-сообщения "адресат не достижим"

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

    Так как в сообщении содержится Интернет-заголовок и первые 64-бита дейтограммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP-сообщения посылается и в случае, когда дейтограмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.

    Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4 для каждого из не записанных в буфер сообщений.

    Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP, среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP (network time protocol) описан в RFC-1119.

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

    Рис. 4.4.4.4. Формат icmp-запроса снижения загрузки

    В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда таблицы все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут, он может послать ей ICMP-запрос переадресации. Формат такого сообщения отображен на рисунке 4.4.4.5.

    Рис. 4.4.4.5. Формат ICMP-запроса переадресации

    Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтограмма достигла места назначения, указанного в ее заголовке. В поле internet-заголовок кроме самого заголовка лежит 64 первых бита дейтограммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 4.4.4.1).

    Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс, через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP-запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу.

    Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос. Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450-600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP-сообщений такого рода (см. рис. 4.4.4.6).

    Рис. 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах

    Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов, рис. 4.4.4.7).

    Рис. 4.4.4.7 Формат запроса маршрутной информации

    Так как следующий прогон (hop) дейтограммы определяется на основании локальной маршрутной таблицы, ошибки в последней могут привести к зацикливанию пакетов. Для подавления таких циркуляций используется контроль по времени жизни пакета (TTL). При ликвидации пакета по истечении TTL маршрутизатор посылает отправителю сообщение "время истекло", которое имеет формат (рис. 4.4.4.8):

    Рис. 4.4.4.8. Формат сообщения "время (ttl) истекло"

    Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1).

    Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтограммы), посылается сообщение "конфликт параметров". Это может произойти при неверных параметрах опций. При этом посылается сообщение вида (рис. 4.4.4.9):

    Рис. 4.4.4.9. Формат сообщения типа "конфликт параметров"

    Поле указатель отмечает октет дейтограммы, который создал проблему. Код=1 используется для сообщения о том, что отсутствует требуемая опция (например, опция безопасности при конфиденциальных обменах), поле указатель при значении поля код=1 не используется.

    В процессе трассировки маршрутов возникает проблема синхронизации работы часов в различных ЭВМ. К счастью синхронизация внутренних часов ЭВМ требуется не так часто (например, при выполнении синхронных измерений), негативную роль здесь могут играть задержки в каналах связи. Для запроса временной метки другой ЭВМ используется сообщение запрос временной метки, которое вызывает отклик с форматом (рис. 4.4.4.10):

    Рис. 4.4.4.10. Формат ICMP-запроса временной метки

    Поле тип=13 указывает на то, что это запрос, а тип=14 - на то, что это отклик. Поле идентификатор и номер по порядку используются отправителем для связи запроса и отклика. Поле исходная временная метка заполняется отправителем непосредственно перед отправкой пакета. Поле временная метка на входе заполняется маршрутизатором при получении этого пакета, а Временная метка на выходе - непосредственно перед его отправкой. Именно этот формат используется в процедурах ping и traceroute. Эти процедуры позволяют не только диагностировать, но и оптимизировать маршруты. Например, команда traceroute cernvm.cern.ch, выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP-адреса узлов и значения времени жизни дейтограмм, значения RTT приводится в миллисекундах):

     

    traceroute to crnvma.cern.ch

    (128.141.2.4) 30 hops max, 40 byte packets

    1 itep-fddi-bbone (193.124.224.50) 3 ms 2 ms 3 ms
    2 msu-tower.moscow.ru.radio-msu.net (193.124.137.13) 3 ms 3 ms 3 ms
    3 npi-msu.moscow.ru.radio-msu.net (193.124.137.9) 27 ms 3 ms 9 ms
    4 desy.hamburg.de.radio-msu.net (193.124.137.6) 556 ms 535 ms 535 ms
    5 * 188.1.133.56 (188.1.133.56) 637ms 670ms
    6 duesseldorf2.empb.net (193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!)
    7 bern3.empb.net (193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!)
    8 cernh3.euro-hep.net (193.172.24.10) 1808ms 1508ms 1830ms
    9 cgate1.cern.ch (192.65.185.1) 1116ms 1270ms 1278ms
    10 crnvma.cern.ch (128.141.2.4) 1132ms 1362ms 1524ms

    Отсюда видно, что наиболее узкими участками маршрута являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург является спутниковым и 500мс задержки здесь вносит время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) является общим также и для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP, как для локальной сети, так и для "окрестного" Интернет.

    При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать "запрос маски" в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (рис. 4.4.4.11).

    Рис. 4.4.4.11. Формат запроса (отклика) маски субсети

    Поле тип здесь специфицирует модификацию сообщения, тип=17 - это запрос, а тип=18 - отклик. Поля идентификатор и номер по порядку, как обычно, обеспечивают взаимную привязку запроса и отклика, а поле адресная маска содержит 32-разрядную маску сети.

    Previous: 4.4.3 Протокол TCP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.5 Протокол XTP


    previous up down next index index
    Previous: 4.4.11.1 Внутренний протокол маршрутизации RIP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.3 Протокол IGRP

    4.4.11.2 Протокол OSPF (алгоритм Дикстры)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол OSPF (Open Shortest Pass First, RFC-1245-48, RFC-1583-1587, алгоритмы предложены Дикстрой) является альтернативой RIP в качестве внутреннего протокола маршрутизации. OSPF представляет собой протокол состояния маршрута (в качестве метрики используется - коэффициент качества обслуживания). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (переключателей) автономной системы. Протокол OSPF реализован в демоне маршрутизации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP.

    Автономная система может быть разделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный (designated) маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. На иллюстративном рис. 4.2.11.2.1 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они оказываются выбранными в результате рассмотрения графа ("кратчайшие пути").

    Рис. 4.2.11.2.1 Иллюстрация работы алгоритма Дикстры

    Ниже дается формальное описание алгоритма. Сначала вводим некоторые определения.

    Пусть D(v) равно сумме весов связей для данного пути.
    Пусть c(i,j) равно весу связи между узлами с номерами i и j.

    Далее следует последовательность шагов, реализующих алгоритм.

    1. Устанавливаем множество узлов N = {1}.
    2. Для каждого узла v не из множества n устанавливаем D(v)= c(1,v).
    3. Для каждого шага находим узел w не из множества N, для которого D(w) минимально, и добавляем узел w в множество N.
    4. Актуализируем D(v) для всех узлов не из множества N
      D(v)=min{D(v), D(v)+c(w,v)}.
    5. Повторяем шаги 2-4, пока все узлы не окажутся в множестве N.

    Топология маршрутов для узла a приведена на нижней части рис. 4.2.11.2.1. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3.

    Таблица 4.2.11.2.1. Реализация алгоритма

    Множество Метрика связи узла a с узлами

    Шаг

    N

    B C D E F G H I J

    0

    {A}

    3 - 9 - - - - - -

    1

    {A,B}

    (3) 4 9 7 - 10 - - -

    2

    {A,B,C}

    3 (4) 6 6 10 10 8 - 14

    3

    {A,BC,D}

    3 4 (6) 6 10 10 8 9 14

    4

    {A,B,C,D,E}

    3 4 6 (6) 10 10 8 9 14

    5

    {A,B,C,D,E,H}

    3 4 6 6 10 10 (8) 9 14

    6

    {A,B,C,D,E,H,I}

    3 4 6 6 10 10 8 (9) 14

    7

    {A,B,C,D,E,H,I,F}

    3 4 6 6 (10) 10 8 9 14

    8

    {A,B,C,D,E,H,I,F,G}

    3 4 6 6 10 (10) 8 9 14

    9

    {A,B,C,D,E,H,I,F,G,J}

    3 4 6 6 10 10 8 9 (14)

    Таблица 4.2.11.2.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QoS) может характеризоваться следующими параметрами:

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

    Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF. Маршрутизация в этом протоколе определяется IP-адресом и типом сервиса. Так как протокол не требует инкапсуляции пакетов, сильно облегчается управление сетями с большим количеством бриджей и сложной топологией (исключается циркуляция пакетов, сокращается транзитный трафик). Автономная система может быть поделена на отдельные области, каждая из которых становится объектом маршрутизации, а внутренняя структура снаружи не видна (узлы на рис. 4.2.11.2.1 могут представлять собой как отдельные ЭВМ или маршрутизаторы, так и целые сети). Этот прием позволяет значительно сократить необходимый объем маршрутной базы данных. В OSPF используется термин опорной сети (backbone) для коммуникаций между выделенными областями. Протокол работает лишь в пределах автономной системы. В пределах выделенной области может работать свой протокол маршрутизации.

    Рис. 4.2.11.2.2 Пример выделения областей при ospf маршрутизации в автономной системе (М - маршрутизаторы; c - сети).

    На рис 4.2.11.2.2 (см. также рис. 4.2.11.2.1) приведен пример выделения областей маршрутизации при ospf-маршрутизации в пределах автономной системы. На рис. 4.2.11.2.2 маршрутизаторы М4 и М2 выполняют функция опорной сети для других областей. В выделенных областях может быть любое число маршрутизаторов. Более толстыми линиями выделены связи с другими автономными системами.

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

    224.0.0.5 предназначен для обращения ко всем маршрутизаторам, поддерживающим этот протокол.
    224.0.0.6 служит для обращения к специально выделенному маршрутизатору.

    Любое сообщение ospf начинается с 24-октетного заголовка:

    Рис. 4.2.11.2.3 Формат заголовка сообщений для протокола маршрутизации ospf

    Поле версия определяет версию протокола (= 2). Поле тип идентифицирует функцию сообщения согласно таблице 4.2.11.2.2:

    Таблица 4.2.11.2.2. Коды поля тип

    Тип

    Значение

    1

    Hello (используется для проверки доступности маршрутизатора).

    2

    Описание базы данных (топология).

    3

    Запрос состояния канала.

    4

    Изменение состояния канала.

    5

    Подтверждение получения сообщения о статусе канала.

    Поле длина пакета определяет длину блока в октетах, включая заголовок. Идентификатор области - 32-битный код, идентифицирующий область, которой данный пакет принадлежит. Все ospf-пакеты ассоциируются с той или иной областью. Большинство из них не преодолевает более одного шага. Пакеты, путешествующие по виртуальным каналам, помечаются идентификатором опорной области (backbone) 0.0.0.0. Поле контрольная сумма содержит контрольную сумму IP-пакета, включая поле типа идентификации. Контрольное суммирование производится по модулю 1. Поле тип идентификации может принимать значения 0 при отсутствии контроля доступа, и 1 при наличии контроля. В дальнейшем функции поля будут расширены. Важную функцию в OSPF-сообщениях выполняет одно-октетное поле опции, оно присутствует в сообщениях типа Hello, объявление состояния канала и описание базы данных. Особую роль в этом поле играют младшие биты e и Т:

    Бит E характеризует возможность внешней маршрутизации и имеет значение только в сообщениях типа Hello, в остальных сообщениях этот бит должен быть обнулен. Если E=0, то данный маршрутизатор не будет посылать или принимать маршрутную информацию от внешних автономных систем. Бит T определяет сервисные возможности маршрутизатора (TOS). Если T=0, это означает, что маршрутизатор поддерживает только один вид услуг (TOS=0) и он не пригоден для маршрутизации с учетом вида услуг. Такие маршрутизаторы, как правило, не используются для транзитного трафика.

    Протокол ospf использует сообщение типа Hello для взаимообмена данными между соседними маршрутизаторами. Структура пакетов этого типа показана на рис. 4.2.11.2.4.

    Рис. 4.2.11.2.4 Формат сообщения Hello в протоколе OSPF

    Поле сетевая маска соответствует маске субсети данного интерфейса. Например, если интерфейс принадлежит сети класса B и третий байт служит для выделения нужной субсети, то сетевая маска будет иметь вид 0xFFFFFF00.

    Поле время между Hello содержит значение времени в секундах, между сообщениями Hello. Поле опции характеризует возможности, которые предоставляет данный маршрутизатор. Поле приоритет характеризует уровень приоритета маршрутизатора (целое положительное число), используется при выборе резервного (backup) маршрутизатора. Если приоритет равен нулю, данный маршрутизатор никогда не будет использован в качестве резервного. Поле время отключения маршрутизатора определяет временной интервал в секундах, по истечении которого "молчащий" маршрутизатор считается вышедшим из строя. IP-адреса маршрутизаторов, записанные в последующих полях, указывают место, куда следует послать данное сообщение. Поля IP-адрес соседа k образуют список адресов соседних маршрутизаторов, откуда за последнее время были получены сообщения Hello.

    Маршрутизаторы обмениваются сообщениями из баз данных OSPF, чтобы инициализировать, а в дальнейшем актуализовать свои базы данных, характеризующие топологию сети. Обмен происходит в режиме клиент-сервер. Клиент подтверждает получение каждого сообщения. Формат пересылки записей из базы данных представлен на рис. 4.2.11.2.5.

    Рис. 4.2.11.2.5 Формат OSPF-сообщений о маршрутах

    Поля, начиная с тип канала, повторяются для каждого описания канала. Так как размер базы данных может быть велик, ее содержимое может пересылаться по частям. Для реализации этого используются биты I и М. Бит I устанавливается в 1 в стартовом сообщении, а бит M принимает единичное состояние для сообщения, которые являются продолжением. Бит S определяет то, кем послано сообщение (S=1 для сервера, S=0 для клиента, этот бит иногда имеет имя MS). Поле номер сообщения по порядку служит для контроля пропущенных блоков. Первое сообщение содержит в этом поле случайное целое число M, последующие M+1, M+2,...M+L. Поле тип канала может принимать следующие значения:

    Таблица 4.2.11.2.3. Коды типов состояния каналов (LS)

    LS-тип

    Описание объявления о маршруте

    1

    Описание каналов маршрутизатора, то есть состояния его интерфейсов.

    2

    Описание сетевых каналов. Это перечень маршрутизаторов, непосредственно связанных с сетью.

    3 или 4

    Сводное описание каналов, куда входят маршруты между отдельными областями сети. Эта информация поступает от пограничных маршрутизаторов этих зон. Тип 3 приписан маршрутам, ведущим к сетям, а тип 4 характеризует маршруты, ведущие к пограничным маршрутизаторам автономной системы.

    5

    Описания внешних связей автономной системы. Такие маршруты начинаются в пограничных маршрутизаторах AS.

    Поле идентификатор канала определяет его характер, в зависимости от этого идентификатором может быть IP-адрес маршрутизатора или сети. Маршрутизатор, рекламирующий канал определяет адрес этого маршрутизатора. Поле порядковый номер канала позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле возраст канала определяет время в секундах с момента установления связи. После обмена сообщениями с соседями маршрутизатор может выяснить, что часть данных в его базе устарела. Он может послать своим соседям запрос с целью получения свежей маршрутной информации о каком-то конкретном канале связи. Сосед, получивший запрос, высылает необходимую информацию. Запрос посылается в соответствии с форматом, показанном ниже (рис. 4.2.11.2.6):

    Рис. 4.2.11.2.6 Формат ospf-запроса маршрутной информации

    Три поля этого запроса повторяются согласно числу каналов, информация о которых запрашивается. Если список достаточно длинен, может потребоваться несколько запросов. Маршрутизаторы посылают широковещательные (или мультикастинговые) сообщения об изменении состояния своих непосредственных связей. Такое сообщение содержит список объявлений, имеющих формат (рис. 4.2.11.2.7):

    Рис. 4.2.11.2.7 Сообщение об изменении маршрутов

    Сообщения об изменениях маршрутов могут быть вызваны следующими причинами:

    1. Возраст маршрута достиг предельного значения (lsrefreshtime).
    2. Изменилось состояние интерфейса.
    3. Произошли изменения в маршрутизаторе сети.
    4. Произошло изменение состояния одного из соседних маршрутизаторов.
    5. Изменилось состояние одного из внутренних маршрутов (появление нового, исчезновение старого и т.д.)
    6. Изменение состояния межзонного маршрута.
    7. Появление нового маршрутизатора, подключенного к сети.
    8. Вариация виртуального маршрута одним из маршрутизаторов.
    9. Возникли изменения одного из внешних маршрутов.
    10. Маршрутизатор перестал быть пограничным для данной as (например, перезагрузился).

    Каждое сообщение о состоянии канала начинается с заголовка - "объявление состояния канала" (LS- link state). Формат этого типа заголовка приведен ниже (20 октетов):

    Рис. 4.2.11.2.8 Формат ospf-сообщения, описывающего состояние канала

    Поле возраст ls информации (рис. 4.2.11.2.8) определяет время в секундах с момента объявления состояния канала. Поле опции содержит значения типов сервиса (TOS), поддерживаемые маршрутизатором, рассылающим маршрутную информацию. Поле тип LS (тип состояния канала) может принимать значения, описанные выше в табл. 4.2.11.2.3. Следует обратить внимание, что код, содержащийся в этом поле, определяет формат сообщения. Поле длина задает размер сообщения в октетах, включая заголовок. В результате получается сообщение с форматом, показанным на рис. 4.2.11.2.9. Зарезервированный октет должен быть обнулен. Идентификатор связи определяет тип маршрутизатора, подключенного к каналу. Действительное значение этого поля зависит от поля тип. В свою очередь информация о канале также зависит от поля тип. Число tos определяет многообразие метрик, соответствующих видам сервиса, для данного канала. Последовательность описания метрик задается величиной кода TOS. Таблица кодов TOS, принятых в OSPF протоколе приведена ниже.

    Таблица 4.2.11.2.4. Коды типа сервиса (TOS)

    OSPF-код

    TOS-коды

    TOS(RFC-1349)

    0

    0000

    Обычный сервис

    2

    0001

    Минимизация денежной стоимости

    4

    0010

    Максимальная надежность

    8

    0100

    Максимальная пропускная способность

    16

    1000

    Минимальная задержка

    Рис. 4.2.11.2.9 Формат описания типа канала с LS=1

    Если бит V=1 (virtual), маршрутизатор является оконечной точкой активного виртуального канала. Если бит E (external) равен 1, маршрутизатор является пограничным для автономной системы. Бит B=1 (border) указывает на то, что маршрутизатор является пограничным для данной области. Поле тип может принимать значения, приведенные в таблице 4.2.11.2.5.

    Таблица 4.2.11.2.5. Коды типов связей (см. рис. 4.2.11.2.9)

    Код типа связи

    Описание

    1

    Связь с другим маршрутизатором по схеме точка-точка

    2

    Связь с транзитной сетью

    3

    Связь с оконечной сетью

    4

    Виртуальная связь (например, опорная сеть или туннель)

    Поле идентификатор канала характеризует объект, с которым связывается маршрутизатор. Примеры идентификаторов представлены в таблице:

    Таблица 4.2.11.2.6. Коды идентификаторов канала

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

    Описание

    1

    Идентификатор соседнего маршрутизатора

    2

    IP-адрес основного маршрутизатора (по умолчанию)

    3

    IP-адрес сети/субсети

    4

    Идентификатор соседнего маршрутизатора

    Маршрутизатор, получивший OSPF-пакет, посылает подтверждение его приема. Этот вид пакетов имеет тип=5 и структуру, отображенную на рис. 4.2.11.2.10. Получение нескольких объявлений о состоянии линий может быть подтверждено одним пакетом. Адресом места назначения этого пакета может быть индивидуальный маршрутизатор, группа маршрутизаторов или все маршрутизаторы автономной системы.

    Рис. 4.2.11.2.10 Формат сообщения о получении OSPF-пакета

    Рекламирование сетевых связей относится к типу 2. Сообщения посылаются для каждой транзитной сети в автономной системе. Транзитной считается сеть, которая имеет более одного маршрутизатора. Сообщение о сетевых связях должно содержать информацию обо всех маршрутизаторах, подключенных к сети, включая тот, который рассылает эту информацию. Расстояние от сети до любого подключенного маршрутизатора равно нулю для всех видов сервиса (TOS), поэтому поля TOS и метрики в этих сообщениях отсутствуют. Формат сообщения о транзитных сетевых связях показан на рис. 4.2.11.2.11.

    Следует помнить, что приведенные ниже сообщения должны быть снабжены стандартными 24-октетными OSPF-заголовками (на рис. 4.2.11.2.11 отсутствует).

    Рис. 4.2.11.2.11 Формат сообщения о сетевых связях (тип LS=2)

    Сетевая маска относится к описываемой сети, а поле подключенный маршрутизатор содержит идентификатор маршрутизатора, работающего в сети. Информация об адресатах в пределах автономной системы передается LS-сообщениями типа 3 и 4. Тип 3 работает для IP-сетей. В этом случае в качестве идентификатора состояния канала используется IP-адрес сети. Если же адресатом является пограничный маршрутизатор данной AS, то используется LS-сообщение типа 4, а в поле идентификатор состояния канала записывается OSPF-идентификатор этого маршрутизатора. Во всех остальных отношениях сообщения 3 и 4 имеют идентичные форматы (рис. 4.2.11.2.12):

    Рис. 4.2.11.2.12 Формат сообщений об адресатах в пределах автономной системы

    Поля, следующие после заголовка, повторяются в соответствии с числом описываемых объектов. Рекламирование внешних маршрутов относится к пятому типу. Эта информация рассылается пограничными маршрутизаторами. Информация о каждом внешнем адресате, известном маршрутизатору, посылается независимо. Этот вид описания используется и для маршрутов по умолчанию, для которых идентификатор состояния канала устанавливается равным 0.0.0.0 (аналогичное значение принимает при этом и сетевая маска). Формат такого сообщения представлен на рис. 4.2.11.2.13.

    Рис. 4.2.11.2.13 Формат описания внешних маршрутов

    Сетевая маска характеризует место назначения рекламируемого маршрута. Так для сети класса A маска может иметь вид 0xFF000000. Последующий набор полей повторяется для каждого вида TOS. Поля для TOS=0 заполняются всегда, и это описание является первым. Бит E характеризует внешнюю метрику. Если E=0, то она может непосредственно (без преобразования) сравниваться с метриками других каналов. При E=1 метрика считается больше любой метрики. Поле адрес пересылки указывает на место, куда будут пересылаться данные, адресованные рекламируемым маршрутом. Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы - источнику данного сообщения. Метка внешнего маршрута - 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:

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

    Преимущества OSPF:

    1. Для каждого адреса может быть несколько маршрутных таблиц, по одной на каждый вид IP-операции (TOS).
    2. Каждому интерфейсу присваивается безразмерная цена, учитывающая пропускную способность, время транспортировки сообщения. Для каждой IP-операции может быть присвоена своя цена (коэффициент качества).
    3. При существовании эквивалентных маршрутов OSFP распределяет поток равномерно по этим маршрутам.
    4. Поддерживается адресация субсетей (разные маски для разных маршрутов).
    5. При связи точка-точка не требуется IP-адрес для каждого из концов. (Экономия адресов!)
    6. Применение мультикастинга вместо широковещательных сообщений снижает загрузку не вовлеченных сегментов.

    Недостатки:

    1. Трудно получить информацию о предпочтительности каналов для узлов, поддерживающих другие протоколы, или со статической маршрутизацией.
    2. OSPF является лишь внутренним протоколом.

    Previous: 4.4.11.1 Внутренний протокол маршрутизации RIP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.3 Протокол IGRP


    previous up down next index index
    Previous: 4.4.11.2 Протокол OSPF (алгоритм Дикстры)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.4 Внешний протокол BGP

    4.4.11.3 Протокол IGRP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол IGRP разработан фирмой CISCO для своих многопротокольных маршрутизаторов в середине 80-х годов. Хотя этот протокол и не является стандартным, я счел возможным включить его описание, так как маршрутизаторы этой фирмы относятся к наиболее массовым. IGRP представляет собой протокол, который позволяет большому числу маршрутизаторов координировать свою работу. Основные достоинства протокола (описание протокола взято из депозитария FTP.CISCO.COM/pub/igrp.doc).

    • стабильность маршрутов даже в очень больших и сложных сетях;
    • быстрый отклик на изменения топологии сети;
    • минимальная избыточность. Поэтому IGRP не требует дополнительной пропускной способности каналов для своей работы;
    • разделение потока данных между несколькими параллельными маршрутами, примерно равного достоинства;
    • учет частоты ошибок и уровня загрузки каналов;
    • возможность реализовать различные виды сервиса для одного и того же набора информации.

    Сегодняшняя реализация протокола ориентирована на TCP/IP. Однако, базовая конструкция системы позволяет использовать IGRP и с другими протоколами. IGRP имеет некоторое сходство со старыми протоколами, например с RIP и Hello. Здесь маршрутизатор обменивается маршрутной информацией только с непосредственными соседями. Поэтому задача маршрутизации решается всей совокупностью маршрутизаторов, а не каждым отдельно.

    Для того чтобы исключить осцилляции маршрутов, протокол IGRP должен игнорировать новую информацию в течение нескольких минут после ее возникновения. OSPF-протокол вынужден использовать большую избыточность информации по сравнению с IGRP, как на уровне базы маршрутных данных, так и в процессе обмена с внешней средой.

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

    Протокол IGRP формирует эту базу данных на основе информации, которую он получит от соседних маршрутизаторов. В простейшем случае находится один путь для каждой из сетей. Сегменты пути характеризуются используемым сетевым интерфейсом, метрикой и маршрутизатором, куда следует сначала послать пакет. Метрика - то число, которое говорит о том, насколько хорош данный маршрут. Это число позволяет сравнить его с другими маршрутами, ведущими к тому же месту назначения и обеспечивающим тот же уровень QOS. Предусматривается возможность (как и в OSPF) разделять информационный поток между несколькими доступными эквивалентными маршрутами. Пользователь может сам разделить поток данных, если два или более пути оказались почти равными по метрике, при этом большая часть трафика будет послана по пути с лучшей метрикой. Метрика, используемая в IGRP, учитывает:

    • время задержки;
    • пропускную способность самого слабого сегмента пути (в битах в сек);
    • загруженность канала (относительную);
    • надежность канала (определяется долей пакетов, достигших места назначения неповрежденными).

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

    Среди параметров, которые контролируются, но не учитываются метрикой, находятся число шагов до цели и MTU (maximum transfer unit - размер пакета пересылаемого без фрагментации). Расчет метрики производится для каждого сегмента пути.

    Время от времени каждый маршрутизатор широковещательно рассылает свою маршрутную информацию всем соседним маршрутизаторам. Получатель сравнивает эти данные с уже имеющимися и вносит, если требуется, необходимые коррекции. На основании вновь полученной информации могут быть приняты решения об изменении маршрутов. Эта процедура типична для многих маршрутизаторов и этот алгоритм носит имя Белмана-Форда. (см. также описание протокола RIP, RFC-1058). Наилучший путь выбирается с использованием комбинированной метрики, вычисленной по формуле:

    [(K1 / Be) + (K2 * Dc)] r [1],

    где: K1, K2 = константы;

    Be= пропускная способность канала (в отсутствии загрузки) * (1 - загрузка канала);
    Dc = топологическая задержка;

    r = относительная надежность. (% пакетов, успешно передаваемых по данному сегменту пути). Здесь загрузка измеряется как доля от 1.

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

    Одним из преимуществ igrp является простота реконфигурации. В igrp маршрут по умолчанию не назначается, а выбирается из числа кандидатов.

    Когда маршрутизатор включается, его маршрутные таблицы инициализируются оператором вручную или с использованием специальных файлов. На рис. 4.4.11.3.1 маршрутизатор S связан через соответствующие интерфейсы с сетями 2 и 3.

    Рис. 4.4.11.3.1

    Таким образом, в исходный момент маршрутизатор S знает только о доступности сетей 2 и 3. За счет обмена информацией, полученной при инициализации и присланной позднее соседями, маршрутизаторы познают окружающий мир. Так S спустя некоторое время получит информацию от маршрутизатора R о доступности сети 1 и от T - о сети 4. В свою очередь S проинформирует T о доступе к сети 1. Очень быстро информация о доступности дойдет до всех маршрутизаторов и разрозненные сети станут единым целым. Для пояснения выбора маршрута в условиях многовариантности рассмотрим схему на рис. 4.4.11.3.2.

    Рис. 4.4.11.3.2.  Пример с альтернативными маршрутами

    Пусть каждый из маршрутизаторов уже вычислил комбинированную метрику для системы, изображенной на рис. 4.4.11.3.2. Для места назначения в сети 6 маршрутизатор A вычислит метрику для двух путей, через маршрутизаторы B и C. В действительности существует три маршрута из a в сеть 6:

    - непосредственно в B
    - в C и затем в B
    - в C и затем в D

    Маршрутизатору A не нужно выбирать между двумя маршрутами через C. Маршрутная таблица в A содержит только одну запись, соответствующую пути к C. Если маршрутизатор A посылает пакет маршрутизатору C, то именно C решает, использовать далее путь через маршрутизаторы B или D.

    Для каждого типа канала используется свое стандартное значение комбинированной задержки. Ниже приведен пример того, как может выглядеть маршрутная таблица в маршрутизаторе A для сети, изображенной на рис. 4.4.11.3.3.

    Номер
    сети

    Интерфейс

    Следующий
    Маршрутизатор

    Метрика
    маршрута

    Сеть 1

    NW 1

    Нет

    Непосредственная связь

    Сеть 2

    NW 2

    Нет

    Непосредственная связь

    Сеть 3

    NW 3

    Нет

    Непосредственная связь

    Сеть 4

    NW 2

    C

    1270

     

    NW 3

    B

    1180

    Сеть 5

    NW 2

    C

    1270

     

    NW 3

    B

    2130

    Сеть 6

    NW 2

    C

    2040

     

    NW 3

    B

    1180

    Рис. 4.4.11.3.3.  Пример маршрутной таблицы

    Для того чтобы обеспечить работу с большими и сложными сетями, в IGRP введены три усовершенствования алгоритма Белмана-Форда:

    1. Для описания путей вместо простой, введена векторная метрика. Расчет комбинированной метрики проводится с использованием формулы [1]. Применение векторной метрики позволяет адаптировать систему с учетом различных видов сервиса.
    2. Вместо выбора одного пути с минимальной метрикой, информационный поток может быть поделен между несколькими путями с метрикой, лежащей в заданном интервале. Распределение потоков определяется соотношением величин комбинированной метрики. Таким образом, используются маршруты с комбинированной метрикой меньше некоторого предельного значения M, а также с метрикой меньше V*M, где V - значение вариации M (обычно задается оператором сети).
    3. Существуют определенные проблемы с вариацией. Трудно определить стратегию использования вариации V>1 и избежать зацикливания пакетов. В современных реализациях V=1.
    4. Разработан ряд мер, препятствующих осцилляциям маршрутов при изменении топологии сети.

    Значения вариации, отличное от единицы, позволяет использовать одновременно два или более путей с разной пропускной способностью. При дальнейшем увеличении вариации можно разрешить не только более "медленные" сегменты пути, но и ведущие в обратном направлении, что приведет с неизбежностью к "бесконечному" циклическому движению пакетов.

    Протокол маршрутизации IGRP предназначен для работы с несколькими типами сервиса (TOS) и несколькими протоколами. Под типами сервиса в TCP/IP подразумевается оптимизация маршрутизации по пропускной способности, задержке, надежности и т.д. Для решения этой задачи можно использовать весовые коэффициента K1 и K2 (формула [1] данного раздела). При этом для каждого TOS подготавливается своя маршрутная таблица. Среди мер, обеспечивающих cтабильность топологии связей, следует отметить следующее правило, которое поясняется на приведенном ниже примере.

    Маршрутизатор A сообщает B о маршруте к сети 1. Когда же B посылает сообщения об изменении маршрутов в A, он ни при каких обстоятельствах не должен упоминать сеть 1. Т.е. сообщения об изменении маршрута, направленные какому-то маршрутизатору, не должны содержать данных об объектах, непосредственно с ним связанных. Сообщения об изменении маршрутов должны содержать:

    - адреса сетей, с которыми маршрутизатор связан непосредственно;
    - пропускную способность каждой из сетей;
    - топологическую задержку каждой из сетей;
    - надежность передачи пакетов для каждой сети;
    - загруженность канала для каждой сети;
    - MTU для каждой сети.

    Следует еще раз обратить ваше внимание, что в IGRP не используется измерение задержек, измеряется только надежность и коэффициент загрузки канала. Надежность определяется на основе сообщений интерфейсов о числе ошибок.

    Существует 4 временные константы, управляющие процессом распространения маршрутной информации (эти константы определяются оператором сети):

    - период широковещательных сообщений об изменении маршрутов (это время по умолчанию равно 90 сек);

    - время существования - если за это время не поступило никаких сообщений о данном маршруте, он считается нерабочим. Это время в несколько раз больше периода сообщений об изменениях (по умолчанию в 3 раза).

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

    - время удаления - если в течение данного времени не поступило сообщений о доступе к данному адресату, производится удаление записи о нем из маршрутной базы данных (по умолчанию это время в 7 раз больше периода сообщений об изменениях маршрутов).

    IGRP-сообщение вкладывается в IP-пакет, это сообщение имеет следующие поля:

    version номер версии протокола 4 байта

    opcode код операции
    edition код издания
    asystem номер автономной системы
    Ninterior, Nsystem, Nexterior числа субсетей в локальной сети, в автономной системе и вне автономной системы.
    checksum контрольная сумма IGRP-заголовка и данных
    Version - номер версии в настоящее время равен 1. Пакеты с другим номером версии игнорируются.

    Opcode - код операции определяет тип сообщения и может принимать значения:

    1 - изменение; 2 - запрос

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

    Asystem - номер автономной системы. Согласно нормам Сisco маршрутизатор может входить в более чем одну автономную систему. В каждой AS работает свой протокол и они могут иметь совершенно независимые таблицы маршрутизации. Хотя в IGRP допускается "утечка" маршрутной информации из одной автономной системы в другую, но это определяется не протоколом, а администратором.

    Ninterior, nsystem, и nexterior определяют числа записей в каждой из трех секций сообщения об изменениях.

    Checksum - контрольная сумма заголовка и маршрутной информации, для вычисления которой используется тот же алгоритм, что и в UDP, TCP и ICMP.

    IGRP запрос требует от адресата прислать свою маршрутную таблицу. Сообщение содержит только заголовок. Используются поля version, opcode и asystem, остальные поля обнуляются. IP-пакет, содержащий сообщение об изменении маршрутов, имеет 1500 байт (включая IP-заголовок). Для описанной выше схемы это позволяет включить в пакет до 104 записей. Если требуется больше записей, посылается несколько пакетов. Фрагментация пакетов не применяется.

    Ниже приведено описание структуры для маршрута:

    Number

    3 октета IP-адреса

    delay

    задержка в десятках микросекунд 3 октета

    bandwidth

    Пропускная способность, в Кбит/с 3 октета

    uchar mtu

    MTU, в октетах 2 октета

    reliability

    процент успешно переданных пакетов tx/rx 1 октет

    load

    процент занятости канала 1 октет

    hopcount

    Число шагов 1 октет

    Субполе описание маршрута Number определяет IP-адрес места назначения, для экономии места здесь используется только 3 его байта. Если поле задержки содержит только единицы, место назначения недостижимо.

    Пропускная способность измеряется в величинах, обратных бит/сек, умноженных на 1010. (Т.е., если пропускная способность равна N Кбит/с, то ее измерением в IGRP будет 10000000/N.). Надежность измеряется в долях от 255 (т.е. 255 соответствует 100%). Загрузка измеряется также в долях от 255, а задержка в десятках миллисекунд.

    Ниже приведены значения по умолчанию для величин задержки и пропускной способности

    Вид среды

    Задержка

    Пропускная способность

    Спутник

    200,000 (2 сек)

    20 (500 Мбит/c)

    Ethernet

    100 (1 мсек)

    1,000

    1.544 Мбит/c

    2000 (20 мсек)

    6,476

    64 Кбит/c

    2000

    156,250

    56 Кбит/c

    2000

    178,571

    10 Кбит/c

    2000

    1,000,000

    1 Кбит/c

    2000

    10,000,000

    Комбинированная метрика в действительности вычисляется по следующей формуле (для версии Cisco 8.0(3)):

    Метрика = [K1*пропускная_способность + (K2*пропускная_способность)/(256 - загрузка) + K3*задержка] * [K5/(надежность + K4)].

    Если K5 == 0, член надежности отбрасывается. По умолчанию в IGRP K1 == K3 == 1, K2 == K4 == K5 == 0, а загрузка лежит в интервале от 1 до 255.

    В начале 90-х годов разработана новая версия протокола IGRP - EIGRP с улучшенным алгоритмом оптимизации маршрутов, сокращенным временем установления и масками субсетей переменной длины. EIGRP поддерживает многие протоколы сетевого уровня. Рассылка маршрутной информации здесь производится лишь при измении маршрутной ситуации. Протокол периодически рассылает соседним маршрутизаторам короткие сообщения Hello. Получение отклика означает, что сосед функционален и можно осуществлять обмен маршрутной информацией. Протокол EIGRP использует таблицы соседей (адрес и интерфейс), топологические таблицы (адрес места назначения и список соседей, объявляющих о доступности этого адреса), состояния и метки маршрутов. Для каждого протокольного модуля создается своя таблица соседей. Протоколом используется сообщения типа hello (мультикастная адресация), подтверждени (acknowledgent), актуализация (update), запрос (query; всегда мультикастный) и отклик (reply; посылается отправителю запроса). Маршруты здесь делятся на внутренние и внешние - полученные от других протоколов или записанные в статических таблицах. Маршруты помечаются идентификаторами их начала. Внешние маршруты помечаются следующей информацией:

    • Идентификатор маршрутизатора EIGRP, который осуществляет рассылку информации о маршруте
    • Номер AS, где расположен адресат маршрута
    • Метка администратора
    • Идентификатор протокола
    • Метрика внешнего маршрута
    • Битовые флаги маршрута по умолчанию

    Протокол EIGRP полностью совместим с IGRP, он обеспечивает работу в сетях IP, Apple Talk и Novell.

    Previous: 4.4.11.2 Протокол OSPF (алгоритм Дикстры)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.4 Внешний протокол BGP


    previous up down next index index
    Previous: 4.4.11.3 Протокол IGRP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)

    4.4.11.4 Внешний протокол BGP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае - это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

    Рис. 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов

    Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

    1

    OPEN

    (открыть)

    2

    UPDATE

    (изменить)

    3

    NOTIFICATION

    (внимание)

    4

    KEEPALIVE

    (еще жив)

    После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение open содержит следующие поля (рис. 4.4.11.4.2):

    Рис. 4.4.11.4.2 Формат сообщения open

    Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.

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

    Длина сообщения = 29 + длина поля идентификационных данных.
    Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

    Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный заголовок и может содержать другие поля в соответствии со схемой:

    Рис. 4.4.11.4.3 Формат update-сообщения

    Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны. Каждая такая запись имеет формат:

    Длина префикса (в битах), равная нулю означает, что префикс соответствует всем IP-адресам, а сам имеет нулевой размер. Поле префикс содержит IP-адресные префиксы, за которыми следуют разряды, дополняющие их до полного числа октетов. Значения этих двоичных разрядов смысла не имеют.

    Нулевое значение полной длины списка атрибутов пути говорит о том, что информация о доступности сетевого уровня в UPDATE-сообщении отсутствует. Список атрибутов пути присутствует в любом UPDATE-сообщении. Этот список имеет переменную длину, а каждый атрибут содержит три составные части: тип атрибута, длину атрибута и значение атрибута. Тип атрибута представляет собой двух-октетное поле со структурой:

    Старший бит (бит0) поля флаги атрибута определяет, является ли атрибут опционным (бит0=1) или стандартным (well-known, бит0=0). Бит 1 этого поля определяет, является ли атрибут переходным (бит1=1) или непереходным (бит1=0). Для обычных атрибутов этот бит должен быть равен 1. Третий бит (бит 2) поля Флагов атрибута определяет, является ли информация в опционном переходном атрибуте полной (бит2=0) или частичной (бит2=1). Для обычных и для опционных непереходных атрибутов этот бит должен быть равен нулю. Бит 3 поля флагов атрибута информирует о том, имеет ли длина атрибута один (бит3=0) октет или два октета (бит3=1). Бит3 может быть равен 1 только в случае, когда длина атрибута более 255 октетов. Младшие 4 бита октета флагов атрибута не используются (и должны обнуляться). Если бит3=0, то третий октет атрибута пути содержит длину поля данных атрибута в октетах. Если же бит3=1, то третий и четвертый октеты атрибута пути хранят длину поля данных атрибута. Остальные октеты поля атрибут пути характеризуют значение атрибута и интерпретируются согласно флагам атрибута.

    Атрибуты пути бывают "стандартные обязательные" (well-known mandatory), "стандартные на усмотрение оператора", "опционные переходные" и "опционные непереходные". Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься, как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз.

    Предусмотрены следующие разновидности кодов типа атрибута:

    ORIGIN (код типа = 1) - стандартный обязательный атрибут, который определяет происхождение путевой информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения:

    Код атрибута

    Описание

    0

    IGP - информация достижимости сетевого уровня является внутренней по отношению к исходной автономной системе;

    1

    EGP - информация достижимости сетевого уровня получена с помощью внешнего протокола маршрутизации;

    2

    Incomplete - информация достижимости сетевого уровня получена каким-то иным способом.

    AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH-атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей <тип сегмента пути, длина сегмента пути и оценка сегмента пути>. Тип сегмента пути представляет в свою очередь однооктетное поле, которое может принимать следующие значения:

    Код типа сегмента

    Описание

    1

    AS_set: неупорядоченный набор маршрутов в update сообщении;

    2

    AS_sequence: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении.

    Длина сегмента пути представляет собой одно-октетное поле, содержащее число as, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый.

    NEXT_HOP (код типа = 3) - стандартный обязательный атрибут, определяющий IP-адрес пограничного маршрутизатора, который должен рассматриваться как цель следующего шага на пути к точке назначения.

    MULTI_EXIT_DISC (код типа = 4) представляет собой опционный непереходной атрибут, который занимает 4 октета и является положительным целым числом. Величина этого атрибута может использоваться при выборе одного из нескольких путей к соседней автономной системе.

    LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.

    ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который используется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов.

    aggregator (код типа = 7) - опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета). Объем информации о достижимости сетевого уровня равен (в октетах):

    Длина сообщения UPDATE - 23 - полная длина атрибутов пути - длина списка отмененных маршрутов. Информация о достижимости кодируется в следующей форме:

    Поле длина определяет длину IP-адресного префикса в битах. Если длина равна нулю, префикс соответствует всем IP-адресам. Префикс содержит IP-адресные префиксы и двоичные разряды, дополняющие код до целого числа октетов.

    Информация о работоспособности соседних маршрутизаторов получается из KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы уложиться во время, отведенное таймером сохранения (hold). Обычно это время не должно превышать одной трети от времени сохранения, но не должно быть и меньше 1 секунды. Если выбранное значение времени сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не обязательна.

    NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается. Помимо заголовка NOTIFICATION-сообщение имеет следующие поля:

    Код ошибки представляет собой одно-октетное поле и указывает на тип данного сообщения. Возможны следующие коды ошибки:

    Таблица 4.4.11.4.1. Коды ошибок

    Код ошибки

    Описание

    1

    Ошибка в заголовке сообщения.

    2

    Ошибка в сообщении open

    3

    Ошибка в сообщении update

    4

    Истекло время сохранения

    5

    Ошибка машины конечных состояний

    6

    Прерывание

    При отсутствии фатальной ошибки BGP-партнер может в любой момент прервать связь, послав NOTIFICATION-сообщение с кодом ошибки прерывание.

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

    Таблица 4.4.11.4.2 Субкоды ошибок

    Ошибка

    Субкод

    Описание

    Заголовок

    1
    2
    3

    Соединение не синхронизовано
    Неверная длина сообщения
    Неверный тип сообщения

    Сообщения OPEN

    1
    2
    3
    4
    5
    6

    Неверный код версии
    Ошибочный код as-партнера
    Ошибочный идентификатор BGP
    Ошибка в коде идентификации
    Ошибка при идентификации
    Неприемлемое время сохранения

    Сообщения UPDATE

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11

    Ошибка в списке атрибутов
    Не узнан стандартный атрибут
    Отсутствует стандартный атрибут
    Ошибка в флагах атрибута
    Ошибка в длине атрибута
    Неправильный атрибут origin
    Циклический маршрут
    Ошибка в атрибуте next_hop
    Ошибка в опционном атрибуте
    Ошибка в сетевом поле
    Ошибка в as_path

    Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:

    1.

    ADJ-RIBS-IN:

    Запоминает маршрутную информацию, которая получена из update-сообщений. Это список маршрутов, из которого можно выбирать. (policy information base - PIB).

    2.

    LOC-RIB:

    Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN.

    3.

    ADJ-RIBS-OUT:

    Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений.

    Так как разные BGP-партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам.

    Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел "Автономные системы и маршрутная политика"). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов.

    BGP использует три таймера:
    Connectretry (сбрасывается при инициализации и коррекции; 120 сек),
    Holdtime (запускается при получении команд Update или Keepalive; 90сек) и
    keepalive (запускается при посылке сообщения Keepalive; 30сек).

    BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.

    BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается.

    Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы:

    1. Вычисление степени предпочтения для каждого маршрута, полученного от соседней AS, и передача информации другим узлам местной AS.
    2. Выбор лучшего маршрута из наличного числа для каждой точки назначения и укладка результата в LOC-RIB.
    3. Рассылка информации из loc_rib всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.

    Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) - способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 - "Маршрутная политика"). Для приведенных примеров это в терминах масок выглядит следующим образом:

    24 и 17 длины префикса сети.

    Следует помнить, что маски с разрывами здесь недопустимы. Ниже приведена таблица метрик маршрутизации для различных протоколов.

    Протокол

    Метрика

    Диапазон

    Код "маршрут недостижим"

    RIP
    hello
    BGP

    Число скачков
    Задержка в ms
    Не определена

    0-15
    0-29999
    0-65534

    16
    30000
    65535

    Колонка "маршрут недостижим" содержит коды метрики, которые говорят о недоступности маршрута. Обычно предполагается, что если послан пакет из точки <А> в точку <B>, то маршруты их в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов "туда" и "обратно" не совпадают, представлен на рис. 4.4.11.4.4. В предложенной схеме имеется две ЭВМ "Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора "GW-2" и "GW-1".

    Рис. 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно".

    Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:

    1 GW-1

    (192.148.166.35)

    2 Место назначения

    (192.148.166.33)

    Команда же traceroute 192.148.165.80 распечатает:

    1 GW-1

    (192.148.166.35)

    2 GW-2

    (192.148.166.7)

    3 Место назначения

    (192.148.165.80)

    Команда traceroute -g 192.148.165.80 сообщит вам:

    1 GW-1

    (192.148.166.35)

    2 *****

    ; В этом режиме маршрутизатор не откликается

    3 Место назначения

    (192.148.165.80)

    4 GW-1

    (192.148.166.35)

    5 ЭВМ-отправитель

    (192.148.166.32)

    Из приведенных примеров видна также полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.

    Другой полезной командой является Netstat, которая позволяет получить разнообразную информацию о состоянии сети. Существует четыре модификации этой команды:

    -a отображает состояния всех соединений;
    -i отображает значения конфигурационных параметров;
    -r отображает таблицу маршрутов;
    -v отображает статистику обмена локального Ethernet-интерфейса.

    Например, команда netstat -r может выдать:

    Routing tables (таблицы маршрутизации)

    Destination

    Gateway

    Flags

    Refcnt

    Use

    Interface

    Stavropol-GW.ITEP.RU

    nb

    UGHD

    0

    109

    le0

    ihep.su

    itepgw

    UGHD

    0

    103

    le0

    m10.ihep.su

    itepgw

    UGHD

    0

    16

    le0

    194.85.66.50

    itepgw

    UGHD

    0

    455

    le0

    Kharkov.ITEP-Kharkov

    nb

    UGHD

    0

    105

    le0

    Bryansk-GW.ITEP.Ru

    nb

    UGHD

    1

    8113

    le0

    193.124.225.67

    nb

    UGHD

    0

    0

    le0

    ixwin.ihep.su

    itepgw

    UGHD

    1

    6450

    le0

    ihep.su

    itepgw

    UGHD

    0

    14

    le0

    192.148.166.21

    nb

    UGHD

    0

    109

    le0

    ihep.su

    itepgw

    UGHD

    0

    224

    le0

    193.124.225.71

    nb

    UGHD

    0

    10

    le0

    194.85.112.0

    ITEP-FDDI-BBone.ITEP

    UGD

    0

    253

    le0

    default

    itepgw

    UG

    10

    102497

    le0

    Здесь приведен только фрагмент маршрутной таблицы. Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway - имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Базовая команда netstat может обеспечить следующую информацию:

    Active Internet connections (активные Интернет связи)

    Proto

    Recv-Q

    Send-Q

    Local Address

    Foreign Address

    (state)

    tcp

    0

    0

    127.0.0.1.1313

    127.0.0.1.sunrpc

    TIME_WAIT

    tcp

    0

    0

    ns.1312

    193.124.18.65.smtp

    SYN_SENT

    tcp

    0

    0

    127.0.0.1.1311

    127.0.0.1.sunrpc

    TIME_WAIT

    tcp

    0

    0

    ns.1310

    ns.domain

    TIME_WAIT

    tcp

    0

    0

    127.0.0.1.1309

    127.0.0.1.sunrpc

    TIME_WAIT

    tcp

    39

    24576

    ns.nntp

    Bryansk-GW.ITEP.1697

    ESTABLISHED

    tcp

    0

    0

    ns.telnet

    semenov.1802

    ESTABLISHED

    tcp

    0

    188

    ns.1033

    xmart.desy.de.6000

    ESTABLISHED

    udp

    0

    0

    127.0.0.1.domain

    *.*

    udp

    0

    0

    ns.domain

    *.*

    Active UNIX domain sockets (активные UNIX-соединители домена)

    Address

    Type

    Recv-Q

    Send-Q

    Vnode

    Conn

    Refs

    Nextref Addr

    ff64b38c

    stream

    0

    0

    ff13187c

    0

    0

    0 /dev/printer

    ff64b28c

    dgram

    0

    0

    0

    0

    0

    0

    ff64698c

    dgram

    0

    0

    ff137fa8

    0

    0

    0 /dev/log

    Previous: 4.4.11.3 Протокол IGRP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)


    previous up down next index index
    Previous: 4.4.11.4 Внешний протокол BGP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.6 Автономные системы

    4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Вряд ли отцы-создатели Интернет предполагали, что когда-либо, тем более при их жизни возникнет дефицит IP-адресов. Уже в 1996 году было зарегистрировано более 100000 сетей. Разбивка сетей на три класса A, B и С уже не может отвечать современным требованиям. Сеть класса А с ее 16000000 адресов слишком велика, а класса С с 254 адресами, как правило, слишком мала. Сети класса B с 65536 машинами может показаться оптимальными, но на практике каждая из этих сетей не обеспечивает оптимального использования адресного пространства и всегда остаются неиспользованные адреса (для классов B и A количество пустующих адресов оказывается обычно значительным). Адресные блоки заказываются администраторами, которые полагают, что однажды их организация или фирма станет великой с тысячами ЭВМ (пока же у них есть всего несколько машин). Надо сказать, что такие оптимистические прогнозы сбываются крайне редко. Проблема маршрутизации может быть решена путем реализации более глубокой структурной иерархии, где каждый IP-адрес имеет код страны, региона, города, сети, но при этом размер адреса должен существенно превышать 32 разряда, так как адреса неизбежно будут использоваться крайне не эффективно - ведь Китаю и Монако будут выделены равные адресные зоны. Это может стать возможным при внедрении технологии IPv6.

    Если бы в адресах класса С для кода номера ЭВМ было выделено 10 или 11 бит (1024-2048), ситуация была бы более приемлемой. Маршрутизатор рассматривает IP-адресную среду на двух уровнях - адрес сети и адрес ЭВМ, при этом практически они работают только с адресами сетей. Число записей в маршрутной таблице должно будет быть равным половине миллиона записей (по числу блоков С-адресов).

    Проблема может быть решена, если забыть про разбиение всей совокупности IP-адресов на классы. Такая модель реализуется в рамках протокола CIDR (Classless InterDomain Routing). В этой модели каждой сети ставится в соответствие определенное число смежных блоков по 256 адресов. Далее используется известное географическое зонное распределение IP-адресов (см. Ethernet в Интернет, а также RFC-1519). Протокол при просмотре маршрутных таблиц предполагает применение специальных масок и индексных механизмов.

    Previous: 4.4.11.4 Внешний протокол BGP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.6 Автономные системы


    previous up down next index index
    Previous: 4.4.11.6 Автономные системы    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.11.8 Язык описания маршрутной политики RPSL

    4.4.11.7 Маршрутная политика
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики:

    оповещение (announce) и
    восприятие (accept).

    Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (AS) может работать только один внутренний протокол маршрутизации (IGP), а обмен маршрутной информацией между автономными системами происходит в соответствии с внешним протоколом маршрутизации (EGP). Эта идея продемонстрирована на рис. 4.4.11.4.1. ЭВМ (или узлы) A1,B1,C1,D1 и маршрутизатор G-1 составляют одну автономную систему, а A2,B2,C2,D2,E2 и маршрутизатор G-2 - вторую.

    Рис. 4.4.11.4.1. Схема связи автономных систем

    Пусть имеются две автономные системы ASX и ASY, обменивающиеся маршрутной информацией. ASX знает, как можно достичь сети Net1, которая может и не принадлежать ASX. Аналогично ASY знает, как послать пакет для сети Net2.

    net1 .... ASX <----> ASY ...... Net2

    Для того чтобы пакеты попали из Net1 в Net2 через ASX и ASY, автономная система ASX должна анонсировать сеть Net1 автономной системе ASY, используя один из внешних протоколов маршрутизации (EGP или BGP), а ASY должна воспринять эту информацию и использовать. Предметом маршрутной политики в этом случае является решение ASX послать маршрутную информацию ASY, а также решение ASY эту информацию принять и использовать. Не существует никаких правил, которые бы вынуждали ASX и ASY к принятию таких решений. Таким образом, протокол маршрутизации определяет формат маршрутной информации, способ ее пересылки и хранения, но решения о ее посылке той или иной AS, а также решение об использовании маршрутной информации, поступающей извне остаются в руках администратора AS.

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

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

    Рис. 4.4.11.4.2

    Под каналом в данном случае подразумевается любая среда коммуникации - Ethernet, FDDI и т.д.. Может так случиться, что AS2 предпочитает использовать канал 2 только для обмена с AS4. А канал 1 используется для связи с AS3 и в качестве резервного маршрута (back-up) к AS4 в случае выхода из строя канала 2. Для описания маршрутной политики используются атрибуты interas-in и interas-out. Эти атрибуты позволяют описать локальные решения AS, основанные на ее предпочтениях, так как это делается в протоколах BGP-4 или IGRP. Пример такого описания представлен ниже:

    aut-num: AS2 - (номер автономной системы, формат:
    AS<целое положительное число в интервале 1-65535>)

    as-in: from AS3 10 accept AS3 AS4

    (описание воспринимаемой маршрутной информации от других AS-партнеров. Формат описания:

    from accept <выражение маршрутной политики>;
    здесь - относится к AS-соседям; - положительное целое число, характеризующее относительную ценность маршрутов, чем меньше cost, тем предпочтительнее маршрут; ключевые слова from (от) и accept (воспринимает) могут отсутствовать.)

    Маршрутная политика (<выражение маршрутной политики>) может иметь следующие форматы.

    1. Список из одного или нескольких кодов AS, AS-макро или список маршрутов. Список маршрутов записывается в префиксной форме, в качестве разделителей используются запятые и фигурные скобки.
    2. Список ключевых слов. В настоящее время определено ключевое слово ANY, которое говорит о том, что речь может идти о любых соседних AS.
    3. Логическое выражение, включающее в себя объекты типа 1 или 2, объединенные операторами AND, OR, NOT, которые в данном случае, строго говоря, не являются Булевыми. Так например, AS1 OR AS2 означает все маршруты AS1 или AS2. Или AS1 AND HepNet означает маршрут AS1, принадлежащий объединению HepNet. NOT AS3 означает любой маршрут кроме маршрутов AS3.

    Приоритеты операторов распределены в следующем порядке: для оператора () слева направо; для NOT - справа на лево; для AND и OR - слева направо.

    В отсутствии логических операторов элементы списка (AS, AS-макро, объединения и списки маршрутов) предполагаются объединенными оператором OR.

    as-out: to AS3 announce AS1 AS2

    (описание сформированной маршрутной информации, рассылаемой другим AS-партнерам). Формат описания:

    to announce <выражение маршрутной политики>;
    ключевые слова to {указатель адресата} и announce
    {указатель списка доступных AS} могут и отсутствовать.)
    относится к AS-соседям.

    interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5) accept AS3
    interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref=15) accept AS4
    interas-in: from AS3 193.0.1.5/32 193.0.1.6/32 (pref=10) accept AS4
    ...

    interas-in: описывает локальные предпочтения для соединений с другими AS. Это описание имеет формат:

    from <местный-rid> <соседний-rid> <предпочтение>
    accept <выражение маршрутной политики>

    Ключевые слова from (от) и accept (воспринимает) могут отсутствовать. - автономная система, описанная в as-in. <местный-rid> - (идентификатор местного маршрутизатора) содержит IP-адрес пограничного маршрутизатора, политика которого описывается. <соседний-rid> содержит IP-адрес соседнего маршрутизатора, от которого воспринимается маршрутная информация, описанная в <выражении маршрутной политики>. IP-адреса имеют префиксный формат (описание префиксного формата см. выше в конце раздела 1.4.11.4 [бесклассовая интердоменная маршрутизация - CIDR]).

    Предпочтение описывается, как = <значение>; ключевое слово должно обязательно присутствовать. В настоящее время стандарт поддерживает только один вид - "pref". <значение> может принимать один из следующих видов:

    <стоимость> - положительное число, служащее выражением относительной ценности исследуемых маршрутов. Чем меньше <стоимость> - тем предпочтительнее маршрут. <стоимость> имеет смысл при сравнении атрибутов interas-in и совершенно не применима для сравнения с атрибутами as-in.

    Любой маршрут, описанный в interas-in и неупомянутый в AS-IN, предполагается отвергнутым. Система диагностики выдаст при этом сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как as-out и as-in.

    Если мы рассмотрим соответствующие атрибуты interas-out для AS3, то увидим следующее:

    aut-num: AS3
    as-in: from AS2 10 accept AS1 A2
    as-out: to AS2 announce AS3 AS4
    interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3
    interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=15) announce AS4
    interas-out: to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=10) announce AS4
    ...

    Оператор interas-out: имеет формат:

    to aut-num> <местный-rid> <соседний-rid> [<метрика>]
    announce <выражение маршрутной политики>

    Ключевые слова IN и announce могут и отсутствовать. Остальные фрагменты оператора идентичны описанным выше.

    <метрика> является необязательным параметром и описывается как:

    (=<величина>), следует заметить, что в данном случае наличие скобок "()" и ключевого слова (тип метрики) обязательно. В настоящее время поддерживается только один тип метрики "metric-out". Параметр <величина> может иметь следующий вид:

    - метрика для оценки выходных маршрутов, чем ниже ее значение, тем предпочтительнее маршрут. Именно эта оценка маршрута передается соседним маршрутизаторам. IGP - этот тип метрики указывает на то, что она отражает оценку внутренних маршрутов AS. Следует избегать использования и IGP для одних и тех же точек назначения.

    Атрибут as-exclude отмечает список транзитных AS, маршруты через которые должны быть исключены из рассмотрения. Формат использования:

    exclude to , ключевые слова exclude и to не являются обязательными. - описывает транзитные AS. В качестве можно использовать одно из:

    , AS макро, ANY (любой) или community.

    Атрибут default указывает на маршрут по умолчанию. Формат атрибута:

    ,

    где указывает на AS-партнера, путь к которому и предлагается в качестве маршрута по умолчанию. Атрибут - положительное целое число, характеризующее уровень приоритета предлагаемого маршрута. AS-macro является удобным средством группировать автономные системы. AS-макро могут использоваться в <выражениях маршрутной политики> для атрибутов as-in и as-out. В качестве примера можно привести:

    aut-num: AS786
    as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
    as-out: to AS1755 announce AS786
    .......

    Здесь присутствует as-macro с именем AS-EBONE, описание которого может выглядеть как:

    as-macro: AS-EBONE (имя AS-макро)
    descr: ASes routed by EBONE (AS, маршрутизируемые в EBONE)
    as-list: AS2121 AS1104 AS2600 AS2122 (список AS)
    as-list: AS1103 AS1755 AS2043
    guardian: guardian@ebone.net (администратор EBONE)
    ......

    В результате описание маршрутной политики будет выглядеть как:

    aut-num: AS786
    as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
    as-in: from AS1755 100 accept AS1103 OR AS1755 OR AS2043)AND NOT AS1104
    ......

    Community - это группа маршрутов, которые не могут быть представлены одной AS или группой AS. Это может быть полезно при описании доступа к супер-ЭВМ, это может быть группа маршрутов, используемых для специальных целей, возможно объединение в группу для получения сетевой статистики. Такие группы не обмениваются маршрутной информацией. Группа Community может использоваться в качестве объекта маршрутной политики автономных систем. Примерами объектов типа community могут служить HEPNET (объединение сетей для физики высоких энергий), NSFNET (Национальная Научная сеть США), опорная московская оптоволоконная сеть.

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

    Previous: 4.4.11.6 Автономные системы    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.11.8 Язык описания маршрутной политики RPSL


    previous up down next index index
    Previous: 4.4.11.8 Язык описания маршрутной политики RPSL    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP

    4.4.12 DNS (структура, обработка запросов, ресурсные записи)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети не последнюю роль играет сервер имен (DNS-система, RFC-2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706, -1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35). Сервер имен это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и ЭВМ вместе с их IP-адресами. Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkrley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS - преобразование символьного имени в IP-адрес и наоборот в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNS-серверами показана ниже на рисунке 4.4.12.1.

    Рис. 4.4.12.1. Структура взаимодействия с серверами имен

    База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Как уже отмечалось имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (двухсимвольные национальные коды смотри в приложении), или характер организации образовательная, коммерческая, правительственная и т.д.).

    Следующие 3-х символьные коды в конце Internet-адреса означают функциональную принадлежность узла:

    Таблица 4.4.12.1. Стандартизованные суффиксы имен

    Поле адреса

    Тип сети

    .com

    Коммерческая организация;

    .gov

    Государственное учреждение (США);

    .org

    Бесприбыльная организация;

    .edu

    Учебное заведение;

    .mil

    Военное предприятие или организация (США);

    .net

    Большая сеть;

    .int

    Международная организация;

    .arpa

    Специальный домен, используемый для преобразования ip-адреса в имя

    Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru - имя mvax-кластера в ИТЭФ, vxitep.itep.ru - имя vax-кластера, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

    Маленький фрагмент интернетовской иерархии имен показан на рис. 4.4.12.2. Число уровней реально больше, но обычно не превышает 5.

    Рис. 4.4.12.2. Иерархия имен в Интернет-DNS (I - домен первого уровня; II - второго уровня)

    Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен сходная с com/edu/org. Так в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk - для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна - существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен. Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах.

    Список корневых серверов вы можете получить с помощью анонимного ftp по адресам: nic.ddn.mil или ftp.rs.internic.net . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй - адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее - в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 4.4.12.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).

    Рис. 4.4.12.3. Формат dns-сообщений

    Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так число вопросов задает число записей в секции вопросов, где записаны запросы, требующие ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены в таблице 4.4.12.2. Разряды пронумерованы слева направо, начиная с нуля рис. 4.4.12.4.

    Рис. 4.4.12.4. Назначение битов поля флаги.

    Таблица 4.4.12.2. Коды поля флаги

    Код поля флаги

    Описание

    0 (qr)

    Операция:

    0 Запрос
    1 Отклик

    1.4

    Тип запроса (opcode):

    0 стандартный
    1 инверсный
    2 запрос состояния сервера

    5 (aa)

    Равен 1 при ответе от сервера, в ведении которого находится домен, упомянутый в запросе.

    6 (tc)

    Равен при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 октетов, но прислано только первые 512.

    7 (rd)

    Равен 1, если для получения ответа желательна рекурсия.

    8 (ra)

    Равен 1, если рекурсия для запрашиваемого сервера доступна.

    9.11

    Зарезервировано на будущее. Должны равняться нулю.

    12.15

    Тип отклика (rcode):

    0 нет ошибки
    1 ошибка в формате запроса
    2 сбой в сервере
    3 имени не существует

    Ниже описан формат секции вопросов в DNS-сообщении.

    Рис. . 4.4.12.5. Формат секции вопросов dns-запроса.

    Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой октеты длины):

    В реальной нотации байты длины субполя могут иметь два старших бита равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти ухищрения придуманы для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса:

    Таблица 4.4.12.3.. Разновидности полей тип запроса и их коды

    Тип запроса

    Код запроса

    Описание

    A

    1

    IP-адрес

    NS

    2

    Сервер имен.

    CNAME

    5

    Каноническое имя.

    SOA

    6

    Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.

    MB

    7

    Имя домена почтового ящика.

    WKS

    11

    well-known service - стандартная услуга.

    PTR

    12

    Запись указателя.

    HINFO

    13

    Информация об ЭВМ.

    MINFO

    14

    Информация о почтовом ящике или списке почтовых адресов.

    MX

    15

    Запись о почтовом сервере.

    TXT

    16

    Не интерпретируемая строка ASCII символов.

    AXFR

    252

    Запрос зонного обмена

    * или ANY

    255

    Запрос всех записей.

    (Пропущенные коды являются устаревшими или экспериментальными).

    Последние две строки в таблице 4.4.12.3 относятся только к вопросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] - 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса). Появление ресурсных полей в DNS базе данных придают ей новые качества. Каждая запись описывает только одно имя, формат этих записей отображен на рис. 4.4.12.6.

    Рис. 4.4.12.6. Формат ресурсных записей в DNS

    Имя домена в этой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 - это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.

    Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет собой октет IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив несколько запросов в домен IN-ADDR.ARPA относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат:

    IP_address

    Hard-addr

    Delay

    Date

    Host_name

    128.141.202.101

    00.00.0c.02.69.7d

    440

    10/10/95

    na48-1.cern.ch

    192.148.166.102

    00.00.a7.14.41.c2

    5

    10/10/95

    192.148.166.237

    00.00.0c.02.69.7d

    5

    10/10/95

    ITEP-M9.Relcom.ITEP.RU

    где в левой колонке записаны IP-адреса, имена которых ищутся, во второй - записаны аппаратные адреса интерфейсов, через которые доступны искомые объекты. Поскольку первая и третья строки относятся к внешним по отношению к узлу ITEP объектам, здесь записан адрес интерфейса пограничного маршрутизатора. В третьей колонке содержится значение RTT в мсек, а в оследней - имена объектов. IP-адресу 192.148.166.102 не соответствует никакого имени.

    Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNS-сервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 4.4.12.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала).

    host -t cname cernvm.cern.ch

    cernvm.cern.ch is a nickname for crnvma.cern.ch

    Напомним, что CNAME - каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias).

    host -t hinfo ns.itep.ru

    ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3

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

    host -t mx cl.itep.ru
    cl.itep.ru is a nickname for r02vax.itep.ru
    r02vax.itep.ru mail is handled by relay1.kiae.su
    r02vax.itep.ru mail is handled by relay2.kiae.su
    r02vax.itep.ru mail is handled by mx.itep.ru
    r02vax.itep.ru mail is handled by x4u2.desy.de

    host -v info.cern.ch
    Trying domain "itep.ru"
    rcode = 3 (Non-existent domain), ancount=0
    Trying null domain
    rcode = 0 (Success), ancount=2

    info.cern.ch

    86400

    IN

    CNAME

    www6.cern.ch

    www6.cern.ch

    86400

    IN

    A

    128.141.202.119

    Trying domain "itep.ru"
    rcode = 3 (Non-existent domain), ancount=0
    Trying null domain
    rcode = 0 (Success), ancount=1
    The following answer is not authoritative:

    www6.cern.ch

    86400

    IN

    A

    128.141.202.119

    For authoritative answers, see:

    CERN.CH

    52256

    IN

    NS

    dxmon.cern.ch

    CERN.CH

    52256

    IN

    NS

    ns.eu.net

    CERN.CH

    52256

    IN

    NS

    sunic.sunet.se

    CERN.CH

    52256

    IN

    NS

    scsnms.switch.ch

    Additional information:

    dxmon.cern.ch 79157 IN A 192.65.185.10
    ns.eu.net 56281 IN A 192.16.202.11
    sunic.sunet.se 85087 IN A 192.36.125.2
    sunic.sunet.se 85087 IN A 192.36.148.18
    scsnms.switch.ch 72545 IN A 130.59.1.30
    scsnms.switch.ch 72545 IN A 130.59.10.30

    Опция -v, используемая совместно с командой host позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 4.4.12.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MX-записями производится в следующих случаях:

    • Локальная сеть или ЭВМ не имеет непосредственной связи с Интернет, но желает участвовать в почтовом обмене (например, через UUCP-протокол).
    • Адресат не доступен и предпринимается попытка доставить почтовое сообщение альтернативной ЭВМ.
    • Создание виртуальных ЭВМ, куда можно пересылать почту.

    MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MX-записей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете напечатать команду (WKS - Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWS-сервера и пр.):

    host -tv wks ns.itep.ru
    ns.itep.ru WKS 193.124.224.35 udp domain tftp
    ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger

    Если вам нужно узнать IP-адреса того или иного узла можно также воспользоваться командой host:

    host vxdesy.desy.de
    vxdesy.desy.de has address 131.169.35.78
    vxdesy.desy.de has address 131.169.35.79
    vxdesy.desy.de has address 131.169.35.76
    vxdesy.desy.de has address 131.169.35.77

    Большая часть данных относится к типу "А".

    Выше уже говорилось, что для транспортировки DNS-запросов применяются протоколы UDP и TCP. Когда же следует использовать эти протоколы? Обычно используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами.

    Обычно реализация сервера имен (версия BIND - Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:

    named.boot - файл начальной загрузки сервера имен;
    named.local - стартовый файл клиента DNS;
    named.ca - исходный буфер имен и адресов.

    Это текстовые файлы, строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла-буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary. Эти строки содержат помимо имен субдоменов и файлов IP-адрес первичного DNS. Последний выполняет и функцию переадресации запросов вышестоящим серверам. Вторичный DNS-сервер при невозможности выполнить запрос переадресует его первичному серверу, а не вышестоящему. Первичный сервер может создавать большой кэш-буфер для локального обслуживания часто поступающих запросов.

    Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

    • номер версии файла (увеличивается каждый раз при внесении любых изменений, этот параметр отслеживается вторичным сервером);
    • время обновления данных (период запросов, посылаемых вторичным сервером первичному) в секундах;
    • длительность периода повторных попыток (retry) вторичного сервера в случае неудачи;
    • продолжительность пригодности данных (expiration time) в секундах, по истечении этого времени вторичный сервер считает всю базу данных устаревшей.
    • значение TTL по умолчанию.

    Запись может выглядеть как (RFC-1033):

    @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
    45 ;serial
    3600 ;refresh
    600 ;retry
    3600000 ;expire
    86400 ) ;minimum

    В файле приводится имя первичного сервера имен для данного субдомена (флаг NS) и имя администратора с указанием адреса его электронной почты. Последняя запись в файле содержит указатель на местную ЭВМ. Первая цифра в строке этой записи содержит суффикс IP-адреса этой машины.

    Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла можно считать следующее (взято из RFC-1033):

    ;list of possible root servers
    . 1 IN NS SRI-NIC.ARPA.
    NS C.ISI.EDU.
    NS BRL-AOS.ARPA.
    NS C.ISI.EDU.
    ;and their addresses
    SRI-NIC.ARPA. A 10.0.0.51
    A 26.0.0.73
    C.ISI.EDU. A 10.0.0.52
    BRL-AOS.ARPA. A 192.5.25.82
    A 192.5.22.82
    A 128.20.1.2
    A.ISI.EDU. A 26.3.0.103

    Первое поле представляет собой имя домена или субдомена, второе поле - значение TTL, третье - поле класс (Internet), четвертое - тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен.

    Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 ("Common DNS Implementation Errors and Suggested Fixes"). Ошибки при конфигурации DNS-сервера могут привести к досадным ошибкам и отказам системы. Обычно, при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNS-серверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них. Если клиент прислал рекурсивный запрос и сервер поддерживает рекурсию, запрос пересылается соответствующим серверам. Если рекурсия не поддерживается, сервер возвращает клиенту список DNS-серверов, предоставляя ему решать свои проблемы самостоятельно. Однако в некоторых случаях DNS-сервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов.

    Возможна и другая схема возникновения циклов запросов. Предположим, что сервер <1> содержит в своем списке внешних DNS сервер <2>, а последний в свою очередь содержит в своем списке сервер <1>. Такого рода перекрестные ссылки трудно обнаружить особенно, если в перечне фигурирует большое число серверов. Иногда возникает ситуация, когда клиент, получив список DNS-серверов, не знает, что с ним делать и посылает запрос повторно тому же серверу. Идентифицировать такого рода ошибки весьма трудно, особенно когда в это вовлечены внешние серверы, содержимое конфигурационных файлов которых недоступно.

    Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и никаких-либо данных клиенту. Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода "отклик" некорректным, он может послать запрос повторно и т.д. и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.

    В системах Windows часто используется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, также как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает использование протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service).

    WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 4.4.12.7.

    В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 4.4.12.8.

    Поле флаги имеет следующую структуру:

    0 _ _ _ _ _ _ _ Команда
    _ 000 0 _ _ _ Запрос
    _ _ _ _ _ _ 0 _ Не укорочено
    _ _ _ _ _ _ _ 0 Рекурсия нежелательна
    1 _ _ _ _ _ _ _ Отклик
    _ 000 0 _ _ _ Запрос
    _ _ _ _ _ _ 0 _ Не укорочено
    _ _ _ _ _ 1 _ _ Официальный ответ

    Для поля флаги имени характерна следующая структура

    0 _ _ _ _ _ _ _ Уникальное имя NetBIOS
    _ 10 _ _ _ _ _ Узел М-типа
    _ _ _ _ _ 1 _ _ Активное имя
    _ _ _ _ _ _ 0 _ Временное имя

    Для поля флагов имени группы характерно следующее назначение бит

    1 _ _ _ _ _ _ _ Имя группы NetBIOS
    _ 10 _ _ _ _ _ Узел М-типа
    _ _ _ _ _ 1 _ _ Активное имя
    _ _ _ _ _ _ 0 _ Временное имя

    В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решено путем использования цифровых подписей (RFC-2137).

    Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnarure).

    Previous: 4.4.11.8 Язык описания маршрутной политики RPSL    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP


    previous up down next index index
    Previous: 4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.13.1 Управляющая база данных MIB

    4.4.13 Протокол управления SNMP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP(Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

    Протокол snmp работает на базе транспортных возможностей UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212).

    Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (4.4.13.1) команд (pdu - protocol data unit) SNMP:

    Таблица 4.4.13.1 Команды SNMP

    Команда SNMP

    Тип PDU

    Назначение

    GET-request

    0

    Получить значение указанной переменной или информацию о состоянии сетевого элемента;

    GET_next_request

    1

    Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);

    SET-request

    2

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

    GET response

    3

    Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);

    TRAP

    4

    Отклик сетевого объекта на событие или на изменение состояния.

    GetBulkRequest

    5

    Запрос пересылки больших объемов данных, например, таблиц.

    InformRequest

    6

    Менеджер обращает внимание партнера на определенную информацию в MIB.

    SNMPv3-Trap

    7

    Отклик на событие (расширение по отношению v1 и v2).

    Report

    8

    Отчет (функция пока не задана).

    Рис. 4.4.13.1 Схема запросов/откликов snmp

    Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):

    Рис. 4.4.13.2 Формат snmp-сообщений, вкладываемых в UDP-дейтограммы

    Поле версия содержит значение, равное номеру версии snmp минус один. Поле пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:

    Таблица 4.4.13.2. Номера и назначения используемых портов

    Назначение

    Порт

    Пояснение

    SNMP

    161/TCP

    Simple Network Management Protocol

    SNMP

    162/TCP

    Trap

    SMUX

    199/TCP

    SNMP Unix Multiplexer

    SMUX

    199/UDP

    SNMP Unix Multiplexer

    synoptics-relay

    391/TCP

    SynOptics SNMP Relay Port

    synoptics-relay

    391/UDP

    SynOptics SNMP Relay Port

    agentx

    705/TCP

    AgentX

    snmp-tcp-port

    1993/TCP

    cisco SNMP TCP port

    snmp-tcp-port

    1993/UDP

    cisco SNMP TCP port

    Таблица 4.4.13.3. Коды ошибок

    Статус ошибки

    Имя ошибки

    Описание

    0

    Noerror

    Все в порядке;

    1

    Toobig

    Объект не может уложить отклик в одно сообщение;

    2

    Nosuchname

    В операции указана неизвестная переменная;

    3

    badvalue

    В команде set использована недопустимая величина или неправильный синтаксис;

    4

    Readonly

    Менеджер попытался изменить константу;

    5

    Generr

    Прочие ошибки.

    Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется. Таблица типов TRAPпредставлена ниже (4.4.13.4):

    Таблица 4.4.13.4. Коды TRAP

    Тип TRAP

    Имя TRAP

    Описание

    0

    Coldstart

    Установка начального состояния объекта.

    1

    Warmstart

    Восстановление начального состояния объекта.

    2

    Linkdown

    Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.

    3

    Linkup

    Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.

    4

    Authenticationfailure

    От менеджера получено snmp-сообщение с неверным паролем (community).

    5

    EGPneighborloss

    R$GP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера.

    6

    Entrprisespecific

    Информация о TRAP содержится в поле специальный код.

    Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.

    В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):

    Рис. 4.4.13.3. Формат заголовка SNMP-запроса

    Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 - длина пакета-запроса, начиная с T1 и до конца пакета, а L3 - длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО - статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

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

    Previous: 4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.13.1 Управляющая база данных MIB


    previous up down next index index
    Previous: 4.4.13 Протокол управления SNMP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.13.2 Нотация ASN.1

    4.4.13.1 Управляющая база данных MIB
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks).

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

    Согласно нормативам MIB управляющая информация делится на восемь категорий (см. также рис. 4.4.13.1.1):

    MIB-категория включает в себя информацию о

    MIB-категория

    Описание

    Код

    system

    Операционная система ЭВМ или маршрутизатора.

    1

    Interfaces

    Сетевой интерфейс.

    2

    addr.trans

    Преобразование адреса (напр., с помощью ARP).

    3

    IP

    Программная поддержка протоколов Интернет.

    4

    ICMP

    Программное обеспечение ICMP-протокола.

    5

    TCP

    Программное обеспечение TCP-протокола.

    6

    UDP

    Программное обеспечение UDP-протокола.

    7

    EGP

    Программное обеспечение EGP-протокола.

    8

    SNMP

    Программное обеспечение SNMP-протокола.

    11

    Таблица 4.4.13.1.1. Системные переменные MIB

    Системная переменная

    Описание

    Код

    Sysdescr

    Текстовое описание объекта;

    1

    Sysobjectid

    Идентификатор производителя в рамках дерева 1.3.6.1.4.1

    2

    Sysuptime

    Время с момента последней загрузки системы (timeticks);

    3

    Syscontact

    Имя системного менеджера и способы связи с ним;

    4

    Sysname

    Полное имя домена;

    5

    Syslocation

    Физическое местоположение системы;

    6

    Sysservice

    Величина, которая характеризует услуги, предоставляемые узлом (сумма номеров уровней модели OSI);

    7

    Таблица 4.4.13.1.2. Переменные IFtable (интерфейсы)

    Переменная описания интерфейсов (iftable)

    Тип данных

    Описание

    ifEntry

    IFindex

    integer

    Список интерфейсов от 1 до ifnumber.

    1

    IfDescr

    displaystring

    Текстовое описание интерфейса.

    2

    IfType

    integer

    Тип интерфейса, например, 6 - ethernet; 9 - 802.5 маркерное кольцо; 23 - PPP; 28 - SLIP.

    3

    IfNumber

    integer

    Число сетевых интерфейсов.

     

    IfMTU

    integer

    mtu для конкретного интерфейса;

    4

    IfSpeed

    gauge

    Скорость в бит/с.

    5

    IfPhysaddress

    physaddress

    Физический адрес или строка нулевой длины для интерфейсов без физического адреса (напр. последовательный).

    6

    IfAdminStatus

    [1...3]

    Требуемое состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.

    7

    IfOperStatus

    [1...3]

    Текущее состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется.

    8

    IfLastchange

    timeticks

    Sysuptime, когда интерфейс оказался в данном состоянии.

    9

    IfInOctets

    counter

    Полное число полученных байтов.

    10

    IfInUcastpkts

    counter

    Число пакетов, доставленных на верхний системный уровень (unicast).

    11

    IfInNUcastpkts

    counter

    Число пакетов, доставленных на верхний системный уровень (unicast).

    12

    IfInDiscads

    counter

    Число полученных но отвергнутых пакетов.

    13

    IfInErrors

    counter

    Число пакетов, полученных с ошибкой;

    14

    IfInUnknownProtos

    counter

    Число пакетов, полученных с ошибочным кодом протокола;

    15

    IfOutOctets

    counter

    Число отправленных байтов;

    16

    IfOutUcastPkts

    counter

    Число unicast- пакетов, полученных с верхнего системного уровня;

    17

    IfOutNucastPkts

    counter

    Число мультикастинг- и широковещательных пакетов, полученных с верхнего системного уровня;

    18

    IfOutDiscads

    counter

    Количество отвергнутых пакетов из числа отправленных;

    19

    IfOutErrors

    counter

    Число отправленных пакетов, содержащих ошибки;

    20

    IfOutQlen

    gauge

    Число пакетов в очереди на отправку;

    21

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

    Название объекта Цифра-точечное представление
    org 1.3
    dod 1.3.6
    internet 1.3.6.1
    directory 1.3.6.1.1
    mgmt 1.3.6.1.2
    experimental 1.3.6.1.3
    private 1.3.6.1.4
    enterprises 1.3.6.1.4.1
    security 1.3.6.1.5
    snmpV2 1.3.6.1.6
    snmpDomains 1.3.6.1.6.1
    snmpProxys 1.3.6.1.6.2
    snmpModules 1.3.6.1.6.3
    snmpMIB 1.3.6.1.6.3.1
    snmpMIBObjects 1.3.6.1.6.3.1.1
    snmpTraps 1.3.6.1.6.3.1.1.5
    mib-2 1.3.6.1.2.1
    ifMIB 1.3.6.1.2.1.31
    interfaces 1.3.6.1.2.1.2
    ifMIBObjects 1.3.6.1.2.1.31.1
    ifConformance 1.3.6.1.2.1.31.2
    ifTableLastChange 1.3.6.1.2.1.31.1.5
    ifXTable 1.3.6.1.2.1.31.1.1
    ifStackTable 1.3.6.1.2.1.31.1.2
    ifStackLastChange 1.3.6.1.2.1.31.1.6
    ifRcvAddressTable 1.3.6.1.2.1.31.1.4
    ifTestTable 1.3.6.1.2.1.31.1.3
    ifXEntry 1.3.6.1.2.1.31.1.1.1
    ifName 1.3.6.1.2.1.31.1.1.1.1
    ifInMulticastPkts 1.3.6.1.2.1.31.1.1.1.2
    ifInBroadcastPkts 1.3.6.1.2.1.31.1.1.1.3
    ifOutMulticastPkts 1.3.6.1.2.1.31.1.1.1.4
    ifOutBroadcastPkts 1.3.6.1.2.1.31.1.1.1.5
    ifLinkUpDownTrapEnable 1.3.6.1.2.1.31.1.1.1.14
    ifHighSpeed 1.3.6.1.2.1.31.1.1.1.15
    ifPromiscuousMode 1.3.6.1.2.1.31.1.1.1.16
    ifConnectorPresent 1.3.6.1.2.1.31.1.1.1.17
    ifAlias 1.3.6.1.2.1.31.1.1.1.18
    ifCounterDiscontinuityTime 1.3.6.1.2.1.31.1.1.1.19
    ifStackEntry 1.3.6.1.2.1.31.1.2.1
    ifStackHigherLayer 1.3.6.1.2.1.31.1.2.1.1
    ifStackLowerLayer 1.3.6.1.2.1.31.1.2.1.2
    ifStackStatus 1.3.6.1.2.1.31.1.2.1.3
    ifRcvAddressEntry 1.3.6.1.2.1.31.1.4.1
    ifRcvAddressAddress 1.3.6.1.2.1.31.1.4.1.1
    ifRcvAddressStatus 1.3.6.1.2.1.31.1.4.1.2
    ifRcvAddressType 1.3.6.1.2.1.31.1.4.1.3
    ifTestEntry 1.3.6.1.2.1.31.1.3.1
    ifTestId 1.3.6.1.2.1.31.1.3.1.1
    ifTestStatus 1.3.6.1.2.1.31.1.3.1.2
    ifTestType 1.3.6.1.2.1.31.1.3.1.3
    ifTestResult 1.3.6.1.2.1.31.1.3.1.4
    ifTestCode 1.3.6.1.2.1.31.1.3.1.5
    ifTestOwner 1.3.6.1.2.1.31.1.3.1.6
    ifGroups 1.3.6.1.2.1.31.2.1
    ifCompliances 1.3.6.1.2.1.31.2.2
    ifGeneralInformationGroup 1.3.6.1.2.1.31.2.1.10
    ifFixedLengthGroup 1.3.6.1.2.1.31.2.1.2
    ifHCFixedLengthGroup 1.3.6.1.2.1.31.2.1.3
    ifPacketGroup 1.3.6.1.2.1.31.2.1.4
    ifHCPacketGroup 1.3.6.1.2.1.31.2.1.5
    ifVHCPacketGroup 1.3.6.1.2.1.31.2.1.6
    ifRcvAddressGroup 1.3.6.1.2.1.31.2.1.7
    ifStackGroup2 1.3.6.1.2.1.31.2.1.11
    ifCounterDiscontinuityGroup 1.3.6.1.2.1.31.2.1.13
    ifGeneralGroup 1.3.6.1.2.1.31.2.1.1
    ifTestGroup 1.3.6.1.2.1.31.2.1.8
    ifStackGroup 1.3.6.1.2.1.31.2.1.9
    ifOldObjectsGroup 1.3.6.1.2.1.31.2.1.12
    ifCompliance2 1.3.6.1.2.1.31.2.2.2
    ifCompliance 1.3.6.1.2.1.31.2.2.1
    ifNumber 1.3.6.1.2.1.2.1
    ifTable 1.3.6.1.2.1.2.2
    ifEntry 1.3.6.1.2.1.2.2.1
    ifIndex 1.3.6.1.2.1.2.2.1.1
    ifDescr 1.3.6.1.2.1.2.2.1.2
    ifType 1.3.6.1.2.1.2.2.1.3
    ifMtu 1.3.6.1.2.1.2.2.1.4
    ifSpeed 1.3.6.1.2.1.2.2.1.5
    ifPhysAddress 1.3.6.1.2.1.2.2.1.6
    ifAdminStatus 1.3.6.1.2.1.2.2.1.7
    ifOperStatus 1.3.6.1.2.1.2.2.1.8
    ifLastChange 1.3.6.1.2.1.2.2.1.9
    ifInOctets 1.3.6.1.2.1.2.2.1.10
    ifInUcastPkts 1.3.6.1.2.1.2.2.1.11
    ifInNUcastPkts 1.3.6.1.2.1.2.2.1.12
    ifInDiscards 1.3.6.1.2.1.2.2.1.13
    ifInErrors 1.3.6.1.2.1.2.2.1.14
    ifInUnknownProtos 1.3.6.1.2.1.2.2.1.15
    ifOutOctets 1.3.6.1.2.1.2.2.1.16
    ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17
    ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18
    ifOutDiscards 1.3.6.1.2.1.2.2.1.19
    ifOutErrors 1.3.6.1.2.1.2.2.1.20
    ifOutQLen 1.3.6.1.2.1.2.2.1.21
    ifSpecific 1.3.6.1.2.1.2.2.1.22

    Таблица 4.4.13.1.3. Переменные IP-группы

    Переменная IP-группы

    Тип данных

    Описание

    Код

    ipForwarding

    integer

    Указание на то, что данный объект осуществляет переадресацию (работает как маршрутизатор).

    1

    IPdefaultTTL

    integer

    Значение, которое использует IP в поле TTL.

    2

    IPinreceives

    counter

    Число полученных дейтограмм.

    3

    ipInHdrErrors

    counter

    Число дейтограмм, отвергнутых из-за ошибок формата или неверных адресов или опций, из-за истекшего TTL.

    4

    ipInHdrErrors

    counter

    Число дейтограмм, отвергнутых из-за неверного IP-адреса, например, 0.0.0.0, или неподдерживаемого класса, например Е.

    5

    ipForwDatagrams

    counter

    Число дейтограмм, для которых данный объект не является местом назначения (маршрутизация отправителя).

    6

    ipInUnknownProtos

    counter

    Число дейтограмм с неподдерживаемым кодом протокола.

    7

    ipInDiscards

    counter

    Число дейтограмм, отвергнутых из-за переполнения буфера.

    8

    ipInDelivers

    counter

    Полное число входных дейтограмм, успешно обработанных на IP-уровне.

    9

    ipOutRequests

    counter

    Полное число IP и ICMP дейтограмм, переданных для отправки.

    10

    ipOutRequests

    counter

    Полное число IP и ICMP дейтограмм, переданных для отправки.

    11

    IPoutNoroutes

    counter

    Число неудач при маршрутизации.

    12

    ipReasmTimeout

    counter

    Максимальное число секунд ожидания сборки фрагментов.

    13

    ipReasmReqds

    counter

    Число полученных фрагментов

    14

    ipReasmOKs

    counter

    Число полученных и успешно собранных IP-дейтограмм

    15

    ipReasmFails

    counter

    Число полученных IP-дейтограмм, которые по тем или иным причинам не удалось собрать

    16

    IPFragOKs

    counter

    Число успешно фрагментированных IP- дейтограмм.

    17

    ipFragFails

    counter

    Число IP- дейтограмм, которые нужно фрагментировать, но сделать это нельзя (например, из-за флага).

    18

    ipFragCreates

    counter

    Число IP-дейтограмм фрагментов, сформированных данным объектом.

    19

    ipAddrTable

    counter

    Таблица адресной информации данного объекта.

    20

    ipRouteTable

    Последовательность записей маршрутной таблицы

    Запись в маршрутной таблице

    21
    ipAddrEntry

    IPAdEntAddr

    IPaddress

    IP-адрес для данного ряда

    1

    IPadentifindex

    integer

    Число интерфейсов.

    2

    IPadentnetmask

    IPaddress

    Маска субсети для данного IP-адреса;

    3

    IPAdEntBcastAddr

    [0...1]

    Значение младшего бита широковещательного адреса (обычно 1);

    4

    IPAdEntReasmMaxsize

    [0...65535]

    Размер наибольшей IP-дейтограммы, полученной интерфейсом, которая может быть собрана.

    5

    Помимо простых переменных объектами MIB могут быть таблицы. Для каждой таблицы имеется один или несколько индексов.

    Таблица 4.4.13.1.4. Переменные TCP-группы

    Переменные TCP-группы

    Тип данных

    Описание

    Код

    tcpRtoAlgorithm

    integer

    Алгоритм выявления таймаута для повторной передачи TCP-пакетов: 1 - ни один из следующих; 2 - постоянное RTO; 3 - стандарт MIL-std-1778; 4 - алгоритм Ван Джакобсона

    1

    tcpRtoMin

    integer

    Минимальное допустимое время повторной передачи tcp- пакетов.

    2

    tcpRtoMax

    integer

    Максимальное значение тайм-аута в миллисек.

    3

    tcpMaxConn

    integer

    Максимальное допустимое число tcp-соединений.

    4

    tcpActiveOpens

    integer

    Число TCP-соединений Active-Open

    5

    tcpPassiveOpens

    integer

    Число TCP-соединений Passive-Open (из состояния LISTEN)

    6

    tcpAttemptFails

    integer

    Число неудачных TCP-соединений

    7

    tcpEstabResets

    integer

    Число разрывов TCP-соединений из состояний ESTABLISHED или CLOSE-WAIT

    8

    tcpCurrEstab

    Gauge

    Число TCP-соединений, для которых текущее состояние ESTABLISHED или CLOSE-WAIT

    9

    tcpInSegs

    counter

    Полное число полученных tcp-сегментов.

    10

    tcpOutSegs

    counter

    Полное число посланных сегментов, исключая повторно пересылаемые.

    11

    tcpRetransSegs

    counter

    Полное число повторно пересланных сегментов.

    12

    tcpConnTable

    counter

    Таблица данных специфичных для соединения

    13

    tcpInErrs

    counter

    Полное число сегментов, полученных с ошибкой.

    14

    tcpOutRsts

    counter

    Полное число посланных сегментов с флагом rst=1.

    15

    tcpconntable. tcp-таблица связей

    tcpconnstate

    [1...12]

    Состояние соединения: 1 - closed; 2 - listen; 3 - syn_sent; 4 - syn_rcvd; 5 - established, 6 - fin_wait_1; 7 - fin_wait_2; 8 - close_wait; 9 - last_ack; 10 - closing; 11 - time_wait;, 12 - delete TCB. Только последняя переменная может устанавливаться менеджером, немедленно прерывая связь.

    tcpconnlocal
    address

    ipaddress

    Местный IP-адрес. 0.0.0.0 означает, что приемник готов установить связь через любой из интерфейсов.

    tcpconnlocal
    port

    [0...65535]

    Местный номер порта.

    tcpconnlocal
    address

    ipaddress

    Удаленный ip-адрес.

    tcpconnrem
    port

    [0...65535]

    Удаленный номер порта.

    Таблица 4.4.13.1.5. Переменные ICMP-группы (тип данных - counter)

    Переменная icmp-группы

    Описание

    Код

    icmpInMsgs

    Полное число полученных ICMP-сообщений.

    1

    icmpInErrors

    Число ICMP-сообщений, полученных с ошибками.

    2

    icmpInDestUnreach

    Число ICMP-сообщений о недостижимости адресата.

    3

    icmpintimeexcds

    Число ICMP-сообщений об истечении времени.

    4

    icmpInParmProbs

    Число полученных ICMP-сообщений о проблемах с параметрами.

    5

    icmpInSrcQuench

    Число ICMP-сообщений с требованием сократить или прервать посылку пакетов из-за перегрузки.

    6

    icmpInRedirects

    Число ICMP-сообщений о переадресации.

    7

    icmpInEchos

    Число полученных ICMP-запросов отклика.

    8

    icmpInEchoReps

    Число полученных ICMP-эхо- откликов.

    9

    icmpInTimestamps

    Число ICMP-запросов временных меток.

    10

    icmpInTimestampReps

    Число ICMP-откликов временных меток.

    11

    icmpInAddrMasks

    Число ICMP-запросов адресных масок.

    12

    icmpInAddrMaskReps

    Число ICMP-откликов на запросы адресных масок.

    13

    icmpOutMsgs

    Число отправленных ICMP- сообщений.

    14

    icmpOutErrors

    Число не отправленных ICMP- сообщений из-за проблем в ICMP (напр. нехватка буферов).

    15

    icmpOutDestUnreachs

    Число ICMP-сообщений о недоступности адресата.

    16

    icmpOutTimesExcds

    Число посланных ICMP-сообщений об истечении времени.

    17

    icmpOutParmProbs

    Число посланных ICMP-сообщений о проблемах с параметрами.

    18

    icmpOutSrcQuench

    Число посланных ICMP-сообщений об уменьшении потока пакетов.

    19

    icmpOutRedirects

    Число посланных ICMP-сообщений о переадресации.

    20

    icmpOutEchos

    Число посланных ICMP-эхо-запросов.

    21

    icmpOutEchoReps

    Число посланных ICMP-эхо-откликов.

    22

    icmpOutTimestamps

    Число посланных ICMP-запросов временных меток.

    23

    icmpOutTimestampReps

    Число посланных ICMP-откликов на запросы временных меток.

    24

    icmpOutAddrMasks

    Число посланных ICMP-запросов адресных масок.

    25

    Таблица 4.4.13.1.6. Переменные AT-группы (attable, преобразование адресов).

    Переменные at-группы

    Тип данных

    Описание

    atEntry

    atIfIndex

    integer

    Число интерфейсов.

    1

    atPhysAddress

    physaddress

    Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует.

    2

    atNetAddress

    networkaddress

    IP-адрес.

    3

    Каждый протокол (например IP) имеет свою таблицу преобразования адресов. Для IP это ipnettomediatable. Способ пропечатать эту таблицу с помощью программы SNMPI описан ниже.

    MIB II содержит управляемые объекты, принадлежащие к группе snmp. SNMP-группа предоставляет информацию о SNMP-объектах, информационных потоках, о статистике ошибок:

    Название объекта

    Описание

    Код

    snmpInPkts

    Число пакетов, полученных от слоя, расположенного ниже SNMP.

    1

    snmpOutPkts

    Число пакетов доставленных от SNMP к нижележащему слою.

    2

    snmpInBadVersions

    Индицирует число PDU, полученных с ошибкой в поле версия.

    3

    snmpInBadCommunityNames

    Индицирует число PDU, полученных с нечитаемым или нелегальным именем community.

    4

    snmpInBadCommunityUses

    Полное число SNMP-пакетов, полученных с нечитаемым или нелегальным значение операции для данного имени community.

    5

    snmpInAsnParsErrs

    Указывает полное число ошибок ASN.1 или BER, которые не могут быть обработаны во входных SNMP-сообщениях

    6

    snmpInTooBigs

    Указывает число полученных PDU со слишком большим значением поля статус ошибки.

    8

    snmpInNoSuchNames

    Указывает число PDU, полученных с индикацией ошибки в поле nosuchname.

    9

    snmpInBadValues

    Указывает число PDU, полученных с индикацией ошибки в поле badvalue.

    10

    snmpInReadOnlys

    Указывает число PDU, полученных с индикацией ошибки в поле readonly.

    11

    snmpNnGenErrs

    Указывает число PDU, полученных с generr-полем.

    12

    snmpInTotalReqVar

    Указывает число объектов MIB, которые были восстановлены.

    13

    snmpInTotalSetVars

    Указывает число объектов MIB, которые были изменены.

    14

    snmpInGetRequests

    Указывает число соответствующих pdu, которые были получены.

    15

    snmpInGetNexts

    Указывает полное число pdu с запросами GetNext

    16

    snmpInSetRequests

    Указывает полное число pdu, полученных с запросами SET

    17

    snmpInGetResponses

    Указывает полное число pdu, полученных c откликами на запросы

    18

    snmpInTraps

    Указывает полное число, полученных и успешно обработанныз TRAP

    19

    snmpOutTooBig

    Указывает число посланных PDU с полем toobig.

    20

    snmpOutNoSuchNames

    Указывает число посланных PDU с полем nosuchname.

    21

    snmpOutBadValues

    Указывает число посланных PDU с полем badvalue.

    22

    snmpOutGenErrs

    Указывает число посланных PDU с полем genErrs.

    24

    snmpOutGetRequests

    Указывает число посланных PDU Get-Request

    25

    snmpOutGetNexts

    Указывает число посланных PDU Get-NEXT

    26

    snmpOutSetRequests

    Указывает число посланных PDU SET

    27

    snmpOutGetResponses

    Указывает число посланных PDU откликов

    28

    snmpOutTraps

    Указывает число посланных PDU TRAPs

    29

    snmpEnableAuthTraps

    Говорит о том, разрешены или нет ловушки (TRAPS).

    30

    Стандарт на структуру управляющей информации (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ASN.1 (abstract syntax notation 1, формализованный синтаксис). ASN.1 является формальным языком, который обладает двумя основными чертами:

    используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. В SMI не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: integer, octet string, object identifier и null. Практически в протоколе SNMP фигурируют следующие виды данных:

    integer. Некоторые переменные объявляются целыми (integer) с указанием начального значения или с заданным допустимым диапазоном значений (в качестве примера можно привести номера UDP- или TCP-портов).

    octet string (последовательность байтов). В соответствии с требованиями BER (basic encoding rules, ASN.1) последовательность октетов должна начинаться с числа байт в этой последовательности (от 0 до n).

    object identifier (идентификатор объекта). Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5.

    null. Указывает, что соответствующая переменная не имеет значения.

    displaystring. Строка из 0 или более байт (но не более 255), которые представляют собой ASCII-символы. Представляет собой частный случай octet string.

    physaddress. Последовательность октетов, характеризующая физический адрес объекта (6 байт для Ethernet). Частный случай object identifier.

    Сетевой адрес. Допускается выбор семейства сетевых протоколов. В рамках ASN.1 этот тип описан как choice, он позволяет выбрать протокол из семейства протоколов. В настоящее время идентифицировано только семейство протоколов Интернет.

    IP-адрес. Этот адрес используется для определения 32-разрядного Интернет-адреса. В нотации ASN.1 - это octet string.

    time ticks (такты часов). Положительное целое число, которое используется для записи, например, времени последнего изменения параметров управляемого объекта, или времени последней актуализации базы данных. Время измеряется в сотых долях секунды.

    gauge (масштаб). Положительное целое число в диапазоне 0 - (232-1), которое может увеличиваться или уменьшаться. Если эта переменная достигнет величины 232-1, она будет оставаться неизменной до тех пор пока не будет обнулена командой сброс. Примером такой переменной может служить tcpcurresta, которая характеризует число TCP соединений, находящихся в состоянии established или close_wait.

    counter (счетчик). Положительное целое число в диапазоне 0 - (232-1), которое может только увеличиваться, допуская переполнение.

    sequence. Этот объект аналогичен структуре в языке Си.

    Например, MIB определяет sequence с именем udpentry, содержащую информацию об активных UDP-узлах. В этой структуре содержится две записи:

    1. UDPlocaladdress типа ipaddress, содержит местные IP-адреса.

    2. UDPlocalport типа integer, содержит номера местных портов.

    SEQUENCE OF. Описание вектора, все элементы которого имеют один и тот же тип. Элементы могут представлять собой простые объекты, например, типа целое. В этом случае мы имеем одномерный список. Но элементами вектора могут быть объекты типа SEQUENCE, тогда этот вектор описывает двумерный массив.

    В Интернет MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.

    Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT. Структура имен носит иерархический характер, отображенный на рис. 4.4.13.1.1.

    Рис. 4.4.13.1.1 Структура идентификаторов переменных в MIB

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

    Имя переменной

    Тип данных

    Описание

    Код

    udpInDatagrams

    counter

    Число UDP-дейтограмм, присланных процессам пользователя.

    1

    udpNoPorts

    counter

    Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения.

    2

    udpInErrors

    counter

    Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы).

    3

    udpOutDatagrams

    counter

    Число посланных UDP-дейтограмм.

    4

    udpTable

    counter

    Таблица, содержащая данные о принимающей стороне

    5

    Ниже приведено описание таблицы (udptable; index = ,), состоящей из двух простых переменных (read-only).

    Имя переменной

    Тип данных

    Описание

    udplocaladdress

    ipaddress

    Местный IP-адрес для данного приемника;

    udplocalport

    (0 - 65535)

    Местный номер порта приемника.

    Согласно этой иерархии переменные, соответствующие ICMP, должны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символьном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хотите узнать значение какой-то переменной, следует послать запрос, содержащий соответствующий префикс и суффикс, последний определяет имя конкретной переменной. Для простой переменной суффикс имеет вид .0. Ветвь структуры на рис. 4.4.13.1.1, завершающейся узлом Interfaces (2) имеет продолжение в виде ifTable(2) и ifEntry(1). Таким образом переменная ifInUcastPkts будет иметь представление 1.3.6.1.2.1.2.2.1.11.

    Помимо стандартного набора переменных и таблиц MIB возможно использование индивидуальных расширений этой базы данных. Это можно продемонстрировать на примере MIB маршрутизаторов Cisco (рис. 4.4.13.1.2).

    Рис. 4.4.13.1.2. Расширение базы данных mib маршрутизаторов Cisco

    Префикс 1.3.6.1.4.1. является стандартным, далее следует расширение, индивидуальное для маршрутизаторов компании Cisco. Например, группа IPcheckpoint accounting позволяет контролировать поток байтов с определенных адресов локальной сети, что бывает важно при работе с коммерческими провайдерами услуг.

    Коды-префиксы для различных производителей телекоммуникационного оборудования приведены в таблице 4.4.13.1.7.

    Таблица 4.4.13.1.7 Коды-префиксы производителей

    Код префикса

    Название фирмы

    0

    Зарезервировано

    1

    Proteon

    2

    IBM

    3

    CMU

    4

    UNIX

    5

    ACC

    6

    TWG

    7

    Cayman

    8

    PSI

    9

    Cisco

    10

    NSC

    11

    HP

    12

    Epilogue

    13

    U of Tennessee

    14

    BBN

    15

    Xylogics, inc.

    16

    Unisys

    17

    Canstar

    18

    Wellfleet

    19

    TRW

    20

    MIT

    Группа локальных переменных IP checkpoint accounting (1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в каждом рекорде по четыре переменных (в скобках указан суффикс адреса MIBдля переменной):

    • ckactbyts [4] - число переданных байт,
    • ckactdst [2] - адрес места назначения,
    • ckactpkts [3] - число переданных пакетов
    • ckactsrc [1] - адрес отправителя

    Маршрутизаторы Cisco поддерживают две базы данных: active accounting и checkpoint accounting. В первую заносятся текущие результаты измерения входящего и исходящего трафика. Эти результаты копируются в базу данных checkpoint accounting и, если там уже имеются предыдущие данные, они объединяются. Для очистки базы данных checkpointed database выдается команда clear IP accounting, а для базы checkpoint - clear IP accounting checkpoint (для использования этих команд необходимы системные привилегии). Объем памяти, выделяемой для этих баз данных задается командой IP accounting-threshold <значение>, по умолчанию максимальное число записей в базе данных равно 512.

    Лучшим способом закрепить в памяти все вышесказанное является использование программы SNMPI (SNMP initiator) или ее аналога. Если в вашем распоряжении имеется ЭВМ, работающая под unix, например SUN, вы можете попутно узнать много полезного о вашей локальной сети. Ниже описан синтаксис обращения к SNMPI.

    snmpi [-a agent] [-c community] [-f file] [-p portno] [-d] [-v] [-w]

    SNMPI - крайне простая программа, используемая для тестирования SNMPD. Для того чтобы проверить, работает ли она, выдайте команду:

    % SNMPI dump

    Следует отметить, что в ответ на эту операцию будет произведена весьма объемная выдача.

    Опция -a предлагает возможность ввести адрес SNMP-объекта - имя ЭВМ, IP-адрес или транспортный адрес. По умолчанию это местная ЭВМ. Аналогично опция -p позволяет задать номер UDP-порта. По умолчанию это порт 161.

    Опция -c позволяет задать групповой пароль (community) для snmp-запроса. По умолчанию - это public, т.е. свободный доступ.

    Опция -f позволяет выбрать файл, содержащий откомпилированные описания mib-модулей. По умолчанию - это objects.defs.

    Опция -w включает режим наблюдения, осуществляя выдачу на терминал всех служебных сообщений. Уход из программы по команде quit (q).

    Если вы работаете на IBM/PC, и ваша машина подключена к локальной сети, получите допуск к одной из UNIX-машин в сети (если вы его не имели) и приступайте. Можно начать с обращения типа:

    SNMPI -a 193.124.224.33 (адрес или символьное имя надо взять из вашей локальной сети)

    Машина откликнется, отобразив на экране SNMPI>, это означает, что программа имеется и вы можете вводить любые команды.

    Начать можно со знакомства с системными переменными системы (в дальнейшем курсивом выделены команды, введенные с клавиатуры):

    SNMPI> get sysdescr.0

    snmpi> sysdescr.0="GS software (gs3-k), version 9.1(4) [fc1], software copyright (c) 1986-1993 by cisco systems, inc. compiled thu 25-mar-93 09:49 by daveu"

    snmpi> get sysobjectid.0
    snmpi> sysobjectid.0=1.3.6.1.4.1.9.1.1
    snmpi> get sysuptime.0
    snmpi> sysuptime.0=14 days, 7 hours, 0 minutes, 15.27 seconds (123481527 timeticks)
    snmpi> get sysservices.0
    snmpi> sysservices.0=0x6

    Код 0x06 (sysservices.0) представляет собой сумму кодов уровней модели iso, поддерживаемых системой. Для справок: 0x01 - физический уровень; 0x02 - связной уровень; 0x04 - Интернет; 0x08 - связь точка-точка; 0x40 - прикладной уровень.

    Если вы хотите получить информацию о состоянии интерфейсов на одной из ЭВМ, подключенных к вашей локальной сети (команды вызова snmpi далее не повторяются; в ниже приведенных примерах в круглых скобках помещены комментарии автора), выдайте команды:

    SNMPI> next iftabl (команда next в данном случае соответствует запросу get-next, здесь понятие "следующий" подразумевает порядок переменных в MIB)

    snmpi> ifindex.1=1
    snmpi> get ifdescr.1
    snmpi> ifdescr.1="ethernet0"
    snmpi> get iftype.1
    snmpi> iftype.1=ethernet-csmacd(6)
    snmpi> get ifmtu.1
    snmpi> ifmtu.1=1500
    snmpi> get ifspeed.1
    snmpi> ifspeed.1=10000000 (10Мб/с ethernet)
    snmpi> get ifphysaddress.1
    snmpi> ifphysaddress.1=0x00:00:0c:02:3a:49 (физический адрес интерфейса)
    snmpi> next ifdescr.1 iftype.1 ifmtu.1 ifspeed.1 ifphysaddress.1
    snmpi> ifdescr.2="serial0"
    iftype.2=proppointtopointserial(22)
    ifmtu.2=1500

    ifspeed.2=2048000 (2 Мбит/c радиорелейный последовательный канал, спутниковый канал был бы охарактеризован точно также).

    ifphysaddress.2=

    В приведенном примере размеры пересылаемых блоков для Ethernet и радиорелейного последовательного канала идентичны и равны 1500. Помните, что SLIP-канал характеризуется как pointtopointserial, а не slip. Скорость обмена по SLIP-каналу не сообщается.

    Теперь просмотрим некоторые UDP-переменные. Например:

    SNMPI> next UDP
    SNMPI> udpindatagrams.0=98931
    SNMPI> next udpindatagrams.0 (обратите внимание на суффикс простой переменной)
    SNMPI> udpnoports.0=60009
    SNMPI> next udplocaladdress.0
    SNMPI>udplocaladdress.193.124.137.14.7=193.124.137.14

    (Идентификатор этого объекта - 1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.)

    SNMPI> next udplocalport
    SNMPI> udplocalport.193.124.137.14.7=7
    Если у вас возникла необходимость просмотреть таблицу, например, udptable, это
    также можно сделать, используя snmpi:
    SNMPI> next udptable
    SNMPI> udplocaladdress.193.124.137.14.7=193.124.137.14
    SNMPI> next udplocaladdress.193.124.137.14.7
    SNMPI> udplocaladdress.193.124.224.33.67=193.124.224.33
    SNMPI> next udplocaladdress.193.124.224.33.67
    SNMPI> udplocaladdress.193.124.224.33.161=193.124.224.33
    SNMPI> next udplocalport.193.124.224.33.67
    SNMPI> udplocalport.193.124.224.33.161=161

    Ниже показана методика выяснения алгоритма и параметров задания величины тайм-аута:

    SNMPI> get tcprtoalgorithm.0 tcprtomin.0 tcprtomax.0 tcpmaxconn.0
    SNMPI> tcprtoalgorithm.0=vanj(4) (vanj - алгоритм Ван Джакобсона для расчета времени тайм-аута)

    tcprtomin.0=300

    (минимальное значение тайм-аута = 300 мс)

    tcprtomax.0=60000

    (максимальное - 60 сек)

    tcpmaxconn.0=-1

    (никаких ограничений на число соединений)

    Чтобы получить информацию о состоянии таблицы адресных преобразований, выдайте команду: SNMPI -a 193.124.224.33 dump at (процедуры с использование субкоманды dump требуют определенного времени для своего исполнения)

    atifindex.1.1.193.124.224.33=

    1

    atifindex.1.1.193.124.224.35=

    1

    atifindex.3.1.192.148.166.203=

    3

    atifindex.3.1.192.148.166.205=

    3

    atifindex.5.1.145.249.30.33=

    5

    atifindex.5.1.192.148.166.98=

    5

    atphysaddress.1.1.193.124.224.33=

    0x00:00:0c:02:3a:49

    atphysaddress.1.1.193.124.224.35=

    0x08:00:20:12:1b:b1

    atphysaddress.1.1.193.124.224.40=

    0x00:00:cd:f9:0d:e7

    atphysaddress.1.1.193.124.224.50=

    0x00:00:0c:02:fb:c5

    atnetaddress.1.1.193.124.224.33=

    193.124.224.33

    atnetaddress.1.1.193.124.224.35=

    193.124.224.35

    atnetaddress.1.1.193.124.224.40=

    193.124.224.40

    atnetaddress.1.1.193.124.224.50=

    193.124.224.50

    atnetaddress.1.1.193.124.224.60=

    193.124.224.60

    Текст выдачи с целью экономии места сокращен.

    Обычно элементы таблицы расположены в порядке колонка-ряд. Если вы дошли до края колонки или всей таблицы ЭВМ выдаст вам, в зависимости от реализации программы, имя и значение следующего элемента или сообщение об ошибке.

    Чтобы получить полный текст адресной таблицы в рамках SNMPI достаточно выдать команду:

    SNMPI> dump ipaddrtable

    snmpi> ipadentaddr.192.148.166.222=

    192.148.166.222

    ipadentaddr.192.168.1.1=

    192.168.1.1

    ipadentaddr.192.168.1.2=

    192.168.1.2

    ipadentaddr.193.124.224.33=

    193.124.224.33

    ipadentaddr.193.124.224.190=

    193.124.224.190

    ipadentifindex.192.148.166.222=

    3

    ipadentifindex.192.168.1.1=

    4

    ipadentifindex.192.168.1.2=

    6

    ipadentifindex.193.124.224.33=

    1

    ipadentifindex.193.124.224.190=

    5

    (Маски субсетей)

    ipadentnetmask.192.148.166.222=

    255.255.255.224

    ipadentnetmask.192.168.1.1=

    255.255.255.0

    ipadentnetmask.192.168.1.2=

    255.255.255.0

    ipadentnetmask.193.124.224.33=

    255.255.255.224

    ipadentnetmask.193.124.224.190=

    255.255.255.224

    ipadentbcastaddr.192.148.166.222= 1 (Все эти субсети используют для широковещательной адресации одни и те же биты).

    ipadentbcastaddr.192.168.1.1=

    1

    ipadentbcastaddr.192.168.1.2=

    1

    ipadentbcastaddr.193.124.224.33=

    1

    ipadentbcastaddr.193.124.224.190=

    1

    ipadentreasmmaxsize.192.148.166.222= 18024 (С точки зрения фрагментации и последующей сборки дейтограмм данные субсети эквивалентны).

    ipadentreasmmaxsize.192.168.1.1=

    18024

    ipadentreasmmaxsize.192.168.1.2=

    18024

    ipadentreasmmaxsize.193.124.224.33=

    18024

    ipadentreasmmaxsize.193.124.224.190=

    18024

    Данная пропечатка совместно с приведенной для IFtable позволяет получить достаточно полную картину о данной конкретной локальной сети. Чтобы познакомиться с ARP таблицей, можно воспользоваться командой:

    sun> arp -a

    itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49
    nb.itep.ru (193.124.224.60) at 0:80:ad:2:24:b7

    и дополнить полученные данные с помощью SNMPI:

    SNMPI> dump ipnettomediatable

    SNMPI> ipnettomediaifindex.1.193.124.224.33= 1
    ipnettomediaifindex.1.193.124.224.35= 1
    ipnettomediaifindex.3.192.148.166.193= 3
    ipnettomediaifindex.3.192.148.166.196= 3
    ipnettomediaifindex.3.193.124.226.110= 3
    ipnettomediaifindex.5.145.249.30.33= 5
    ipnettomediaifindex.5.192.148.166.100= 5
    ipnettomediaphysaddress.1.193.124.224.33= 0x00:00:0c:02:3a:49
    ipnettomediaphysaddress.3.192.148.166.196= 0xaa:00:04:00:0c:04
    ipnettomediaphysaddress.3.192.148.166.198= 0xaa:00:04:00:0e:04
    ipnettomediaphysaddress.3.192.148.166.203= 0x00:00:01:00:54:62
    .........................................
    ipnettomediaphysaddress.5.145.249.30.33= 0x00:00:0c:02:69:7d
    ipnettomediaphysaddress.5.192.148.166.100= 0x00:20:af:15:c1:61
    ipnettomediaphysaddress.5.192.148.166.101= 0x08:00:09:42:0d:e8
    ipnettomedianetaddress.1.193.124.224.33= 193.124.224.33
    ipnettomedianetaddress.1.193.124.224.35= 193.124.224.35
    ipnettomedianetaddress.3.192.148.166.193= 192.148.166.193
    ipnettomedianetaddress.3.193.124.226.110= 193.124.226.110
    ipnettomedianetaddress.5.145.249.30.33= 145.249.30.33
    ipnettomediatype.1.193.124.224.33= other(1)
    ipnettomediatype.1.193.124.224.35= dynamic(3)
    ipnettomediatype.1.193.124.224.37= dynamic(3)
    ipnettomediatype.3.192.148.166.195= dynamic(3)
    ipnettomediatype.3.192.148.166.222= other(1)
    ipnettomediatype.5.193.124.224.190= other(1)
    ipnettomediatype.5.193.124.225.33= other(1)
    ipnettomediatype.5.193.124.225.35= dynamic(3)

    Синтаксис каждого объекта описывается в рамках ASN.1 и показывает побитовое представление объекта. Кодирование объекта характеризует то, как тип объекта отображается через его синтаксис и передается по телекоммуникационным каналам. Кодирование производится в соответствии с базовыми правилами кодирования asn.1. Все описания объектов базируются на типовых шаблонах и кодах asn.1 (см. RFC-1213). Формат шаблона показан ниже:

    object (Объект):

    Имя типа объекта с соответствующим ему идентификатором объекта (object identifier)

    syntax (Синтаксис):
    asn.1 описание синтаксиса типа объекта.
    definition (Определение):
    Текстовое описание типа объекта.
    access (доступ):
    Опции доступа.
    status (состояние):
    Статус типа объекта.

    Маршруты также являются объектами mib. Согласно требованиям к mib, каждому маршруту в этой базе соответствует запись, схема которой приведена ниже на рис. 4.4.13.1.3:

    Рис. 4.4.13.1.3 Формат записи маршрутной таблицы в MIB

    Поле место назначения представляет собой IP-адрес конечной точки маршрута. Поле индекс интерфейса определяет локальный интерфейс (физический порт), через который можно осуществить следующий шаг по маршруту. Следующие пять полей (метрика 1-5) характеризуют оценку маршрута. В простейшем случае, например для протокола RIP, достаточно было бы одного поля. Но для протокола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг представляет собой IP-адрес следующего маршрутизатора. Поле тип маршрута имеет значение 4 для опосредованного достижения места назначения; 3 - для прямого достижения цели маршрута; 2 - для нереализуемого маршрута и 1 - для случаев отличных от вышеперечисленных.

    Поле протокол маршрутизации содержит код протокола. Для RIP этот код равен 8, для OSPF - 13, для BGP - 14, для IGMP - 4, для прочих протоколов - 1. Поле возраст маршрута описывает время в секундах, прошедшее с момента последней коррекции маршрута. Следующее поле - маска маршрута используется для выполнения логической побитовой операции И над адресом в IP-дейтограммы перед сравнением результата с кодом, хранящимся в первом поле записи (место назначения). Последнее поле маршрутная информация содержит код, зависящий от протокола маршрутизации и обеспечивающий ссылки на соответствующую информацию в базе MIB.

    Новым расширением MIB является система удаленного мониторинга сетей (RMON; RFC-1513, -1271). RMON служит для мониторирования сети в целом, а не отдельных сетевых устройств. В RMON предусмотрено 9 объектных групп (см. табл. 4.4.13.1.8).

    Таблица 4.4.13.1.8. Функциональные группы RMON

    Группа

    Назначение

    statistics

    Таблица, которая отслеживает около 20 статистических параметров сетевого трафика, включая общее число кадров и количество ошибок

    history

    Позволяет задать частоту и интервалы для измерений трафика

    alarm

    Позволяет установить порог и критерии, при которых агенты выдают сигнал тревоги

    host

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

    hostTopN

    Позволяет создать упорядоченные списки, которые базируются на пиковых значениях трафика группы ЭВМ

    matrix

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

    filter

    Позволяет определить конкретные характеристики кадров в канале. Например, можно выделить TCP-трафик.

    packet capture

    Работает совместно с группой filter. Позволяет специфицировать объем ресурса памяти, выделяемой для запоминания кадров, которые отвечают критериям filter.

    event

    Позволяет специфицировать набор параметров или условий, которые должен контролировать агент. Когда условия выполняются, информация о событии записывается в специальный журнал

    Для того чтобы реализовать функционирование RMON-агента, сетевая карта должна быть способна работать в режиме 6 (promiscuous mode), когда воспринимаются все пакеты, следующие по кабельному сетевому сегменту.

    Previous: 4.4.13 Протокол управления SNMP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.13.2 Нотация ASN.1


    previous up down next index index
    Previous: 4.4.13.1 Управляющая база данных MIB    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14 Протокол электронной почты SMTP

    4.4.13.2 Нотация ASN.1
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Одной из наиболее сложных систем сегодня являются открытые системы связи OSI (Open System Interconnection). OSI представляет собой достаточно формализованную стандартную архитектуру управления межкомпьютерными коммуникациями. Для описания этой системы была разработана абстрактный синтаксис нотаций ASN.1 (Abstract Syntax Notation; См. A Layman's Guide to a Subset of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, Inc. Redwood City, CA, 1991). ASN.1 является формальным языком, который обладает двумя основными чертами.

    Используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. Неотъемлемой частью ASN.1 являются базовые правила кодирования BER (Basic Encoding Rules), которые позволяют определить большое разнообразие типов данных. BER описывает то, как представить или закодировать любую величину в рамках стандарта ASN.1. Практически все величины здесь представляются в виде последовательности 8-битных октетов. Восьмой бит октета всегда считается самым старшим. BER позволяет закодировать величину более чем одним способом. Имеется также поднабор правил кодирования DER (Distinguished Encoding Rules, описаны в документе Х.509), которые определяют однозначные способы кодирования величин ASN.1.

    Ниже приведены базовые правила обозначений метасинтаксиса ASN.1.

    n

    (полужирный курсив) обозначает переменную

    []

    (квадратные скобки, напечатанные полужирным шрифтом) указывают на то, что терм является опционным.

    {}

    (фигурные скобки, напечатанные полужирным шрифтом) группируют родственные термы.

    |

    (вертикальная черта, напечатанная полужирным шрифтом) выделяет альтернативные значения.

    .

    (многоточие, напечатанное полужирным шрифтом) обозначает повторения.

    =

    (знак равенства, напечатанный полужирным шрифтом) описывает терм как субтерм.

    ASN.1 имеет четыре разновидности типов: простые типы, не имеющие компонент, структурные типы, имеющие компоненты, помеченные (tagged) типы, которые получаются из других типов, а также прочие типы, которые включают в себя типы CHOICE и ANY. Типам и значениям могут присваиваться имена с помощью оператора (::=). Эти имена в дальнейшем могут использоваться для определения других типов и величин.

    Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые состоят из класса и неотрицательного кода метки. Типы ASN.1 тождественны, если их числовые метки совпадают. Существует четыре класса меток.

    universal

    для типов, значения которых является неизменным для всех приложений. Эти типы определены в документе Х.208.

    application

    для типов со значением, специфическим для приложений, таких как служба каталогов Х.500. Типы двух разных приложений могут иметь одну и ту же метку и разные значения.

    private

    для типов, которые являются специфическими для данного предприятия.

    content-specific

    для типов со значением, специфическим для данного структурного типа.

    Ниже приведена таблица 4.4.13.2.1 типов и их меток универсального класса.

    Таблица 4.4.13.2.1. Типы и их метки

    Тип

    Комментарий Цифровая метка (шестнадцатеричное)

    INTEGER

    Любое целое число

    02

    BIT STRING

    Произвольная строка бит

    03

    OCTET STRING

    Произвольная последовательность октетов

    04

    NULL

    0

    05

    OBJECT IDENTIFIER

    Последовательность целых компонент, идентифицирующих объект

    06

    SEQUENCE and SEQUENCE OF

    10

    SET and SET OF

    11

    PrintableString

    Последовательность печатных символов

    13

    IA5String

    Произвольная строка символов IA5 (ASCII)

    16

    UTCTime

    Универсальное время (по Гринвичу; GMT)

    17

    ASN.1 типы и значения выражаются в нотации, близкой к используемой в языках программирования. Множественные пробелы и разрывы строк рассматриваются как один пробел. Комментарии выделяются парами дефисов или парой дефисов и переводом строки. Идентификаторы (имена значений и полей) и имена типов состоят из букв, цифр и пробелов. Идентификаторы начинаются со строчной буквы, а имена типов - с прописной.

    В SMI (Structure of Management Information) не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL.

    Стандарт ASN.1 определяет форму представления информации и имен. Для строчных типов может быть введено ограничение на максимальный размер. В ASN.1 определено четыре структурированных типов:

    SEQUENCE

    упорядоченный набор из одного или более типов.

    SEQUENCE OF

    упорядоченный набор из нуля или более представителей данного типа.

    SET

    неупорядоченный набор из одного или более типов.

    SET OF

    неупорядоченный набор из нуля или более представителей данного типа.

    Структурированные типы могут иметь опционные компоненты, в том числе со значениями по умолчанию.

    Существуют типы помеченные явно и неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки. Помеченный явно тип - это структурированный тип, состоящий из одного компонента основного типа. Для явной пометки используется ключевое слово EXPLICIT. Пометка (тэгирование) весьма удобна для различия типов в пределах одного приложения.

    Тип CHOICE обозначает объединение одного или более альтернатив. Тип ANY служит для обозначения произвольной величины для произвольного типа.

    Правила BER определяют один или более способов представить любую величину в виде строки октетов. Существует три метода кодирования величин (в рамках BER): примитивный с известной длиной; конструктивный при известной длине и конструктивный при неизвестной длине. Выбор метода зависит от типа величины и от того, известна ли длина преобразуемой величины. Для простых не строчных типов используется примитивный метод кодирования. В каждом методе BER-кодирование имеет три или четыре части:

    Identifier octets

    Определяет класс и числовую метку значения, а также указывает, является ли метод примитивным или конструктивным.

    Length octets

    Для методов кодирования с известной длиной определяет число октетов содержимого.

    Contents octets

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

    End-of-contents octets

    Для конструктивных методов с неопределенной длиной указывает на конец содержимого.

    Примитивный метод кодирования с заданной длиной

    Этот метод применим для простых типов и типов полученных из простых типов путем неявной пометки. Здесь необходимо, чтобы длина величины была известна заранее. Октеты идентификатора имеют два формата: для числовых меток от 0 до 31, и для числовых меток более 31. В первом случае биты 7 и 8 определяют класс (см. таблицу 4.4.13.2.2), бит 6 равен нулю, указывая на то, что метод кодирования primitive. Остальные биты используются для записи кода числовой метки. Во втором случае используется два или более октетов. В первом октете кодировка аналогична первому варианту за исключением того, что биты 1-5 содержат единицы.

    Таблица 4.4.13.2.2. Коды классов

    Класс

    Бит 8

    Бит 7

    Универсальный

    0

    0

    Прикладной

    0

    1

    Контекстно-ориентированный

    1

    0

    Частный

    1

    1

    Для октетов длины примитивного метода имеется два формата: короткий (один октет для длин 0-127) и длинный (2-127 октетов). Для короткой формы 8-ой бит октета всегда равен нулю. Для длинной формы восьмой бит первого октета всегда равен 1, биты 1-7 содержат код числа дополнительных октетов длины. Старшая цифра записывается первой.

    Конструктивный метод с заданной длиной

    Этот метод используется для простых строчных и структурированных типов, типов, производных от простых строчных типов, и некоторых других. Здесь октеты идентификатора и октеты длины имеют формат, идентичный используемому примитивным методом, за исключением того, что бит 6 первого октета идентификатора равен 1.

    Конструктивный метод кодирования с незаданной длиной

    Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00.

    Нотация типов, помеченных неявно, имеет вид:

    [[class] number] IMPLICIT Type

    class = UNIVERSAL | APPLICATION | PRIVITE

    где Type - тип, class - опционное имя класса и number - цифровая метка (неотрицательное целое число).

    Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например:

    PrivateKeyInfo ::= SEQUENCE {
    version Version,
    privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
    privateKey PrivateKey,
    attributes [0] IMPLICIT Attributes OPTIONAL }

    Здесь исходным (порождающим) типом является Attributes, класс отсутствует (т.е. контекстно-ориентированный), а числовая метка равна нулю. Кодирование компоненты attributes величины PrivateKeyInfo осуществляется следующим образом.

    Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование. Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes.

    Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate (X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат.

    [ [class] number] EXPLICIT Type

    class = UNIVERSAL | APPLICATION | PRIVATE

    где Type - тип, class - опционное имя класса, а number - числовая метка в пределах класса (неотрицательное целое число). Пример:

    ContentInfo ::= SEQUENCE {
    ContebtType ContentType,
    Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

    Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0.

    Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено).

    Certificate ::= .
    Version [0] Version DEFAULT v1988,
    .

    BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид.

    Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType.

    Тип ANY

    Тип ANY обозначает произвольную величину произвольного типа, где произвольный тип возможно определен при регистрации идентификатора объекта или является целочисленным индексом. Нотация типа ANY имеет формат:

    ANY [DEINED BY identifier ]

    где identifier - опционный идентификатор. Форма ANY DEINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которой identifier определяет какую-то другую компоненту и эта компонента имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме истинный тип задается величиной этой другой компоненты. Например, тип AlgorithmIdentifier [X.509] имеет компоненту типа ANY:

    AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameter ANY DEFINED BY algorithm OPTIONAL }

    Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm.

    Битовые строки

    Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат.

    BIT STRING

    Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING:

    SubjectPublicKeyInfo ::= SEQUENCE {
    Algorithm AlgorithmIdentifier,
    PublicKey BIT STRING }

    BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты.

    При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING "0111 1101 1001 1111 11" может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).

    03 04 06 7D 9F C0

    DER-кодирование

    03 04 06 7D 9F E0

    Дополнение кодом "100000"

    03 81 04 06 7D 9F C0

    Длинная форма представления октетов длины

    23 09
    03 03 00 7D 9F
    03 02 06 C0

    Конструктивное кодирование "01111101 1001 1111" +"11"

    Первый октет первых трех представлений содержат код типа (для BIT STRING = 03). Второй октет в первых двух представлениях - код октетов длины (ведь далее следует 4 октета). Третий октет первой и второй строк содержит число добавленных нулей до числа бит, кратного восьми. Во втором байте третей строки записана 8, что указывает на длинную форму представления октетов длины. Последующая 1 говорит о том, что использован один дополнительный октет длины. Код длины в четвертом примере записан также во втором октете (далее следует 9 октетов). В этом варианте битовая строка разбита на две субстроки, первая из которых имеет длину в два октета. DER-кодирование предполагает всегда примитивный метод представления с дополнением строки нулями до длины, кратной целому числу октетов.

    Тип CHOICE

    Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат.

    CHOICE {
    [ identifier 1] Type 1,
    .,
    [ identifiern ] Type n }

    где identifier 1, ., identifiern являются опционными идентификаторами альтернатив, а типы Type 1, ., Type n - альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при кодировании. Типы должны иметь определенные метки. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.

    ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate, -- X.509 certificate
    extendedCertificate [0] IMPLICIT ExtendedCertificate }

    Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для типа CHOICE сводится к кодированию альтернатив. При этом октеты идентификатора для рассмотренного примера содержат код 30, если выбранная альтернатива certificate, и A0 - в случае ExtendedCertificate.

    Строки IA5

    Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 - эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.

    IA5String

    BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов. При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки "test1@rsa.com".

    12 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D

    DER-кодирование

    12 81 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D Длинная форма октетов длины
    32 13
    12 05 74 65 73 74 31
    12 01 40
    12 07 72 73 61 2E 63 6F 6D
    Конструктивное
    кодирование: "test1"
    + "@" +
    "rsa.com"

    DER-кодирование является всегда примитивным, октеты содержимого идентичны случаю BER-кодирования.

    Целое

    Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат:

    INTEGER [{ identifier 1( value1 ) . identifier n( valuen ) }]

    где identifier 1 . identifier n являются опционными идентификаторами, а value1 . valuen опционные целые значения. Например, Version RFC-1114 относится к целому типу со значением:

    Version ::= INTEGER { 1988(0) }

    Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version:

    Certificate
    version Version DEFAULT v1988,
    .

    BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3.

    Таблица 4.4.13.2.3. Примеры BER-кодирования

    Значение целого

    BER-код

    0

    02 01 00

    127

    02 02 00 7F

    128

    02 02 00 80

    256

    02 02 01 00

    -128

    02 01 80

    -129

    02 02 FF 7F

    NULL

    Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:

    NULL

    Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты. Например, BER-представление значения NULL может иметь одну из приведенных ниже форм (зависит от используемого представления октетов длины).

    05 00
    05 81 00

    DER-кодирование типа NULL является также примитивным и совпадает с первой строкой приведенного выше примера.

    Объектные идентификаторы

    Тип OBJECT IDENTIFIER служит для обозначения дентификаторов, которые представляют собой последовательность целочисленных компонент, которые идентифицируют такие объекты, как алгоритм или атрибут имени каталога. Значение OBJECT IDENTIFIER может содержать любое число неотрицательных компонент. Этот тип не относится в числу строчных. Значения OBJECT IDENTIFIER присваиваются при регистрации.

    Тип OBJECT IDENTIFIER используется для идентификации содержимого ContentInfo, алгоритмов в X.509 (AlgorithmIdentifier) и атрибутов Attribute и AttributeValueAssertion (X.501). Нотация OBJECT IDENTIFIER имеет формат.

    OBJECT IDENTIFIER

    Нотация величины OBJECT IDENTIFIER имеет вид:

    { [ identifier ] component1. componentn }
    componenti = identifieri | identifieri (valuei) | valuei

    где identifier, identifier1, . identifiern являются идентификаторами, а value1 ., valuen - опционные целые числа. Идентификаторы без целых значений могут встретиться только для объектов, описанных в Х.208.

    Например, нижеприведенные величины объектных идентификаторов присвоены RSA DATA Security, Inc.

    { iso(1) member-body(2) 840 113549 }
    { 1 2 840 113549 }

    В таблице 4.4.13.2.4 представлены некоторые объектные идентификаторы и их значения.

    Таблица 4.4.13.2.4. Некоторые объектные идентификаторы и их значения

    Величина объектного идентификатора

    Назначение

    { 1 2 }

    Члены ISO

    { 1 2 840 }

    US (ANSI)

    { 1 2 840 113549}

    RSA Data Security, Inc.

    { 1 2 840 113549 }

    RSA Data Security, Inc. PKCS (Public Key Cryptography Standard)

    { 2 5 }

    Служба каталогов (X.500)

    { 2 5 8 }

    Служба каталогов - алгоритмы

    BER-кодирование OBJECT IDENTIFIER является всегда примитивным. Октеты содержимого представляют собой объединение n-1 строки октетов, где n число компонент объектного идентификатора. Каждая октетная строка несет в себе целое число по модулю 128 (старшая часть первая). 8-ой бит каждого октета, кроме последнего, равен 1. Пусть value1, ., valuen целые значения компонентов объектного идентификатора. Тогда n-1 субидентификаторов, из которых формируется октетная строка, будут иметь следующий вид.

    1. Первый субидентификатор равен 40value1 + value2 . (значение value1 лежит в пределах 0-2 включительно, а value2 в интервале 0-39, когда value1 равна 0 или 1.
    2. i-ый субидентификатор равен valuei+1 ; 2 ё iё n-1.

    Например, субидентификаторы объектного идентификатора RSA Data Security, Inc. равны 42 = 40 1 + 2, 840, 113549 и 1. В шестнадцатеричном представлении BER-код этого объектного идентификатора имеет вид:

    06 07 2A 86 48 86 F7 0D 01

    DER-кодирование в данном случае совпадает с BER.

    Строки октетов

    Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений, включая зашифрованные, а также для типа PBEParameter. Нотация типа OCTET STRING имеет формат.

    OCTET STRING [SIZE ({ size | size1..size2 })]

    где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE( size ) строка октетов должна иметь октеты size . В формате OCTET STRING SIZE( size1 .. size2 ) строка должна содержать число октетов между size1 и size2 . Например, тип PBEParameter имеет компоненту типа OCTET STRING:

    PBEParameter ::= SEQUENCE {
    salt OCTET STRING SIZE (8),
    iterationCount INTEGER }

    Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING. Например, BER-код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное).

    04 08 01 23 45 67 89 AB CD EF

    DER-кодирование

    04 81 08 01 23 45 67 89 AB CD EF

    Длинный формат октетов длины

    24 0С

    Конструктивное кодирование

    04 04 01 23 45 67

    "01 23 45 67" + "89 AB CD EF"

    04 04 89 AB CD EF

    Строки печатных символов

    Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора:

    A, B,.,Z
    a,b,.,z
    0,1,.,9
    (пробел) ' () +, - . / : = ?

    Этот тип используется для представления атрибутов имен (Х.520). Нотация типа PrintableString имеет вид:

    PrintableString

    BER-кодирование значения PrintableString может быть примитивным или конструктивным. При примитивном кодировании печатных символов байты содержимого несут в себе строки октетов печатных ASCII-кодов. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок. Например, BER-код значения PrintableString "Test User 1" может быть представлено одним из ниже приведенных способов.

    13 0B 54 65 73 74 20 55 73 65 72 20 31

    DER-кодирование

    13 81 0B 54 65 73 74 20 55 73 65 72 20 31

    Длинная форма октетов длины

    33 0F

    Конструктивная форма,

    13 05 54 65 73 74 20

    "Test" + "User 1"

    13 06 55 73 65 72 20 31

    Тип SEQUENCE

    Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид:

    SEQUENCE {
    [identifier1 ] Type1 [{OPTIONAL | DEFAULT value1 }],
    .,
    [identifiern ] Typen
    [{OPTIONAL | DEFAULT valuen }],

    где identifier1 , ., identifiern являются опционными идентификаторами компонентов, Type1 , ., Typen - типы компонентов, а value1 ,., valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует. Например, тип Validity [X.509] относится к типу SEQUENCE и имеет два компонента.

    Validity ::= SEQUENCE {
    start UTCTime,
    end UTCTime }

    Здесь start и end являются идентификаторами компонент, а типом компонент служит UTCTime. BER-кодирование значения SEQUENCE является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов последовательности.

    Тип SEQUENCE OF

    Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более компонентов данного типа, используется для имен в X.501. Нотация SEQUENCE OF имеет вид:

    SEQUENCE OF Type

    Так например, тип RNDSequence состоит из нуля или более компонент типа RelativeDistinguishedName.

    RNDSequence ::= SEQUENCE OF RelativeDistinguishedName

    BER-кодирование SEQUENCE OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов значений элементов последовательности в порядке их расположения. DER-кодирование имеет тот же формат.

    Тип SET

    Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.

    SET {
    [identifier1 ] Type1 Type1 [{OPTIONAL | DEFAULT value1 }],
    .,
    [identifiern ] Typen
    [{OPTIONAL | DEFAULT valuen }],

    где identifier1 , ., identifiern являются опционными идентификаторами компонентов, Type1 , ., Typen - типы компонентов, а value1 ,., valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует.

    BER-кодирование для типа SET является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов набора.

    Тип SET OF

    Тип SET OF представляет неупорядоченный набор, состоящий из нуля или более компонентов заданного типа и предназначенный для атрибутов PKCS (Public-Key Cryptography Standard) и имен X.501. Нотация типа SET OF имеет вид:

    SET OF Type

    где Type - тип. Так тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.

    RelativeDistinguishedName ::= SET OF AttributeValueAssertion

    BER-кодирование типа SET OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов величин компонентов в порядке их исходного расположения. DER-кодирование также является всегда конструктивным, октеты содержимого представляются как и в случае BER-кодировки. Но компоненты лексикографически упорядочиваются.

    Тип UTCTime

    Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime характеризует местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:

    YYMMDDhhmmZ
    YYMMDDhhmm+hh`mm`
    YYMMDDhhmm-hh`mm`
    YYMMDDhhmmssZ
    YYMMDDhhmmss+ hh`mm`
    YYMMDDhhmmss- hh`mm`

    где

    YY

    младшие две цифры года

    ММ

    код месяца (01 - 12)

    DD

    код дня (01 - 31)

    hh

    код часа (00 - 23)

    mm

    код минут (00 - 59)

    ss

    код секунд (00 - 59)

    Z

    означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а - указывает на то, что местное время опережает GMT.

    hh`

    абсолютное значение смещения по отношению к GMT в часах

    mm`

    абсолютное смещение по отношению к GMT в минутах.

    UTCTime используется для определения типа Validity [X.509]. Нотация типа UTCTime имеет вид.

    UTCTime

    BER-кодирование значения UTCTime может быть примитивным или конструктивным. При примитивном кодировании октеты представляют собой символы строки в виде ASCII-кодов. При конструктивном кодировании октеты образуют объединение BER-кодов последовательных субстрок. В качестве примера рассмотрим варианты представления времени 4:45:40 после полудня 6 мая 1991 года (Pacific Daylight Time) в виде величины UTCTime.

    "910506164540-0700"
    "910506234540Z"

    Это представление эквивалентно следующим BER-кодам:

    17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5A
    17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30

    DER-кодирование типа UTCTime всегда является примитивным.

    Ниже приводится пример ASN.1 нотации имен типа X.501.

    Name ::= CHOICE { RNDSequence }

    RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
    RelativeDistinguishedName ::= SET OF AttributeValueAssertion
    AttributeValueAssertion ::= SEQUENCE { AttributeType, AttributeValue }
    AttributeType ::= OBJECT IDENTIFIER
    AttributeValue ::= ANY

    Тип Name идентифицирует объект в каталоге X.500. Name имеет тип CHOICE с одной альтернативой RNDSequence. Тип RNDSequence указывает проход по дереву каталогов X.500, начиная с корневой части. RNDSequence имеет тип SEQUENCE OF, состоящий из нуля или более компонентов RelativeDistinguishedName. Тип RelativeDistinguishedName присваивает уникальное имя объекту на дереве каталога. RelativeDistinguishedName имеет тип SET OF, состоящий из нуля или более компонентов AttributeValueAssertion. Тип AttributeValueAssertion присваивает значение атрибуту имени (например, определяющее принадлежность к стране). AttributeValueAssertion имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и AttributeValue. AttributeType идентифицирует атрибут с помощью объектного идентификатора. AttributeValue присваивает значение атрибуту. Ниже предлагается пример DER-кодирования типа Name. В качестве имени использовано RSA Data Security, Inc. NOTARY (отдел Internet Privacy Enhanced Mail).

    (root)
    |
    countryName = "US"
    |
    organizationName = "RSA Data Security, Inc."
    |
    organizationalUnitName = "NOTARY"

    Каждый уровень соответствует одному значению RelativeDistinguishedName, в выбранном случае они имеют только одно значение AttributeValueAssertion. Значение AttributeType помещается до знака равенства, а AttributeValue (строка печатных символов с заданным типом атрибута) - после знака равенства.

    Тип атрибута

    DER-кодирование трех значений AttributeType согласно примитивному методу с заданной длиной дает следующие строки октетов.

    06 03 55 04 06

    countryName

    06 03 55 04 0A

    organizationName

    06 03 55 04 0B

    organizationalUnitName

    Здесь countryName, organizationName и organizationalUnitName являются типами атрибутов Х.520, которые имеют следующие определения.

    AttributeType OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
    countryName OBJECT IDENTIFIER ::= { AttributeType 6 }
    organizationName OBJECT IDENTIFIER ::= { AttributeType 10 }
    organizationalUnitName OBJECT IDENTIFIER ::= { AttributeType 11 }

    Октеты идентификатора имеют формат с меткой, так как метка равна 6 для OBJECT IDENTIFIER. Биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, что говорит о примитивном методе кодирования. Октеты длины ориентированы на короткую форму представления. Октеты содержимого представляют собой объединения трех-октетных строк, полученных из субидентификаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11.

    Значение атрибута

    DER-кодирование трех значений AttributeValue в соответствии с примитивным методом при заданной длине дает следующие строки:

    13 02 55 53

    "US"

    13 17 52 53 41 20

    "RSA

    44 61 74 61 20

    Data

    53 65 63 75 72 69 74 79 2C 20

    Security,

    49 6E 63 2E

    Inc."

    Метка равна 19 (PrintableString) биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, отмечая примитивный метод кодирования. Октеты длины имеют "короткий" формат, а октеты содержимого являются ASCII-представлением значения атрибута.

    Атрибут ValueAssertion

    DER-кодирование трех значений AttributeValueAssertion в соответствии с конструктивным методом дает следующие строки октетов.

    30 09
    06 03 55 04 06
    13 02 55 53

    countryName = "US"

    30 1E
    06 03 55 04 0A
    13 17 52 53 41 20
    44 61 74 61 20
    53 65 63 75 72 69 74 79 2C 20
    49 6E 63 2E

    organizationName = "RSA Data Security, Inc."

    30 0D
    06 03 55 04 0B
    13 06 4E 4F 54 41 52 59

    organizationalUnitName = "NOTARY"

    Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов компонент attributeType и attributeValue.

    RelativeDistinguishedName</p>

    DER-кодирование трех значений RelativeDistinguishedName, выполняемое согласно конструктивному методу, дает следующие строки октетов.

    31 0B
    30 09 . 55 53
    31 20
    30 1E . 63 2E
    31 0F
    30 0D . 52 59

    Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов компонент AttributeValueAssertion.

    RDNSequence

    DER-кодирование значений RDNSequence, выполняемое согласно конструктивному методу при заданной длине, дает следующие строки октетов.

    30 40
    31 0B . 55 53
    31 20 . 63 2E
    31 0F . 52 59

    Октеты идентификатора используют короткий формат (low-octet form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют "короткому" формату, а октеты содержимого представляют собой объединение DER-кодов трех компонент RelativeDistinguishedName в порядке их следования.

    Name

    DER-кодирование значений Name выполняется аналогично значениям RDNSequence и выдает следующие результаты.

    30 40 31 0B
    30 09
    06 03 55 04 06
    13 02 55 53
    31 20 30 1E
    06 03 55 04 0A
    13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69
    74 79 2C 20 49 6E 63 2E
    31 0F 30 0D
    06 03 55 04 0B
    13 06 4E 4F 54 41 52 59

    Previous: 4.4.13.1 Управляющая база данных MIB    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14 Протокол электронной почты SMTP


    previous up down next index index
    Previous: 4.4.13.2 Нотация ASN.1    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14.1 Протокол обмена UUCP

    4.4.14 Протокол электронной почты SMTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Главной целью протокола simple mail transfer protocol (SMTP, RFC-821, -822) служит надежная и эффективная доставка электронных почтовых сообщений. SMTP является довольно независимой субсистемой и требует только надежного канала связи. Средой для SMTP может служить отдельная локальная сеть, система сетей или весь Интернет.

    SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть оконечный или промежуточный адресат. SMTP-команды генерируются отправителем и посылаются получателю. На каждую команду должен быть отправлен и получен отклик.

    Когда канал организован, отправитель посылает команду MAIL, идентифицирую себя. Если получатель готов к приему сообщения, он посылает положительное подтверждение. Далее отправитель посылает команду RCPT, идентифицируя получателя почтового сообщения. Если получатель может принять сообщение для оконечного адресата, он выдает снова положительное подтверждение (схема формирования откликов помещена в приложении 10.14). В противном случае он отвергает получение сообщения для данного адресата, но не вообще почтовой посылки. Взаимодействие с почтовым сервером возможно и в диалоговом режиме, например:

    tn dxmint.cern.ch 25 (команда telnet с использованием порта 25)
    220 dxmint.cern.ch sendmail ready at sun, 9 jul 1995 11:13:57 +0200 (связь установлена, код отклика 220 является положительным)

    EHLO dxmint.cern.ch

    (поддерживает ли сервер расширение mime?)

    500 command unrecognized

    (не поддерживает)

    HELO crnvma.cern.ch

    (команда выхода на конкретный сервер)

    250 dxmint.cern.ch hello crnvma.cern.ch, pleased to meet you (отклик 250 также является положительным)
    mail from:<> (так как на моей PC нет резидентной почтовой программы, я не указываю обратного адреса)

    250 <>... sender ok

    (команда прошла успешно)

    RCPT TO: ysemenov@cernvm.cern.ch

    (указываем адрес места назначения)

    250 ... recipient ok

    DATA

    (начало ввода текста сообщения)

    nu-i-nu...

    (текст сообщения)

    .

    (знак конца сообщения)

    QUIT

    (прерывание или завершение процедуры)

    221 dxmint.cern.ch closing connection (сообщение об успешном завершении процедуры)

    Почтовое сообщение отправлено без использования доступа к локальной почтовой программе (mail на sun, например). Следует отметить, что работа через порт 25 в данном случае открывает богатые возможности для хакеров. Вообще умелый программист может многого достичь, используя номера портов. Здесь есть над чем поработать людям, ответственным за безопасность сетей. Аналогично, не имея авторизации, можно выявить клиентов почтового сервера, используя команду VRFY:

    tn ns.itep.ru 25
    220 ns.itep.ru 5.67a8/ida-1.5 sendmail is ready at sat, 29 jul 1995 13:53:03
    vrfy bobyshev
    250 andrey bobyshev
    и т.д.
    quit

    SMTP-отправитель и SMTP-получатель могут вести диалог с несколькими оконечными пользователями (рис. 4.4.14.1). Любое почтовое сообщение завершается специальной последовательностью символов. Если получатель успешно завершил прием и обработку почтового сообщения, он посылает положительное подтверждение.

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

    Рис. 4.4.14.1 Схема взаимодействия различных частей почтовой системы

    Для решения поставленной задачи SMTP-сервер должен знать имя конечного получателя и название почтового ящика места назначения. Аргументом команды MAIL является адрес отправителя (обратный адрес). Аргументом команды RCPT служит адрес конечного получателя. Обратный адрес используется для посылки сообщения в случае ошибки.

    Все отклики имеют цифровые коды. Команды, отклики и имена ЭВМ не чувствительны к тому, строчные или прописные символы использованы при их написании. Это не всегда справедливо при написании имен и адресов получателя.

    Многие почтовые системы работают только с ASCII-символами. Если транспортный канал работает с октетами, 7-битные коды будут дополнены нулевым восьмым битом. Именно здесь коренилась проблема пересылки почтовых сообщений на русском языке несколько лет назад(русский алфавит требует 8-битового представления).

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

    MAIL FROM: ,

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

    Эта команда сообщает SMTP-получателю, что стартует новая процедура и следует сбросить в исходное состояние все статусные таблицы, буферы и т.д. Если команда прошла, получатель реагирует откликом: 250 OK.

    Аргумент может содержать не только адрес почтового ящика, в общем случае является списком адресов ЭВМ-серверов, через которые пришло данное сообщение, включая, разумеется, и адрес почтового ящика отправителя. Первым в списке стоит адрес ЭВМ-отправителя.

    После прохождения команды MAIL посылается команда RCPT:

    RCPT TO:

    Эта команда указывает адрес конечного получателя (). При благополучном прохождении команды получатель посылает код-отклик 250 OK, и запоминает полученный адрес. Если получатель неизвестен, SMTP-сервер пошлет отклик 550 Failure reply. Команда RCPT может повторяться сколько угодно раз, если адресат не один.

    Аргумент может содержать не только адрес почтового ящика, но и маршрутный список ЭВМ по дороге к нему. Первым в этом списке должно стоять имя ЭВМ, получившей данную команду. По завершении этого этапа посылается собственно сообщение:

    DATA

    При правильном приеме этого сообщения SMTP-сервер реагирует посылкой отклика 354 Intermediate reply (промежуточный отклик), и рассматривает все последующие строки в качестве почтового текста. При получении кода конца текста отправляется отклик: 250 OK.

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

    В некоторых случаях адрес места назначения может содержать ошибку, но получатель знает правильный адрес. Тогда возможны два варианта отклика:

    1. 251 User not local; will forward to

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

    2. 551 User not local; please try

    Получатель знает правильный адрес и предлагает отправителю переадресовать сообщение по адресу .

    SMTP имеет команды для проверки корректности имени адресата (VRFY) и расширения списка адресов (EXPN). Обе команды в качестве аргументов используют строки символов (в некоторых реализациях эти две команды по своей функции идентичны). Для команды VRFY параметром является имя пользователя, а отклик может содержать его полное имя и адрес его почтового ящика.

    Реакция на команду VRFY зависит от аргумента. Так если среди клиентов почтового сервера имеется два пользователя с именем Ivanov, откликом на команду "VRFY Ivanov" будет "553 User ambiguous". В общем случае команда VRFY Ivanov может получить в качестве откликов:

    250 Vasja Ivanov Ivanov@cl.itep.ru
    или:
    251 User not local; will forward to Ivanov@cl.itep.ru
    или:
    550 String does not match anything (данная строка ничему не соответствует).
    или:
    551 User not local; please try Vasja@ns.itep.ru
    или:
    VRFY Chtozachertovchina
    553 User ambiguous (несуществующее имя)

    В случае пропечатки списка адресов отклик занимает несколько строк, например:

    EXPN Example-People
    250-Juri Semenov Semenov@ns.itep.ru
    250-Alexey Sher Sher@suncom.itep.ru
    250-Andrey Bobyshev Bobyshev@ns.itep.ru
    250-Igor Gursky Gursky@ns.itep.ru

    В некоторых системах аргументом команды EXPN может быть имя файла, содержащего список почтовых адресов.

    Основной задачей почты служит доставка сообщений в почтовый ящик адресата. Сходную форму услуги оказывают некоторые ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP). Для посылки сообщений на экран терминала адресата предусмотрено три команды:

    1. SEND FROM:

    Команда SEND требует, чтобы почтовое сообщение было доставлено на терминал. Если терминал адресата не активен в данный момент, то откликом на команду RCPT будет код 450.

    2. SOML FROM:

    Команда Send Or MaiL (SOML) пересылает сообщение на экран адресата, если он активен, в противном случае сообщение будет уложено в его почтовый ящик.

    3. SAML FROM:

    Команда Send And MaiL (SAML) предполагает доставку сообщение на экран терминала адресата и занесение в его почтовый ящик.

    Для открытия и закрытия коммуникационного канала используются команды:

    HELO , где - имя запрашивающего домена.
    QUIT

    Выражение может быть маршрутом, имеющим вид "@ONE,@TWO:VANJA@THREE", где ONE, TWO и THREE - имена ЭВМ. Что подчеркивает различие между адресом и маршрутом. Концептуально элементы из переносятся в при пересылке сообщений от одного SMTP-сервера к другому.

    Если SMTP-сервер обнаружит, что доставка сообщения по адресу невозможна, тогда он формирует сообщение о "не доставленном письме", используя . Следует также помнить, что ни прямой ни обратный адреса-маршруты, вообще говоря, могут не иметь ничего общего с текстом заголовка почтового сообщения.

    При определенных условиях и ошибках в задании прямых и обратных адресов-маршрутов возможно зацикливание сообщений об этих ошибках. Чтобы заведомо избежать этого можно выдавать команду MAIL c нулевым обратным маршрутом:

    MAIL FROM:<>

    Если вы или ваша программа не указали обратного адреса, не следует думать, что это помешает работе почтовой программы и она не будет знать, куда посылать отклики. Ваш обратный IP-адрес указан в каждом пакете, посылаемом адресату!

    Некоторые другие команды, используемые в SMTP:

    Команда TURN используется для того, чтобы поменять местами функции программ, взаимодействовавших по телекоммуникационному каналу. Программа-отправитель становится получателем (после того как она выдаст команду TURN и получит отклик 250), а программа-получатель - отправителем. Если программа не хочет или не может поменять свою функцию, она пошлет отклик 502.

    Команда RESET (RSET) прерывает текущую процедуру отправки почтового сообщения. Все буферы и таблицы очищаются, получатель должен послать отклик 250 OK.

    Команда HELP вынуждает получателя послать справочную информацию отправителю команды HELP. Команда может содержать аргумент (имя команды). Команда не изменяет состояния таблиц или буферов.

    Команда NOOP не оказывает влияния на какие-либо параметры или результаты предшествующих команд, она только вынуждает получателя послать отклик 250 OK. Может использоваться для проверки работоспособности TCP-канала.

    Допустимо написание команд строчными или прописными символами, например: MAIL, Mail, mail, MaIl или mAIl.

    Для того чтобы программа SMTP-сервера была работоспособна, она должна понимать следующий минимум команд: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT.

    Предельная длина имени пользователя или домена равна 64 символам. Максимальная длина или составляет 256 символов, включая разделители (пробелы, точки, запятые и пр.). Командная строка не должна быть длиннее 512 символов. Максимальный размер строки отклика не должен превышать, включая его код и , 512 символов. Максимальная длина строки составляет, включая , 1000 символов. Предельно допустимое число адресатов равно 100, последнее полезно помнить, если вы храните этот список в файле.

    Previous: 4.4.13.2 Нотация ASN.1    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14.1 Протокол обмена UUCP


    previous up down next index index
    Previous: 4.4.14 Протокол электронной почты SMTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14.2 Почтовый протокол POP3

    4.4.14.1 Протокол обмена UUCP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Этот протокол сыграл немалую роль в становлении современных телекоммуникационных технологий. Первые системы электронной почты использовали протокол UUCP (Unix-to-Unix Copy Program). Основополагающие идеи ОС UNIX расширили область взаимодействия вычислительных и управляющих процессов за рамки центрального процессора ЭВМ. Хотя большинство современных почтовых серверов базируется на протоколе SMTP, протокол UUCP продолжает применяться во многих приложениях, использующих ОС UNIX (см. www.isf.ru/~stas/doc/uucp-1.06/uucp_7.html).

    Современные программные пакеты UUCP поддерживают приоритеты для всех команд, которые варьируются от a (наивысший) до z и далее a-z. В UNIX эти коды приоритетов вставляются в имена командных файлов, создаваемых UUCP или UUX. Имя командного файла обычно имеет вид: c.nnnngssss, где g - код приоритета (от слова grade), nnnn - имя удаленной системы, а ssss - четырех символьный номер. Например, командный файл создаваемый системой sun2 с уровнем приоритета d может иметь имя c.sun2d1111. При этом в имени удаленной системы сохраняется лишь 7 символов, чтобы обеспечить совместимость с 14-символьным ограничением для имен файлов.

    UUCP-протокол определяет взаимодействие между двумя программами. Этот диалог включает в себя три этапа: установление канала, последовательность запросов пересылки файлов и закрытие канала. Прежде чем начать диалог, инициатор обмена должен авторизоваться в ЭВМ, с которой планируется обмен, и активизировать тамошнюю систему UUCP. На рисунке инициатор обмена назван клиентом (в литературе можно также встретить также название master). Все сообщения начинаются с символа ^p (восьмеричный код '\020') и завершаются нулевым байтом (\000). В некоторых системах для завершения сообщений используется код перевода строки (\012).

    Установление канала инициируется сервером, который посылает сообщение \020shere=hostname\000, где hostname - имя ЭВМ сервера. В устаревших пакетах uucp можно встретить инициирующие сообщения вида \020shere\000.

    Клиент должен откликнуться сообщением \020shostname options\000, где hostname соответствует имени клиента (инициатора обмена). При этом допустимы следующие опции (опции могут и отсутствовать).

    Опция

    Описание

    -qseq

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

    -xlevel

    Требует, чтобы сервер установил требуемый отладочный уровень (поддерживается не всеми системами)

    -vgrade=grade

    Требует, чтобы сервер передавал файлы заданного сорта (grade)

    -r

    Указывает на то, что клиент знает, как повторно запустить обмен в случае сбоя

    -ulimit

    Сообщает предельный размер файла, который может создать клиент. Размер задается в шестнадцатеричном формате и обозначает число 512 байтных блоков в файле, например -ux300000.

    На запрос \020rok\000 возможно несколько откликов:

    rok

    Запрос принимается, диалог переходит к согласованию протокола;

    rlck

    Сервер заблокирован, что говорит о том, что ЭВМ уже осуществляют обмен;

    rcb

    Сервер осуществляет обратный запрос клиенту, что позволяет исключить ложные вызовы;

    rbadseq

    Неверен порядковый номер сообщения;

    rlogin

    Клиент использовал неверное имя при авторизации;

    ryou are unknown to me

    Клиент неизвестен серверу (uucp не позволяет соединение с неизвестными системами).

    Если отклик не rok, то обе стороны прерывают сессию.

    Запрос сервера \020pprotocols\000, где protocols характеризует список поддерживаемых протоколов, причем каждому протоколу соответствует лишь один символ. Клиент может послать сообщение \020uprotocols\000, где инициатор сессии выбирает протокол из предлагаемого сервером списка. Если в предлагаемом списке нет нужного протокола, посылается сообщение \020un\000 и обе стороны разрывают сессию.

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

    Клиент может послать команды: s, r, x, e, или h (команды посылает только клиент). В качестве параметров этих команд используются имена файлов. Это могут быть абсолютные имена файлов, начинающиеся с символа /, файлы из публичного каталога с именами, которые начинаются с символов ~/, файлы из каталога пользователя, начинающиеся с строки ~user/, или файлы из временного буфера (spool). Собственно имена начинаются с c. для командных файлов, с d. для файлов данных, или с x. для исполнительных файлов.

    Команда клиента s, предназначенная для посылки файлов серверу, имеет формат: s from to user -options temp mode notify size. Параметр from представляет собой имя посылаемого файла, to - имя файла на сервере, куда будет скопирован файл, user - имя пользователя, инициировавшего пересылку файла, options - список опций, управляющих обменом, temp - имя пересылаемого файла в случае использования опции С. После успешного завершения обмена сервер стирает файл temp. Параметр mode задает разновидность файла на сервере. Если файл не из каталога spool, клиент создает его с mode=0666. Параметр notify может отсутствовать, он имеет смысл лишь при наличии опции n. В этом случае при успешном завершении обмена посылается уведомление через электронную почту по адресу notify. Поле size задает размер файла в байтах.

    Опция

    Описание

    c

    Файл копируется в каталог spool (клиент должен использовать temp, а не from)

    c

    Файл не должен копироваться в каталог spool (по умолчанию)

    d

    Сервер должен сформировать каталог, если необходимо (по умолчанию)

    f

    Сервер не должен формировать каталог, если необходимо, а вместо этого он должен оборвать связь

    m

    Клиент должен послать электронное почтовое сообщение пользователю (user) по завершении обмена

    n

    Сервер должен послать e-mail по адресу, указанному в параметре notify, по завершении обмена

    Сервер может откликнуться на s-команду следующими способами.

    Отклик

    Описание

    sy start

    Сервер готов принять файл и обмен начинается. Поле start присутствует в случае использования рестарта и характеризует позицию в файле, с которой осуществляется рестарт. Для нового файла start=0x0

    sn2

    Сервер не выдает разрешение на пересылку файла. Это может означать, например, что недоступен нужный каталог. Такой отклик говорит о том, что пересылка принципиально невозможна.

    sn4

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

    sn6

    Используется версией taylor uucp. Сервер считает файл слишком длинным (в данный момент места нет, но возможно ситуация изменится в будущем)

    sn7

    Используется версией taylor UUCP. Сервер считает файл настолько большим, что пересылка вообще невозможна

    sn8

    Используется версией taylor UUCP. Означает, что файл был уже получен ранее. Это может произойти при потере подтверждения завершения обмена.

    sn9

    Используется версией taylor UUCP и uuplus. Означает, что удаленная система не может открыть другой канал и можно позднее попытаться передать файл еще раз

    sn10

    Используется только svr4 uucp и означает, что размер файла слишком велик

    cy

    Передача файла успешно завершилась

    cym

    Передача успешно завершена и сервер хочет стать клиентом

    cn5

    Временный файл не может быть перемещен в окончательное положение, что означает невозможность завершения обмена.

    Последние три отклика сервера называются С-командами. При получении С-команды клиент может послать новую команду-запрос. Такой командой может быть r-команда, которая имеет следующий формат.

    r from to user -options size

    Это запрос клиента на получение файла от сервера. Параметр from - имя файла на сервере. Это не может быть spool-файл, имя не может иметь символов подмены (wildcard). Параметр to - имя файла, который должен появиться у клиента, user - имя пользователя, инициировавшего обмен, options - список опций, контролирующих обмен, size - определяет максимальный размер файла, который может принять клиент. Допускаются следующие опции.

    d

    клиент должен создать каталог, если необходимо (по умолчанию);

    f

    клиент не должен создать каталог, если необходимо,вместо этого он должен прервать сессию;

    m

    клиент должен послать e-mail по адресу user в случае успешного завершения обмена.

    Сервер может прислать следующие отклики на r-команду.

    Отклик

    Описание

    ry mode [size]

    Сервер готов послать файл и начинает эту процедуру. Аргумент mode - восьмеричный код модификатора файла на сервере. Для некоторых версий bsd uucp аргумент mode может иметь в конце символ М, означающий, что сервер хочет стать клиентом и выдать команду-запрос

    rn2

    Сервер не может послать файл, так как это запрещено или потому, что такой файл отсутствует

    rn6

    Используется версией taylor uucp. Файл слишком велик (например, не соответствует ограничениям клиента)

    rn9

    Используется версией taylor uucp и fsuucp. Удаленная система не может открыть еще один канал. Можно попробовать позднее

    По завершении обмена клиент может послать следующие команды (сервер их может проигнорировать).

    cy файл благополучно передан;

    cn5 временный файл не может быть перемещен в окончательную позицию.

    Клиент может использовать команду x для запуска uucp на сервере. Команда может иметь формат x from to user -options. Параметр from - имя файла (или файлов) на ЭВМ-сервере, пересылку которого затребовал клиент. Команда может служить для пересылки файлов из сервера посторонней третьей системе. Параметр to является именем файла или каталога, куда будут перенесен файл (или файлы). Например, если клиент хочет получить файлы сам, можно использовать запись master!path. Сервер может прислать следующие отклики на команду x.

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

    xn Запрос отклонен (причина отклонения не сообщается, может быть сервер не поддерживает Х-запросы).

    Клиент может послать команду Е, которая имеет следующий формат:

    e from to user -options temp mode notify size command

    Е-команда поддерживается системой taylor uucp и служит для реализации запросов исполнения без использования файлов x.*. Эта команда применяется в случае, когда исполняемая команда требует входного файла, который используется ей в качестве стандартного ввода. Основные параметры команды имеют то же значение, что и в случае команды s. Список опций, управляющих обменом, представлен в таблице.

    Опция

    Описание

    c

    Файл копируется в каталог spool (клиент должен использовать temp, а не from)

    c

    Файл не копируется в каталог spool (по умолчанию)

    n

    e-mail сообщение не посылается даже в случае неудачи. Это эквивалентно n-команде в файле x.*.

    z

    Е-mail сообщение посылается, если при исполнении команды произошла ошибка (значение по умолчанию). Эквивалентно команде z в файле Х.*

    r

    Е-mail сообщение о результате выполнения посылается адресату, записанному в параметре notify. Эквивалентно команде r в файле Х.*

    e

    Исполнение должно проводиться с /bin/sh. Эквивалентно команде e файла Х.*.

    В поле command записывается команда, которая должна быть исполнена. Это эквивалентно команде c файла Х.*. Отклики сервера на Е-команду эквивалентны откликам на команду s, только начальное s заменяется на Е.

    Для переведения соединения в пассивное состояние клиент может использовать h-команду (не имеет параметров или опций). Сервер реагирует на нее h-откликом.

    hy

    сервер согласен заблокировать обмен. В некоторых пакетах uucp клиент также посылаете команду hy. После этого стартует процедура закрытия канала.

    hn

    Сервер не готов заблокировать обмен. После этого клиент и сервер меняются ролями, такой обмен ролями возможен несколько раз за время сессии.

    Если обмен завершен и клиент не намерен выдавать какие-либо запросы, связь прерывается. Клиент посылает сообщение \020ОООООО\000, на что сервер откликается посылкой строки \02ООООООО\000 (6 символов 'О' в первом и 7 - во втором случае). Какой-либо смысловой нагрузки этот обмен не несет, по этой причине некоторые пакеты его не производят.

    В рамках UUCP предусмотрено несколько вспомогательных протоколов.

    g-протокол предназначен для коррекции ошибок и поддерживается всеми версиями UUCP. Стандартная ширина окна в этом протоколе равна 3, а размер пакета 64 байтам, но в принципе предусмотрена возможность расширения окна при реализации потоков до 7 при размере пакетов 4096 байт. Протокол базируется на стандартных пакетных драйверах. Для реализации g-протокола используются пакеты с 6-байтовыми заголовками (управляющие пакеты содержат только заголовок). Формат этих пакетов представлен на рис. 4.4.14.1.1.

    Рис. 4.4.14.1. Формат пакетов g-протокола

    Пакет начинается с восьмеричного кода 020, далее следует поле k (1 ё k ё 9). Для управляющих пакетов k=9. Для информационных пакетов k определяет размер поля данных. k=1 соответствует 32 байтам данных, а k=9 - 4096 байтам. Далее следуют два байта контрольной суммы, контрольный байт, определяющий тип пакета, и xor-байт. Последний равен результату операции xor для полей k, младшего байта контрольной суммы, старшего байта контрольной суммы и контрольного байта. Этот байт служит для контроля целостности заголовка пакета.

    Управляющий байт заголовка содержит в себе три субполя (ttxxxyyy). Поле tt может принимать следующие значения.

    0

    Указатель управляющего пакета (k должно быть равно 9). При этом поле xxx определяет тип управляющего пакета;

    1

    Не используется UUCP;

    2

    Информационный пакет;

    3

    Короткий информационный пакет.

    Пусть длина поля данных, заданная k, равна 1, пусть также первый байт поля данных равен b1. Если b1 меньше 128, тогда истинное число байт в поле данных равно 1 - b1, начиная со второго байта. Если b1Ё 128 и второй байт поля данных b2, то истинное число байт в поле данных равно 1 - ((b1 & 0x7f) + (b2 << 7)), начиная с третьего байта. Контрольная сумма вычисляется для всех байтов поля данных.

    Один байт данных пересылается в любом случае. Для всех типов информационных пакетов поле ххх определяет порядковый номер пакета, а поле yyy определяет номер последнего пакета, принятого без ошибки, что и определяет максимальный размер окна, равный 7. Каждая из сторон, участвующих в обмене, использует окно, чтобы регистрировать число пакетов, которое может быть послано без получения подтверждения. Размер этого окна может лежать в пределах 1-7. Пакеты посылаются строго по очереди, получение всех пакетов должно быть подтверждено в том порядке, в каком они были посланы.

    В пакетах управления поле ххх может принимать следующие значения:

    CLOSE

    Соединение должно быть оборвано немедленно (например, обнаружено слишком много ошибок).

    RJ или NAK

    Последний пакет доставлен с ошибкой. В поле ууу записан номер последнего пакета, доставленного корректно.

    SRJ

    Выборочный отказ. Поле ууу содержит номер пакета, доставленного с ошибкой. Пакет должен быть послан повторно. В UUCP обычно не используется.

    RR или ACK

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

    INITA

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

    INITB

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

    INITC

    Третий пакет инициализации. Поле ууу содержит размер окна, который будет использован.

    Контрольная сумма управляющего пакета равна 0хаааа - с, где с - контрольный байт заголовка. Контрольная сумма информационного пакета равна 0хаааа - (check ^ c), где ^ обозначает операцию исключающее ИЛИ, а check результат работы программы, приведенной ниже и обрабатывающей поле данных. Исходными параметрами для этой программы является указатель на начало блока данных z и число байтов в блоке c.

    Int
    igchecksum (z, c)
    register const char *z;
    register int c;
    {
    register unsigned int ichk1, ichk2;
    ichk1 = 0xffff;
    ichk2 = 0;
    do
    {
    register unsigned int b;
    /* rotate ichk1 left. */
    if ((ichk1 & 0x8000) == 0)
    ichk1 <<= 1;
    else
    {
    ichk1 <<= 1;
    ++ichk1;
    }
    /* add the next character to ichk1. */
    b = *z++ & 0xff;
    ichk1 += b;
    /* add ichk1 xor the character position in the buffer counting from the back to ichk2. */
    ichk2 += ichk1 ^ c; /* if the character was zero, or adding it to ichk1 caused an overflow, xor ichk2 to ichk1. */
    if (b == 0 || (ichk1 & 0xffff) < b)
    ichk1 ^= ichk2;
    }
    while (--c > 0);
    return ichk1 & 0xffff;
    }

    Когда g-протокол запускается в работу, посылается управляющий пакет INITA с кодом желательного значения максимального размера окна. Сервер откликается пакетом INITA со своим предложением размера окна. После этого аналогичный обмен производится пакетами INITB и INITC. В результате каждая из сторон может использовать свой размер окна и длину посылаемых пакетов.

    Когда UUCP выдает команду, посылается один или более пакетов. В конце команды всегда посылается нулевой байт, который указывает на завершение командной строки. Когда пересылается файл, его завершение отмечается коротким информационным пакетом, содержащим нули. Прекращение работы протокола осуществляется посылкой управляющего пакета close.

    f-протокол. Этот протокол предназначен для пересылки 7-битных текстовых файлов. Здесь используются только символы от \040 (пробел) до \176 (~) и возврат каретки. Протокол весьма не эффективен для транспортировки 8-битовых данных. Его система контрольного суммирования не слишком надежна для больших файлов. Первоначально этот протокол предназначался для работы в сетях Х.25. В f-протоколе не предусмотрена процедура инициализации. При пересылке команды передается строка, завершающаяся символом возврат каретки. В процессе передачи файлов каждый байт b преобразуется в соответствии с таблицей.

    0 <= b <= 037: 0172, b + 0100 (0100 дo 0137)
    040 <= b <= 0171: b (040 до 0171)
    0172 <= b <= 0177: 0173, b - 0100 ( 072 до 077)
    0200 <= b <= 0237: 0174, b - 0100 (0100 до 0137)
    0240 <= b <= 0371: 0175, b - 0200 ( 040 до 0171)
    0372 <= b <= 0377: 0176, b - 0300 ( 072 до 077)

    Таким образом, байты между \040 и \171 включительно передаются без изменений, остальные перед отправкой преобразуются. Когда файл данных переслан, посылается 7-байтовая последовательность, включающая в себя два байта \176, за которыми следует 4 ASCII байта контрольной суммы (в шестнадцатеричном формате) и символ возврата каретки. Если контрольная сумма равна 0x1a2b, то будет послана последовательность \176\1761a2b\r.

    При вычислении контрольной суммы туда сначала заносится код 0xffff. Для вычисления контрольной суммы (ichk) используется следующая программа, которая выполняется перед отправкой каждого байта.

    /* rotate the checksum left. */
    if ((ichk & 0x8000) == 0)
    ichk <<= 1;
    else
    {
    ichk <<= 1;
    ++ichk;
    }
    /* add the next byte into the checksum. */
    ichk += b;

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

    G

    Файл принят без ошибок;

    R

    Ошибка в контрольной сумме, файл надо передать повторно;

    Q

    Контрольная сумма неверна, но уже совершено много попыток и сессию следует прервать

    t-протокол. Протокол предназначен для каналов, обеспечивающих надежную связь по схеме точка-точка (аналог TCP) для 8-битных данных. При посылке команды сначала определяется ее длина с. Затем посылается (с/512 +1)*512 байт, которые включают в себя строку команды и соответствующее число нулевых байтов. При пересылке файлов обмен идет блоками по 1024 байта. Каждый блок начинается с 4 байтов, характеризующих объем данных в блоке (формат аналогичен используемому UNIX-утилитой htonl). В конце файла передается блок нулевых байтов.

    e-протокол. Протокол подобен t-протоколу. Но здесь нет управления потоком и контроля ошибок. При посылке команды передается командная строка, завершающаяся нулевым байтом. При пересылке файла сначала посылается код его размера в виде ASCII десятичных цифр. Эта строка дополняется до 20 символов нулевыми байтами. Так, если длина файла 40000 байт, сначала посылается последовательность 40000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, после чего посылается собственно файл.

    G-протокол. Протокол используется SVR4 UUCP. Он идентичен G-протоколу за исключением того, что можно модифицировать окно и размер пакетов. В SVR4 реализации G-протокола размер окна всегда равен 7 а длина пакета 64 байтам.

    \

    i-протокол. Протокол написан Яном Лансом Тейлором и использован в taylor UUCP. Это протокол пересылки данных со скользящим окном, подобно G-протоколу. Но в отличие от этого протокола i-протокол поддерживает обмен данными в двух направлениях одновременно. Пакеты в этом протоколе имеют 6-байтовый заголовок. За полем данных следует 4-байтовая контрольная сумма. Определено 5 типов пакетов: DATA, SYNC, ACK, NAK, SPOS и CLOSE. Все они могут содержать поле данных. Пакеты типа DATA, SPOS и CLOSE имеют порядковые номера. Каждая из сторон нумерует пакеты независимо по модулю 32. Каждый из пакетов характеризуется локальным и удаленным номерами каналов. Каждому типу команд в локальной системе ставится в соответствие ненулевой локальный номер канала. Аналогичное правило справедливо и для удаленной системы. Это позволяет решить проблему одновременного двухстороннего информационного обмена. Для каждого файла протокол формирует указатель, в исходный момент равный нулю. После получения очередного пакета указатель соответствующим образом инкрементируется. Исключение представляют пакеты типа spos, которые служат для изменения указателя файла. Формат пакета i-протокола представлен на рис. 4.4.14.1.2.

    Рис. 4.4.14.1.2. Формат пакета i -протокола

    Заголовок начинается с флага ^g (восьмеричный код \007), далее следует 5-битовое поле пакет. Пакеты DATA, SPOS и CLOSE используют это поле для номера пакета. В пакетах NAK сюда заносится номер пакета, подлежащий повторной пересылке. В пакетах же ACK и SYNC это поле заполняется нулями. Поле ACK содержит 5 бит и служит для записи номера последнего пакета, принятого без ошибки. Это поле используется всеми типами пакетов. В трехбитовое поле тип определяет назначение пакета и может принимать следующие значения.

    0 'DATA'

    Информационный пакет;

    1 'SYNC'

    Пакет sync используется при инициализации соединения, поле пакет в для этого типа обнуляется;

    2 'ACK'

    Пакет-отклик. Так как пакет типа data также может использоваться для отклика, ack предназначен для случая, когда одной из сторон нечего посылать. Пакеты ack не нумеруются.

    3 'NAK'

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

    4 'SPOS'

    Пакет служит для изменения указателя файла. Пакет содержит 4 байта указателя файла (наиболее значащий байт первый).

    5 'CLOSE'

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

    Однобитовое поле d =1 для пакетов клиента и =0 для пакетов сервера. Поле длины поля данных состоит из двух секций (полный байт содержит младшую часть), имеет суммарную протяженность 12 бит, что позволяет варьировать поле данных в пределах от 0 до 4095 байт. Однобайтовое поле контрольная сумма содержит код, который представляет собой результат операции XOR, выполненной для байт заголовка, начиная со второго по пятый. После заголовка следует поле данных, за которым помещается 32-разрядная контрольная сумма информационного поля (CRC).

    При инициализации i-протокола стороны обмениваются SYNC-пакетами, которые содержат по крайней мере 3 байта. Первые два байта несут в себе максимальный размер пакетов, посылаемых удаленной стороной (старший байт первый). Третий байт определяет размер окна, используемый удаленной стороной. При этом могут посылаться пакеты любого размера, но не больше указанного максимального. Если SYNC содержит четвертый байт, то он хранит в себе номер канала (1-7), который может использовать удаленная система. Размер окна определяет число пакетов, которое может быть послано, не дожидаясь подтверждения получения. Подтверждаться может не каждый пакет. Если получено подтверждение получения пакета n, все предшествующие считаются полученными корректно. Если потерян пакет, посланный одной из сторон, другая может передавать пакеты, как ни в чем не бывало. Команды посылаются в виде последовательности информационных пакетов с ненулевым полем номера локального канала. Последний из пакетов в этом случае должен содержать нулевой байт в конце (обычно команда укладывается в один пакет). Файла передаются в виде последовательности пакетов, завершающейся пакетом нулевой длины. При получении отклика sn пересылка файла абортируется. Применение номеров каналов позволяет посылать команды и пересылать файлы одновременно.

    j-протокол. Этот протокол является разновидностью i-протокола написанного тем же автором. Протокол предназначен для коммуникационных каналов с возможностью перехвата некоторых символов, например xon или xoff. Протокол не выполняет детектирования или исправления ошибок. При инициализации j-протокола системы обмениваются последовательностями печатных ascii-символов, чтобы указать, какие из них стороны хотят исключить из употребления. Такая последовательность должна начинаться с символа ^ (восьмеричный код 136) и завершаться символом ~ (восьмеричный код 176). После отправления такой строки система ждет аналогичной посылки с противоположной стороны. Строки состоят из esc-последовательностей типа \ooo, где o - восьмеричная цифра. Например, посылка последовательности ^\021\023~ означает, что следует избегать символов xon и xoff. Блокировка использования символов из диапазона \040 - \176 запрещена. После указанного обмена включается стандартный i-протокол, но пакеты i-протокола вкладываются в j-пакеты. Заголовок j-пакетов содержит 7 байт. Формат заголовка пакета j-протокола показан на рис. 4.4.14.1.3.

    Рис. 4.4.14.1.3. Формат заголовка j-пакета

    Заголовок начинается с кода символа ^. Далее следует два байта поля длина (первый из них старший), которые характеризуют полную длину пакета в байтах. Запись в этом поле осуществляется в виде ascii-символов. Истинная длина пакета вычисляется согласно формуле: (l1 - 040)*0100 + (l2 - 040), где 040 ё l1 < 0177 и 040 ё l2 < 0140. После поля длина следует байт 075 (символ =), за которым следует два байта длины поля данных (равна размеру вложенного i-пакета в октетах). Заголовок завершается символом @ (восьмеричный код 0100). Все символы, запрещенные к использованию при инициализации, в случае их наличия в i-пакете подменяются печатными ASCII-символами. При этом для каждой такой подмены вводится два индексных байта (index-h и index_l). Индексные байты непосредственно следуют за байтами данных. В индексных байтах закодировано положение "запретного" символа в i-пакете. Преобразование запретных символов производится следующим образом. Если код символа больше или равно 0200, из него вычитается 0200, если при этом результат меньше 020 или равен 0177, над ним производится операция xor 020. Индексные байты представляют собой ASCII-символы. Истинное положение запретного символа вычисляется по формуле: (index-h - 040) * 040 + (index_l - 040). Значение index_l должно лежать в пределах 040 ё index_l < 0100, а index-h - 040 ё index-h < 0176.

    x-протокол. Протокол ориентирован на машины со встроенными картами Х.25 и предназначен для непосредственной пересылки 8-битовых данных без взаимодействия со слоями Х.28 или Х.29. Пересылка осуществляется 512 байтными пакетами.

    y-протокол. Протокол разработан Йоргом Квиком и используется в FX uucico. Протокол осуществляет контроль и коррекцию ошибок, он предназначен для передачи 8-битовых данных в поточном режиме. Здесь не предусмотрено подтверждения получения пакетов, по этой причине протокол удобен для полудуплексных каналов. Каждый пакет имеет 6-байтовый заголовок. Формат заголовка для y-пакетов показан на рис. 4.4.14.1.4.

    Рис. 4.4.14.1.4. Формат заголовка для y-пакетов

    Первое поле номер содержит два байта номера пакета, причем первый из байтов является младшей частью номера (это справедливо и для других полей заголовка). Нумерация начинается с нуля. Так как первый пакет всегда SYNC, информационные пакеты имеют номера, начиная с 1. Каждая из систем, участвующих в обмене, нумеруют пакеты независимо. Если старший бит 16-битового поля длины равен нулю, то в этом поле записано число байт в поле данных, следующем за заголовком. Если же старший бит равен 1, то данных в пакете нет, а сам он является управляющим пакетом. В этом случае поле длина определяет тип пакета. Содержимое двухбайтового поля контрольная сумма вычисляется по программе, приведенной в описании протокола f. Для пакетов, не содержащих данных, контрольная сумма равна нулю. Инициализация протокола начинается с того, что стороны обмениваются SYNC-пакетами. SYNC-пакет должен содержать по меньшей мере 4 байта данных. Первый из них содержит код версии протокола. Далее следует байт длины пакета, которая измеряется в блоках по 256 байт (максимальный размер поля данных 32768 байт, что соответствует коду длины 128). Завершается блок данных пакета SYNC двумя байтами флагов. В настоящее время их функции не определены и их следует обнулять. Определены следующие типы управляющих пакетов.

    0хFFFE 'YPKT_ACK'

    подтверждение корректного приема файла;

    0xFFFD 'YPKT_ERR'

    указывает на ошибку в контрольной сумме;

    0xFFFC 'YPKT_BAD'

    указывает на ошибку в порядковом номере, в поле длины или какую-либо еще ошибку.

    Если получен управляющий пакет, отличный от 'YPKT_ACK', соединение обрывается (это же делается при обнаружении других ошибок). Команда в y-протоколе представляет собой последовательность пакетов, завершающаяся нулевым байтом. Конец передачи файла отмечается посылкой пакета с нулем в поле длина.

    Существуют также d-, h- и v-протоколы UUCP, но они не имеют заметного применения.

    Previous: 4.4.14 Протокол электронной почты SMTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14.2 Почтовый протокол POP3


    previous up down next index index
    Previous: 4.4.14.1 Протокол обмена UUCP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP

    4.4.14.2 Почтовый протокол POP3
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для "домашних ЭВМ" слишком дорого поддерживать связь с Интернет круглые сутки.

    Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу.

    POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734.

    В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером - сторона, предлагающая услуги POP3.

    Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером.

    В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами.

    Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.

    Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).

    Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF.

    На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF.

    В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается.

    На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния.

    POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.

    Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822].

    В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция.

    LIST [сообщение]

    Аргументы: номер сообщения (опционно), который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION. При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число октетов в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message.

    Примеры использования команды LIST:

    Клиент выдает команду: LIST
    Сервер откликается: +OK 2 messages (320 octets)
    Сервер: 1 120
    Сервер: 2 200
    Сервер: .
    ...
    Клиент: LIST 2
    Сервер: +OK 2 200
    ...
    К: LIST 3
    С: -ERR no such message, only 2 messages in maildrop
    Здесь и далее символом К обозначается клиент, а символом С - сервер.

    STAT - аргументов не использует, возможный отклик +OK nn mm, где nn - номер сообщения, а mm - его длина в байтах. Пример использования:

    К: STAT
    С: +OK 2 320

    QUIT - аргументов не использует, возможный отклик +OK.

    Сервер POP3 удаляет все сообщения, помеченные как удаленные из почтового ящика, посылает соответствующий отклик и разрывает TCP связь. Пример:

    К: QUIT
    С: +OK dewey POP3 server signing off.

    RETR msg (msg - номер сообщения)

    Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.

    Пример использования команды:

    К: RETR 1
    С: +OK 120 octets
    С:
    С: .

    DELE msg (msg - номер сообщения)

    Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE.

    Пример использования команды:

    К: DELE 1
    С: +OK message 1 deleted
    ...
    К: DELE 2
    С: -ERR message 2 already deleted

    NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.

    RSET (не использует каких-либо аргументов)

    Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например:

    К: RSET

    С: +OK maildrop has 2 messages (320 octets)

    Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE.

    Ряд команд не входят в перечень обязательных (являются опционными).

    TOP msg n, где msg - номер сообщения, а n - число строк (используется только в режиме TRANSACTION).

    При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.

    UIDL [msg], где msg - номер сообщения является опционным (Unique-ID Listing).

    Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:

    К: UIDL
    С: +OK
    С: 1 whqtswO00WBw418f9t5JxYwZ
    С: 2 QhdPYR:00WBw1Ph7x7

    USER name, где name - характеризует почтовый ящик сервера.

    Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики:

    +OK name is a valid mailbox
    -ERR never heard of mailbox name
    Примеры использования команды USER:

    К: USER frated
    С: -ERR sorry, no mailbox for frated here
    ...
    К: USER mrose
    С: +OK mrose is a real hoopy frood

    PASS string (string - пароль для доступа к почтовому серверу)

    Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:

    +OK maildrop locked and ready
    -ERR invalid password
    -ERR unable to lock maildrop
    Пример диалога при использовании команды PASS:
    К: USER mrose
    С: +OK mrose is a real hoopy frood
    К: PASS secret
    С: -ERR maildrop already locked
    ...
    К: USER mrose
    С: +OK mrose is a real hoopy frood
    К: PASS secret
    С: +OK mrose's maildrop has 2 messages (320 octets)

    APOP name digest, где name - идентификатор почтового ящика, а digest - дайджест сообщения - MD5 (RFC-1828). Команда используется только на стадии авторизации.

    Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:

    где `process-ID' представляет собой десятичное значение PID процесса, clock - десятичное показание системных часов, а hostname - полное имя домена, где размещен сервер POP3.

    Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.

    Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.

    Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].

    Previous: 4.4.14.1 Протокол обмена UUCP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP


    previous up down next index index
    Previous: 4.4.14.2 Почтовый протокол POP3    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14.4 Многоцелевое расширение почты Интернет (MIME)

    4.4.14.3 Протокол Интернет для работы с сообщениями IMAP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Протокол IMAP представляет собой альтернативу POP-3. Также как и последний он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.

    1.Команды и отклики

    Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.

    1.1 Протокольный отправитель клиента и протокольный получатель сервера

    Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом - аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе "Форматы данных"). Во втором - аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа "+".

    Замечание: Если, вместо этого, сервер детектирует ошибку в команде, посылается отклик завершения bad с меткой, требующей игнорирования команды и предотвращения посылки клиентом каких-либо еще запросов.

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

    Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик.

    1.2 Протокольный отправитель сервера и протокольный получатель клиента

    Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс "*" и называются непомеченными откликами.

    Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки.

    Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no (отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка).

    Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия, в соответствии с первым символом метки "*" или "+".

    Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.

    Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.

    Доступ к сообщениям в IMAP 4.1 осуществляется с помощью уникального идентификатора или порядкового номера сообщения.

    1.3 Атрибут сообщения UID

    Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее.

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

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

    Замечание: UID для данного почтового ящика должен всегда изменяться монотонно. Если порядок записей изменен вне рамок IMAP, необходимо перегенерировать UID для данного почтового ящика, так как порядок старых значений UID в этом случае уже не будет монотонным.

    Еще одной причиной не сохранения UID может служить стирание старого и создание нового почтового ящика с тем же именем. Так как имя почтового ящика не изменилось, клиент может не знать об этом и пытаться использовать старые UID. Хорошим значением UID можно считать 32-битное представление даты и времени создания почтового ящика. Вполне приемлемо и значение 1, если имеется гарантия, что это значение никогда не будет использовано повторно, даже в случае стирания и создания нового почтового ящика с тем же именем.

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

    Атрибут порядкового номера сообщения

    Этот атрибут определяет порядковый номер сообщения в почтовом ящике, начиная с 1. Последующее сообщение всегда имеет значение этого атрибута на 1 большее, чем у предшествующего.

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

    Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, имеется 286 сообщений, имеющих меньшее значение UID и 236 сообщений с большими UID.

    1.4 Атрибут флагов сообщения

    Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.

    Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:

    \seen

    Сообщение прочитано

    \answered

    На сообщение послан ответ

    \flagged

    Сообщение "помечено" как срочное, требующее особого внимания

    \deleted

    Сообщение помечено как стертое для последующего удаления посредством expunge

    \draft

    Сообщения не является законченным (помечено, как проект).

    \recent

    Сообщение только что положено в почтовый ящик. Эта сессия является первой, где фигурирует данное сообщение; для последующих сессий это сообщение не будет иметь флага \recent. Флаг не может быть изменен клиентом.

    Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа "\". Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.

    Замечание: Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store, и по этой причине не может быть изменен вообще.

    Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола [SMTP], это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.

    Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения.

    2. Состояние и диаграмма исполнения

    Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы.

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

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

    В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика. В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.

    Рис. 4.4.14.2.1. Схема состояний для протокола IMAP

    (1) Cоединение без предварительной аутентификации (отклик OK)
    (2) Cоединение с предварительной аутентификацией (отклик PREAUTH)
    (3) Соединение отвергнуто (отклик BYE)
    (4) Успешное завершение команды LOGIN или AUTHENTICATE
    (5) Успешное завершение команды SELECT или EXAMINE
    (6) Выполнение команды CLOSE, или неудачная команда SELECT или EXAMINE
    (7) Выполнение команды LOGOUT, закрытие сервера, или прерывание соединения

    3. Формат данных

    IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL.

    Атом состоит из одного или более неспециализированных символов.

    Число состоит из одной или более цифр и характеризует некоторое числовое значение.

    Строка может иметь одну из двух форм: литерал или строка в кавычках. Литеральная форма является основной формой строки. Строка в кавычках является альтернативной формой, исключающей избыточность литеральной формы за счет ограничений, налагаемых на символы, используемые в строке.

    Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.

    Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой (<">). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF.

    Замечание: Даже если число октетов равно нулю, клиент, передающий литерал должен подождать прихода команды продолжения.

    3.1. 8-битовые и двоичные строки

    8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB]. Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. "Двоичная строка" - это любая строка из NUL символов. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую как BASE64, прежде чем их пересылать. Строка с большим числом символов CTL может рассматриваться как двоичная.

    3.2. Список в скобках

    Структуры данных представляются в виде списков, помещенных в скобки, элементы списка разделяются пробелами. Такой список может включать в себя другие "списки в скобках". Пустой список выглядит как () - "список в скобках" с нулевым числом членов.

    3.3. NIL

    Специальный атом "NIL" представляет собой указание на отсутствие каких-то определенных данных типа строка или "список в скобках". Его следует отличать от пустой строки "" или пустого "списка в скобках" ().

    4. Операционные соображения
    4.1. Присвоение имени почтовому ящику

    Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере" (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.

    4.2. Соглашение о пространстве имен почтовых ящиков

    В соответствии с соглашением первый иерархический элемент любого имени почтового ящика, который начинается с символа "#" указывает на "пространство имен" остальной части имени. Например, реализации, которые предлагают доступ к группам новостей USENET могут использовать пространство имен "#news", для того чтобы отделить пространство имен групп новостей от имен других почтовых ящиков. Таким образом, группа новостей comp.mail.misc будет иметь имя почтового ящика "#news.comp.mail.misc", а имя "comp.mail.misc" может относиться к другому объекту (напр., к почтовому ящику пользователя).

    4.3. Международное соглашение об именах почтовых ящиков

    Согласно договоренности имена международных почтовых ящиков специфицированы в соответствии модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7:

    1. UTF-7 использует символ "+" для смещения; это вызывает конфликт с обычным применением "+" в именах почтовых ящиков, в частности в именах групп новостей USENET.
    2. Кодировка UTF-7 базируется на BASE64, где используется символ "/", что вступает в конфликт с применением "/" в качестве популярного иерархического разделителя.
    3. UTF-7 запрещает использование "\"; что противоречит применению "\" в качестве популярного разделителя.
    4. UTF-7 запрещает использование "~", это вступает в конфликт с тем, что некоторые серверы рассматривают этот символ, как указатель на базовый каталог (home).
    5. UTF-7 допускает разнообразные формы представления одних и тех же строк, в частности, печатные символы US-ASCII могут использоваться в закодированной форме.

    В модифицированном UTF-7, печатные символы US-ASCII за исключением "&" представляются в исходном виде; то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7e. Символ "&" (0x26) представляется в виде двух октетной последовательности "&-". Все другие символы (значения октетов 0x00-0x1f, 0x7f-0xff, и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя.

    Символ "&" используется для перехода к модифицированной кодировке BASE64 а "-" для возврата назад к US-ASCII. Все имена начинаются с US-ASCII, и должны завершаться US-ASCII (то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом "-"). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках: ~peter/mail/&ZeVnLIqe-/&U,BTFw-

    4.4. Размер почтового ящика и актуализации состояния сообщений

    В любое время сервер может послать данные, которые клиент не запрашивал. Иногда, такое поведение системы является необходимым. Например, агенты, внешние по отношению к серверу, могут положить сообщения в почтовый ящик, изменить флаги сообщения в почтовом ящике (например, одновременный доступ в почтовый ящик нескольких агентов), или даже удалить сообщения из почтового ящика. Сервер должен автоматически послать уведомление об изменении размера почтового ящика, если такое изменение произошло в процессе выполнения команды. Сервер должен автоматически послать уведомление об изменении флагов сообщений, не требуя соответствующего запроса клиента. Имеются специальные правила для оповещения клиента сервером об удалении сообщений, чтобы избежать ошибок синхронизации (смотри также описание EXPUNGE). Программа клиента должна своевременно фиксировать изменения размера почтового ящика. Она не должна полагаться на то, что любая команда после начального выбора почтового ящика возвращает значение его размера.

    4.5. Отклик в случае, когда не исполняется никакой команды

    Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, или (2) использовать неблокирующую запись.

    4.6. Таймер автоматического отключения (Autologout)

    Если сервер имеет таймер выгрузки в случае длительной пассивности, тогда такой таймер должен быть настроен на время, по крайней мере, 30 минут. Получения любой команды от клиента в течение этого периода должно быть достаточно для сброса этого таймера.

    4.7. Одновременное исполнение нескольких команд

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

    Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента.

    Наиболее очевидный пример неопределенности реализуется, например, когда последовательно выполняются команды FETCH для флагов сообщения и STORE для тех же самых флагов.

    Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:

    FETCH + NOOP + STORE
    STORE + COPY + FETCH
    COPY + COPY
    CHECK + FETCH

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

    FETCH + STORE + SEARCH + CHECK
    STORE + COPY + EXPUNGE

    5. Команды клиента

    Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.

    5.1. Команды клиента - любое состояние

    Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.

    5.1.1. Команда CAPABILITY

    Аргументы: отсутствуют.
    Отклики: Необходим немаркированный отклик: CAPABILITY.
    Результат: OK - успешное завершение команды;
    BAD - команда неизвестна или неверный аргумент<./p>

    Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP".

    Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.

    Пример: C: abcd CAPABILITY
    S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
    S: abcd OK CAPABILITY completed

    5.1.2. Команда NOOP

    Аргументы: отсутствуют.
    Отклики: никакого специального отклика на эту команду не требуется.
    Результат: OK - команда успешно завершена;
    BAD - команда неизвестна или неверен аргумент;
    Команда NOOP ничего не делает и всегда успешно завершается.

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

    Пример: C: a002 NOOP
    S: a002 OK NOOP completed
    . . .
    C: a047 NOOP
    S: * 22 EXPUNGE
    S: * 23 EXISTS
    S: * 3 RECENT
    S: * 14 FETCH (FLAGS (\Seen \Deleted))
    S: a047 OK NOOP completed

    5.1.3. Команда LOGOUT

    Аргументы: отсутствуют.
    Отклики: необходим немаркированный отклик BYE.
    Результат: OK - прерывание сессии завершено;
    BAD - неизвестная команда или неверный аргумент.

    Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.

    Пример: C: A023 LOGOUT
    S: * BYE IMAP 4.1 Server logging out
    S: A023 OK LOGOUT completed
    (Сервер и клиент разорвали соединение)

    5.2. Команды клиента - в состоянии без аутентификации

    В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.

    Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.

    По завершении аутентификации невозможно вернуться непосредственно в состояние "без аутентификации". В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "без аутентификации" возможны команды: AUTHENTICATE и LOGIN.

    5.2.1. Команда AUTHENTICATE

    Аргументы: имя механизма аутентификации.
    Отклики: может быть запрошена дополнительная информация.

    Результат

    OK

    Аутентификация завершена, осуществлен переход в состояние "аутентификация выполнена";

    NO

    Ошибка аутентификации: неподдерживаемый механизм аутентификации, параметры аутентификации отвергнуты;

    BAD

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

    Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.

    Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.

    Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если механизм защиты согласовыван, то в дальнейшем он используется для всех сообщений, проходящих через данное соединение. Механизм защиты начинает действовать сразу после ввода последовательности CRLF, которая завершает аутентификационный обмен для клиента, и прихода CRLF маркированного отклика OK сервера. Раз механизм защиты вступил в силу, поток октетов команд и откликов заносится в буферы шифрованного текста. Каждый буфер передается через соединение в виде потока октетов, который начинается с четырех октетов, содержащих длину последующих данных. Максимальный размер буфера для текста-шифра определяется выбранным механизмом защиты.

    Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.

    Пример: S: * OK KerberosV4 IMAP4rev1 Server
    C: A001 AUTHENTICATE KERBEROS_V4
    S: + AmFYig==
    C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
    +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
    WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
    S: + or//EoAADZI=
    C: DiAF5A4gA+oOIALuBkAAmw==
    S: A001 OK Kerberos V4 authentication successful

    5.2.2. Команда LOGIN

    Аргументы: имя пользователя, пароль.
    Отклики: команда не требует какого-либо специального отклика.
    Результат: OK - login завершено, система в состоянии с аутентификацией;
    NO - login не прошла: имя пользователя или пароль отвергнуты;
    BAD - команда неизвестна или неверный аргумент.

    Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.

    Пример: C: a001 LOGIN SMITH SESAME
    S: a001 OK LOGIN completed

    5.3. Команды клиента в состоянии "аутентификация осуществлена"

    В состоянии "аутентификация осуществлена" разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние "выбрано" .

    В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.

    5.3.1. Команда SELECT

    Аргументы: имя почтового ящика.
    Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
    опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

    Результат: OK - процедура выбора закончена, система находится в состоянии "выбрано";
    NO - выбор неудачен: нет такого ящика, доступ к почтовому ящику невозможен;
    BAD - команда неизвестна или неверен аргумент.

    Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:

    FLAGS - флаги, определенные для почтового ящика.
    EXISTS Число сообщений в почтовом ящике.
    RECENT Число сообщений с набором флагов \Recent.
    OK [UIDVALIDITY ] Уникальный идентификатор корректности.

    Сервер должен также послать "невидимый" код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике.

    Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.

    Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом "[READ-WRITE]".

    Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме "только для чтения" и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика "[READ-ONLY]". Доступ "только для чтения" тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние некоторых флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа "только для чтения".

    Пример: C: A142 SELECT INBOX
    S: * 172 EXISTS
    S: * 1 RECENT
    S: * OK [UNSEEN 12] Message 12 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
    S: A142 OK [READ-WRITE] SELECT completed

    5.3.2. Команда EXAMINE

    Аргументы: имя почтового ящика.
    Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
    опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

    Результат:

    OK

    Осмотр закончен, система в состоянии "выбор сделан" ;

    NO

    Осмотр не прошел, система в состоянии "аутентификация выполнена"; нет такого почтового ящика; доступ к почтовому ящику невозможен;

    BAD

    Команда неизвестна или неверен аргумент.

    Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как "только для чтения". Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика "[READ-ONLY]".

    Пример: C: A932 EXAMINE blurdybloop
    S: * 17 EXISTS
    S: * 2 RECENT
    S: * OK [UNSEEN 8] Message 8 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
    S: A932 OK [READ-ONLY] EXAMINE completed

    5.3.3. Команда CREATE

    Аргументы: имя почтового ящика.
    Отклики: на эту команду не посылается каких-либо откликов.

    Результат

    OK

    команда выполнена;

    NO

    команда не выполнена: почтовый ящик с таким именем не может быть создан;

    BAD

    команда неизвестна или неверен аргумент.

    Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.

    Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды LIST), то это является декларацией клиента о намерении создать почтовый ящик с именем в рамках указанной иерархии. Реализации сервера, которые не требуют этой декларации, должны ее игнорировать.

    Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания "foo/bar/zap" на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.

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

    Пример: C: A003 CREATE owatagusiam/
    S: A003 OK CREATE completed
    C: A004 CREATE owatagusiam/blurdybloop
    S: A004 OK CREATE completed

    Замечание: интерпретация этого примера зависит от того, является ли символ "/" иерархическим сепаратором. Если "/" иерархический сепаратор, создается новый иерархический уровень с "owatagusiam" с новым членом иерархии этого уровня "blurdybloop". В противном случае создаются два почтовых ящика на одном и том же уровне иерархии.

    5.3.4. Команда DELETE

    Аргументы: имя почтового ящика.
    Отклики: команда не требует каких-либо откликов.
    Результат: OK - команда завершена;
    NO - ошибка при выполнении команды: не удается стереть ящик с этим именем;
    BAD - команда неизвестна или неверен аргумент.

    Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем.

    Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик "foo" имеет иерархическую структуру "foo.bar" (предполагается, что "." является иерархическим сепаратором), удаление "foo" не должно удалять "foo.bar". Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect.

    Разрешено удалять имена, которым соответствуют нижележащие иерархические уровни, но не имеющие атрибута имени \Noselect. В этом случае все сообщения из этого почтового ящика также будут удалены, а имя получит атрибут \Noselect.

    Значение наибольшего используемого уникального идентификатора удаленных почтовых ящиков должно сохраняться, так чтобы новые созданные ящики с тем же именем не использовали идентификаторы своих предшественников, если только новый ящик не имеет другое значение UID.

    Примеры: C: A682 LIST "" *
    S: * LIST () "/" blurdybloop
    S: * LIST (\Noselect) "/" foo
    S: * LIST () "/" foo/bar
    S: A682 OK LIST completed
    C: A683 DELETE blurdybloop
    S: A683 OK DELETE completed
    C: A684 DELETE foo
    S: A684 NO Name "foo" has inferior hierarchical names
    C: A685 DELETE foo/bar
    S: A685 OK DELETE Completed
    C: A686 LIST "" *
    S: * LIST (\Noselect) "/" foo
    S: A686 OK LIST completed
    C: A687 DELETE foo
    S: A687 OK DELETE Completed
    C: A82 LIST "" *
    S: * LIST () "." blurdybloop
    S: * LIST () "." foo
    S: * LIST () "." foo.bar
    S: A82 OK LIST completed
    C: A83 DELETE blurdybloop
    S: A83 OK DELETE completed
    C: A84 DELETE foo
    S: A84 OK DELETE Completed
    C: A85 LIST "" *
    S: * LIST () "." foo.bar
    S: A85 OK LIST completed
    C: A86 LIST "" %
    S: * LIST (\Noselect) "." foo
    S: A86 OK LIST completed

    5.3.5. Команда RENAME

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

    Результат:

    OK

    переименование успешно осуществилось;

    NO

    переименование не прошло: не удалось переименовать ящик с данным именем, не удалось присвоить новое имя;

    BAD

    команда неизвестна или неверен аргумент.

    Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать не существующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO.

    Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "foo" в "zap" переименует "foo/bar" (предполагая, что "/" является иерархическим разделителем) в "zap/bar".

    Значение наибольшего использованного уникального идентификатора имени старого почтового ящика должно быть сохранено, так чтобы новый создаваемый с тем же именем почтовый ящик не использовал идентификатора своего предшественника, если только он не имеет другого значения UID.

    Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX.

    Примеры: C: A682 LIST "" *
    S: * LIST () "/" blurdybloop
    S: * LIST (\Noselect) "/" foo
    S: * LIST () "/" foo/bar
    S: A682 OK LIST completed
    C: A683 RENAME blurdybloop sarasoop
    S: A683 OK RENAME completed
    C: A684 RENAME foo zowie
    S: A684 OK RENAME Completed
    C: A685 LIST "" *
    S: * LIST () "/" sarasoop
    S: * LIST (\Noselect) "/" zowie
    S: * LIST () "/" zowie/bar
    S: A685 OK LIST completed
    C: Z432 LIST "" *
    S: * LIST () "." INBOX
    S: * LIST () "." INBOX.bar
    S: Z432 OK LIST completed
    C: Z433 RENAME INBOX old-mail
    S: Z433 OK RENAME completed
    C: Z434 LIST "" *
    S: * LIST () "." INBOX
    S: * LIST () "." INBOX.bar
    S: * LIST () "." old-mail
    S: Z434 OK LIST completed

    5.3.6. Команда SUBSCRIBE

    Аргументы: имя почтового ящика.
    Отклики: эта команда не требует каких-либо специфических откликов.
    Результат: OK - процедура подписки завершена;
    NO - подписка не прошла: подписка для данного имени невозможна;
    BAD - команда неизвестна или неверен аргумент.

    Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку "активных" или "подписных" ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.

    Сервер может проверить аргумент команды SUBSCRIBE, чтобы проконтролировать его корректность для данного почтового ящика. Однако он не должен в одностороннем порядке удалять существующее имя почтового ящика из подписного листа, даже если ящика с таким именем более не существует.

    Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, "system-alerts") после того как срок годности его содержимого истек с тем, чтобы создать его вновь при появлении новых сообщений.

    Пример: C: A002 SUBSCRIBE #news.comp.mail.mime
    S: A002 OK SUBSCRIBE completed

    5.3.7. Команда UNSUBSCRIBE

    Аргументы: имя почтового ящика.
    Отклики: эта команда не требует каких-либо специфических откликов.
    Результат: OK - ликвидация подписки прошла успешно;
    NO - ликвидация подписки не прошла: это невозможно для данного имени;
    BAD - команда неизвестна или неверен аргумент.

    Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка "активных" или "подписных" почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.

    Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime
    S: A002 OK UNSUBSCRIBE completed

    5.3.8. Команда LIST

    Аргументы: имя,
    имя почтового ящика может содержать символы подмены (wildcard).
    Отклики: немаркированные отклики LIST.

    Результат:

    OK

    команда list выполнена;

    NO

    команда не прошла: не возможно выполнение list для данного образца или имени;

    BAD

    команда неизвестна или неверен аргумент.

    Команда LIST возвращает субнабор имен из полного набора, доступного клиенту. Присылается нуль или более немаркированных откликов LIST, содержащих атрибуты имен, иерархические разделители и имена.

    Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.

    Аргумент, содержащий пустую строку образца имени (""), указывает, что имя почтового ящика интерпретируется также, как это делает команда SELECT. Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровеня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени ("") представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени.

    Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо.

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

    Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:

    Шаблон

    Имя почтового ящика

    Интерпретация

    ~smith/Mail/

    foo.*

    ~smith/Mail/foo.*

    Archive/

    %

    archive/%

    #news.

    comp.mail.*

    #news.comp.mail.*

    ~smith/Mail/

    /usr/doc/foo

    /usr/doc/foo

    archive/

    ~fred/Mail/*

    ~fred/Mail/*

    Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что "~smith/Mail" не должно преобразоваться во что-то подобное "/u2/users/smith/Mail", иначе для клиента было бы невозможно определить, соответствовала ли интерпретация контексту шаблона.

    Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю. Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию "*" так, что начальный символ "/" будет приводить к несоответствию имени шаблону.

    Специальное имя INBOX включается в выдачу команды LIST, если INBOX поддерживается данным сервером для данного пользователя и, если строка "INBOX", напечатанная прописными буквами, соответствует интерпретированному шаблону.

    Пример: C: A101 LIST "" ""

    S: * LIST (\Noselect) "/" ""
    S: A101 OK LIST Completed
    C: A102 LIST #news.comp.mail.misc ""
    S: * LIST (\Noselect) "." #news.
    S: A102 OK LIST Completed
    C: A103 LIST /usr/staff/jones ""
    S: * LIST (\Noselect) "/" /
    S: A103 OK LIST Completed
    C: A202 LIST ~/Mail/ %
    S: * LIST (\Noselect) "/" ~/Mail/foo
    S: * LIST () "/" ~/Mail/meetings
    S: A202 OK LIST completed

    5.3.9. Команда LSUB

    Аргументы: имя-шаблон,
    имя почтового ящика может содержать символы подмены (wildcards).
    Отклики: немаркированный отклик: LSUB

    Результат:

    OK

    команда успешно исполнена;

    NO

    команда не прошла: не возможна выдача списка для предлагаемого шаблона или имени;

    BAD

    команда неизвестна или неверен аргумент.

    Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.

    Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.

    Пример: C: A002 LSUB "#news." "comp.mail.*"
    S: * LSUB () "." #news.comp.mail.mime
    S: * LSUB () "." #news.comp.mail.misc
    S: A002 OK LSUB completed

    5.3.10. Команда STATUS

    Аргументы: имя почтового ящика, статусная информация имен.
    Отклики: немаркированные отклики: STATUS.
    Результат: OK - команда успешно выполнена;
    NO - команда не прошла: нет статусной информации для данного имени;
    BAD - команда неизвестна или неверен аргумент.

    Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent).

    Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.

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

    MESSAGES

    Число сообщений в почтовом ящике

    RECENT

    Число сообщений с установленным флагом \Recent

    UIDNEXT

    Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто.

    UIDVALIDITY

    Уникальный валидатор почтового ящика

    UNSEEN

    Число сообщений, не имеющих установленного флага \Seen

    Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
    S: A042 OK STATUS completed

    5.3.11. Команда APPEND

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

    Отклики: команда не требует какого-либо специального отклика

    Результат:

    OK

    команда успешно исполнена

    NO

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

    BAD

    команда неизвестна или неверен аргумент

    Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.

    Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND.

    Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.

    Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).

    Пример: C: A003 APPEND saved-messages (\Seen) {310}
    C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
    C: From: Fred Foobar
    C: Subject: afternoon meeting
    C: To: mooch@owatagu.siam.edu
    C: Message-Id:
    C: MIME-Version: 1.0
    C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    C:
    C: Hello Joe, do you think we can meet at 3:30 tomorrow?
    C:
    S: A003 OK APPEND completed

    Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP].

    5.4. Команды клиента в состоянии "выбор сделан"

    В состоянии "выбор сделан", разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.

    5.4.1. Команда CHECK

    Аргументы: отсутствуют.
    Отклики: команда не требует какого-либо специального отклика;
    Результат: OK - проверка завершена;
    BAD - команда неизвестна или неверен аргумент.

    Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP.

    Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.

    Пример: C: FXXZ CHECK
    S: FXXZ OK CHECK Completed

    5.4.2. Команда CLOSE

    Аргументы: отсутствуют.
    Отклики: команда не требует какого-либо специального отклика.
    Результат: OK - команда выполнена, система в состоянии "аутентификация выполнена";
    NO - команда не прошла, никакого ящика не выбрано;
    BAD - команда неизвестна или неверен аргумент.

    Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние "аутентификация выполнена". Никакого немаркированного отклика EXPUNGE не посылается.

    Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме "только для чтения".

    Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент вероятно проигнорирует).

    Пример: C: A341 CLOSE
    S: A341 OK CLOSE completed

    5.4.3. Команда EXPUNGE

    Аргументы: отсутствуют.
    Отклики: немаркированные отклики: EXPUNGE.
    Результат: OK - команда успешно завершена;
    NO - команда не прошла: стирание не выполнено (например, запрещено);
    BAD - команда неизвестна или неверен аргумент.

    Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений.

    Пример: C: A202 EXPUNGE
    S: * 3 EXPUNGE
    S: * 3 EXPUNGE
    S: * 5 EXPUNGE
    S: * 8 EXPUNGE
    S: A202 OK EXPUNGE completed

    Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.

    5.4.4. Команда SEARCH

    Аргументы: опционны, [CHARSET]-спецификация.
    Критерии поиска (один или более).
    Отклики: необходим немаркированный отклик: SEARCH.
    Результат: OK - поиск завершен;
    NO - ошибка: поиск для данного набора символов или критериев не возможен;
    BAD - команда неизвестна или неверен аргумент

    Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора.

    Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT).

    Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).

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

    <набор сообщений>

    Сообщения с номерами, соответствующими специфицированному набору номеров

    ALL

    Все сообщения в почтовом ящике. Ключ отбора по умолчанию для применения команд AND

    ANSWERED

    Сообщения с установленным флагом \Answered.

    BCC <строка>

    Сообщения, которые содержат специфицированную строку в поле BCC структуры заголовка сообщения.

    BEFORE <дата>

    Сообщения, чьи внутренние даты раньше указанной.

    BODY <строка>

    Сообщения, которые содержат специфицированную строку в теле сообщения.

    CC <строка>

    Сообщения, которые содержат специфицированную строку в CC поле заголовка.

    DELETED

    Сообщения с установленным флагом \Deleted.

    DRAFT

    Сообщения с установленным флагом \Draft.

    FLAGGED

    Сообщения c установленным флагом \Flagged.

    FROM <строка>

    Сообщения, которые содержат специфицированную строку в поле FROM заголовка.

    HEADER <имя поля> <строка>

    Сообщения, которые содержат заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицированную строку в теле данного поля.

    KEYWORD <флаг>

    Сообщения со специфицированным ключевыми словами.

    LARGER

    Сообщения с размером [RFC-822] больше чем специфицированное число октетов.

    NEW

    Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функционально эквивалентно "(RECENT UNSEEN)".

    NOT <ключ поиска>

    Сообщения, которые не содержат специфицированного ключевого слова.

    OLD

    Сообщения, которые не имеют флага \Recent. "NOT RECENT" (противоположно "NOT NEW").

    ON <дата>

    Сообщения, чья внутренняя дата соответствует специфицированному значению даты.

    OR <ключ поиска 1> <ключ поиска 2>

    Сообщения, которые соответствуют любому из ключевых слов поиска.

    RECENT

    Сообщения, которые имеют установленный флаг \Recent.

    SEEN

    Сообщения, которые имеют установленный флаг \Seen.

    SENTBEFORE <дата>

    Сообщения, чье содержимое заголовка, соответствует дате ранее специфицированного значения [RFC-822].

    SENTON <дата>

    Сообщения, чье содержимое заголовка, соответствует специфицированной дате [RFC-822]

    SENTSINCE <дата>

    Сообщения, чье содержимое заголовка, соответствует [RFC-822]: специфицированному значению даты или позже.

    SINCE <дата>

    Сообщения, чья внутренняя дата соответствует или позже специфицированного значения.

    SMALLER

    Сообщения с размером [RFC-822] меньше чем специфицированное число октетов.

    SUBJECT <строка>

    Сообщения, которое содержит специфицированную строку в поле SUBJECT заголовка.

    TEXT <строка>

    Сообщения, которые содержат специфицированную строку в заголовке или теле сообщения

    TO <строка>

    Сообщения, которые содержат специфицированную строку в поле заголовка TO.

    UID <набор сообщений>

    Сообщения с уникальными идентификаторами, соответствующими заданному значению идентификатора.

    UNANSWERED

    Сообщения, которые не имеют флага \Answered.

    UNDELETED

    Сообщения, которые не имеют флага \Deleted.

    UNDRAFT

    Сообщения, которые не имеют флага \Draft.

    UNFLAGGED

    Сообщения, которые не имеют флага \Flagged.

    UNKEYWORD <флаг>

    Сообщения, которые не содержат заданных ключевых слов.

    UNSEEN

    Сообщения, которые не имеют флага \Seen.

    Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
    S: * SEARCH 2 84 882
    S: A282 OK SEARCH completed

    5.4.5. Команда FETCH

    Аргументы: набор сообщений,
    имена информационных сообщений.
    Отклики: немаркированные отклики: FETCH
    Результат: OK - операция успешно завершена;
    NO - команда не прошла: не удалось доставить эти данные;
    BAD - команда неизвестна или неверен аргумент.

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

    ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
    BODY Нерасширяемая форма BODYSTRUCTURE.
    BODY[

    ]<>

    Текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:

    HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок.

    Каждое сообщение имеет номер, по крайней мере, одной части.

    Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 1.

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

    Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях, вставляется разграничивающая пустая строка между заголовком и телом сообщения.

    Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:

    HEADER ([RFC-822] заголовок сообщения)
    TEXT MULTIPART/MIXED
    1 TEXT/PLAIN
    2 APPLICATION/OCTET-STREAM
    3 MESSAGE/RFC822
    3.HEADER ([RFC-822] заголовок сообщения)
    3.TEXT ([RFC-822] текстовое тело сообщения)
    3.1 TEXT/PLAIN
    3.2 APPLICATION/OCTET-STREAM
    4 MULTIPART/MIXED
    4.1 IMAGE/GIF
    4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
    4.2 MESSAGE/RFC822
    4.2.HEADER ([RFC-822] заголовок сообщения)
    4.2.TEXT ([RFC-822] текстовое тело сообщения)
    4.2.1 TEXT/PLAIN
    4.2.2 MULTIPART/ALTERNATIVE
    4.2.2.1 TEXT/PLAIN
    4.2.2.2 TEXT/RICHTEXT

    Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору части открытой угловой скобки ("<"), положения первого нужного октета, точки, максимального требуемого числа октетов и закрывающей угловой скобки. Если начальный октет находится за пределами текста, возвращается пустая строка.

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

    Замечание: это означает, что запрос BODY[]<0.2048> сообщения длиной 1500 октетов пришлет BODY[]<0> с литералом размера 1500, а не BODY[].

    BODY.PEEK[

    ] <>

    Альтернативная форма BODY[

    ], которая не устанавливает флаг \Seen.

    BODYSTRUCTURE

    Структура тела сообщения [MIME-IMB]. Она вычисляется сервером путем разбора полей заголовка [MIME-IMB] [RFC-822] и заголовков [MIME-IMB].

    ENVELOPE

    Структура заголовка сообщения. Она вычисляется сервером в результате разбора заголовка [RFC-822] на части, присваивая им значения по умолчания, если это необходимо.

    FAST

    Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE)

    FLAGS

    Флаги, присвоенные сообщению.

    FULL

    Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)

    INTERNALDATE

    Внутренняя дата сообщения.

    RFC822

    Функционально эквивалентно BODY[], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822).

    RFC822.HEADER

    Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных FETCH (возвращает данные в формате RFC822.HEADER).

    RFC822.SIZE

    Размер сообщения [RFC-822].

    RFC822.TEXT

    Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822.TEXT).

    UID

    Уникальный идентификатор сообщения.

    Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
    S: * 2 FETCH ....
    S: * 3 FETCH ....
    S: * 4 FETCH ....
    S: A654 OK FETCH completed

    5.4.6. Команда STORE

    Аргументы: набор сообщений,
    имя элемента сообщения,
    значение элемента сообщения.
    Отклики: немаркированные отклики: FETCH.
    Результат: OK - операция успешно завершена;
    NO - команда не прошла: данные не могут быть запомнены;
    BAD - команда неизвестна или неверен аргумент.

    Команда STORE заносит данные в почтовый ящик. В норме команда STORE возвращает обновленную версию данных с немаркированным откликом FETCH. ".SILENT" в имени элемента данных блокирует немаркированный отклик FETCH, и сервер должен предполагать, что клиент определил обновленное значение сам или ему обновленное значение не нужно.

    Замечание: вне зависимости от того используется или нет суффикс ".SILENT", сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения.

    В настоящее время определены следующие элементы данных:

    FLAGS <список флагов>

    Заменить флаги для сообщения, приведенного в аргументе. Новое значение флагов присылается, как если бы выполнялась команда FETCH для этих флагов.

    FLAGS.SILENT <список флагов>

    Эквивалентно FLAGS, но без возвращения нового значения.

    +FLAGS <список флагов>

    Добавить аргумент к флагам сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.

    +FLAGS.SILENT <список флагов>

    Эквивалентно +FLAGS, но без возвращения нового значения.

    -FLAGS <список флагов>

    Удаляет аргумент из флагов сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.

    -FLAGS.SILENT <список флагов>

    Эквивалентно -FLAGS, но без возвращения нового значения.

    Пример: C: A003 STORE 2:4 +FLAGS (\Deleted)
    S: * 2 FETCH FLAGS (\Deleted \Seen)
    S: * 3 FETCH FLAGS (\Deleted)
    S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
    S: A003 OK STORE completed

    5.4.7. Команда COPY

    Аргументы: набор сообщений,
    имя почтового ящика.
    Отклики: команда не требует какого-либо специального отклика.

    Результат:

    OK

    команда успешно завершена;

    NO

    команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик;

    BAD

    команда неизвестна или неверен аргумент.

    Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии.

    Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.

    Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY.

    Пример: C: A003 COPY 2:4 MEETING
    S: A003 OK COPY completed

    5.4.8. Команда UID

    Аргументы: имя команды,
    аргументы команды.
    Отклики: немаркированные отклики: FETCH, SEARCH.
    Результат: OK - команда UID завершена;
    NO - команда UID не прошла;
    BAD - команда неизвестна или неверен аргумент.

    Команда UID имеет две формы. В первой форме она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.

    Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению порядкового номера сообщения 1:100 и UID 443:557.

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

    Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.

    Пример: C: A999 UID FETCH 4827313:4828442 FLAGS
    S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
    S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
    S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
    S: A999 UID FETCH completed

    5.5. Команды клиента - экспериментальные и расширения
    5.5.1. Команда X

    Аргументы: определяется приложением.
    Отклики: определяется приложением.
    Результат: OK - команда выполнена;
    NO - отказ;
    BAD - команда неизвестна или неверен аргумент.

    Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X.

    Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды.

    Пример: C: a441 CAPABILITY
    S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
    S: a441 OK CAPABILITY completed
    C: A442 XPIG-LATIN
    S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
    S: A442 OK XPIG-LATIN completed-cay

    6. Отклики сервера

    Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".

    Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.

    Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными".

    Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений).

    Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.

    Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.

    Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.

    6.1. Отклики сервера - отклики состояния

    Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы.

    Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:

    ALERT

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

    NEWNAME

    За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика.

    PARSE

    Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике.

    PERMANENTFLAGS

    Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике.

    READ-ONLY

    Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only.

    READ-WRITE

    Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write.

    TRYCREATE

    Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE

    UIDVALIDITY

    Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора.

    UNSEEN

    Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen.

    Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.

    6.1.1. Отклик OK

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.

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

    Пример: S: * OK IMAP4rev1 server ready
    C: A001 LOGIN fred blurdybloop
    S: * OK [ALERT] System shutdown in 10 minutes
    S: A001 OK LOGIN Completed

    6.1.2. Отклик NO

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.

    Пример: C: A222 COPY 1:2 owatagusiam
    S: * NO Disk is 98% full, please delete unnecessary data
    S: A222 OK COPY completed
    C: A223 COPY 3:200 blurdybloop
    S: * NO Disk is 98% full, please delete unnecessary data
    S: * NO Disk is 99% full, please delete unnecessary data
    S: A223 NO COPY failed: disk is full

    6.1.3. Отклик BAD

    Содержимое: опционный код отклика;
    текст, читаемый человеком

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

    Пример: C: ...very long command line...
    S: * BAD Command line too long
    C: ...empty line...
    S: * BAD Empty command line
    C: A443 EXPUNGE
    S: * BAD Disk crash, attempting salvage to a new disk!
    S: * OK Salvage successful, no data lost
    S: A443 OK Expunge completed

    6.1.4. Отклик PREAUTH

    Содержимое: опционный код отклика;
    текст, читаемый человеком

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

    Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith

    6.1.5. Отклик BYE

    Содержимое: опционный код отклика;
    текст, читаемый человеком

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

    1. Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.
    2. Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.
    3. Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.
    4. Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение.

    Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.

    Пример: S: * BYE Autologout; idle for too long

    6.2. Отклики сервера - сообщения о состоянии сервера и почтового ящика

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

    6.2.1. Отклик CAPABILITY

    Содержимое: список возможностей.

    Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1".

    Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.

    Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".

    Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.

    Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN

    6.2.2. Отклик LIST

    Содержимое: атрибуты имени, иерархический разделитель, имя.

    Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.

    Определено четыре атрибута имени:

    \Noinferiors

    Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем.

    \Noselect

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

    \Marked

    Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран.

    \Unmarked

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

    Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.

    Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.

    Пример: S: * LIST (\Noselect) "/" ~/Mail/foo

    6.2.3. Отклик LSUB

    Содержимое: атрибуты имени, иерархический разграничитель, имя.

    Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.

    Пример: S: * LSUB () "." #news.comp.mail.misc

    6.2.4. Отклик STATUS

    Содержимое: имя, статусный список, заключенный в скобки.

    Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.

    Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

    6.2.5. Отклик SEARCH

    Содержимое: нуль или более чисел.

    Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH - их уникальные идентификаторы. Числа отделяются друг от друга пробелами.

    Пример: S: * SEARCH 2 3 6

    6.2.6. Отклик FLAGS

    Содержимое: список флагов, заключенный в скобки.

    Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.

    Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

    6.3. Отклики сервера - размер почтового ящика

    Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом "*" определяет количество сообщений.

    6.3.1. Отклик EXISTS

    Содержимое: отсутствует.

    Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.

    Пример: S: * 23 EXISTS

    6.3.2. Отклик RECENT

    Содержимое: отсутствует.

    Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).

    Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.

    Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.

    Пример: S: * 5 RECENT

    6.4. Отклики сервера - статусное сообщение

    Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения.

    6.4.1. Отклик EXPUNGE

    Содержимое: отсутствует.

    Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика. Порядковые номера последующих сообщений немедленно уменьшаются на единицу.

    Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи "снизу-вверх" пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.

    Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.

    Информация отклика EXPUNGE должна регистрироваться клиентом.

    Пример: S: * 44 EXPUNGE

    6.4.2. Отклик FETCH

    Содержимое: текст сообщения.

    Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:

    BODY Форма BODYSTRUCTURE без расширения данных.
    BODY[

    ]<>

    Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.

    Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[]<0> может быть укорочено, но BODY[] никогда не укорачивается.

    Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.

    Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность.

    BODYSTRUCTURE - список, заключенный в скобки, который описывает [MIME-IMB],
    структура тела сообщения.

    Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию.

    Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)

    Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).

    Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED"))

    Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:

    Список параметров тела, заключенный в скобки.

    Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB].

    Размещение тела

    Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.

    Язык тела

    Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].

    Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:

    Тип тела

    Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].

    Субтип тела

    Строка, описывающая имя субтипа, как это определено в [MIME-IMB].

    Список параметров тела, заключенный в скобки

    Список пар атрибут/значение, заключенный в скобки, [например, ("foo" "bar" "baz" "rag"), где "bar" является значением "foo", а "rag" - значением "baz"], как это описано в [MIME-IMB].

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

    Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].

    Описание тела

    Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].

    Шифрование тела

    Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].

    Размер тела

    Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.

    Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.

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

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

    Данные расширения для несоставной части тела располагаются в следующем порядке:

    MD5 тела

    Строка, содержащая значение MD5 тела, как это описано в [MD5].

    Размещение тела

    Список, заключенный в скобки, с тем же содержимым и функциями, что и размещение тела для составной части тела.

    Язык тела

    Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].

    Любые последующие данные расширения пока не определены в данной версии протокола.

    ENVELOPE - список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.

    Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.

    Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.

    Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.

    Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.

    FLAGS

    Список флагов, установленных для данного сообщения, заключенный в скобки.

    INTERNALDATE

    Строка, представляющая внутреннюю дату сообщения.

    RFC822

    Эквивалент BODY[].

    RFC822.HEADER

    Эквивалент BODY.PEEK[HEADER].

    RFC822.SIZE

    Число, выражающее размер сообщения [RFC-822].

    RFC822.TEXT

    Эквивалент BODY[TEXT].

    UID

    Число, выражающее уникальный идентификатор сообщения.

    Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

    6.5 Отклики сервера - запрос продолжения команды

    Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.

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

    Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.

    Пример: C: A001 LOGIN {11}
    S: + Ready for additional command text
    C: FRED FOOBAR {7}
    S: + Ready for additional command text
    C: fat man
    S: A001 OK LOGIN completed
    C: A044 BLURDYBLOOP {102856}
    S: A044 BAD No such command as "BLURDYBLOOP"

    7. Пример соединения IMAP 4.1

    Последующее является записью для соединения IMAP 4.1. (Данный пример и нижеприведенное описание синтаксиса практически без изменения взято из документа RFC-2060).

    S: * OK IMAP4rev1 Service Ready
    C: a001 login mrc secret
    S: a001 OK LOGIN completed
    C: a002 select inbox
    S: * 18 EXISTS
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * 2 RECENT
    S: * OK [UNSEEN 17] Message 17 is the first unseen message
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: a002 OK [READ-WRITE] SELECT completed
    C: a003 fetch 12 full
    S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
    RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
    "IMAP4rev1 WG mtg summary and minutes"
    (("Terry Gray" NIL "gray" "cac.washington.edu"))
    (("Terry Gray" NIL "gray" "cac.washington.edu"))
    (("Terry Gray" NIL "gray" "cac.washington.edu"))
    ((NIL NIL "imap" "cac.washington.edu"))
    ((NIL NIL "minutes" "CNRI.Reston.VA.US")
    ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
    "")
    BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
    S: a003 OK FETCH completed
    C: a004 fetch 12 body[header]
    S: * 12 FETCH (BODY[HEADER] {350}
    S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
    S: From: Terry Gray gray@cac.washington.edu
    S: Subject: IMAP4rev1 WG mtg summary and minutes
    S: To: imap@cac.washington.edu
    S: cc: minutes@CNRI.Reston.VA.US, John Klensin KLENSIN@INFOODS.MIT.EDU
    S: Message-Id: B27397-0100000@cac.washington.edu
    S: MIME-Version: 1.0
    S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    S:
    S: )
    S: a004 OK FETCH completed
    C: a005 store 12 +flags \deleted
    S: * 12 FETCH (FLAGS (\Seen \Deleted))
    S: a005 OK +FLAGS completed
    C: a006 logout
    S: * BYE IMAP4rev1 server terminating connection
    S: a006 OK LOGOUT completed

    8. Формальный синтаксис

    Последующая синтаксическая спецификация использует нотацию Бакуса-Наура (BNF - Backus-Naur Form), как это описано в [RFC-822] с одним исключением, разделителем, используемым в конструкции "#", служит одиночный пробел (SPACE), а не одна или более запятых.

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

    address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")"
    addr_adl ::= nstring
    ;; Хранит маршрут из route-addr [RFC-822], если не равно нулю
    addr_host ::= nstring
    ;; NIL указывает на синтаксис группы [RFC-822].
    ;; В противном случае, содержит имя домена [RFC-822]
    addr_mailbox ::= nstring
    ;; NIL индицирует конец группы [RFC-822]; если не NIL, а addr_host равно NIL,
    ;; содержит имя группы ;; [RFC-822].
    ;; В противном случае, содержит локальную часть [RFC-822]
    addr_name ::= nstring
    ;; Содержит фразу из почтового ящика [RFC-822], если не NIL
    alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
    "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
    "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
    "Y" / "Z" /
    "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
    "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
    "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
    "y" / "z"
    ;; Чувствительно к набору строчными или прописными буквами
    append ::= "APPEND" SPACE mailbox [SPACE flag_list]
    [SPACE date_time] SPACE literal
    astring ::= atom / string
    atom ::= 1*ATOM_CHAR
    ATOM_CHAR ::=
    atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
    quoted_specials
    authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
    auth_type ::= atom
    ;; Определено в [IMAP-AUTH]
    base64 ::= *(4base64_char) [base64_terminal]
    base64_char ::= alpha / digit / "+" / "/"
    base64_terminal ::= (2base64_char "==") / (3base64_char "=")
    body ::= "(" body_type_1part / body_type_mpart ")"
    body_extension ::= nstring / number / "(" 1#body_extension ")"
    ;; Будущее расширение. Реализации клиента должны воспринимать поля
    ;; body_extension. Реализации сервера не должны генерировать
    ;; поля body_extension, за исключением случаев, закрепленных в будущих
    ;; стандартах или зарегистрированных модификациях уже существующих норм.
    body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp
    [SPACE body_fld_lang
    [SPACE 1#body_extension]]]
    ;; не должны присылаться при non-extensible доставке "BODY"
    body_ext_mpart ::= body_fld_param
    [SPACE body_fld_dsp SPACE body_fld_lang
    [SPACE 1#body_extension]]
    ;; MUST NOT be returned on non-extensible "BODY" fetch
    body_fields ::= body_fld_param SPACE body_fld_id SPACE
    body_fld_desc SPACE body_fld_enc SPACE
    body_fld_octets
    body_fld_desc ::= nstring
    body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil
    body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
    "QUOTED-PRINTABLE") <">) / string
    body_fld_id ::= nstring
    body_fld_lang ::= nstring / "(" 1#string ")"
    body_fld_lines ::= number
    body_fld_md5 ::= nstring
    body_fld_octets ::= number
    body_fld_param ::= "(" 1#(string SPACE string) ")" / nil
    body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
    [SPACE body_ext_1part]
    body_type_basic ::= media_basic SPACE body_fields
    ;; субтип MESSAGE не должен следовать "RFC822"
    body_type_mpart ::= 1*body SPACE media_subtype
    [SPACE body_ext_mpart]
    body_type_msg ::= media_message SPACE body_fields SPACE envelope
    SPACE body SPACE body_fld_lines
    body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines
    capability ::= "AUTH=" auth_type / atom
    ;; Новая возможность должна начинаться с "X" или быть зарегистрирована
    ;; IANA в качестве стандарта или являться усовершенствованием
    ;; существующего стандарта
    capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"
    [SPACE 1#capability]
    ;; серверы IMAP 4.1, которые предлагают совместимость с RFC 1730
    ;; должны включать "IMAP4" в список возможностей этой реализации
    CHAR ::= 0x01 - 0x7f>
    CHAR8 ::=
    command ::= tag SPACE (command_any / command_auth /
    command_nonauth / command_select) CRLF
    ;; Modal based on state
    command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
    ;; Справедливо для всех состояний
    command_auth ::= append / create / delete / examine / list / lsub /
    rename / select / status / subscribe / unsubscribe
    ;; Работает только в состояниях Authenticated или Selected
    command_nonauth ::= login / authenticate
    ;; Работает только в состоянии Non-Authenticated
    command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
    copy / fetch / store / uid / search
    ;; Работает только в состоянии Selected
    continue_req ::= "+" SPACE (resp_text / base64)
    copy ::= "COPY" SPACE set SPACE mailbox
    CR ::=
    create ::= "CREATE" SPACE mailbox
    ;; Использование INBOX не приводит к ошибке
    CRLF ::= CR LF
    CTL ::= 0x00 - 0x1f, 0x7f>
    date ::= date_text / <"> date_text <">
    date_day ::= 1*2digit
    ;; День месяца
    date_day_fixed ::= (SPACE digit) / 2digit
    ;; Версия с фиксированным форматом date_day
    date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
    "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
    date_text ::= date_day "-" date_month "-" date_year
    date_year ::= 4digit
    date_time ::= <"> date_day_fixed "-" date_month "-" date_year
    SPACE time SPACE zone <">
    delete ::= "DELETE" SPACE mailbox
    ;; Использование INBOX не приводит к ошибке
    digit ::= "0" / digit_nz
    digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
    envelope ::= "(" env_date SPACE env_subject SPACE env_from
    SPACE env_sender SPACE env_reply_to SPACE env_to
    SPACE env_cc SPACE env_bcc SPACE env_in_reply_to
    SPACE env_message_id ")"
    env_bcc ::= "(" 1*address ")" / nil
    env_cc ::= "(" 1*address ")" / nil
    env_date ::= nstring
    env_from ::= "(" 1*address ")" / nil
    env_in_reply_to ::= nstring
    env_message_id ::= nstring
    env_reply_to ::= "(" 1*address ")" / nil
    env_sender ::= "(" 1*address ")" / nil
    env_subject ::= nstring
    env_to ::= "(" 1*address ")" / nil
    examine ::= "EXAMINE" SPACE mailbox
    fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
    "FAST" / fetch_att / "(" 1#fetch_att ")")
    fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
    "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
    "BODY" ["STRUCTURE"] / "UID" /
    "BODY" [".PEEK"] section
    ["<" number "." nz_number ">"]
    flag ::= "\Answered" / "\Flagged" / "\Deleted" /
    "\Seen" / "\Draft" / flag_keyword / flag_extension
    flag_extension ::= "\" atom

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

    flag_keyword ::= atom
    flag_list ::= "(" #flag ")"
    greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
    header_fld_name ::= astring
    header_list ::= "(" 1#header_fld_name ")"
    LF ::=
    list ::= "LIST" SPACE mailbox SPACE list_mailbox
    list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
    list_wildcards ::= "%" / "*"
    literal ::= "{" number "}" CRLF *CHAR8
    ;; Число характеризует количество октетов CHAR8
    login ::= "LOGIN" SPACE userid SPACE password
    lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
    mailbox ::= "INBOX" / astring
    ;; INBOX не чувствителен к использованию строчных или прописных букв.
    ;; все версии написания INBOX (напр., "iNbOx") должны
    ;; интерпретироваться как INBOX, а не как строку.
    mailbox_data ::= "FLAGS" SPACE flag_list /
    "LIST" SPACE mailbox_list /
    "LSUB" SPACE mailbox_list /
    "MAILBOX" SPACE text /
    "SEARCH" [SPACE 1#nz_number] /
    "STATUS" SPACE mailbox SPACE
    "(" # number SPACE "EXISTS" / number SPACE "RECENT"
    mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
    "\Noselect" / "\Unmarked" / flag_extension) ")"
    SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
    media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
    "MESSAGE" / "VIDEO") <">) / string)
    SPACE media_subtype
    ;; Определено в [MIME-IMT]
    media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <">
    ;; Определено в [MIME-IMT]
    media_subtype ::= string
    ;; Определено в [MIME-IMT]
    media_text ::= <"> "TEXT" <"> SPACE media_subtype
    ;; Определено в [MIME-IMT]
    message_data ::= nz_number SPACE ("EXPUNGE" /
    ("FETCH" SPACE msg_att))
    msg_att ::= "(" 1#("ENVELOPE" SPACE envelope /
    "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
    "INTERNALDATE" SPACE date_time /
    "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
    "RFC822.SIZE" SPACE number /
    "BODY" ["STRUCTURE"] SPACE body /
    "BODY" section ["<" number ">"] SPACE nstring /
    "UID" SPACE uniqueid) ")"
    nil ::= "NIL"
    nstring ::= string / nil
    number ::= 1*digit
    ;; 32-битное целое число без знака
    ;; (0 <= n < 4,294,967,296)
    nz_number ::= digit_nz *digit
    ;; 32-битное не равное нулю целое число без знака
    ;; (0 < n < 4,294,967,296)
    password ::= astring
    quoted ::= <"> *QUOTED_CHAR <">
    QUOTED_CHAR ::= /
    "\" quoted_specials
    quoted_specials ::= <"> / "\"
    rename ::= "RENAME" SPACE mailbox SPACE mailbox
    ;; Использование INBOX в качестве места назначения не дает ошибки
    response ::= *(continue_req / response_data) response_done
    response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
    mailbox_data / message_data / capability_data)
    CRLF
    response_done ::= response_tagged / response_fatal
    response_fatal ::= "*" SPACE resp_cond_bye CRLF
    ;; Сервер закрывает соединение немедленно
    response_tagged ::= tag SPACE resp_cond_state CRLF
    resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
    ;; Условие аутентификации
    resp_cond_bye ::= "BYE" SPACE resp_text
    resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
    ;; Условие состояния
    resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
    ;; текст не должен начинаться с "[" или "="
    resp_text_code ::= "ALERT" / "PARSE" /
    "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
    "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
    "UIDVALIDITY" SPACE nz_number /
    "UNSEEN" SPACE nz_number /
    atom [SPACE 1*]
    search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
    1#search_key

    ;; Символьный набор [CHARSET] должен быть зарегистрирован IANA

    search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
    "BEFORE" SPACE date / "BODY" SPACE astring /
    "CC" SPACE astring / "DELETED" / "FLAGGED" /
    "FROM" SPACE astring /
    "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
    "ON" SPACE date / "RECENT" / "SEEN" /
    "SINCE" SPACE date / "SUBJECT" SPACE astring /
    "TEXT" SPACE astring / "TO" SPACE astring /
    "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
    "UNKEYWORD" SPACE flag_keyword / "UNSEEN" /

    ;; Выше этой строки все в [IMAP2]

    "DRAFT" /
    "HEADER" SPACE header_fld_name SPACE astring /
    "LARGER" SPACE number / "NOT" SPACE search_key /
    "OR" SPACE search_key SPACE search_key /
    "SENTBEFORE" SPACE date / "SENTON" SPACE date /
    "SENTSINCE" SPACE date / "SMALLER" SPACE number /
    "UID" SPACE set / "UNDRAFT" / set /
    "(" 1#search_key ")"
    section ::= "[" [section_text / (nz_number *["." nz_number]
    ["." (section_text / "MIME")])] "]"
    section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"]
    SPACE header_list / "TEXT"
    select ::= "SELECT" SPACE mailbox
    sequence_num ::= nz_number / "*"

    ;; * является наибольшим используемым числом. Для порядковых номеров
    ;; сообщений оно равно количеству сообщений в почтовом ящике.
    ;; Для уникальных идентификаторов оно равно уникальному
    ;; идентификатору последнего сообщения в почтовом ящике./p>

    set ::= sequence_num / (sequence_num ":" sequence_num) /
    (set "," set)

    ;; Идентифицирует набор сообщений. Для порядковых номеров
    ;; сообщений это последовательность чисел с 1 до числа
    ;; сообщений в почтовом ящике.
    ;; Запятая разграничивает индивидуальные номера, двоеточие
    ;; указывает на диапазон чисел включительно.
    ;; Пример для почтового ящика с 15 сообщениями: 2,4:7,9,12:*
    ;; эквивалентно 2,4,5,6,7,9,12,13,14,15.

    SPACE ::=
    status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"
    status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
    "UNSEEN"
    store ::= "STORE" SPACE set SPACE store_att_flags
    store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
    (flag_list / #flag)
    string ::= quoted / literal
    subscribe ::= "SUBSCRIBE" SPACE mailbox
    tag ::= 1*
    text ::= 1*TEXT_CHAR
    text_mime2 ::= "=?" "?" "?"
    "?="
    ;; Синтаксис определен в [MIME-HDRS]
    TEXT_CHAR ::=
    time ::= 2digit ":" 2digit ":" 2digit
    ;; Часы, минуты, секунды
    uid ::= "UID" SPACE (copy / fetch / search / store)

    ;; Уникальные идентификаторы используются вместо
    ;; последовательных номеров сообщения.

    uniqueid ::= nz_number

    ;; В возрастающем порядке
    unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox
    userid ::= astring
    x_command ::= "X" atom
    zone ::= ("+" / "-") 4digit

    ;; Число из 4 цифр со знаком hhmm, представляющее часы и минуты к западу от Гринвича
    ;; (Это число отличается от Universal Time). Вычитая временную зону из данного времени, можно получить
    ;; форму UT. Зона Universal Time равна "+0000".

    1. Соображения безопасности

    Протокольные операции IMAP 4.1, включая данные электронной почты, передаются через сеть открытым текстом, если только не согласовано применение конфиденциальных методов обмена посредством команды AUTHENTICATE.

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

    Использование команды LOGIN осуществляет передачу паролей открытым текстом. Этого можно избежать, используя для этого команду AUTHENTICATE.

    A. Библиография

    [ACAP]

    Myers, J. "ACAP -- Application Configuration Access Protocol", Work in Progress.

    [CHARSET]

    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

    [DISPOSITION]

    Troost, R., and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.

    [IMAP-AUTH]

    Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. Carnegie-Mellon University, December 1994.

    [IMAP-COMPAT]

    Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, University of Washington, November 1996.

    [IMAP-DISC]

    Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.

    [IMAP-HISTORICAL]

    Crispin, M. "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, University of Washington, December 1994.

    [IMAP-MODEL]

    Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, University of Washington, December 1994.

    [IMAP-OBSOLETE]

    Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, University of Washington, November 1996

    [IMAP2]

    Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, University of Washington, August 1990.

    [LANGUAGE-TAGS]

    Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.

    [MD5]

    Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.

    [MIME-IMB]

    Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

    [MIME-IMT]

    Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996.

    [MIME-HDRS]

    Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

    [RFC-822]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.

    [SMTP]

    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

    [UTF-7]

    Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 1642, July 1994.

    Previous: 4.4.14.2 Почтовый протокол POP3    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14.4 Многоцелевое расширение почты Интернет (MIME)


    previous up down next index index
    Previous: 4.4.14.5 Программа Sendmail    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.16 Протокол SNTP

    4.4.15 Сетевой протокол времени NTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Время - самый важный и невосполнимый ресурс любого человека. Проблема эта занимала людей всегда, и уже более 4 тысяч лет люди пытаются как-то упорядочить учет расходования этого ресурса, создавая различные календарные системы и устройства измерения времени. Календарные системы древнего мира отражали сельскохозяйственные, политические и ритуальные нужды, характерные для того времени. Астрономические наблюдения для установления зимнего и летнего солнцестояния производились еще 4000 лет тому назад. Проблема создания календаря возникала только в обществах, где государственная стабильность поддерживалась в течение достаточно долгого времени (Китай, Египет, государство Майя). В 14-ом столетии до Рождества Христова в Китае была определена длительность солнечного года - 365.25 дней, а лунный месяц - 29.5 дней. Солнечно-лунный календарь действовал на ближнем востоке (за исключением Египта) и в Греции, начиная с 3-го тысячелетия до нашей эры. Ранние календари использовали либо 13 лунных месяцев по 28 дней или 12 месяцев с чередующейся протяженностью 29 и 30 дней.

    Древнеегипетский календарь имел 12 30-дневных лунных месяцев, но был привязан к сезонному появлению звезды Сириус (sirius - sothis). Для того чтобы примирить этот календарь с солнечным годом, был изобретен гражданский календарь, в котором добавлено 5 дней, доводящих длительность года до 365 дней. Однако со временем было замечено, что гражданский год примерно на одну четверть дня короче, чем солнечный год. Выбранная длительность года обеспечивала полное совпадение с солнечным годом раз за 1460 лет. Этот период называется циклом Сотиса (sothic-цикл). Так же как и shang chinese, древние египтяне установили длительность солнечного года равной 365,25 дней, что с точностью 11 минут совпадает с результатами современных вычислений. В 432 году до рождества Христа, около столетия после китайцев греческий астроном Метон вычислил, что 110 лунных месяцев по 29 дней и 125 лунных месяцев по 30 дней соответствуют 6940 солнечным дням, что лишь немного превышает 19 лет. 19-летний цикл, названный циклом Метона, установил длительность лунного месяца равной 29,532 солнечных дней, что с точностью 2 минут совпадает результатами современных измерений.

    В древнем Риме использовался лунный календарь. Юлий Цезарь пригласилалександрийского астронома Сосигенса, который разработал календарь (который по понятным причинам стал называться юлианским), принятый в 46 году до Рождества Христова. Календарь содержал 365 дней в году с добавлением одного дня каждые 4 года. Однако первые 36 лет по ошибке дополнительный день добавлялся каждые три года. В результате набежало лишних три дня, которые пришлось компенсировать вплоть до 8 года нашей эры.

    Семидневная неделя была введена лишь в четвертом столетии нашей эры императором Константином I.

    Во время романской эры 15-летний цикл переписи использовался при исчислении налогов. Последовательность имен дней недели воспроизводится через 28 лет, этот период называется солнечным циклом. Таким образом, учитывая 28-летний солнечный цикл, 19-летний цикл Метона и 15-летний переписи, получаем суперцикл протяженностью 7980-лет, называемый юлианской эрой, которая начинается в 4713 году до рождества христова.

    К 1545 году расхождение между юлианским календарем и солнечным годом достигло 10 дней. В 1582, астрономы Кристофер Клавиус и Луиджи Лилио предложили новую схему календаря. Папа Грегорий XIII выпусти указ, где среди прочего указывалось, что в году содержится 365.2422 дней. Для того чтобы более точно аппроксимировать эту новую величину, только столетние годы, которые делятся без остатка на 400, объявляются високосными, что предполагает длительность года 365,2425 дней. В настоящее время григорианский календарь принят большинством стран мира.

    Для того чтобы мерить расширение вселенной или распад протона необходимо стандартную схему нумерации дней. По решению Международного астрономического Союза был принят стандарт на секунду и юлианская система нумерации дней (jdn). Стандартный день содержит 86,400 стандартных секунд, а стандартный год состоит из 365,25 стандартных дней.

    В схеме (JDN), предложенной в 1583 французским ученым Джозефом Юлиусом Скалигером, JDN 0.0 соответствует 12 часам (полдень) первого дня юлианской эры - 1 января 4713 до нашей эры. Годы до нашей эры подсчитываются согласно юлианскому календарю, в то время как годы нашей эры нумеруются по григорианскому календарю. 1 января 1 года после рождества христова в григорианском календаре соответствует 3 января 1 года юлианского календаря [DER90], в JDN 1.721.426,0 день соответствует 12 часам первого дня нашей эры.

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

    Сетевой протокол задания времени NTP (network time protocol; Network Time Protocol Version 3 Specification, Implementation and Analysis, David L. Mills, RFC-1305, March 1992) служит для осуществления синхронизации работы различных процессов в серверах и программах клиента. Он определяет архитектуру, алгоритмы, объекты и протоколы, используемые для указанных целей. NTP был впервые определен в документе RFC-958 [MIL85c], но с тех пор несколько раз переделан и усовершенствован (RFC-1119 [MIL89]). Протокол использует для транспортных целей UDP [POS80]. Целью протокола является обеспечение максимально возможной точности и надежности, несмотря на значительный разброс задержек при прохождении через большое число промежуточных маршрутизаторов.

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

    Точность, достижимая с помощью NTP, сильно зависит от точности локальных часов и характерных скрытых задержек. Алгоритм коррекции временной шкалы включает внесение задержек, коррекцию частоты часов и ряд механизмов, позволяющих достичь точности порядка нескольких миллисекунд, даже после длительных периодов, когда потеряна связь с синхронизирующими источниками.

    Существует ряд механизмов в Интернет, которые позволяют передавать и записывать время, когда произошло какое-то событие. Это протокол daytime [POS83a], time protocol [POS83b], сообщения ICMP "временная метка" [DAR81b] и опция IP "временная метка" [SU81].

    Маршрутный протокол fuzzball [MIL83b], иногда называемый hellospeak, встраивает синхронизацию непосредственно в алгоритм маршрутного протокола. Он не является протоколом из стека IP.

    Юниксовский (4.3BSD) времязадающий демон [GUS85a] измеряет временные сдвиги различных клиентских процессов и рассылает им соответствующие поправки.

    В этой модели сервер определен с помощью алгоритма выбора [GUS85b], который исключает ситуации, где сервер не выбран или выбрано более одного сервера. Процесс выбора требует возможности рассылки широковещательных сообщений.

    Архитектура системы

    В модели NTP некоторое число первичных эталонов времени, синхронизованных по кабелю или с помощью национальных радио служб времени, подключено к широкодоступным ресурсам, таким как порты опорной сети. Эти устройства функционируют как первичные серверы времени. Целью NTP является передача информации о точном времени от этих серверов к другим серверам через Интернет и коррекция ошибок, связанных с флуктуациями задержек в сети. Некоторое число локальных ЭВМ или внешних шлюзов могут выполнять функции вторичных серверов времени, общающихся с первичными эталонами на основе протокола NTP. Вторичные серверы позволяют минимизировать избыточность протокола, рассылая нужную временную информацию локально. В целях обеспечения надежности выбранные вторичные источники могут быть снабжены менее точными, зато более дешевыми радио-часами, используемыми в ситуациях, когда откажет первичный эталон или выйдет из строя ведущий к нему канал.

    Под стабильностью подразумевается степень постоянства задающей частоты часов, а под точностью - соответствие этой частоты национальным стандартам времени. Если не указано обратного, под временным сдвигом между часами подразумевается разница показаний этих часов. В то время как под сбоем (skew) подразумевается различие их рабочих частот (первая производная). Настоящие часы имеют конечную стабильность частоты (вторая производная не равна нулю). Нестабильность частоты называется дрейфом, но в рамках протокола NTP дрейф предполагается равным нулю.

    Протокол NTP создан с целью определения трех величин: смещения часов (clock offset), RTT и дисперсии, все они вычисляются по отношению к выбранным эталонным часам. Смещение часов определяет поправку, которую необходимо внести в показания местных часов, чтобы результат совпал показанием эталонных часов. Дисперсия характеризует максимальную ошибку локальных часов по отношению к эталонным.

    В протоколе NTP нет средств для нахождения партнера или управления. Целостность данных обеспечивается с помощью IP и UDP контрольных сумм. Система может работать в симметричном режиме, когда сервер и клиент неразличимы, и в режиме клиент-сервер, где сервер выполняет только то, что требует клиент. Используется только один формат сообщений NTP. В рамках модели необходимо определить минимально возможную частоту коррекций часов, обеспечивающую требуемую временную точность.

    Реализация модели

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

    Модель клиент-сервер может быть вполне достаточна для локальных сетей, где один сервер обслуживает некоторое количество клиентов. В общем случае NTP требует одновременной работы большого числа распределенных пар партнеров (клиент-сервер), конфигурация которых изменяется динамически. Нужны достаточно сложные алгоритмы управления такой ассоциацией, для обработки данных и контроля множества локальных часов.

    Процесс передачи, управляемый независимыми таймерами для каждого из партнеров, осуществляет накопление информации в базе данных и посылает сообщения NTP. Каждое сообщение содержит локальную временную метку момента отправки сообщения, ранее полученные временные метки, а также необходимую вспомогательную информацию. Частота посылки сообщений определяется требуемой точностью локальных часов, а также предельными точностями часов партнеров.

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

    Конфигурации сети

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

    Следуя принципам, принятым в телефонной промышленности [BEl86], точность каждого сервера определяется номером слоя (stratum), наивысший уровень (для первичного сервера) имеет номер 1. На современном уровне технологий (радио-часы) точность однократной сверки имеет порядок одной миллисекунды.

    Точность однократной сверки падает по мере роста значения RTT и его разброса. Для того чтобы избежать сложных расчетов [BRA80], необходимых для оценки точности в каждом конкретном случае, полезно предположить, что средняя ошибка измерения пропорциональна RTT и ее дисперсии. Предполагая, что первичные серверы синхронизованы стандартами времени с известной точностью, можно получить вполне надежную оценку точности синхронизации субсети.

    Дополнительным фактором является то, что каждый переход от одного слоя к другому предполагает наличие ненадежного сервера времени, который вносит дополнительные ошибки. Алгоритм выбора серверов времени использует разновидность алгоритма маршрутизации Беллмана-Форда, при этом формируется дерево минимальных весов, основанием которого являются первичные сервера. Метрикой расстояния служит номер слоя плюс расстояние синхронизации, которое характеризуется суммой дисперсии и половины абсолютного значения задержки.

    Такая конструкция способствует тому, что субсеть автоматически реконфигурируется и настраивается на максимально достижимую точность даже при выходе из строя первичных или вторичных серверов времени. Если даже все первичные серверы выйдут из строя или станут недоступными, их функции будут выполнять вторичные серверы, если расстояние до них согласно алгоритму Беллмана-Форда не превышает значения метрики, соответствующего бесконечности (разрыву связи). Если все серверы окажутся на больших расстояниях, субсеть продолжит работу при установках, выполненных при последней синхронизации (коррекции внутренних часов). Даже в этом случае достижима точность порядка миллисекунд в сутки.

    Если два сервера находятся согласно алгоритму на равных расстояниях, допускается случайный выбор.

    Форматы данных

    Все арифметические операции в рамках протокола выполняются в формате с фиксированной запятой. По этой причине все переменные в NTP имеют именно этот формат. Биты пронумерованы слева на право (со старшего бита), начиная с нуля. Жестких требований на число разрядов после запятой не установлено. Если не оговорено обратного, все числа не имеют знака и занимают все отведенное для них поле (при необходимости в качестве заполнителей старших разрядов используются нули).

    Временные метки NTP представляют собой 64-битные числа с фиксированной запятой без знака, которое указывает число секунд с нуля часов 1-го января 1900 года. Целая часть содержит первые 32 разряда, а дробная часть остальные 32 разряда. Этот формат не совпадает с форматом меток ICMP, где время измеряется в миллисекундах. Точность представления составляет 200 пикосекунд, что должно удовлетворить самым экзотическим требованиям.

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

    Заметим, что с 1968 года старший бит (бит 0 целой части) равен единице, а где-то в 2036 году 64-битовое поле переполнится.

    Переменные состояния и параметры

    Ниже приводится обзор различных переменных и параметров, используемых протоколом. Они распределены по классам системных переменных, которые имеют отношение к операционной среде и механизму реализации местных часов. Сюда входят переменные партнеров, которые характеризуют состояние протокольных машин участников обмена, переменные пакетов, описывающие содержимое пересылаемых NTP-сообщений, а также параметры, задающие конфигурацию текущей версии программного обеспечения. Имена переменных записываются строчными буквами, а имена параметров - прописными.

    Общие переменные

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

    Адрес партнера (peer.peeraddr, pkt.peeraddr), порт партнера (peer.peerport, pkt.peerport). 32-битный ip-адрес и 16-битный номер порта партнера.

    Адрес ЭВМ (peer.hostaddr, pkt.hostaddr), порт ЭВМ (peer.hostport, pkt.hostport). 32-битный IP-адрес и 16-битный номер порта ЭВМ. Эти переменные включаются в переменные состояния для поддержки мультиинтерфейсных систем.

    Индикатор приращения (sys.leap, peer.leap, pkt.leap) - это двухбитный код предупреждения о включении дополнительных секунд во временную шкалу NTP. Эти биты устанавливаются до 23:59 дня добавления и сбрасываются после 00:00 следующего дня. В результате день, для которого проведена эта процедура, окажется длиннее или короче на одну секунду. Для вторичных серверов эти биты устанавливаются протоколом NTP. Биты 0 и 1 (LI) принимают значения, перечисленные в таблице 4.4.15.1:

    Таблица 4.4.15.1 Значения кодов индикатора LI

    LI

    Величина

    Значение

    00

    0

    предупреждения нет

    01

    1

    последняя минута содержит 61 секунду

    10

    2

    последняя минута содержит 59 секунд

    11

    3

    аварийный сигнал (часы не синхронизованы)

    Во всех случаях за исключением аварийного сигнала (alarm = 112), протокол NTP никак не изменяет эти биты, а только передает их программам преобразования времени, которые не являются частью протокола. Аварийная ситуация возникает, когда по какой-либо причине локальные часы оказываются не синхронизованными. Это может случиться в ходе инициализации системы или в случае, когда первичные часы оказываются недоступны в течение длительного времени.

    Режим (peer.mode, pkt.mode) - это целое 3-битовое число, обозначающее код режима ассоциации, который может принимать значения, приведенные в таблице 4.4.15.2:

    Таблица 4.4.15.2. Значения кодов Режим

    Режим

    Значение

    0

    зарезервировано

    1

    симметричный активный

    2

    симметричный пассивный

    3

    клиент

    4

    сервер

    5

    широковещательный

    6

    для управляющих сообщений NTP

    7

    зарезервировано для частного использования

    Слой (sys.stratum, peer.stratum, pkt.stratum) - это целое число, указывающее код слоя локальных часов, который может принимать значения приведенные в таблице 4.4.15.3.

    Таблица 4.4.15.3. Значения кодов слой

    Слой

    Значение

    0

    Не специфицирован или недоступен

    1

    Первичный эталон (например, радио часы)

    2-15

    Вторичный эталон (через NTP или sntp)

    16-255

    Зарезервировано на будущее

    Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная, ограничено параметром ntp.maxstratum.

    Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll). Это целая переменная со знаком, указывающая минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды.

    Точность (sys.precision, peer.precision, pkt.precision). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлено в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс).

    Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay). Это число с фиксированной запятой со знаком, указывающее на величину полной циклической задержки (RTT) до первичного эталона частоты, выраженной в секундах.

    Базовая дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах.

    Идентификатор эталонных часов (sys.refid, peer.refid, pkt.refid). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), 4-октетная ASCII-строка, выровненная по левому краю и дополненная при необходимости нулями, например:

    Таблица 4.4.15.4. Коды идентификаторов часов

    Слой

    Код

    Значение

    0

    dcn

    Протокол маршрутизации dcn

    0

    dts

    Цифровая служба времени (digital time service)

    0

    nist

    Общий модем nist

    0

    tsp

    Временной протокол tsp

    1

    atom

    Атомные часы (калиброванные)

    1

    vlf

    vlf-радио (omega, и пр.)

    1

    callsign

    Общее радио

    1

    gps

    gps УВЧ позиционирование спутников

    1

    lorc

    loran-c радионавигация

    1

    wwvb

    Радио wwvb НЧ (диапазон 5)

    1

    goes

    Спутник goes УВЧ (диапазон 9)

    1

    wwv

    Радио wwv ВЧ (диапазон 7)

    В случае слоя 2 и выше (вторичный эталон) - это 4-октетный IP-адрес партнера, выбранного для синхронизации.

    Эталонная временная метка (sys.reftime, peer.reftime, pkt.reftime) - локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль.

    Базовая временная метка (peer.org, pkt.org) - локальное время в формате временных меток, соответствующее моменту посылки последнего NTP-сообщения. Если партнер недостижим, переменная принимает нулевое значение.

    Временная метка получения (peer.rec, pkt.rec) - локальное время в формате временных меток, соответствующее моменту прихода последнего NTP-сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение.

    Временная метка передачи (peer.xmt, pkt.xmt) - локальное время в формате временных меток, соответствующее моменту отправки NTP-сообщения.

    Системные переменные

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

    Переменная локальные часы (sys.clock) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями.

    Переменная Базовые часы (sys.peer) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.

    Переменные партнера

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

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

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

    Регистр достижимости (peer.reach) - сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.

    Таймер партнера (peer.timer) - целочисленный счетчик, используемый для управления интервалом между последовательно посылаемыми NTP-сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек) пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов.

    Пакетные переменные

    Номер версии (pkt.version) - целое число индицирующее номер версии отправителя. NTP сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии (ntp.version). Исключения допускаются лишь при смене номера версии.

    Переменные фильтра часов

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

    Регистр фильтра (peer.filter) - сдвиговый регистр каскадов ntp.shift, где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются.

    Счетчик корректных данных (peer.valid) - целочисленный счетчик, указывающий на корректные образцы, остающиеся в регистре фильтра. Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений.

    Смещение (peer.offset) - число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.

    Задержка (peer.delay) - число с фиксированной запятой со знаком, индицирующее полную циклическую задержку (RTT) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения.

    Дисперсия (peer.dispersion) - число с фиксированной запятой, индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля.

    Переменные аутентификации

    При использовании механизма аутентификации привлекаются следующие переменные состояния.

    Бит разрешения аутентификации (peer.authenable) - бит, указывающий, что ассоциация должна работать в режиме аутентификации.

    Бит аутентификации (peer.authentic) - бит, индицирующий то, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.

    Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid) - целое число, идентифицирующее криптографический ключ, использованный при генерации аутентификационного кода сообщения.

    Криптографические ключи (sys.key) - набор 64-битных ключей DES. Каждый ключ создается в соответствии с берклиевскими UNIX-распределениями, которые состоят из 8 октетов, где 7 младших бит каждого октета соответствуют битам des 1-7, а старший бит соответствует биту четности DES.

    Контрольная крипто-сумма (pkt.check) - криптографическая контрольная сумма, вычисляемая процедурой шифрации.

    Параметры

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

    Номер версии (ntp.version) - текущий номер версии NTP (3).

    Порт NTP (ntp.port) - стандартный номер порта (123), присвоенный протоколу NTP.

    Максимальный номер слоя (ntp.maxstratum) - максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).

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

    Максимальный сбой (ntp.maxskew) - максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.

    Максимальное расстояние (ntp.maxdistance) - максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.

    Минимальный период рассылки (ntp.minpoll) - минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.

    Максимальный период рассылки (ntp.maxpoll) -максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.

    Минимум избранных часов (ntp.minclock) - минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).

    Максимум избранных часов (ntp.maxclock) - максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).

    Минимальная дисперсия (ntp.mindisperse) - минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).

    Максимальная дисперсия (ntp.maxdisperse) - максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).

    Размер регистра доступности (ntp.window) - размер регистра доступности (peer.reach) в битах.

    Размер фильтра (ntp.shift) - размер сдвигового регистра фильтра часов (peer.filter) в каскадах.

    Вес фильтра (ntp.filter) - вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации).

    Выбранный вес (ntp.select) - вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции).

    Режимы работы

    За исключением широковещательного режима, NTP-ассоциация формируется, когда два партнера обмениваются сообщениями и один или оба из них создает и поддерживает протокольную машину, называемую ассоциацией. Ассоциация может работать в одном из 5 режимов, заданных переменной peer.mode: симметрично активный, симметрично пассивный, клиент, сервер и широковещательный:

    Симметрично активный (1). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

    Симметрично пассивный (2). Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

    Клиент (3). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ, обычно это сетевая рабочая станция, оповещает о своем намерении быть синхронизованной партнером.

    Сервер (4). Этот тип ассоциации первоначально создается по прибытии запроса клиента и существует только для отклика на этот запрос. После отклика ассоциация ликвидируется. При работе в этом режиме ЭВМ, обычно рабочая сетевая станция, оповещает о намерении синхронизовать партнера.

    Широковещательный (5). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от доступности или слоя партнеров. При работе в этом режиме ЭВМ, обычно сетевой сервер времени, который работает в широковещательной среде, оповещает о намерении синхронизовать всех партнеров.

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

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

    Симметрично активный режим предназначен для использования серверами времени, работающими вблизи оконечных узлов (наивысший слой) синхронизации. Надежный временной сервис обычно может быть реализован с помощью двух партнеров на ближайшем нижележащем слое и одном партнере в том же слое. По этой причине поток сообщений обычно невелик, даже когда связь потеряна, и на каждый запрос приходит отклик об ошибке.

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

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

    Обработка событий

    Существенные события с точки зрения протокола NTP происходят при истечении времени таймеров партнера (peer.timer), один из которых ориентирован специально на данного партнера в активной ассоциации, а также при получении NTP-сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой как отказ первичного эталона.

    Обозначения

    Алгоритмы фильтрации и селекции NTP используют несколько переменных для хранения значений сдвига часов, RTT и дисперсии. Переменные, относящиеся к партнерам, обычно обозначаются строчными греческими буквами, а для первичного эталона времени используются прописные буквы. Эти алгоритмы базируются на параметре, называемом расстояние синхронизации (l) и вычисляемом с использованием rtt и дисперсии.

    Дисперсия партнера (e) содержит вклады от ошибок измерения (r) и накопления ошибок дрейфа (skew-error).

    Каждый раз, когда соответствующие переменные партнеров изменяются, значения дисперсии корректируются. Ниже приводятся основные определения переменных и формулы их вычисления:

    q = peer.offset,
    d = peer.delay,
    e = peer.dispersion = r + jt + es ,
    l = e + |d|/2,

    где d = rtt, q - сдвиг часов, jt - накопление сбоя, j = ntp.maxskew/ntp.maxage, t - момент времени передачи исходной временной метки (на основе t вычисляется q и d), e s - дисперсия фильтра. Переменные, относящиеся к партнеру i, определяются следующим образом:

    q i = j i,
    d i = peer.rootdelay + d i,
    e i = peer.rootdispersion + e i + j t i (максимальная дисперсия часов партнера),
    l i= e i + |d i|/2,

    Окончательно, предполагая, что для синхронизации выбран i-ый партнер, система переменных определяется следующим образом:

    q = комбинированное окончательное смещение (combined final offset),
    d = d i,
    e = e i + ex + q,
    l = l i,

    где ex дисперсия выбора (select dispersion).

    Приводимые ниже тексты программ, реализующие вычисления переменных, записаны на условном языке, напоминающем СИ.

    Процедура передачи

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

    Нижеприведенный фрагмент программы инициализирует пакетный буфер и копирует пакетные переменные.

    pkt.peeraddr <- peer.hostaddr;

    /* копирование системных и партнерских переменных */

    pkt.peerport <- peer.hostport;
    pkt.hostaddr <- peer.peeraddr;
    pkt.hostport <- peer.peerport;
    pkt.leap <- sys.leap;
    pkt.version <- ntp.version;
    pkt.mode <- peer.mode;
    pkt.stratum <- sys.stratum;
    pkt.poll <- peer.hostpoll;
    pkt.precision <- sys.precision;
    pkt.rootdelay <- sys.rootdelay;
    if (sys.leap = 112 or (sys.clock - sys.reftime) > ntp.maxage)
    skew <- ntp.maxskew;
    else
    skew <- j (sys.clock - sys.reftime);
    {pkt.rootdispersion <- sys.rootdispersion + (1 << sys.precision)} + skew;
    pkt.refid <- sys.refid;
    pkt.reftime <- sys.reftime;

    Временная метка передачи pkt.xmt будет использована позднее, для того чтобы проконтролировать отклик. Таким образом, программа должна сохранить точное переданное значение. Кроме того, порядок копирования временных меток должен быть выбран так, чтобы не понизить точность.

    pkt.org <- peer.org;

    /* копирование временных меток */

    pkt.rec <- peer.rec;
    pkt.xmt <- sys.clock;
    peer.xmt <- pkt.xmt;

    Регистр доступности сдвигается на одну позицию влево, в освободившийся разряд записывается нуль. Если все биты регистра равны нулю, вызывается процедура очистки (clear procedure) для обнуления фильтра часов и выбора, если необходимо, нового источника синхронизации. Если ассоциация не была сконфигурирована при инициализации, то она ликвидируется.

    peer.reach <- peer.reach <<1;

    /* актуализация доступности */

    if (peer.reach = 0 and peer.config =0)
    begin
    ликвидируем ассоциацию;
    exit;
    endif

    Если корректные данные введены в сдвиговый регистр фильтра хотя бы раз за время предыдущих двух периодов рассылки (младший бит peer.reach равен 1), счетчик корректных данных увеличивается на 1. После восьми таких удачных периодов интервал рассылки увеличивается. Процедура выбора часов вызывается, если необходимо заменить источник синхронизации.

    if (peer.reach & 6 ≠ 0)

    /* Проверка младших двух бит */

    if (peer.valid << ntp.shift)

    /* получены корректные данные */

    peer.valid <- peer.valid + 1;
    else peer.hostpoll <- peer.hostpoll + 1;
    else begin

    peer.valid <- peer.valid - 1;

    /* ничего не слышно */

    peer.hostpoll <- peer.hostpoll - 1;
    call clock-filter(0, 0, ntp.maxdisperse);

    call clock-select;

    /* выбираем источник синхронизации */

    endif
    call poll-update;
    end transmit procedure;

    Процедура получения

    Процедура получения выполняется по приходу NTP-сообщения. Она проверяет сообщения, интерпретирует различные режимы и вызывает другие процедуры для фильтрации данных и выбора источника синхронизации. Если номер версии в пакете не соответствует текущей версии, сообщение может быть отброшено. Если получено управляющее сообщение NTP и код режима пакета равен 6 (управление), вызывается процедура управляющего сообщения. IP-адреса отправителя и адресата, а также номера портов устанавливаются соответствующими заданному партнеру. Если соответствия нет, производится новая инсталляция протокольной машины и формируется новая ассоциация.

    begin receive procedure
    if (pkt.version ≠ ntp.version>) exit;
    #ifdef (control messages implemented)
    if (pkt.mode = 6) call control-message;
    #endef

    for (all associations)

    /* Здесь выполняется управление доступом */

    match addresses and ports to associations;
    if (no matching association)

    call receive-instantiation procedure;

    /* создаем ассоциацию */

    Вызов процедуры дешифровки осуществляется только в случае применения аутентификации.

    #ifdef (authentication implemented)
    call decrypt;
    #endef

    Если код режима пакета не равен нулю, он определяет режим на следующем этапе; в противном случае, режим определяется по номеру порта.

    if (pkt.mode = 0)

    /* для совместимости со старыми версиями */

    mode;
    else
    mode <- pkt.mode;
    case (mode, peer.hostmode)

    В случае ошибки пакет просто игнорируется, а ассоциация, если она не была предварительно сконфигурирована, ликвидируется.

    error: if (peer.config = 0) demobilize association;
    break;

    В случае recv пакет обрабатывается, а ассоциация помечается как достижимая при условии 5-8 успешных проверок. Если и проверки с первой по 4-ую проходят успешно (данные корректны), вызывается процедура коррекции показания локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она ликвидируется.

    recv: call packet;

    /* обработать пакет */

    if (valid header) begin

    /* если правильный заголовок, актуализовать внутренние часы */

    peer.reach <- peer.reach | 1;
    if (valid data) call clock-update;
    endif
    else
    if (peer.config = 0) ликвидировать ассоциацию;
    break;

    В случае xmit, пакет обрабатывается и посылается промежуточный отклик. Ассоциация затем ликвидируется.

    xmit: call packet;

    /* обработать пакет */

    peer.hostpoll <- peer.peerpoll;

    /* послать немедленно отклик */

    call poll-update;
    call transmit;
    if (peer.config = 0) ликвидировать ассоциацию;
    break;

    В случае pkt, пакет обрабатывается, а ассоциация помечается как достижимая при условии, что тесты 5-8 (правильный заголовок), перечисленные в пакетной процедуре, прошли успешно. Если, кроме того, прошли тесты 1-4 (корректные данные), вызывается процедура коррекции показаний локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она сразу после отклика ликвидируется.

    pkt: call packet;

    /* обработка пакета */

    if (valid header) begin

    /* если заголовок правилен, поправляется показание местных часов */

    peer.reach <- peer.reach | 1;
    if (valid data) call clock-update;
    endif
    else if (peer.config = 0) begin

    peer.hostpoll <- peer.peerpoll;

    /* послать немедленно отклик */

    call poll-update;
    call transmit;
    ликвидировать ассоциацию;
    endif
    endcase
    end receive procedure;

    Пакетная процедура

    Пакетная процедура проверяет корректность сообщения, вычисляет задержку/смещение и вызывает другие процедуры для отбора данных и выбора источника синхронизации. Тест 1 требует, чтобы переданная временная метка отличалась от последней, полученной от того же партнера. Тест 2 требует, чтобы исходная временная метка соответствовала последней метке, посланной тому же партнеру. В случае широковещательного режима (5) rtt=0 и полная точность операции передачи времени будет недостижимой. Однако, полученная точность может быть вполне приемлемой для многих целей. Процедура вызова коррекции времени использует в качестве параметра peer.hostpoll (peer.peerpoll может быть изменено).

    begin packet procedure

    peer.rec <- sys.clock;

    /* забрать полученную временную метку */

    if (pkt.mode ≠ 5) begin

    test1 <- (pkt.xmt ≠ peer.org);

    /* Тест 1 */

    test2 <- (pkt.org = peer.xmt);

    /* Тест 2 */

    endif
    else begin

    pkt.org <- peer.rec;

    /* потеря временной метки из-за ошибки */

    pkt.rec <- pkt.xmt;

    test1;

    /* ложные тесты */

    test2;
    endif

    peer.org <- pkt.xmt;

    /* актуализация исходной временной метки */

    peer.peerpoll <- pkt.poll;

    /* скорректировать период рассылки */

    call poll-update(peer.hostpoll);

    Тест 3 требует, чтобы исходная и полученная временные метки не были равны нулю. Если любая из них равна нулю, ассоциация не синхронизирована или потеряла доступ в одном или обоих направлениях.

    test3 <- (pkt.org ≠ 0 and pkt.rec ≠ 0); /* Тест 3 */

    rtt и временное смещение по отношению партнера вычисляется следующим образом. Пусть i четное целое число.
    Тогда ti-3, ti-2, ti-1 и ti - содержимое переменных pkt.org, pkt.rec, pkt.xmt и peer.rec, соответственно. Смещение часов j, rtt=d и дисперсия e ЭВМ по отношению к партнеру равны:

    d = (ti - ti-3) - (ti-1 - ti - 2),
    j = ((ti - 2 - ti-3) + ( ti-1 - ti))/2,
    e = (1 << sys.precision) + j (ti - ti-3),

    где, как и прежде, j = ntp.maxskew/ntp.maxage. << - обозначает сдвиг кода влево. Значение e представляет собой максимальную ошибку или дисперсию, связанную с ошибкой измерения на стороне ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за время после посылки последнего сообщения, посланного партнером. Дисперсия корректируется процедурой фильтра часов (clock-filter).

    Рассмотренный метод эквивалентен непрерывному стробированию, которое используется в некоторых телефонных сетях [bel86]. Преимуществом метода является полная независимость от порядка и времени прихода сообщений, а также допустимость потери некоторых пакетов. Очевидно, что достижимые точности зависят от статистических свойств каналов связи.

    Тест 4 требует, чтобы вычисленная задержка лежала в допустимых пределах:

    test4 <- (|d| < ntp.maxdisperse И e

    Тест 5 используется, только если реализован механизм аутентификации. Он требует, чтобы либо аутентификация была явно блокирована, либо чтобы аутентификатор в точности соответствовал тому, что описано в процедуре дешифровки.

    #ifdef (authentication implemented) /* Тест 5 */
    test5 <- ((peer.config = 1 и peer.authenable = 0) или peer.authentic = 1);
    #endef

    Тест 6 требует, чтобы часы партнера были синхронизованы, и время с момента последней коррекции было положительным и меньше чем ntp.maxage.

    Тест 7 гарантирует, что ЭВМ не будет синхронизовано от партнера с большим кодом номера слоя.

    Тест 8 требует, чтобы заголовок содержал соответствующие коды в полях pkt.rootdelay и pkt.rootdispersion.

    test6 <- (pkt.leap ≠ 112 and

    /* Тест 6 */

    {pkt.reftime ≤ pkt.xmt << pkt.reftime + ntp.maxage})

    test7 <- {pkt.stratum ≤ sys.stratum} and

    /* Тест 7 */

    {pkt.stratum << ntp.maxstratum};

    test8 <- (| pkt.rootdelay | << ntp.maxdisperse and

    /* Тест 8 */

    {pkt.rootdispersion << ntp.maxdisperse});

    С точки зрения последующей обработки пакеты содержат корректные данные, если успешно проходят тесты 1-4 (test1 & test2 & test3 & test4 = 1), вне зависимости от результатов других тестов. Только пакеты с корректными данными могут использоваться для вычисления смещения (offset), задержки (delay) и дисперсии. Пакеты имеют корректные заголовки, если успешно проходят тесты 5-8 (test5 & test6 & test7 & test8 = 1), вне зависимости от результатов остальных тестов. Только пакеты с корректными заголовками могут использоваться для определения того, может ли партнер быть выбран в качестве источника синхронизации. Заметим, что тесты 1-2 не используются в широковещательном режиме.

    Процедура "часовой фильтр" вызывается для вычисления задержки (peer.delay), смещения (peer.offset) и дисперсии (peer.dispersion) для партнера. Спецификация алгоритма часового фильтра не является составной частью протокола NTP. По этой причине описания, приводимые ниже, следует рассматривать как рекомендательные.

    if (not valid header) exit;

    peer.leap < pkt.leap;

    /* Копирование переменных пакета */

    peer.stratum <- pkt.stratum>;
    peer.precision <- pkt.precision>;
    peer.rootdelay <- pkt.rootdelay>;
    peer.rootdispersion <- pkt.rootdispersion>;
    peer.refid <- pkt.refid>;
    peer.reftime <- pkt.reftime>;

    if (valid data) call clock-filter(q, d, e);

    /* обработка данных */

    end packet procedure;

    Процедура коррекции показаний часов

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

    begin clock-update procedure

    call clock-select;

    /* Выбор базовых часов */

    if (sys.peer ≠ peer) exit;

    Может так случиться, что локальные часы оказались сброшены. В этом случае вызывается процедура очистки (clear procedure) для каждого из партнеров, чтобы возвратить в исходное состояние фильтр часов, период рассылки и, если необходимо, осуществить выбор нового источника синхронизации.

    Процедура расстояния вычисляет базовую (root) задержку d, базовую дисперсию e и базовое расстояние синхронизации l. ЭВМ не будет синхронизовать выбранного партнера, если расстояние больше чем ntp.maxdistance.

    l andistance(peer);

    /* обновление системных переменных */

    if (l ≥ ntp.maxdistance) exit;
    sys.leap <- peer.leap;
    sys.stratum <- peer.stratum + 1;
    sys.refid <- peer.peeraddr;
    call local-clock;

    if (local clock reset) begin

    /* если сброс, очистить системные переменные */

    sys.leap <- 112;
    for (all peers) call clear;
    endif
    else begin

    sys.peer <- peer;

    /* если нет, то подстроить локальные часы */

    sys.rootdelay <- d;
    sys.rootdispersion <- e + max (ex + |t|, ntp.mindisperse);
    endif
    sys.reftime <- sys.clock;
    end clock-update procedure;

    В некоторых конфигурациях системы прецизионный источник временной информации доступен в виде последовательности синхронизующих импульсов, следующих с периодом в одну секунду. Обычно это является дополнением к базовому источнику времязадающей информации, такому как радио-часы или даже сам протокол NTP, для того чтобы обеспечить подсчет секунд, минут, часов и дней. В этих конфигурациях системные переменные устанавливаются с учетом источника, от которого поступают такие импульсы. Для конфигураций, которые поддерживают первичные эталонные источники, такие как радио-часы или калиброванные атомные часы код слоя устанавливается равным 1, поскольку именно он является действительным источником синхронизации.

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

    Работа первичных часов (primary-clock procedure)

    Когда ЭВМ связана с первичным эталоном времени, таким как радио-часы, удобно ввести информацию об этих часах в базу данных, как если бы это был обычный партнер. В процедуре первичных часов часы запрашиваются раз в минуту или около того, полученный же временной код используется для корректировки показаний местных часов. Когда обнуляется peer.timer для первичного партнера, процедура передачи не вызывается, а посылается запрос радио-часам с использованием ASCII-последовательности, предусмотренной для этого случая. Когда получен корректный временной код от радио-часов, он преобразуется в формат временной метки NTP и корректируются соответствующие переменные партнера. Величина peer.leap устанавливается в зависимости от состояния бита оповещения временного кода, если таковой имеется, или вручную оператором. Значение для peer.peeraddr, которое становится равно sys.refid, когда вызывается процедура корректировки показаний часов, делается равным ASCII-строке, описывающей часы.

    begin primary-clock-update procedure

    peer.leap <- "from" radio or operator;

    /* Копирование переменных */

    peer.peeraddr <- ascii identifier;
    peer.rec <- radio timestamp;
    peer.reach <- 1;

    call clock-filter({sys.clock - peer.rec, 0, 1 << peer.precision});

    /* образец процесса */

    call clockupdate;

    /* коррекция локальных часов */

    end primary-clock-update procedure;

    Процедуры инициализации

    Процедура инициализации вызывается при перезагрузке системы или при повторном запуске демона NTP. Состояние локальных часов при загрузке предполагается неопределенным; однако, некоторые виды оборудования обеспечивают доступ к локальным часам, как в ходе загрузки, так и сразу после нее. Переменная точности определяется внутренней архитектурой оборудования локальных часов. Аутентификационные переменные используются лишь при реализации механизма аутентификации. Значения этих переменных определяются процедурами, выходящими за рамки протокола NTP.

    begin initialization procedure
    #ifdef (authentication implemented)
    sys.keys <- as required;
    #endef;

    sys.leap <- 112;

    /* копирование переменных */

    sys.stratum <- 0 (undefined);
    sys.precision <- host~precision;
    sys.rootdelay <- 0(undefined);
    sys.rootdispersion <- 0 (undefined);
    sys.refid <- 0 (undefined);
    sys.reftime <- 0 (undefined);
    sys.clock <- external reference;
    sys.peer <- null;
    sys.poll <- ntp.minpoll;

    for (all configured peers)

    /* создание конфигурированных ассоциаций */

    call initialization-instantiation procedure;
    end initialization procedure;

    Процедура initialization-instantiation

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

    begin initialization-instantiation procedure
    peer.config <- 1;
    #ifdef (authentication implemented)
    peer.authenable <- 1 (suggested);
    peer.authentic <- 0;
    peer.hostkeyid <- as required;
    peer.peerkeyid <- 0;
    #endef;

    peer.peeraddr <- peer ip address;

    /* копирование переменных */

    peer.peerport <- ntp.port;
    peer.hostaddr <- host ip address;
    peer.hostport <- ntp.port;
    peer.mode <- host mode;
    peer.peerpoll <- 0 (undefined);
    peer.timer <- 0;
    peer.delay <- 0 (undefined);
    peer.offset <- 0 (undefined);

    call clear;

    /* инициализация ассоциации */

    end initialization-instantiation procedure;

    Процедура receive-instantiation

    Процедура receive-instantiation вызывается процедурой приема, когда обнаруживается новый партнер. Она инициализирует переменные партнера и формирует ассоциацию. Если сообщение получено от партнера, работающего в режиме клиента (3), ЭВМ переводится в режим сервера (4); в противном случае, она устанавливается в симметрично пассивный режим (2).

    begin receive-instantiation procedure
    #ifdef (authentication implemented)
    peer.authenable <- 0;
    peer.authentic <- 0;
    peer.hostkeyid <- as required;
    peer.peerkeyid <- 0;
    #endef

    peer.config <- 0;

    /* Копирование переменных */

    peer.peeraddr <- pkt.peeraddr;
    peer.peerport <- pkt.peerport;
    peer.hostaddr <- pkt.hostaddr;
    peer.hostport <- pkt.hostport;

    if (pkt.mode = 3)

    /* Определение режима */

    peer.mode <- 4;
    else
    peer.mode <- 2;
    peer.peerpoll <- 0 (undefined);
    peer.timer <- 0;
    peer.delay <- 0 (undefined);
    peer.offset <- 0 (undefined);

    call clear;

    /* инициализация ассоциации */

    end receive-instantiation procedure;

    Процедура primary clock-instantiation

    Эта процедура вызывается из процедуры инициализации для того, чтобы установить переменные состояния для первичных часов. Значение peer.precision определяется из спецификации радио-часов и аппаратного интерфейса. Значение peer.rootdispersion номинально равно удесятеренной максимальной ошибке радио-часов, например, 10 мсек для WWVB или радио-часов goes и 100 мсек для менее точных радио-часов WWV.

    begin clock-instantiation procedure

    peer.config <- 1;

    /* копирование переменных */

    peer.peeraddr <- 0 undefined;
    peer.peerport <- 0 (not used);
    peer.hostaddr <- 0 (not used);
    peer.hostport <- 0 (not used);
    peer.leap <- 112;
    peer.mode <- 0 (not used);
    peer.stratum <- 0;
    peer.peerpoll <- 0 (undefined);
    peer.precision <- clock precision;
    peer.rootdelay <- 0;
    peer.rootdispersion <- clock dispersion;
    peer.refid <- 0 (not used);
    peer.reftime <- 0 (undefined);
    peer.timer <- 0;
    peer.delay <- 0 (undefined);
    peer.offset <- 0 (undefined);

    call clear;

    /* инициализация ассоциации */

    end clock-instantiation procedure;

    В некоторых конфигурациях, включающих в себя атомные часы или приемники LORAN-C, первичный эталон может выдавать только секундные импульсы и не предоставлять полного временного кода (числа секунд и пр.). В этих конфигурациях нумерация секунд может быть получена из других источников, таких как радио-часы или даже другие NTP-партнеры. В этих конфигурациях переменные первичных часов должны отражать особенности первичного эталона, а не источника нумерации секунд. Однако если источник нумерации секунд отказал или работает некорректно, актуализация локальных часов от первичного эталона должна быть заблокирована.

    Процедура очистки

    Процедура очистки вызывается, когда произошло событие, которое значительно изменило достижимость или вызвало поломку локальных часов.

    begin clear procedure

    peer.org <- 0 (undefined);

    /* пометка неопределенных временных меток */

    peer.rec <- 0 (undefined);
    peer.xmt <- 0 (undefined);

    peer.reach <- 0;

    /* сброс переменных состояния */

    peer.filter <- [0, ,0, ntp.maxdisperse];

    /* все ступени */

    peer.valid <- 0;
    peer.dispersion <- ntp.maxdisperse;

    {peer.hostpoll <- ntp.minpoll};

    /* первичная установка периода рассылки */

    call poll-update;

    call clock-select;

    /* Выбор эталонных часов */

    end clear procedure;

    Процедура запроса-коррекции (poll-update)

    Процедура запросов-коррекции вызывается, когда происходит событие, которое может вызвать изменение периода запросов (рассылки) или таймера партнера. Она проверяет значения периода запросов ЭВМ (peer.hostpoll) и партнера (peer.peerpoll), а также устанавливает их в заданных пределах.

    begin poll-update procedure

    temp <- peer.hostpoll;

    /* определение периода запросов ЭВМ */

    if (peer = sys.peer)
    temp <- min (temp, {sys.poll, ntp.maxpoll)};
    else
    temp <- min (temp, ntp.maxpoll);
    peer.hostpoll <- max (temp, ntp.minpoll);
    temp <- 1 <

    Если интервал запросов (рассылок) не изменился, а таймер партнера на нуле, то таймер просто сбрасывается в начальное состояние. Если интервал запросов изменен, и новое значение таймера больше текущего значения, никаких дополнительных действий не требуется; в противном случае величина выдержки таймера партнера должна быть уменьшена. Когда время выдержки таймера партнера уменьшается, важно исключить тенденцию синхронизации обмена между партнерами. Благоразумной предосторожностью является рэндмизация первой передачи после уменьшения выдержки таймера.

    if (peer.timer = 0)

    /* сброс таймера партнера */

    peer.timer <- temp;
    else if (peer.timer >temp)
    peer.timer <- (sys.clock & (temp - 1)) + 1;
    end poll-update procedure;

    Процедура расстояния синхронизации (synchronization distance)

    Процедура расстояния вычисляет расстояние синхронизации на основе переменных партнеров.

    begin distance(peer) procedure;
    d <- {peer.rootdelay + |peer.delay|};
    e <- {peer.rootdispersion + peer.dispersion + f (sys.clock - peer.update)};
    l <-e + |d|/2;
    end distance procedure;

    Заметим, что, в то время как d может быть в некоторых случаях отрицательной, e и l всегда положительны.

    Замечания о контроле доступа

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

    Если требуется более надежная модель, система может базироваться на списке доступа, в который включаются 32-битовый IP-адрес, 32-битовая маска и 3-битовый код режима работы. Если логическое И адреса эталона (pkt.peeraddr) и маски на входе ЭВМ соответствуют соответствующим адресу и режиму (pkt.mode), доступ разрешается, в противном случае отправителю запроса присылается ICMP-сообщение об ошибке. Список управления доступом служит фильтром, определяющим, какой из партнеров может сформировать ассоциацию.

    Алгоритмы фильтрации и селекции

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

    Для того чтобы NTP алгоритмы фильтрации и отбора работали эффективно, полезно иметь меру вариации для каждого из партнеров. Принятая мера вариации базируется на разностях первого порядка, которые легко вычислить. Существует две меры, одна называемая дисперсией фильтра es , и другая дисперсия выбора (select dispersion) ez . Обе меры вычисляются как взвешенные суммы смещений из списка, сформированного на основе расстояний синхронизации. Если q i (0ё i < n) смещение i-ой записи, тогда разность e ij i-ой записи по отношению к j-ой записи определяется как |q i - q j|. Дисперсия относительно j-ой записи определяется как e j = , где w - весовой коэффициент, который служит для учета влияния расстояния синхронизации на дисперсию. В алгоритмах NTP w выбирается меньше 1/2: w = ntp.filter для дисперсии фильтра (filter dispersion) и w = NTP.SELECT для дисперсии выбора (select dispersion).
    Дисперсия es и ex определены относительно 0-ой записи e 0.

    Существует две процедуры, описанные ниже, процедура "часовой-фильтр" (clock-filter), которая используется для выбора лучших записей смещения для данных часов, и процедура "выбора часов" (clock-selection), которая используется, чтобы выбрать наилучшие часы среди иерархического набора часов.

    Процедура часовой фильтр (clock-filter)

    Процедура часовой фильтр исполняется по прибытии сообщения NTP или другого события, в результате которого получены новые данные. Она использует аргументы (q, d, e), где q - результат измерения смещения часов, содержащийся в записи, а d и e соответственно RTT и дисперсия. Процедура определяет значение отфильтрованного смещения часов (filtered clock offset - peer.offset), RTT (peer.delay) и дисперсии (peer.dispersion). Она также корректирует дисперсию хранящихся записей и текущее показание часов (peer.update).

    Процедура часового фильтра использует сдвиговый регистр (peer.filter), который состоит из NTP.SHIFT каскадов, каждый каскад содержит значения q i, d i и e i, которые пронумерованы, начиная с нуля, слева направо. Фильтр инициализируется процедурой очистки при этом заносятся значения [0, 0, NTP.MAXDISPERSE] во всех каскадах. Новые данные записей вдвигаются в фильтр с левого конца. Пакетная процедура выдает записи в формате (q ,d, e), когда приходят новые корректирующие данные, в то время как процедура передачи выдает записи в форме [0, 0, NTP.MAXDISPERSE], когда истекает два периода запроса без поступления свежих данных. Когда одни и те же символы (q, d, e) используютсядля аргументов, содержимого часового фильтра и переменных партнера, их значения обычно понятно из контекста. Ниже представлена псевдопрограмма, поясняющая работу данной процедуры.

    begin clock-filter procedure (q, d, e)

    Дисперсия e i для всех корректных записей в регистре фильтра должна корректироваться с тем, чтобы отражать накопление смещения со времени последней коррекции. Эти записи заносятся также во временный список, следуя стандартному формату записей [расстояние, индекс]. Записи в регистре сдвигаются вправо, новые записи вводятся слева, а самая правая запись теряется. Временный список сортируется по значению расстояния. Если в списке не остается записей, процедура прерывается без корректировки переменных партнера.

    for (i from ntp.size 1 to 1) begin

    /* коррекция дисперсии */

    [q i, d i, e i] <- [q {i-1}, d {i-1}, e {i-1}];
    /* shift stage right */
    e i = e i + ft;
    add [l ie i + {|d i|}/2, i] to temporary list;
    endfor;

    [q 0, d 0, e 0] <- [q, d, e];

    /* ввести новую запись */

    add [le + {|d|}/2, 0] to temporary list;

    peer.update <- sys.clock;

    /* сбросить показание часов */

    sort temporary list by increasing [distance ||index];

    где [distance ||index] представляет собой объединение полей расстояния и индекса (расстояние занимает старшую позицию). Дисперсия фильтра es вычисляется и включается в дисперсию партнера. Заметим, что временный список для этой цели уже упорядочен.

    es <- 0;

    for (i from ntp.shift-1 to 0)

    /* вычисление дисперсии фильтра */

    if (peer.dispersionindex[i] ≥ NTP.MAXDISPERSE or |q i - q 0 > NTP.MAXDISPERSE)
    es <- (es + NTP.MAXDISPERSE) * NTP.FILTER;
    else
    es <- (es + |q i - q 0|) * NTP.FILTER;

    Смещение партнера q 0, задержка d 0 и дисперсия e 0 выбираются как величины, соответствующие записи с минимальным расстоянием; другими словами, записи, соответствующей первому элементу временного списка (в данной нотации имеет индекс 0).

    peer.offset <- q 0;

    /* корректировка переменных партнера */

    peer.delay <- d 0;
    peer.dispersion <- min(e 0 + es , NTP.MAXDISPERSE);
    end clock-filter procedure

    Переменные peer.offset и peer.delay представляют смещение шкалы часов и RTT для локальных часов, измеренные относительно часов партнера. Обе они усредняются по большому числу измерений в течение длительного периода времени. Переменная peer.dispersion характеризует максимальную ошибку из-за неточности измерений, дрейфа и вариации записей. Все три переменные используются при выборе часов для синхронизации.

    Процедура выбора часов

    Процедура выбора часов использует переменные партнера q, d, e и t, она вызывается, когда эти переменные изменились или изменился статус доступности. Процедура включает в себя две составные части: алгоритм пересечения (intersection algorithm) и алгоритм кластеризации (clustering algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них. Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния синхронизации. Системная переменная sys.peer представляет собой указатель на наиболее вероятного кандидата, если таковой имеется, или на нулевую величину в противном случае.

    Алгоритм пересечения

    begin clock-selection procedure

    Каждый из партнеров просматривается последовательно и добавляется в конец списка, если он прошел ряд тестов. Для каждого из m кандидатов в список заносятся 3 записи в форме [указатель, тип]: [q - l, - 1], [q, 0] и [q + l, 1]. В результате в списке будет 3m записей, которые будут позднее упорядочены.

    m <- 0;

    for (each peer)

    /*обращение ко всем партнерам */

    if ({peer.reach ≠ 0 and peer.dispersion < ntp.maxdisperse} and not (peer.stratum > 1 И peer.refid = peer.hostaddr)) begin
    l

    andistance (peer);

    /* запись в список */

    add [q - l, -1] to endpoint list;
    add [q, 0] to endpoint list;
    add [q + l, 1] to endpoint list;
    m <- m + 1;
    <B>endif
    endfor

    if (m = 0) begin

    /* уход, если кандидаты отсутствуют */

    sys.peer <- null;
    sys.stratum <- 0 (undefined);
    exit;
    endif
    sort endpoint list by increasing endpoint||type;

    Ниже приведенный алгоритм представляет собой адаптированную версию DTS [DEC89] и сконструирован так, чтобы отбирать только истинных кандидатов. Алгоритм начинается с инициализации значения f и занесения нуля в счетчики i и c. Затем, начиная с конца упорядоченного, для каждой записи [указатель, тип] значение типа вычитается из кода счетчика i, который содержит число пересечений. Если код типа равен нулю, инкрементируется значение c, которое регистрирует число ложных кандидатов. Если для некоторых записей i Ё ≥ m - f, конец записи становится нижней границей пересечения; в противном случае, f увеличивается на 1 и процедура повторяется. Без сброса значений f или c, аналогичная процедура используется для нахождения верхней границы, за исключением того, что значение кода тип добавляется к счетчику. Если после того как обе границы определены c ё f, процедура продолжается для найденных m - f кандидатов, в противном случае, f увеличивается на 1 и вся процедура повторяется.

    for (f from 0 to f ≥ m/2) begin

    /* обращение ко всем кандидатам */

    c <- 0;
    i <- 0;

    for (each [endpoint, type] from lowest) begin

    /* нахождение нижней границы */

    i <- i - type;
    low <- endpoint;
    if (i ≥ m - f) break;
    if (type = 0) c <- c + 1;
    endfor;
    i <- 0;

    for (each [endpoint, type] from highest) begin

    /* нахождение верхней границы */

    i <- i + type;
    high <- endpoint;
    if (i ≥ m - f) break;
    if (type = 0 ) c <- c + 1;
    endfor;

    if (c ≤ f) break;

    /* продолжить, пока не будут найдены все ложные кандидаты */

    endfor;

    if (low > high) begin

    /* завершить, если не найдено ни одного пересечения */

    sys.peer <- null;
    exit;
    endif;

    Заметим, что работа продолжается далее данной точки, только если имеется более m/2 пересечений. Однако возможно, но не слишком вероятно, что в области пересечения окажется менее m/2 кандидатов.

    Алгоритм кластеризации

    В исходном алгоритме DTS процедура выбора часов прерывается в данной точке с выбором кандидатов из центра области пересечения. Однако это ведет к заметной потере точности и стабильности, так как не учитываются индивидуальные статистические свойства партнеров. Следовательно, в NTP только кандидаты, которые остаются в результате описанного выше отбора, могут участвовать в последующей обработке. Список кандидатов преобразуется к форме [расстояние, индекс], где расстояние вычисляется на основе кода слоя и расстояния синхронизации l партнера. Масштабный коэффициент позволяет реализовать механизм весового учета вкладов от кодов слоя и расстояния. Обычно, код слоя доминирует, если только один или более кандидатов имеют слишком большие расстояния. Список упорядочивается согласно величине расстояния.

    m <- 0;

    for (each peer) begin

    /* обращение ко всем партнерам */

    if (low ≤ q ≤ high) begin

    l <- distance (peer);

    /* сформировать запись в списке */

    dist <- {peer.stratum * NTP.MAXDISPERSE + l}
    add [dist, peer] to candidate list;
    m <- m + 1;
    endif;
    endfor;
    sort candidate list by increasing dist;

    Последующие шаги служат для того, чтобы отсеять кандидатов со слишком большими дисперсиями. Практика показывает, что число кандидатов здесь может быть достаточно велико. Это может привести к большому числу циклов повторения процедуры отбора, которые не дадут какого-либо улучшения результатов. Длина списка кандидатов ограничивается переменной ntp.maxclock.

    Заметим, что exi представляет собой дисперсию относительно i-го партнера из списка кандидатов, которая может быть вычислена методом дисперсии фильтра, описанным выше. e j - дисперсия j-ого партнера из списка, включающая в себя вклады от ошибок измерения, от накопления дрейфа и из-за дисперсии фильтра. Если максимальное значение exi больше чем минимальное значение e j, а число кандидатов больше чем ntp.minclock, i-ый партнер удаляется из списка и процедура повторяется. Если текущий источник синхронизации является одним из членов списка и нет других кандидатов из более низкого слоя, процедура прерывается, и никакие другие последующие шаги не предпринимаются. В противном случае в качестве источника синхронизации берется первый кандидат из списка. В ниже приведенном тексте i, j, k, l - индексы партнеров, k - индекс текущего источника синхронизации (нуль, если такой источник отсутствует), l - индекс первого кандидата в списке.

    while begin

    for (each survivor [distance, index]) begin

    /* вычисление дисперсии */

    find index i for max e{xi};
    find index j for min e j;
    endfor
    if (e{xi} ≤ e j or m ≤ NTP.MINCLOCK) break;

    peer.survivor [i] <- 0;

    /* отбрасывание i-го партнера */

    if (i = k) sys.peer <- null;
    delete the ith peer from the candidate list;
    m <- m - 1;
    endwhile
    if (peer.survivor [k] = 0 or peer.stratum [k] >> peer.stratum [l]) begin
    sys.peer <- l; /* новый источник часов */
    call poll-update;
    endif
    end clock-select procedure;

    Алгоритм сконструирован так, чтобы отдавать предпочтение партнерам из головной части списка, которые размещены в более низком слое, имеют наименьшее расстояние и могут обеспечить наибольшую точность и стабильность. С помощью правильного выбора весового коэффициента v (называемого ntp.select), можно удалить некоторые записи из финальной части списка.

    Локальные часы

    Для того чтобы иметь точные локальные часы, ЭВМ должна быть оборудована аппаратными часами, состоящими из задающего генератора и интерфейса, обеспечивающего необходимые операции установки и коррекции. Логические часы конструируются, используя эти компоненты и программы, которые осуществляют подстройку частоты и абсолютного показания локальных часов. Такая система позволяет достичь точности времени до 15 нс и стабильности частоты на уровне 0.3 мс в день. Предлагаемая модель удобна для применения как для компенсируемых, так и для некомпенсируемых кварцевых генераторов, пригодна она и для часов, использующих для создания временной шкалы частоту сети переменного тока.

    Важно заметить, что конкретная описанная реализация является лишь одной из многих возможных.

    Реализация "пушистый шарик" (Fuzzball)

    Локальные часы "пушистый шарик" представляют собой комбинация аппаратных и программных регистров, а также алгоритмов, которые осуществляют функционирование часов - работу управляемого задающего генератора, синхронизуемого от внешнего источника. Долее следует описание его компонент и способа работы. Заметим, что все числа представлены в представлении дополнений до 2, а все сдвиги являются арифметическими (заполнение знаком при сдвиге вправо и нулем при сдвиге влево).

    48-битовый часовой регистр (clock) и 32-битовый предварительный счетчик (prescaler) образуют управляемый задающий генератор с периодом 1 мс. Дробная часть кода времени представляет число миллисекунд с начала суток. 32-битовый регистр коррекций (Clock-Adjust) используется для подстройки фазы часов постепенными шагами, что исключает неоднородности временной шкалы. Его содержимое обозначается x. 32-битовый регистр компенсации дрейфа (Skew-Compensation) используется для подстройки частоты задающего генератора с помощью добавления небольших фазовых сдвигов (0,01%). Его содержимое обозначается символом y. 16-битовый счетчик оповещения (Watchdog) и 32-битный регистр согласования (Compliance) используются для определения корректности и служит также для задания периода рассылки запросов. Содержимое регистра согласования обозначается символом z. 32-битовый регистр настройки (PPS-Adjust) служит для подстройки точности, когда имеется точный источник сигналов с периодом в одну секунду. 2-битовый регистр флагов управляет добавлением/вычитанием секунд к показаниям часов, когда это необходимо.

    Все регистры кроме предварительного счетчика обычно размещаются в памяти. В типовом интерфейсе часов, таком как DEC KWV11-C, регистр prescaler реализован в виде 16-битового буферного счетчика, управляемого кварцевым генератором с частотой, кратной 1000 Гц. Переполнение счетчика вызывает прерывание процессора, которое осуществляет приращение содержимого регистра часов.

    Когда наступает момент подстройки, CLOCK.ADJ секунд вычитается из содержимого PPS-счетчика, но это CLOCK.ADJ делается лишь при условии, что там лежит число больше нуля. CLOCK.ADJ добавляется к коду счетчика Watchdog. Этот код не должен превышать значения NTP.MAXAGE, поделенного на CLOCK.ADJ. Если счетчик Watchdog достигнет этой величины, часы считаются не синхронизованными, а Leap-биты устанавливаются равными 112.

    Постепенная настройка фазы

    Если локальные часы нескорректированы, они продолжают работать со смещением и частотой (при отсутствии дрейфа), установленными при последней коррекции. Корректирующая информация имеет формат 48-битного целого числа со знаком. Это число характеризует целое и дробное число миллисекунд (запятая располагается после 32-го двоичного разряда). Если полученная величина превосходит максимальное значение, заданное CLOCK.MAX, необходима постепенная пошаговая коррекция. В норме величина поправки вычисляется в рамках алгоритма NTP. Однако, если код счетчика PPS больше нуля, вместо него должен использоваться регистр PPS-ADJUST. Пусть u представляет собой 32-битовый код с битами 0-31 равными разрядам 16-47 корректирующего кода. Если некоторые младшие биты корректирующего кода не используются, они устанавливаются равными биту знака. Такие операции сдвигают положение запятой влево по отношению биту 16, что уменьшает влияние ошибок округления. Пусть b число начальных нулей в коде регистра Compliance и пусть c - число начальных нулей в коде счетчика W@atchdog. Тогда b установится равным:

    b = b - 16 + clock.comp

    b не должно быть меньше нуля (это логарифм постоянной времени обратной связи). Затем установим c равным:

    c = 10 - c

    Величина c представляет собой логарифм времени интегрирования со времени последней коррекции. Затем вычисляются новые значения кодов для регистров CLOCK.ADJUST и Skew-Compensation.

    x = u >> b,
    y = y + (u >> (b + b - c)).

    В заключение вычисляем экспоненциальное среднее

    z = z + (u << (b + clock.mult) - z) >> clock.weight,

    где сдвиг влево переносит положения запятой с целью достижения большей точности.

    Для каждого периода подстройки определяется корректирующий код из двух составляющих. Первая составляющая (фаза) определяется как

    x >> clock.phase,

    эта величина затем вычитается из предшествующего значения регистра Clock-Adjust. Результат становится новым значением кода этого регистра. Вторая компонента - (частота) определяется как

    y >> clock.freq.

    Совокупность фазы и частоты представляет собой окончательный корректирующий код, который затем добавляется к коду регистра (clock). В заключение, счетчик Watchdog обнуляется.

    Величина b вычисленная ранее может использоваться для изменения величины системной переменной, характеризующей период запросов (коррекций) sys.poll.

    sys.poll <- b + NTP.MINPOLL.

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

    Ступенчатая подстройка фазы

    Когда величина поправки превышает CLOCK.MAX, имеется возможность того, что часы окажутся настолько не синхронизованы, что наилучшим решением будет немедленная замена содержимого регистра часов. Однако, в случаях, когда вариация записи весьма высока, разумно не поверить в возможность скачкообразного изменения, если только со времени последней коррекции не прошло достаточно много времени. Следовательно, если обнаружено скачкообразное изменение, а счетчик Watchdog содержит код меньше предварительно установленного значения CLOCK.MINSTEP, корректирующее сообщение игнорируется.

    Если обнаружено ступенчатое изменение, коррекция заносится непосредственно в регистры Clock, а содержимое регистров Clock-Adjust и Watchdog обнуляется. Другие же регистры остаются без изменений. Так как ступенчатое изменение показаний указывает на некорректность информации в часовых фильтрах (clock filters), биты добавления делаются равными 112 (не синхронизовано) и вызывается процедура очистки часовых фильтров и переменных состояния для всех партнеров. На практике необходимость корректировать показания часов скачкообразно случается крайне редко, когда, например, локальные часы или эталон перезагружаются.

    Практически значения CLOCK.MAX могут быть превышены временным сервером лишь в условиях чрезмерной перегрузки канала или при сбоях оборудования. Наиболее часто встречаемый случай - это смена сервера при регистрации слишком большого числа ошибок или из-за сильной вариации задержки. Рекомендуется, чтобы реализации программ включали средства формирования значений CLOCK.MAX для особых случаев. Величина, на которую можно превысить CLOCK.MAX, не нарушая требования монотонности, зависит от значения приращения регистра часов (Clock Register).

    Обсуждение реализации

    Базовая модель надежности NTP предполагает, что не должно быть никаких других способов изменения показаний кроме предусмотренных самим протоколом NTP. Системы с часами-календарем, имеющие питание от батареи или аккумулятора, считаются надежными, но менее точными, чем использующие NTP-синхронизацию. При последовательных коррекциях, если величина поправки превышает конфигурационный параметр (напр., 1000 секунд), поправка отбрасывается и посылается сообщение об ошибке. Некоторые реализации периодически записывают содержимое регистра Skew-Compensation (компенсация дрейфа) в системный файл или в NVRAM (память, сохраняемая при отключении питания).

    Преобразование из формата NTP в обычный информационный формат осуществляется прикладными программами. В день накануне добавления/вычитания секунды из показаний времени значение sys.leap устанавливается на первичном сервере вручную. Следует иметь в виду, что большинство радио-часов не имеет автоматических или ручных средств добавления/вычитания секунд. Но даже в случае некорректного добавления/вычитания секунды локальные часы будут вновь синхронизованы не позднее чем через число секунд, заданное CLOCK.MINSTEP.

    Приложение А. Формат данных NTP - версия 3

    Формат NTP-сообщения, которое следует сразу после UDP-заголовка, показан на рис 4.4.15.1.

    Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.

    Рис. 4.4.15.1. Формат сообщения NTP.

    Номер версии (VN) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).

    Режим (Mode) - трехбитовое поле, определяющее режим, значения кодов режима приведены в таблице 4.4.15.2.

    Слой (Stratum) - 8-битовое поле, определяющее код слоя, где работают локальные часы. Коды слоя представлены в таблице 4.4.15.3. Возможные значения кодов лежат в интервале от нуля до NTP.INFIN включительно.

    Период запросов (poll interval) - 8-битовое поле, указывающее на максимальное значение интервала между запросами. Код, записанный в этом поле, интерпретируется как целое число со знаком и характеризует значение периода в секундах, как ближайшее к величине степени двух. Коды, которые могут быть записаны в этом поле, должны лежать в интервале между NTP.MAXPOLL и NTP.MAXPOLL включительно.

    Точность (precision) - 8-битовое поле, обозначающее точность локальных часов в секундах. Код поля интерпретируется как целая степень со знаком числа 2.

    Базовая задержка (Root Delay) - 32-битовое поле, характеризующее RTT до эталонного источника в секундах. Код поля интерпретируется как число с фиксированной запятой, размещенной между битами 15 и 16. Заметим, что величина этого кода может иметь и отрицательное значение (зависит от точности часов и величины дрейфа).

    Базовая дисперсия (Root Dispersion) - 32-битовое поле, определяющее максимальную ошибку по отношению к эталонному источнику в секундах. Код поля интерпретируется как число с фиксированной запятой (между 15 и 16 битами). Допустимы только положительные значения.

    Идентификатор эталонных часов (Reference Clock Identifier) - 32-битовое поле, идентифицирующее конкретные эталонные часы. В случае кода слоя нуль (не специфицировано) или слоя 1 (первичный эталон), это 4-октетная комбинация выравнивается по левому краю и дополняется нулями (ASCII). Когда идентификатор в NTP не специфицирован, предлагаются ascii- идентификаторы, приведенные в таблице 4.4.15.4.

    В случае слоя 2 и больше (вторичный эталон) - это 4-октетный IP-адрес ЭВМ - первичного эталона.

    Эталонная временная метка (Reference Timestamp) - поле локального времени (64-битовый формат временных меток), когда часы корректировались в последний раз.

    Исходная временная метка (Originate Timestamp) определяет время, когда запрос направлен серверу (стандартный 64-битовый формат временных меток).

    Получаемая временная метка (Receive Timestamp) - время, когда запрос прибыл к серверу (стандартный 64-битовый формат временных меток).

    Передаваемая временная метка (Transmit Timestamp) - локальное время, когда послан отклик сервером (стандартный 64-битовый формат временных меток).

    Аутентификатор (authenticator) (опционно) - поле, содержащее аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.

    Приложение Б. Сообщения управления NTP

    В сетевой среде должны быть средства управления программами NTP, такие как установка индикатора добавления секунды (Leap-Indicator) со стороны первичного сервера, настройка различных системных параметров и процедур мониторинга. Такие операции могут быть реализованы с привлечением протокола snmp и соответствующего расширения базы данных MIB. Однако в тех случаях, когда такие средства недоступны, эти функции могут быть реализованы с помощью специальных управляющих NTP-сообщений.

    Управляющие сообщения NTP имеют код 6 в поле режима первого октета NTP-заголовка. Формат поля данных специфичен для каждой из команд или отклика. Однако, в большинстве случаев формат конструируется так, чтобы облегчить его непосредственное чтение. Как правило, он состоит из ASCII-строк. Если используется аутентификатор, поле данных дополняется нулями до границы, кратной целому числу 32-битных слов.

    IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 октетов; однако, некоторые команды или отклики могут содержать данные, непомещающиеся в одну дейтограмму. Для решения данной проблемы все октеты сообщения нумеруются, начиная с нуля. При передаче фрагментов сообщения номер первого октета записывается в поле смещения (offset), а число октетов в поле длины. Бит (M - more) устанавливается во всех фрагментах за исключением последнего.

    Большинство контрольных функций включает посылку команды и получение отклика. Отправитель выбирает ненулевой порядковый номер и устанавливает статусное поле и биты R и E равными нулю. Получатель интерпретирует код операции и дополнительную информацию, содержащуюся в поле данных, вносит изменение в поле статуса и устанавливает бит R=1, а также возвращает три 32-битного слова заголовка вместе с другой дополнительной информацией поля данных. В случае неверного формата сообщения или ошибки в поле данных получатель заносит соответствующий код в поле статуса, устанавливает биты R и E равными 1, и опционно записывает диагностическое сообщение в поле данных.

    Некоторые команды осуществляют чтение или запись для системных переменных и переменных партнеров для ассоциации, идентифицированной в команде. Другие читают или записывают значения переменных, связанных с радио-часами и другими приборами, имеющими непосредственное отношение к эталонам времени. Для определения ассоциации используется ее 16-битовый идентификатор. Для системных переменных используется идентификатор нуль. Управляющий объект может затребовать текущий список идентификаторов с тем, чтобы их использовать в дальнейшем. При попытке употребить уже недействительный идентификатор будет прислан соответствующий отклик, после чего необходимо запросить список идентификаторов еще раз.

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

    Формат сообщений управления NTP

    Формат заголовков управляющих NTP-сообщений показан на рис. 4.4.15.2. Этот заголовок располагается непосредственно вслед за UDP-заголовком.

    Рис. 4.4.15.2. Формат управляющего сообщения ntp

    Первые два бита, обозначенные ZZ, должны всегда содержать 0.

    Номер версии (VN - version number) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).

    Режим (Mode) - трехбитовое поле, определяющее режим, значение кода режима для управляющих сообщений равно 6.

    Бит отклика (R) - равен нулю для команд и 1 для откликов.

    Бит ошибки (E) - равен нулю для нормального отклика и 1 в случае ошибки.

    Бит продолжения (M - more) - равен нулю для последнего фрагмента и 1 - для всех остальных.

    Код операции (OP) - 5-битовое поле, определяющее код команды. Значения кодов и их функции представлены в таблице 4.4.15.5.

    Таблица 4.4.15.5. Коду операции управляющего сообщения

    Код

    Функция

    0

    Зарезервировано

    1

    чтение статуса команда/отклик

    2

    чтение переменной команда/отклик

    3

    запись переменной команда/отклик

    4

    чтение переменных часов команда/отклик

    5

    запись переменных часов команда/отклик

    6

    установка адреса/порта trap команда/отклик

    7

    отклик на Trap

    8-31

    Зарезервировано на будущее

    Порядковый номер (Sequence) - 16-битовое поле, определяющее номер запроса или отклика, и облегчающее определения их соответствия.

    Статус - 16-битовое поле, содержащее код статуса системы, партнера или часов.

    Идентификатор ассоциации (Association ID) - 16-битовое поле, несущее в себе идентификатор ассоциации.

    Смещение (Offset) - 16-битовое поле, определяющее положение первого октета поля данных в сообщении, передаваемом в нескольких дейтограммах (позиция задается в октетах).

    Длина (Count) - 16-битовое поле, определяющее длину поля данных в октетах.

    Данные - это поле содержит информацию сообщения, как для команды, так и для отклика. Максимальное число октетов в поле данных равно 468.

    Аутентификатор (опционно). Поле, содержащие аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.

    Статусные слова

    Статусные слова указывают на текущее состояние системы ассоциации и часов. Эти слова интерпретируются программами сетевого мониторинга и имеют 4 разных 16-битовых форматов. Статусные слова партнеров и системы соответствуют откликам для всех команд за исключением случая чтения/записи переменных часов и установки адреса/порта для TRAP. Идентификатор ассоциации нуль соответствует системным статусным словам, в то время как ненулевой идентификатор указывает на какую-то конкретную ассоциацию. Статусное слово, присланное в ответ на команду чтения или записи переменной часов, указывает на состояние оборудования и кодирующего программного обеспечения.

    Системные статусные слова

    Системное статусное слово может присутствовать в статусном поле отклика. Системное статусное слово имеет следующий формат.

    Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.

    Источник часов (clock source) - 6-битовое поле, указывающее на используемый в данный момент источник синхронизации. Назначение кодов этого поля описано в таблице 4.4.15.6.

    Таблица 4.4.15.6. Коды источников временного эталона

    Код

    Функция

    0

    Не специфицирован или неизвестен

    1

    Калиброванные атомные часы (напр., hp 5061)

    2

    vlf (диапазон 4) или НЧ (диапазон 5) радио (напр., omega, wwvb)

    3

    ВЧ (диапазон 7) радио (напр., chu, msf, wwv/h)

    4

    УВЧ (диапазон 9) спутник (напр., goes, gps)

    5

    Локальная сеть (напр., dcn, tsp, dts)

    6

    UDP/NTP

    7

    UDP/time

    8

    eyeball-and-wristwatch

    9

    Телефонный модем (напр., nist)

    10-63

    Зарезервировано на будущее

    Системный счетчик событий - четырех битовое целое число, обозначающее число событий, происшедших с момента последнего получения статусного слова системы. Счетчик обнуляется, когда присылается в статусном поле отклика и остается неизменным после достижения значения 15.

    Код системного события - четырехбитовое число, идентифицирующее последнее системное событие, новое значение переписывает предыдущее. Коды событий перечислены в таблице 4.4.15.7.

    Таблица 4.4.15.7. Коды системных событий

    Код

    Функция

    0

    Не специфицировано

    1

    Рестарт системы

    2

    Системный или аппаратный сбой

    3

    Новое статусное слово системы (изменение битов добавления или синхронизации)

    4

    Новый источник синхронизации или слой (изменение sys.peer или sys.stratum)

    5

    Сброс системных часов (корректирующая добавка превысила clock.max)

    6

    Некорректное системное время или дата

    7

    system clock exception

    8-15

    Зарезервировано на будущее

    Статусное слово партнера

    Статусное слово партнера возвращается в статусном поле отклика на команду чтения статуса, а также чтения или записи переменных. Это слово появляется в списке идентификаторов ассоциации и статусных слов, присылаемых в ответ на команду чтения статуса с нулевым идентификатором ассоциации. Формат статусного слова партнера содержит следующие поля (рис. 4.4.15.3)

    Рис. 4.4.15.3. Форматы статусных слов

    Статус партнера - 5-битный код, характеризующий состояние партнера, определяемого процедурой обмена. Значения этого поля представлены в таблице 4.4.15.8.

    Таблица 4.4.15.8. Коды состояния партнера

    Значение кода

    Функция

    0

    Сконфигурирован (peer.config)

    1

    Разрешена аутентификация (peer.authenable)

    2

    Аутентификация успешна (peer.authentic)

    3

    Партнер доступен (peer.reach)

    4

    Зарезервировано на будущее

    Выбор партнера (Sel) - 3-битный код, говорящий о состоянии партнера, определенного в результате процедуры выбора часов. Значения кодов представлены в таблице 4.4.15.9.

    Таблица 4.4.15.9. Коды выбора партнера

    Значение кода

    Функция

    0

    Отклонен

    1

    Проверка соответствия прошла успешно (тесты 1 - 8)

    2

    Прошел проверки корректности (алгоритм пересечения)

    3

    Прошел проверки, как кандидат

    4

    Проверка ресурсов прошла успешно (алгоритм кластеризации)

    5

    Текущий источник синхронизации; превышено максимальное расстояние (если используются предельные проверки)

    6

    Текущий источник синхронизации; максимальное расстояние в пределах нормы

    7

    Зарезервировано на будущее

    Счетчик событий партнера - 4-битовое число событий (exception) партнера, которые имели место со времени последнего получения статусного слова в рамках отклика или сообщения TRAP. Счетчик сбрасывается при занесении кода в поле статуса отклика, и перестает изменяться при достижении значения 15.

    Код события партнера - 4-битовое целое число, идентифицирующее последнее событие партнера. Новое значение переписывает предыдущее. Значения кодов представлены в таблице 4.4.15.10.

    Таблица 4.4.15.10. Коды события партнера

    >

    Значение кода

    Функция

    0

    Не специфицировано

    1

    IP-ошибка партнера

    2

    Ошибка аутентификации партнера (бит peer.authentic был равен 1, а теперь =0)

    3

    Партнер не достижим (peer.reach стал равен нулю)

    4

    Партнер достижим (peer.reach стал не равен нулю)

    5

    Проблема с часами партнера

    6-15

    Зарезервировано на будущее

    Слово состояния часов

    Существует два способа подключить эталонные часы к NTP-серверу, как специальный прибор, поддерживаемый операционной системой или как партнера, управляемого NTP. Как и в случае команды чтения статуса идентификатор ассоциации определяет, часы какого из партнеров имеются в виду. При нулевом идентификаторе речь идет о системных часах. Протокол поддерживает только одни системные часы, число часов-партнеров практически не ограничено. Статусное слово часов системы или партнера записывается в поле статуса отклика на команды чтения или записи переменных, характеризующих часы. Это слово может рассматриваться как расширение системного статусного слова или статусного слова партнера. Формат слова описан ниже (См. также рис. 4.4.15.3).

    Состояние часов - 8-битовое число, характеризующее текущее состояние часов. Допустимые значения этого числа и их смысл представлены в таблице 4.4.15.11.

    Таблица 4.4.15.11. Коды состояния часов

    Код

    Функция

    0

    Работа часов в пределах нормы

    1

    Таймаут ответа

    2

    Плохой формат ответа

    3

    Сбой оборудования или программы

    4

    Потеря при передаче

    5

    Неверный формат или значение даты

    6

    Неверный формат или значение времени

    7-255

    Зарезервировано на будущее

    Код события для часов - 8-битовый код, идентифицирующий последнее событие для данных часов (exception). Новое значение переписывает предыдущее значение кода. Когда значение кода становится ненулевым для поля статуса радио-часов, этот код копируется в статусное поле кода события и считается, что произошло событие для системных часов или часов партнера.

    Слово состояния ошибки

    Статусное слово ошибки присылается в поле статуса отклика, если обнаружена ошибка в формате сообщения или в его содержимом. Его присутствие указывается равенствами E (error) и R (response) битов 1. Коды ошибки и их значения собраны в таблице 4.4.15.12.

    Таблица 4.4.15.12. Коды ошибки

    Код ошибки

    Значение

    0

    Не специфицировано

    1

    Неудачная аутентификация

    2

    Неверный формат или длина сообщения

    3

    Неверный код операции

    4

    Неизвестный идентификатор ассоциации

    5

    Неизвестное имя переменной

    6

    Неверное значение переменной

    7

    Административно запрещено

    8-255

    Зарезервировано на будущее

    Команды

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

    [=],[=],...

    где представляет собой имя переменной системы или партнера в форме ASCII-последовательности, а является десятичным или шестнадцатеричным числом, или строкой, соответствующей синтаксису языка C. Для большей читаемости допускается применение пробелов (Whitespace). IP-адреса представляются в формате [n.n.n.n], где n - десятичное число. Скобки являются опционными.

    Команды интерпретируются следующим образом:

    Чтение статуса (1). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Команда работает по-разному в зависимости от значения идентификатора. Если идентификатор не равен нулю, отклик содержит идентификатор партнера и статусное слово. Если идентификатор ассоциации равен нулю, отклик содержит системный идентификатор (0) и статусное слово, в то время как поле данных содержит список пар двоичных кодов:

    <идентификатор ассоциации> <статусное слово>,

    по одному на каждую, определенную в данный момент ассоциацию.

    Чтение переменных (2). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Если идентификатор ассоциации не равен нулю, отклик включает в себя идентификатор запрашиваемого партнера и его статусное слово, в то время как в поле данных записывается список переменных партнера и их значения. Если идентификатор ассоциации равен нулю, поле данных содержит список системных переменных и их значения. Если партнер выбран в качестве источника синхронизации, отклик включает в себя идентификатор партнера и его статусное слово.

    Запись переменных (3). Поле данных команды содержит список присвоений, описанный выше. Отклик идентичен отклику на команду чтения переменных.

    Чтение переменных часов (4). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Идентификатор ассоциации выбирает переменные системных часов или партнера точно также, как в случае команды чтения переменных. Отклик включает в себя запрошенные идентификатор часов и статусное слово, а поле данных несет в себе список переменных часов и их значений, включая последний временной код, полученный от часов.

    Запись переменных часов (5). Поле данных команды содержит список присвоений, как это описано выше. Отклик имеет формат, как в случае команду чтения переменных часов.

    Установка адреса/порта Trap (6). Идентификатор ассоциации команды, статус и поле данных игнорируются. Адрес и номер порта для последующих TRAP-сообщений берутся из самого управляющего сообщения. Исходное значение счетчика TRAP для сообщений откликов заимствуется из поля номера по порядку. Идентификатор ассоциации, статус и поле данных в отклике несущественны.

    Отклик на TRAP (7). Это сообщение посылается, когда происходит событие (exception) в систему, у партнера или для данных часов. Код команды равен 7, а бит R=1. Содержимое trap-счетчика увеличивается на 1 для каждого сообщения данного типа. Поле номер по порядку сообщения равно содержимому этого счетчика. При посылке сообщения TRAP используется IP-адрес и номер порта, заданные командой установки адреса и порта TRAP. В случае системного TRAP идентификатор ассоциации устанавливается равным нулю, а поле статус содержит статусное слово системы. В случае TRAP партнера поле идентификатора ассоциации соответствует партнеру, а поле статус несет в себе его статусное слово. В поле данных опционно может быть включено любое символьное сообщение (ASCII).

    Приложение В. Аутентификация

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

    Механизм управления доступом в NTP отвечает всем базовым требованиям. Различные проверки препятствуют большинству возможных атак, связанных с подменой временных меток.

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

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

    Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77].

    Механизм аутентификации NTP

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

    Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0.

    Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.

    Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения. Системная переменная peer.hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована.

    Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна).

    Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования.

    Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование.

    Процедуры аутентификации NTP

    Когда используется аутентификация для реализации протокола NTP, привлекается две дополнительные процедуры. Одна из них формирует крипто-сумму для передаваемых сообщений, а другая дешифрует и проверяет корректность контрольной суммы получаемых сообщений. Процедуры представляют собой варианты программ, используемых для реализации алгоритма DES и описанных в [NBS80]. На самом деле процедура не связана жестко с алгоритмом DES, а лишь предполагают работу с 64-битовыми блоками данных.

    Приложение Г. Временная шкала NTP и ее хронометрия

    Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени.

    Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны.

    Первичная частота и стандарты времени

    Первичными стандартами частоты являются осцилляторы с высокой стабильностью. Такие стандарты используют межуровневые переходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.12 приведены характеристики типичных стандартов времени. Локальные же часы обычно используют некомпенсированные кварцевые генераторы. Такие генераторы не только подвержены дрейфам под действием изменения параметров окружающей среды, но систематически меняют свои свойства со временем (старение).

    Даже если кварцевый генератор имеет температурную компенсацию, его частота должна время от времени сравниваться первичным стандартом для обеспечения высокой точности.

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

    Обычно часовые осцилляторы классифицируются по трем параметрам: стабильность, разброс и блуждание. Стабильность определяется систематическими вариациями частоты со временем. Синонимом нестабильности является старение и дрейф. Разброс (называемый также временным дрожанием) характеризует кратковременные случайные вариации частоты с составляющими более 10 Гц, в то время как блуждание характеризует медленные вариации частоты с составляющими менее 10 Гц.

    Таблица 4.4.15.12. Точность и стабильность часов для различных слоев

    Слой

    Минимальная точность (за день)

    Минимальная стабильность (за день)

    1

    1 x 10-11

    Не специфицировано

    2

    1.6 x 10-8

    1 x 10-10

    3

    4.6 x 10-6

    3.7 x 10-7

    4

    3.2 x 10-5

    Не специфицировано

    Конструкция, работа и характеристики осциллятора слоя 1 предполагаются сопоставимыми с национальными стандартами времени и часто базируются на цезиевом стандарте. Часы слоя 4 соответствуют требованиям обычных цифровых каналов и систем PBX. Слои 2-3 могут использоваться для работы с мощными синхронными каналами связи.

    Раздача времени и частоты

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

    Американский Национальный Институт Стандартов и Технологии (NIST - National Institute of Standards and Technology) поддерживает три радиослужбы для рассылки временной информации. Одна из них использует передачу (ВЧ или CCIR диапазон 7) на частотах 2.5, 5, 10, 15 и 20 Мгц. Сигнал распространяется, отражаясь от верхних слоев атмосферы, что неизбежно приводит к непредсказуемым вариациям задержки на принимающей стороне. С 60-секундным интервалом передается временной код, который транслируется на 100 килогерцной субнесущей со скоростью передачи 1 бит/с. Этот код содержит информацию об UTC времени и дате, но не включает в себя данных о текущем годе и оповещения о добавлении/вычитании секунды для последней минуты данного дня. Существуют и другие сходные службы времени (например, в Оттаве), гарантирующие точность на уровне 1-10 мсек.

    Вторая служба времени NIST использует передачу (НЧ или CCIR диапазон 5) на частоте 60 КГц, она доступна на континентальной части США и вблизи берегов. Сигнал распространяется в нижней части атмосферы и по этой причине слабо подвержен вариациям времени распространения. Временной код передается с периодом в 60 секунд со скоростью 1 бит/с. Достижимая точность составляет 50 миллисекунд [BLA74]. Ряд европейских стран предлагают аналогичные службы времени (Великобритания - MSF; Германия - DCF77). Коды времени здесь включают информацию о текущем годе и предупреждение о добавляемой/вычитаемой секунде. Третья служба NIST использует передачу на частоте 468 МГц (УВЧ или CCIR диапазон 9) с геостационарных спутников GOES, три из которых перекрывают западное полушарие. Временной код перемежается с сообщениями, адресованными удаленным датчикам и состоит из 600 4-битовых слов, передаваемых с периодом в 30 секунд. Временной код содержит информацию об UTC времени-дне-годе, а также предупреждение о добавлении/вычитании секунды в конце дня. Точность этой службы составляет 0,5 мсек.

    Министерство обороны США разработало глобальную систему определения координат GPS (Global Positioning System). Эта система базируется на 24 спутниках, движущихся по орбитам с периодом 12 часов. Система GPS может обеспечить точность определения времени на уровне нескольких наносекунд [VAN84].

    Американская береговая охрана в течение многих лет использует службу радионавигации LORAN-C [FRA82]. Эта служба обеспечивает временную точность менее 1 мксек.

    Система радионавигации военно-морского флота США и других стран OMEGA [VAS78] состоит из 8 передатчиков, работающих на частотах от 10.2 до 13.1 КГц (УНЧ или CIR диапазон 4) и перекрывающих весь земной шар 24 часа в сутки. Точность этой системы составляет около 1 мсек. Система OMEGA обеспечивает высокую точность для частоты, но не передает временного кода. По этой причине приемник должен предварительно получить географические координаты с точностью до градуса и время UTC с точностью 5 секунд от независимых источников.

    Заметим, что не все службы времени передают информацию о текущем годе и предупреждения о добавлении/вычитании секунды. Протокол NTP позволяет решить эту проблему.

    Определение частоты

    В течение многих лет наиболее важным использованием времени и частоты были всемирная навигация и космическая наука, которые зависят от наблюдений солнца, луны и звезд. За стандартную секунду (в 1957 году) принята 1/31,556,925.9747 периода вращения Земли вокруг Солнца (тропический год). Согласно этой шкалы тропический год длится 365.2421987 дней, а лунный месяц 29.53059 дней. Однако тропический год может быть определен лишь с точностью около 50 мсек.

    С древнейших времен человечеству были известны три осциллятора (процесса задающих временную шкалу) - вращение земли вокруг своей оси, вращение Луны вокруг Земли и вращение Земли вокруг Солнца. К сожалению, с точки требований современных технологий все эти три осциллятора не обладают достаточной стабильностью. В 1967 стандартная секунда была переопределена и теперь равняется 9,192,631,770 периодов перехода в атоме цезия-133. С 1972 стандарты времени и частоты базируются на международном атомном времени TAI (International Atomic Time). Точность таких часов составляет около микросекунды в сутки. Важно то, что новая шкала абсолютно однородна и не подвержена дрейфам.

    Определение времени и необходимости добавления/вычитания секунды

    Международное бюро мер и стандартов IBWM (International Bureau of Weights and Measures) использует астрономические наблюдения, выполненные морской обсерваторией США и другими обсерваториями для определения UTC.

    Для более точной временной привязки событий после 1972 года необходимо знать, когда вставлялись или удалялись секунды коррекции (удаление пока никогда не производилось). Как определено в докладе 517 CCIR, который воспроизведен в [BLA74], дополнительные секунды вставляются после 23:59:59 в последний день июня или декабря. Неоднородность во временную шкалу (TAI) помимо добавляемых секунд вносят также 100 миллисекундные коррекции UT1, называемые DUT1, которые служат для повышения точности при навигации. Следует признать, что момент добавления секунды является началом новой (однородной) временной шкалы.

    Временная шкала NTP базируется на шкале UTC, но необязательно всегда совпадает с ней. В 0 часов 1 января 1972 начинается эра UTC, часы NTP были установлены на 2,272,060,800 стандартных секунд после 0 часов 1 января 1900.

    Ссылки

    [ABA89]

    Abate, et al. AT&T's new approach to the synchronization of telecommunication networks. IEEE Communications Magazine (April 1989), 35-45.

    [ALL74a]

    Allan, D.W., J.H. Shoaf and D. Halford. Statistics of time and frequency data analysis. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 151-204.

    [ALL74b]

    Allan, D.W., J.E. Gray and H.E. Machlan. The National Bureau of Standards atomic time scale: generation, stability, accuracy and accessibility. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 205-231.

    [BEL86]

    Bell Communications Research. Digital Synchronization Network Plan. Technical Advisory TA-NPL-000436, 1 November 1986.

    [BER87]

    Bertsekas, D., and R. Gallager. Data Networks. Prentice-Hall, Englewood Cliffs, NJ, 1987.

    [BLA74]

    Blair, B.E. Time and frequency dissemination: an overview of principles and techniques. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 233-314.

    [BRA80]

    Braun, W.B. Short term frequency effects in networks of coupled oscillators. IEEE Trans. Communications COM-28, 8 (August 1980), 1269-1275

    [COL88]

    Cole, R., and C. Foxcroft. An experiment in clock synchronisation. The Computer Journal 31, 6 (1988), 496-502.

    [DAR81a]

    Defense Advanced Research Projects Agency. Internet Protocol. DARPA Network Working Group Report RFC-791, USC Information Sciences Institute, September 1981.

    [DAR81b]

    Defense Advanced Research Projects Agency. Internet Control Message Protocol. DARPA Network Working Group Report RFC-792, USC Information Sciences Institute, September 1981.

    [DEC89]

    Digital Time Service Functional Specification Version T.1.0.5. Digital Equipment Corporation, 1989

    [DER90]

    Dershowitz, N., and E.M. Reingold. Calendrical Calculations. Software Practice and Experience 20, 9 (September 1990), 899-928.

    [FRA82]

    Frank, R.L. History of LORAN-C. Navigation 29, 1 (Spring 1982).

    [GUS84]

    Gusella, R., and S. Zatti. TEMPO - A network time controller for a distributed Berkeley UNIX system. IEEE Distributed Processing Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in: Proc. Summer USENIX Conference (June 1984, Salt Lake City).

    [GUS85a]

    Gusella, R., and S. Zatti. The Berkeley UNIX 4.3BSD time synchronization protocol: protocol specification. Technical Report UCB/CSD 85/250, University of California, Berkeley, June 1985.

    [GUS85b]

    Gusella, R., and S. Zatti. An election algorithm for a distributed clock synchronization program. Technical Report UCB/CSD 86/275, University of California, Berkeley, December 1985.

    [HAL84]

    Halpern, J.Y., B. Simons, R. Strong and D. Dolly. Fault-tolerant clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 89-102.

    [JOR85]

    Jordan, E.C. (Ed). Reference Data for Engineers, Seventh Edition. H.W. Sams & Co., New York, 1985.

    [KOP87]

    Kopetz, H., and W. Ochsenreiter. Clock synchronization in distributed real-time systems. IEEE Trans. Computers C-36, 8 (August 1987), 933-939.

    [LAM78]

    Lamport, L., Time, clocks and the ordering of events in a distributed system. Comm. ACM 21, 7 (July 1978), 558-565.

    [LAM85]

    Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the presence of faults. J. ACM 32, 1 (January 1985), 52-78.

    [LIN80]

    Lindsay, W.C., and A.V. Kantak. Network synchronization of random signals. IEEE Trans. Communications COM-28, 8 (August 1980), 1260-1266.

    [LUN84]

    Lundelius, J., and N.A. Lynch. A new fault-tolerant algorithm for clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 75-88.

    [MAR85]

    Marzullo, K., and S. Owicki. Maintaining the time in a distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-54.

    [MIL81a]

    Mills, D.L. Time Synchronization in DCNET Hosts. DARPA Internet Project Report IEN-173, COMSAT Laboratories, February 1981.

    [MIL81b]

    Mills, D.L. DCNET Internet Clock Service. DARPA Network Working Group Report RFC-778, COMSAT Laboratories, April 1981.

    [MIL83a]

    Mills, D.L. Internet Delay Experiments. DARPA Network Working Group Report RFC-889, M/A-COM Linkabit, December 1983.

    [MIL83b]

    Mills, D.L. DCN local-network protocols. DARPA Network Working Group Report RFC-891, M/A-COM Linkabit, December 1983.

    [MIL85a]

    Mills, D.L. Algorithms for synchronizing network clocks. DARPA Network Working Group Report RFC-956, M/A-COM Linkabit, September 1985.

    [MIL85b]

    Mills, D.L. Experiments in network clock synchronization. DARPA Network Working Group Report RFC-957, M/A-COM Linkabit, September 1985.

    [MIL85c]

    Mills, D.L. Network Time Protocol (NTP). DARPA Network Working Group Report RFC-958, M/A-COM Linkabit, September 1985.

    [MIL88a]

    Mills, D.L. Network Time Protocol (version 1) - specification and implementation. DARPA Network Working Group Report RFC-1059, University of Delaware, July 1988.

    [MIL88b]

    Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo Alto, CA, August 1988), 115-122.

    [MIL89]

    Mills, D.L. Network Time Protocol (version 2) - specification and implementation. DARPA Network Working Group Report RFC-1119, University of Delaware, September 1989.

    [MIL90]

    Mills, D.L. Measured performance of the Network Time Protocol in the Internet system. ACM Computer Communication Review 20, 1 (January 1990), 65-75.

    [MIL91a]

    Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications 39, 10 (October 1991), 1482-1493.

    [MIL91b]

    Mills, D.L. On the chronology and metrology of computer network timescales and their application to the Network Time Protocol. ACM Computer Communications Review 21, 5 (October 1991), 8-17.

    [MIT80]

    Mitra, D. Network synchronization: analysis of a hybrid of master-slave and mutual synchronization. IEEE Trans. Communications COM-28, 8 (August 1980), 1245-1259.

    [NBS77]

    Data Encryption Standard. Federal Information Processing Standards Publication 46. National Bureau of Standards, U.S. Department of Commerce, 1977.

    [NBS79]

    Time and Frequency Dissemination Services. NBS Special Publication 432, U.S. Department of Commerce, 1979

    [NBS80]

    DES Modes of Operation. Federal Information Processing Standards Publication 81. National Bureau of Standards, U.S. Department of Commerce, December 1980.

    [POS80]

    Postel, J. User Datagram Protocol. DARPA Network Working Group Report RFC-768, USC Information Sciences Institute, August 1980.

    [POS83a]

    Postel, J. Daytime protocol. DARPA Network Working Group Report RFC-867, USC Information Sciences Institute, May 1983.

    [POS83b]

    Postel, J. Time protocol. DARPA Network Working Group Report RFC-868, USC Information Sciences Institute, May 1983.

    [RIC88]

    Rickert, N.W. Non Byzantine clock synchronization - a programming experiment. ACM Operating Systems Review 22, 1 (January 1988), 73-78.

    [SCH86]

    Schneider, F.B. A paradigm for reliable clock synchronization. Department of Computer Science Technical Report TR 86-735, Cornell University, February 1986.

    [SMI86]

    Smith, J. Modern Communications Circuits. McGraw-Hill, New York, NY, 1986.

    [SRI87]

    Srikanth, T.K., and S. Toueg. Optimal clock synchronization. J. ACM 34, 3 (July 1987), 626-645.

    [STE88]

    Steiner, J.G., C. Neuman, and J.I. Schiller. Kerberos: an authentication service for open network systems. Proc. Winter USENIX Conference (February 1988).

    [SU81]

    Su, Z. A specification of the Internet protocol (IP) timestamp option. DARPA Network Working Group Report RFC-781. SRI International, May 1981.

    [TRI86]

    Tripathi, S.K., and S.H. Chang. ETempo: a clock synchronization algorithm for hierarchical LANs - implementation and measurements. Systems Research Center Technical Report TR-86-48, University of Maryland, 1986.

    [VAN84]

    Van Dierendonck, A.J., and W.C. Melton. Applications of time transfer using NAVSTAR GPS. In: Global Positioning System, Papers Published in Navigation, Vol. II, Institute of Navigation, Washington, DC, 1984.

    [VAS78]

    Vass, E.R. OMEGA navigation system: present status and plans 1977-1980. Navigation 25, 1 (Spring 1978).

    Previous: 4.4.14.5 Программа Sendmail    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.16 Протокол SNTP


    previous up down next index index
    Previous: 4.4.15 Сетевой протокол времени NTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.17 Введение в MPLS, TE и QoS

    4.4.16 Протокол SNTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол SNTP V 4 отличается от предыдущей версии NTP и SNTP (Simple Network Time Protocol (SNTP) V.4 for IPv4, IPv6 and OSI, D. Mills, RFC-2030) модификацией интерпретации заголовка с целью осуществления совместимости адресации с IPv6 [DEE96] и OSI [COL94].

    1. Введение

    Протокол сетевого времени (NTP v3), описанный в документе RFC-1305 [MIL92], широко используется для синхронизации часов ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным системам точного времени. В большинстве мест Интернет протокол гарантирует точность синхронизации с точностью 1-50 мс, в зависимости от свойств источника синхронизации и сетевых задержек.

    RFC-1305 специфицирует машину протокола NTP v3 в терминах событий, состояний, функций перехода и действий. Кроме того, там определены инженерные алгоритмы улучшения точности синхронизации и выбора из списка эталонных источников, некоторые из которых могут быть неисправны. Эти алгоритмы необходимы для компенсации влияния вариаций задержки пакетов в сети Интернет. Однако, во многих обстоятельствах приемлемы точности порядка доли секунды. В таких случаях используется более простые протоколы времени [POS83]. Эти протоколы обычно использует RPC-обмен, где клиент запрашивает время дня, а сервер присылает его значение в секундах после некоторого известного эталонного момента.

    NTP создан для использования клиентами и серверами с широким диапазоном возможностей для широкого интервала сетевых задержек и большого временного разброса. Большинство пользователей NTP синхронизации используют программное обеспечение с полным набором опций и алгоритмов (смотри http://www.eecis.udel.edu/~ntp).

    SNTP v 4 предполагает совместимость с NTP и SNTP v 3 как для клиентов так и для серверов. Кроме того, клиенты и серверы SNTP v.4 могут реализовывать расширения для работы в эникаст режиме.

    Клиенты SNTP должны работать только на самом верхнем уровне субсети в конфигурациях, где синхронизация NTP или SNTP клиентов не зависит от других клиентов. Серверы SNTP должны работать только на первом (базовом) уровне субсети и в конфигурациях, где нет других источников синхронизации кроме надежных радио или модемных служб точного времени.

    2. Рабочие режимы и адресация

    SNTP v.4 может работать в уникастном (точка-точка), мультикастном (один передатчик - много приемников) или эникаст (несколько передатчиков - один приемник). Уникастный клиент посылает запросы специально выделенному серверу по его уникастному адресу и ожидает отклика, из которого он может определить время и опционно RTT, а также сдвижку временной шкалы местных часов по отношению к шкале сервера. Мультикастный сервер периодически посылает сообщения по локальному мультикаст-адресу (IPv4 или IPv6). Мультикастный клиент воспринимает получаемые данные и не посылает никаких запросов. Эникастный клиент посылает запрос по локальному специально выделенному мультикастному (IPv4 или IPv6) адресу, при этом один или более эникатных серверов отправляют клиенту отклик. Клиент связывается с первым из них и в дальнейшем продолжает работу уже в уникастном режиме адресации.

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

    В уникастном режиме адреса клиенту и серверу присваиваются согласно обычной схеме IPv4, IPv6 или OSI. В мультикастном режиме сервер использует локальный широковещательный адрес или мультикастный групповой адрес. Локальный широковещательный IP-адрес имеет область действия, ограниченную субсетью, так как маршрутизаторы не ретранслируют широковещательные IP-дейтограммы. С другой стороны IP-адрес мультикастинг-группы имеет область действия, распространяющуюся потенциально на весь Интернет. Для IPv4 iana для целей NTP выделила мультикастный групповой адрес 224.0.1.1, который используется как для мультикаст серверов, так и для эникаст клиентов.

    Мультикастные клиенты прослушивают выделенный локальный широковещательный адрес или мультикастный групповой адрес. В случае мультикастного IP-адреса, мультикастный клиент и эникастный сервер должны реализовать протокол IGMP (Internet Group Management Protocol) [DEE89], для того чтобы местный маршрутизатор подключился к мультикаст-группе и ретранслировал сообщения, направленные по IPv4 или IPv6 мультикастным групповым адресам, присвоенным IANA.

    Очень важно оптимально выбрать значение поля TTL в IP-заголовке мультикастинг-сообщения, для того чтобы ограничить сетевые ресурсы, используемые данным видом сервиса.

    Режим эникаст сконструирован для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее. Эникастный клиент посылает запрос по локальному широковещательному адресу или групповому мультикастинг-адресу. Для этой цели используется групповой адрес NTP специально выделенный iana для этих целей. Один или более эникастных серверов воспринимают этот запрос и отправляют отклик по уникастному адресу клиента. Клиент устанавливает связь с сервером, от которого получил отклик раньше. Последующие отклики эникаст-серверов игнорируются.

    В случае SNTP, существует реальная угроза того, что SNTP мультикаст-клиент может быть введен в заблуждение поведением SNTP или NTP-серверов (возможно и преднамеренным), так как все они используют один и тот же групповой мультикаст-адрес, выделенный для этих целей IANA. Где необходимо, для выбора сервера, известного клиенту может проводиться отбор по адресу. Опционной является схема криптографической аутентификации, описанной в документе RFC-1305.

    3. Формат временных меток NTP

    Протокол SNTP использует стандартный формат временных меток NTP, описанный в документе RFC-1305 и в предыдущих версиях стандарта. Для согласования со стандартной практикой в Интернет данные NTP характеризуются целыми числами с фиксированной запятой. Биты нумеруются так, что нулевой (старший) разряд размещается слева. Если не оговорено обратного, все числа не имеют знака и занимают все выделенное для них поле.

    Так как временная метка NTP представляет собой наиважнейшую часть протокола, для нее разработан специальный формат. Временные метки NTP характеризуются 64-битным числом без знака с фиксированной запятой, которое равно количеству секунд с 0 часов 1 января 1900. Для целочисленной части выделено 32 бита и столько же для дробной части.

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

    Максимальное число, которое может быть представлено в данном формате равно 4,294,967,295 секунд с точностью порядка 200 пикосекунд, что может удовлетворить самым экзотическим требованиям.

    Рис. 4.4.16.1. Формат представления временной метки

    Заметим что с некоторого времени в 1968 (2,147,483,648 секунда) старший бит (бит 0 целочисленной части) стал равным 1 и 64-битовое поле переполнится в 2036 году. Если NTP или SNTP будут использоваться в 2036 г, будут необходимы некоторые внешние по отношению к данному протоколу меры для определения того относительно 1900 или 2036 года отсчитана приведенная дата (это справедливо и для других дат, кратных 136 годам).

    Так как формат временных меток NTP использовался в течение последних 17 лет, остается возможность того, что он будет использоваться еще 40 лет. Так как временных меток NTP до 1968 не существует, можно считать приемлемым, что при бите 0 равном 1, UTC-время лежит в диапазоне 1968-2036 с началом отсчета 0 час. 0 мин. 0 сек. 1 января 1900 г. Если же бит 0 равен нулю, время лежит в диапазоне 2036-2104 г., а UTC-время отсчитывается от 6 час. 28 мин. 16 сек. 7 февраля 2036. Заметим, что при этом вычислении 2000 год не считался високосным.

    4. Формат сообщений NTP

    Протоколы NTP и SNTP используют в качестве транспортного протокол UDP. При этом работает UDP-порт 123 (NTP), который проставляется как в поле порта отправителя, так и получателя UDP-заголовка.

    Ниже приводится описание формата сообщений NTP/SNTP v.4, которые размещаются после UDP-заголовка. Этот формат идентичен описанному в RFC-1305, за исключением содержимого поля идентификатора эталона (reference identifier). Поля заголовка представлены на рис. 4.4.16.2:

    Рис. 4.4.16.2. Формат заголовка SNTP-пакета

    Поле LI (Leap Indicator) содержит два бита кода предупреждения о добавлении/удалении секунды в последней минуте текущего дня. Значения кодов поля LI приведены в таблице 4.4.16.1:

    Таблица 4.4.16.1 Значения кодов поля LI

    LI

    Величина

    Значение

    00

    0

    предупреждения нет

    01

    1

    последняя минута содержит 61 секунду

    10

    2

    последняя минута содержит 59 секунд

    11

    3

    аварийный сигнал (часы не синхронизованы)

    Поле VN (Version Number - номер версии) имеет длину три бита и содержит номер версии протокола NTP/SNTP. Это поле содержит 3 для V.3 (только IPv4) и 4 для V.4 (IPv4, IPv6 и OSI).

    Поле режим также содержит три бита и указывает на код режима. Значения кодов режима представлены в таблице 4.4.16.2.

    Таблица 4.4.16.2. Значение кодов поля режим

    Режим

    Значение

    0

    зарезервировано

    1

    симметричный активный

    2

    симметричный пассивный

    3

    клиент

    4

    сервер

    5

    широковещательный

    6

    для управляющих сообщений NTP

    7

    зарезервировано для частного использования

    В уникастном и эникастном режиме клиент при запросе устанавливает это поле равным 3 (клиент), а сервер в отклике устанавливает его равным 4. В мультикастном режиме сервер записывает в данное поле код 5 (широковещательный).

    Поле слой (Stratum) содержит восемь бит, указывающих на уровень локальных часов. Значения кодов поля слой представлены в таблице 4.4.16.3.

    Таблица 4.4.16.3. Значения кодов поля слой (stratum)

    Слой

    Значение

    0

    не специфицирован или не доступен

    1

    первичный эталон (например, радио часы)

    2-15

    вторичный эталон (через NTP или SNTP)

    16-255

    зарезервировано на будущее

    Поле интервал запросов (Poll Interval - регистрация ) содержит 8 бит и указывает на максимальный интервал между последовательными сообщениями. Код (k) характеризует показатель степени 2. Интервал между запросами равен 2k секунд. Значения, которые могут появиться в этом поле лежат в диапазоне от 4 (16 сек) до 14 (16284 сек); однако большинство приложений использует субдиапазон от 6 (64 сек.) до 10 (1024 сек).

    Поле точность содержит 8 бит и характеризует точность локальных часов, в секундах (показатель степени 2, как и в предыдущем поле). Значения кодов в этом поле лежат в диапазоне -6 для частоты сети переменного тока до -20 для микросекундных часов.

    Поле Root Delay представляет собой 32-битовое число с фиксированной запятой, характеризующее RTT в секундах до эталона точного времени. Запятая в этом числе располагается между битами 15 и 16. Заметим, что эта переменная может быть положительной или отрицательной. Диапазон значений кодов этого поля лежит в диапазоне от минус нескольких миллисекунд до плюс нескольких сотен миллисекунд.

    Поле Root Dispersion представляет собой 32-битовое число без знака с фиксированной запятой, указывающее на номинальное значение временной ошибки относительно эталона в секундах. Разброс значений этого поля лежит в пределах от нуля до нескольких сот миллисекунд.

    Поле идентификатор эталона представляет собой 32-битовую строку, которая позволяет однозначно идентифицировать эталон времени. В случае первичных серверов (слой 0 или 1) NTP V.3 или V.4, идентификатор представляет собой четырех символьную ASCII-строку, размещенную в левой части поля. Свободная часть поля заполняется нулями. Для вторичных серверов NTP V.3, идентификатор равен 32-битовому адресу эталонного источника (IPv4). Для вторичных серверов NTP V.4, в качестве идентификатора используются младшие 32 бита последней временной метки эталонного источника. Первичные серверы NTP (слой 1) должны заносить в это поле коды, идентифицирующие внешние эталоны согласно таблице 4.4.16.4. Если код в таблице отсутствует, допускаются и другие коды.

    Таблица 4.4.16.4. Коды идентификатора эталона

    ID-код

    Внешний эталонный источник

    LOCL

    В качестве первичного эталона для субсети используются некалиброванные внутренние часы, которые не имеют внешнего источника синхронизации

    PPS

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

    ACTS

    Модемная служба NIST (работает через коммутируемую телефонную сеть)

    USNO

    Модемная служба USNO

    PTB

    Модемная служба PTB (Германия)

    TDF

    Радио 164 кГц (Allouis Франция)

    DCF

    Радио 77.5 кГц (Mainflingen, Германия)

    MSF

    Радио 60 кГц (Rugby, Англия)

    WWV

    Радио 2.5, 5, 10, 15, 20 МГц (Ft. Collins, США)

    WWVB

    Радио 60 кГц (Boulder, US)

    WWVH

    Радио 2.5, 5, 10, 15 МГц (Кауи Гавайи, США)

    CHU

    Радио 3330, 7335, 14670 кГц (Оттава, Канада)

    LORC

    Радионавигационная система LORAN-C

    OMEG

    Радионавигационная система OMEGA

    GPS

    Глобальная служба определения местоположения

    GOES

    Геостационарный спутник контроля за окружающей средой

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

    Поле Originate Timestamp (исходная временная метка) соответствует времени, когда клиент направил запрос серверу (64-битовый формат временной метки).

    Поле Receive Timestamp характеризует время, когда запрос пришел на сервер (64-битовый формат временной метки).

    Поле Transmit Timestamp соответствует времени, когда сервер послал отклик клиенту (64-битовый формат временной метки).

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

    Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code).

    5. Операции клиента SNTP

    Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.

    Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp . В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.

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

    Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.

    Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток.

    Таблица 4.4.16.5. Типы временных меток

    Имя временной метки

    ID

    Когда генерируется

    Originate Timestamp (исходная метка)

    T1

    Время отправки запроса клиента

    Receive Timestamp (метка получения)

    T2

    Время получения запроса сервером

    Transmit Timestamp (метка посылки)

    T3

    Время посылки отклика сервером

    Destination Timestamp (метка назначения)

    T4

    Время получения отклика клиентом

    Циклическая (roundtrip) задержка d и смещение локальных часов t определяются как:

    d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.

    В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы "Отклик" и "Мультикаст". Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой "Игнорируется", зависит от конкретной реализации программы.

    Таблица 4.4.16.6. Операции клиента и значения полей заголовка

    Имя поля

    Уникаст/Эникаст

    Мультикаст

    Запрос

    Отклик

    LI

    0

    0-2

    0-2

    VN (номер версии)

    1-4

    копируется из запроса

    1-4

    Режим

    3

    4

    5

    Слой

    0

    1-14

    1-14

    Запрос

    0

    Игнорируется

    Игнорируется

    Точность

    0

    Игнорируется

    Игнорируется

    Root Delay

    0

    Игнорируется

    Игнорируется

    Root Dispersion

    0

    Игнорируется

    Игнорируется

    Reference Identifier

    0

    Игнорируется

    Игнорируется

    Reference Timestamp

    0

    Игнорируется

    Игнорируется

    Originate Timestamp

    0

    (смотри текст)

    Игнорируется

    Receive Timestamp

    0

    (смотри текст)

    Игнорируется

    Transmit Timestamp

    (смотри текст)

    не равно нулю

    не равно нулю

    Аутентификатор

    опционно

    опционно

    опционно

    6. Операции сервера SNTP

    Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

    В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.

    Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме.

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

    Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой - 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.

    Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса. В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.

    Таблица 4.4.16.7

    Имя поля

    Уникаст/Эникаст

    Мультикаст

    Запрос

    Отклик

    LI

    игнорируется

    0 или 3

    0 или 3

    VN

    1-4

    копия из запроса

    4

    Режим

    3

    2 или 4

    5

    Слой

    игнорируется

    1

    1

    Регистрация

    игнорируется

    копия из запроса

    log2 периода запросов

    Точность

    игнорируется

    -log2 числа значащих бит сервера

    -log2 числа значащих бит сервера

    Root Delay

    игнорируется

    0

    0

    Root Dispersion

    игнорируется

    0

    0

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

    игнорируется

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

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

    Reference Timestamp

    игнорируется

    время последней коррекции по радио-часам

    время последней коррекции по радио-часам

    Originate Timestamp

    игнорируется

    копируется из поля transmit timestamp

    0

    Receive Timestamp

    игнорируется

    время дня

    0

    Transmit Timestamp

    (см. текст)

    время дня

    время дня

    Аутентификатор

    опционно

    опционно

    опционно

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

    7. Конфигурация и управление

    Исходная конфигурация SNTP серверов и клиентов может быть произведена на основе конфигурационного файла, если такой файл имеется, или через последовательный порт. Предполагается, что SNTP серверы и клиенты практически не требуют какого-то конфигурирования, специфического для данного узла (помимо IP-адреса, маски субсети или адреса OSI NSAP).

    Уникастные клиенты должны быть снабжены именем сервера или его адресом. Если используется имя сервера, то необходим один или несколько адресов ближайших DNS-серверов. Мультикастные серверы и эникастные клиенты должны снабжаться значением TTL, а также местным широковещательным или групповым мультикастным адресом. Эникастные серверы и мультикастные клиенты могут конфигурироваться с привлечением списков пар адрес-маска. Это обеспечивает контроль доступа, так что операции будут производиться только с известными клиентами или серверами. Эти серверы и клиенты должны поддерживать протокол IGMP, а также знать местный широковещательный или групповой мультикастный адрес.

    Существует несколько сценариев, которые помогают обнаружить и выбрать сервер для SNTP клиента без предварительной конфигурации (IP-адрес и маска субсети предполагается известной). Для IP-субсети или сегмента LAN, содержащих работающий NTP-сервер клиент может быть сконфигурирован для мультикастного режима, используя местный широковещательный адрес. Тот же подход может быть применен для других серверов, используя групповой мультикастинг-адрес. В обоих случаях предоставление списка адресов-масок серверов является желательным.

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

    В еще одном сценарии, удобном для любой сети, где мультикастные услуги недоступны, DNS может быть сконфигурирована с одним CNAME, аналогично time.domain.net, и списком адресных записей для серверов NTP в домене. Используя адрес time.domain.net и получив список, клиент выбирает сервер и начинает с ним работу в уникастном режиме.

    8. Ссылки

    [COL94]

    Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.

    [DAR81]

    Postel, J., "Internet Protocol", STD 5, RFC 791, USC Information Sciences Institute, September 1981.

    [DEE89]

    Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989.

    [DEE96]

    Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox and Ipsilon, January 1996.

    [DOB91]

    Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, Open Software Foundation, June 1991.

    [EAS95]

    Eastlake, D., 3rd., and C. Kaufman, "Domain Name System Security Extensions", Work in Progress.

    [FUR94]

    Furniss, P., "Octet sequences for upper-layer OSI to support basic communications applications", RFC 1698, Consultant, October 1994.

    [HIN96]

    Hinden, R., and S. Deering, "IP Version 6 addressing Architecture", RFC 1884, Ipsilon and Xerox, January 1996.

    [ISO86]

    International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.

    [MIL92]

    Mills, D., "Network Time Protocol (V.3) specification, implementation and analysis", RFC 1305, University of Delaware, March 1992.

    [PAR93]

    Partridge, C., T. Mendez and W. Milliken, "Host anycasting service", RFC 1546, Bolt Beranek Newman, November 1993.

    [POS80]

    Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC Information Sciences Institute, August 1980.

    [POS83]

    Postel, J., "Time Protocol", STD 26, RFC 868, USC Information Sciences Institute, May 1983.

    Previous: 4.4.15 Сетевой протокол времени NTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.17 Введение в MPLS, TE и QoS


    previous up down next index index
    Previous: 4.3.7 Модемы    UP: 4.3 Региональные сети
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.1 IP-протокол

    4.4 Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.4 Интернет

    3

    2

    4.4.1 IP-протокол

    10

    91

    4.4.2 Протокол UDP

    7

    5

    4.4.3 Протокол TCP

    15

    135

    4.4.4 Протокол передачи команд и сообщений об ошибках (ICMP)

    10

    93

    4.4.5 Протокол XTP

    10

    103

    4.4.6 Протокол преобразования адресов ARP

    4

    141

    4.4.7 Прокси-ARP

    1

    11

    4.4.8 Протокол обратного адресного преобразования RARP

    1

    13

    4.4.9 Протокол IGMP

    3

    20

    4.4.10 Протокол загрузки BOOTP

    3

    30

    4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

    10

    86

    4.4.12 DNS (структура, обработка запросов, ресурсные записи)

    15

    100

    4.4.13 Протокол управления SNMP

    6

    52

    4.4.14 Протокол электронной почты SMTP

    5

    39

    4.4.15 Сетевой протокол времени NTP

    47

    190

    4.4.16 Протокол SNTP

    11

    68

    4.4.17 Введение в MPLS, TE и QoS

    15

    150

    4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

    40

    250

    4.4.19 Кодирование меток в MPLS

    12

    67

    4.4.20 Требования для управления трафиком

    18

    92

    4.4.21 BGP/MPLS VPN

    18

    78

    Виртуальная сеть виртуальных сетей - Интернет является самой большой и самой популярной сетью. Можно смело утверждать, что эта сеть сохранит это лидерство в ближайшие годы. Привлекательность сети не только в том, что это единая среда общения людей, находящихся в разных странах и на разных континентах. Интернет предоставляет все более широкий спектр услуг. Это и информационно-поисковые системы, телефония, аудио и видео письма, доставляемые за считанные секунды в любую точку мира (где имеется Интернет), видеоконференции, электронные журналы, службы новостей, дистанционное обучение, банковские операции и многое, многое другое. Интернету предстоит мучительная процедура перехода на 128-битовые адреса (IPv6), но по ее завершении можно ожидать дальнейшего расширения списка услуг. Уже сегодня Интернет стал средой, предоставляющей возможность целевой рекламы и дистанционной торговли. Уже в начале следующего века сети станут самым мощным средством массовой информации. Но для решения всех этих проблем в этой сфере еще очень много надо сделать. Современные поисковые системы, несмотря на впечатляющие успехи, требуют существенного улучшения эффективности, много надо сделать для того, чтобы Интернет пришел в каждую квартиру.

    Сегодня Интернет использует многие десятки протоколов. Если сюда добавить протоколы физического уровня, то их число превысит сотню. На уровне локальных сетей наиболее распространены различные разновидности Ethernet, а также Token Ring и некоторые другие. Особенно велико разнообразие протоколов межсетевого обмена. Здесь помимо PPP используется FDDI, X.25, ISDN, ATM, SDH, Fibre Channel и пр.. На транспортном уровне в Интернет работают протоколы UDP (без установления соединения) и TCP (с установлением соединения). Это два принципиально разных подхода к передаче данных. В обоих случаях и передатчик и приемник имеют индивидуальные IP-адреса и порты. Но в случае TCP они ассоциируются в соединители (socket) - две пары IP-адрес-порт и прием/передача в рамках одной сессии происходит по схеме точка-точка. Для UDP же допускается возможность передачи одновременно нескольким приемникам (мультикастинг) и прием данных от нескольких передатчиков в рамках одной и той же сессии. Протокол TCP используется для поточной передачи данных, при которой доставка гарантируется на протокольном уровне. Это обеспечивается обязательным подтверждением получения каждого пакета TCP. Напротив, протокол UDP не требует подтверждения получения. В этом случае, как правило, исключается также и фрагментация пакетов, так как пакеты при схеме без установления соединения никак не связаны между собой. По этим причинам UDP в основном служит для передачи мультимедийных данных, где важнее своевременность, а не надежность доставки. Протокол TCP используется там, где важна надежная, безошибочная доставка информации (файловый обмен, передача почтовых сообщений и WEB-технология).

    Схема без установления соединения привлекательна также тем, что позволяет при передаче данных от исходного источника к большому числу приемников минимизировать общий трафик. Если бы для этой цели использовался протокол TCP, то при N приемниках надо было бы сформировать N виртуальных каналов и транспортировать N идентичных пакетов (рис. 4.4.1). В случае UDP от передатчика до точки разветвления передается только один пакет, что уменьшает загрузку данного участка в N раз (рис. 4.4.2). Причем аналогичная экономия может быть реализована и по пути к очередной точке разветвления (смотри описание протокола мультикастинг-маршрутизации PIM).

    Рис.4.4.1

    Рис. 4.4.2.

    В примере на рисунке 4.4.2 на участке 1 снижение трафика по сравнению с традиционным методом передачи данных происходит в 8 раз, на участке 2 - в 4 раза, а на сегментах 3 - в два раза.

    Все множество протоколов Интернет можно поделить на две группы. К первой относятся те, что имеют собственный стандарт на формат пакетов (IP, UDP, TCP, ARP, RARP, RTP, RIP, OSPF, BGP, IGRP, ICMP, SNMP, DNS, PIM, IGMP, BOOTP, IPX/SPX, AAL и др.). Вторую группу образуют протоколы, которые формализуют обмен на уровне сообщений. Они не имеют своих форматов на пакеты, а стандартизуют лишь форму сообщений и алгоритм обмена. Вторая группа использует для передачи своих сообщений протоколы первой группы. К этой группе относятся SMTP, NTP, POP, IMAP, FTP, HTTP, RSVP, Telnet, Finger, NNTP, Whois, SET, SSL и т.д. По существу, вторая группа располагается на прикладном уровне. Первая группа более консервативна и достаточно хорошо структурирована, вторая - динамична и постоянно расширяется. Ко второй группе примыкают некоторые стандартизованные утилиты типа ping, traceroute, а также поисковые системы. В перспективе на подходе протоколы для интерфейсов баз данных и мультимедиа. Особняком стоят алгоритмы обеспечения безопасности.

    Previous: 4.3.7 Модемы    UP: 4.3 Региональные сети
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.1 IP-протокол


    previous up down next index index
    Previous: 4.4.5 Протокол XTP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.7 Прокси-ARP

    4.4.6 Протокол преобразования адресов ARP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Любое устройство, подключенное к локальной сети (Ethernet, FDDI и т.д.), имеет уникальный физический сетевой адрес, заданный аппаратным образом. 6-байтовый Ethernet-адрес выбирает изготовитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресного пространства. Если у машины меняется сетевой адаптер, то меняется и ее Ethernet-адрес.

    4-байтовый IP-адрес задает менеджер сети с учетом положения машины в сети Интернет. Если машина перемещается в другую часть сети Интернет, то ее IP-адрес должен быть изменен. Преобразование IP-адресов в сетевые выполняется с помощью arp-таблицы. Каждая машина сети имеет отдельную ARP-таблицу для каждого своего сетевого адаптера. Не трудно видеть, что существует проблема отображения физического адреса (6 байт для Ethernet) в пространство сетевых IP-адресов (4 байта) и наоборот.

    Протокол ARP (address resolution protocol, RFC-826) решает именно эту проблему - преобразует ARP- в Ethernet-адреса.

    Рассмотрим процедуру преобразования адресов при отправлении сообщения. Пусть прикладная программа одной ЭВМ отправляет сообщение другой. Прикладной программе IP-адрес места назначения обычно известен. Для определения Ethernet-адреса просматривается ARP-таблица. Если для требуемого IP-адреса в ней присутствует Ethernet-адрес, то формируется и посылается соответствующий пакет. Если же с помощью ARP-таблицы не удается преобразовать адрес, то выполняется следующее:

    1. Всем машинам в сети посылается пакет с ARP-запросом (с широковещательным Ethernet-адресом места назначения).
    2. Исходящий IP-пакет ставится в очередь.

    Каждая машина, принявшая ARP-запрос, в своем ARP-модуле сравнивает собственный IP-адрес с IP-адресом в запросе. Если IP-адрес совпал, то прямо по Ethernet-адресу отправителя запроса посылается ответ, содержащий как IP-адрес ответившей машины, так и ее Ethernet-адрес. После получения ответа на свой ARP-запрос машина имеет требуемую информацию о соответствии IP и Ethernet-адресов, формирует соответствующий элемент ARP-таблицы и отправляет IP-пакет, ранее поставленный в очередь. Если же в сети нет машины с искомым IP-адресом, то ARP-ответа не будет и не будет записи в ARP-таблицу. Протокол IP будет уничтожать IP-пакеты, предназначенные для отправки по этому адресу.

    Протоколы верхнего уровня не могут отличить случай повреждения в среде ethernet от случая отсутствия машины с искомым IP-адресом. Во многих реализациях в случае, если IP-адрес не принадлежит локальной сети, внешний порт сети (gateway) или маршрутизатор откликается, выдавая свой физический адрес (режим прокси-ARP).

    Функционально, ARP делится на две части. Одна - определяет физический адрес при посылке пакета, другая отвечает на запросы других машин. ARP-таблицы имеют динамический характер, каждая запись в ней "живет" определенное время после чего удаляется. Менеджер сети может осуществить запись в ARP-таблицу, которая там будет храниться "вечно". ARP-пакеты вкладываются непосредственно в ethernet-кадры. Формат arp-пакета показан на рис. 4.4.6.1.

    Рис. 4.4.6.1. Формат пакета ARP

    HA-Len - длина аппаратного адреса; PA-Len - длина протокольного адреса (длина в байтах, например, для IP-адреса PA-Len=4). Тип оборудования - это тип интерфейса, для которого отправитель ищет адрес; код содержит 1 для Ethernet. Ниже представлена таблица 4.4.6.1 кодов оборудования.

    Таблица 4.4.6.1. Коды оборудования

    Код типа оборудования

    Описание

    1

    Ethernet (10 Мбит/с)

    2

    Экспериментальный Ethernet (3 Мбит/с)

    3

    Радиолюбительская связь через X.25

    4

    Proteon ProNET маркерная кольцевая сеть (Token Ring)

    5

    Chaos

    6

    Сети IEEE 802

    7

    ARCNET

    Таблица 4.4.6.2. Коды протоколов (для IP это 0800H).

    Код типа протокола

    Описание

    Десятичное значение

    Hex

    512

    0200

    XEROX PUP

    513

    0201

    PUP трансляция адреса

    1536

    0600

    XEROX NS IDP

    2048

    0800

    DOD Internet протокол (IP)

    2049

    0801

    X.75 Internet

    2050

    0802

    NBS Internet

    2051

    0803

    ECMA Internet

    2052

    0804

    Chaosnet

    2053

    0805

    X.25 уровень 3

    2054

    0806

    Протокол трансляции адреса (ARP)

    2055

    0807

    XNS совместимость

    2560

    0A00

    Xerox IEEE-802.3 PUP

    4096

    1000

    Bercley Trailer

    21000

    5208

    BBN Simnet

    24577

    6001

    DEC MOP Dump/Load

    24578

    6002

    DEC MOP удаленный терминал

    24579

    6003

    DEC DECnet фаза IV

    24580

    6004

    DEC LAT

    24582

    6005

    DEC

    24583

    6006

    DEC

    32773

    8005

    HP Probe

    32784

    8010

    Excelan

    32821

    8035

    Реверсивный протокол ARP (RARP)

    32824

    8038

    DEC LANbridge

    32923

    8098

    Appletalk

    33100

    814C

    SNMP

    Поле код операции определяет, является ли данный пакет ARP-запросом (код = 1), ARP-откликом (2), RARP-запросом (3), или RARP-откликом (4). Это поле необходимо, как поле тип кадра в Ethernet пакетах, они идентичны для ARP-запроса и отклика.

    ARP-таблицы строятся согласно документу RFC-1213 и для каждого IP-адреса содержит четыре кода:

    ifindex

    Физический порт (интерфейс), соответствующий данному адресу;

    Физический адрес

    MAC-адрес, например Ethernet-адрес;

    IP-адрес

    IP-адрес, соответствующий физическому адресу;

    тип адресного соответствия

    это поле может принимать 4 значения: 1 - вариант не стандартный и не подходит ни к одному из описанных ниже типов; 2 - данная запись уже не соответствует действительности; 3 - постоянная привязка; 4 - динамическая привязка;

    В SUN и некоторых других ЭВМ имеется программа arp, которая позволяет отобразить ARP-таблицу на экране. С флагом -a команда отображает всю таблицу, флаг -d позволяет стереть запись, а -s - служит для внесения записей в таблицу (последние два флага доступны для операторов с системными привилегиями). Команда ARP без флагов с адресом или именем ЭВМ выдаст соответствующую строку таблицы:

    arp 192.148.166.129
    Name: semenov.itep.ru
    Address: 192.148.166.129 (IP-адрес моей персональной ЭВМ)
    Aliases: yas
    А команда
    arp nb
    выдаст запись
    nb (193.124.224.60) at 0:80:ad:2:24:b7 (запись для NetBlazer ИТЭФ)

    ARP запросы могут решать и другие задачи. Так при загрузке сетевого обеспечения ЭВМ такой запрос может выяснить, а не присвоен ли идентичный IP-адрес какому-то еще объекту в сети. При смене физического интерфейса такой запрос может инициировать смену записи в ARP-таблице.

    Previous: 4.4.5 Протокол XTP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.7 Прокси-ARP


    previous up down next index index
    Previous: 4.4.11.7 Маршрутная политика    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)

    4.4.11.8 Язык описания маршрутной политики RPSL
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1. Введение

    Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации.

    Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.

    Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set).

    Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4].

    Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5].

    2. Имена, зарезервированные слова и представления RPSL

    Каждый класс имеет набор атрибутов, где записывается некоторая информация об объектах класса. Атрибуты могут быть обязательными и опционными. Обязательный атрибут должен быть определен для всех объектов класса. Опционный атрибут может отсутствовать. Атрибуты могут быть одно- и многозначными. Каждый объект однозначно идентифицируется набором атрибутов класса "key".

    Значение любого атрибута имеет определенный тип. Язык RPSL не чувствителен к тому, в каком регистре записаны те или иные выражения. Далее перечислены наиболее часто используемые типы атрибутов.

    Многие объекты в RPSL имеют имя. <object-name> составляется из букв, чисел, а также символов подчеркивания ("_") и дефисов ("-"), первым символов всегда должна быть буква, а последним символом - буква или цифра. Следующие слова зарезервированы в RPSL, и не могут использоваться в качестве имен:

    any as-any rs-any peeras
    and or not
    atomic from to at action accept announce except refine
    networks into inbound outbound

    Имена, начинающиеся с определенных префиксов зарезервированы для определенных типов объектов. Имена, начинающиеся с "as-" зарезервированы для имен автономных систем. Имена, начинающиеся с "rs-" зарезервированы для набора имен маршрутов. Имена, начинающиеся с "rtrs-" зарезервированы для набора имен маршрутизаторов. Имена, начинающиеся с "fltr-" зарезервированы для набора имен фильтров. Имена, начинающиеся с "prng-" зарезервированы для набора имен партнеров.

    <as-number>

    Номер AS x представляется в виде строки "ASx". То есть автономная система 226 характеризуется с помощью AS226.

    <ipv4-address>

    Адрес IPv4 характеризуется последовательностью из четырех целых чисел, лежащих в диапазоне от 0 до 255, разделенные символом точка ".". Например, 192.148.166.48.

    <address-prefix>

    Адресный префикс представляет собой IPv4-адрес, за которым следует символ косой черты "/" и без пробела целое число, лежащее в диапазоне 0-32. Примерами адресных префиксов могут служить:

    192.224.128.5/32, 192.148.0.0/16, 0.0.0.0/0. Следующие адресные префиксы являются неверными: 0/0, 192.10/16, так как 0 или 192.10 не являются строками, содержащими четыре целые числа.

    <address-prefix-range>

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

    ^-

    оператор значений "больше, исключая". Он служит для выделения адресных префиксов больше указанного, но исключая пограничное значение префикса. Например, 128.9.0.0/16^- содержит все префиксы больше 128.9.0.0/16, исключая значение 128.9.0.0/16.

    ^+

    оператор значений "больше, включая". Он служит для выделения адресных префиксов больше указанного, включая пограничное значение префикса. Например, 5.0.0.0/8^+ содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8.

    ^n

    где n целое, выделяет из адресного префикса все значения с длиной n. Например, 30.0.0.0/8^16 содержит все префиксы более 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16.

    ^n-m

    где n и m целые числа, выделяет из адресного префикса все значения с длинами в интервале от n до m. Например, 30.0.0.0/8^24-32 содержит все значения из префикса 30.0.0.0/8, которые имеют длины в интервале 24-32, такие как 30.9.9.96/28.

    Операторы диапазона могут применяться для наборов адресных префиксов. Например, для набора маршрутов rs-foo, rs-foo^+ (определенный ниже) содержит все специфические данные о префиксах в rs-foo.

    Применение двух операторов диапазона последовательно является ошибкой (напр. 30.0.0.0/8^24-28^+ - ошибка). Однако оператор диапазона может быть применен к набору адресных префиксов, содержащий диапазоны адресных префиксов (напр. {30.0.0.0/8^24-28}^27-30 не является ошибкой). В этом случае, внешний оператор ^n-m располагается над внутренним оператором ^k-l и становится оператором ^max(n,k)-m, если m больше или равно max(n,k), в противном случае префикс удаляется из набора. Заметим, что оператор ^n эквивалентен ^n-n. Префикс/l^+ эквивалентен префиксу prefix/l^l-32. Префикс/l^- эквивалентен префиксу prefix/l^(l+1)-32. Префикс {prefix/l^n-m}^+ эквивалентен префиксу {prefix/l^n-32}, а префикс {prefix/l^n-m}^- эквивалентен префиксу {prefix/l^(n+1)-32}. Например,

    {128.9.0.0/16^+}^-

    == {128.9.0.0/16^-}

    {128.9.0.0/16^-}^+

    == {128.9.0.0/16^-}

    {128.9.0.0/16^17}^24

    == {128.9.0.0/16^24}

    {128.9.0.0/16^20-24}^26-28

    == {128.9.0.0/16^26-28}

    {128.9.0.0/16^20-24}^22-28

    == {128.9.0.0/16^22-28}

    {128.9.0.0/16^20-24}^18-28

    == {128.9.0.0/16^20-28}

    {128.9.0.0/16^20-24}^18-22

    == {128.9.0.0/16^20-22}

    {128.9.0.0/16^20-24}^18-19

    == {}

    /TR>

    <date>

    Дата представляется в виде восьми десятичных цифр вида YYYYMMDD, где YYYY отображает год, MM представляет месяц (01 - 12) и DD характеризует день месяца (01 - 31). Все даты, если не определено что-то иное, задаются в стандарте UTC. Например, 07 июля 1938 представляется в виде 19380707.

    <email-address>

    описано в RFC-822 [10].

    <dns-name>

    описано в RFC-1034 [17].

    <nic-handle>

    представляет собой уникальный идентификатор, используемый при маршрутизации, присвоении адресов и т.д. для того, чтобы обеспечить однозначную ссылку на контактную информацию. Классы person и role связывают указатели NIC с действительными именами людей и контактной информацией.

    <free-form>

    представляет собой последовательность ASCII-символов.

    <X-name>

    является именем объекта типа X. То есть <mntner-name> является именем объекта mntner.

    <registry-name>

    является именем регистратора IRR.

    Значением атрибута может быть также список одного из этих типов. Элементы списка отделяются друг от друга запятыми. Например, "AS1, AS2, AS3, AS4". Заметим, что значение-список ортогонально многозначности. Многозначный атрибут имеет более одного значения, каждое из которых может быть, а может и не быть списком. С другой стороны однозначный атрибут может иметь значение-список. Объект RPSL текстуально представляется в виде списка пар атрибут-значение. Каждая пара атрибут-значение записывается на отдельной строке. Имя атрибута начинается с колонки 0 и завершается двоеточием. Далее следует значение атрибута. Атрибут, который имеет то же имя, что и класс объекта должен быть специфицирован раньше. Представление объекта завершается пустой строкой. Значение атрибута может занимать несколько строк, для этого очередная строка должна начинаться с символа пробел, табулятор или знак плюс ('+'). Символ "+" для строки продолжения позволяет значениям атрибута содержать пустые строки. Порядок размещения пар атрибут-значение является существенным.

    Описание атрибута может содержать комментарий. Комментарий может размещаться где угодно в определении объекта, он начинается с символа "#" и завершается первым же символом перехода на новую строку.

    Целые числа могут задаваться:

    1. в нотации языка программирования C (напр. 1, 12345),
    2. в виде последовательности четырех одно-октетных целых чисел (в диапазоне 0-255), разделенных символом точка "." (например, 1.1.1.0, 255.255.0.0), в этом случае 4-октетное целое образуется объединением этих однооктетных целых чисел, начиная с наиболее значимых,
    3. в виде двух 2-октетных целых чисел (в диапазоне 0 - 65535), разделенных символом двоеточие ":" (например, 3561:70, 3582:10), в этом случае 4-октетное целое число образуется путем объединения всех октетов в порядке их значимости.

    3. Контактная информация

    Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации.

    3.1. Класс mntner

    Класс mntner специфицирует аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать объекты RPSL. Провайдер прежде чем создавать RPSL-объект, должен создать объект mntner. Атрибуты класса mntner показаны на рис. .1. Класс mntner описан в [13].

    Атрибут mntner является обязательным и выполняет функцию ключа класса. Его значение - имя RPSL. Атрибут auth специфицирует схему, которая будет использоваться для идентификации и аутентификации запросов актуализации. Атрибут имеет следующий синтаксис:

    auth: <scheme-id> <auth-info>
    Например, auth: NONE

    Атрибут

    Значение

    Тип

    Mntner

    <object-name>

    обязательный, однозначный, ключ класса

    Descry

    <free-form>

    обязательный, однозначный

    Auth

    Смотри описание в тексте

    обязательный, многозначный

    upd-to

    <email-address>

    обязательный, многозначный

    mnt-nfy

    <email-address>

    опционный, многозначный

    tech-c

    <nic-handle>

    обязательный, многозначный

    admin-c

    <nic-handle>

    опционный, многозначный

    remarks

    <free-form>

    опционный, многозначный

    notify

    <email-address>

    опционный, многозначный

    mnt-by

    список <mntner-name>

    обязательный, многозначный

    changed

    <email-address> <date>

    обязательный, многозначный

    source

    <registry-name>

    обязательный, однозначный

    Рис. .1. Атрибуты класса mntner

    auth: CRYPT-PW dhjsdfhruewf
    auth: MAIL-FROM .*@ripe\.net

    В настоящее время для <scheme-id> определены значения: NONE, MAIL-FROM, PGP-KEY и CRYPT-PW. <auth-info> представляет дополнительную информацию, необходимую для конкретной схемы: в случае MAIL-FROM, это регулярное выражение, соответствующее корректному электронному почтовому адресу. В случае CRYPT-PW, это пароль в крипто-формате UNIX. В случае PGP-KEY, это указатель на объект key-certif [22], содержащий открытый ключ PGP-пользователя. Если специфицировано несколько атрибутов auth, запрос эксплуатационный актуализации, удовлетворяющий любому из них, будет аутентифицирован.

    Атрибут upd-to представляет собой электронный почтовый адрес. При неавторизованной попытке актуализации объекта, по этому адресу будет послано сообщение. Атрибут mnt-nfy также представляет собой почтовый адрес. При добавлении, изменении или удалении объекта по этому адресу посылается уведомляющее сообщение.

    Атрибут descr является коротким текстовым описанием объекта, выполненным в произвольной форме. Атрибут tech-c представляет собой контактный дескриптор NIC. Он используется при возникновении технических проблем, например, при неверной конфигурации. Атрибут admin-c представляет собой административный контактный дескриптор NIC. Атрибут remarks представляет собой текстовый комментарий или разъяснение. Атрибут notify представляет собой электронный адрес, куда следует отправлять уведомление об изменении этого объекта. Атрибут mnt-by является списком имен объектов mntner. Атрибут changed определяет, кто последний раз изменял данный объект, и когда это изменение было произведено. Его синтаксис имеет следующий формат:

    changed:
    Например
    changed: johndoe@terabit-labs.nn 19900401

    <email-address> идентифицирует человека, который внес последние изменения. <YYYYMMDD> представляет собой дату изменения. Атрибут source специфицирует реестр, где объект зарегистрирован. На рис. .2 показан пример объекта mntner. В этом примере использован криптографический формат UNIX для паролей аутентификации.

    mntner:

    RIPE-NCC-MNT

    descr:

    RIPE-NCC Maintainer

    admin-c:

    DK58

    tech-c:

    OPS4-RIPE

    upd-to:

    ops@ripe.net

    mnt-nfy:

    ops-fyi@ripe.net

    auth:

    CRYPT-PW lz1A7/JnfkTtI

    mnt-by:

    RIPE-NCC-MNT

    changed:

    ripe-dbm@ripe.net 19970820

    source:

    RIPE

    Рис. 2. Пример объекта mntner.

    Атрибуты descr, tech-c, admin-c, remarks, notify, mnt-by, changed и source являются атрибутами всех классов RPSL. Их синтаксис, семантика, а также статус mandatory (обязательный), optional (опционный), multi-valued (многозначный), или однозначный те же что и для всех классов RPSL. Единственным исключением является атрибут admin-c, который является обязательным для класса aut-num.

    3.2. Класс person

    Класс person используется для описания информации о людях. Хотя он не описывает маршрутную политику, его описание здесь приводится, так как многие объекты политики делают ссылки на конкретных людей. Класс person был впервые описан в [15].

    Атрибуты класса person представлены на рис. .3 Атрибут person представляет собой полное имя человека. Атрибуты phone и fax-no имеют следующий синтаксис:

    phone: +<country-code> <city> <subscriber> [ext. <extension>]
    Например:

    phone: +31 20 12334676

    Атрибут

    Значение

    Тип

    Person

    <free-form>

    обязательный, однозначный

    nic-hdl

    <nic-handle>

    обязательный, однозначный, ключ класса

    address

    <free-form>

    обязательный, многозначный

    phone

    См. описание в тексте

    обязательный, многозначный

    fax-no

    То же что и phone

    опционный, многозначный

    e-mail

    <email-address>

    обязательный, многозначный

    Рис. .3: Атрибуты класса person

    phone: +44 123 987654 ext. 4711

    На рис. .4 приведен пример объекта person.

    person:

    Daniel Karrenberg

    address:

    RIPE Network Coordination Centre (NCC)

    address:

    Singel 258

    address:

    NL-1016 AB Amsterdam

    address:

    Netherlands

    phone:

    +31 20 535 4444

    fax-no:

    +31 20 535 4445

    e-mail:

    Daniel.Karrenberg@ripe.net

    nic-hdl:

    DK58

    changed:

    Daniel.Karrenberg@ripe.net 19970616

    source:

    RIPE

    Рис. .4. Пример объекта person.

    3.3. Класс role

    Класс role подобен объекту person. Однако вместо описания человека он описывает роль, которую выполняет один или несколько человек. Примеры включают в себя консультационные пункты, центры сетевого мониторинга, системных администраторов и т.д. Объект role особенно полезен, так как человек, выполняющий роль, может быть заменен, а сама роль остается неизменной.

    Атрибуты класса role показаны на рис. .5. Атрибуты лиц nic-hdl и классы role используют совместно одно и то же пространство имен. Атрибут trouble объекта role может содержать дополнительную контактную информацию, которая может быть использована при возникновении проблемы в любом объекте, который ссылается на данный объект role. На рис. .6 показан пример объекта role.

    Атрибут

    Значение

    Тип

    Role

    <free-form>

    обязательный, однозначный

    nic-hdl

    <nic-handle>

    обязательный, однозначный, ключ класса

    trouble

    <free-form>

    опционный, многозначный

    address

    <free-form>

    обязательный, многозначный

    phone

    see description in text

    обязательный, многозначный

    fax-no

    same as phone

    опционный, многозначный

    e-mail

    <email-address>

    обязательный, многозначный

    Рис. .5. Атрибуты класса role

    role:

    RIPE NCC Operations

    trouble:

    address:

    Singel 258

    address:

    1016 AB Amsterdam

    address:

    The Netherlands

    phone:

    +31 20 535 4444

    fax-no:

    +31 20 545 4445

    e-mail:

    ops@ripe.net

    admin-c:

    CO19-RIPE

    tech-c:

    RW488-RIPE

    tech-c:

    JLSD1-RIPE

    nic-hdl:

    OPS4-RIPE

    notify:

    ops@ripe.net

    changed:

    roderik@ripe.net 19970926

    source:

    RIPE

    Рис. .6. Пример объекта role.

    4. Класс route

    Каждый маршрут interAS (называемый также междоменным маршрутом), начинающийся в AS, специфицируется с помощью объекта route. Атрибуты класса route представлены на рис. .7. Атрибут route представляет собой адресный префикс маршрута, а атрибут origin является номером AS, где этот маршрут начинается. Пара атрибутов route и origin являются ключом класса.

    На рис. .8 представлены примеры четырех объектов route. Заметим, что последние два объекта route имеют один и тот же адресный префикс 128.8.0.0/16. Однако они являются различными объектами route, так как они начинаются в разных AS (то есть они имеют разные ключи).

    Атрибут

    Значение

    Тип

    Route

    <address-prefix>

    обязательный, однозначный, ключ класса

    Origin

    <as-number>

    обязательный, однозначный, ключ класса

    member-of

    список <route-set-names>
    см. раздел 5

    опционный, многозначный

    Inject

    см. раздел 8

    опционный, многозначный

    Components

    см. раздел 8

    опционный, однозначный

    aggr-bndry

    см. раздел 8

    опционный, однозначный

    aggr-mtd

    см. раздел 8

    опционный, однозначный

    export-comps

    см. раздел 8

    опционный, однозначный

    holes

    см. раздел 8

    опционный, многозначный

    Рис. 7: Атрибуты класса route

    route:

    128.9.0.0/16

    origin:

    AS226

    route:

    128.99.0.0/16

    origin:

    AS226

    route:

    128.8.0.0/16

    origin:

    AS1

    route:

    128.8.0.0/16

    origin:

    AS2

    Рис. .8. Объекты Route

    5. Классы Set

    При спецификации политики часто полезно определить наборы объектов. Для этих целей определены классы as-set, route-set, rtr-set, filter-set, and peering-set. Эти классы определяют именованный набор. Члены этих наборов могут быть специфицированы непосредственно путем перечисления их в определении набора, или косвенно, имея ссылки членов-объектов на имена наборов. Допускается применение обоих методов.

    Имя набора является словом rpsl со следующими ограничениями. Все имена as-set начинаются с префикса "as-". Все имена route-set начинаются с префикса "rs-". Все наборы имен rtr-set начинаются с префикса "rtrs-". Все имена filter-set начинаются с префикса "fltr-". Все имена peering-set начинаются с префикса "prng-". Например, as-foo является корректным именем as-set.

    Имена наборов могут быть иерархическими. Имя иерархического набора представляет собой последовательность имен наборов и номеров AS, разделенных символом двоеточие ":". По крайней мере, одна компонента такого имени должна быть действительным именем набора (то есть начинается с одного из префиксов). Все компоненты имени набора иерархического имени должны иметь один и тот же тип. Например, следующие имена корректны: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.

    Целью имени иерархического набора является выделение определенного пространства имен, так что администратор набора X1 управляет всем набором нижележащих имен, то есть X1:...:Xn-1. Таким образом, набор объектов с именем X1:...:Xn-1:Xn может быть создан администратором объекта с именем X1:...:Xn-1. То есть, только администратор AS1 может создать набор с именем AS1:AS-FOO. Только администратор AS1:AS-FOO может создать набор с именем AS1:AS-FOO:AS-BAR.

    5.1. Класс as-set

    Атрибуты класса as-set показан на рис. .9. Атрибут as-set определяет имя набора. Он является именем RPSL, которое начинается с "as-". Атрибут members перечисляет членов набора. Атрибут members является списком AS, или других имен as-set.

    Атрибут

    Значение

    Тип

    as-set

    <object-name>

    обязательный, однозначный, ключ класса

    members

    список <as-numbers> или

    опционный, многозначный

    Mbrs-by-ref

    список <mntner-names>

    опционный, многозначный

    Рис. .9. Атрибуты класса as-set

    На рис. .10 представлены два объекта as-set. Набор as-foo содержит две AS, в частности AS1 и AS2. Набор as-bar содержит членов набора as-foo и AS3, т.е. он содержит AS1, AS2, AS3. Набор as-empty не содержит членов.

    as-set: as-foo

    as-set: as-bar

    as-set: as-empty

    members: AS1, AS2

    members: AS3, as-foo

    Рис. .10. Объекты as-set.

    Атрибут mbrs-by-ref представляет собой список имен администраторов (maintainer) или ключевое слово ANY. Если используется этот атрибут, набор AS включает также автономные системы, чьи объекты aut-num зарегистрированы одним из этих администраторов и чей атрибут member-of относится к имени этого набора AS. Если значение атрибута mbrs-by-ref равно ANY, любой объект AS, относящийся к набору, является членом этого набора. Если атрибут mbrs-by-ref пропущен, только AS, перечисленные в атрибуте members, являются членами набора.

    as-set: as-foo
    members: AS1, AS2
    mbrs-by-ref: MNTR-ME

    Aut-num: AS3

    Aut-num: AS4

    member-of: as-foo

    member-of: as-foo

    mnt-by: MNTR-ME

    mnt-by: MNTR-OTHER

    Рис. .11. Объекты as-set.

    На рис. .11 представлен пример объекта as-set, который использует атрибут mbrs-by-ref. Набор set as-foo содержит AS1, AS2 и AS3. AS4 не является членом набора as-foo не смотря на то, что объект aut-num ссылается на as-foo. Это происходит потому, что MNTR-OTHER отсутствует в списке атрибута as-foo mbrs-by-ref.

    5.2. Класс route-set

    Атрибуты класса route-set показаны на рис. .12. Атрибут route-set определяет имя набора. Он является именем RPSL, которое начинается с "rs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список адресных префиксов или других имен route-set. Заметим, что, класс route-set является набором префиксов маршрутов, а не маршрутных объектов RPSL.

    Атрибут

    Значение

    Тип

    route-set

    <object-name>

    обязательный, однозначный, ключ класса

    members

    список <address-prefix-range> или <route-set-name> или <route-set-name><range-operator>

    опционный, многозначный

    Mbrs-by-ref

    список <mntner-names>

    опционный, многозначный

    Рис. .12. Атрибуты класса route-set

    На рис. .13 приведены некоторые примеры объектов route-set. Набор rs-foo содержит два адресных префикса, в частности 128.9.0.0/16 и 128.9.0.0/24. Набор rs-bar содержит члены набора rs-foo и адресный префикс 128.7.0.0/16.

    За адресным префиксом или именем route-set в атрибуте members может опционно следовать оператор диапазона. Например, следующий набор:

    route-set: rs-foo
    members: 128.9.0.0/16, 128.9.0.0/24
    route-set: rs-bar
    members: 128.7.0.0/16, rs-foo

    Рис. .13. Объекты route-set

    route-set: rs-bar
    members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+

    содержат все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 30.0.0.0/8, чья длина лежит в пределах 24 - 32, такие как 30.9.9.96/28, и все префиксы больше префиксов из маршрутного набора rs-foo.

    Атрибут mbrs-by-ref представляет собой список имен администраторов и может содержать ключевое слово ANY. Если используется этот атрибут, маршрутный набор включает также префиксы, чьи маршрутные объекты зарегистрированы одним из администраторов, и чей атрибут member-of указывает на имя этого маршрутного набора. Если значение атрибута mbrs-by-ref равно ANY, любой объект, связанный с именем маршрутного набора, является его членом. Если атрибут mbrs-by-ref отсутствует, только адресные префиксы, перечисленные в атрибуте members, являются членами этого набора.

    route-set: rs-foo
    mbrs-by-ref: MNTR-ME, MNTR-YOU
    route-set: rs-bar
    members: 128.7.0.0/16
    mbrs-by-ref: MNTR-YOU
    route: 128.9.0.0/16
    origin: AS1
    member-of: rs-foo
    mnt-by: MNTR-ME
    route: 128.8.0.0/16
    origin: AS2
    member-of: rs-foo, rs-bar
    mnt-by: MNTR-YOU

    Рис. .14. Объекты route-set.

    На рис. 14 представлен пример объектов route-set, которые используют атрибут mbrs-by-ref. Набор rs-foo содержит два адресных префикса, в частности 128.8.0.0/16 и 128.9.0.0/16, так как маршрутные объекты для 128.8.0.0/16 и 128.9.0.0/16 отнесены к набору имен rs-foo в их атрибуте member-of. Набор rs-bar содержит адресные префиксы 128.7.0.0/16 и 128.8.0.0/16. Маршрут 128.7.0.0/16 представлен явно в атрибуте members rs-bar, а маршрутный объект для 128.8.0.0/16 связан с именем набора rs-bar в атрибуте member-of. Заметим, что если адресный префикс представлен в атрибуте маршрутного набора members, он является членом этого маршрутного набора. Маршрутный объект, соответствующий этому адресному префиксу не должен содержать атрибут member-of, относящийся к имени этого набора. Атрибут маршрутного класса member-of является дополнительным механизмом для косвенной спецификации членов набора.

    5.3. Объекты предопределенных наборов

    В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на рис. .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO.

    route-set: rs-special
    members: 128.9.0.0/16, AS1, AS2, AS-FOO

    Рис. .15. Использование номеров AS и маршрутных наборов.

    Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR.

    5.4. Класс Filters и filter-set

    Атрибуты класса filter-set представлены на рис. 16. Объект filter-set определяет набор маршрутов, которые соответствуют этому фильтру. Атрибут filter-set определяет имя фильтра. Он является именем RPSL, которое начинается с "fltr-".

    Атрибут

    Значение

    Тип

    filter-set

    <object-name>

    обязательный, однозначный, ключ класса

    filter

    <filter>

    обязательный, однозначный

    Рис. .16. Атрибуты класса filter

    filter-set: fltr-foo
    filter: { 5.0.0.0/8, 6.0.0.0/8 }
    filter-set: fltr-bar
    filter: (AS1 or fltr-foo) and

    Рис. .17. Объекты filter-set.

    Атрибут filter определяет фильтр политики для данного набора. Фильтр политики является логическим выражением, которое в случае приложения к набору маршрутов в качестве результата возвращает субнабор этих маршрутов. Считается, что фильтр политики соответствует возвращенному субнабору. Фильтр политики может соответствовать маршрутам, использующим любой атрибут BGP-прохода, такой как адресный префикс места назначения (или NLRI), AS-path, или атрибуты community.

    Фильтры политики могут составляться путем использования операторов AND, OR и NOT. Ниже представленные фильтры политики могут использоваться для селекции субнабора маршрутов:

    ANY

    Ключевое слово ANY соответствует всем маршрутам.

    Address-Prefix Set

    Это список адресных префиксов, заключенных в фигурные скобки '{' и '}'. Фильтр политики соответствует набору маршрутов, чей адресный префикс места назначения содержится в этом наборе. Например:

    { 0.0.0.0/0 }
    { 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }
    { }

    За адресным префиксом может опционно следовать оператор диапазона (то есть
    { 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }

    содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 128.9.0.0/16, исключая 128.9.0.0/16, все префиксы больше 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16, и все префиксы больше 30.0.0.0/8, которые имеют длину в диапазоне 24 - 32, такие как 30.9.9.96/28.

    Route Set Name

    Имя набора маршрутов соответствует набору маршрутов, которые являются членами набора. Имя набора маршрутов может быть именем объекта route-set, номером AS или именем объекта as-set (номера AS и имена as-set неявно определяют маршрутные наборы). Например:

    aut-num: AS1
    import: from AS2 accept AS2
    import: from AS2 accept AS-FOO
    import: from AS2 accept RS-FOO

    Ключевое слово PeerAS может использоваться вместо номера AS партнера. PeerAS является особенно полезным, когда партнерство охарактеризовано с помощью AS-выражения. Например:

    as-set: AS-FOO
    members: AS2, AS3

    aut-num: AS1
    import: from AS-FOO accept PeerAS

    то же самое, что и:

    aut-num: AS1
    import: from AS2 accept AS2
    import: from AS3 accept AS3

    За именем набора маршрутов может также следовать один из операторов '^-', '^+', например, { 5.0.0.0/8, 6.0.0.0/8 }^+ эквивалентно { 5.0.0.0/8^+, 6.0.0.0/8^+ } и AS1^- эквивалентно всем адресным префиксам, соответствующим маршрутам, исходящим из AS1.

    Регулярные выражения для проходов AS.

    Регулярное выражение AS-path может использоваться в качестве фильтра политики путем заключения его в угловые скобки `<' и `>'. Фильтр политики AS-path соответствует набору маршрутов, который проходит через последовательность AS, которая согласуется с регулярным выражением AS-path. Маршрутизатор может проверить это, используя атрибут AS_PATH в протоколе BGP [19], или атрибут RD_PATH в протоколе IDRP [18].

    Регулярное выражение формируется следующим образом:

    ASN

    где ASN является номером AS. ASN соответствует AS-path, который имеет длину равную 1 и содержит корректный номер AS (например, регулярное выражение AS-path AS1 соответствует AS-path "1"). Вместо номера AS-партнера может использоваться ключевое слово PeerAS.

    AS-set

    где AS-set является именем набора AS. AS-set соответствует AS-проходам, которые согласуются с одним из AS в AS-set.

    .

    соответствует AS-path, который согласуется с любым номером AS.

    [...]

    является набором номеров AS. Это выражение соответствует AS-path, согласующимся со списком номеров AS, записанных в скобках. Номера AS в наборе отделяются друг от друга пробелом или символом TAB (white space). Если между двумя номерами AS использован символ `-', в набор включаются все AS из этого диапазона. Если в список включено имя as-set, в набор войдут все номера AS as-set.

    [^...]

    является дополнением набора AS. Это выражение соответствует любому AS-path, который не соответствует набору номеров AS из приведенного набора.

    ^

    Соответствует пустой строке в начале AS-path.

    $

    Соответствует пустой строке в конце AS-path.

    Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо.

    Унарные постфиксные операторы * + ? {m} {m,n} {m,}

    Для регулярных выражений A, запись A* соответствует нулю или более использований A. A+ соответствует одному или более использованию A. A? соответствует нулю или одному использованию A. A{m} соответствует m использованиям A. A{m,n} соответствует от m до n использованиям A/, A{m,} соответствует m или более использованиям A. Например, [AS1 AS2]{2} соответствует AS1 AS1, AS1 AS2, AS2 AS1 и AS2 AS2.

    Унарные постфиксные операторы ~* ~+ ~{m} ~{m,n} ~{m,}

    Эти операторы имеют аналогичную функциональность, что и соответствующие операторы, перечисленные выше, но все включения регулярного выражения должны соответствовать одному образцу. Например, [AS1 AS2]~{2} соответствует AS1 AS1 и AS2 AS2, но не соответствует AS1 AS2 и AS2 AS1.

    Двоичный оператор объединения.

    Это неявный оператор, он вставляется между двумя регулярными выражениями A и B, когда не специфицирован другой оператор. Полученное выражение A B соответствует AS-path, если A соответствует некоторому префиксу AS-path, а B соответствует остальной части AS-path.

    Двоичный альтернативный оператор |

    Для регулярных выражений A и B, A | B соответствует любому AS-path, который соответствует A или B.

    Для изменения порядка действий, предусмотренного по умолчанию, можно использовать скобки. Для улучшения читаемости могут использоваться WS (пробел или символ TAB). Ниже приведены примеры фильтров AS-path:


    <^AS1>

    <^AS1 AS2 AS3$>
    <^AS1 .* AS2$>.

    Первый пример соответствует любому маршруту, чей AS-path содержит AS3, второй соответствует маршрутам, чьи AS-path начинаются с AS1, третий соответствует маршрутам, чьи AS-path заканчиваются AS2, четвертый соответствует маршрутам, чьи AS-path в точности равны "1 2 3", а пятый соответствует маршрутам, чьи AS-path начинаются в AS1 и заканчиваются в AS2 с любым числом промежуточных AS между ними.

    Составные фильтры политики.

    Последующие операторы могут использоваться при формировании составных фильтров политики.

    NOT

    Дан фильтр политики x, NOT x соответствует набору маршрутов, которые не соответствуют x. Таким образом он представляет отрицание фильтра политики x.

    AND

    Даны два фильтра политики x и y, x AND y соответствует пересечению множеств маршрутов, которые соответствуют как фильтру x так и фильтру y.

    OR

    Даны два фильтра политики x и y, x OR y соответствует объединению множеств маршрутов, которые соответствуют фильтру x или фильтру y. Заметим, что оператор OR может быть неявным, то есть `x y' эквивалентно `x OR y'. Например

    NOT {128.9.0.0/16, 128.8.0.0/16}
    AS226 AS227 OR AS228
    AS226 AND NOT {128.9.0.0/16}
    AS226 AND {0.0.0.0/0^0-18}

    Первый пример соответствует любому маршруту кроме 128.9.0.0/16 и 128.8.0.0/16. Второй пример соответствует маршрутам AS226, AS227 и AS228. Третий пример соответствует маршрутам AS226, исключая 128.9.0.0/16. Четвертый пример соответствует маршрутам AS226, чья длина не больше 18.

    Атрибуты фильтров политики могут использоваться для сравнения значения других атрибутов. Атрибуты, чьи значения могут применяться в фильтрах политики, специфицированы в словаре RPSL. Пример использования атрибута BGP community приведен ниже:

    aut-num: AS1
    export: to AS2 announce AS1 AND NOT community(NO_EXPORT)

    Фильтры, использующие атрибуты маршрутной политики, определенные в словаре, вычисляются до выполнения операторов AND, OR и NOT.

    Имя набора фильтров.

    Имя набора фильтров отвечает набору маршрутов, которые соответствуют их атрибуту фильтра. Заметим, что атрибут фильтра набора может рекурсивно связан с другими именами наборов фильтров. Например на рис. .17, fltr-foo соответствует {5.0.0.0/8, 6.0.0.0/8} и fltr-bar соответствует маршрутам AS1 или { 5.0.0.0/8, 6.0.0.0/8 }, если их путь содержит AS2.

    5.5. Класс rtr-set

    Атрибуты класса rtr-set представлены на рис. .18. Атрибут rtr-set определяет имя набора. Он является словом RPSL, которое начинается с "rtrs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список имен inet-rtr, ipv4_addresses или других имен rtr-set.

    Атрибут

    Значение

    Тип

    rtr-set

    <object-name>

    обязательный, однозначный, ключ класса

    members

    список <inet-rtr-names> или <rtr-set-names> или <ipv4_addresses>

    опционный, многозначный

    mbrsbyref

    список <mntnernames>

    опционный, многозначный

    Рис. .18. Атрибуты класса rtr-set

    На рис. .19 представлены два объекта rtr-set. Набор rtrs-foo содержит два маршрутизатора, в частности rtr1.isp.net и rtr2.isp.net. Набор rtrs-bar содержит членов набора rtrs-foo и rtr3.isp.net, то есть он содержит rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.

    rtr-set: rtrs-foo

    rtr-set: rtrs-bar

    members: rtr1.isp.net, rtr2.isp.net

    members: rtr3.isp.net, rtrs-foo

    Рис. .19. Объекты rtr-set.

    Атрибут mbrs-by-ref содержит список имен администраторов (maintainer) или ключевое слово ANY. Если использован этот атрибут, набор маршрутизаторов включает также маршрутизаторы, чьи объекты inet-rtr зарегистрированы одним из этих администраторов и чей атрибут member-of согласуется с именем этого набора маршрутизаторов. Если значение атрибута mbrs-by-ref равно ANY, любой объект inet-rtr соотносящийся набору маршрутизаторов, является членом этого набора. Если атрибут mbrs-by-ref отсутствует, только маршрутизаторы перечисленные в атрибуте members, являются членами набора.

    rtr-set: rtrs-foo
    members: rtr1.isp.net, rtr2.isp.net
    mbrs-by-ref: MNTR-ME
    inet-rtr: rtr3.isp.net
    local-as: as1
    ifaddr: 1.1.1.1 masklen 30
    member-of: rtrs-foo
    mnt-by: MNTR-ME

    Рис. .20. Объекты rtr-set.

    На рис. 20 представлен пример объекта rtr-set, который использует атрибут mbrs-by-ref. Набор rtrs-foo содержит rtr1.isp.net, rtr2.isp.net и rtr3.isp.net.

    5.6. Партнерство и класс peering-set

    Атрибуты класса peering-set представлены на рис. .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".

    Атрибут

    Значение

    Тип

    peering-set

    <object-name>

    обязательный, однозначный, ключ класса

    peering

    <peering>

    обязательный, многозначный

    Рис. .21. Атрибуты класса filter

    Атрибут peering определяет партнеров, которые могут быть использованы для импорта или экспорта маршрутных данных.

    Рис. .22. Пример топологии, состоящий из трех AS: AS1, AS2 и AS3, двух точек обмена: EX1 и EX2 и шести маршрутизаторов (IP[R1]= 1.1.1.1, IP[R2]= 2.2.2.1, IP[R3]= 1.1.1.2, IP[R4]= 1.1.1.3, IP[R5]= 2.2.2.2, IP[R6]= 2.2.2.3).

    При описании партнерства используется топология, показанная на рис. .22. В этой топологии имеется три автономные системы, AS1, AS2, and AS3; две точки обмена, EX1 и EX2, и шесть маршрутизаторов (R1-R6). Маршрутизаторы соединены с точками обмена. То есть, 1.1.1.1, 1.1.1.2 и 1.1.1.3 являются партнерами друг для друга, а 2.2.2.1, 2.2.2.2 и 2.2.2.3 - также партнеры друг для друга.

    Синтаксис спецификации партнерства:

    <as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name>

    где <as-expression> является выражением для номеров AS и наборов AS, использующих операторы AND, OR и EXCEPT, а выражения <router-expression-1> и <router-expression-2> являются функциями IP-адресов маршрутизаторов, имен inet-rtr, и имен rtr-set, использующих операторы AND, OR и EXCEPT. Двоичный оператор "EXCEPT" семантически эквивалентен комбинации "AND NOT". То есть "(AS1 OR AS2) EXCEPT AS2" эквивалентно "AS1".

    Эта форма идентифицирует всех партнеров между любым локальным маршрутизатором в <router-expression-2> и любыми маршрутизаторами в <router-expression-1> в автономных системах из <as-expression>. Если <router-expression-2> не специфицировано, это по умолчанию предполагает, что все маршрутизаторы локальной AS связаны с AS из <as-expression>.

    Если используется <peering-set-name>, партеры перечислены в соответствующем объекте peering-set. Заметим, что объекты peering-set могут быть рекурсивными.

    Возможны также многие специальные формы этой общей спецификации партнеров. Ниже приведенные примеры иллюстрируют наиболее общие случаи с использованием атрибута import класса aut-num. В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2.

    (1) aut-num: AS1
    import: from AS2 1.1.1.2 at 1.1.1.1 accept { 128.9.0.0/16 }

    В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

    (2) aut-num: AS1
    import: from AS2 at 1.1.1.1 accept { 128.9.0.0/16 }

    В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3, а 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2.

    (3) aut-num: AS1
    import: from AS2 accept { 128.9.0.0/16 }

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.

    (4) as-set: AS-FOO
    members: AS2, AS3

    aut-num: AS1
    import: from ASFOO

    at 9.9.9.1 accept { 128.9.0.0/16 }

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3, а 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

    (5) aut-num: AS1
    import: from AS-FOO accept { 128.9.0.0/16 }

    В следующем примере AS1 импортирует 128.9.0.0/16 из AS3 через маршрутизатор 9.9.9.1

    (6) aut-num: AS1
    import: from AS-FOO and not AS2 at not 1.1.1.1 accept { 128.9.0.0/16 }

    Это связано с тем, что "AS-FOO and not AS2" эквивалентно AS3 и "not 1.1.1.1" эквивалентно 9.9.9.1.

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.
    (7) peering-set: prng-bar peering: AS1 at 9.9.9.1
    peering-set: prng-foo
    peering: prng-bar
    peering: AS2 at 9.9.9.1

    aut-num: AS1
    import: from prng-foo accept { 128.9.0.0/16 }

    6. Класс aut-num

    Маршрутная политика специфицируется с использованием класса aut-num. Атрибуты класса aut-num представлены на рис. .23. Значение атрибута aut-num равно номеру AS, описанной данным объектом. Атрибут as-name является символическим именем (в рамках синтаксиса имен RPSL) AS. Импорт, экспорт и маршрутная политика по умолчанию AS специфицируются, используя атрибуты import, export и default, соответственно.

    Атрибут

    Значение

    Тип

    aut-num

    <as-number>

    обязательный, однозначный, ключ класса

    as-name

    <object-name>

    обязательный, однозначный

    member-of

    Список <as-set-names>

    опционный, многозначный

    import

    См. раздел 6.1

    опционный, многозначный

    export

    См. раздел 6.2

    опционный, многозначный

    default

    См. раздел 6.5

    опционный, многозначный

    Рис. .23. Атрибуты класса aut-num

    6.1. Атрибут import: Спецификация политики импорта

    В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:

    import:

    from <peering-1> [action <action-1>] . . .

    from <peering-N> [action <action-N>]

    accept <filter>

    Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются.

    Например
    aut-num: AS1
    import: from AS2 action pref = 1; accept { 128.9.0.0/16 }

    Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).

    6.1.1. Спецификация действия (Action)

    Действия политики в RPSL устанавливают или модифицируют атрибуты маршрутов, таких как предпочтение маршрута, добавляет атрибут BGP community или устанавливает атрибут MULTI-EXIT-DISCRIMINATOR. Действия политики могут также инструктировать маршрутизаторы по выполнению специальных операций, таких как гашение осцилляций маршрутов.

    Атрибуты маршрутной политики, чьи значения могут быть модифицированы посредством действий политики, специфицированы в словаре RPSL. Каждое действие при записи в RPSL завершаются символом точка с запятой (';'). Имеется возможность формировать составные действия политики путем последовательного их перечисления. В этом случае действия выполняются в порядке слева направо. Например,

    aut-num: AS1
    import: from AS2 action pref = 10; med = 0; community.append(10250, 3561:10);
    accept { 128.9.0.0/16 }

    устанавливает pref = 0, med = 0, и затем добавляет 10250 и 3561:10 к атрибуту прохода community BGP. Атрибут pref является инверсным по отношению к атрибуту local-pref (т.e. local-pref == 65535 - pref). Маршрут с атрибутом local-pref всегда предпочтительнее, чем без него.

    aut-num: AS1
    import: from AS2 action pref = 1;
    from AS3 action pref = 2;
    accept AS4

    Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 с предпочтением 1 и от AS3 с предпочтением 2 (маршруты с более низкими предпочтениями имеют больший приоритет, чем с большими значениями).

    aut-num: AS1
    import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;
    from AS2 action pref = 2;
    accept AS4

    Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 для направления 1.1.1.1-1.1.1.2 с предпочтением 1, а для любого другого направления от AS2 с предпочтением 2.

    6.2. Атрибут export: Спецификация экспортной политики

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

    export:

    to <peering-1> [action <action-1>]

    . . .

    to <peering-N> [action <action-N>]

    announce <filter>

    Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует <filter> пересылается всем партнерам, специфицированным в <peerings>, в то время как экспортируемые маршруты из <peering-M>, <action-M> реализуются.

    Например
    aut-num: AS1
    export: to AS2 action med = 5; community .= { 70 }; announce AS4

    В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.

    Пример:
    aut-num: AS1
    export: to AS-FOO announce ANY

    В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.

    6.3. Другие маршрутные протоколы, мультипротокольные маршрутные протоколы и обмен маршрутами между протоколами

    Более сложный синтаксис атрибутов import и export выглядит следующим образом:

    import: [protocol <protocol-1>] [into <protocol-2>]

    from <peering-1> [action <action-1>]

    . . .

    from <peering-N> [action <action-N>]

    accept <filter>

    export: [protocol <protocol-1>] [into <protocol-2>]

    to <peering-1> [action <action-1>]

    . . .

    to <peering-N> [action <action-N>]

    announce <filter>

    Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <protocol-1> является именем протокола, чьими маршрутами производится обмен. <protocol-2> представляет собой имя протокола, который принимает данные об этих маршрутах. Как <protocol-1> так и <protocol-2> являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP.

    aut-num: AS1
    import: from AS2 accept AS2
    export: protocol BGP4 into RIP to AS1 announce ANY

    В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.

    aut-num: AS1
    import: from AS2 accept AS2^+
    export: protocol BGP4 into OSPF to AS1 announce AS2

    В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.

    aut-num: AS1

    import:

    protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1);

    accept AS1:RS-STATIC-ROUTES

    В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2:

    aut-num: AS1
    import: from AS2 accept AS2
    import: protocol IDMR
    from AS2 accept AS2:RS-RPF-ROUTES

    6.4. Разрешение неопределенности

    Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики. Например:

    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 2;

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;

    accept AS4

    Это не ошибка, хотя такая запись определенно не желательна. Чтобы убрать неопределенность, используется действие (action), соответствующее первой спецификации партнерства. То есть маршруты воспринимаются с предпочтением, равным 2. Это правило называется правилом порядка спецификаций.

    Рассмотрим пример:

    aut-num: AS1

    import:

    from AS2 action pref = 2;

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5;

    accept AS4

    где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее:

    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1

    action pref = 1; dpa = 5;

    from AS2

    action pref = 2;

    accept AS4

    Допускается также, чтобы более чем одно выражение политики покрывало один и тот же набор маршрутов в рамках одного пиринга. Например:

    aut-num: AS1
    import: from AS2 action pref = 2; accept AS4
    import: from AS2 action pref = 1; accept AS4

    В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны:

    aut-num: AS1
    import: from AS2 action pref = 2; accept AS4
    import: from AS2 action pref = 1; accept AS4 OR AS5

    маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1.

    Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL. Рассмотрим два расширения политики:

    aut-num: AS1
    import: from peerings-1 action action-1 accept filter-1
    import: from peerings-2 action action-2 accept filter-2

    Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности:

    aut-num: AS1
    import: from peerings-1 action action-1 accept filter-1
    import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1
    import: from peerings-4 action action-2 accept filter-2

    где peerings-3 - это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 - набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1).

    Пример:
    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1

    action pref = 2;

    accept {128.9.0.0/16}

    import:

    from AS2

    action pref = 1;

    accept {128.9.0.0/16, 75.0.0.0/8}

    Рассмотрим два пиринга с AS2, 1.1.1.1-1.1.1.2 и 9.9.9.1- 2.2.2.2. Оба выражения политики покрывают 1.1.1.1-1.1.1.2. Для этого пиринга, маршрут 128.9.0.0/16 воспринимается с предпочтением 2, а маршрут 75.0.0.0/8 воспринимается с предпочтением 1. Пиринг 9.9.9.1-2.2.2.2 покрывается только вторым выражением политики. Следовательно, как маршрут 128.9.0.0/16 так и маршрут 75.0.0.0/8 воспринимаются с предпочтением 1 пирингом 9.9.9.1-2.2.2.2. Заметим, что аналогичное правило разрешения неопределенности применимо к выражениям политики по умолчанию и экспортной политики (рассылка маршрутной информации).

    6.5. Атрибут default. Спецификация политики по умолчанию

    Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:

    default: to <peering> [action <action>] [networks <filter>]

    Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию. Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>.

    В следующем примере, AS1 маршрутизируется по умолчанию через AS2.

    aut-num: AS1
    default: to AS2

    В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.

    aut-num: AS1
    default: to AS2 1.1.1.2 at 1.1.1.1

    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.

    aut-num: AS1
    default: to AS2 action pref = 1;
    default: to AS3 action pref = 2;

    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.

    aut-num: AS1
    default: to AS2 networks { 128.9.0.0/16 }

    6.6. Спецификация структурированной политики

    Политики импорта и экспорта (рассылки и приема маршрутной информации) могут быть структурированы. Применение структурированной политики рекомендуется для продвинутых пользователей RPSL. Синтаксис спецификации структурированной политики выглядит следующим образом:

    <import-factor> ::=

    from <peering-1> [action <action-1>]

    . . .

    from <peering-N> [action <action-N>]

    accept <filter>;

    <import-term> ::=

    <import-factor> |

    LEFT-BRACE

    <import-factor>

    . . .

    <import-factor>

    RIGHT-BRACE

    <import-expression> ::=

    <import-term>

    |

    <import-term> EXCEPT <import-expression>

    |

    <import-term> REFINE <import-expression>

    import:

    [protocol <protocol1>] [into <protocol2>]

    <import-expression>

    В конце <import-factor> должна быть точка с запятой. Если спецификация политики не структурирована эта точка с запятой является опционной. Синтаксис и семантика для <import-factor> определена в разделе 6.1. <import-term> представляет собой либо последовательность <import-factor>, заключенную в фигурные скобки, либо один <import-factor>. Семантика <import-term> заключается в объединении <import-factor> с использованием правила порядка спецификаций. <import-expression> представляет собой либо один <import-term>, либо <import-term>, за которым следуют ключевые слова "except" и "refine", с завершающим <import-expression>. Заметим, что данное определение допускает вложенные выражения. Следовательно, могут существовать исключения к исключениям, уточнения к уточнениям или даже уточнения к исключениям и т.д.

    Семантика для оператора except имеет вид. Результатом операции исключения является еще один член <import-term>. Результирующий набор политики содержит описание политики правой стороны, но его фильтры модифицированы так, что остаются только маршруты, соответствующие левой стороне. Политика левой стороны, в конце концов, включается, а ее фильтры модифицируются так, чтобы исключить маршруты, соответствующие левой стороне. Заметим, что фильтры модифицированы во время этого процесса, но действия скопированы один к одному. При нескольких уровнях вложения операции (принять или уточнить) выполняются справа налево.

    Рассмотрим следующий пример:

    import:

    from AS1 action pref = 1;

    accept as-foo;

    except

    {

    from AS2 action pref = 2;

    accept AS226;

    except

    {

    from AS3 action pref = 3;

    accept {128.9.0.0/16};

    }
    }

    где маршрут 128.9.0.0/16 порождается AS226, а AS226 является членом набора AS as-foo. В этом примере, маршрут 128.9.0.0/16 воспринят от AS3, любой другой маршрут (не 128.9.0.0/16) порожденный AS226 воспринимается от AS2, и любые другие маршруты AS из as-foo получены от AS1. Можно прийти к тому же заключению, используя алгебраические выкладки, определенные выше. Рассмотрим спецификацию внутреннего исключения:

    from AS2 action pref = 2; accept AS226;
    except { from AS3 action pref = 3; accept {128.9.0.0/16};}

    Эквивалентно

    { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};}

    Следовательно, исходное выражение эквивалентно:

    import:

    from AS1 action pref = 1; accept as-foo;

    except { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};

    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; }

    который эквивалентен

    import:

    { from AS3 action pref = 3;

    accept as-foo AND AS226 AND {128.9.0.0/16};

    from AS2 action pref = 2;

    accept as-foo AND AS226 AND NOT {128.9.0.0/16};

    from AS1 action pref = 1;

    accept as-foo AND NOT

    (AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); }

    Так как AS226 находится в as-foo и 128.9.0.0/16 заключен в AS226, выражение упрощается:

    import:

    {

    from AS3 action pref = 3; accept {128.9.0.0/16};

    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};

    from AS1 action pref = 1; accept as-foo AND NOT AS226;

    }

    В случае оператора refine, результирующий набор формируется с помощью декартова произведения для двух сторон следующим образом. Для каждой политики l левой стороны и для каждой политики r правой стороны, пиринг результирующей политики является пересечением множеств пирингов r и l. Фильтр результирующей политики соответствует пересечению фильтров l и r. Действие результирующей политики есть действие l, за которым следует действие r. Если общие пиринги отсутствуют, или если множество пересечения фильтров является пустым, результирующая политика не формируется. Рассмотрим следующий пример:

    import:

    { from AS-ANY action pref = 1; accept community(3560:10);

    from AS-ANY action pref = 2; accept community(3560:20);

    } refine { from AS1 accept AS1;

    from AS2 accept AS2;

    from AS3 accept AS3; }

    Здесь любому маршруту с community 3560:10 присваивается предпочтение 1 а любому маршруту с community 3560:20 присваивается предпочтение 2 вне зависимости от того, откуда они импортированы. Однако только маршруты AS1 импортированы из AS1, и только маршруты AS2 импортированы из AS2, и только маршруты AS3 импортированы из AS3, ни один маршрут не импортирован из каких-либо других AS. К тому же заключению можно прийти, используя алгебраические методы, описанные выше. То есть, это пример эквивалентен:

    import:

    {

    from AS1 action pref = 1; accept community(3560:10) AND AS1;

    from AS1 action pref = 2; accept community(3560:20) AND AS1;

    from AS2 action pref = 1; accept community(3560:10) AND AS2;

    from AS2 action pref = 2; accept community(3560:20) AND AS2;

    from AS3 action pref = 1; accept community(3560:10) AND AS3;

    from AS3 action pref = 2; accept community(3560:20) AND AS3; }

    Рассмотрим следующий пример:

    import:

    {

    from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};

    } refine {

    from AS1 at 1.1.1.1 action pref = 1; accept AS1;

    from AS1 action pref = 2; accept AS1; }

    где воспринимаются только маршруты с длиной от 0 до 18, а значение med сделано равным 0, для того чтобы блокировать влияние med на все пиринги. Кроме того, из AS1 импортируются только маршруты AS1, а маршруты автономной системы AS1, импортированные от 1.1.1.1, предпочтительнее других пирингов. Это эквивалентно:

    import:

    {

    from AS1 at 1.1.1.1 action med=0; pref=1;

    accept {0.0.0.0/0^0-18} AND AS1;

    from AS1 action med=0; pref=2;

    accept {0.0.0.0/0^0-18} AND AS1; }

    Описанный выше синтаксис и семантика применима также к структурированным описаниям экспортной политики с ключевым словом "from", замененным на "to", а "accept" - на "announce".

    7. Класс dictionary

    Класс dictionary обеспечивает расширяемость для RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и маршрутные протоколы. Атрибуты маршрутной политики, впредь называемые rp-атрибутами, могут соответствовать действительным протокольным атрибутам, таким как атрибуты пути BGP (напр., community, dpa и AS-path), или они могут соответствовать особенностям маршрутизатора (напр., гашение осцилляций маршрутов в BGP). Когда вводятся новые протоколы, новые протокольные атрибуты, или новые возможности миршрутизатора, объект словаря актуализуется, с тем чтобы ввести соответствующее описание rp-атрибута или протокола.

    rp-атрибут относится к абстрактному классу, то есть представление данных не доступно. Вместо этого, доступ к ним определяется методом доступа. Например, rp-атрибут для BGP-атрибута AS-path называется aspath, и он имеет метод доступа, называемый prepend, который вставляет дополнительные номера AS в атрибуты AS-path. Методы доступа могут воспринимать аргументы. Аргументы строго типофицируются. Например, метод prepend воспринимает номера AS в качестве аргументов.

    Раз rp-аргумент определен в словаре, он может использоваться для описания фильтров и действий. Необходимы средства анализа политики, чтобы предоставить объект словаря и распознать вновь определенные rp-атрибуты, типы и протоколы. Средства анализа могут даже загружать программу для выполнения соответствующих операций, используя механизмы помимо RPSL.

    Ниже рассматривается синтаксис и семантика класса dictionary. Это описание не существенно для понимания объектов dictionary (но оно существенно для их создания).

    Атрибуты класса dictionary представлены на рис. .24. Атрибут dictionary является именем объекта словаря, подчиняющимся правилам присвоения имен в RPSL. Может существовать много объектов словаря, однако имеется только один стандартный объект "RPSL". Все средства используют этот словарь по умолчанию.

    Атрибут

    Значение

    Тип

    Dictionary

    <object-name>

    обязательный, однозначный, ключ класса

    rp-attribute

    См. описание в тексте

    опционный, многозначный

    typedef

    См. описание в тексте

    опционный, многозначный

    protocol

    См. описание в тексте

    опционный, многозначный

    Рис. .24. Атрибуты класса dictionary

    Атрибут rp-attribute имеет следующий синтаксис:

    rp-attribute:

    <method-1>(<type-1-1>, ..., <type-1-N1> [, "..."])

    ...

    <method-M>(<type-M-1>, ..., <type-M-NM> [, "..."])

    где <name> является именем rp-атрибута, а <method-i> является названием метода доступа для rp-атрибута, требующего Ni аргументов, где j-ый аргумент имеет тип <type-i-j>. Название метода является либо именем RPSL, либо одним из операторов, определенных на рис. .25. Операторные методы за исключением operator() и operator[] могут воспринимать только один аргумент.

    operator=

    operator==

    operator<<=

    operator<

    operator>>=

    operator>

    operator+=

    operator>=

    operator-=

    operator<=

    operator*=

    operator!=

    operator/=

    operator()

    operator.=

    operator[]

    Рис. .25. Операторы

    Атрибут rp-attribute может иметь много методов, определенных для него. Некоторые из методов могут даже иметь то же самое имя, в этом случае их аргументы должны относиться к другому типу. Если список аргументов завершается "...", метод может воспринять переменное число аргументов. В этом случае, действительные аргументы после N-го аргумента имеют тип <type-N>.

    Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на рис. .26.

    integer[lower, upper]

    ipv4_address

    real[lower, upper]

    address_prefix

    enum[name, name, ...]

    address_prefix_range

    string

    dns_name

    Boolean

    filter

    rpsl_word

    as_set_name

    free_text

    route_set_name

    email

    rtr_set_name

    as_number

    filter_set_name

    peering_set_name

    Рис. .26. Предопределенные типы аргументов

    За целочисленными и действительными предопределенными типами могут следовать младшие или старшие секции, которые позволяют специфицировать набор допустимых значений аргумента. Спецификация диапазона является опционной. Для представления целых действительных значений и символьных строк используется нотация языка Си (ANSI). За типом enum следует список имен RPSL, которые являются значениями данного типа. Булев тип может принимать значение true или false. as_number, ipv4_address, address_prefix и dns_name типы имеют те же значения, что типы фильтра (раздел 2) и фильтры политики (раздел 6). Значения фильтра следует помещать в скобки.

    Синтаксис типа union имеет следующий вид:

    union <type-1>, ... , <type-N>
    где <type-i> является типом RPSL. Тип union может иметь тип в интервале от <type-1> до <type-N>.

    Синтаксис списочного типа приведен ниже:
    list [<min_elems>:<max_elems>] of <type>

    В этом случае элементы списка представляют <type>, а список содержит по крайней мере <min_elems> элементов, но не больше чем <max_elems>>. Размер спецификации является опционным. Если спецификация отсутствует, то никаких регламентаций на число элементов в списке не накладывается. Значение списочного типа представляется в виде последовательности элементов, разделенных символом запятой "," и заключенных в фигурные скобки "{" и "}". Атрибут typedef в словаре определяет именованный тип следующим образом:

    typedef: <name> <type>
    где <name> - имя типа <type>. Атрибут typedef является особенно полезным, когда тип не является предопределенным (напр., список объединений [union], список списков и т.д.). Атрибут класса словаря protocol определяет протокол и набор параметров пиринга для этого протокола, которые используются в классе inet-rtr (раздел 9). Его синтаксис представлен ниже:

    protocol:

    <name>

    MANDATORY | OPTIONAL <parameter-1>(

    <<type-1-1>,...,

    <type-1-N1> [,"..."])

    ...

    MANDATORY | OPTIONAL <parameter-M>(

    <type-M-1>,...,

    <type-M-NM> [,"..."])

    где представляет собой имя протокола, MANDATORY и OPTIONAL являются ключевыми словами, а <parameter-i> - пиринг-параметр протокола, использующий Ni аргументов. Синтаксис и семантика аргументов та же, что и для rp-атрибута. Если используется ключевое слово MANDATORY, параметр является обязательным и должен быть специфицирован для каждого пиринга этого протокола. Если применено ключевое слово OPTIONAL, параметр может быть опущен.

    7.1. Исходный словарь RPSL, пример действий политики и фильтры

    dictionary: RPSL
    rp-attribute: # меньшие значения соответствуют более высокому предпочтению pref

    operator=(integer[0, 65535])

    rp-attribute: # атрибут BGP multi_exit_discriminator

    med

    # установить med равным 10: med = 10;

    # установить med метрике IGP: med = igp_cost;

    operator=(union integer[0, 65535], enum[igp_cost])

    rp-attribute: # атрибут предпочтения места назначения BGP (dpa)

    dpa

    operator=(integer[0, 65535])

    rp-attribute: # атрибут BGP aspath

    aspath

    # prepends AS numbers from last to first order

    prepend(as_number, ...)

    typedef: # значение community в RPSL равно:

    # - 4-байтовому целому (ok to use 3561:70 notation)

    # - internet, no_export, no_advertise (смотри RFC-1997)

    community_elm union

    integer[1, 4294967295],

    enum[internet, no_export, no_advertise],

    typedef: # список значений community { 40, no_export, 3561:70 }

    community_list list of community_elm

    rp-attribute: # атрибут BGP community

    community

    # set to a list of communities

    operator=(community_list)

    # добавить значения community

    operator.=(community_list)

    append(community_elm, ...)

    # удалить значения community

    delete(community_elm, ...)

    # фильтр: true если содержится одно из значений community

    contains(community_elm, ...)

    # shortcut to contains: community(no_export, 3561:70)

    operator()(community_elm, ...)

    # сравнение равенства, независящее от порядка

    operator==(community_list)

    rp-attribute:

    # следующий маршрутизатор в статическом маршруте next-hop

    # установить равным 7.7.7.7: next-hop = 7.7.7.7;

    # установить собственный адрес маршрутизатора: next-hop = self;

    operator=(union ipv4_address, enum[self])

    rp-attribute:

    # цена статического маршрута cost

    operator=(integer[0, 65535])

    protocol:

    BGP4

    # номер AS маршрутизатора партнера

    MANDATORY asno(as_number)

    # разрешить гашение осцилляций маршрута

    OPTIONAL flap_damp()

    OPTIONAL flap_damp(integer[0,65535],

    # penalty per flap

    integer[0,65535],

    # penalty value for supression

    integer[0,65535],

    # penalty value for reuse

    integer[0,65535],

    # halflife in secs when up

    integer[0,65535],

    # halflife in secs when down

    integer[0,65535])

    # максимальный штраф

    protocol: OSPF
    protocol: RIP
    protocol: IGRP
    protocol: IS-IS
    protocol: STATIC
    protocol: RIPng
    protocol: DVMRP
    protocol: PIM-DM
    protocol: PIM-SM
    protocol: CBT
    protocol: MOSPF

    Рис. .27. Словарь RPSL

    На рис. .27 показан исходный словарь RPSL. Он имеет семь rp-атрибутов: pref для присвоения локального предпочтения воспринимаемым маршрутам; med для присвоения значения атрибуту MULTI_EXIT_DISCRIMINATOR BGP; dpa для присвоения значения атрибуту DPA BGP; aspath для присвоения значения атрибуту AS_PATH BGP; community для присвоения или проверки значения атрибута community BGP; next-hop для назначения следующих маршрутизаторов в случае статических маршрутов; cost для назначения цены статических маршрутов. Словарь определяет два типа: community_elm и community_list. Тип community_elm является либо 4-байтовым целым числом без знака, либо одним из ключевых слов Интернет, no_export или no_advertise. Целое число может быть специфицировано с помощью двух 2-байтовых чисел, разделенных двоеточием ":", чтобы разделить пространство кода community так, чтобы провайдер мог использовать номер AS первых двух байт, и определить семантику выбора последних двух байт.

    Исходный словарь (рис. .27) определяет только опции для BGP (Border Gateway Protocol): asno и flap_damp. Обязательная опция asno является номером AS партнера-маршрутизатора. Опция flap_damp инструктирует маршрутизатор гасить осцилляции маршрутов [21], при импортировании маршрутов от маршрутизатора-партнера. Она может быть специфицирована с или без параметров. Если параметры опущены, принимаются значения по умолчанию:

    flap_damp(1000, 2000, 750, 900, 900, 20000)

    То есть, назначается штраф 1000 для каждого переключения маршрута, маршрут закрывается, когда штраф достигает 2000. Штраф снижается вдвое после 15 минут стабильного режима вне зависимости оттого открыт путь или нет. Закрытый маршрут используется вновь, когда штраф падает ниже 750. Максимальный штраф маршрута может достигать 20,000 (т.e. максимальное время закрытия маршрута после стабилизации ситуации составляет около 75 минут).

    Действия политики и фильтров, использующих rp-атрибуты

    Синтаксис действия политики или фильтра, использующего rp-атрибут x выглядит следующим образом:

    x.method(arguments)
    x "op" argument

    где method представляет собой метод, а "op" - метод оператора rp-атрибута x. Если метод оператора используется при спецификации составного фильтра политики, он определяется раньше, чем операторы составных фильтров политики (т.e. AND, OR, NOT или оператор). rp-атрибуту pref может быть присвоено положительное целое число следующим образом:

    pref = 10;

    rp-атрибуту med может быть присвоено положительное целое число или слово "igp_cost" следующим образом:

    med = 0;
    med = igp_cost;

    rp-атрибуту dpa может быть присвоено положительное целое число следующим образом:

    dpa = 100;

    Значением атрибута community BGP является список, который состоит из 4-байтовых целых чисел, каждое их которых характеризует "community". Следующие примеры демонстрируют, как добавлять новые значения community к этому rp-атрибуту:

    community .= { 100 };
    community .= { NO_EXPORT };
    community .= { 3561:10 };

    В последнем случае, 4-байтовое целое число, сформированное так, что наиболее значимые два байта равны 3561, а менее значимые два байта равны 10. Следующие примеры показывают, как удалять элементы из rp-атрибута community:

    community.delete(100, NO_EXPORT, 3561:10);

    Фильтры, которые используют rp-атрибут community могут быть определены, как это показано в следующем примере:

    community.contains(100, NO_EXPORT, 3561:10);

    community(100, NO_EXPORT, 3561:10); # shortcut

    rp-атрибуту community может быть присвоено значение, соответствующее списку community следующим образом:

    community = {100, NO_EXPORT, 3561:10, 200};
    community = {};

    В этом первом случае, rp-атрибут community содержит значения (communities) 100, NO_EXPORT, 3561:10 и 200. В последнем случае, rp-атрибут community обнулен. rp-атрибут community может быть сравнен со списком communities следующим образом:

    community == {100, NO_EXPORT, 3561:10, 200}; # точное соответствие

    Чтобы повлиять на выбор маршрута, rp-атрибут BGP as_path может быть сделан длиннее путем предварительной прописи номеров AS следующим образом:

    aspath.prepend(AS1);
    aspath.prepend(AS1, AS1, AS1);

    Следующие примеры некорректны:

    med = -50;

    # -50 лежит вне диапазона

    med = igp;

    # igp не является одним из значений enum

    med.assign(10);

    # заданный метод не определен

    community.append(AS3561:20);

    # первый аргумент должен быть равен 3561. На рис. .28 показан более продвинутый пример, использующий rp-атрибут community. В этом примере, AS3561 базирует свое предпочтение при выборе маршрута на атрибуте community. Другие AS могут апосредовано влиять на выбор маршрутов AS3561 путем включения соответствующих значений communities в их оповещения о маршрутах.

    aut-num: AS1

    export:

    to AS2 action community.={3561:90};

    to AS3 action community.={3561:80};

    announce AS1

    as-set: AS3561:AS-PEERS
    members: AS2, AS3

    aut-num: AS3561

    import:

    from AS3561:AS-PEERS

    action pref = 10;

    accept community(3561:90)

    import:

    from AS3561:AS-PEERS

    action pref = 20;

    accept community(3561:80)

    import:

    from AS3561:AS-PEERS

    action pref = 20;

    accept community(3561:70)

    import:

    from AS3561:AS-PEERS

    action pref = 0;

    accept ANY

    Рис. .28. Пример политики с использованием rp-атрибута community.

    8. Класс Advanced route
    8.1. Спецификация агрегатных маршрутов

    Атрибуты components, aggr-bndry, aggr-mtd, export-comps, inject и holes используются для спецификации агрегатных маршрутов [11]. Объект route специфицирует агрегатный маршрут, если специфицирован любой из этих атрибутов за исключением inject. Атрибут origin для агрегатного маршрута производит объединение маршрутов на базе AS. Здесь термин "aggregate" используется в отношении генерируемого маршрута, термин "component" относится к маршрутам, использованным для формирования атрибута объединения (aggregate) path, а термин "more specifics" относится к любому маршруту, который более специфичен для объединения, вне зависимости от того, используется ли он при формировании атрибутов path. Атрибут components определяет, какой из составляющих маршрутов используется для формирования объединения. Его синтаксис выглядит следующим образом:

    components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]

    где <protocol> представляет собой имя протокола маршрутизации, такого как BGP4, OSPF или RIP (допустимые значения определяются словарем), а <filter> - выражение политики. Маршруты, соотносятся с одним из этих фильтров и получены с помощью соответствующего протокола, используются для формирования объединения (aggregate). Если <protocol> опущен, по умолчанию предполагается любой протокол. <filter> неявно содержит термин "AND" с более специфическими префиксами объединения, так что выбираются только маршруты компоненты. Если используется ключевое слово ATOMIC, объединение выполнено на уровне атомов [11]. Если атрибут components пропущен, используются все более специфичные префиксы без ключевого слова ATOMIC.

    route: 128.8.0.0/15
    origin: AS1
    components: <^AS2>
    route: 128.8.0.0/15
    origin: AS1

    components:

    protocol BGP4 {128.8.0.0/16^+}

    protocol OSPF {128.9.0.0/16^+}

    Рис. .29. Два объекта агрегатных маршрутов.

    На рис. 29 показаны два объекта route. В первом примере объединяются более специфические префиксы 128.8.0.0/15 с проходами, начинающимися с AS2. Во втором примере агрегатированы некоторые маршруты, полученные от BGP и некоторые маршруты, полученные из OSPF.

    Атрибут aggr-bndry является AS-выражением для номеров и наборов (см. раздел 5.6). Результат определяет набор AS, который задает границу объединения (aggregation). Если атрибут aggr-bndry опущен, исходная AS является единственной границей объединения. За пределами границы объединения экспортируется только это объединение, а более специфичные префиксы передаваться не могут. Однако в пределах границы, более специфичные префиксы также могут пересылаться.

    Атрибут aggr-mtd определяет то, как формируется объединение. Его синтаксис показан ниже:

    aggr-mtd:

    inbound

    | outbound [<as-expression>]

    где <as-expression> - выражение для номеров AS и наборов (см. раздел 5.6). Если <as-expression> опущено, по умолчанию предполагается AS-ANY. Если специфицировано экспортное объединение, более специфические префиксы будут присутствовать в пределах AS, а объединение будет сформировано перед отправкой на всех inter-AS границах с AS в <as-expression>, за исключением AS, которые находятся на границе объединения. Если специфицировано импортное объединение, объединение формируется на всех границах inter-AS прежде чем переносить маршруты в агрегатор AS. Заметим, что <as-expression> не может быть специфицировано с использованием импортного объединения. Если атрибут aggr-mtd опущен, он не выполняет функции "outbound AS-ANY".

    route: 128.8.0.0/15

    route: 128.8.0.0/15

    origin: AS1

    origin: AS2

    components: {128.8.0.0/15^-}

    components: {128.8.0.0/15^-}

    aggr-bndry: AS1 OR AS2

    aggr-bndry: AS1 OR AS2

    aggr-mtd: outbound AS-ANY

    aggr-mtd: outbound AS-ANY

    Рис. .30. Пример экспортного объединения большого числа AS.

    На рис. 30 показан пример экспортного объединения. В этом примере, AS1 и AS2 представляют собой объединение и оповещают окружающий мир только о менее специфических префиксах 128.8.0.0/15, обмениваясь друг с другом более специфическими префиксами. Эта форма объединения полезна, когда некоторые компоненты находятся внутри AS1, а некоторые в AS2.

    Когда агрегатируется набор маршрутов, предполагается экспортировать только агрегатные маршруты и блокировать экспорт более специфичных префиксов вне границы объединения, чтобы удовлетворить определенной политике и топологическим ограничениям (напр., компонента со многими интерфейсами (multi-homed)) часто необходимо экспортировать некоторые компоненты. Атрибут export-comps эквивалентен фильтру RPSL, который соответствует более специфичным префиксам. Если этот атрибут опущен, более специфические префиксы не экспортируются за пределы границы объединения. Заметим, что, фильтр export-comps содержит неявный оператор "AND" по отношению более специфичным префиксам объединения.

    На рис. 31 показан пример экспортного объединения. В этом примере, более специфические префиксы 128.8.8.0/24 экспортируются из AS1 в дополнение к объединению. Это полезно, когда 128.8.8.0/24 является многопортовым узлом, связанным с другими AS.

    route:

    128.8.0.0/15

    origin:

    AS1

    components:

    {128.8.0.0/15^-}

    aggr-mtd:

    outbound AS-ANY

    export-comps:

    {128.8.8.0/24}

    Рис. .31. Экспортное объединение с исключениями.

    Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:

    inject:

    [at <router-expression>] ...

    [action <action>]

    [upon <condition>]

    где <action> - спецификация действия (см. раздел 6.1.1), <condition> - булево выражение, описанное ниже, <router-expression> описано в разделе 5.6.

    Все маршрутизаторы в <router-expression> и в агрегаторе (объединении) AS выполняют агрегацию. Если <router-expression> не специфицировано, все маршрутизаторы внутри агрегатора AS выполняют агрегацию. Спецификация <action> может установить атрибуты path объединения (aggregate), например, определить предпочтения для объединения.

    Так как условие является булевым выражением, объединение создается, если и только если это условие истинно. <condition> - булево выражение, использующее логические операторы AND и OR (т.e. оператор NOT не разрешен):

    HAVE-COMPONENTS { список префиксов }
    EXCLUDE { список префиксов }
    STATIC

    Список префиксов в HAVE-COMPONENTS может состоять из более специфических префиксов объединения. Список может также включать диапазоны префиксов (т.e. использование операторов ^-, ^+, ^n, и ^n-m). В этом случае, по крайней мере, один префикс из каждого диапазона префиксов должен присутствовать в каждой маршрутной таблице, для того чтобы условие было выполнено. Список префиксов в EXCLUDE может быть произвольным. Условие выполняется, когда ни один из перечисленных префиксов не содержится в маршрутной таблице. Список может содержать диапазоны префиксов, а ни один префикс из этого диапазона не должен присутствовать в маршрутной таблице. Ключевое слово static всегда предполагается равным true.

    route:

    128.8.0.0/15

    origin:

    AS1

    components:

    {128.8.0.0/15^-}

    aggr-mtd:

    outbound AS-ANY

    inject:

    at 1.1.1.1 action dpa = 100;

    inject:

    at 1.1.1.2 action dpa = 110;

    route:

    128.8.0.0/15

    origin:

    AS1

    components:

    {128.8.0.0/15^-}

    aggr-mtd:

    outbound AS-ANY

    inject:

    upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}

    holes:

    128.8.8.0/24

    Рис. .32. Примеры инжекции.

    На рис. 32 показаны два примера. В первом случае, объединение вводится в два маршрутизатора, каждый из которых устанавливает атрибут прохода dpa по-разному. Во втором случае, объединение формируется только если в маршрутной таблице присутствуют как 128.8.0.0/16 так и 128.9.0.0/16, в отличие от первого случая, когда присутствия лишь одного из них достаточно для ввода (injection).

    Атрибут holes перечисляет компоненты адресных префиксов, которые не достижимы через агрегатный маршрут (возможно, что часть адресного пространства не распределена). Атрибут holes полезен для диагностических целей. На рис. .32, второй пример имеет дырку, в частности 128.8.8.0/24. Это может быть связано с тем, что клиент менял провайдера и брал для этой цели эту часть адресного пространства.

    8.1.1. Взаимодействие с политикой в классе aut-num

    О сформированном объединении другие AS оповещаются только в случае, когда экспортная политика AS позволяет передавать объединения маршрутов. Когда объединение сформировано, более специфические префиксы запрещены для экспорта за исключением AS в aggr-bndry и компонент в export-comps.

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

    route:

    128.8.0.0/16

    origin:

    AS1

    route:

    128.9.0.0/16

    origin:

    AS1

    route:

    128.8.0.0/15

    origin:

    AS1

    aggr-bndry:

    AS1 or AS2 or AS3

    aggr-mtd:

    outbound AS3 or AS4 or AS5

    components:

    {128.8.0.0/16, 128.9.0.0/16}

    inject:

    upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}

    aut-num:

    AS1

    export:

    to AS2 announce AS1

    export:

    to AS3 announce AS1 and not {128.9.0.0/16}

    export:

    to AS4 announce AS1

    export:

    to AS5 announce AS1

    export:

    to AS6 announce AS1

    Рис. .33. Взаимодействие с политикой в классе aut-num.

    На рис. 33 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 128.8.0.0/16 и 128.9.0.0/16 между AS1, AS2 и AS3 (граница объединения).

    Экспортное объединение выполнено для AS4 и AS5, но не для AS3, так как AS3 находится на границе объединения. Объект aut-num допускает экспортирование обоих компонентов в AS2, и только компонент 128.8.0.0/16 в AS3. Объединение может быть сформировано, если присутствуют все компоненты. В данном случае только об этом объединении оповещены AS4 и AS5. Однако, если одна из компонент не доступна, объединение не может быть создано, и любая из доступных компонент или более специфический префикс будет экспортирован в AS4 и AS5. Вне зависимости от того, выполнено объединение или нет, только более специфические префиксы будут экспортированы в AS6.

    При выполнении импортного объединения конфигурирующие генераторы могут опускать агрегационные заявления для маршрутизаторов, где импортная политика AS запрещает импортирование более специфических префиксов.

    8.1.2. Разрешение неопределенности для перекрывающихся объединений

    Когда специфицированы несколько маршрутных объединений и они перекрываются, т.e. один менее специфичен чем другой, тогда сначала определяются более а затем менее специфичные. Когда для партнера осуществляется экспортное объединение (outbound aggregation), объединение и компоненты, перечисленные в атрибуте export-comps, доступны для генерации следующих менее специфичных объединений. Компоненты, которые не специфицированы в атрибуте export-comps, являются недоступными. Маршрут экспортируем в AS, если это наименее специфическое объединение, экспортируемое в эту автономную систему или маршрут упомянут в атрибуте export-comps. Заметим, что это рекурсивное определение.

    route:

    128.8.0.0/15

    origin:

    AS1

    aggr-bndry:

    AS1 or AS2

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}

    route:

    128.10.0.0/15

    origin:

    AS1

    aggr-bndry:

    AS1 or AS3

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16}

    export-comps:

    {128.11.0.0/16}

    route:

    128.8.0.0/14

    origin:

    AS1

    aggr-bndry:

    AS1 or AS2 or AS3

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15}

    export-comps:

    {128.10.0.0/15}

    Рис. .34. Перекрывающиеся объединения.

    На рис. 34, AS1 вместе с AS2 объединяют 128.8.0.0/16 и 128.9.0.0/16 в 128.8.0.0/15. Вместе с AS3, AS1 объединяет 128.10.0.0/16 и 128.11.0.0/16 в 128.10.0.0/15. Но все вместе они объединяют эти четыре маршрута в 128.8.0.0/14. Предполагая все четыре компоненты доступными, маршрутизатор в AS1 для внешней AS, скажем AS4, сначала сгенерирует 128.8.0.0/15 и 128.10.0.0/15. Это сделает 128.8.0.0/15, 128.10.0.0/15 и его исключение 128.11.0.0/16 доступным для генерации 128.8.0.0/14. Маршрутизатор из этих трех маршрутов будет затем генерировать 128.8.0.0/14. Следовательно, для AS4, 128.8.0.0/14 и его исключение, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми.

    Для AS2, маршрутизатор в AS1 сгенерирует только 128.10.0.0/15. Следовательно, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми. Заметим, что 128.8.0.0/16 и 128.9.0.0/16 являются также экспортируемыми, так как они не участвуют в объединении, допускающем экспорт в AS2. Аналогично, для AS3, маршрутизатор в AS1 будет генерировать только 128.8.0.0/15. В этом случае 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 могут экспортироваться.

    8.2. Спецификация статических маршрутов

    Атрибут inject может служить для спецификации статических маршрутов, используя "upon static" в качестве условия:

    inject:

    [at <routerexpression>] ...

    [action <action>]

    upon static

    В этом случае маршрутизатор в <router-expression> выполняет <action> и вводит маршрут в статическую маршрутную систему interAS. <action> может установить определенные маршрутные атрибуты, такие как next-hop router или cost.

    В следующем примере, маршрутизатор 1.1.1.1 вводит маршрут 128.7.0.0/16. Маршрутизаторы следующего шага (в этом примере, имеется два маршрутизатора "следующего шага") для этого маршрута имеют адреса 1.1.1.2 и 1.1.1.3, а маршрут имеет цену 10 для 1.1.1.2 и 20 для 1.1.1.3.

    route: 128.7.0.0/16
    origin: AS1
    inject: at 1.1.1.1 action next-hop = 1.1.1.2; cost = 10; upon static
    inject: at 1.1.1.1 action next-hop = 1.1.1.3; cost = 20; upon static

    9. Класс inet-rtr

    Маршрутизаторы специфицируются с использованием класса inet-rtr. Атрибуты класса inet-rtr показаны на рис. 35. Атрибут inet-rtr представляет собой допустимое имя DNS описанного маршрутизатора. Каждый атрибут alias, если он присутствует, является каноническим именем DNS для маршрутизатора. Атрибут local-as специфицирует номер AS, которой управляет данный маршрутизатор.

    Атрибут

    Значение

    Тип

    inet-rtr

    <dns-name>

    обязательный, однозначный, ключ класса

    alias

    <dns-name>

    опционный, многозначный

    local-as

    <as-number>

    обязательный, однозначный

    ifaddr

    См. описание в тексте

    обязательный, многозначный

    peer

    См. описание в тексте

    опционный, многозначный

    member-of

    список <rtr-set-names>

    опционный, многозначный

    Рис. .35. Атрибуты класса inet-rtr

    Значение атрибута ifaddr имеет следующий синтаксис:

    <ipv4-address> masklen <integer>> [action <action>]

    IP-адрес и длина маски являются обязательными для каждого интерфейса. Опционно можно специфицировать действие (action), которое позволяет установить другие параметры этого интерфейса.

    На рис. .36 предложен пример объекта inet-rtr. Имя маршрутизатора "amsterdam.ripe.net". "amsterdam1.ripe.net" является каноническим именем для маршрутизатора. Маршрутизатор соединен с четырьмя сетями. Их IP-адреса и длины масок специфицированы в атрибутах ifaddr.

    inet-rtr: Amsterdam.ripe.net
    alias: amsterdam1.ripe.net
    local-as: AS3333
    ifaddr: 192.87.45.190 masklen 24
    ifaddr: 192.87.4.28 masklen 24
    ifaddr: 193.0.0.222 masklen 27
    ifaddr: 193.0.0.158 masklen 27
    peer: BGP4 192.87.45.195 asno(AS3334), flap_damp()

    Рис. .36. Объекты inet-rtr

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

    <protocol> <ipv4address>

    <options>

    | <protocol> <inet-rtr-name>

    <options>

    | <protocol> <rtr-set-name>

    <options>

    | <protocol> <peering-set-name>

    <options>

    где <protocol> - имя протокола, <ipv4-address> - IP-адрес маршрутизатора партнера, а <options> - список опций пиринга для <protocol>. Элементы списка разделяются запятыми. Вместо IP-адресов партнеров, может использоваться его inet-rtr-name. Допустимые имена протоколов и атрибуты определены в словаре (см. раздел 7). В выше приведенном примере, маршрутизатор имеет BGP-пиринг с маршрутизатором 192.87.45.195 в AS3334. Он включает подавление осцилляций маршрута, когда импортирует маршруты из этого маршрутизатора.

    Вместо одиночного партнера с помощью форм <rtr-set-name> и <peering-set-name> может быть специфицирована группа партнеров. Если использована форма <peering-set- name>, то включаются только пиринги из соответствующего набора данного маршрутизатора. На рис. .37 показан пример объекта inet-rtr с пиринг-группами.

    rtr-set: rtrs-ibgp-peers
    members: 1.1.1.1, 2.2.2.2, 3.3.3.3
    peering-set: prng-ebgp-peers
    peering: AS3334 192.87.45.195
    peering: AS3335 192.87.45.196
    inet-rtr: Amsterdam.ripe.net
    alias: amsterdam1.ripe.net
    local-as: AS3333
    ifaddr: 192.87.45.190 masklen 24
    ifaddr: 192.87.4.28 masklen 24
    ifaddr: 193.0.0.222 masklen 27
    ifaddr: 193.0.0.158 masklen 27
    peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()
    peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()

    Рис. .37. Объект inet-rtr с пиринг-группами

    10. Расширение RPSL

    Практика работы с языками описания маршрутной политики (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) показывает, что язык описания должен быть расширяемым. Новые маршрутные протоколы или новые особенности существующих протоколов могут быть легко описаны, с помощью класса dictionary RPSL. Могут быть добавлены новые классы или новые атрибуты существующих классов.

    Класс dictionary является первичным механизмом расширения RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и протоколы маршрутизации.

    Чтобы добавить соответствующее определение rp-атрибута, протокола, или новых особенностей маршрутизатора, вводится модификация словаря RPSL.

    Когда изменяется словарь, должна быть обеспечена полная совместимость. Например, в случае демпфирования осцилляций аршрута спецификация параметров делается опционной, когда ISP на данном уровне не требует деталей. Предполагается, что любое средство, базирующееся на RPSL, выполняет по умолчанию определенные действия, встретив атрибуты маршрутной политики, которые не распознаны (напр., выдает предупреждение или просто игнорирует). Следовательно, старые средства демпфирования осцилляций маршрутов, обнаружив неизвестные им параметры спецификации, должны эти параметры игнорировать.

    Любой класс может быть расширен путем добавления новых атрибутов. Для обеспечения полной совместимости новые атрибуты не должны противоречить семантике объектов, к которым они добавлены. Любое средство, которое использует IRR, должно быть устроено так, чтобы игнорировать атрибуты, которые оно не понимает.

    Введение новых атрибутов рекомендуется, когда у существующего класса появляются новые черты. Например, класс RPSL route расширяет возможности препроцессора RIPE-181 путем введения нескольких новых атрибутов, которые разрешают агрегатирование и спецификации статических маршрутов.

    Новые классы могут добавляться к RPSL для записи новых типов данных, характеризующих политику. Так как любое средство запрашивает IRR только о классах, которые ему известны, проблемы совместимости возникнуть просто не может.

    Прежде чем добавлять новый класс, следует ответить на вопрос, относится ли информация, содержащаяся в объекте, к новому классу.

    Ссылки

    [1]

    Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.

    [2]

    Nsfnet policy routing database (prdb). Maintained by MERIT Network Inc., Ann Arbor, Michigan. Contents available from nic.merit.edu.:/nsfnet/announced.networks /nets.tag.now by anonymous ftp.

    [3]

    Alaettinouglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizer, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.

    [4]

    C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing policy specification language (rpsl) on the internet. Work in Progress.

    [5]

    T. Bates. Specifying an `internet router' in the routing registry. Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

    [6]

    T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of ip routing policies in a routing registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

    [7]

    Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, " Representation of IP Routing Policies in a Routing Registry", RFC-1786, March 1995.

    [8]

    T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. Representation of ip routing policies in the ripe database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.

    [9]

    Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC-1997, August 1996.

    [10]

    Crocker, D., "Standard for ARPA Internet Text Messages", STD 11, RFC-822, August 1982.

    [11]

    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC-1519, September 1993.

    [12]

    D. Karrenberg and T. Bates. Description of inter-as networks in the ripe routing registry. Technical Report RIPE-104, RIPE, RIPE NCC, Amsterdam, Netherlands, December 1993.

    [13]

    D. Karrenberg and M. Terpstra. Authorisation and notification of changes in the ripe database. Technical Report ripe-120, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

    [14]

    B. W. Kernighan and D. M. Ritchie. The C Programming Language. Prentice-Hall, 1978.

    [15]

    A. Lord and M. Terpstra. Ripe database template for networks and persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

    [16]

    A. M. R. Magee. Ripe ncc database documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.

    [17]

    Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC-1034, November 1987.

    [18]

    Y. Rekhter. Inter-domain routing protocol (idrp). Journal of Internetworking Research and Experience, 4:61--80, 1993.

    [19]

    Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC-1771, March 1995.

    [20]

    C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. Routing policy system security", Work in Progress.

    [21]

    Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC-2439, November 1998.

    [22]

    J. Zsako, "PGP authentication for ripe database updates", Work in Progress.

    B. Грамматические правила

    Ниже рассмотрены формальные грамматические правила RPSL. Основные типы данных определены в разделе 2. Правила записаны с использованием входного языка грамматического разбора GNU Bison.

    //**** базовые атрибуты *********************************************
    changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT

    //**** класс aut-num *************************************************

    //// as_expression /////////////////////////////////////////////////////

    opt_as_expression: | as_expression
    as_expression: as_expression OP_OR as_expression_term | as_expression_term
    as_expression_term: as_expression_term OP_AND as_expression_factor
    | as_expression_term KEYW_EXCEPT as_expression_factor | as_expression_factor
    as_expression_factor: '(' as_expression ')' | as_expression_operand
    as_expression_operand: TKN_ASNO | TKN_ASNAME

    //// router_expression /////////////////////////////////////////////////

    opt_router_expression: | router_expression
    opt_router_expression_with_at: | KEYW_AT router_expression
    router_expression: router_expression OP_OR router_expression_term | router_expression_term
    router_expression_term: router_expression_term OP_AND router_expression_factor
    | router_expression_term KEYW_EXCEPT router_expression_factor | router_expression_factor
    router_expression_factor: '(' router_expression ')' | router_expression_operand
    router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME

    //// пиринг ///////////////////////////////////////////////////////////

    peering: as_expression opt_router_expression opt_router_expression_with_at
    | TKN_PRNGNAME

    //// действие ////////////////////////////////////////////////////////////
    opt_action: | KEYW_ACTION action
    action: single_action | action single_action
    single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'
    | TKN_RP_ATTR TKN_OPERATOR list_item ';' | TKN_RP_ATTR '(' generic_list ')' ';'
    | TKN_RP_ATTR '[' generic_list ']' ';' | ';'

    //// фильтр ////////////////////////////////////////////////////////////

    filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_term
    filter_term : filter_term OP_AND filter_factor | filter_factor
    filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand
    filter_operand: KEYW_ANY | '<' filter_aspath '>' | filter_rp_attribute | TKN_FLTRNAME
    | filter_prefix
    filter_prefix: filter_prefix_operand OP_MS | filter_prefix_operand
    filter_prefix_operand: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME
    | '{' opt_filter_prefix_list '}'
    opt_filter_prefix_list: | filter_prefix_list
    filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix
    filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG
    filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term
    filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure
    filter_aspath_closure: filter_aspath_closure '*' | filter_aspath_closure '?' | filter_aspath_closure '+'
    | filter_aspath_factor
    filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no
    filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']'
    | '[' '^' filter_aspath_range ']'
    filter_aspath_range: | filter_aspath_range TKN_ASNO | filter_aspath_range KEYW_PEERAS
    | filter_aspath_range '.' | filter_aspath_range TKN_ASNO '-' TKN_ASNO
    | filter_aspath_range TKN_ASNAME
    filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'
    | TKN_RP_ATTR TKN_OPERATOR list_item | TKN_RP_ATTR '(' generic_list ')'
    | TKN_RP_ATTR '[' generic_list ']'

    //// пара пиринг-действий ///////////////////////////////////////////////
    import_peering_action_list: KEYW_FROM peering opt_action
    | import_peering_action_list KEYW_FROM peering opt_action
    export_peering_action_list: KEYW_TO peering opt_action
    | export_peering_action_list KEYW_TO peering opt_action
    //// фактор import/export //////////////////////////////////////////////
    import_factor: import_peering_action_list KEYW_ACCEPT filter
    import_factor_list: import_factor ';' | import_factor_list import_factor ';'
    export_factor: export_peering_action_list KEYW_ANNOUNCE filter
    export_factor_list: export_factor ';' | export_factor_list export_factor ';'
    //// термин import/export ////////////////////////////////////////////////
    import_term: import_factor ';' | '{' import_factor_list '}'
    export_term: export_factor ';' | '{' export_factor_list '}'
    //// выражение import/export //////////////////////////////////////////
    import_expression: import_term | import_term KEYW_REFINE import_expression
    | import_term KEYW_EXCEPT import_expression
    export_expression: export_term | export_term KEYW_REFINE export_expression
    | export_term KEYW_EXCEPT export_expression
    //// протокол ///////////////////////////////////////////////////////////
    opt_protocol_from: | KEYW_PROTOCOL tkn_word
    opt_protocol_into: | KEYW_INTO tkn_word
    //**** атрибуты import/export ****************************************
    import_attribute: ATTR_IMPORT
    | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor
    export_attribute: ATTR_EXPORT
    | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor
    opt_default_filter: | KEYW_NETWORKS filter
    default_attribute: ATTR_DEFAULT KEYW_TO peering
    filter_attribute: ATTR_FILTER filter
    peering_attribute: ATTR_PEERING peering

    //**** класс inet-rtr **************************************************
    ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
    //// атрибут peer ////////////////////////////////////////////////////
    opt_peer_options: | peer_options
    peer_options: peer_option | peer_options ',' peer_option
    peer_option: tkn_word '(' generic_list ')'
    peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME
    peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options
    //**** класс route *****************************************************
    aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression
    aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND
    | ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression
    //// атрибут inject //////////////////////////////////////////////////
    opt_inject_expression: | KEYW_UPON inject_expression
    inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term
    inject_expression_term: inject_expression_term OP_AND inject_expression_factor
    | inject_expression_factor
    inject_expression_factor: '(' inject_expression ')' | inject_expression_operand
    inject_expression_operand: KEYW_STATIC
    | KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'
    | KEYW_EXCLUDE '{' opt_filter_prefix_list '}'
    inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression
    //// атрибут components //////////////////////////////////////////////
    opt_atomic: | KEYW_ATOMIC
    components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter
    components_attribute: ATTR_COMPONENTS opt_atomic components_list

    //**** набор маршрутов *****************************************************

    opt_rs_members_list: /* пустой список */
    | rs_members_list
    rs_members_list: rs_member | rs_members_list ',' rs_member
    rs_member: TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS
    | TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4 | TKN_PRFXV4RNG
    rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list

    //**** словарь ******************************************************
    rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods
    | ATTR_RP_ATTR TKN_RP_ATTR methods
    methods: method | methods method
    method: TKN_WORD '(' ')' | TKN_WORD '(' typedef_type_list ')'
    | TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'
    | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'
    | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'
    //// атрибут typedef ////////////////////////////////////////////////
    typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type
    typedef_type_list: typedef_type | typedef_type_list ',' typedef_type
    typedef_type: KEYW_UNION typedef_type_list | KEYW_RANGE KEYW_OF typedef_type
    | TKN_WORD | TKN_WORD '[' TKN_INT ',' TKN_INT ']'
    | TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' | TKN_WORD '[' enum_list ']'
    | KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type
    | KEYW_LIST KEYW_OF typedef_type
    enum_list: tkn_word | enum_list ',' tkn_word
    //// атрибут protocol ////////////////////////////////////////////////

    protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options
    protocol_options: | protocol_options protocol_option
    protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method
    //**** Описания лексем *********************************************

    //// макросы flex, используемые при определении лексем /////////////////////////////
    INT [[:digit:]]+
    SINT [+-]?{INT}
    REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?
    NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?
    ASNO AS{INT}
    ASNAME AS-[[:alnum:]_-]*[[:alnum:]]
    RSNAME RS-[[:alnum:]_-]*[[:alnum:]]
    RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]]
    PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]]
    FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]]
    IPV4 [0-9]+(\.[0-9]+){3,3}
    PRFXV4 {IPV4}\/[0-9]+
    PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})
    ENAMECHAR [^()<>,;:\\\"\.[\] \t\r]
    ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")
    DNAME [[:alnum:]_-]+
    //// Определения лексем >////////////////////////////////////////////////
    TKN_INT {SINT}
    TKN_INT {INT}:{INT} if each {INT} is two octets
    TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet
    TKN_REAL {REAL}
    TKN_STRING То же самое что и в языке СИ
    TKN_IPV4 {IPV4}
    TKN_PRFXV4 {PRFXV4}
    TKN_PRFXV4RNG {PRFXV4RNG}
    TKN_ASNO {ASNO}
    TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\
    (:({ASNO}|peeras|{ASNAME}))*
    TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\
    (:({ASNO}|peeras|{RSNAME}))*
    TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\
    (:({ASNO}|peeras|{RTRSNAME}))*
    TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\
    (:({ASNO}|peeras|{PRNGNAME}))*
    TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\
    (:({ASNO}|peeras|{FLTRNAME}))*
    TKN_BOOLEAN true|false
    TKN_RP_ATTR {NAME} if defined in dictionary
    TKN_WORD {NAME}
    TKN_DNS {DNAME}("."{DNAME})+
    TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4})

    Документ RFC-2280 [3] содержит раннюю версию языка RPSL.

    Previous: 4.4.11.7 Маршрутная политика    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)


    previous up down next index index
    Previous: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.13 Протокол управления SNMP

    4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1. Введение

    Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов.

    Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса.

    DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ.

    ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. ЭВМ могут не всегда корректно зарезервировать свои сетевые адреса, таким образом, схема распределенного выделения адресов не может гарантировать уникальности сетевых адресов.

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

    Динамическое присвоение адресов представляет собой единственный механизм, который позволяет автоматически повторно использовать адрес, который не нужен клиенту. Таким образом, динамическое присвоение адресов является оптимальной схемой для клиентов, подключаемых к сети временно, или совместно использующих один и тот же набор IP-адресов и не нуждающихся в постоянных адресах .

    Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [7, 21] и обеспечить совместимость DHCP-серверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCP-серверов в каждом физическом сегменте сети.

    1.1. Сопряженные разработки

    Существует несколько протоколов Интернет, которые так или иначе связаны с проблемой присвоения сетевых адресов. Протокол RARP (Reverse Address Resolution Protocol) [10] через расширения, описанные в DRARP (Dynamic RARP [5]), не только позволяет определить сетевой адрес, но и включает в себя автоматический механизм распределения IP-адресов. Протокол TFTP (Trivial File Transfer Protocol) [20] обеспечивает транспортировку загрузочного модуля от boot-сервера. Протокол ICMP (Internet Control Message Protocol) [16] с помощью сообщений "ICMP redirect" информирует ЭВМ о дополнительных маршрутизаторах. ICMP может также предоставить информацию о масках субсетей (сообщения "ICMP mask request"). ЭВМ могут найти маршрутизатор через ICMP-механизм поиска маршрутизаторов [8].

    BOOTP является транспортным механизмом сбора конфигурационной информации. Протокол BOOTP является масштабируемым, определены стандартные расширения [17] для нескольких конфигурационных параметров. Морган предложил расширение BOOTP для динамического присвоения IP-адресов [15]. Протокол NIP (Network Information Protocol), использованный в проекте Athena МТИ, предоставляет распределенный динамический механизм выделения IP-адресов [19]. Протокол RLP (Resource Location Protocol [1]) служит для нахождения серверов, предоставляющих услуги верхнего уровня. Бездисковые рабочие станции компании Sun Microsystems используют процедуру загрузки, которая с привлечением механизма RARP, TFTP и RPC, называемого "bootparams", предоставляет бездисковой ЭВМ конфигурационную информацию и фрагменты операционной системы.

    Существуют разработки, которые позволяют определить для заданного пути максимальный размер пакета (MTU) [14]. Существуют предложение по использованию протокола ARP (Address Resolution Protocol) для нахождения и выбора ресурсов [6]. Наконец, в RFC Host Requirements [3, 4] упоминаются специфические требования к конфигурированию ЭВМ, и предлагается сценарий инициализации бездисковых ЭВМ.

    1.2. Постановка задачи

    Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.

    Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.

    1.3. Терминология

    В данном документе применены следующие определения:

    DHCP клиент

    Клиент DHCP является ЭВМ, подключенной к Интернет, которая использует DHCP, чтобы получить конфигурационные параметры, например сетевой адрес.

    DHCP сервер

    Сервер DHCP является ЭВМ, подключенной к Интернет, которая присылает клиенту DHCP параметры конфигурации.

    Агент пересылки BOOTP

    Агент пересылки BOOTP представляет собой ЭВМ, подключенную к Интернет, или маршрутизатор, который осуществляет связь между клиентом и сервером DHCP. DHCP спроектирован так, чтобы обеспечить совместимость со спецификациями протокола BOOTP.

    Binding

    Сопряжение (binding) представляет собой совокупность конфигурационных параметров, включая, как минимум, IP-адрес, присваиваемый DHCP-клиенту. Сопряжением управляют DHCP-серверы.

    1.4. Цели

    Ниже предлагается список основных задач DHCP.

    o

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

    o

    Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры.

    o

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

    o

    DHCP не требует отдельного сервера для каждой субсети.

    o

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

    o

    DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную.

    o

    DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21].

    o

    DHCP должен обслуживать существующих клиентов BOOTP.

    DHCP должен:

    o

    Гарантировать, что любой специфический сетевой адрес не будет использоваться более чем одним клиентом DHCP одновременно.

    o

    Поддерживать DHCP конфигурацию клиента при стартовой перезагрузке DHCP-клиента. Клиенту DHCP должен, при каждом запросе по мере возможности, присваиваться один и тот же набор конфигурационных параметров (например, сетевой адрес).

    o

    Поддерживать конфигурацию DHCP-клиента при перезагрузке сервера, и, по мере возможности, DHCP-клиенту должен присваиваться один и тот же набор конфигурационных параметров.

    o

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

    o

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

    2. Краткий обзор протокола

    С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4).

    На рис. .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах.

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

    DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    op (1)

    htype (1)

    hlen (1)

    Шаги (1)

    xid (4)

    secs (2)

    Флаги (2)

    ciaddr (4)

    yiaddr (4)

    siaddr (4)

    chaddr (4)

    chaddr (16)


    sname (64)


    Файл (128)

    Опции (длина переменная)

    Рис. 1. Формат сообщения DHCP

    DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.

    Таблица 1. Описание полей сообщения DHCP

    Поле

    Байт

    Описание

    op

    1

    Код операции сообщения / тип сообщения.

    1

    = BOOTREQUEST, 2 = BOOTREPLY

    htype

    1

    Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet.

    Hlen

    1

    Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet).

    Шаги

    1

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

    Xid

    4

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

    Secs

    2

    Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса.

    Флаги

    2

    Флаги (смотри рис. 2).

    Ciaddr

    4

    IP-адрес клиента заполняется только в случае, если клиент находится в состоянии BOUND, RENEW или REBINDING и может реагировать на запросы ARP.

    Yiadd

    4

    IP-адрес следующего сервера, используемого в процессе загрузки; присылается сервером в DHCPOFFER, DHCPACK.

    Giaddr

    4

    IP-адрес агента транспортировки, используется когда загрузка осуществляется через посредника.

    Chaddr

    16

    Аппаратный адрес клиента.

    Sname

    64

    Опционное имя ЭВМ-сервера, строка завершается нулем.

    Файл

    128

    Имя файла загрузки (Boot-файла), строка завершается нулем; имя "generic" или нуль в DHCPDISCOVER, полное описание прохода в DHCPOFFER.

    Опции

    var

    Поле опционных параметров.

    Поле опции имеет переменную длину. Клиент DHCP должен быть готов получать DHCP-сообщения с полем 'опции' длиной, по крайней мере, 312 октетов. Это требование подразумевает, что DHCP-клиент должен быть готов получать сообщения длиной до 576 октетов. DHCP-клиенты могут согласовать применение более длинных DHCP-сообщений с помощью опции 'maximum DHCP message size'. Поле options может быть еще расширено в полях 'файл' и 'sname'.

    В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122. Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом.

    Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле 'флаги' [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис. 2 показан формат поля флаги.

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

    B

    MBZ

    B: флаг BROADCAST
    MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)

    Рис. .2: Формат поля 'флаги'

    2.1. Основные конфигурационные параметры

    Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента.

    Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.

    2.2. Динамическое выделение сетевых адресов

    Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать.

    При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.

    3. Протокол клиент-сервер

    DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис. 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.

    Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.

    Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения.

    В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".

    3.1. Взаимодействие клиента и сервера при выделении сетевого адреса

    Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.

    1.

    Клиент широковещательно пересылает сообщение DHCPDISCOVER по локальной физической субсети. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и длительности его использования. Агент транспортировки BOOTP может передать сообщение DHCP-серверам, которые размещены за пределами данной физической субсети.

    2.

    Каждый сервер может откликнуться сообщением DHCPOFFER, которое содержит сетевой адрес в поле 'yiaddr' (и другие конфигурационные параметры в опциях DHCP). Серверы не должны резервировать предлагаемый сетевой адрес, хотя протокол будет работать более эффективно, если сервер избегает присвоения предлагаемого сетевого адреса другому клиенту. При выделении нового адреса, серверы должны проверять, чтобы предлагаемый сетевой адрес не использовался где-то еще; например, сервер может протестировать предлагаемый адрес с помощью эхо-запроса ICMP. Серверы должны быть реализованы так, чтобы сетевые администраторы могли выбрать желательные тесты для вновь выделяемых адресов. Сервер отправляет клиенту сообщение DHCPOFFER, используя, если необходимо транспортные средства BOOTP.

    Таблица 2: Сообщения DHCP

    Сообщение

    Использование

    DHCPDISCOVER

    Клиент посылает сообщение широковещательно, чтобы обнаружить доступный сервер.

    DHCPOFFER

    Посылается сервером клиенту в ответ на сообщение DHCPDISCOVER и содержит предложение по конфигурационным параметрам.

    DHCPREQUEST

    Сообщение клиента серверу либо (a) запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов, (b) подтверждающее корректность ранее присвоенного адреса после, например, перезагрузки системы, или (c) запрос расширения времени жизни конкретного сетевого адреса.

    DHCPACK

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

    DHCPNAK

    Посылается сервером клиенту, сообщая о том, что сетевой адрес не корректен (например, клиент переместился в новую субсеть), или время использования адреса клиентом истекло

    DHCPDECLINE

    Клиент и сервер обнаружили, что сетевой адрес уже используется.

    DHCPRELEASE

    Посылается клиентом серверу с целью отказа от сетевого адреса и аннулирует оставшееся время действия адреса.

    DHCPINFORM

    Посылается клиентом серверу с просьбой о локальных конфигурационных параметрах; клиент уже имеет полученный извне сетевой адрес.

    Рис. 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса

    3. Клиент получает одно или более сообщений DHCPOFFER от одного или более серверов. Клиент может предпочесть дождаться нескольких откликов. Клиент выбирает один сервер, которому пошлет запрос конфигурационных параметров, согласно предложению, содержащемуся в сообщении DHCPOFFER. Клиент широковещательно отправляет сообщение DHCPREQUEST, которое должно содержать опцию 'server identifier', чтобы указать, какой сервер им выбран, и которое может включать в себя другие опции, специфицирующие желательные конфигурационные значения. Опция 'requested IP-адрес' в сообщении сервера DHCPOFFER должна содержать значение 'yiaddr'. Сообщение DHCPREQUEST посылается широковещательно агентами транспортировки DHCP/BOOTP. Для того чтобы быть уверенным, что любой агент транспортировки BOOTP направляет сообщение DHCPREQUEST тому же набору DHCP-серверов, которые получили исходное сообщение DHCPDISCOVER, сообщение DHCPREQUEST должно использовать то же значение поля 'secs' заголовка DHCP-сообщения и должно посылаться по тому же широковещательному IP-адресу, что и оригинальное сообщение DHCPDISCOVER. Клиент реализует таймаут и повторно посылает сообщение DHCPDISCOVER, если не получает сообщений DHCPOFFER.

    4.

    Серверы получают широковещательное сообщение DHCPREQUEST от клиента. Серверы, не выбранные сообщением DHCPREQUEST, используют сообщение как уведомления о том, что клиент отверг предложение сервера. Сервер, выбранный сообщением DHCPREQUEST, осуществляет запись конфигурационного набора клиента в постоянную память и реагирует сообщением DHCPACK, содержащим конфигурационные параметры для клиента, приславшего запрос. Комбинация 'client identifier' или 'chaddr' и присвоенного сетевого адреса представляет собой уникальный идентификатор для времени действия адреса клиента и используется клиентом и сервером для идентификации этого времени в любом DHCP-сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с параметрами из сообщения DHCPOFFER, на которое клиент откликается. Сервер не должен проверять предложенный сетевой адрес. В поле 'yiaddr' сообщений DHCPACK записывается выбранный сетевой адрес.

    Если выбранный сервер не может адекватно реагировать на сообщение DHCPREQUEST (например, запрошенный сетевой адрес уже выделен), сервер должен реагировать посылкой сообщения DHCPNAK.

    Сервер должен пометить адрес, предложенный клиенту в сообщении DHCPOFFER, как доступный, если сервер не получил от клиента никакого сообщения DHCPREQUEST.

    5.

    Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент должен выполнить окончательную проверку параметров (например, запустить ARP для выделенного сетевого адреса), и фиксировать длительность предоставления конфигурационных параметров, прописанную в сообщении DHCPACK. Клиент окончательно сконфигурирован. Если клиент обнаруживает, что адрес уже используется (например, с помощью ARP), он должен послать серверу сообщение DHCPDECLINE и повторно запустить процесс конфигурации. Клиент должен подождать как минимум 10 секунд, прежде чем заново начинать конфигурационную процедуру, чтобы избежать возникновения лишнего сетевого трафика. Если клиент получает сообщение DHCPNAK message, клиент перезапускает конфигурационный процесс.

    Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.

    6.

    Клиент может решить отказаться от аренды сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью своего идентификатора, или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал идентификатор клиента, когда он получил набор конфигурационных параметров, клиент должен использовать тот же идентификатор клиента (client identifier) в сообщении DHCPRELEASE.

    3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов

    Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на рис. 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.

    1.

    Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции 'requested IP-адрес'. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле 'ciaddr'. Агенты транспортировки BOOTP передают сообщение DHCP-серверам за пределами данной субсети. Если клиент использует 'client identifier' для получения своего адреса, клиент должен использовать тот же 'client identifier' в сообщении DHCPREQUEST.

    2.

    Серверы, которые знают конфигурационные параметры клиента, откликаются сообщением DHCPACK. Серверы не должны проверять, используется ли уже сетевой адрес клиента; клиент может реагировать посылкой запроса эхо ICMP.

    Рис. .4. Временная диаграмма обмена сообщениями между DHCP-клиентов и сервером при повторном присвоении ранее использованного сетевого адреса

    Если запрос клиента не корректен (например, клиент переместился в другую субсеть), серверы должны реагировать посылкой клиенту сообщения DHCPNAK. Серверы не должны откликаться, если их информация не абсолютно надежна. Например, сервер, который идентифицирует запрос для набора параметров, который принадлежит другому серверу, и имеет истекший срок действия, сервер не должен реагировать сообщением DHCPNAK, если только серверы не используют явно механизм поддержания когерентности.

    Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARP-запрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в 'giaddr'. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.

    3.

    Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров (как в разделе 3.1), и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается 'client identifier' или 'chaddr' и сетевым адресом. С этого момента клиент считается сконфигурированным.

    Если клиент обнаруживает, что IP-адрес в сообщении DHCPACK уже использован, клиент должен послать сообщение DHCPDECLINE серверу и повторно запустить процесс конфигурации, послав запрос на новый сетевой адрес. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP, которая описана в разделе 4.4.

    Если клиент получает сообщение DHCPNAK, он не может повторно использовать свой запомненный сетевой адрес. Он должен вместо этого запросить новый адрес путем повторного запуска конфигурационного процесса. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP.

    Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, клиент, согласно алгоритму из раздела 4.1, повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента, показанной на рис. 5.

    4.

    Клиент может решить отказаться от сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью 'идентификатора клиента', или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE.

    Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.

    3.3. Интерпретация и представление значений времени

    Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.

    Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.

    Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных.

    3.4. Получение параметров при внешне заданных адресах

    Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.

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

    3.5. Параметры клиента в DHCP

    Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.

    Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'.

    Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.

    Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.

    Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.

    3.6. Применение DHCP для клиентов с несколькими интерфейсами

    Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо.

    3.7. Когда клиентам следует использовать DHCP?

    Клиент должен использовать DHCP для нового запроса или верификации своего IP-адреса и сетевых параметров всякий раз, когда локальные конфигурационные параметры изменились; например, во время перезагрузки системы или после сетевого разрыва, так как локальная сетевая конфигурация может измениться без информирования об этом клиента или пользователя.

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

    4. Спецификация протокола DHCP для системы клиент-сервер

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

    4.1. Формирование и посылка сообщений DHCP

    Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'.

    DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.

    Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора). DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу.

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

    Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и 'giaddr' равно нулю и 'ciaddr' равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу 'yiaddr'. Во всех случаях, когда 'giaddr' равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff.

    Если опции в DHCP-сообщении распространяются на поля 'sname' и 'файл', в поле 'опции' должна появиться опция 'option overload', со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле 'опции' присутствует опция 'option overload', опции в этом поле должны завершаться опцией 'end', и могут содержать один или более опций 'pad' (заполнитель). Опции в полях 'sname' и 'файл' (если их применение индицировано опцией 'options overload') должны начинаться с первого октета поля, завершаться опцией 'end', и за ними для заполнения пространства до конца поля должны следовать опции 'pad'. Любая индивидуальная опция в полях 'опции', 'sname' и 'файл' должна полностью умещаться в поле. Опции в поле 'options' должны интерпретироваться первыми, так чтобы любая 'option overload' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'.

    Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации.

    Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c Ethernet, задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи.

    Поле 'xid' используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее запросом. DHCP-клиент должен выбрать 'xid так чтобы минимизировать вероятность получения идентичных 'xid' разными клиентами. Например, клиент может выбирать разные, случайные начальные 'xid' каждый раз, когда клиент перезагружается, а далее использует инкрементацию этого значения при последующих передачах вплоть до следующей перезагрузки. Выбор нового 'xid' для каждой последующей повторной передачи относится на усмотрение конкретной программной реализации. Клиент может решить повторно использовать то же самое значение 'xid' или выбрать новый 'xid' для передачи каждого сообщения.

    В норме, DHCP-серверы и агенты доставки BOOTP пытаются доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK непосредственно клиенту, используя уникастную адресацию. IP-адрес места назначения (в IP-заголовке) равен адресу 'yiaddr', а адрес связного уровня равен 'chaddr'. К сожалению, некоторые реализации клиентов не могут получать уникастные IP-дейтограммы до тех пор, пока приложение не будет сконфигурировано и клиент не получит корректный IP-адрес (это ведет к тупику, когда IP-адрес не может быть получен клиентом до тех пор, пока в результате конфигурационного процесса он этот самый адрес не получит).

    Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0.

    Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле 'giaddr'), должны анализировать бит BROADCAST поля 'флаги'. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле 'yiaddr'. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff.

    4.2. Административное управление сервером DHCP

    DHCP-серверы не обязаны откликаться на каждое сообщение DHCPDISCOVER и DHCPREQUEST, которое они получают. Например, сетевой администратор с целью сохранения строгого контроля за клиентами, подключенными к сети, может захотеть сконфигурировать DHCP-серверы так, чтобы они реагировали только на клиентов, которые были зарегистрированы ранее с помощью некоторого внешнего механизма. Спецификация DHCP описывает только взаимодействие между клиентами и серверами, когда они хотят этого; описание административного контроля со стороны системного администратора находится вне пределов данной спецификации. Специальные реализации DHCP-серверов могут включать в себя любые механизмы административного контроля.

    При некоторых условиях, DHCP-сервер будет должен проанализировать значения опций vendor class, включенные в сообщения DHCPDISCOVER или DHCPREQUEST с тем, чтобы определить корректные параметры для конкретного клиента.

    DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции 'client identifier'. Если клиент предоставляет 'client identifier', он должен использовать его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию 'client identifier', сервер должен для идентификации клиента использовать содержимое поля 'chaddr'. Для клиента DHCP весьма важно использовать уникальный идентификатор в пределах субсети, к которой он подключен согласно опции 'client identifier'. Использование 'chaddr' в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому клиенту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (из-за переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также использовать в качестве идентификатора клиента DNS-имя.

    Клиенты DHCP вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'.

    4.3. Поведение сервера DHCP

    DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения:

    o DHCPDISCOVER
    o DHCPREQUEST
    o DHCPDECLINE
    o DHCPRELEASE
    o DHCPINFORM

    В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.

    4.3.1. Сообщение DHCPDISCOVER

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

    o

    Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае

    o

    Предшествующий адрес клиента, как это записано в текущем блоке параметров клиента (срок действия которого истек или использование которого прекратилось), если этот адрес находится в пуле доступных адресов сервера, в противном случае

    o

    Адрес запрошенный в опции 'Запрошенный IP-адрес', если адрес корректен и еще не присвоен, в противном случае

    o

    Новый адрес, полученный из пула свободных адресов; адрес выбирается с учетом субсети, откуда получено сообщение (если 'giaddr' = 0) или с учетом адреса агента транспортировки, который доставил сообщение (когда 'giaddr' не равен 0).

    Как это описано в разделе 4.2, сервер может, по административным причинам, присвоить адрес отличный от запрошенного, или может повторно использовать адрес для конкретного клиента, даже если имеются свободные адреса.

    Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.

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

    o

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

    o

    Если клиент не запросил определенное значение времени действия конфигурационного набора в сообщении DHCPDISCOVER и клиент не имеет сетевого адреса, сервер присваивает времени действия набора местное значение по умолчанию, в противном случае

    o

    Если клиент запросил специальный конфигурационный набор параметров в сообщении DHCPDISCOVER (вне зависимости оттого, имел ли он уже сетевой адрес), сервер может либо предоставить запрошенный набор (если это согласуется с местной политикой) или выбрать другой набор.

    Таблица 3. Поля и опции, используемые DHCP-серверами

    Поле

    DHCPOFFER

    DHCPACK

    DHCPNAK

    'op'

    BOOTREPLY

    BOOTREPLY

    BOOTREPLY

    'htype'

    Из RFC "Assigned Numbers"

    'hlen'

    Длина аппаратного адреса в октетах

    'hops'

    0

    0

    0

    'xid'

    'xid' из сообщения клиента DHCPDISCOVER

    'xid' из сообщения клиента DHCPREQUEST

    'xid' из сообщения клиента DHCPREQUEST

    'secs'

    0

    0

    0

    'ciaddr'

    0

    'ciaddr' из DHCPREQUEST или 0

    0

    'yiaddr'

    IP-адрес предложенный клиенту

    IP-адрес присвоенный клиенту

    0

    'siaddr'

    IP-адрес следующего сервера загрузки

    IP-адрес следующего сервера загрузки

    0

    'flags'

    'flags' из сообщения клиента DHCPDISCOVER

    флаги' из сообщения клиента DHCPREQUEST

    'flags' из сообщения клиента DHCPREQUEST

    'giaddr'

    'giaddr' из сообщения клиента DHCPDISCOVER

    'giaddr' из сообщения клиента DHCPREQUEST

    'giaddr' >из сообщения клиента DHCPREQUEST

    'chaddr'

    'chaddr' из сообщения клиента DHCPDISCOVER

    'chaddr' из сообщения клиента DHCPREQUEST

    'chaddr' из сообщения клиента DHCPREQUEST

    'sname'

    Имя ЭВМ сервера
    или опции

    Имя ЭВМ сервера
    или опции

    (не используется)

    'файл'

    Файл загруз. клиента
    имя или опции

    Файл загруз. клиента
    имя или опции

    (не используется)

    'опции'

    опции

    опции

    Опция

    DHCPOFFER

    DHCPACK

    DHCPNAK

    Запрошенный IP-адрес

    не должен

    не должен

    не должен

    IP-адрес lease time

    должен

    должен (DHCPREQUEST)
    не должен (DHCPINFORM)

    не должен

    Использование полей 'файл'/'sname'

    может

    может

    не должен

    Тип сообщения DHCP

    DHCPOFFER

    DHCPACKDHCPNAK

    Список параметров

    не должен

    не должен

    не должен

    Сообщение

    должен

    должен

    должен

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

    не должен

    не должен

    может

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

    может

    может

    может

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

    должен

    должен

    должен

    Макс. размер сообщения

    не должен

    не должен

    не должен

    Все прочие

    может

    может

    не должен

    Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами. Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением - новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:

    o

    Сетевой адрес клиента, как это определено правилами приведенными выше,

    o

    Время действия клиентского набора, как это определено правилами из данного раздела,

    o

    Параметры, запрошенные клиентом, согласно следующим правилам:

    - Если в сервере явно задано значение параметра по умолчанию, сервер должен включить это значение в соответствующую опцию поля 'option', в противном случае

    - Если сервер распознает параметр, как параметр, определенный в документе Host Requirements, сервер должен включить его значение по умолчанию (как это рекомендуется в документе Host Requirements), в соответствующую опцию в поле 'option', в противном случае

    - Сервер не должен присылать значение этого параметра

    Сервер должен предоставить столько запрошенных параметров, сколько возможно, должен опустить любые параметры, которые не может предоставить. Сервер должен включить каждый запрошенный параметр только один раз, если только не разрешено обратного в опциях DHCP и в документе Vendor Extensions BOOTP.

    o

    Любые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements,

    o

    Любые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором,

    o

    Любые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором;

    o

    Параметры со значениями, неравными величинам по умолчанию для клиентской субсети.

    Сервер может прислать 'vendor class identifier', использованный чтобы определить параметры в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле 'xid' из сообщения DHCPDISCOVER в поле 'xid' сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER.

    4.3.2. Сообщение DHCPREQUEST

    Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию 'server identifier', то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует 'client identifier' в сообщении DHCPREQUEST, он должен использовать его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом:

    o DHCPREQUEST, сформированный в состоянии SELECTING:

    Клиент вводит адрес выбранного сервера 'server identifier', 'ciaddr' должен быть равен нулю, в 'запрошенный IP-адрес' должно быть записано значение yiaddr, взятое из DHCPOFFER.

    Заметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать наилучшее предложение. Клиент определяет свой выбор путем идентификации сервера в сообщении DHCPREQUEST. Если клиент получает неприемлемые предложения, клиент может попробовать другое сообщение DHCPDISCOVER. Следовательно, серверы не могут получить DHCPREQUEST, из которого они могли бы решить, принял ли клиент данное предложение. Так как серверы не осуществили присвоение какого-либо сетевого адреса на основе DHCPOFFER, они вольны повторно использовать предложенные сетевые адреса в откликах на последующие запросы. Серверы не должны повторно использовать предложенные адреса и могут реализовать зависимый от реализации механизм таймаутов в процессе принятия решения о повторном использовании предложенных адресов.

    o DHCPREQUEST генерируется в состоянии INIT-REBOOT:

    Поле 'server identifier' не должно быть заполнено, в опции 'Запрошенный IP-адрес' должен быть записан предшествующий адрес, присвоенный клиенту. 'ciaddr' должен быть равен нулю. Клиент пытается верифицировать присвоенный ранее конфигурационный набор. Сервер должен клиенту послать сообщение DHCPNAK, если 'запрошенный IP-адрес' не корректен, или относится к неверной сети.

    Определение того, находится ли клиент в состоянии INIT-REBOOT, осуществляется просмотром содержимого 'giaddr', опции 'requested IP-адрес', и базы данных. Если DHCP-сервер обнаружит, что клиент находится не в той сети (т.e., результат наложения локальной маски субсети или маски удаленной субсети (если 'giaddr' не равно нулю) на опцию 'запрошенный IP-адрес' выдает не реальный результат), тогда сервер должен послать клиенту сообщение DHCPNAK. Если с сетью все в порядке, тогда DHCP-сервер должен проверить, корректна ли запись клиента о его IP-адресе. Если нет, сервер должен послать клиенту сообщение DHCPNAK. Если DHCP-сервер не имеет записи об этом клиенте, тогда он должен оставаться пассивным, и может выдать предупреждение сетевому администратору.

    Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент не может иметь корректный сетевой адрес или сетевую маску, и клиент не может откликаться на ARP-запросы.

    Если в сообщении DHCPREQUEST установлен 'giaddr', клиент находится в другой субсети. Сервер должен установить широковещательный бит в DHCPNAK, агент отклика пошлет клиенту сообщение DHCPNAK широковещательно, так как клиент может не иметь корректного сетевого адреса или сетевой маски, и клиент может не откликаться на ARP-запросы.

    o DHCPREQUEST генерируется в состоянии RENEWING:

    'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как 'giaddr' не заполнен, DHCP-сервер будет полагаться на значениеn 'ciaddr', и использовать его при передаче данных клиенту.

    Клиент может пожелать обновить или расширить время действия конфигурационного набора до T1. Сервер может пожелать не расширять время действия (например, по решению сетевого администратора), но должен в любом случае откликнуться сообщением DHCPACK.

    o DHCPREQUEST генерируется в состоянии REBINDING:

    'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается увеличить время действия набора параметров. Это сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. DHCP-сервер должен проверить корректность 'ciaddr' прежде чем откликаться на DHCPREQUEST. DHCPREQUEST от клиента в состоянии REBINDING имеет целью согласовать узлы, имеющие несколько DHCP-серверов, а также предложить механизм для согласования времен действия конфигурационных наборов, предлагаемых разными серверами. DHCP-сервер может расширить время действия набора параметров клиента, только если он имеет для этого административные привилегии.

    4.3.3. Сообщение DHCPDECLINE

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

    4.3.4. Сообщение DHCPRELEASE

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

    4.3.5. Сообщение DHCPINFORM

    Сервер реагирует на сообщение DHCPINFORM посылкой сообщения DHCPACK непосредственно по адресу, записанному в поле 'ciaddr' сообщения DHCPINFORM. Сервер не должен уведомлять клиента об истечении времени действия конфигурационного набора и не должен производить запись в 'yiaddr'. Сервер включает в сообщение DHCPACK другие параметры, как это определено в разделе 4.3.1.

    4.3.6. Сообщения клиента

    Таблица 4 характеризует различие между сообщениями клиента в различных состояниях

    Таблица 4. Сообщения клиента для различных состояний

    INIT-REBOOT

    SELECTING

    RENEWING

    REBINDING

    broad/unicast

    Широковещ.

    Широковещ

    Уникастный

    Широковещ

    server-ip

    Не должен

    Должен

    Не должен

    Не должен

    Запрошенный IP

    Должен

    Должен

    Не должен

    Не должен

    ciaddr

    нуль

    нуль

    IP адрес

    IP адрес

    4.4. Поведение клиента DHCP

    На рис. 5 представлена диаграмма состояний для DHCP-клиента. Клиент может получить следующие сообщения от сервера:

    o DHCPOFFER
    o DHCPACK
    o DHCPNAK

    Сообщение DHCPINFORM не показано на рис. 5. Клиент просто посылает DHCPINFORM и ждет сообщения-отклика DHCPACK. Раз клиент выбрал свои параметры, он завершил процесс конфигурации.

    Таблица 5 описывает использование полей и опций DHCP-сообщения клиента.

    Рис. 5. Диаграмма состояний DHCP-клиента

    4.4.1. Инициализация и выделение сетевого адреса

    Клиент начинает работу в состоянии INIT и формирует сообщение DHCPDISCOVER. Клиент должен ждать случайное время в интервале 1-10 секунд, для того чтобы десинхронизовать процессы при запуске DHCP. Клиент устанавливает 'ciaddr' равным 0x00000000. Клиент может запросить специфические параметры путем включения опции 'parameter request list'. Клиент может предложить сетевой адрес и/или время действия набора параметров путем включения опций 'запрошенный IP-адрес' и 'IP-address lease time'. Клиент должен включить его аппаратный адрес в поле 'chaddr', если это необходимо для доставки DHCP-откликов. Клиент может включить уникальный идентификатор в опцию 'client identifier', как это описано в разделе 4.2. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включать этот список во все последующие сообщения.

    Клиент генерирует и записывает случайный идентификатор транзакции, вставляет этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для использования позднее при вычислении времени пригодности набора конфигурационных параметров. Клиент затем посылает широковещательно DHCPDISCOVER по локальному аппаратному адресу 0xffffffff, по широковещательному IP-адресу и UDP-порту 'DHCP-сервера'.

    Если 'xid' приходящего сообщения DHCPOFFER не согласуется с 'xid' последнего сообщения DHCPDISCOVER, сообщение DHCPOFFER должно молча игнорироваться. Любое приходящее сообщение DHCPACK должно молча игнорироваться.

    Клиент собирает сообщения DHCPOFFER за определенный период времени, выбирает одно сообщение DHCPOFFER из числа приходящих сообщений DHCPOFFER (например, первое сообщение DHCPOFFER или сообщение DHCPOFFER от сервера, используемого ранее) и извлекает адрес сервера из опции 'server identifier' сообщения DHCPOFFER. Время, в течение которого клиент собирает сообщения, и механизм, используемый для выбора одного DHCPOFFER зависит от конкретной реализации.

    Таблица 5. Поля и опции, используемые клиентами DHCP

    Поле

    DHCPDISCOVER
    DHCPINFORM

    DHCPREQUEST

    DHCPDECLINE,
    DHCPRELEASE

    'op'

    BOOTREQUEST

    BOOTREQUEST

    BOOTREQUEST

    'htype'

    Из RFC"Assigned Numbers"

    'hlen'

    Длина аппаратного адреса в октетах

    'шаги'

    0

    0

    0

    'xid'

    выбрано клиентом

    'xid' из сообщения сервера DHCPOFFER

    выбрано клиентом

    'secs'

    0 или число сек с момента, когда HCP-процесс запущен

    0 или число сек со времени, когдаDHCP- процесс запущен

    0

    'флаги'

    Устанавливает 'BROADCAST'-флаг, если клиент требует широковещательного отклика

    Устанавливает 'BROADCAST' флаг, если клиент требует широковещательного отклика

    0

    'ciaddr'

    0 (DHCPDISCOVER) сетевой адрес клиента(DHCPINFORM)

    0 или сетевой адрес клиента (BOUND/RENEW/REBIND)

    0 (DHCPDECLINE) сетевой адрес клиента (DHCPRELEASE)

    'yiaddr'

    0

    0

    0

    'siaddr'

    0

    0

    0

    'giaddr'

    0

    0

    0

    'chaddr'

    аппаратный адрес клиента аппаратный адрес клиента аппаратный адрес клиента

    'sname'

    опции, если указано в 'sname/file' опция; иначе не используется

    опции, если указано в 'sname/file' опция; иначе не используется

    (не используется)

    'файл'

    опции, если указано в 'sname/file' опция; иначе не используется

    опции, если указано в 'sname/file' опция; иначе не используется

    (не используется)

    'опции'

    опции

    опции

    (не используется)

    Опция

    DHCPDISCOVER
    DHCPINFORM

    DHCPREQUEST

    DHCPDECLINE,
    DHCPRELEASE

    Requested IP-address

    Может (DISCOVER)
    не должен (INFORM)

    Должен (в SELECTING или INIT-REBOOT)
    не должен (в BOUND или RENEWING)

    Должен (DHCPDECLINE),
    не должен (DHCPRELEASE)

    IP-address lease time

    Может (DISCOVER)
    не должен (INFORM)

    Может

    Не должен

    Использование полей 'file'/'sname'

    Может

    Может

    Может

    Тип сообщения DHCP

    DHCPDISCOVER/ DHCPINFORM

    DHCPREQUEST

    DHCPDECLINE/ DHCPRELEASE

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

    Может

    Может

    Может

    Vendor class identifier

    Может

    Может

    Не должен

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

    Не должен

    Должен (после SELECTING)

    Не должен (после INIT-REBOOT, BOUND, RENEWING или REBINDING)

    Должен

    Parameter request list

    Может

    Может

    Не должен

    Maximum message size

    Может

    Может

    Не должен

    Message

    Не следует

    Не следует

    Следует

    Site-specific

    Может

    Может

    Не должен

    Прочие

    Может

    Может

    Не должен

    Если параметры приемлемы, клиент записывает адрес сервера, который предоставляет параметры из поля 'server identifier' и посылает этот адрес в поле 'server identifier' широковещательного сообщения DHCPREQUEST. Раз от сервера пришло сообщение DHCPACK, клиент инициализирован и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит тот же 'xid' что и сообщение DHCPOFFER. Клиент записывает время истечения действия конфигурационного набора как сумму времени, когда был послан исходный запрос и длительности действия конфигурационного набора из сообщения DHCPACK. Клиент должен выполнить проверку предложенного адреса, чтобы убедиться, что адрес не используется. Например, если клиент находится в сети, которая поддерживает ARP, клиент может послать запрос ARP для предложенного адреса. При посылке широковещательного ARP-запроса для предлагаемого адреса, клиент должен записать туда, как отправитель, свой аппаратный адрес, и 0 в качестве IP-адреса отправителя, чтобы исключить конфликт с ARP-кэшами в других ЭВМ той же субсети. Если оказалось, что сетевой адрес используется, клиент должен послать серверу сообщение DHCPDECLINE. Клиент должен широковещательно послать ARP-отклик, чтобы уведомить о новом IP-адресе клиента и удалить устаревшие записи из ARP-кэша ЭВМ, размещенных в той же субсети.

    4.4.2. Инициализация при известном сетевом адресе

    Клиент начинает работу в состоянии INIT-REBOOT и посылает сообщение DHCPREQUEST. Клиент должен вставить свой сетевой адрес в опцию 'requested IP-адрес' сообщения DHCPREQUEST. Клиент может запросить специфические конфигурационные параметры, включив опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и заносит этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для последующего использования при вычислении времени истечения пригодности конфигурационного набора параметров. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST. Клиент затем широковещательно посылает DHCP-серверу сообщение DHCPREQUEST с использованием аппаратного широковещательного адреса и UDP-порта.

    Раз от какого-то сервера пришло сообщение DHCPACK с полем 'xid' согласующимся с тем, которое содержится в сообщении клиента DHCPREQUEST, клиент инициализирован и он переходит в состояние BOUND. Клиент записывает время истечения годности конфигурационного набора параметров, которое равно сумме времени, когда было послано сообщение DHCPREQUEST и длительности пригодности конфигурационного набора, взятого из сообщения DHCPACK.

    4.4.3. Инициализация при сетевом адресе заданном извне

    Клиент посылает сообщение DHCPINFORM, клиент может запросить специфические конфигурационные параметры путем включения их в опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и вводит его в поле 'xid'. Клиент помещает свой сетевой адрес в поле 'ciaddr'. Клиенту не следует запрашивать параметры времени действия конфигурационного набора.

    Клиент посылает уникастное сообщение DHCPINFORM DHCP-серверу, если он знает адрес сервера, в противном случае он посылает это сообщение широковещательно. Сообщения DHCPINFORM должны быть направлены 'DHCP-серверу ' через UDP-порт.

    Раз от любого из серверов получено сообщение DHCPACK с полем 'xid', согласующимся с тем, что содержалось в сообщении клиента DHCPINFORM, клиент инициализирован.

    Если клиент не получил DHCPACK в пределах разумного временного интервала (60 секунд или 4 попыток, если используется таймауты, предложенные в разделе 4.1), тогда клиент должен выдать сообщение пользователю, уведомляющее его о возникшей проблеме, а затем продолжить сетевую активность, используя разумные значения по умолчанию из приложения A.

    4.4.4. Использование широковещательной и уникастной адресации

    DHCP-клиент широковещательно посылает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, если только клиент не знает адреса DHCP-сервера. Клиент посылает сообщения DHCPRELEASE серверу уникастно. Так как клиент отказывается использовать IP-адрес, предоставленный сервером, он посылает сообщения DHCPDECLINE широковещательно.

    Когда DHCP-клиент знает адрес DHCP-сервера, в состоянии INIT или REBOOTING, клиент может использовать адрес, записанный в DHCPDISCOVER или DHCPREQUEST, а не широковещательный IP-адрес. Клиент может также использовать уникастную адресацию при посылке сообщений DHCPINFORM известному DHCP-серверу. Если клиент не получает отклика на DHCP-сообщение, посланное по IP-адресу известного DHCP-сервера, DHCP-клиент переходит на широковещательную адресацию.

    4.4.5. Восстановление и истечение пригодности

    Клиент поддерживает две временные переменные, T1 и T2, которые специфицируют времена, когда клиент пытается расширить время действия своего сетевого адреса. T1 равно времени, когда клиент попадает в состояние RENEWING и пытается контактировать с сервером, который предоставил клиенту сетевой адрес. T2 равно времени, когда клиент перешел в состояние REBINDING и пытается контактировать с каким-то сервером. T1 должно быть раньше T2, которое в свою очередь, должно быть раньше, чем время, когда истекает период годности конфигурационного набора параметров.

    Чтобы исключить необходимость синхронизации часов, T1 и T2 выражаются в опциях в относительных единицах [2].

    В момент T1 клиент переходит в состояние RENEWING и посылает серверу (уникастно) сообщение DHCPREQUEST с тем, чтобы продлить действие набора конфигурационных параметров. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент записывает локальное время, когда было послано сообщение DHCPREQUEST. Клиент не должен включать идентификатор сервера в сообщение DHCPREQUEST.

    Любые сообщения DHCPACK, которые приходят с 'xid', не согласующимся с 'xid' из сообщения клиента DHCPREQUEST, игнорируются. Когда клиент получает от сервера DHCPACK, он вычисляет время истечения пригодности конфигурационного набора параметров (равно сумме времени, когда клиент посылал сообщение DHCPREQUEST и длительности пригодности конфигурационного набора параметров из сообщения DHCPACK). Клиент успешно восстанавливает свой сетевой адрес, возвращается в состояние BOUND и может продолжить свою сетевую активность.

    Если не приходит никакого DHCPACK до T2, клиент переходит в состояние REBINDING и посылает широковещательно сообщение DHCPREQUEST с целью расширения времени действия конфигурационного набора. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST.

    Времена T1 и T2 конфигурируются сервером посредством опций. T1 по умолчанию равно (0.5 * duration_of_lease). T2 по умолчанию равно (0.875 * duration_of_lease). Чтобы исключить синхронизацию восстановления состояния клиентов, времена T1 и T2 должны быть выбраны с некоторым случайным разбросом относительно фиксированных значений.

    Клиент может решить обновить или продлить время действия конфигурационного набора вплоть до T1. Сервер может решить расширить длительность пригодности конфигурационного набора параметров в соответствии с политикой сетевого администратора.

    Как в состоянии RENEWING, так и в REBINDING, если клиент не получает отклика на свое сообщение DHCPREQUEST. Клиент должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST.

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

    4.4.6. Сообщение DHCPRELEASE

    Если клиент более не нуждается в использовании своего сетевого адреса (например, клиент завершил работу через shutdown), клиент посылает серверу сообщение DHCPRELEASE. Заметим, что корректная работа DHCP не зависит от передачи сообщений DHCPRELEASE.

    5. Ссылки

    [1]

    Acetta, M., "Resource Location Protocol", RFC-887, CMU, December 1983.

    [2]

    Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-1533, Lachman Technology, Inc., Bucknell University, October 1993.

    [3]

    Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC-1122, USC/Information Sciences Institute, October 1989.

    [4]

    Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC-1123, USC/Information Sciences Institute, October 1989.

    [5]

    Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress.

    [6]

    Comer, D., and R. Droms, "Uniform Access to Internet Directory Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer Communications Review), 20(4):50--59, 1990.

    [7]

    Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC-951, Stanford and SUN Microsystems, September 1985.

    [8]

    Deering, S., "ICMP Router Discovery Messages", RFC-1256, Xerox PARC, September 1991.

    [9]

    Droms, D., "Interoperation between DHCP and BOOTP", RFC-1534, Bucknell University, October 1993.

    [10]

    Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC-903, Stanford, June 1984.

    [11]

    Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", In Proc. of the Twelfth ACM Symposium on Operating Systems Design, 1989.

    [12]

    Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC-1034, USC/Information Sciences Institute, November 1987.

    [13]

    Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC-1035, USC/Information Sciences Institute, November 1987.

    [14]

    Mogul J., and S. Deering, "Path MTU Discovery", RFC-1191, November 1990.

    [15]

    Morgan, R., "Dynamic IP-адрес Assignment for Ethernet Attached Hosts", Work in Progress.

    [16]

    Postel, J., "Internet Control Message Protocol", STD 5, RFC-792, USC/Information Sciences Institute, September 1981.

    [17]

    Reynolds, J., "BOOTP Vendor Information Extensions", RFC-1497, USC/Information Sciences Institute, August 1993.

    [18]

    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC-1700, USC/Information Sciences Institute, October 1994.

    [19]

    Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP-адресes for use on an Ethernet. (Available from the Athena Project, MIT), 1989.

    [20]

    Sollins, K., "The TFTP Protocol (Revision 2)", RFC-783, NIC, June 1981.

    [21]

    Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC-1542, Carnegie Mellon University, October 1993.

    [22]

    G. Stump, R. Droms, Y. Gu, R., Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. The User Class Option for DHCP, RFC-3004, November 2000.

    [23]

    M. Patrick, DHCP Relay Agent Information Option. RFC-3046, January 2001.

    [24]

    http://www.dhcp-handbook.com/dhcp_faq.html

    [25]

    S. Alexander, DHCP Options and BOOTP Vendor Extensions, RFC-2132, March 1997

    A. Параметры конфигурации ЭВМ

    IP-layer_parameters,_per_host:_

    Быть маршрутизатором

    on/off

    HRC 3.1

    Non-local source routing

    on/off

    HRC 3.3.5

    Фильтры для non-local source routing

    (список)

    HRC 3.3.5

    Maximum reassembly size

    целое

    HRC 3.3.2

    TTL по умолчанию

    целое

    HRC 3.2.1.7

    PMTU aging timeout

    целое

    MTU 6.6

    MTU plateau table

    (список)

    MTU 7

    IP-layer_parameters,_per_interface:

    IP -адрес
    Маска субсети
    MTU
    All-subnets-MTU
    Широковещательный адрес
    Определить маску
    Быть поставщиком масок
    Выполнять поиск маршрутизатора
    Router solicitation address

    (адрес)

    HRC 3.3.1.6

    (маска адреса)

    HRC 3.3.1.6

    целое

    HRC 3.3.3

    on/off

    HRC 3.3.3

    0x00000000/0xffffffff

    HRC 3.3.6

    on/off

    HRC 3.2.2.9

    on/off

    HRC 3.2.2.9

    on/off

    RD 5.1

    (адрес)

    RD 5.1

    Маршрутизаторы по умолчанию:

    Адрес маршрутизатора

    (адрес)

    HRC 3.3.1.6

    Уровень предпочтения

    целое

    HRC 3.3.1.6

    Статические маршруты, список:

    Место назначения

    (host/subnet/net)

    HRC 3.3.1.2

    Маска места назначения

    (маска адреса)

    HRC 3.3.1.2

    Тип услуг

    целое

    HRC 3.3.1.2

    Соседний маршрутизатор

    (адрес)

    HRC 3.3.1.2

    Игнорирование переадресации

    on/off

    HRC 3.3.1.2

    PMTU

    целое

    MTU 6.6

    Выполнить поиск PMTU

    on/off

    MTU 6.6

    Link-layer_parameters,_per_interface:_

    Trailers

    on/off

    HRC 2.3.1

    Таймаут ARP кэша

    целое

    HRC 2.3.2.1

    Инкапсуляция Ethernet

    RFC-894/RFC-1042

    HRC 2.3.3

    TCP_parameters,_per_host:_

    TTL

    целое

    HRC 4.2.2.19

    Интервал Keep-alive

    целое

    HRC 4.2.3.6

    Размер данных Keep-alive

    0/1

    HRC 4.2.3.6

    Key:
    MTU = Path MTU Discovery (RFC-1191, предлагаемый стандарт)
    RD = Router Discovery (RFC-1256, предлагаемый стандарт)

    Опция DHCP для протокола аутентификации пользователей открытых групп
    (RFC-2485, S. Drach, DHCP Option for The Open Group's User Authentication Protocol)

    Технический стандарт для клиента вычислительной сети разработан рабочей группой по сетевым вычислениям NCWG (Network Computing Working Group), он определяет схему аутентификации клиента-пользователя в вычислительной сети, которая носит название протокола аутентификации пользователя (UAP).

    UAP предлагает два уровня аутентификации, базовый и безопасный. Базовая аутентификация использует механизм, определенный в спецификации HTTP 1.1 [3]. Безопасная аутентификация является просто аутентификацией реализованной в рамках сессии SSLv3 [4].

    В обоих случаях клиент UAP должен получить IP-адрес и номер порта службы UAP. В зависимости от реализации системы может потребоваться дополнительная информация о проходе. URL [5] представляет прекрасный механизм инкапсуляции этой информации, так как многие серверы UAP реализуются как часть HTTP/SSL-серверов.

    Большинство клиентов UAP конфигурируются при загрузке через DHCP. Ни одна из существующих опций DHCP [6] не имеет информационных полей, содержащих URL. Опция 72 содержит список IP-адресов WWW-серверов, но она не адекватна задаче, так как нельзя специфицировать номер порта и/или проход. Следовательно, нужна опция, которая содержит список URL.

    Опция протокола аутентификации пользователя

    Эта опция специфицирует список URL, каждый из которых указывает на сервер аутентификации пользователя, способный обрабатывать запросы, реализуемые через протокол UAP. Серверы UAP могут воспринимать соединения HTTP 1.1 или SSLv3. Если список содержит URL, который не содержит данных о номере порта, присваивается значение порта по умолчанию (т.e., порт 80 для http и порт 443 для https). Если список включает в себя URL, который не содержит данных о проходе, предполагается проход /uap. На рис. 1 показан формат опции аутентификации пользователя.

    Рис. .1. Формат опции аутентификации пользователя

    Код

    98

    Длина

    длина поля данных (т.e., списка URL) в байтах.

    Список URL

    Список из одного или более URL, разделенных символами ASCII (0x20) пробел. Поле список URL имеет переменную длину.

    Ссылки

    [1]

    Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997.

    [2]

    Technical Standard: Network Computing Client, The Open Group, Document Number C801, October 1998.

    [3]

    Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC-2068, January 1997.

    [4]

    Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol, Version 3.0", Netscape Communications Corp., November 1996. Standards Information Base, The Open Group, http://www.db.opengroup.org/sib.htm#SSL_3.

    [5]

    Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994.

    [6]

    Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997.

    Previous: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.13 Протокол управления SNMP


    previous up down next index index
    Previous: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.14.5 Программа Sendmail

    4.4.14.4 Многоцелевое расширение почты Интернет (MIME)
    Семенов Ю.А. (ГНЦ ИТЭФ)


    Формат тела Интернет сообщений

    Стандарт STD 11, RFC 822 определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII. Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.

    1. Передача текстовых сообщений с символьным набором, отличным от US-ASCII.
    2. Передача сообщений нетекстового формата (например, звукового письма).
    3. Использование комбинированных сообщений, содержащих разнородные части.
    4. Размещение в заголовке информации в символьном наборе, отличном от US-ASCII.

    Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию.

    1. Введение

    Документ RFC 822, который прослужил без малого 20 лет, регламентировал работу лишь с текстовыми сообщениями (передача аудио- видео- или графических сообщений в нем не рассматривалась). Но даже в случае чисто текстовых документов возникали проблемы при работе с языковыми наборами, требующими символов, которые отсутствуют в US-ASCII.

    Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).

    Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения.

    В протоколе MIME регламентируется следующее:

    1. Поле заголовка MIME-Version, которое характеризует версию протокола и позволяет почтовым агентам согласовать свои возможности и исключить конфликты с устаревшим программным обеспечением.
    2. Поле заголовка Content-Type, которое используется для спецификации типа среды и субтипа данных в теле сообщения, а также для описания канонической формы этих данных.
    3. Поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования.
    4. Два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).

    Важно заметить, что основополагающими принципами при создании MIME была совместимость с существующими стандартами и надежность работы. Для тех, кто попытается реализовать протокол MIME, определенный интерес могут представлять документы RFC 1344, RFC 1345 и RFC 1524.

    Далее все цифровые величины и октеты приводятся в десятичном представлении. Все значения типа среды, субтипы и имена параметров безразличны к регистру их написания. Значения параметров, напротив, зависимы от того строчными или прописными буквами они записаны.

    Терм CRLF в данном описании относится к последовательности октетов, соответствующих ASCII-символам CR (десятичный код 13) и LF (десятичный код 10), которые обозначают разрыв строки.

    Терм "символьный набор" используется в MIME для того, чтобы обозначить метод преобразования последовательности октетов в последовательность символов. Заметим, что безусловное и однозначное преобразование в обратном направлении не требуется, то есть не все символы могут быть представлены через данный символьный набор (более чем одна последовательность октетов может соответствовать одной и той же последовательности символов).

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

    Термин "символьный набор" был первоначально введен для описания прямых схем преобразования, таких как ASCII и ISO-8859-1, для которых характерна однозначная связь символов и кодовых октетов. Многооктетные кодированные символьные наборы и методики переключения несколько осложнили ситуацию.

    Термин "сообщение", обозначает сообщение типа RFC 822, передаваемое по сети, или сообщение, инкапсулированное в тело типа "message/rfc822" или "message/partial".

    Термин "объект" (entity) относится к полям заголовка MIME и содержимому сообщения или его части в случае, если оно составное. Спецификация таких объектов определяется исключительно MIME. Так как содержимое объекта часто называется "тело", имеет смысл говорить о теле объекта. Любой вид поля может быть представлен в заголовке объекта, но только поля, имена которых начинаются с "content-" имеют значение, связанное с протоколом MIME.

    Выражение "7-битовые данные" относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Октеты с кодом больше чем 127 или равные нулю не допустимы. Октеты CR (десятичный код 13) и LF (десятичный код 10) могут встречаться только в виде последовательности, отмечающей конец строки.

    Выражение "8-битовые данные " относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Но здесь допустимы октеты с десятичными значениями кодов, превышающими 127 (нулевые коды не допускаются).

    "Строки" в данном контексте представляют собой последовательности октетов, завершающиеся CRLF. Это согласуется с документами RFC 821 и RFC 822.

    2. Поля заголовка MIME

    MIME определяет ряд новых полей заголовков по сравнению с RFC 822. Они описывают содержимое MIME-объекта. Эти поля заголовков используются в двух контекстах:

    1. В качестве части стандартного заголовка RFC 822.
    2. В MIME-заголовке в рамках составной конструкции сообщения.

    Ниже представлено формальное описание этих полей заголовка.

    entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ]
    *( MIME-extension-field CRLF )
    MIME-message-headers := entity-headers fields version CRLF

    ; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

    MIME-part-headers := entity-headers [ fields ]

    ; Любое поле, не начинающееся с "content-" не может иметь какого-либо значения и может игнорироваться.

    ; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

    3. Поле заголовка MIME-Version

    Так как документ RFC 822 был опубликован в 1982, там имелся только один формат для сообщений, передаваемых по каналам Интернет, и по этой причине не было необходимости декларировать тип такого стандарта. MIME является независимым дополнением документа RFC 822. Хотя протокол MIME строился так, чтобы обеспечить совместимость с RFC 822, бывают обстоятельства, когда почтовому агенту желательно выяснить, составлено ли сообщение с учетом нового стандарта. Поле заголовка "MIME-Version" служит как раз для того, чтобы можно было определить, какому стандарту соответствует тело сообщения. Сообщения, соответствующие MIME обязаны содержать такое поле заголовка со следующим текстом:

    MIME-Version: 1.0

    Присутствие этого поля заголовка означает, что сообщение подготовлено согласно требованиям MIME. Так как существует возможность того, что в будущем формат документов может быть изменен, формальное BNF-представление поля MIME-Version следует записать следующим образом:

    version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

    Таким образом, будущие спецификаторы формата, которые могут заменить версию "1.0", ограничены двумя цифровыми полями, разделенными точкой. Если сообщение получено со значением поля MIME-version, отличным от "1.0", оно может не соответствовать данному описанию.

    Заметим, что поле заголовка MIME-Version должно располагаться в самом начале сообщения. При составном сообщении не требуется, чтобы каждая из частей начиналась с поля версии. Это необходимо лишь в случае, когда заголовки встроенных сообщений типа "message/rfc822" или "message/partial" объявляют о совместимости со стандартом MIME.

    Для некоторых приложений согласование версий должно проводиться независимо. Некоторые форматы (такие как application/postscript) имеют внутреннюю систему нумерации версий для каждого типа среды. Там где имеет место такое соглашение, MIME не предпринимает попыток подменить эту систему. Там где такого соглашения нет, тип среды MIME может использовать параметр "version" в поле типа содержимого. При проверке значений MIME-Version любые строки комментария RFC 822 должны игнорироваться. В частности, следующие четыре записи поля MIME-Version эквивалентны.

    MIME-Version: 1.0
    MIME-Version: 1.0 (produced by MetaSend Vx.x)
    MIME-Version: (produced by MetaSend Vx.x) 1.0
    MIME-Version: 1.(produced by MetaSend Vx.x)0

    В отсутствии поля MIME-Version, принимающий почтовый агент (следующий стандарту MIME или нет) может опционно интерпретировать сообщения согласно локальным соглашениям.

    Нельзя быть уверенным, что почтовое сообщение, не согласованное с MIME, является непременно обычным текстом в кодировке ASCII, так как оно может содержать код согласно локальному соглашению (например, результат работы процедуры UUTNCODE или какого-то архиватора).

    4. Поле заголовка Content-Type

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

    Поле заголовка Content-Type было первым, определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, в прочем, вполне согласуется с регламентациями MIME.

    Поле заголовка Content-Type специфицирует природу данных в теле объекта, сообщая тип среды и идентификаторы субтипа, а также предоставляя вспомогательную информацию, которая может требоваться для определенного типа среды. После типа среды и имен субтипов может следовать набор параметров, который описывается в нотации атрибут = значение. Порядок параметров не имеет значения. Тип среды верхнего уровня используется для декларирования общего типа данных, в то время как субтип определяет специфический формат информации. Таким образом, типа среды "image/xyz" достаточно, чтобы сообщить агенту пользователя, что данные представляют собой изображение, даже если агент пользователя не имеет представления о формате изображения "xyz". Такая информация может использоваться, например, для того чтобы решить, следует ли показывать пользователю исходные данные нераспознанного субтипа. Такая операция разумна для нераспознанного субтипа текста, но бессмысленна для изображения или звука. По этой причине, зарегистрированные субтипы текста, изображения, аудио и видео не должны содержать вложенной информации другого типа. Такой составной формат должен быть представлен с использованием "multipart" или "application" типов.

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

    Например, параметр "charset" применим к любому субтипу "текста", в то время как параметр "boundary" необходим для любого субтипа типа среды "multipart". Не существует параметров, применимых для всех типов среды.

    Исходный набор из семи типов среды верхнего уровня определен в документе RFC 2046. Пять из них являются дискретными типами. Остальные два являются составными типами, чье содержимое требует дополнительной обработки процессорами MIME.

    Этот набор типов среды верхнего уровня является замкнутым. Предполагается, что необходимые расширения набора могут осуществляться за счет введения субтипов к существующим базовым типам. В будущем, расширение базового набора допустимо лишь при смене стандарта. Если необходим какой-то новый базовый тип среды, его имя должно начинаться с "X-", что указывает на то, что он не является стандартным.

    4.1. Синтаксис поля заголовка Content-Type

    В нотации BNF, значение поля заголовка Content-Type определяется следующим образом:

    content

    :=

    "Content-Type" ":" type "/" subtype *(";" parameter)

    ; Распознавание типа и субтипа среды всегда не зависит от регистра, в котором они напечатаны.

    type

    :=

    discrete-type / composite-type

    discrete-type

    :=

    "text" / "image" / "audio" / "video" / "application" / extension-token

    composite-type

    :=

    "message" / "multipart" / extension-token

    extension-token

    :=

    ietf-token / x-token

    ietf-token

    :=

    <Лексема расширения, определенная стандартом RFC и зарегистрированная IANA.>

    x-token

    :=

    <Два символа "X-" или "x-", за которыми следует без пробела лексема (token)>

    subtype

    :=

    extension-token / iana-token

    iana-token

    :=

    <Общедоступная лексема расширения. Лексемы этой формы должны быть зарегистрированы IANA, как это указано в RFC 2048.>

    parameter

    :=

    attribute "=" value

    attribute

    :=

    token

    ; Распознавание атрибутов не зависит от регистра, в котором они напечатаны.

    value

    :=

    token / quoted-string

    token

    :=

    1*

    tspecials

    :=

    "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="

    ; Должно представлять собой строку в кавычках

    Заметим, что определение "tspecials" совпадает с определением "specials" в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка).

    Заметим также, что спецификация субтипа является MANDATORY - она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр "access-type" для сообщения message/External-body не чувствителен.)

    Обратите внимание, что значение строки в кавычках не включает в себя сами кавычки. В полях заголовка в соответствии с RFC 822 допускаются комментарии. Таким образом, две приведенные ниже формы являются эквивалентными.

    Content-type: text/plain; charset=us-ascii (Plain text)
    Content-type: text/plain; charset="us-ascii".

    Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

    1. Частные значения (начинающиеся с "X-") могут быть определены для двух взаимодействующих агентов без официальной регистрации или стандартизации.
    2. Новые стандартные значения должны регистрироваться IANA, как это описано в RFC 2048.

    4.2. Значения по умолчанию Content-Type

    Сообщения по умолчанию без MIME-заголовка Content-Type согласно протоколу должны содержать простой текст с символьным набором ASCII, который может быть специфицирован явно.

    Content-type: text/plain; charset=us-ascii

    Это значение подразумевается, если не специфицировано поле заголовка Content-Type. Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя.

    5. Поле заголовка Content-Transfer-Encoding

    Многие типы среды, которые могут передаваться посредством электронной почты, представляются в своем естественном формате, таком как 8-битовые символы или двоичные данные. Такие данные не могут быть переданы посредством некоторых транспортных протоколов. Например, RFC 821 (SMTP) ограничивает почтовые сообщения 7-битовым символьным набором ASCII со строками короче 1000 символов, включая строчные разделители CRLF.

    Таким образом, необходимо определить стандартный механизм кодировки таких данных в 7-битный формат с короткими строками. В MIME для этой цели используется поле заголовка "Content-Transfer-Encoding". Это поле не было определено каким-либо прежним стандартом.

    5.1. Синтаксис Content-Transfer-Encoding

    Значения полей Content-Transfer-Encoding представляют собой лексему, характеризующую тип кодирования, как это описано ниже.

    encoding

    :=

    "Content-Transfer-Encoding" ":" mechanism

    mechanism

    :=

    "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

    Эти значения не чувствительны к регистру, в котором напечатаны. - Base64, BASE64 и bAsE64 эквивалентны. Тип кодировки 7BIT требует, чтобы тело уже имело 7-битовое представление, пригодное для передачи. Это значение по умолчанию, означает, что в отсутствии поля Transfer-Encoding предполагается "Content-Transfer-Encoding: 7BIT".

    5.2. Семантика Content-Transfer-Encodings

    Лексема Content-Transfer-Encoding предоставляет два вида информации. Она специфицирует, какому виду кодового преобразования подвергнуто тело сообщения и, следовательно, какая процедура декодирования должна использоваться при восстановлении исходного вида сообщения.

    Преобразовательная часть любого Content-Transfer-Encodings специфицирует явно или неявно алгоритм декодирования, который либо восстановит исходный вид последовательности или обнаружит ошибку. Преобразования Content-Transfer-Encodings для нормальной работы никогда не требует какой-либо дополнительной внешней информации. Преобразование заданной последовательности октетов в другую эквивалентную кодовую последовательность совершенно легально.

    В настоящее время определены три преобразования: тождественное (никакого преобразования), преобразование в последовательность печатных символов и в последовательность кодов "base64".

    Значения Content-Transfer-Encoding "7bit", "8bit" и "binary" означают, что никакого преобразования не произведено. Они указывают на тип тела сообщения, и позволяют предполагать, какое кодирование может потребоваться при передаче данных.

    Кодирование в последовательность печатных символов или в кодовую последовательность base64 предполагает преобразование из произвольного исходного формата в представление "7bit", что позволяет передачу через любые транспортные среды.

    Всегда должна использоваться корректная метка Content-Transfer-Encoding. Пометка данных, преобразованных программой UUENCODE и содержащих 8-битовые символы, как "7bit" не допустима, такие данные должны помечаться только как "binary".

    При прочих равных условиях предпочтительным представлением является последовательность печатных символов или кодов base64.

    Передача почтовых сообщений закодированных программой uuencode описана в документе RFC 1652. Но следует иметь в виду, что ни при каких обстоятельствах Content-Transfer-Encoding "binary" нельзя считать приемлемым для e-mail. Однако когда используется MIME, двоичное тело сообщение может быть помечено как таковое.

    5.3. Новое значение Content-Transfer-Encodings

    Программисты могут, если необходимо, определить частные значения Content-Transfer-Encoding. При этом должны использоваться x-лексемы, которые представляют собой имена с префиксом "X-", что указывает на нестандартный статус, например, "Content-Transfer- Encoding: x-my-new-encoding". Дополнительные стандартизованные значения Content-Transfer-Encoding должны быть специфицированы в официальных документах RFC.

    В отличие от типов среды и субтипов, формирование новых значений Content- Transfer-Encoding категорически не рекомендуется, так как может привести к полному выходу из строя системы.

    4. Реализация и применение

    Если поле заголовка Content-Transfer-Encoding появляется как часть заголовка сообщения, оно относится ко всему телу сообщения. Если поле заголовка Content-Transfer-Encoding появляется в качестве части заголовка объекта, то зоной его действия будет тело этого объекта. Если объект имеет тип "multipart", то Content-Transfer-Encoding не может иметь значение "7bit", "8bit" или "binary". Следует заметить, что большинство типов среды определены в терминах октетов, а не бит, поэтому описываемые механизмы относятся к кодировке произвольных потоков октетов, а не бит. Если необходимо закодировать битовую последовательность, она должна быть преобразована в последовательность октетов с сетевой последовательностью бит ("big-endian"), в которой более ранние биты становятся старшими битами октетов. Битовые потоки, длина которых не кратна 8, должны быть дополнены нулями.

    Механизмы кодировки, определенные здесь, осуществляют преобразование любых данных в ASCII. Таким образом, предположим, например, что объект имеет следующие поля заголовка:

    Content-Type: text/plain; charset=ISO-8859-1
    Content-transfer-encoding: base64

    Это должно интерпретироваться так, что тело имеет кодировку base64, а исходные данные имели представление в ISO-8859-1.

    Определенные значения Content-Transfer-Encoding могут использоваться только с определенными типами среды. В частности, категорически запрещено использовать любую кодировку отличную от "7bit", "8bit" или "binary" с любым составным типом среды, т.e. включающим и другие поля Content-Type. В настоящее время допустимы составные типы среды "multipart" и "message". Все кодировки, допустимые для тел типа multipart или message должны использоваться на самом внутреннем уровне.

    Следует также заметить, что по определению, если составной объект имеет значение transfer-encoding равное "7bit", но один из составляющих объектов имеет менее регламентирующее значение, например, "8bit", тогда либо внешняя метка "7bit" является ошибкой, или внутренняя метка "8bit" устанавливает слишком высокое требование к транспортной системе (следовало проставить 7bit).

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

    Любой объект с нераспознанным значением Content-Transfer-Encoding должен рассматриваться, как если бы он имел код Content-type "application/octet-stream", вне зависимости оттого, что утверждается полем заголовка Content-Type.

    Может показаться, что Content-Transfer-Encoding может быть выяснено из характеристик среды, для которой нужно осуществить кодирование или, по крайней мере, что определенное Content-Transfer-Encodings может быть предназначено для использования с определенными типами среды. Есть несколько причин, почему это не так. Во-первых, существующие различные типы транспорта, используемые для почты, некоторые кодирования могут годиться для определенных комбинаций типов среды и транспорта, но быть непригодными для других. Например, при 8-битовой передаче, при определенном символьном наборе для текста не потребуется никакого кодирования, в то время как такое кодирование очевидно необходимо для 7-битового SMTP.

    Во-вторых, определенные типы среды могут требовать различного транспортного кодирования при разных обстоятельствах. Например, многие PostScript-тела могут целиком состоять из коротких строк 7-битовых кодов, и, следовательно, совсем не требуют кодирования. Другие тела PostScript (в особенности те, что используют механизм двоичного кодирования уровня 2 PostScript) могут быть представлены с использованием двоичного транспортного кодирования. Наконец, так как поле Content-Type ориентировано на то, чтобы предоставлять открытые механизмы спецификации, строгие ассоциации типов среды и кодирования эффективно соединяют спецификацию прикладного протокола с определенным транспортом нижнего уровня. Это нежелательно, так как разработчики типа среды не должны заботиться обо всех видах транспорта и их особенностях.

    5.5. Транслирующее кодирование

    Кодирование с использованием закавыченных строк печатных символов и кодов base64 устроено так, чтобы позволить взаимные преобразования. Единственная проблема, которая здесь возникает, это обработка принудительных разрывов строк для закавыченных последовательностей печатных символов. При преобразовании закавыченных строк в коды base64 принудительные разрывы строк отображаются последовательностями CRLF. Аналогично, последовательность CRLF в канонической форме данных, полученной после декодирования из base64, должна преобразоваться в принудительный разрыв строки в случае представления текста в виде закавыченной строки печатных символов. Каноническая модель кодирования представлена в документе RFC 2049.

    5.6. Транспортное кодирование содержимого Quoted-Printable

    Кодирование Quoted-Printable имеет целью представление данных, состоящих по большей части из октетов, которые соответствуют печатным символам ASCII-набора. Оно преобразует данные таким образом, что результирующие октеты не будут видоизменены при транспортировке почты. Если преобразуемые данные представляют собой ASCII-текст, то после кодирования они сохранят читабельность. Тело, которое целиком состоит из ASCII-кодов, может быть также представлено в виде закавыченной строки печатных символов. При этом сохраняется целостность текста в процессе прохождении через шлюз, который осуществляет трансляцию символов и/или обработку разрывов строк. При этом кодировании октеты должны определяться согласно изложенным ниже правилам:

    (1)

    8-битовое представление. Любой октет, за исключением CR или LF, которые являются частью последовательности разрыва строки CRLF, канонического (стандартного) формата данных может быть представлен с помощью символом "=", за которым следуют две шестнадцатеричные цифры, характеризующие значение октета. Для этих целей используются цифры шестнадцатеричного алфавита "0123456789ABCDEF". Должны использоваться прописные буквы; использование строчных букв недопустимо. Так, например, десятичное значение 12 (ASCII FF) может быть представлено как "=0C", а десятичное значение 61 (ASCII символ знака равенства) представляется с помощью "=3D". Это правило должно выполняться всегда за исключением случаев, когда правила допускают альтернативное кодирование.

    (2)

    Литеральное представление. Октеты с десятичными кодами в интервале 33 - 60 включительно, и 62 - 126, включительно, могут представляться ASCII-символами, которые соответствуют этим октетам (с ! до < и с > до ~ соответственно).

    (3)

    Пробелы. Октеты со значениями кодов 9 и 32 могут отображаться с помощью ASCII-символов TAB (HT) и пробел, соответственно, но не должны использоваться в конце строки. За любым символом TAB (HT) или пробел в кодируемой строке должен следовать печатный символ. В частности, символ "=" в конце каждой кодируемой строки, обозначающий "мягкий" разрыв строки (смотри правило #5), может следовать за одним или более символами TAB (HT) или SP. Отсюда следует, что октет, равный 9 или 32 появляющийся в конце кодируемой строки должен быть представлен в форме, указанной правилом #1. Это правило необходимо, так как некоторые MTA (Message Transport Agents, программы, которые передают сообщения от одного пользователя другому) дополняют строки пробелами, а другие удаляют пробелы (HT или SP) в конце строки. Следовательно, при декодировании тела, представленного в форме закавыченных печатных последовательностей, любые HT или SP должны быть удалены.

    (4)

    Разрывы строк. Разрыв строки в теле текста, представленный последовательностью CRLF в канонической форме, для закавыченной печатной строки отмечается CRLF. Последовательности типа "=0D", "=0A", "=0A=0D" и "=0D=0A" появляются в нетекстовых данных, представленных в виде закавыченных строк печатных символов.
    Заметим, что многие реализации могут выбрать для кодирования непосредственно локальное представление различных типов содержимого, а не преобразование в каноническую форму, кодирование и только затем преобразование в локальное представление. В частности, такая техника может быть применена к простому тексту в системах, которые используют для межстрочных разрывов последовательности, отличные от CRLF. Такая оптимизация конкретной программной реализации вполне допустима, но только когда комбинированный шаг канонизация-кодирование эквивалентен выполнению всех трех шагов отдельно.

    (5)

    Мягкие разрывы строки. Кодирование с помощью закавыченных строк печатных символов требует, чтобы строки содержали не более 76 символов. Если нужно закодировать более длинные строки вводятся "мягкие" разрывы строк. Символ равенства в конце строки как раз и обозначает такой разрыв.

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

    Now's the time for all folk to come to the aid of their country.

    Это может быть представлено следующим образом с помощью закавыченных строк печатных символов:

    Now's the time =
    to the aid of their country.

    Это предоставляет механизм, с помощью которого длинные строки преобразуются таким образом, как они должны быть запомнены агентом пользователя. Ограничение в 76 символов не учитывает завершающие строку CRLF, но включают все прочие символы, включая знаки равенства. Так как символ дефис ("-") может отображаться в закавыченных строках самим собой, нужно следить за тем, чтобы при инкапсуляции закодированного так фрагмента, в одном или более составных объектов пограничные разделители не появились в закодированном теле. Хорошей стратегией является выбор в качестве границы последовательности символов "=_", которая не может встретиться в закавыченной строке печатных символов.

    Преобразование в закавыченные строки печатных символов представляет собой компромисс между читабельностью и надежностью при транспортировке. Тела, закодированные с помощью закавыченных строк печатных символов, пропускаются без проблем большинством почтовых шлюзов. Проблемы могут возникать только со шлюзами, осуществляющими трансляцию в коды EBCDIC. Кодирование с помощью base64 обеспечивает более высокий уровень надежности. Методом получения разумно высокой надежности транспортировки через шлюзы EBCDIC является представление символов !"#$@[\]^`{|}~ согласно правилу #1.

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

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

    (1)

    Символ "=", за которым следует две шестнадцатеричные цифры, одна или обе из которых являются строчными символами (abcdef). Надежные реализации могут распознавать их как прописные буквы.

    (2)

    Символ "=", за которым следует символ, не являющийся ни шестнадцатеричной цифрой (включая abcdef), ни CR из комбинации CRLF. Это не может стать частью ASCII-текста, включенного в сообщение, без преобразования в закавыченную последовательность печатных кодов. Разумным решением для надежной реализации может быть включение символа "=" и следующих за ним кодов в декодированную последовательность, без какого-либо преобразования и, если возможно, дать и сигнал агенту пользователя, что декодирование в этом месте оказалось невозможным.

    (3)

    Символ "=" не может быть последним или завершающим символом в кодируемом объекте. Решением проблемы можно считать способ, предложенный в пункте (2).

    (4)

    Управляющие символы, отличные от TAB, CR и LF (в качестве части CRLF) не должны присутствовать. То же справедливо для октетов с десятичными значениями больше чем 126. Если такие коды обнаруживаются в приходящих закавыченных последовательностях печатных символов, корректная реализация может исключить из декодированных данных и предупредить пользователя о том, что обнаружен нелегальный символ.

    (5)

    Закодированные строки не должны быть длиннее 76 символов, не считая завершающие CRLF. Если во входном потоке обнаружены более длинные строки, надежная реализация может их декодировать, но должна предупредить пользователя об ошибке.

    Если двоичные данные закодированы в виде закавыченных последовательностей печатных символов, следует позаботиться о том, чтобы символы CR и LF были представлены в виде "=0D" и "=0A", соответственно. В частности, последовательность CRLF в двоичных данных должна кодироваться как "=0D=0A". В противном случае, если CRLF была бы представлена как "жесткий" разрыв строки, она может декодироваться некорректно на платформах с различными способами обработки разрывов строки. С формальной точки зрения, закавыченные последовательности печатных символов подчиняются следующей грамматике.

    quoted-printable

    :=

    qp-line *(CRLF qp-line)

    qp-line

    :=

    *(qp-segment transport-padding CRLF) qp-part transport-padding

    qp-part

    :=

    qp-section

    ; Максимальна длина 76 символов

    qp-segment

    :=

    qp-section *(SPACE / TAB) "="

    ; Максимальна длина 76 символов

    qp-section

    :=

    [*(ptext / SPACE / TAB) ptext]

    ptext

    :=

    hex-octet / safe-char

    safe-char

    :=

    <любой октет с десятичным кодом от 33 до 60 включительно, и от 62 до 126>

    ; Символы, не включенные в список "mail-safe" RFC 2049, не рекомендуются к применению.

    hex-octet

    :=

    "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

    ; Октет должен использоваться для символов с кодами > 127, =, SP или TAB в конце строк, и рекомендуются для любого символа не указанного в списке "mail-safe" документа RFC 2049.

    transport-padding

    :=

    *LWSP-char

    ; Составители не должны генерировать заполнители ненулевой длины, но получатели должны быть способны обрабатывать заполнители, добавленные при транспортировке.

    Добавление LWSP между элементами, показанное в данном BNF-представлении, не допустимо, так как данное BNF не специфицирует структурированных полей заголовка.

    5.7. Транспортное кодирование Base64 (Content-Transfer-Encoding)

    Транспортное кодирование на основе Base64 создано для представления произвольной последовательности октетов в форме, которая не обязательно должна быть приемлемой для прочтения человеком. Алгоритмы кодирования и декодирования просты. Это кодирование сходно с тем что используется в почтовом приложении PEM (Privacy Enhanced Mail), как это определено в RFC-1421.

    Здесь используется 65-символьный субнабор ASCII, для каждого печатного символа выделено по 6 бит. Дополнительный 65-ый символ "=", используется для обозначения специальных функций обработки.

    Этот субнабор имеет важное свойство, которое заключается в том, что он представляется идентично во всех версиях ISO 646, включая US-ASCII, и все символы субнабора имеют аналоги во всех версиях EBCDIC. Другие популярные кодировки, такие как применение утилиты uuencode, Macintosh binhex 4.0 [RFC-1741] и base85, специфицированная как часть уровня 2 PostScript, имеют отличающиеся свойства и, следовательно, не выполняют условий переносимости, которым должна удовлетворять двоичное транспортное кодирование электронной почты.

    При кодировании входные 24-битовые группы преобразуют в 4 символа. Входная группа формируется из трех 8-битовых кодов и обрабатывается слева направо. Эти 24 бита рассматриваются в дальнейшем как 4 6-битовые группы, каждая из которых транслируется в одно число из алфавита base64. Когда кодируется битовый поток с использованием base64, предполагается, что старший бит передается первым. То есть, первый бит потока станет старшим битом первого 8-битового байта, а 8-ой бит станет его последним битом.

    Каждая 6-битовая группа используется как индекс массива из 64 печатных символов. Символ, на который указывает индекс, берется из массива и помещается в выходной поток. Эти символы представлены в таблице .1., из их перечня исключены коды, имеющие особое значение для протокола SMTP (например, ".", CR, LF), а также разграничитель секций составного сообщения "-" (RFC-2046).

    Таблица .1. Коды Base64

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    0

    A

    10

    Q

    20

    g

    30

    w

    1

    B

    11

    R

    21

    h

    31

    x

    2

    C

    12

    S

    22

    i

    32

    y

    3

    D

    13

    T

    23

    j

    33

    z

    4

    E

    14

    U

    24

    k

    34

    0

    5

    F

    15

    V

    25

    l

    35

    1

    6

    G

    16

    W

    26

    m

    36

    2

    7

    H

    17

    X

    27

    n

    37

    3

    8

    I

    18

    Y

    28

    o

    38

    4

    9

    J

    19

    Z

    29

    p

    39

    5

    A

    K

    1A

    a

    2A

    q

    3A

    6

    B

    L

    1B

    b

    2B

    r

    3B

    7

    C

    M

    1C

    c

    2C

    s

    3C

    8

    D

    N

    1D

    d

    2D

    t

    3D

    9

    E

    O

    1E

    e

    2E

    u

    3E

    +

    F

    P

    1F

    f

    2F

    v

    3F

    /

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

    Если число бит в группе меньше 24, используется специальная обработка. Неполная битовая группа дополняется нулями справа до 24. Заполнение в конце информационной группы осуществляется с использованием символа "=". Так как последовательность кодов base64 представляет собой поток октетов, возможны следующие случаи:

    1. последний блок кодируемых данных кратен 24 битам; здесь, завершающий выходной блок будет содержать в себе 4 символа и никакого заполнителя,
    2. завершающий блок кодируемых данных содержит ровно 8 бит; здесь, оконечный выходной блок будет содержать два символа, за которыми будут следовать два символа заполнителя, или
    3. последний блок кодируемой информации содержит ровно 16 бит; здесь, оконечный блок на выходе будет иметь три символа плюс один символ заполнителя "=".

    Так как "=" используется для дополнения, его наличие указывает на то, что достигнут конец массива данных. Такая уверенность не возможна, когда число переданных октетов кратно трем и нет ни одного символа "=". Любые символы, не входящие в алфавит base64-должны игнорироваться.

    Следует позаботиться о том, чтобы использовались корректные октеты в качестве разделителей строк при работе с base64. В частности, разрывы строк должны быть преобразованы в последовательности CRLF до выполнения кодирования base64.

    6. Поле заголовка Content-ID

    При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID":

    id := "Content-ID" ":" msg-id

    Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными.

    Значение Content-ID может использоваться для идентификации MIME-объектов в нескольких контекстах, в частности для кэширования данных с доступом через механизм message/external-body. Хотя заголовок Content-ID является обычно опционным, его использование является обязательным в приложениях, которые генерируют данные опционного типа среды MIME "message/external-body". По этой причине каждый объект message/external-body должен иметь поле Content-ID, для того чтобы разрешить кэширование таких данных.

    7. Поле заголовка Content-Description

    Часто оказывается желательным установить соответствие между описательной информацией и данным телом. Например, может быть полезным пометить тело типа "image" как "изображение старта космического корабля". Такой текст может быть помещен в поле заголовка Content-Description. Это поле всегда является опционным.

    description := "Content-Description" ":" *text

    Предполагается, что описание дается с использованием символьного набора US-ASCII, хотя механизм, специфицированный в RFC 2047, может быть использован и для значений Content-Description, не соответствующих стандарту US-ASCII.

    8. Дополнительные поля заголовка MIME

    Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822.

    MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-">

    Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049).

    Приложение A -- обзор грамматики

    Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.

    attribute

    :=

    token

    Распознавание атрибутов не зависит от регистра, в котором написаны их имена.

    composite-type

    :=

    "message" / "multipart" / extension-token

    Content

    :=

    "Content-Type" ":" type "/" subtype *(";" parameter)

    Распознавание типов среды и субтипов не зависит от регистра, в котором написаны их имена.

    description

    :=

    "Content-Description" ":" *text

    discrete-type

    :=

    "text" / "image" / "audio" / "video" / "application" / extension-token

    encoding

    :=

    "Content-Transfer-Encoding" ":" mechanism

    entity-headers

    :=

    [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF )

    extension-token

    :=

    ietf-token / x-token

    hex-octet

    :=

    "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

    Октет должен использоваться для символов > 127, =, пробелов или TAB в конце строк, и рекомендуется для любого символа вне списка "mail-safe" RFC 2049.

    iana-token

    :=

    <Общедоступная лексема. Лексемы этого формата должны регистрироваться IANA, как это определено в RFC 2048.>

    ietf-token

    :=

    <Лексема расширения, определенная согласно RFC и зарегистрированная IANA.>

    Id

    :=

    "Content-ID" ":" msg-id

    mechanism

    :=

    "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

    MIME-extension-field

    :=

    <Любое поле заголовка RFC 822, которое начинается со строки "Content-">

    MIME-message-headers

    :=

    entity-headers fields version CRLF

    Порядок полей заголовка, заданный в BNF-определении не играет никакой роли.

    MIME-part-headers

    :=

    Заголовки объекта [поля]

    Любое поле, начинающееся с "content-", не имеет строго заданного значения и может игнорироваться.

    parameter

    :=

    атрибут "=" значение

    Ptext

    :=

    hex-octet / safe-char

    qp-line

    :=

    *(qp-segment transport-padding CRLF) транспортный заполнитель qp-части

    qp-part

    :=

    qp-секция

    Максимальная длина 76 символов

    qp-section

    :=

    [*(ptext / SPACE / TAB) ptext]

    qp-segment

    :=

    qp-секция *(SPACE / TAB) "="

    Максимальная длина 76 символов

    Quoted-printable

    :=

    qp-line *(CRLF qp-line)

    safe-char

    :=

    <любой октет с десятичным кодом от 33 до 60, включительно, и с 62 до 126>

    Символы вне списка "mail-safe" в RFC 2049 не рекомендуются.

    subtype

    :=

    Лексема расширения / лексема iana

    Token

    :=

    1*<любой US-ASCII-символ за исключением SPACE, CTLs, или tspecials>

    transport-padding

    :=

    *LWSP-char

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

    tspecials

    :=

    "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="

    При использовании в значениях параметров они должны иметь формат закавыченных строк.

    Type

    :=

    discretetype / compositetype

    Value

    :=

    лексема / закавыченная строка

    version

    :=

    "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

    x-token

    :=

    <Два символа "X-" или "x-", за которыми следует без пробела любая лексема>

    II. Типы среды

    1. Введение

    Поле Content-Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен.

    Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application".

    Параметры являются модификаторами субтипа среды, и как таковые не оказывают никакого влияния на содержимое. Набор параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако определенный тип среды высшего уровня может определить параметры, которые приложимы к любому субтипу данного типа. Параметры могут быть обязательными или опционными. MIME игнорирует любые параметры, имена которых нераспознаны.

    Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения. Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.

    2. Определение типов среды верхнего уровня

    Определение типа среды верхнего уровня состоит из:

    (1)

    Имя и описание типа, включая критерии, согласно которым можно решить, относится ли данная среда к указанному типу.

    (2)

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

    (3)

    Как агент пользователя и/или шлюз должен обрабатывать не узнанный субтип данного типа.

    (4)

    Общие соображения о шлюзовании объектов данного типа, если таковые имеются.

    (5)

    Любые ограничения на транспортное кодирование объектов данного типа.

    3. Обзор базовых типов среды верхнего уровня

    Имеется пять дискретных типов среды высокого уровня.

    (1)

    text

    - текстовая информация. Субтип "plain" в частности указывает, что текст не содержит команд форматирования или каких-либо директив. Такой текст нужно отображать, так как он есть. Не нужно никакого специального программного обеспечения для восприятия такого текста, помимо поддержки указанного символьного набора. Другие субтипы должны использоваться для обогащенного текста (enriched) в форме, где прикладное программное обеспечение может улучшить представление текста. Но такая программа не нужна для общей обработки содержимого. Возможные субтипы "text" включают в себя любые форматы, которые могут быть прочитаны без обращения к программе, которая понимает этот формат. В частности, форматы, которые используют встроенное двоичное форматирование, не считаются непосредственно читаемыми. Очень простой и портативный субтип, "richtext", был определен в документе RFC 1341, и позднее пересмотрен в RFC 1896 под именем "enriched".

    (2)

    image

    - графические данные. "Image" требует устройства отображения (такого как графический дисплей, графический принтер, или факс) для того чтобы просмотреть информацию. Первичный субтип определен для широко используемого формата изображения JPEG. Субтипы определены для двух широко используемых форматов изображения jpeg и gif.

    (3)

    audio

    - звуковые данные. "Audio" требует выходного устройства (такого как громкоговоритель или телефон) для воспроизведения содержимого.

    (4)

    video

    - видео данные. "Video" требует выходного устройства, способного воспроизвести движущееся изображение. В данном документе определен первичный субтип "mpeg".

    (5)

    application

    - некоторые другие типы данных, обычно не интерпретированные двоичные данные или информация, которая должна быть обработана приложением. Субтип "octet-stream" следует использовать в случае не интерпретируемых двоичных данных, в этом случае простейшей рекомендацией может служить передача этой информации в файл пользователя. Субтип "PostScript" определен для транспортировки PostScript текстов.

    Существует два составных типа среды высшего уровня.

    (1)

    multipart

    - данные, состоящие из нескольких объектов с различными типами данных. Определены четыре первичных субтипов, включая базовый субтип "mixed", специфицирующий смешанный набор частей, "alternative" - для представления одних и тех же данных в различных форматах, "parallel" - для частей, которые должны представляться одновременно и "digest" - для составных объектов, в которых каждая часть имеет тип по умолчанию "message/rfc822".

    (2)

    message

    - инкапсулированное сообщение. Тело типа среды "message" составляет часть или весь объект сообщения некоторого типа. Такие объекты могут содержать в свою очередь другие объекты. Субтип "rfc822" используется, когда инкапсулированное содержимое само является сообщением RFC 822. Субтип "partial" определен для частичных сообщений вида RFC 822, чтобы разрешить по-фрагментную передачу слишком длинных тел сообщения. Другой субтип "external-body" определен для спецификации протяженных тел с помощью ссылок на внешние источники информации.

    4. Дискретные значения типа среды

    Пять из семи базовых значений типа среды относятся к дискретным телам. Содержимое этих типов должно обрабатываться с использование механизмов за пределами MIME, они непрозрачны для MIME-процессоров.

    4.1. Тип среды Text

    Тип среды "text" предназначен для посылки материала, который имеет принципиально текстуальную форму. Параметр "charset" можно использовать для указания символьного набора тела субтипов "text", включая субтип "text/plain", который является общим субтипом для чистого текста. Чистый текст не содержит форматирующих команд, спецификаций атрибутов шрифтов, инструкций обработки, директив интерпретации или разметки. Чистый текст представляет собой последовательность символов, которая может содержать разрывы строк или страниц.

    Помимо чистого текста существует много форматов, называемых "богатый" текст ("rich text"). Интересной характеристикой многих таких представлений является то, что они читабельны даже без программы, которая его интерпретирует. Полезно затем отличать их на верхнем уровне от таких нечитабельных данных как изображения, звук или текст, представленный в нечитаемом виде. В отсутствии подходящей интерпретирующей программы разумно показать субтипы "text" пользователю, в то время как это неразумно для большей части нетекстовых данных. Такие форматированные текстовые данные должны представляться с помощью субтипов "text".

    4.1.1. Представление разрывов строк

    Каноническая форма любого субтипа MIME "text" должна всегда оформлять разрыв строки с помощью последовательности CRLF. Аналогично, любое появление CRLF в тексте MIME должно означать разрыв строки. Использование CR и LF по отдельности вне обозначения разрыва строки запрещено. Это правило работает вне зависимости от используемого символьного набора.

    Правильная интерпретация разрывов строк при отображении текста зависит от типа среды. Следует учитывать, что одно и то же оформление разрывов строк при отображении "text/plain" может восприниматься корректно, в то время как для других субтипов "text", например, "text/enriched" [RFC-1896] аналогичные разрывы строк будут восприниматься как неверные. Нет необходимости в добавлении каких-либо разрывов строк при отображении "text/plain", в то время как отображение "text/enriched" требует введения соответствующего оформления разрывов строк.

    Некоторые протоколы определяют максимальную длину строки. Например, SMTP [RFC-821] допускает максимум 998 октетов перед последовательностью CRLF. Для того чтобы реализовать транспортировку посредством такого протокола, данные, содержащие слишком длинные сегменты без CRLF, должны быть закодированы с применением соответствующего content-transfer-encoding.

    4.1.2. Параметр Charset

    Критическим параметром, который может быть специфицирован в поле Content-Type для данных "text/plain", является символьный набор. Он специфицируется параметром "charset", например, как:

    Content-type: text/plain; charset=iso-8859-1

    В отличие от других значений параметров, значения параметра символьный набор не чувствительны к регистру, в котором написано его имя. Значением по умолчанию параметра символьный набор равно US-ASCII.

    Для других субтипов "text", семантика параметра "charset" должна быть определена аналогично параметрам, заданным для "text/plain", т.e., тело состоит полностью из символов данного набора. В частности, авторы будущих определений субтипов "text" должны обратить особое внимание мультиоктетным символьным наборам. Параметр charset для субтипов "text" дает имя символьному набору, как это определено в RFC 2045.

    Заметим, что специфицированный символьный набор включает в себя 8-битовые коды и эти символы используются в теле, поле заголовка Content-Transfer-Encoding и для передачи данных с помощью транспортных протоколов (например, SMTP) необходима соответствующая кодировка, такая как [RFC-821].

    Значение символьного набора по умолчанию, равное US-ASCII, являлось причиной многих неурядиц в прошлом. Для того чтобы исключить какие-либо неопределенности в будущем, настоятельно рекомендуется новым агентам пользователя задавать символьный набор в явном виде в качестве параметра типа среды в поле заголовка Content-Type. "US-ASCII" не указывает на произвольный 7-битовый символьный набор, а говорит о том, что все октеты в теле должны интерпретироваться как символы US-ASCII. Национальные и ориентированные на приложения версии ISO 646 [ISO-646] обычно не идентичны US-ASCII, и их непосредственное применение в электронной почте может вызвать проблемы. Имя символьного набора "US-ASCII" относится к кодам, заданным в документе ANSI X3.4-1986 [US- ASCII].

    Полный набор символов US-ASCII представлен в ANSI X3.4-1986. Заметим, что управляющие символы, включая DEL (0-31, 127) не имеют определенного значения, исключение составляет комбинация CRLF (US-ASCII значения 13 и 10) обозначающая разрыв строки. Два символа имеют широко используемые функции, это: FF (12) - продолжить последующий текст с начала новой страницы, и TAB или HT (9) часто (хотя и не всегда) означает "переместить курсор в следующую колонку. Колонки нумеруются, начиная с нуля и их позиции кратны 8. Помимо этих случаев любые управляющие символы или DEL в теле объекта могут появиться при следующих условиях.

    (1)

    по причине того, что субтип текста, отличающийся от "plain", приписывает им некоторые дополнительные значения, или

    (2)

    в рамках контекста частного соглашения между отправителем и получателем.

    Определены следующие значения charset:

    (1)

    US-ASCII - как это определено в ANSI X3.4-1986 [US-ASCII].

    (2)

    ISO-8859-X -- где "X" следует замещать как это требуется для частей ISO-8859 [ISO-8859]. Допустимыми подменами "X" являются цифры от 1 до 10.

    Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII.

    Значения символьных наборов "ISO-8859-6" и "ISO-8859-8" специфицируют применение визуального метода [RFC-1556].

    Все эти символьные наборы используются как чисто 7-битовые или 8-битовые без модификаций связанных или .

    Никакие символьные наборы, отличные от определенных выше, не могут использоваться в электронной почте без публикации и формальной регистрации в IANA. Допустимы частные соглашения, в этом случае имя символьного набора должно начинаться с "X-".

    Потребителям не рекомендуется определять новые символьные наборы, если это не диктуется крайней необходимостью. Параметр "charset" был первоначально определен для текстовых данных. Однако возможно его использование и для не текстовой информации, обычно это делается для синтаксической совместимости.

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

    4.1.3. Субтип Subtype

    Простейшим и наиболее важным субтипом "text" является "plain". Он указывает, что текст не содержит форматирующих команд или директив. Чистый текст может отображаться непосредственно без какой-либо обработки. По умолчанию для электронной почты предполагается тип среды "text/plain; charset=us-ascii".

    4.1.4. Не распознанные субтипы

    Не распознанные субтипы "text" должны обрабатываться как чистый текст ("plain"), поскольку реализация MIME знает, как работать с данным символьным набором. Не распознанные субтипы, которые также специфицируют нераспознаваемый символьный набор, должны обрабатываться как "application/octet- stream".

    4.2. Тип среды Image

    Тип среды "image" указывает, что тело содержит изображение. Субтип называет имя специфического формата изображения. Эти имена не чувствительны к регистру. Исходным субтипом является "jpeg", который использует кодировку JFIF для формата JPEG [JPEG]. Не распознанные субтипы "image" должны обрабатываться как "application/octet-stream".

    4.3. Тип среды Audio

    Исходный субтип "basic" специфицирован, для того чтобы удовлетворить требованиям, которые соответствуют самому нижнему в иерархии аудио-форматов. Предполагается, что форматы для более высококачественного воспроизведения и/или низко полосной передачи будут определены позднее.

    Содержимое субтипа "audio/basic" представляет собой моноканальное звуковое кодирование, использующее 8-битоый ISDN-стандарт с m-функцией преобразования [PCM] с частотой стробирования 8000 Hz. Не распознанные субтипы "audio" должны обрабатываться как "application/octet-stream".

    4.4. Тип среды Type

    Тип среды "video" указывает, что тело содержит движущееся изображение, возможно цветное и в сопровождении звука. Термин 'video' используется в самом общем значении, и не подразумевает какого-то конкретного формата. Субтип "mpeg" относится к видео закодированного согласно стандарту MPEG [MPEG]. Не распознанные субтипы "video" должны обрабатываться как "application/octet-stream".

    4.5. Тип среды Application

    Тип среды "application" следует использовать для дискретных данных, которые не могут быть отнесены ни к какой другой категории, в частности для данных, которые должны быть обработаны какой-то прикладной программой. Это информация, которая должна обрабатываться приложением до того как она станет доступной для просмотра пользователем. К предполагаемым применениям типа среды "application" относится файловый обмен, электронные таблицы, диспетчерские системы, базирующиеся на электронной почте.

    Такие приложения могут быть определены как субтипы типа среды "application". В данном документе определены два субтипа:

    octet-stream и PostScript.

    4.5.1. Субтип Octet-Stream (поток октетов)

    Субтип "octet-stream" используется для индикации того, что тело содержит произвольные двоичные данные. В настоящее время определены следующие параметры:

    (1)

    TYPE - общий тип или категория двоичных данных. Это параметр предназначен для оператора-получателя, а не для программы обработки.

    (2)

    PADDING - число бит заполнителя, добавленного к потоку бит, представляющему действительное содержимое, для того чтобы получить байт-ориентированный поток. Используется, когда число бит в теле не кратно 8

    Оба эти параметра являются опционными.

    4.5.2. Субтип PostScript

    Тип среды "application/postscript" указывает на программу PostScript. В настоящее время допускается два варианта языка PostScript. Исходный вариант уровня 1 описан в [POSTSCRIPT], а более новый вариант уровня 2 рассмотрен в [POSTSCRIPT2].

    Описания языка PostScript предоставляет возможности внутренней пометки специфических возможностей данного приложения. Эта пометка, называемая DSC (document structuring conventions) PostScript, предоставляет существенно больше информации, чем уровень языка. Использование DSC рекомендуется даже тогда, когда это непосредственно не требуется, так как обеспечивает более широкую совместимость. Документы, которые недостаточно структурированы, не могут быть проверены с целью выяснения того, могут ли они работать в данной среде.

    Работа универсальных интерпретаторов PostScript представляет серьезную угрозу безопасности, разработчикам не рекомендуется просто посылать тела PostScript имеющимся ("off-the-shelf") интерпретаторам. В то время как посылка PostScript-файла на принтер обычно безопасна, программисты должны рассмотреть все возможные последствия, прежде чем ввести интерактивное отображение тел типа PostScript на их читающих средствах MIME.

    Ниже перечислены возможные проблемы, связанные с транспортировкой объектов PostScript.

    (1)

    В список опасных операций языка PostScript входят "deletefile", "renamefile", "filenameforall" и "file". "File" является единственной опасной процедурой, которая применяется для входных/выходных потоков не стандартных данных. Конкретные реализации могут определить не стандартные файловые операторы, которые могут также представлять угрозу безопасности. "Filenameforall", - оператор поиска файлов, может показаться на первый взгляд безобидным.
    Заметим, что этот оператор может раскрыть информацию о том, к каким файлам имеет доступ пользователь, а эти данные могут облегчить задачу хакеру. Отправители сообщений должны избегать использования потенциально опасных файловых операторов, так как такие операторы, скорее всего, недоступны в PostScript приложениях, где приняты меры по обеспечению безопасности. Программное обеспечение, которое используется для приема и отображения, должно блокировать потенциально опасные файловые операторы или принять меры по ограничению их возможностей.

    (2)

    Язык PostScript предоставляет возможность для выхода из цикла интерпретатора или сервера. Операторы, сопряженные с выходом интерпретатора из цикла могут интерферировать с процедурами последующей обработки документов. Операторы PostScript, которые выводят интерпретатор из цикла, включают в себя серверы выхода и начала задания. Программе отправки сообщения не следует генерировать PostScript, который зависит от функционирования выхода интерпретатора из цикла, так как такая процедура может отсутствовать в реализациях с повышенной безопасностью. Программа приема сообщений должна полностью блокировать работу операторов "startjob" и "exitserver", также какие-либо изменения в среде PostScript на постоянной основе. Если эти операции не могут быть полностью исключены, для их выполнения должен быть организован контролируемый доступ с необходимостью ввода пароля.

    (3)

    PostScript предоставляет операторы для установки системных параметров и специфических параметров внешних устройств. Эти установки параметров могут влиять неблагоприятным образом на работу интерпретатора. Процедуры PostScript, которые устанавливают системные параметры, могут включать в себя операторы "setsystemparams" и "setdevparams". Программа отправки не должна генерировать PostScript-сообщений, которые зависят от установки системных параметров. Программа приема и отображения сообщений должна блокировать изменение системных параметров. Если блокировка по каким-либо причинам невозможна, процедура установки параметров должна требовать специфического пароля.

    (4)

    Некоторые реализации PostScript предоставляют нестандартные возможности для прямой загрузки и исполнения машинных кодов. Такие возможности чреваты злоупотреблениями. Программа отправки сообщений не должна использовать такие возможности. Программа приема и отображения сообщений не должна позволять применение таких операторов, если они имеются.

    (5)

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

    (6)

    Имеется возможность написания такой PostScript-программы, которая потребует огромных системных ресурсов. Можно также написать PostScript-фрагмент, который реализует бесконечный цикл. Оба варианта представляют угрозу для ничего не подозревающего получателя. Программа отправки сообщений должна избегать создания и распространения таких кодов. Программа приема и отображения сообщений должна предоставлять подходящий механизм для блокировки исполнения и удаления таких программ по истечении некоторого заданного времени.

    (7)

    Существует возможность включения двоичной информации в PostScript-текст. Это не рекомендуется в электронной почте, так как это не поддерживается всеми PostScript-интерпретаторами, потому что сильно усложняет использование транспортного кодирования MIME.

    (8)

    Наконец, в некоторых интерпретаторах PostScript вполне возможны ошибки, которые могут использоваться для получения не авторизованного доступа к системе получателя.

    4.5.3. Другие субтипы приложений

    Ожидается, что в будущем будут определены многие другие субтипы "application". Реализации MIME должны уметь обрабатывать нераспознанные субтипы как "application/octet-stream".

    5. Значения типа среды Composite (составной)

    Оставшиеся два из семи исходных значений Content-Type относятся к составным объектам. Составные объекты обрабатываются с использованием механизмов MIME -- процессор MIME обрабатывает тело объекта непосредственно.

    5.1. Тип среды Multipart

    В случае составных объектов, когда один или более различных наборов данных объединяется в одном теле, в заголовке объекта должно присутствовать поле типа среды "multipart". Тело должно тогда содержать одну или более частей, каждая из которых начинается с разделительной строки. За разделительной строкой следует заголовок, пустая строка и тело объекта. Таким образом, часть тела по своему синтаксису аналогична сообщению в RFC-822, но имеет другое назначение.

    Часть тела является объектом и, следовательно, не должна интерпретироваться как сообщение RFC-822. Начнем с того, что части тела должны иметь заголовки. Допустимы части тела, которые начинаются с пустой строки. В таком случае отсутствие заголовка Content-Type обычно указывает, что соответствующее тело имеет тип содержимого "text/plain; charset=US-ASCII".

    Единственные поля заголовка, которые определяют назначение частей тела, имеют имена, начинающиеся с "Content-". Все другие поля в заголовке части тела могут игнорироваться. Для экспериментальных или частных назначений могут создаваться поля, с именами, начинающимися с "X-". Информация, содержащаяся в этих полях может теряться в некоторых шлюзах.

    Различие между сообщением RFC-822 и частью тела не велико, но существенно. Шлюз между Интернет и почтовым сервером X.400, например, должен быть способен различать части тела, содержащие изображение и инкапсулированное сообщение, тело которого представляет собой JPEG-образ. Для того чтобы представить последнее, часть тела должна иметь "Content-Type: message/rfc822", и ее тело после пустой строки должно представлять собой инкапсулированное сообщение со своим собственным полем заголовка "Content-Type: image/jpeg". Применение подобного синтаксиса способствует преобразованию сообщений в части тела и обратно.

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

    Все существующие и будущие субтипы типа "multipart" должны использовать идентичный синтаксис. Субтипы могут отличаться по своей семантике и могут вводить дополнительные ограничения на синтаксис, но должны согласовываться с базовым синтаксисом типа "multipart". Это требование гарантирует, что все агенты пользователя будут, по крайней мере, способны распознать и разделить части составного объекта, даже если они относятся к нераспознанным субтипам.

    Как задано в определении поля Content-Transfer-Encoding [RFC-2045], никакие кодировки кроме "7bit", "8bit" или "binary" не разрешены для объектов типа "multipart". Граничные разделители и поля заголовков "multipart" всегда представляются как 7-битовые коды US-ASCII, а данные внутри частей тела могут быть закодированы по-разному и иметь свои поля Content-Transfer-Encoding для каждой из частей.

    5.1.1. Общий синтаксис

    Поле Content-Type для составных объектов требует одного параметра - "boundary". Строка-разделитель определяется как строка, содержащая два символа дефис ("-", десятичный код 45), за которыми следует значение пограничного параметра из поля заголовка Content-Type, опционный строчный пробел и заключительные CRLF.

    Символы дефис служат для некоторой совместимости с ранним методом (RFC-934) инкапсуляции сообщений, и для облегчения поиска границ для некоторых приложений. Однако следует заметить, что составные сообщения не вполне совместимы с инкапсуляцией, описанной в RFC-934. В частности, они не подчиняются RFC-934 регламентации использования кавычек для вложенных строк, которые начинаются с дефиса. Этот механизм был выбран помимо RFC-934, потому что при данной схеме происходит удлинение строк для каждого уровня закавычивания. Возрастание длины строк, а также то, что некоторые реализации SMTP осуществляют разрыв строк, делают механизм RFC-934 неприменимым для составных сообщений при большой глубине вложений.

    Грамматика для параметров поля Content-type такова, что в строке Content-type часто необходимо помещать пограничный параметр в кавычки. Это необходимо не всегда, но никогда не повредит. Программисты должны тщательно изучить грамматику, для того чтобы избежать генерации некорректных полей Content-type. Таким образом, типичное поле заголовка "multipart" Content-Type может выглядеть как:

    Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
    Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p (из-за двоеточия) и должно вместо этого выглядеть как
    Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

    Это значение Content-Type указывает, что содержимое состоит из одной или более частей со структурой, которая синтаксически идентична сообщению RFC-822, за исключением того, что область заголовка может быть совершенно пустой, а каждая из частей начинается со строки

    --gc0pJq0M:08jU534c0p

    Пограничный разделитель должен размещаться в начале строки, т.e., следовать за CRLF, а начальный CRLF рассматривается объединенным со строкой пограничного разделителя, а не частью предшествующей секции. За границей может следовать нуль или более символов строчного пробела (HT, SP). Далее следует еще один CRLF и поля заголовка следующей части, или два CRLF, что означает отсутствие полей заголовка следующей части. Если поле Content-Type отсутствует, предполагается объект типа "message/rfc822" в сообщении "multipart/digest", в противном случае "text/plain".

    Граничные разделители не должны появляться внутри инкапсулированного материала и не должны быть длиннее 70 символов, не считая двух начальных символов дефис.

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

    --gc0pJq0M:08jU534c0p--

    Сравнение пограничной строки должно сопоставлять значение пограничного параметра с началом каждой строки-кандидата. Полного совпадения всей строки-кандидата не требуется, достаточно наличия разграничителя, следующего за CRLF.

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

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

    Ниже представлен простой пример составного сообщения, имеющего две части, каждая из которых содержит чистый текст, введенный явно и неявно:

    From: Nathaniel Borenstein
    To: Ned Freed
    Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
    Subject: Sample message
    MIME-Version: 1.0
    Content-type: multipart/mixed; boundary="simple boundary"

    Это преамбула. Она будет проигнорирована, но, тем не менее, это удобное место, чтобы отправитель мог поместить сообщение для принимающей стороны, которая не поддерживает MIME.

    простая граница

    Это неявно введенный чистый US-ASCII-текст. Он не завершается на данной строке

    простая граница

    Content-type: text/plain; charset=us-ascii. Это явно введенный чистый US-ASCII-текст. Он завершается на данной строке

    простая граница

    Это эпилог. Он также игнорируется

    Использование типа среды "multipart" в части тела в пределах другого составного объекта вполне допустимо. В таких случаях следует позаботиться о том, чтобы каждый из последовательно вложенных объектов использовал свой уникальный пограничный разделитель. Применение типа среды "multipart" при наличии только одной части тела может быть полезным в определенном контексте и вполне допустимо.

    Практика показала, что тип "multipart" с единственной составной частью полезен для посылки сообщений с нетекстовым типом среды. Он имеет возможность формирования преамбулы, как места, где можно поместить инструкции по декодированию. Кроме того, многие шлюзы SMTP перемещают или удаляют заголовки MIME, и хороший MIME-декодер таким путем может получить необходимую информацию даже в отсутствие заголовка Content-Type и корректно декодировать сообщение.

    Единственным обязательным глобальным параметром для типа среды "multipart" является граничный параметр, который состоит из 1 - 70 кодов из символьного набора, который надежен по отношению преобразований, осуществляемых почтовыми шлюзами. Значение параметра не должно завершаться пробелом. Формально это записывается в BNF-представлении следующим образом.

    boundary := 0*69 bcharsnospace
    bchars := bcharsnospace / " "
    bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

    Вообще тело объекта "multipart" может быть специфицировано как:

    dash-boundary := "--" boundary
    ; boundary берется из значения граничного параметра поля Content-Type.
    multipart-body := [preamble CRLF]

    dash-boundary transport-padding CRLF

    body-part *encapsulation

    close-delimiter transport-padding

    [CRLF epilogue]

    transport-padding := *LWSP-char

    Отправители не должны генерировать транспортные
    ; заполнители ненулевой длины, но получатели
    ; должны уметь обрабатывать заполнители, введенные
    ; при транспортировке.

    encapsulation := delimiter transport-padding CRLF body-part
    delimiter := CRLF dash-boundary
    close-delimiter := delimiter "--"
    >epilogue := discard-text
    ; Строки части тела не должны начинаться с дефис-границы, а разделитель
    ; не должен появляться где-либо в теле секции. Заметим, что семантика части тела
    ; отличается от семантики сообщения, как это описано в тексте.
    OCTET := <любое значение октета 0-255 >

    Введение пробелов (HT, SP) и комментариев RFC 822 между элементами, показанными выше, не допустимо, так как эти BNF не специфицируют структурированное поле заголовка.

    В определенных транспортных зонах регламентации RFC 822, такие как ограничение применения каких-либо символов, помимо печатных кодов US-ASCII могут не действовать. Ослабление этих ограничений может рассматриваться как локальное расширение определения тел, например, чтобы включить октеты вне набора US-ASCII, постольку, поскольку эти расширения поддерживаются системой передачи и соответствующим образом документированы в поле заголовка Content-Transfer-Encoding. Однако заголовки ни в коем случае не могут содержать чего-либо помимо кодов US-ASCII.

    5.1.2. Обработка вложенных и составных сообщений

    Субтип "message/rfc822" не имеет других условий завершения кроме окончания массива данных. Аналогично, некорректно укороченный составной объект не будет иметь завершающего разделителя, что может вызвать нарушение работы почтовой системы.

    Существенно, чтобы такие объекты обрабатывались корректно, когда они сами вложены в другие составные структуры. Реализации MIME должны уметь распознавать граничные маркеры на любом уровне вложения.

    5.1.3. Субтип Mixed

    Субтип "mixed" типа "multipart" предназначен для использования в условиях, когда части тела независимы и должны объединяться в определенном порядке. Любые субтипы "multipart", которые не распознаны программой, должны восприниматься как субтип "mixed".

    5.1.4. Субтип Alternative

    Тип "multipart/alternative" синтаксически идентичен "multipart/mixed", но имеет иную семантику. В частности, каждая часть тела является альтернативой одной и той же информации.

    Системы должны распознавать, что содержимое различных частей взаимозаменяемы. Системы должны выбрать наилучший тип на основе локального окружения и в некоторых случаях с использованием диалога с пользователем. Как и для "multipart/mixed", порядок частей тела является существенным. В этом случае, альтернативы появляются в порядке возрастания правдоподобия оригинальному содержимому. Вообще наилучшим выбором является последняя часть типа, поддерживаемая локальной средой приемной системы..

    "Multipart/alternative" может использоваться, например, для посылки сообщения в любом формате таким образом, чтобы его было легко отобразить:

    From: Nathaniel Borenstein
    To: Ned Freed
    Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
    Subject: Formatted text mail
    MIME-Version: 1.0
    Content-Type: multipart/alternative; boundary=boundary42
    --boundary42
    Content-Type: text/plain; charset=us-ascii
    ... здесь следует версия сообщения в виде чистого текста ...

    --boundary42
    Content-Type: text/enriched
    ... здесь следует версия сообщения RFC 1896 в виде обогащенного текста (text/enriched) ...

    --boundary42
    Content-Type: application/x-whatever
    ... здесь следует наиболее причудливая версия сообщения ...
    --boundary42--

    В этом примере пользователи, чья почтовая система может работать с форматом "application/x-whatever", увидят только причудливую версию сообщения, в то время как другие пользователи увидят версию с обогащенным или чистым текстом, в зависимости от возможностей их системы.

    Вообще, агенты пользователя, которые формируют объекты "multipart/alternative" должны размещать части тела в порядке их предпочтения, то есть, предпочтительный формат следует последним. Посылающий агент пользователя должен поместить простейший формат текста первым, а обогащенный - последним. Принимающие агенты должны воспринять самый последний формат, который они способны отобразить. В случае, когда одной из альтернатив является тип "multipart", который содержит нераспознанные составные части, агент пользователя может отобразить эту альтернативу, более раннюю или даже обе версии сообщения.

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

    Каждая часть объекта "multipart/alternative" представляет одну и ту же информацию, версии не необязательно тождественны. Например, информация теряется, когда осуществляется трансляция ODA в PostScript или в чистый текст. Рекомендуется, чтобы каждая часть имела свое значение Content-ID в тех случаях, когда содержимое частей неэквивалентно. Например, там, где несколько частей типа "message/external-body" специфицируют способы доступа к идентичной информации, следует использовать одни и те же значения поля Content-ID. Возможен вариант, когда одно значение Content-ID может относиться к объекту "multipart/alternative", в то время как одно или более других значений Content-ID будут относиться к частям внутри объекта.

    5.1.5. Субтип Digest

    Этот документ определяет субтип "digest" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в дайджесте, значение по умолчанию Content-Type для части тела меняется с "text/plain" на "message/rfc822". Это сделано, для того чтобы допустить более читаемый формат дайджеста, совместимый с RFC-934.

    Хотя можно специфицировать значение Content-Type для части тела в дайджесте, который отличается от "message/rfc822", такая часть как "text/plain", содержащая описание материала в дайджесте, делает это нежелательным. Тип содержимого "multipart/digest" предназначен для использования при посылке группы сообщений. Если необходима часть "text/plain", она должна быть включена как отдельная компонента сообщения "multipart/mixed". Дайджест в этом формате может выглядеть как.

    From: Moderator-Address
    To: Recipient-List
    Date: Mon, 22 Mar 1994 13:34:51 +0000
    Subject: Internet Digest, volume 42
    MIME-Version: 1.0
    Content-Type: multipart/mixed;
    boundary="---- главный разделитель ----"
    ------ главный разделитель ----
    ...Вводный текст или содержимое таблицы...
    ------ главный разделитель ----
    Content-Type: multipart/digest;
    boundary="---- следующее сообщение ----"
    ------ следующее сообщение ----
    From: someone-else
    Date: Fri, 26 Mar 1993 11:13:32 +0200
    Subject: my opinion
    ... здесь размещается тело...
    ------ следующее сообщение ----

    From: someone-else-again
    Date: Fri, 26 Mar 1993 10:07:13 -0500
    Subject: my different opinion
    ... здесь размещается следующее тело ...
    ------ следующее сообщение ------
    ------ главный разделитель ------

    5.1.6. Субтип Parallel

    Этот документ определяет субтип "parallel" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в параллельном объекте, порядок частей тела не играет роли.

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

    5.1.7. Прочие субтипы Multipart

    В будущем ожидается появление новых субтипов "multipart". Реализации MIME должны уметь работать с нераспознанными субтипами "multipart" как с "multipart/mixed".

    5.2. Тип среды Message

    Часто желательно при посылке почты вложить туда какое-то другое сообщение. Для решения этой задачи определен специальный тип среды "message". В частности, для вложения в сообщения RFC-822 служит субтип "rfc822"

    Субтип "message" часто накладывает ограничения на допустимые типы кодирования. Эти ограничения описаны для каждого специфического субтипа. Почтовые шлюзы, системы транспортировки и другие почтовые агенты иногда изменяют заголовки верхнего уровня в сообщениях RFC 822. В частности, они часто добавляют, удаляют и меняют порядок полей заголовков. Эти операции запрещены для заголовков, вложенных в тело сообщения типа "message."

    5.2.1. Субтип RFC822

    Тип среды "message/rfc822" указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле "message/rfc822" заголовков "From", "Date", и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков "From", "Subject" или "Date". Следует заметить, что, несмотря на использование чисел "822", объект "message/rfc822" не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение "message/rfc822" может быть статьей новостей или сообщением MIME.

    В теле объекта "message/rfc822" не разрешены никакие кодировки помимо "7bit", "8bit" или "binary". Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047.

    5.2.2. Субтип Partial

    Субтип "partial" определен, для того чтобы разрешить разделять на части слишком большие объекты, которые затем доставляются в виде отдельных почтовых сообщений и автоматически восстанавливаются как единое целое принимающим агентом пользователя. Этот механизм может использоваться, когда промежуточный транспортный агент ограничивает максимальный размер почтового сообщения. Тип среды "message/partial", таким образом, указывает, что тело содержит фрагмент некоторого большого объекта.

    Так как данные типа "message" могут не быть закодированны в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты "message/partial" созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений "message/partial", каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно конечно дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине, было специфицировано, что объекты типа "message/partial" должны всегда иметь транспортное кодирование "7bit" (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования "8bit" или "binary" для MIME-объектов типа "message/partial" запрещено. Это в свою очередь предполагает, что внутреннее сообщение не должно использовать кодирование "8bit" или "binary". Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо.

    В поле Content-Type типа "message/partial" необходимо специфицировать три параметра. "id" - уникальный идентификатор, который должен использоваться для привязки фрагментов друг к другу. "number" - целое число, которое является номером фрагмента. "total" - целое число, характеризующее полное число фрагментов. Число фрагментов является опционным и обязательно присутствует только в последнем фрагменте. Заметим также, что эти параметры могут быть заданы в любом порядке. Таким образом, второй сегмент 3-фрагментного сообщения может иметь поля заголовка одного из следующих видов.

    ontent-Type: Message/Partial; number=2; total=3;

    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

    ontent-Type: Message/Partial;

    id="oc=jpbe0M2Yt4s@thumper.bellcore.com";

    number=2

    Но в третьем сегменте должно быть специфицировано полное число фрагментов.

    Content-Type: Message/Partial; number=3; total=3;

    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

    Заметьте, что нумерация фрагментов начинается с 1, а не 0.

    Когда фрагменты объекта, разорванные таким способом, складываются вместе, результатом всегда будет исходный MIME-объект, который может иметь свое собственное поле заголовка Content-Type, и, следовательно, иметь любой другой тип данных.

    5.2.2.1. Фрагментация и сборка сообщений

    Семантика восстановленных фрагментов сообщений должна соответствовать "внутреннему" сообщению, а не сообщению, в которое оно вложено. Это делает возможным, например, посылку большого аудио-сообщения в виде нескольких сообщений-фрагментов таким образом, что получатель воспримет его как простое аудио-сообщение, а не инкапсулированное сообщение, содержащее аудио-сообщение. Такая инкапсуляция рассматривается как прозрачная. Когда формируются фрагменты и осуществляется сборка составных частей сообщения "message/partial", заголовки инкапсулированного сообщения должны объединяться с заголовками вложенных объектов. При реализации этой процедуры должны выполняться следующие правила:

    (1)

    Фрагментирующие агенты должны разделять сообщения только по границам строк. Это ограничение вводится из-за того, что при несоблюдении данного правила возникнет транспортная проблема сохранения семантики сообщения, не заканчивающегося последовательностью CRLF. Многие виды транспорта не способны решить такую задачу.

    (2)

    Все поля заголовка исходного вложенного сообщения, за исключением тех, чьи имена начинаются с "Content-", и специфических полей заголовка "Subject", "Message-ID", "Encrypted" и "MIME-Version", должны копироваться в новое сообщение.

    (3)

    Поля заголовка вложенного сообщения, начинающиеся с "Content-", плюс поля "Subject", "Message-ID", "Encrypted" и "MIME-Version" fields, должны быть добавлены в порядке к полям нового сообщения. Любые поля заголовка, которые не начинаются с "Content-" (за исключением полей "Subject", "Message-ID", "Encrypted" и "MIME-Version") будут проигнорированы и отброшены.

    (4)

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

    5.2.2.2. Пример фрагментации и сборки

    Если аудио-сообщение разделено на два фрагмента, первая часть может выглядеть как:

    X-Weird-Header-1: Foo
    From: Bill@host.com
    Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
    Subject: Audio mail (part 1 of 2)
    Message-ID:
    MIME-Version: 1.0
    Content-type: message/partial; id="ABC@host.com";
    number=1; total=2

    X-Weird-Header-1: Bar
    X-Weird-Header-2: Hello
    Message-ID:
    Subject: Audio mail
    Content-type: audio/basic
    Content-transfer-encoding: base64
    ... здесь помещается первая половина закодированных аудио-данных ...
    а вторая часть может выглядеть следующим образом:

    From: Bill@host.com
    >To: joe@otherhost.com
    Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
    Subject: Audio mail (part 2 of 2)
    MIME-Version: 1.0
    Message-ID:
    Content-type: message/partial;
    id="ABC@host.com"; number=2; total=2
    ... здесь помещается вторая половина закодированных аудио-данных ...

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

    X-Weird-Header-1: Foo
    From: Bill@host.com
    To: joe@otherhost.com
    Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
    Subject: Audio mail
    Message-ID:
    MIME-Version: 1.0
    Content-type: audio/basic
    Content-transfer-encoding: base64
    ... здесь помещается первая половина закодированных аудио-данных ...
    ... здесь помещается вторая половина закодированных аудио-данных ...

    Включение в заголовки второго и последующих секций фрагментированного сообщения поля "References" (ссылка), которое указывает на Message-Id (идентификатор сообщения) предшествующей секции, может быть полезно для системы чтения почты, которая умеет отслеживать ссылки. Однако генерация полей "References" является опционной.

    Наконец, следует заметить, что поле "Encrypted" заголовка является устаревшим из-за внедрения конфиденциальной почты PEM (Privacy Enhanced Messaging; RFC-1421, RFC-1422, RFC-1423, RFC-1424), но правила описанные выше, несмотря ни на что, описывают правильный путь его обработки, если оно встретится в контексте прямого и обратного преобразования фрагментов "message/partial".

    5.2.3. Субтип External-Body

    Субтип external-body указывает, что в сообщении содержатся не данные, а ссылка на место, где эти данные находятся. В этом случае параметры описывают механизм доступа к внешним данным.

    Когда объект MIME имеет тип "message/external-body", он состоит из заголовка, двух последовательностей CRLF, и заголовка для инкапсулированного сообщения. Если появится еще одна пара последовательностей CRLF, это завершит заголовок инкапсулированного сообщения. Однако так как тело инкапсулированного сообщения само является внешним, оно не появится вслед за заголовком. Например, рассмотрим следующее сообщение:

    Content-type: message/external-body;

    access-type=local-file;

    name="/u/nsb/Me.jpeg"

    Content-type: image/jpeg
    Content-ID:
    Content-Transfer-Encoding: binary
    Это в действительности не тело!

    Область в конце, которую можно назвать телом-фантомом, игнорируется для большинства сообщений с внешним телом. Однако оно может использоваться для хранения вспомогательной информации для некоторых таких сообщений, как это действительно бывает, когда тип доступа - "mail-server". Единственный тип доступа, описанный в этом документе и использующий тело-фантом, это "mail-server", но могут быть описаны другие типы в будущем.

    Инкапсулированные заголовки во всех объектах "message/external-body" должны включать в себя поле заголовка Content-ID, для того чтобы предоставить уникальный идентификатор, который служит для ссылки на данные. Этот идентификатор может быть использован в процессе кэширования и для распознавания входных данных, когда типом доступа является "mail-server".

    Заметим, что, как это специфицировано здесь, лексемы, которые описывают данные внешнего тела, такие как имена файлов и команды почтового сервера, должны быть записаны с использованием символьного набора US-ASCII.

    Как с "message/partial", объекты MIME типа "message/external-body" MUST имеют транспортное кодирование 7-бит (по умолчанию). В частности, даже в среде, которая поддерживает 8-битовую транспортировку, использование транспортного кодирования "8bit" или "binary" категорически запрещено для объектов типа "message/external-body".

    5.2.3.1. Общие параметры External-Body

    С "message/external- body" могут использоваться следующие параметры:

    (1)

    ACCESS-TYPE (тип доступа). Слово, характеризующее поддерживаемый механизм доступа, с помощью которого можно получить файл или данные. Это слово не чувствительно к регистру, в котором напечатано. Параметр может принимать следующие значения "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE" и "MAIL-SERVER". Будущие значения, за исключением экспериментальных, начинающихся с "X-", должны регистрироваться IANA, как это описано в RFC-2048. Данный параметр является обязательным и должен присутствовать в каждом "message/external-body".

    (2)

    EXPIRATION (конец срока действия). Дата (имеет синтаксис "date-time" как в RFC-822, документ RFC-1123 разрешил 4 цифры для обозначения года), после которой существование внешних данных не гарантируется. Этот параметр может использоваться с любым типом доступа и является опционным.

    (3)

    SIZE (размер). Число октетов данных. Этот параметр предназначен, для того чтобы помочь получателю решить, достаточно ли ресурсов памяти для приема этих внешних данных. Заметим, что параметр описывает размер данных в канонической форме, то есть, до использования какого-либо транспортного кодирования или после декодирования. Этот параметр может использоваться с любым типом доступа и является опционным.

    (4)

    PERMISSION (разрешение). Не чувствительное к регистру поле, которое указывает, предполагается ли возможность для клиента переписать данные. По умолчанию или, если разрешение соответствует "read", считается, что это запрещено и что, если данные однажды извлечены, они не потребуются никогда. Если PERMISSION соответствует "read-write", такое предположение не верно. "Read" и "Read-write" являются единственными определенными значениями параметра разрешения. Этот параметр используется с любым типом доступа и является опционным.

    5.2.3.2. Типы доступа 'ftp' и 'tftp'

    Тип доступа FTP или TFTP указывают, что тело сообщения доступно в виде файла с помощью протоколов FTP [RFC-959] или TFTP [RFC- 783], соответственно. Для этих типов доступа необходимы следующие параметры:

    (1)

    NAME (имя). Имя файла, который содержит тело данных.

    (2)

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

    (3)

    Прежде чем какие-либо данные будут извлечены с помощью FTP, пользователь должен выполнить процедуру аутентификации (ввести имя и пароль) на машине, указанной в параметре SITE. По соображениям безопасности имя и пароль не специфицируются параметрами типа доступа, они должны быть получены непосредственно от пользователя.

    Кроме того, следующие параметры являются опционными:

    (1)

    DIRECTORY (каталог). Каталог, из которого должен быть взят файл с именем, заданным параметром NAME.

    (2)

    MODE (режим). Строка символов, не зависящая от регистра ввода и указывающая на режим, который должен использоваться при извлечении информации. Допустимыми значениями параметра для типа доступа "TFTP" являются "NETASCII", "OCTET" и "MAIL", как это определено для протокола TFTP [RFC- 783]. Допустимыми значениями параметра для типа доступа "FTP" являются "ASCII", "EBCDIC", "IMAGE" и "LOCALn", где "n" - целое число, обычно 8. Они соответствуют типам представления "A" "E" "I" и "L n", как это задано протоколом FTP [RFC-959]. Заметим, что "BINARY" и "TENEX" не являются корректными значениями для MODE и что вместо этого следует использовать "OCTET", "IMAGE" или "LOCAL8". Если параметр MODE не задан, значением по умолчанию является "NETASCII" для TFTP и "ASCII" во всех прочих случаях.

    5.2.3.3. Тип доступа 'anon-ftp'

    Тип доступа "anon-ftp" идентичен варианту "ftp", за исключением того, что пользователю не нужно предоставлять имя и пароль. Вместо этого протокол ftp воспользуется именем "anonymous" и паролем, равным почтовому адресу пользователя.

    5.2.3.4. Тип доступа 'local-file'

    Тип доступа "local-file" указывает, что тело данных доступно в виде файла на локальной ЭВМ. Для этого типа доступа определены два дополнительные параметра:

    (1)

    NAME (имя). Имя файла, который содержит тело данных. Этот параметр является обязательным для типа доступа "local-file".

    (2)

    SITE (узел). Спецификатор домена для данной ЭВМ или набора машин, которые имеют доступ к данному информационному файлу. Этот опционный параметр используется для описания локального указателя на данные, т.е., узел или группа узлов, откуда данный файл доступен. В качестве символов подмены в имени домена могут использоваться звездочки, как, например, в "*.bellcore.com", чтобы указать на группу ЭВМ, откуда данные доступны непосредственно.

    5.2.3.5. Тип доступа 'mail-server' Access-Type

    Тип доступа "mail-server" указывает, что тело данных доступно на почтовом сервере. Для этого типа доступа определены два дополнительные параметра:

    (1)

    SERVER (сервер). Спецификация адреса почтового сервера, с которого может быть получены данные. Этот параметр является обязательным для типа доступа "mail-server".

    (2)

    SUBJECT (тема сообщения). Тема сообщения (subject), которая используется в почтовом сообщении с целью получения данных. Этот параметр является опционным.

    Так как почтовые сервера воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с поле заголовка content-type. Вместо этого, она заносится как тело-фантом, когда тип среды соответствует "message/external-body", а тип доступа - mail-server.

    Заметим, что MIME не определяет синтаксис почтового сервера. Скорее, оно позволяет включение произвольных команд почтового сервера в тело-фантом. Программные реализации должны включать тело-фантом в тело сообщения, которое посылается по адресу почтового сервера для получения нужных данных.

    В отличие от других типов доступа, доступ к почтовому серверу является асинхронным и происходит в произвольный момент времени. По этой причине важно, чтобы существовал механизм, с помощью которого полученные данные могли быть сопоставлены с исходным объектом "message/external-body". Почтовые серверы MIME должны использовать то же поле Content-ID в сообщении-отклике, которое было использовано в исходных объектах "message/external-body", для того чтобы облегчить такое сопоставление.

    5.2.3.6. Соображения безопасности External-Body

    Объекты "Message/external-body" подводят к следующим важным соображениям безопасности:

    (1)

    Доступ к данным через указатель "message/external-body" эффективно приводит к тому, что получатель сообщения выполняет операцию, которую специфицировал отправитель. Следовательно, отправитель сообщения может заставить получателя выполнить нечто, что тот бы в противном случае не сделал. Например, отправитель может специфицировать процедуру, которая попытается извлечь данные, для получения которых тот не имеет авторизации, принуждая получателя помимо его воли нарушить некоторые правила безопасности. По этой причине агенты пользователя, способные работать с внешними указателями, должны сначала описать процедуру, которую ни хотят предложить выполнить получателю, попросить разрешения и только после этого запускать этот процесс.

    (2)

    Иногда MIME используется в среде, которая предоставляет некоторые гарантии целостности и аутентичности сообщений. В этой ситуации такие гарантии можно отнести только к собственно содержимому сообщения. Что касается механизма MIME "message/external-body", здесь такие гарантии, вообще говоря, могут быть и не реализованы. В частности, имеется возможность разрушить определенные механизмы доступа, даже если сама система доставки сообщений вполне безопасна.

    5.2.3.7. Примеры и дальнейшие расширения

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

    Для распределенных файловых систем очень трудно знать заранее группу машин, где файл может быть доступен непосредственно. Следовательно, имеет смысл предоставить как имя файла на случай его прямой доступности, так имена одного или нескольких узлов, где может быть доступен этот файл. Программные реализации могут пытаться извлечь удаленные файлы, используя FTP или другой протокол. Если внешнее тело доступно за счет нескольких механизмов, отправитель может включить несколько объектов типа "message/external-body" в секции тела объекта "multipart/alternative".

    Однако механизм внешнего тела не ограничивается извлечением файлов, как это показывается типом доступа mail-server. Помимо этого, можно предположить, например, использование видео-сервера для внешнего доступа к видео клипам.

    Поля заголовка вложенного сообщения, которые появляются в теле "message/external-body" должны использоваться для декларации типа среды внешнего тела, если оно представляет собой нечто отличное от чистого текста US-ASCII, так как внешнее тело не имеет секции заголовка, чтобы декларировать тип. Аналогично здесь должно быть также декларировано любое транспортное кодирование, отличное от "7bit". Таким образом, полное сообщение "message/external-body", относящееся к объекту в формате PostScript, может выглядеть как:

    From: От кого-то
    To: Кому-то
    Date: Когда-то
    Subject: Нечто
    MIME-Version: 1.0
    Message-ID:
    Content-Type: multipart/alternative; boundary=42
    Content-ID:

    --42
    Content-Type: message/external-body; name="BodyFormats.ps";

    site="thumper.bellcore.com"; mode="image";

    access-type=ANON-FTP; directory="pub";

    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

    Content-type: application/postscript
    Content-ID:
    --42
    Content-Type: message/external-body; access-type=local-file;

    name="/u/nsb/writing/rfcs/RFC-MIME.ps";

    site="thumper.bellcore.com";

    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

    Content-type: application/postscript
    Content-ID:

    --42
    Content-Type: message/external-body;

    access-type=mail-server

    server="listserv@bogus.bitnet";

    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

    Content-type: application/postscript
    Content-ID:
    get RFC-MIME.DOC
    --42--

    Заметим, что в вышеприведенных примерах в качестве транспортного кодирования для Postscript данных предполагается "7bit".

    Подобно типу "message/partial", тип среды "message/external-body" предполагается прозрачным, т.е. передается тип данных внешнего тела, а не сообщение с телом данного типа. Таким образом, заголовки внешней и внутренней частей должны быть объединены с использованием правил, изложенных выше для "message/partial". В частности, это означает, что поля Content-type и Subject переписываются, а поле From сохраняется в неизменном виде.

    Заметьте, что, так как внешние тела не передаются вместе с указателем, они не должны удовлетворять транспортным ограничениям, которые налагаются на сам указатель. В частности, почтовая транспортная среда Интернет может реализовать 7-битовый обмен и накладывать ограничение на длину строк, но они не распространяются на указатели на двоичное внешнее тело. Таким образом, транспортное кодирование не обязательно, но допустимо.

    Заметим, что тело сообщения типа "message/external-body" регламентируется базовым синтаксисом сообщения RFC 822. В частности, все, что размещено перед первой парой CRLF является заголовком, в то время как все, что следует после заголовка, представляет собой данные, которые игнорируются для большинства типов доступа.

    6. Экспериментальные значения типа среды

    Значение типа среды, начинающееся с символов "X-" представляет собой частное значение, предназначенное для применения системами, которые согласились между собой работать в таком режиме. Любой формат, не являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-".

    Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня.

    Приложение A -- обзор грамматики

    Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены.

    boundary := 0*69 bcharsnospace
    bchars := bcharsnospace / " "
    bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
    body-part := <"сообщение" как это определено в RFC-822, со всеми опционными полями заголовка, не начинающимися со специфицированных дефис-границ, и без разделителей в пределах тела сообщения. Заметим, что семантика секции отличается от семантики сообщения, как это описано в тексте.>

    close-delimiter := delimiter "--"
    dash-boundary := "--" boundary

    boundary берется из значения пограничного параметра из поля Content-Type.

    delimiter := CRLF dash-boundary
    discard-text := *(*text CRLF); Может игнорироваться или отбрасываться.
    encapsulation := delimiter transport-padding CRLF body-part
    epilogue := discard-text
    multipart-body := [preamble CRLF]

    Dash-boundary transport-padding CRLF

    body-part *encapsulation

    close-delimiter transport-padding

    [CRLF epilogue]

    preamble := discard-text
    transport-padding := *LWSP-char
    ; Отправители не должны генерировать транспортных заполнителей не нулевой
    ; длины, но получатели должны уметь обрабатывать заполнители, добавленные в
    ; сообщение при транспортировке.

    III. Расширения для заголовков сообщений с не-ASCII текстом

    В этом разделе описывается техника кодирования не-ASCII-текста в различных частях заголовка сообщения RFC-822 [2].

    Подобно тому, как это рассказано в первом разделе описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения так, чтобы даже специфические) удаляют некоторые поля заголовков, сохраняя другие, (b) меняет содержимое адресов в полях To или Cc, (c) меняют вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "<", "," или ":".

    Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого, определенные последовательности "обычных" печатных ASCII символов (известных как "encoded-words" - кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова.

    Вообще, "encoded-word>" представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного метода кодирования.

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

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

    Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, используемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: 'addr-spec' (спецификация адреса), 'атом', 'CHAR', 'комментарий', 'CTL', 'ctext', 'linear-white-space' (HT| SP|CRLF), 'фраза', 'quoted-pair', 'закавыченная строка', 'пробел' и 'слово'. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822.

    Когда в данном документе встречается термин "ASCII", он относится к "7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME "US-ASCII".

    2. Синтаксис кодированных слов (encoded-words)

    'Кодировочное слово' определено согласно следующей ABNF-грамматике. Используется нотация RFC-822, за исключением того, что символы "white space" (HT и SP) не должны появляться между компонентами кодировочного слова.

    encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

    charset = token

    ; см. секцию 3

    encoding = token

    ; см. секцию 4

    token = 1*
    especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "="
    encoded-text = 1*<Любой печатный ASCII-символ, отличный от "?" или пробела (SP)>

    ; (см. "Использование encoded-words в заголовках сообщений", часть 5)

    Слова 'encoding' и 'charset' не зависят от регистра, в котором напечатаны. Таким образом символьный набор с именем "ISO-8859-1" эквивалентен "ISO-8859-1", а кодирование с именем "Q" может записываться как "Q" или "q".

    'Кодировочное слово' (encoded-word) не может быть длиннее 75 символов, включая 'charset', 'encoding', 'encoded-text' и разделители. Если желательно закодировать текст больший, чем 75 символов, можно использовать несколько кодировочных слов, разделенных CRLF SP.

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

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

    'Кодировочные слова' сконструированы так, чтобы быть узнаваемыми как "атомы" программой грамматического разбора RFC-822. Как следствие, незакодированные символы SP и HT в пределах кодировочных слов запрещены. Например, символьная последовательность

    =?iso-8859-1?q?this is some text?=

    будет воспринята программой разборки RFC-822 как четыре атома, а не как один атом, или как ''кодировочное слово" (в случае программы разборки, воспринимающей кодировочные слова). Правильный способ закодировать строку "this is some text" - это кодировать и сами пробелы, например:

    =?iso-8859-1?q?this=20is=20some=20text?=

    3. Символьный набор

    Секция 'charset' кодировочного слова специфицирует символьный набор, соответствующий незакодированному тексту. 'charset' может представлять любой символьный набор, разрешенный параметром "charset" MIME части тела "text/plain", или любой символьный набор с именем, зарегистрированным IANA для использования с типом содержимого text/plain MIME.

    Некоторые символьные наборы используют технику переключения кодов для перехода между режимом "ASCII" и другими режимами. Если текст в кодировочном слове содержит последовательность, которая заставляет интерпретатор символьного набора переключиться из режима ASCII, он должен содержать дополнительные управляющие коды, которые переключат систему в ASCII-режим в конце кодировочного слова.

    Когда имеется возможность использования более одного символьного набора для представления текста в кодировочном слове и в отсутствии частного соглашения между отправителем и получателем сообщения, рекомендуется, чтобы предпочтительно использовались члены символьного семейства ISO-8859-*.

    4. Кодирование

    Первоначально легальными значениями кодирования являются "Q" и "B". Эти кодировки описаны ниже. Кодирование "Q" рекомендуется для использования, когда большинство символов, которые нужно преобразовать, представлены в наборе ASCII; в противном случае, следует использовать "B"-кодирование. Несмортя ни на что программа, читающая почту, которая воспринимает кодировочные слова, должна быть способна обрабатывать любые кодировки для любых символьных наборов, которые она поддерживает.

    В кодированном тексте может использоваться только субнабор печатных ASCII-символов. Символы SP и HT не допустимы, чтобы начало и конец кодировочного слова были выделены однозначно. Символ "?" используется в "кодировочном слове" для разделения различных частей этого слова друг от друга. По этой причине "?" не может появляться в секциях "кодировочного слова". Другие символы могут также оказаться нелегальными в определенном контексте. Например, 'encoded-word' во 'фразе', предшествующей адресу в поле заголовка From не может содержать какие-либо специальные символы ("specials"), определенные в RFC-822. Наконец, некоторые другие символы также недопустимы в определенных контекстах, это связано с необходимостью обеспечить надежность пересылки сообщений через почтовые шлюзы.

    "B"-кодирование автоматически отвечает этим требованиям. "Q"-кодирование допускает использование широкого перечня печатных символов в некритических позициях заголовка сообщения (например, в Subject), с ограниченным списком символов, допустимых в других полях.

    4.1. "B"-кодирование

    "B"-кодирование идентично "BASE64", описанному RFC-2045.

    4.2. "Q"-кодирование

    "Q"-кодирование подобно закавыченным строкам печатных символов ("Quoted-Printable"), описанным в RFC-2045. Оно создано, для того чтобы позволить читать текст, содержащему по большей части ASCII-символы, а алфавитно-цифровом терминале без декодирования.

    (1)

    Любой 8-битовый код может быть представлен с помощью символа "=", за которым следуют два шестнадцатеричных числа. Например, если бы используемый символьный набор был ISO-8859-1, символ "=" кодировался как "=3D", а пробел (SP) как "=20". (Для шестнадцатеричных чисел следует использовать верхний регистр "A" - "F".)

    (2)

    8-битовое шестнадцатеричное число 20 (напр., ISO-8859-1 SPACE) может быть представлено как "_" (знак подчеркивания, ASCII 95.). (Этот символ может не пройти через некоторые почтовые шлюзы, но его использование существенно улучшает читаемость "Q"-кодированных данных в почтовых системах, которые поддерживают этот вид кодирования). Заметим, что "_" всегда представляется шестнадцатеричным кодом 20, даже если символ пробел (SPACE) занимает другую кодовую позицию в используемом символьном наборе.

    (3)

    8-битовые значения, которые соответствуют печатным ASCII-символам, отличным от "=", "?" и "_", могут быть представлены самими собой. Об ограничениях см. раздел 5. В частности, SP и HT не должны представляться самими собой в пределах кодировочных слов.

    5. Использование кодировочных слов в заголовках сообщений

    'encoded-word' может появиться в заголовке сообщения или в заголовке тела секции в соответствии со следующими правилами:

    (1)

    'encoded-word' может заменить текстовую лексему (как это определено в RFC-822) в любом из полей заголовка Subject или Comments, в любом поле расширения заголовка, или любом поле секции тела MIME, для которого поле тела определено как '*text'. 'encoded-word' может также появиться в любом поле сообщения или секции тела, определенном пользователем ("X-"). Обычный ASCII-текст и 'кодировочные слова' могут появляться совместно в пределах одного и того же поля заголовка. Однако 'кодировочное слово', появляющееся в поле заголовка, определенное как '*text', должно быть отделено от любого смежного 'encoded-word' или 'текста' с помощью LWS (HT|SP|CRLF).

    (2)

    'encoded-word' может появляться внутри 'комментария', ограниченного "(" и ")", т.е., там, где допустим 'ctext'. Более точно, ABNF-определение (RFC-822) для 'comment' следует скорректировать как:

    comment = "(" *(ctext | quoted-pair | comment | encoded-word) ")"

    "Q"-кодированное 'encoded-word', которое появляется в комментарии не должно содержать символов "(", ")" или ". 'Кодировочное слово', появляющееся в комментарии должно отделяться от смежного 'encoded-word' или 'ctext' с помощью LWS.

    Важно заметить, что комментарии распознаются только внутри структурированных полей тела. В полях, чьи тела определены как '*text', "(" и ")" обрабатываются как обычные символы, а не как разделители комментариев, и применимо правило (1) этой секции. (См. RFC-822, секции 3.1.2 и 3.1.3)

    (3)

    В качестве замены для объекта 'word' во 'фразе', например, перед адресом в заголовке From, To или Cc. ABNF-определение для 'phrase' RFC-822 приобретает вид:
    phrase = 1*( encoded-word / word)

    В этом случае набор символов, который можно использовать с "Q"-кодированным 'encoded-word' ограничивается до: < ASCII-буква верхнего и нижнего регистров, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_" (ASCII 95.)>. 'Кодировочное слово', которое появляется внутри 'фразы', должно быть отделено от любого смежного 'слова', 'текста' или специального символа ('special') посредством LWS. Это единственные места, где может появиться 'encoded-word'. В частности:

    + 'encoded-word' не должно появляться в любой части 'addr-spec'.
    + 'encoded-word' не должно появляться в пределах 'quoted-string'.
    + 'encoded-word' не должно использоваться в поле заголовка Received.
    + 'encoded-word' не должно использоваться в параметре MIME поля Content-Type или Content-Disposition, или в любом структурированном поле тела, за исключением 'comment' или 'phrase'.

    'Кодированный текст' не должен продолжаться от одного 'encoded-word' к другому. Это предполагает, что секция кодированного текста 'B-encoded-word' будет иметь длину кратную 4 символам; для 'Q-encoded-word', за любым символом "=", который появляется в секции кодированного текста, следуют две шестнадцатеричные цифры.

    Каждое 'encoded-word' должно кодировать полное число октетов. 'Кодированный текст' в каждом 'encoded-word' должен быть хорошо оформлен согласно специфицированному кодированию. 'Кодированный текст' не может продолжаться в следующем 'encoded-word'. (Например, "=?charset?Q?=?= =?charset?Q?AB?=" было бы нелегальным, так как два шестнадцатеричные числа "AB" должны следовать за "=" в одном и том же 'encoded-word'.)

    Каждое 'encoded-word' представлять собой целое число символов. Многооктетные символы не могут расщепляться между смежными 'кодировочными словами'.

    Согласно этой схеме кодируются только печатные символы и WS (HT и SP). Однако так как эти схемы кодирования позволяют работать с произвольными октетами, программы чтения почты, которые используют такое декодирование, должны быть избавлены от любых нежелательных побочных эффектов при отображении данных на терминале получателя.

    Использование этих методов для кодирования нетекстовых данных (напр., изображения или голоса) в данном документе не определено. Применение 'кодировочных слов' для представления строк ASCII-символов допустимо, но не рекомендуется.

    6. Поддержка 'кодировочных слов' в программах чтения почты
    6.1. Распознавание 'кодировочных слов' в заголовках сообщений

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

    'кодировочные слова' должны распознаваться как:

    (1)

    Поле заголовка любого сообщения или части тела, определенное как '*text', или любое поле заголовка, определенное пользователем, должно разбираться следующим образом: Начало обозначается LWS (HR|SP|CRLF), любая последовательность вплоть до 75 печатных символов (не содержащая LWS) должна рассматриваться как кандидат в 'кодировочные слова' и проверяться на соблюдение правил синтаксиса, описанных в секции 2 данного раздела. Любую другую последовательность печатных символов следует рассматривать как обычный ASCII-текст.

    (2)

    Любое поле заголовка, не определенное как '*text' должно разбираться согласно синтаксическим правилам для данного поля заголовка. Однако любое 'слово', которое появляется в пределах 'фразы' должно обрабатываться как 'кодировочное слово', если оно отвечает синтаксическим правилам секции 2. В противном случае оно должно обрабатываться как обычное 'слово'.

    (3)

    Внутри 'комментария', любая последовательность с длиной до 75 символов (не содержащая LWS), которая отвечает синтаксическим правилам секции 2, должна обрабатываться как 'кодировочное слово'. В противном случае оно должно обрабатываться как обычный текст комментария.

    (4)

    Поле заголовка MIME-Version может отсутствовать в 'кодировочных словах', которые обрабатываются согласно данной спецификации. Причиной этого является то, что программа чтения почты не предполагает разбирать весь заголовок сообщения, прежде чем отображать строки, которые могут содержать 'кодировочные слова'.

    6.2. Отображение кодированных слов

    Любые распознанные 'кодированные слова' декодируются и, если возможно, полученный в результате текст отображается с использованием стандартного символьного набора.

    Декодирование и отображение закодированных слов происходит, после того как структурные поля тела будут разобраны на лексемы. Следовательно, возможно спрятать 'специальные' символы в 'кодировочных словах', которые при отображении будут неотличимы от 'специальных' символов окружающего текста. По этой и другим причинам вообще невозможно транслировать заголовок сообщения, содержащий 'кодировочные слова', к виду, который может анализироваться программой чтения почты (RFC-822).

    При отображении конкретного поля заголовка, который содержит несколько 'кодировочных слов', любой LWS, который разделяет пару смежных 'кодировочных слов', игнорируется.

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

    Если почтовая программа не поддерживает использованный символьный набор, она может отобразить 'кодировочное слово', как обычный текст (т.е., так как оно записано в заголовке), может попробовать отобразить его с использованием имеющегося символьного набора, или выдать сообщение, что текст не может быть отображен.

    Если используемый символьный набор реализует технику кодового переключения, отображение кодированного текста начинается в режиме "ASCII". Кроме того, почтовая программа должна проверить, что выходное устройство снова в режиме "ASCII", после того как отображено 'кодировочное слово'.

    6.3. Обработка почтовой программой некорректно сформированных 'кодировочных слов'

    Возможно, что 'кодировочное слово', которое легально согласно синтаксическим правилам секции 2, не корректно сформировано с точки зрения регламентаций использованного правила кодирования. Например:

    (1)

    'Кодировочное слово', которое содержит символы нелегальные для конкретного кодирования (Например, "-" в "B"-кодировании, или SP и HT в "B"- или "Q"-кодировании), является некорректно сформированным.

    (2)

    Любое 'кодировочное слово', которое кодирует нецелое число символов или октетов является некорректно сформированным.

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

    7. Согласование

    Программа, формирующая почтовое сообщение и соответствующая данной спецификации, должна гарантировать, что любая строка печатных ASCII-символов, не содержащая HT и SP в пределах '*text' или '*ctext', начинается с "=?" и завершается "?=" является корректным 'кодировочным словом'. ("Начинается" означает: в начале тела сразу после LWS, или сразу после "(" для 'кодировочного слова' в пределах '*ctext'; "завершается" означает: в конце тела, непосредственно перед LWS, или непосредственно перед ")" для 'кодировочного слова' в '*ctext'.) Кроме того, любое 'слово' в 'фразе', которое начинается с "=?" и завершается "?=" должно быть корректным 'кодировочным словом'.

    Программа, читающая почтовые сообщения, совместимые с данной спецификацией должна быть способна отделить 'кодировочное слово' от 'text', 'ctext', или 'слов', которые согласуются с правилами секции 6, где бы они не встретились в заголовке сообщения. Она должна поддерживать "B"- и "Q"-кодирование для любых символьных наборов, которые она поддерживает. Программа должна быть способна отобразить не кодированный текст, если символьный набор соответствует "US-ASCII". Для символьных наборов ISO-8859-*, программа должна быть способна, по крайней мере, отобразить символы, которые совпадают с ASCII.

    8. Примеры

    Ниже приведены примеры заголовок сообщений, содержащих 'кодировочные слова':

    From: =?US-ASCII?Q?Keith_Moore?=
    To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
    CC: =?ISO-8859-1?Q?Andr=E9?= Pirard
    Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

    В выше приведенном примере в 'кодировочном слове' поля, последний символ "=" в конце кодированного текста необходим, так как каждое 'кодировочное слово' должно быть самодостаточным (символ "=" завершает группу из 4 символов base64 представляющих 2 октета). Дополнительный октет может быть закодирован в первом 'кодировочном слове' (так чтобы 'кодировочное слово' содержало число октетов кратное трем). Второе 'кодировочное слово' использует символьный набор, не совпадающий с тем, что применен в первом слове.

    From: =?ISO-8859-1?Q?Olle_J=E4rnefors?=
    To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
    >Subject: Time for ISO 10646?

    To: Dave Crocker
    Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
    From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
    Subject: Re: RFC-HDR care and feeding
    From: Nathaniel Borenstein
    (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
    To: Greg Vaudreuil , Ned Freed
    , Keith Moore
    Subject: Test of new header generator
    MIME-Version: 1.0
    Content-type: text/plain; charset=ISO-8859-1

    Правила несколько отличаются для полей, определенных как '*text' так как "(" и ")" не распознаются в качестве разделителей комментария. [Секция 5, параграф (1)].

    В каждом из следующих примеров, если бы одна и та же последовательность встретилась в поле '*text', форма "Отображается как" не рассматривалась бы как кодировочные слова, а была бы идентична форме "Кодированное представление". Это происходит, потому что каждое из 'кодировочных слов' в ниже приведенных примерах соседствуют с символами "(" или ")".

    Кодированное представление

    Отображается как

    (=?ISO-8859-1?Q?a?=)

    (a)

    (=?ISO-8859-1?Q?a?= b)

    (a b)

    В пределах 'комментария', HT или SP должны появляться между 'кодировочным словом' и окружающим текстом. [Секция 5, параграф (2)]. Однако HT или SP не нужны между начальным символом "(", который открывает 'комментарий', и 'кодировочным словом'.

    (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)

    (ab)

    HT или SP между смежными 'кодировочными словами' не отображаются.

    (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)

    (ab)

    Даже кратные пробелы между 'кодировочными словами' игнорируются.

    (=?ISO-8859-1?Q?a?=
    =?ISO-8859-1?Q?b?=)

    (ab)

    Любое число LWS между 'кодировочными словами', даже если там содержится CRLF, за которым следует один или более пробелов, игнорируется.

    (=?ISO-8859-1?Q?a_b?=)

    (a b)

    Для того чтобы пробел был отображен в пределах кодированного текста, SP должен быть закодирован в качестве части 'кодировочного слова'.

    (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)

    (a b)

    Для того чтобы пробел был отображен между двумя строками кодированного текста, SP может быть закодирован как составная часть одного из 'кодировочных слов'.

    9. Ссылки

    [RFC-822]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982.

    [RFC-2049]

    Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

    [RFC-2045]

    Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996.

    [RFC-2046]

    Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

    [RFC-2048]

    Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.

    IV. Процедуры регистрации

    1. Введение

    Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.

    Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем.

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

    2. Регистрация типа среды

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

    2.1. Деревья регистрации и имена субтипов

    Для того чтобы увеличить эффективность и гибкость процесса регистрации различные структуры субтипов имен могут быть зарегистрированы так, чтобы удовлетворить различным естественным требованиям, например, субтип, который будет рекомендованa для широкого использования сообществом Интернет или субтип, который используется для переноса файлов, ассоциированных с некоторой частной программой. Последующие субсекции данного документа определяют регистрационные "деревья", отличающиеся использованием стандартной формы имен (например, имен вида "tree.subtree...type"). Заметим, что некоторые типы среды определены до появления данного документа и их имена не согласуются с данной схемой. Смотри приложение A, где рассматривается эта проблема.

    2.1.1. IETF-дерево

    Дерево IETF служит для типов, представляющих общий интерес для сообщества Интернет. Регистрация в IETF требует одобрения IESG и публикации данного типа среды в каком-то документе RFC.

    Типы среды в IETF-дереве обычно обозначаются именами, которые не оформлены стандартным образом, т.е., не содержат символов точка (".", полный останов).

    "Хозяином" регистрации типа среды в рамках дерева IETF предполагается сама группа IETF. Модификации или изменения спецификации требуют той же процедуры, что и регистрация.

    2.1.2. Дерево производителя (Vendor Tree)

    Дерево производителя используется для типов среды, соответствующих определенным коммерческим продуктам.

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

    Регистрация в рамках дерева производителя выделяется с помощью префикса имени "vnd.". Далее может следовать имя известного производителя (например, "vnd.lapot"), адрес производителя или место расположения программы, заключительная секция имени может содержать наименование типа среды (например, vnd.bigcompany.funnypictures).

    2.1.3. Частное дерево

    Регистрация типов среды, созданных с экспериментальными целями, могут быть зарегистрированы в рамках частного дерева. Регистрация такого вида имеет префикс имени "prs.". Хозяином "частной" регистрации и соответствующих спецификаций является человек или объект, осуществивший регистрацию. Публикация частных типов среды не требуется.

    2.1.4. Специальное `x.'-дерево

    Для удобства и симметрии со схемой регистрации имена типов среды, начинающиеся с "x." могут использоваться для тех же целей, что и имена, начинающиеся с "x-". Эти типы не являются зарегистрированными и могут использоваться партнерами при взаимном согласии.

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

    2.1.5. Дополнительные регистрационные деревья

    От случая к случаю как этого требует сообщество, IANA может по согласованию с IESG, создать новое регистрационное дерево верхнего уровня. Предполагается, что такие деревья могут быть созданы для внешней регистрации и управления, например научными сообществами для их внутреннего использования. Вообще, качество рассмотрения спецификаций для этих деревьев регистрации должно быть столь же тщательным, как и в случае IETF. О создании этих новых деревьев уведомляет публикация RFC, одобренная IESG.

    2.2. Требования регистрации

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

    2.2.1. Требования функциональности

    Типы среды должны функционировать как настоящий формат среды. Регистрация вещей, которые относятся в большей мере к транспортному кодированию, выбору символьного набора не допускается. Например, хотя существуют приложения, которые осуществляют транспортное декодирование base64 [RFC-2045], base64 не может быть зарегистрировано в качестве типа среды. Это требование не зависит от используемого регистрационного дерева.

    2.2.2. Требования к именам

    Всем зарегистрированным типам среды должны быть присвоены имена типов и субтипов MIME. Комбинация этих имен служит в дальнейшем для идентификации типа среды и формата субтипа.

    При выборе имени типа верхнего уровня должна учитываться природа типа среды. Например, среда, используемая для представления статической картинки должна быть субтипом типа изображение, в то время как среда, способная представлять звуковую информацию должна принадлежать аудио типу. Для получения дополнительной информации смотри RFC-2046.

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

    В некоторых случаях новый субтип среды может не вполне согласовываться с определенным на текущий момент типом содержимого верхнего уровня. Если такое произошло, следует определить новый тип верхнего уровня, который бы согласовывался с данным субтипом. Такое определение должно быть выполнено согласно стандартной процедуре и опубликовано в RFC. Это требование не зависит от используемого регистрационного дерева.

    2.2.3. Требования к параметрам

    Типы среды могут использовать один или более параметров MIME, некоторые параметры могут оказаться автоматически доступными для типа среды в случае, когда они применимы ко всему семейству субтипов. В любом случае имена, величины и назначение любого параметра должны быть полностью специфицированы при регистрации типа среды в рамках дерева IETF. Они должны быть специфицированы как можно полнее, когда тип среды регистрируется в рамках частного дерева или дерева производителя.

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

    2.2.4. Требования к канонизации и формату

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

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

    Некоторые типы среды включают в себя патентованные технологии. Регистрация типа среды, включающего в себя патентованные технологии, также разрешена. Однако устанавливаются ограничения (RFC-1602) на применение патентованных технологий в рамках стандартных протоколов.

    2.2.5. Рекомендации по взаимозаменяемости

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

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

    2.2.6. Требования к безопасности

    Рассмотрение аспектов безопасности необходимо для всех типов, регистрируемых в рамках IETF-дерева. Аналогичный анализ для типов среды регистрируемых в рамках частного дерева или дерева производителя рекомендуется, но не является обязательным. Однако вне зависимости от того что анализ безопасности мог проводиться или нет, все описания соображений по безопасности должны быть выполнены крайне аккуратно вне зависимости от дерева регистрации. В частности, заявление, что "никакие соображения безопасности не сопряжены с этим типом" не следует путать с "безопасность сопряженная с данным типом не анализировалась и не оценивалась".

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

    Секция безопасности подлежит дальнейшему развитию. Некоторые аспекты, которые следует учитывать при анализе безопасности типа среды, перечислены ниже.

    (1)

    Комплексные типы среды могут включать в себя директивы, которые определяют действия над файлами или другими ресурсами получателя. Во многих случаях для отправителя перечисляются действия, которые могут вызвать разрушительные последствия. Смотри регистрацию типа среды application/postscript в RFC-2046 в качестве примера таких директив.

    (2)

    Сложные типы среды могут включать директивы, определяющие действия, которые сами по себе безвредны для получателя, но могут вызвать раскрытие конфиденциальных данных или упростить последующие атаки или нарушить конфиденциальность для получателя каким-либо способом. Регистрация типа среды application/postscript иллюстрирует, как следует обрабатывать такие директивы.

    (3)

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

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

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

    2.2.7. Требования к публикации

    Предложения для типов среды регистрируемых в рамках IETF-дерева должны публиковаться в виде RFC. RFC-публикации типа среды производителя или частного типа среды желательны, но не обязательны. Во всех случаях IANA сохраняет копии всех предложений по типам среды и публикует их как часть самого регистрационного дерева типов среды.

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

    Как было обсуждено выше, регистрация типа среды верхнего уровня предполагает стандартную процедуру принятия и, следовательно, обязательную RFC-публикацию.

    2.2.8. Дополнительная информация

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

    (1)

    Магические числа (длина, значения октетов). Магические числа представляют собой байтовые последовательности, которые всегда имеются и по этой причине могут использоваться для идентификации объектов, принадлежащих данному типу среды.

    (2)

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

    (3)

    Код типа файла Macintosh (4 октета) используется для маркировки файлов, содержащих данный тип среды.

    Такая информация часто оказывается весьма полезной и, если имеется, то должна предоставляться.

    2.3. Процедура регистрации

    Следующая процедура была применена IANA для обзора и одобрения новых типов среды. Для регистрации в рамках дерева IETF, нужно следовать обычной процедуре, осуществляя на первом этапе рассылку интернет-проекта. Для регистрации в рамках частного дерева или дерева производителя осуществляется без широкого обсуждения. Проект непосредственно направляется IANA (по адресу iana@iana.org).

    2.3.1. Представление типа среды на суд сообщества

    Все начинается с посылки предложения регистрации типа среды лист-серверу ietf-types@iana.org . Отклики ожидаются в течение двух недель. Этот подписной лист был учрежден для целей обсуждения предлагаемых типов среды и доступа. Предложенные типы среды, если они формально не зарегистрированы, не могут быть использованы; префикс "x-", специфицированный в RFC-2045, может применяться до тех пор, пока процесс регистрации не завершится.

    Типы среды, регистрируемые в рамках дерева IETF должны представляться на одобрение IESG.

    Получив подтверждение, что тип среды отвечает всем требованиям, автор может послать запрос регистрации IANA, которая зарегистрирует тип среды и сделает его доступным для всего сообщества.

    2.4. Комментарии по поводу регистрации типа среды

    Комментарии по поводу регистрации типа среды могут быть направлены членам сообщества IANA. Эти комментарии будут переданы "хозяину" типа среды. Комментаторы могут потребовать, чтобы их замечания были присовокуплены к материалам регистрации данного типа среды и, если IANA одобрит это, такая процедура будет произведена.

    2.5. Расположение списка зарегистрированных типов среды

    Материалы регистрации типа среды доступны через анонимный FTP сервер ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ , а все зарегистрированные типы среды будут перечислены в периодически обновляемом документе "Assigned Numbers" RFC [в настоящее время STD-2, RFC-1700]. Описания типа среды и другие материалы могут быть также опубликованы в виде информационных RFC путем посылки документа по адресу "rfc-editor@isi.edu" [RFC-1543].

    2.6. Процедура регистрации типа среды в IANA

    IANA регистрирует типы среды, принадлежащие дереву IETF. Частные типы и типы среды производителя регистрируются IANA автоматически и без формального обсуждения, если выполнены следующие условия:

    (1)

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

    (2)

    Все типы среды должны иметь корректно сформированные имена типа и субтипов. Все имена типов должны быть определены стандартным образом. Все имена субтипов должны быть уникальными, должны соответствовать грамматике MIME и содержать корректный префикс дерева.

    (3)

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

    (4)

    Любые соображения по безопасности должны отражать объективную ситуацию и быть корректными. IANA не проводит экспертизу, но откровенно некомпетентные материалы отбрасываются.

    2.7. Управление изменением

    Раз тип среды опубликован IANA, автор может потребовать изменения его описания. Запрос изменения оформляется также как и сама регистрация:

    (1)

    Рассылка пересмотренной заявки регистрации через подписной лист ietftypes.

    (2)

    Ожидание в течение двух недель комментариев.

    (3)

    Публикация после формального обсуждения IANA, если это необходимо.

    Изменения следует делать лишь при обнаружении серьезных упущений или ошибок в опубликованной спецификации.

    Владелец типа содержимого может передать ответственность за него другому лицу или организации, проинформировав об этом IANA и список рассылки ietf-типов. Это может быть сделано без обсуждения.

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

    Регистрации типа среды не могут быть аннулированы. Типы среды, которые не используются более, объявляются устаревшими (OBSOLETE) путем изменения их поля "intended use" (область применения). Такие типы среды будет помечены соответствующим образом и в списках, публикуемых IANA.

    2.8. Регистрационный шаблон

    To: ietf-types@iana.org
    Subject: Registration of MIME media type XXX/YYY(Регистрация типа среды MIME)

    MIME media type name:

    (Имя типа среды MIME)

    MIME subtype name:

    (Имя субтипа среды MIME)

    Required parameters:

    (Необходимые параметры)

    Optional parameters:

    (Опционные параметры)

    Encoding considerations:

    (Соображения по кодированию)

    Security considerations:

    (Соображения безопасности)

    Interoperability considerations:

    (Соображения совместимости)

    Published specification:

    (Опубликованная спецификация)

    Applications which use this media type:

    (Приложения, использующие данный тип среды)

    Additional information:

    (Дополнительная информация)

    Magic number(s):

    (Магические числа)

    File extension(s):

    (Расширение имени файла)

    Macintosh File Type Code(s):

    (Код типа файла Macintosh)

    Person & email address to contact
    for further information:

    (Контактный адрес)

    Intended usage:
    (Одно из COMMON, LIMITED USE
    или OBSOLETE)

    (Возможное применение)

    Author/Change controller:

    (Автор/ответственный)
    Сюда может быть добавлена любая другая информация на усмотрение автора.

    3. Типы доступа к внешнему телу

    RFC-2046 определяет тип среды message/external-body, в рамках которой объект MIME может действовать, как указатель на реальное информационное тело сообщения. Каждый указатель message/external-body специфицирует тип доступа, который определяет механизм получения реального тела сообщения. RFC-2046 определяет исходный набор типов доступа, но допустимо описание нового механизма доступа в процессе регистрации нового типа среды.

    3.1. Требования к регистрации

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

    Каждый тип доступа должен иметь уникальное имя. Это имя появляется в параметре типа доступа в поле заголовка типа содержимого message/external-body, и должно соответствовать синтаксису параметров MIME.

    Все протоколы транспортные средства и процедуры, используемые данным типом доступа, должны быть описаны в самой спецификации типа доступа или в какой-то другой общедоступной спецификации, достаточно подробно, чтобы этим мог воспользоваться квалифицированный программист. Использование секретных и/или частных методов доступа категорически запрещено. Ограничения, введенные документом RFC-1602 на стандартизацию патентованных алгоритмов, также должны быть учтены.

    Все типы доступа должны быть описаны в RFC. RFC может быть информационным, а не обязательно описанием стандарта.

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

    3.2. Процедура регистрации

    Регистрация нового типа доступа начинается с создания проекта RFC. Далее осуществляется рассылка проекта через список подписки ietf-types@iana.org . Для получения откликов выделяется две недели. Этот подписной лист создан для целей обсуждения предлагаемых типов среды и доступа. Предлагаемые типы доступа не должны применяться до момента формальной регистрации.

    Когда двухнедельный период истечет, ответственное лицо, назначенное региональным директором IETF, переадресует запрос iana@isi.edu, или отклоняет его из-за существенных возражений, высказанных в процессе обсуждения.

    Решения принятые ответственным лицом IETF рассылаются всем через подписной лист IETF-types всем заинтересованным лицам в пределах двух недель. Это решение может быть обжаловано в IESG.

    Утвержденная спецификация типа доступа должна быть опубликована в качестве документа RFC. Информационные RFC публикуются путем посылки их по адресу "rfc-editor@isi.edu".

    3.3. Расположение списка зарегистрированных типов доступа

    Зарегистрированные спецификации типа доступа доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/ . Все зарегистрированные типы доступа включаются в перечень типов доступа, периодически публикуемый в документе "Assigned Numbers" RFC-1700.

    4. Транспортное кодирование

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

    (1)

    Многие виды транспорта, особенно пересылка сообщений, могут обрабатывать только данные, состоящие из относительно коротких строк текста. Существуют также строгие ограничения на то, какие символы могут использоваться в этих строках текста. Некоторые виды транспортировки допускают использование только субнабора US-ASCII, а другие не могут работать с некоторыми символьными последовательностями. Транспортное кодирование используется, для того чтобы преобразовать двоичные данные в текстовую форму. Примеры такого сорта транспортного кодирования включают применение base64 и закавыченных строк печатных символов, определенных в RFC-2045.

    (2)

    Изображение, аудио, видео и даже объекты приложений имеют иногда овольно большой размер. Алгоритмы сжатия часто весьма эффективны для сокращения объектов большого размера. Транспортное кодирование может использоваться также, для того чтобы с помощью универсальных алгоритмов сжатия без потерь сократить размер MIME-объектов.

    (3)

    Транспортное кодирование может быть определено, как средства представления существующих форматов кодирования в контексте MIME.

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

    4.1. Требования к транспортному кодированию

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

    Каждый тип транспортного кодирования должен иметь уникальное имя. Это имя записывается в поле заголовка Content-Transfer-Encoding и должно согласовываться с его синтаксисом.

    Все алгоритмы, используемые при транспортном кодировании (напр. преобразование к печатному виду или сжатие) должны быть описаны в спецификациях транспортного кодирования. Использование секретных алгоритмов транспортного кодирования категорически запрещено. Ограничения, накладываемые документом RFC-1602 на стандартизацию патентованных алгоритмов должно непременно учитываться.

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

    Не существует требования, чтобы транспортное кодирование приводило к определенному выходному формату. Однако выходной формат каждого транспортного кодирования должен быть исчерпывающе документирован. В частности, каждая спецификация должна ясно объявить, являются ли выходные данные 7-битовыми, 8-битовыми или просто двоичными.

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

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

    4.2. Процедура определения транспортного кодирования

    Определение нового вида транспортного кодирования начинается с создания проекта стандартного документа RFC. RFC должен определить транспортное кодирование точно и исчерпывающе и предоставить необходимое обоснование введения этого вида кодирования. Эта спецификация должна быть представлена на рассмотрение IESG. IESG может

    (1)

    отклонить спецификацию, как неприемлемую для стандартизации,

    (2)

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

    (3)

    принять спецификацию, так как она есть, и поместить ее в перечень стандартов.

    4.3. Процедуры IANA для регистрации транспортного кодирования

    Не существует необходимости для специальной процедуры регистрации транспортного кодирования IANA. Все стандартные транспортные виды кодирования должны быть оформлены в виде RFC, таким образом, ответственность по информированию IANA об одобрении нового вида транспортного кодирования лежит на IESG.

    4.4. Размещение списка зарегистрированных видов транспортного кодирования

    Регистрационные материалы по всем стандартизованным видам транспортного кодирования доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/ . Все зарегистрированные типы транспортного кодирования обязательно заносятся в списки документа "Assigned Numbers" [RFC-1700].

    V. Критерии совместимости и примеры

    Далее рассмотрено, какие части MIME должны поддерживаться MIME-совместимой программной реализацией.

    1. Совместимость с MIME

    Механизмы, описанные в данном разделе являются открытыми для дальнейшего расширения. Не предполагается, что все реализации будут поддерживать все существующие типы среды. Для того чтобы обеспечить наибольшую область применимости полезно определить концепцию "MIME-совместимости", которая позволит обмениваться сообщениями, содержащими данные в формате, отличном от US-ASCII.

    Почтовый агент пользователя, совместимый с MIME должен:

    (1)

    Всегда генерировать поле заголовка "MIME-Version: 1.0" в любом формируемом сообщении.

    (2)

    Распознавать поле заголовка Content-Transfer-Encoding и декодировать все получаемые данные, кодированные в формате закавыченных последовательностей печатных символов или в base64. Должна идентифицироваться также форма преобразования (7-бит, 8-бит или двоичная).
    Любые не 7-битовые данные, посланные без кодирования, должны быть соответствующим образом помечены в поле content-transfer-encoding как 8-битовые или двоичные в зависимости от реального формата. Если транспортная система не поддерживает 8-битовый или двоичный формат (как, например, SMTP [RFC-821]), отправитель должен выполнить кодирование и пометить данные, как закодированные в формате base64 или закавыченных последовательностей печатных символов.

    (3)

    Должен обрабатывать любые нераспознанные транспортные кодирования как тип содержимого "application/octet-stream", вне зависимости от того, распознан или нет действительный тип содержимого.

    (4)

    Распознавать и интерпретировать поле заголовка Content-Type, и избегать отображения исходных данных со значением поля Content-Type, отличным от text. Реализации должны быть способны посылать, по крайней мере, сообщения text/plain, с символьным набором, специфицированным с помощью параметра charset, если это не US-ASCII.

    (5)

    Игнорировать любые параметры типа содержимого с не распознанными именами.

    (6)

    Работать с ниже приведенными значениями типов среды.

    Текст:

    -

    Распознавать и отображать "текст" почтового сообщения с символьным набором "US-ASCII."

    -

    Распознавать другие символьные наборы, по крайней мере, на таком уровне, чтобы информировать пользователя о том, какой символьный набор использован.

    -

    Распознавать символьные наборы "ISO-8859-*" на таком уровне, чтобы быть способным отобразить те символы, которые являются общими для ISO-8859-* и US-ASCII, то есть все символы с кодами в диапазоне 1-127.

    -

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

    -

    Обрабатывать материал с неизвестным символьным набором так, как если бы это был "application/octet-stream".

    Изображение, аудио и видео:

    -

    На минимальном уровне предоставить возможность обрабатывать любой не узнанный субтип, как если бы он был "application/octet-stream".

    Применение:

    -

    Предложить возможность удаления кодирования base64 или закавыченных последовательностей печатных символов, определенных в данном документе, если они были применены, и положить результат в файл пользователя.

    Составное сообщение:

    -

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

    -

    Распознается cубтип "alternative", и исключается отображение лишних частей сообщения multipart/alternative.

    -

    Распознается субтип "multipart/digest", используя формат "message/RFC-822" а не "text/plain" в качестве типа среды по умолчанию для частей тела внутри объектов "multipart/digest".

    -

    Любые не узнанные субтипы обрабатываются, как если бы они были типа "mixed".

    Сообщение:

    -

    Распознаются и отображаются, по крайней мере, инкапсулированные данные сообщения RFC-822 (message/RFC-822) таким образом, чтобы сохранить любую рекурсивную структуру, то есть, отображая или предлагая отобразить инкапсулированные данные с учетом типа среды.

    -

    Любые не распознанные субтипы обрабатывается как если бы они имели тип "application/octet-stream".

    (7)

    При встрече нераспознанного поля Content-Type, программная реализация должна воспринимать ее как если бы она имела тип "application/octet-stream" без каких либо параметров субаргументов. Как обрабатывать эти данные зависит исключительно от конкретной реализации, но желательны опции, предлагающие пользователю после декодирования транспортного формата записать данные в файл или предложить пользователю ввести имя файла, который преобразует содержимое в приемлемый формат.

    (8)

    Нужны адаптирующиеся агенты пользователя, если они предоставляют нестандартную поддержку для сообщений, не следующих протоколу MIME, и использующих символьный набор отличный от US-ASCII. Адаптирующиеся агенты пользователя не должны посылать сообщения, которые не следуют протоколу MIME и в то же время содержат текст отличный от US-ASCII.
    В частности, использование текста не US-ASCII в почтовом сообщении без поля MIME-Version категорически не рекомендуется, так как это уменьшает коммуникационные возможности. Адаптирующиеся агенты пользователя должны содержать корректные метки MIME при посылке чего-либо отличного от чистого текста с символьным набором US-ASCII.
    Кроме того, агенты пользователя, не поддерживающие MIME, должны модифицироваться, если это возможно, чтобы включить соответствующую информацию заголовка MIME в отправляемое сообщение, даже если ничего более из протокола MIME не поддерживается. Эта модификация произведет малое, если вообще какое-либо влияние на получателей, не поддерживающих MIME, но поможет MIME корректно отобразить текст сообщения.

    (9)

    Адаптирующиеся агенты пользователя должны гарантировать, что любая строка печатных US-ASCII-символов (без WS) в пределах "*text" или "*ctext", которая начинается с "=?" и завершается "?=", является корректным кодировочным словом. Слово "начинается" здесь означает - в начале поля тела или сразу после LWS, а "завершается" означает - в конце поля-тела или сразу перед LWS. Кроме того любое "слово" в пределах "фразы", которое начинается с "=?" и завершается "?=", должно быть корректным кодировочным словом.

    (10)

    Адаптирующиеся агенты пользователя должны быть способны отделит кодировочные слова от "text", "ctext" или "word", в соответствии с правилами секции 4, где бы они не встретились в заголовках сообщения. Они должны поддерживать как "B"- так и "Q"-кодирование для любого поддерживаемого символьного набора. Программа должна быть способна отобразить не кодированный текст, если символьным набором является "US-ASCII". Для символьных наборов ISO-8859-*, программа, читающая почтовые сообщения должна быть способна, по крайней мере, отобразить символы, которые входят также и в набор US-ASCII. Агент пользователя, который отвечает данным условиям, считается адаптированным к MIME.

    Есть и другое соображение, почему всегда безопасно посылать данные в формате, согласованным с MIME, ведь такая форма не вступит в конфликт с промежуточными почтовыми серверами, работающими в соответствие со стандартами RFC-821 и RFC-822. Агенты пользователя, которые адаптированы к MIME имеют дополнительную гарантию, что пользователю не будет представлена информация, не воспринимаемая как текст.

    2. Базовые моменты при посылке почтовых сообщений

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

    В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.

    1)

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

    2)

    Многие системы могут выбрать для хранения и представления текста другое локальное соглашение для обозначения начала новой строки. Это локальное соглашение может не согласовываться с RFC-822, где для этого используется CRLF. Известны системы, где для этой цели применяют один символ CR, один LF, CRLF, или нечто совсем другое. В результате получается, что изолированные CR и LF символы не вполне надежны; они могут быть потеряны или преобразованы некоторыми системами в другие разделители, следовательно, на них нельзя положиться.

    3)

    Передача нулей (US-ASCII значение 0) проблематична в Интернет-почте. Это по большей части результат введения нулей, используемых в качестве завершающего символа во многих стандартных программных библиотеках реального времени в языке Си. Практика использования нулей в качестве завершающего символа настолько распространена, что нельзя рассчитывать на то, что эти нули будут сохранены в сообщении.

    4)

    TAB (HT) символы могут быть неверно интерпретированы или автоматически преобразованы в переменное число пробелов. Это неизбежно в некоторых условиях, в особенности тех, которые базируются на символьном наборе US-ASCII. Такое преобразование не рекомендуется, но может случиться и форматы почты не должны полагаться на сохранение символов TAB (HT).

    5)

    Строки длиннее 76 символов могут быть разорваны или укорочены некоторыми почтовыми агентами. Разрыв строк или укорочение при транспортировке почты не рекомендуется, но избежать этого иногда невозможно. Приложения, которые требуют длинных строк, должны каким то образом делать различие между "мягким" и "жестким" разрывом строки. Простым способом решить эту проблему является применение кодирования с помощью закавыченных строк печатных символов.

    6)

    Завершающие символы строки (SP и HT) могут быть отброшены некоторыми транспортными агентами, в то время как другие могут дополнить строки этими символами так, что все строки почтового файла обретают равную длину. На присутствие завершающих символов SP или HT рассчитывать не приходится.

    7)

    Многие почтовые домены используют вариации символьного набора US-ASCII, или работают с символьными наборами типа EBCDIC, который содержит большинство но не все символы из US-ASCII. Корректная трансляция символов в не инвариантный набор не может быть зависимой от конвертирующих шлюзов по дороге. Например, возникает проблема при пересылке информации, обработанной программой uuencodE, через сеть BITNET. Аналогичные проблемы могут возникнуть без прохода через шлюз, так как многие ЭВМ в Интернет используют символьный набор отличный от US-ASCII. Определение печатной строки в X.400 добавляет новые ограничения в некоторых специфических случаях. В частности, символами, которые могут быть пропущены через любые шлюзы, считаются 73 символа. В их число входят прописные и строчные буквы A-Z и a-z, 10 цифр - 0-9 и следующие одиннадцать специальных символов.

    "'" (US-ASCII десятичное значение 39)
    "(" (US-ASCII десятичное значение 40)
    ")" (US-ASCII десятичное значение 41)
    "+" (US-ASCII десятичное значение 43)
    "," (US-ASCII десятичное значение 44)
    "-" (US-ASCII десятичное значение 45)
    "." (US-ASCII десятичное значение 46)
    "/" (US-ASCII десятичное значение 47)
    ":" (US-ASCII десятичное значение 58)
    "=" (US-ASCII десятичное значение 61)
    "?" (US-ASCII десятичное значение 63)

    Максимально переносимое почтовое сообщение имеет короткие строки, содержащие только эти 73 с имвола. Кодирование base64 отвечает этому правилу.

    (8)

    Некоторые почтовые транспортные агенты искажают данные, которые содержат определенные символьные строки. В частности, одиночный символ точка (".") на строке может быть поврежден в некоторых SMTP реализациях, а строки, которые начинаются с пяти символов "From " (пятым символом является пробел), также могут быть повреждены. Хорошие агенты-отправители могут предотвратить эти искажения путем кодирования данных (например, в закавыченных строках печатных символов в начале строки вместо "From " используется "=46rom " и "=2E" вместо одиночной ".").

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

    3. Каноническая модель кодирования

    Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.

    (1)

    Создание локальной формы.

    Тело, которое подлежит пересылке, формируется в локальном системном формате. При этом используется местный символьный набор и, где возможно, локальное кодирование завершения строки. Тело сообщения может быть текстовым файлом системы UNIX, или растровым изображением, или индексным файлом VMS, или аудио данными в системно зависимом формате, хранящимися в оперативной памяти, или что-то еще, что соответствует локальной модели представления информации.

    (2)

    Преобразование в каноническую форму.

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

    Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.

    (3)

    Применение транспортного кодирования.

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

    (4)

    Вставление в объект.

    Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

    (1)

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

    (2)

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

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

    Content-type: text/foo; charset=bar
    Content-Transfer-Encoding: base64

    должно быть сначала представлено в форме text/foo, затем, если необходимо, представлено в символьном наборе и, наконец, трансформировано с использованием алгоритма base64 в формат, безопасный для пересылки через любые шлюзы.

    Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.

    Приложение A. Сложный пример составного сообщения

    Данное сообщение содержит пять частей, которые должны быть отображены последовательно: - два вводных объекта чистого текста, встроенное составное сообщение, объект типа text/enriched и завершающее инкапсулированное текстовое сообщение с символьным набором не ASCII типа. Встроенное составное сообщение в свою очередь содержит два объекта, которые должны отображаться в параллель, изображение и звуковой фрагмент.

    MIME-Version: 1.0
    From: Nathaniel Borenstein
    To: Ned Freed
    Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
    Subject: A multipart example(составной пример)
    Content-Type: multipart/mixed;boundary=unique-boundary-1

    Это область преамбулы составного сообщения. Программы чтения почты, приспособленные для чтения составных сообщений, должны игнорировать эту преамбулу.

    --unique-boundary-1
    ... Здесь размещается некоторый текст ...

    [Заметим, что пробел между границей и началом текста в этой части означает, что не было никаких заголовков и данный текст представлен в символьном наборе US-ASCII.]

    --unique-boundary-1
    Content-type: text/plain; charset=US-ASCII

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

    --unique-boundary-1
    Content-Type: multipart/parallel; boundary=unique-boundary-2

    --unique-boundary-2
    Content-Type: audio/basic

    Content-Transfer-Encoding: base64
    ... здесь размещаются одноканальные аудио данные, полученные при частоте стробирования 8 кГц, представленные с использованием m-преобразования, и закодированные с привлечением base64 ...

    --unique-boundary-2
    Content-Type: image/jpeg
    Content-Transfer-Encoding: base64
    ... здесь размещается изображение, закодированное с привлечением base64 ...
    --unique-boundary-2--
    --unique-boundary-1
    Content-type: text/enriched

    This is enriched.
    как определено в RFC-1896
    Isn't it
    cool?
    -unique-boundary-1
    Content-Type: message/RFC-822
    From: (mailbox in US-ASCII)
    To: (address in US-ASCII)
    Subject: (subject in US-ASCII)
    Content-Type: Text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: Quoted-printable
    Additional text in ISO-8859-1 goes here ...
    --unique-boundary-1--

    Ссылки

    [ATK]

    Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, PrenticeHall, 1990.

    [ISO-2022]

    International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed.

    [ISO-8859]

    International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets
    - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
    - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
    - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
    - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
    - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed.
    - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
    - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
    - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
    - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed. International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets
    >- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed.

    [ISO-646]

    International Standard -- Information Technology - ISO 7-bit Coded Character Set for Information Interchange, ISO 646:1991, 3rd ed..

    [JPEG]

    JPEG Draft Standard ISO 10918-1 CD.

    [MPEG]

    Video Coding Draft Standard ISO 11172 CD, ISO IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.

    [PCM]

    CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972.

    [POSTSCRIPT]

    Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985.

    [POSTSCRIPT2]

    Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990.

    [RFC-783]

    Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981.

    [RFC-821]

    Postel, J.B., "Simple Mail Transfer Protocol", STD-10, RFC-821, USC/Information Sciences Institute, August 1982.

    [RFC-822]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982.

    [RFC-934]

    Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC-934, Delaware and NMA, January 1985.

    [RFC-959]

    Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC-959, USC/Information Sciences Institute, October 1985.

    [RFC-1049]

    Sirbu, M., "Content-Type Header Field for Internet Messages", RFC-1049, CMU, March 1988.

    [RFC-1154]

    Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC-1154, Prime Computer, Inc., April 1990.

    [RFC-1341]

    Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1341, Bellcore, Innosoft, June 1992.

    [RFC-1342]

    Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC-1342, University of Tennessee, June 1992.

    [RFC-1344]

    Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC-1344, Bellcore, June 1992.

    [RFC-1345]

    Simonsen, K., "Character Mnemonics & Character Sets", RFC-1345, Rationel Almen Planlaegning, June 1992.

    [RFC-1421]

    Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC-1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

    [RFC-1422]

    Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC-1422, IAB IRTF PSRG, IETF PEM WG, February 1993.

    [RFC-1423]

    Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.

    [RFC-1424]

    Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993.

    [RFC-1521]

    Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1521, Bellcore, Innosoft, September, 1993.

    [RFC-1522]

    Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC-1522, University of Tennessee, September 1993.

    [RFC-1524]

    Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC-1524, Bellcore, September 1993.

    [RFC-1543]

    Postel, J., "Instructions to RFC Authors", RFC-1543, USC/Information Sciences Institute, October 1993.

    [RFC-1556]

    Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC-1556, Israeli Inter-University Computer Center, December 1993.

    [RFC-1590]

    Postel, J., "Media Type Registration Procedure", RFC-1590, USC/Information Sciences Institute, March 1994.

    [RFC-1602]

    Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", March 1994.

    [RFC-1652]

    Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC-1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, March 1994.

    [RFC-1700]

    Reynolds, J. and J. Postel, "Assigned Numbers", STD-2, RFC-1700, USC/Information Sciences Institute, October 1994.

    [RFC-1741]

    Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December 1994.

    [RFC-1896]

    Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC-1896, February, 1996.

    [RFC-2045]

    Freed, N., and and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, Innosoft, First Virtual Holdings, November 1996.

    [RFC-2046]

    Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, Innosoft, First Virtual Holdings, November 1996.

    [RFC-2047]

    Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC-2047, University of Tennessee, November 1996.

    [RFC-2048]

    Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC-2048, Innosoft, MCI, ISI, November 1996.

    [RFC-2049]

    Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC-2049 (this document), Innosoft, First Virtual Holdings, November 1996.

    [US-ASCII]

    Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.

    [X400]

    Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.

    Previous: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.14.5 Программа Sendmail


    previous up down next index index
    Previous: 4.4.16 Протокол SNTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

    4.4.17 Введение в MPLS, TE и QoS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1. Базовые предпосылки

    Интернет - это система взаимодействия удаленных программ. Совместимость этих программ гарантируется тем, что они следуют определенным регламентациям (протоколам). Управление трафиком представляет собой проблему, ставшую актуальной за последние несколько лет (если не считать составляющую, сопряженную с управлением перегрузкой).

    Период экстенсивного развития сети Интернет завершился несколько лет тому назад даже в РФ. Сейчас многие сервис-провайдеры пытаются привлечь клиентов дополнительными информационными услугами IP-телефония, интерактивные игры, доступ к разнообразным базам данных и депозитариям, электронным магазинам, видеоконференции, видео-телефония и т. д. Клиенты же ищут не просто доступа к Интернет, а интересуются полосой пропускания, безопасностью, стабильностью связи. Именно с этим сопряжен бум разработок основополагающих документов (RFC) в последние 5 лет. По этой причине многие компании, в первую очередь производящие сетевое оборудование, уделяют повышенное внимание средствам управления трафиком (ТЕ) и QoS.

    Если рассмотреть ситуацию на уровне L2, здесь имеется сильная зависимость от физического уровня (L1). В сетях с маркерным доступом (Token Ring или FDDI, см. book.itep.ru) существуют механизмы управления приоритетом и способы контроля доступа, гарантирующие определенное значение задержек сетевого отклика. В сетях ISDN и в особенности в ATM предусмотрен целый арсенал средств управления, работающих на фазе установления виртуального канала (процедура SETUP). Для Ethernet до последнего времени ситуация была много хуже. Здесь только некоторые переключатели поддерживают VLAN. Технология виртуальных сетей L2 позволяет сформировать в локальной сети соединение точка-точка. В таком соединении можно гарантировать пропускную способность на уровне 10/100Мбит/c. К сожалению VLAN L2 создаются и модифицируются, как правило администратором, но можно эту проблему перепоручить сценарию, например, на PERL, работающему с демоном SNMP сетевого прибора. В такой сети можно также гарантировать низкий уровень разброса времени реакции сети. Если сформировать VLAN с числом узлов (N) больше двух, можно гарантировать полосу лишь не ниже (10/100)/N. Для произвольной сети Ethernet никаких гарантий на уровне L2 предоставить нельзя. Здесь можно рассчитывать только на вышележащие уровни (IP/TCP/UDP).

    Принципы организации приоритетного трафика на уровне L2 рассмотрены в стандарте 802.1р. Стандарт 802.1р является частью стандарта 802.1D (мостовые соединения). В протоколе 802.1Q определена 4-байта метки (смотри рис.1). Поле EtherType=TPID (Tagged Protocol Identifier) содержит код 0x8100. Это поле соотвествует полю тип протокола стандартного поля кадра Ethernet и указывает на необходимость обработки кадра согласно требованиям IEEE 802.1Q. Смотри grouper.ieee.org/groups/802/1/pages/802.1v.html.



    Рис. 1. Формат меток VLAN на уровне L2 (стандарт 802.1р).


    Поле приоритета пользователя - 3 бита, 1-битовое поле CFI (Canonical Format Identifier) и 12-битовое поле VID (идентификатор виртуальной сети) называются TCI (Tagged Control Information). 3-битовое поле IP-приоритета размещается здесь без проблем. После введения метки в кадр нужно персчитать контрольную сумму FCS. Канальный уровень в этом случае должен поддерживать множественные очереди. Добавление метки может привести к превышению предельно допустимой длины кадра (1518 байт). В этой связи IEEE разрабатывает спецификацию 802.3ас, где максимальная длина кадра равна 1522 октета. Группа IETF, разрабатывающая систему обеспечения требуемого уровня услуг на специфических нижних уровнях ISSLL (Integrated Services over Specific Lower Layers), предлагает способы отображения запросов протокола резервирования уровня L3 (RSVP) на 802.1р с помощью системы управления полосой пропускания субсети SBM (Subnet Bandwidth Manager). Смотри http://www.ietf.org/html.charters/issll-charter.html. Протокол SBM предполагает, что одна из станций в субсети выполняет функцию DSBM (Designated SBM), и осуществляет управление доступом для всех запросов на резервирование ресурсов, посылаемых DSBM-клиентами. При работе протокола SBM используются мультикатсинг-адреса 224.0.0.17 (все станции прослушивают этот адрес), а DSBM-кандидаты прослушивают - 224.0.0.16. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP)). В этом случае UDP-порт отправителя может быть равен 2-497d, а порт получателя = 2142.

    Топология связей в локальной сети на уровне L3 определяется протоколами маршрутизации (статическими или динамическими - RIP, OSPF, IGRP). В последнее время поставщики сетевого оборудования стали предлагать устройства уровня L2, способные осуществлять отбор пакетов на уровне L3 и даже L4 (TCP/UDP). В принципе ничто не мешает создать сетевые переключатели уровня L2, способные гарантировать пропускную способность, минимизировать вероятность потери пакета и т.д.

    Любые способы управления трафиком на уровне L3 для сетей, работающих в рамках стека протоколов TCP/IP, в настоящее время базируются на возможностях этих транспортных протоколов (IP, UDP, TCP).

    Протокол (см. IP) предусматривает задание значение ToS, определяемое соответствующим полем заголовка. Одно-октетное поле тип сервиса (TOS - Type Of характеризует то, как должна обрабатываться дейтограмма.

    Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

    0 Обычный уровень
    1 Приоритетный
    2 Немедленный
    3 Срочный
    4 Экстренный
    5 CEITIC/ECP
    6 Межсетевое управление
    7 Сетевое управление

    В новейших разработках (RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) поле TOS заменено на поле DSCP (Differentiated Services Code Point), где младшие 6 бит выделены для кода DS (Differentiated Services), а старшие два бита пока не определены и их следует обнулять.

    До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 2. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).


    Рис. 2. Формат поля DSCP.

    Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.

    Селектор класса DSCP
    Приоритет 1 001000
    Приоритет 2 010000
    Приоритет 3 011000
    Приоритет 4 100000
    Приоритет 5 101000
    Приоритет 6 110000
    Приоритет 7 111000

    На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

    В маршрутизаторах компании CISCO Systems для классификации пакетов и выбора очередей используются два младших бита из трех. По умолчанию классу 0 выделяется 10% полосы, а классам 1, 2 и 3 - 20%, 30% и 40%, соответственно. Для очередей, основанных на классах QoS, пакеты, не принадлежащие ни одной группе, относятся к группе 0 и автоматически получают 1% от общей пропускной способности группы. Общий вес остальных групп не может превышать 99%. При наличии нераспределенной полосы, она относится к группе 0.

    В протоколе IPv6 поле приоритет имеет 4 бита (см. IPv6). Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. В таблице 1 приведены стандартизованные значения поля Type of Service (TOS) IP-пакета.

    Таблица .1. Значения TOS для разных протоколов (DTRC)

    Процедура

    Минимальная задержка

    Максимальная пропускная способность

    Максимальная надежность

    Минимальная стоимость

    Код TOS ( DTRC )

    FTP управление
    FTP данные

    1

    0

    0

    0

    0x10

    0

    1

    0

    0

    0x08

    TFTP

    1

    0

    0

    0

    0x10

    DNS

    UDP

    TCP

    1

    0

    0

    0

    0x10

    0

    0

    0

    0

    0x00

    0

    0

    0

    0

    0x00

    Telnet

    1

    0

    0

    0

    0x10

    ICMP

    0

    0

    0

    0

    0x00

    IGP

    0

    0

    1

    0

    0x04

    SMTP управление
    SMTP данные

    1

    0

    0

    0

    0x10

    0

    1

    0

    0

    0x08

    SNMP

    0

    0

    1

    0

    0x04

    NNTP

    0

    0

    0

    1

    0x02

    Помимо перечисленных значений может рассматриваться значение " Максимальная безопасность ". Строго говоря, значения TOS и QOS не эквивалентны, но именно значение ToS является базой для задания QoS. Присваивая при формировании IP-пакета определенное значение поля ToS, прикладная программа может попытаться реализовать определенные ограничения на QoS. Это поле может анализироваться маршрутизаторами, которые поддерживают протокол RSVP. В протоколе UDP нет никаких механизмов управления трафиком. Кое-что предлагает набор протоколов RTP/RTCP, предназначенный для мультимедийных приложений (например, позволяет ликвидировать влияние разброса времени доступа в каналах Ethernet на качество воспроизведения изображения и звука.). Некоторые приложения и сетевые приборы способны сигнализировать о перегрузке (потере пакетов из-за переполнения буферов), посылая ICMP(4).

    Протокол (смотри TCP) имеет в заголовке 6-битовое поле флаги (значения представлены в таблице 2). Значения битов флаги предоставляет дополнительные возможности управления.

    Таблица 2. Значения бит поля флаги

    Обозначение битов (слева на право) поля флаги

    Значение бита, если он равен 1

    URG

    Флаг важной информации, поле Указатель важной информации имеет смысл, если URG=1.

    ACK

    Номер октета, который должен был прийти следующим, правилен.

    PSH

    Этот сегмент требует выполнения операции push . Получатель должен передать эти данные прикладной программе как можно быстрее.

    RST

    Прерывание связи.

    SYN

    Флаг для синхронизации номеров сегментов, используется при установлении связи.

    FIN

    Отправитель закончил посылку байтов.

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

    Существенную проблему составляет необходимость идентифицировать пакеты, принадлежащие определенному процессу. Эта задача легко решается только в рамках протокола IPv6. Там в заголовке предусмотрено поле метка потока. Некоторые возможности предоставляет также протокол MPLS.


    2. Управление трафиком

    В настоящее время используется несколько методов управления трафиком:

    1.      Динамическая маршрутизация (RIP, OSPF, IGRP, BGP) и т.д.). Здесь нет средства резервирования полосы, но имеется механизм изменения маршрута при изменении значений метрики или из-за выхода из строя узла или обрыва канала. Некоторые из таких протоколов (OSPF, IGRP) могут строить отдельные таблицы маршрутизации для каждого уровня TOS/QOS [1], но метрики для каждого уровня задаются сетевым администратором. Здесь имеется возможность запараллеливания потоков с целью увеличения пропускной способности. Эти протоколы работают только в пределах одной автономной системы (AS). Протокол же BGP, используемый для прокладки путей между автономными системами не способен как-либо учитывать уровень TOS/QOS (использует алгоритм вектора расстояния, что связано с трудностью согласования значений метрик состояния канала администраторами разных AS). Новая версия многопротокольного расширения MP-BGP специально создана для совместной работы с MPLS при формировании виртуальных сетей, но и он безразличен к TOS/QOS.

    2.      Формирование виртуальных сетей на уровнях L2 и L3. Протоколы VLAN обеспечивают повышенный уровень безопасности, но не способны резервировать полосу. К этому типу относится и протокол MPLS.

    3.      Резервирование полосы в имеющемся виртуальном канале (протокол RSVP). RSVP может работать с протоколами IPv4 и IPv6. Протокол достаточно сложен для параметризации, по этой причине для решения этой задачи был разработан протокол COPS, который существенно облегчает параметризацию. Функция COPS сходна с задачей языка RPSL для маршрутизации.

    4.      Автоматическое резервирование полосы при формировании виртуального канала процедурой SETUP в сетях ATM, ISDN, DQDB, Frame Relay и т.д. Управления очередями осуществляется аппаратно, но базовые параметры могут задаваться программно. Программы управления трафиком MPLS позволяют расширяют возможности L2 сетей ATM и Frame Relay.

    5.      Использование приоритетов в рамках протокола IPv6. Возможность присвоения потокам меток облегчает, например, разделение аудио- и видеоданных.

    6.      Управление перегрузкой (окно перегрузки в TCP, ICMP(4) для UDP-потоков (ICMP L2 и т.д.).


    3. Качество обслуживания QoS

    QoS связана с возможностью сети предоставить клиенту необходимый ему уровень услуг в условиях работы поверх сетей с самыми разнообразными технологиями, включая Frame Relay, ATM, Ethernet, сети 802.1, SONET, и маршрутизуемые IP-сети.

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

    • Поддержкой определенной полосы пропускания.
    • Сокращением вероятности потери кадров.
    • Исключением или управляемостью сетевых перегрузок.
    • Возможностью конфигурирования сетевого трафика.
    • Установкой количественных характеристик трафика по пути через сеть.

    IEFT определяет для QoS следующие две архитектуры:

    • Интегрированные услуги (IntServ)
    • Дифференцированные услуги ( DiffServ )

    IntServ для явного задания уровня услуги (QoS) использует протокол RSVP. Это делается путем уведомления об этом требовании всех узлов вдоль пути обмена. Если все сетевые устройства вдоль пути могут предоставить запрошенную полосу, резервирование завершается успешно (смотри документ RFC-1633 [2]).

    DiffServ, вместо того чтобы уведомлять о требованиях приложения, использует в IP-заголовке DiffServ Code Point (DSCP), чтобы указать требуемые уровни QoS. Cisco IOS Software Release 12.1(5)T вводит совместимость маршрутизаторов Cisco c DiffServ (см. [15-16]). DSCP размещается в поле TOS IP-пакета. В таблице 3 представлены различные виды использования QoS.

    Таблица 3.

    Протокольная группа

    Протокол

    Ссылка

    QoS Signaling   Protocol_family
    QoS Policy and Shaping CAR Rate Limiting
    CAR
    http://www.cisco.com/en/US/tech/tk543/tk545/tk764/tech_protocol_home.html
    Tech_protocol
    QoS Link Efficiency Mechanisms MLPPP http://www.cisco.com/en/US/tech/tk543/tk762/tk763/tech_protocol_home.html  
    QoS Congestion Management WFQ
    VIP-Distributed WFQ
    PQ
    LLQ
    IP RTP Priority
    FIFO Queueing
    Distributed LLQ
    CBWFQ
    http://www.cisco.com/en/US/tech/tk543/tk544/tk718/tech_protocol_home.html
      http://www.cisco.com/en/US/tech/tk543/tk544/tk530/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk399/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk366/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk228/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk761/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk96/tech_protocol_home.html
    QoS Congestion Avoidance WRED
    RED
    Flow-based WRED
    D-WRED
    http://www.cisco.com/en/US/tech/tk543/tk760/tk725/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk549/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk230/tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk185/tech_protocol_home.html
    QoS Configuration and Monitoring   http://www.cisco.com/en/US/tech/tk543/tk759/tech_protocol_family_home.html  
    QoS Classification and Marking MPLS EXP bit
    Frame Relay DE bit
    DCAR
    ATM CLP bit
    http://www.cisco.com/en/US/tech/tk543/tk757/tk776/tech_protocol_home.html   http://www.cisco.com/en/US/tech/tk543/tk757/tk758/tech_protocol_home.html

     

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

    L2 QoS предполагает следующее:

    1.      Управление входными очередями: когда кадр приходит на вход порта, он может быть отнесен к одной из нескольких очередей, ассоциированных с портом, прежде чем он будет направлен на один из выходных портов. Обычно, несколько очередей используются тогда, когда различные информационные потоки требуют различных уровней услуг или минимизации задержки. Например, IP мультимедиа требует минимизации задержки, в отличие от передачи данных в FTP, WWW, email, Telnet>, и т.д.

    2.      Классификация: процесс классификации включает просмотр различных полей в заголовке Ethernet L2, а также полей IP-заголовка (уровень 3 - L3) и заголовков TCP/UDP (уровень 4 - L4), чтобы обеспечить определенный уровень услуг при коммутации пакетов.

    3.      Политика: осуществление политики является процессом анализа кадра Ethernet, чтобы определить, не будет ли превышен заданный уровень трафика за определенный интервал времени (обычно, это время является внутренним параметром переключателя). Если кадр создает ситуацию, при которой трафик превысит заданный уровень, он будет отброшен. Или значение CoS (Class of Service) может быть понижено.

    4.      Перепись: процесс переписи предоставляет возможность переключателю модифицировать CoS в заголовке или ToS (Type of Service) в IPv4-заголовке. Следует учесть, что заголовок Ethernet 802.3 поля CoS не имеет (именно эта версия стандарта наиболее распространена в РФ).

    5.      Управление выходными очередями: после процесса перезаписи переключатель поместит кадр Ethernet, в выходную очередь для последующей коммутации. Переключатель выполнит управление буфером так, чтобы не произошло переполнение. Это обычно осуществляется с помощью алгоритма RED (Random Early Discard), когда некоторые кадры случайным образом удаляются из очереди. Weighted RE (WRED) является директивой RED (используемой некоторыми модулями семейства Catalyst 6000), где значения CoS анализируются с целью определения того, какие кадры следует отбросить. Когда буферы окажутся заполнены до определенного уровня, кадры с низким уровнем приоритета отбрасываются, в очереди сохраняются только высокоприоритетные кадры.


    4. Мультипротокольная коммутация меток (протокол MPLS)

    Основы протокола MPLS описаны в официальных документах RFC [3-9 и 14]. Существуют публикации и на русском языке [11-13]. Имеются три монографии, посвященных рассматриваемой проблематике [17-19].

    Протокол MPLS хорошо приспособлен для формирования виртуальных сетей (VPN) повышенного быстродействия (метки коммутируются быстрее, чем маршрутизируются пакеты). Принципиальной основой MPLS являются IP-туннели. Для его работы нужна поддержка протокола маршрутизации MP-BGP (RFC-2858 [23]). Протокол MPLS может работать практически для любого маршрутизируемого транспортного протокола (не только IP). После того как сеть сконфигурирована (для этого используются специальные, поставляемые производителем скрипты), сеть существует, даже если в данный момент через нее не осуществляется ни одна сессия. При появлении пакета в виртуальной сети ему присваивается метка, которая не позволяет ему покинуть пределы данной виртуальной сети. Никаких других ограничений протокол MPLS не накладывает. Протокол MPLS предоставляет возможность обеспечения значения QoS, гарантирующего более высокую безопасность. Не следует переоценивать уровня безопасности, гарантируемого MPLS, атаки типа "человек посередине" могут быть достаточно разрушительны. При этом для одного и того же набора узлов можно сформировать несколько разных виртуальных сетей (используя разные метки), например, для разных видов QoS. Но можно использовать возможности АТМ (процедура setup), если именно этот протокол применен в опорной сети (возможные перегрузки коммутаторов не в счет).

    Для обеспечения структурирования потоков в пакете создается стек меток, каждая из которых имеет свою зону действия. Формат стека меток представлен на рис. 3 (смотри RFC-3032). В норме стек меток размещается между заголовками сетевого и канального уровней (соответственно L2 и L 3). Каждая запись в стеке занимает 4 октета.

    Рис. 3. Формат стека меток

    Место заголовка МАС может занимать заголовок РРР. В случае работы с сетями АТМ метка может занимать поля VPI и VCI. Смотри рис 4. Глубина стека в данном случае не может превышать 1.

    Рис. 4. Формат меток в ячейках АТМ

    На рисунке полю СoS соответствует субполю приоритет поля ToS. Поле CoS имеет три бита, что достаточно для поля приоритета IP-заголовка. 6-битовое поле кода дифференцированной услуги DSCP сюда записать нельзя. Можно попробовать разместить этот код в поле самой метки. S - флаг-указатель дна стека меток; TTL - время жизни пакета MPLS.

    Существующие версии программного обеспечения Cisco IOS (например, Cisco IOS Release 12.0) содержат набор средств управления трафиком. В частности, имеется возможность формировать статические маршруты и управлять динамическими маршрутами путем манипулирования значениями метрики . Иногда этого вполне достаточно, но в большинстве случаев провайдер нуждается в более эффективных средствах.

    Межрегиональные каналы являются одной из основных расходных статей провайдеров. Управление трафиком позволяет IP-провайдеру предложить оптимальный уровень услуг своим клиентам с точки зрения полосы и задержки. Одновременно эта технология снижает издержки обслуживания сети.

    MPLS представляет собой интеграцию технологий уровней L2 и L3. Управление трафиком в MPLS реализуется путем предоставления традиционных средств уровня L2 уровню L3. Таким образом, можно предложить в односвязной сети то, что достижимо только путем наложения уровня L3 на уровень L2.

    Управление коммутацией по меткам основывается на базе данных LIB (Label Information Base). Пограничный маршрутизатор MPLS LER (Label Edge Router) удаляет метки из пакетов, когда пакет покидает облако MPLS, у вводит их во входящие пакеты. Схема работы с помеченными и обычными IP-пакетами показана на рис. 5.

    Рис. 5. Обработка помеченных и обычных IP-пакетов

    Управление трафиком MPLS автоматически устанавливает и поддерживает туннель через опорную сеть, используя возможности RSVP. Путь, используемый данным туннелем в любой момент времени определяется на основе ресурсных требований и сетевых возможностей, таких как полоса пропускания. В самом ближайшем будущем MPLS сможет решать проблему обеспечения требуемого уровня QoS и самостоятельно.

    Информация об имеющихся ресурсах доводится до сведения заинтересованных субъектов с помощью протокола IPG (Interior Protocol Gateway), алгоритм которого базируется на состоянии канала.

    Путь туннеля вычисляется, основываясь на сформулированных требованиях и имеющихся ресурсах (constraint-based routing). IGP автоматически маршрутизирует трафик через эти туннели. Обычно, пакет, проходящий через опорную сеть MPLS движется по одному туннелю от его входной точки к выходной.

    Управление трафиком MPLS основано на следующих механизмах IOS:

    • Туннелях LSP (Label-switched path), которые формируются посредством RSVP, c расширениями системы управления трафиком. Туннели LSP представляют собой туннельные двунаправленные интерфейсы IOS c известным местом назначения.
    • Протоколах маршрутизации IGP, базирующиеся на состоянии канала (такие как IS-IS) с расширениями для глобальной рассылки ресурсной информации, и расширениях для автоматической маршрутизации трафика по LSP туннелям.
    • Модуле вычисления пути MPLS, который определяет пути для LSP туннелей.
    • Модуле управления трафиком MPLS, который обеспечивает доступ к и запись ресурсной информации, подлежащей рассылке.
    • Переадресации согласно меткам, которая предоставляет маршрутизаторам возможности, сходные с уровнем L2, перенаправлять трафик через большое число узлов согласно алгоритму маршрутизации отправителя.

    Одним из подходов управления опорной сетью является определение сети туннелей между всеми участниками обменов. Протокол IGP, работающий в начале туннеля, определяет то, какой трафик должен проходить через любой оконечный узел. Модули вычисление пути и управления MPLS определяют маршрут LSP туннеля. Для каждого туннеля подсчитывается число пропущенных пакетов и байт.

    Иногда, поток настолько велик, что его нельзя пропустить через один канал (туннель). В этом случае может быть создано несколько туннелей между отправителем и получателем.

    Для реализации MPLS управления трафиком сеть должна поддерживать следующие возможности Cisco IOS:

    • Мультипротокольную переадресацию пакетов с использованием меток (MPLS)
    • IP-переадресацию CEF (Cisco Express Forwarding)
    • Протокол маршрутизации IS-IS (Intermediate System-to-Intermediate System; см. RFC-1142, -1195, -2763, -2966 и -2973)

    Дополнительные данные о MPLS и управлении трафиком можно найти в документации Cisco (поддерживается в реализациях 7620, 7640, 7200, 7500 и 12000):

    • Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching"
    • Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".
    • Cisco IOS Release 11.3 Switching Services Command Reference, Часть 1, глава "Configuring RSVP"
    • Cisco IOS Release 11.3 Network Protocols Command Reference, Часть 1, глава "RSVP Commands".
    • Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching".
    • Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".

    Протоколы состояния канала типа IS-IS для вычисления кратчайшего пути для всех узлов сети используют алгоритм Дикстры SPF. Маршрутные таблицы получаются на основе дерева кратчайших путей. Эти таблицы содержат упорядоченный набор адресов места назначения и информацию о ближайших соседей. Если маршрутизатор осуществляет прокладку путей на основе алгоритма шаг-за-шагом, первым шагом является физический интерфейс, соединенный с маршрутизатором.

    Новые алгоритмы управления трафиком вычисляют пути до одного или более узлов в сети. Эти маршруты рассматриваются как логические интерфейсы исходного маршрутизатора. В данном контексте эти маршруты представляют собой LSP и рассматриваются как TE-туннели.

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

    Управление трафиком MPLS:

    • Исключается необходимость ручной конфигурации сетевых устройств, чтобы задать определенные маршруты. Вместо этого, можно положиться на возможности управления трафиком, предоставляемые MPLS.
    • Производится оценка полосы канала и значения трафика при прокладке маршрута через опорную сеть.
    • Имеет механизмы динамической адаптации, которые позволяют сделать опорную сеть устойчивой к отказам даже в условиях, когда несколько путей были рассчитаны в режиме off-line. В случае отказа узлов производится коррекция топологии опорной сети.

    В рекомендациях CISCO [15] можно прочесть, что MPLS позволяет провайдеру маршрутизировать потоки данных так, чтобы клиенту гарантировать минимум задержки и максимум пропускной способности.

    Сформировав несколько виртуальных сетей для заданного набора узлов, можно попытаться объединять возможности этих сетей в случае возникновения такой необходимости, увеличивая пропускную способность. Можно для каждой из субсетей использовать разный уровень QoS с помощью протокола RSVP.

    Рассмотрение описания конфигурации MPLS в аппаратах CISCO [15] показывает отсутствие возможности задания какого-либо значения QoS. Но это не означает, что этого не будет возможно уже в 2003 году.


    5. Протокол резервирования ресурсов RSVP

    Если сетевые условия позволяют, то, используя протокол RSVP (где QoS задается в спецификации потока ( flowspec ) - практически на сегодня это единственное реализуемое решение), можно попытаться зарезервировать для заданной виртуальной сети определенное значение полосы пропускания. Следует иметь в виду, что протокол RSVP приспособлен в основном для резервирования определенного значения полосы пропускания, а не произвольного QoS (спецификации QoS см. в RFC-2210, 2211 и 2212) для существующего виртуального соединения. Если виртуальное соединение разорвано, следом ликвидируются и все резервирования. Следует, разумеется, иметь в виду, что >RSVP может работать как c TCP- так и c UDP-сессиями поверх IPv4 и IPv6. Сессия резервирования инициируется получателем данных. Резервирование может осуществляться как для уникаст, так и мультикаст-потоков. Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205; http://book.itep.ru/4/44/Rsv_4496.htm; смотри также RFC-2206-10, -2490, -2745-47, -2750-52, -2872, -2961, -2996, -3097, -3175, -3181, -3209-10) определяет режим резервирования (способ объединения нескольких заявок для одного и того же интерфейса: WF, FF, SE), формирования резервирования и его поддержания в условиях отсутствия поддержки данного протокола в одном или нескольких узлах виртуального пути, пересылки QoS-запросов другим маршрутизаторам и т.д., но решения принимаются маршрутизатором локально без знания условий в остальной части пути. По этой причине здесь не может идти речь о минимизации задержки, обеспечении надежности или безопасности, хотя в перспективе это может стать возможным.

    Следует учитывать, что инициатором резервирования в RSVP всегда является клиент (именно он посылает первичные запросы). По этой причине могут возникнуть проблемы при попытке централизованного управления QoS посредством RSVP.

    RSVP не имеет механизмов управления очередями в конкретных интерфейсах, а механизм резервирования полосы пропускания для одного из направлений обмена является зоной ответственности изготовителя маршрутизатора и не публикуется. Кроме того, при скоростях несколько сот Мбит/с часто обработка процедур буферизации перепоручается аппаратным средствам (например, в случае компании CISCO).

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

            RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.

            RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока.

            RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов.

            RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов.

            RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP.

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

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

            RSVP может работать с IPv4 и IPv6.

    Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме.

    Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

    1.    "Rspec", который определяет желательное значение QoS, и

    2.     "Tspec", который описывает информационный поток.

    Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC 2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

    Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

    1.          Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC 2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.

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

    3.          IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.

    Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации.

    Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec. Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS.

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

    Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

    Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

            Стиль WF (Wildcard-Filter)

    Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая "труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.

            Стиль FF (Fixed-Filter)

    Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии.

            Стиль SE (Shared Explicit)

    Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей.

    Для облегчения работы с RSVP разработан протокол COPS (Common Open Policy Service; RFC-2748, The COPS Protocol, D. Durham, Ed. Смотри также RFC-2749, -2940 и -3084).

    Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике. Предполагается, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [27-28]. Смотри также http://book.itep.ru/4/4/cops.htm

    В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.

    При работе с АТМ ситуация ненамного лучше, программное обеспечение АТМ-коммутаторов также обычно не доступно. Но имеется возможность работы RSVP поверх АТМ [29-31].

    Рассматривается внедрение протокола RSVP на уровень L2 [34].

    При наличии механизмов реализации других типов QoS (смотри, например, RFC-2430 [21] и Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", где предлагается ввести дополнительные биты в заголовок), можно решить проблему в более общем виде (но эта технология находится лишь на стадии обсуждения и не внедрена ни на одном серийном приборе). В рамках одной автономной системы (AS), где используется внутренний протокол маршрутизации OSPF>, можно обеспечить требуемый уровень QoS, но это будет делаться вручную, во всяком случае, на уровне задания значений метрики. Теоретически можно это сделать и автоматически, например, в случае применения версии протокола IGRP (внутренний протокол компании CISCO), поддерживающего автоматическую оценку значений метрики. К сожалению, компания CISCO отошла от первоначального плана и значения метрики там задается в настоящее время также администратором.

    Реализация управления QoS предполагает организацию эффективной системы мониторинга базовых параметров, характеризующих требуемый уровень QoS. Для этого требуется контролировать уровень информационных потоков во всех фрагментах VPN, постоянно измерять значение RTT и его дисперсии, контролировать уровень вероятности потери пакетов во всех фрагментах виртуального пути. Желательно также отслеживать корреляции перечисленных параметров и локального значения загрузки. Схема мониторинга и управления QoS показана на рис. 6.


    Рис. 6.

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

    Выводы

    1.      Для сетей TCP/IP основным инструментом управления QoS пока является протокол RSVP (это касается и MPLS).

    2.      Протокол MPLS является удобным средством формирования корпоративных сетей (VPN), которые позволяют поднять их безопасность.

    3.      Для обеспечения работы MPLS необходима поддержка протоколов IS-IS и MP-BGP всеми маршрутизаторами VPN.

    4.      Протокол MPLS предоставляет гибкие средства мониторинга трафика в пределах VPN.

    5.      Технология управления трафиком ТЕ предполагает совмещение возможностей протоколов уровней L2 и L3.

    6.      Протокольных средств управления очередями в Ethernet или в TCP/IP не существует. Такие средства имеются вATM-коммутаторах, ограниченные возможности имеются в некоторых маршрутизаторах CISCO и в коммутаторах L2 (например, выбор между режимами store-and-forward и cut through и т.д.). В любом случае такие режимы конфигурируются администратором индивидуально для каждого сетевого устройства. Разумеется, что-то можно сделать с помощью протокола SNMP дистанционно, если имеется пароль доступа ( community).

    7.      Переход на IPv6 существенно расширяет возможности управления трафиком за счет использования меток потоков (пока не ясно насколько эта возможность поддерживается программно). Данное свойство особенно важно для передачи мультимедийных данных, например, программ цифрового телевидения. Последнее предполагает значительное расширение интегральной полосы каналов опорной сети (хотя бы до 155Мбит/ c).

    8.      Все выше сказанное отражает ситуацию сегодняшнего дня, когда не стандартизовано дополнительных средств управления трафиком и QoS. Положение может измениться, если будут, например, стандартизованы какие-то дополнительные атрибуты потоков (как это было сделано при введении меток для VPN). Такие работы уже ведутся (см. [3])

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


    Библиография

    1. E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. RFC-2386. A Framework for QoS-based Routing in the Internet. August 1998.

    2. R. Braden, RFC-1633. Integrated Services in the Internet Architecture: an Overview. June 1994.

    3. E. Rosen, Y. Rekhter, RFC-2547. BGP/MPLS VPNs. March 1999.

    4. J. Malcolm, RFC-2702, Requirements for Traffic Engineering Over MPLS. September 1999.

    5. A. Malis, RFC-2917, A Core MPLS IP VPN Architecture, September 2000.

    6. E. Rosen. RFC-3031, Multiprotocol Label Switching Architecture, January 2001

    7. D. Tappan, RFC-3032, MPLS Label Stack Encoding, January 2001.

    8. J. Lawrence, RFC-3035, MPLS using LDP and ATM VC Switching, January 2001.

    9. Y. Katsube, RFC-3063, MPLS Loop Prevention Mechanism, February 2001.

    10. B.Олифер, Н. Олифер, Искусство оптимизации трафика. Журнал сетевых решений LAN, декабрь 2001, стр. 38-47.

    11. В.Олифер, Н. Олифер, Виртуальные частные сети на основе MPLS. Журнал сетевых решений LAN, январь 2002, стр. 58-63.

    12. Д.Гринфильд, Глобальная служба MPLS: опережая время. Журнал сетевых решений LAN, март 2002, стр. 32-38.

    13. В.Олифер, Н. Олифер, MPLS на службе VPN. Журнал сетевых решений LAN, март 2002, стр. 40-47.

    14. L. Wu, RFC-3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, May 2002.

    15. http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/xtocid285471

    16. http://www.cisco.com/warp/public/105/qos_index.shtml

    17. Jim Guichard, Ivan Pepelnjak. MPLS and VPN Architectures. A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPNs. Cisco Press, 2000.

    18. Sean Harnedy. The MPLS Primer. An Introduction to Multiprotocol Label Switching, Prentice Hall, 2001.

    19. Eric W. Gray, MPLS. Implementing the Technology. With CD-ROM, Addison Wesley, 2001.

    20. http://old.ruslan-com.ru/marconi/MPLS/mpls_intro.htm#Arch

    21. Li, T. and Y. Rekhter, RFC-2430, Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). October 1998.

    22. J. Wroclawski. RFC-2210, The Use of RSVP with IETF Integrated Services. September 1997.

    23. L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205. September 1997.

    24. Bates, Y. Rekhter, R., Chandra, D. Katz. Multiprotocol Extensions for BGP-4. RFC-2858. June 2000.

    25. J. Wroclawski. RFC-2211. Specification of the Controlled-Load Network Element Service. September 1997.

    26. S. Shenker. RFC-2212. Specification of Guaranteed Quality of Service. September 1997.

    27. D. Durham, Ed. RFC-2748. The COPS (Common Open Policy Service) Protocol. January 2000.

    28. Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000.

    29. L. Berger. RFC-2379. RSVP over ATM Implementation Guidelines. August 1998.

    30. L. Berger. RFC-2380. RSVP over ATM Implementation Requirements. August 1998.

    31. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. RFC-2382. A Framework for Integrated Services and RSVP over ATM. August 1998.

    32. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. RFC-2749 COPS usage for RSVP. January 2000.

    33. S. Herzog. RFC-2750. RSVP Extensions for Policy Control. January 2000.

    34. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. RFC-2814. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. May 2000.

    35. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. RFC-3175. Aggregation of RSVP for IPv4 and IPv6 Reservations. September 2001.

    36. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RFC-3209. RSVP-TE: Extensions to RSVP for LSP Tunnels. December 2001.

    37. A. Smith, D. Partain, J. Seligson. RFC-2940. Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. October 2000.

    38. K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. RFC-3084. COPS Usage for Policy Provisioning (COPS-PR). March 2001.

    39. Максим Кульгин. Контроль трафика в сетях ATM. LAN/Журнал Сетевых решений #12/98

    40. Алексей Лукацкий. Неизвестная VPN. http://abn.ru/inf/compress/network4.shtml

    41. http://www.cisco.com.ru/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/te120_7t.pdf (управление трафиком - ТЕ)

    42. Мультипротокольная коммутация по меткам (MPLS). http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt3/xcftagc.pdf

    43. http://www.tt.ru/?do=stech2&id=740 ("ТрансТелеКом", обзоры на русском)

    44. http://www.mplsforum.org (Оффициальная страница группы разработчиков MPLS).

    45. IP-Datentransport ist nur der Anfang. Wilhelm Greiner, LANline 10/2002, стр. 110-115;
      MPLS als Hoffnungstraeger. Gerhard Kafka, LANline 10/2002, стр. 122-125.
      Keine Zeit fuer Auszeigen. Markus Heis, LANline 10/2002, стр. 126-129;

    46. Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment; RFC-3353, D. Ooms, August 2002.

    47. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks; RFC-3443, P. Agarwal, January 2003.

    48. Framework for Multi-Protocol Label Switching (MPLS)-based Recovery; RFC-3469, V. Sharma, February 2003.

    49. Generalized Multi-Protocol Label Switching (GMPLS)Signaling Functional Description; RFC-3471, L. Berger, January 2003.

    50. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions; RFC-3472, P. Ashwood-Smith, January 2003.

    51. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions; RFC-3473, L. Berger, January 2003.

    52. Graceful Restart Mechanism for Label Distribution Protocol; RFC-3478, M. Leelanivas, February 2003.

    53. Fault Tolerance for the Label Distribution Protocol (LDP); RFC-3479, A. Farrel, February 2003.

    54. Шринивас Вегешна, "Качество обслуживания в сетях IP", Cisco Press, 2003.

    55. Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers; RFC-2474, K. Nichols, December 1998.

    56. Assured Forwarding PHB Group; RFC-2597,, J. Heinanen, June 1999.

    57. Multiprotocol Label Switching (MPLS) www.ietf.org/html.charters/mpls-charter.html

    58. Jim Guichard, Ivan Pepelnjak, "MPLS and VPN Architectures", Cisco Press, 2001

    59. Adaptive Bandwidth Control for Efficient Aggregate QoS Provisioning, Peerapon Siripongwutikorny Sujata Banerjeeyz David Tippery

    60. Per-flow Delay Performance in Traffic Aggregates, Peerapon Siripongwutikorn├ and Sujata Banerjee├,┤ ├Telecommunications Program, University of Pittsburgh

    61. A QoS Engineering Architecture for the Next-Generation-Internet

    Previous: 4.4.16 Протокол SNTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)


    (E. Rosen. Multiprotocol Label Switching Architecture, RFC-3031.)


    1. Введение в MPLS

    В данном документе специфицирована архитектура многопротокольной коммутации меток (MPLS).


    1.1. Обзор

    Поскольку пакеты в случае протокола сетевого уровня без установления соединения переносятся от одного маршрутизатора к другому, каждый из них совершенно независим в принятии решения переадресации. То есть, каждый маршрутизатор анализирует заголовок пакета и каждый маршрутизатор реализует алгоритм маршрутизации сетевого уровня. Маршрутизатор независимо выбирает следующий шаг для пакета, основываясь на результатах анализа его заголовка и результата работы маршрутного алгоритма. Заголовки пакета содержат значительно больше информации, чем нужно для выбора следующего шага. Выбирая следующий шаг можно, следовательно, выполнять две процедуры. Первая делит весь набор пакетов на классы FEC (Forwarding Equivalence Classes). Вторая ставит в соответствие каждому FEC следующий шаг маршрута. В той части, которая касается переадресации, разные пакеты, поставленные в соответствие определенному FEC, не различимы. Все пакеты, которые принадлежат определенному FEC, и которые отправлены из конкретного узла будут следовать одним и тем же путем (или в случае многомаршрутного протокола, они будут следовать через один и тот же набор путей, ассоциированный с FEC).

    При обычной IP переадресации, маршрутизатор рассматривает два пакета принадлежащими к одному FEC, если существует адресный префикс X в таблицах маршрутизации маршрутизатора, такой что Х, соответствует каждому адресу места назначения. Когда пакет проходит через сеть, на каждом шагу пакет последовательно просматривается и ему присваивается FEC.

    В MPLS присвоение пакету определенного FEC делается только раз, когда пакет входит в сеть. FEC, к которому приписан пакет, кодируется, как код фиксированной длины, называемый меткой. Когда пакет переадресуется на следующем шагу, метка посылается вместе с ним, так что пакеты оказываются помечены, до того, как будут переадресованы.

    При последующих шагах не производится никакого анализа заголовков пакетов сетевого уровня. Здесь для индексации следующего шага и новой метки используется присвоенная ему на входе метка. Старая метка замещается новой и пакет переадресуется в следующий узел.

    В парадигме переадресации MPLS, поскольку пакет приписан определенному FEC, никакого последующего анализа заголовков в маршрутизаторах по пути следования не производится, а переадресация управляется исключительно на основе меток. Это имеет много преимуществ перед традиционной маршрутизацией на сетевом уровне.

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

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

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

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

    - Иногда желательно заставить пакеты следовать определенным маршрутом, который выбран перед входом или во время входа пакета в сеть, вместо следования нормальному динамическому протоколу маршрутизации. Это может быть сделано в соответствии с разной политикой, или с привлечением техники управления трафиком. При традиционной переадресации это требует, чтобы пакет нес в себе информацию о маршруте, по которому он должен двигаться (маршрутизация отправителя). В MPLS, метка может использоваться для представления маршрута, так что идентичность маршрута не переносится вместе с пакетом.

    Некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только с целью выбора следующего шага, но и для определения приоритета и класса услуг. Они могут затем применить различные пороги отсева или графика обслуживания пакетов. MPLS допускает (но не требует) приоритетность или класс обслуживания, зависящие полностью или частично от метки. В этом случае, можно сказать, что метка представляет собой комбинацию FEC, приоритета или класса обслуживания. В MPLS "Multiprotocol" означает многопротокольный, так как его техника применима к любому протоколу сетевого уровня. В данном документе, однако, внимание сконцентрировано на использовании IP в качестве протокола сетевого уровня. Маршрутизатор, который поддерживает MPLS, называется "Label Switching Router", или LSR (маршрутизатором с коммутацией по меткам).


    1.2. Терминология

    DLCI

    Метка, используемая в сетях Frame Relay для идентификации схем frame relay.

    forwarding equivalence class (FEC)

    Группа IP-пакетов, которые переадресуются каким-то образом (например, по тому же маршруту, с той же маршрутной обработкой)

    frame merge -
    объединение кадров

    Слияние меток, когда это применяется к операциям в среде, базирующейся на кадрах (frame based), так что потенциальная проблема перекрытия ячеек не является проблемой.

    Label - Метка

    Идентификатор фиксированной длины, который используется для идентификации FEC, обычно имеет локальное значение.

    label merging -
    объединение меток

    Замещение множественных приходящих меток для определенного FEC с одной выходной меткой

    label swap -
    инверсия меток

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

    label swapping

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

    label switched hop

    Шаг между двумя узлами MPLS, на которые осуществляется переадресация с привлечением меток.

    label switched path - путь с коммутацией меток

    Путь через один или более LSR на одном уровне иерархии для пакетов в определенном FEC.

    label switching router

    Узел MPLS, который способен переадресовывать пакеты L3 согласно их меткам

    layer 2-
    слой L2

    Протокольный уровень, ниже уровня 3 (который, следовательно, предлагает услуги уровню 3). Переадресация с использованием меток, происходит на уровне 2 вне зависимости от того, являлась ли рассмотренная метка ATM VPI/VCI, frame relay DLCI или метка MPLS.

    layer 3 -
    слой L3

    Протокольный уровень, на котором IP и ассоциированные с ним протоколы маршрутизации взаимодействуют с канальным уровнем 2.

    loop detection -
    детектирование петель

    Метод, при котором разрешено формирование петлевых маршрутов, такие структуры позднее выявляются

    loop prevention -
    предотвращение петель

    Метод, при котором данные никогда не передаются по петлевым маршрутам

    label stack - стек меток

    Упорядоченный набор меток

    merge point

    Узел, в котором произведено объединение меток

    MPLS domain -
    домен MPLS

    Непрерывный набор узлов, реализующих MPLS -маршрутизацию и находящихся в одном маршрутном и административном домене.

    MPLS edge node -
    пограничный узел MPLS

    Узел MPLS, который соединяет MPLS-домен с узлом, находящимся вне домена, потому что он не поддерживает MPLS, и/или из-за того, что он размещен в другом домене. Заметим, что если LSR имеет соседнюю ЭВМ, которая не работает с MPLS, тогда этот LSR является пограничным узлом MPLS.

    MPLS egress node -
    выходной узел MPLS

    Пограничный узел MPLS, если через него трафик выходит из домена MPLS

    MPLS ingress node - входной узел MPLS

    Пограничный узел MPLS, если через него трафик входит в домен MPLS

    MPLS label -
    метка MPLS

    Метка, которая содержится в заголовке пакета и которая представляет FEC пакета

    MPLS node -
    узел MPLS

    Узел, поддерживающий протокол MPLS. Узел MPLS распознает протоколы управления MPLS, реализует один или более протоколов маршрутизации L3, и способен переадресовывать пакеты на основе меток. Узел MPLS может опционно переадресовывать L3 пакеты в традиционном режиме.

    MultiProtocol Label Switching

    Рабочая группа IETF и разработки данной группы

    network layer - сетевой уровень

    Синоним уровня 3

    stack

    Синоним стека меток

    switched path

    Синоним пути с коммутацией меток

    virtual circuit -
    виртуальная схема

    Схема, используемая технологией обмена с установлением соединения на уровне 2, такой как ATM или Frame Relay, требующая поддержки статусной информации в переключателях уровня 2.

    VC merge -
    объединение VC

    Объединение меток, когда метка MPLS переносится в поле ATM VCI (или в комбинации полей VPI/VCI), чтобы позволить объединение нескольких VC в один VC

    VP merge -
    объединение VP

    Объединение меток, когда метка MPLS переносится в поле ATM VPI, чтобы позволить объединение нескольких VP в один VP. В этом случае две ячейки будут иметь одно и то же значение VCI, только если отправлены из одного узла. Это позволяет различать ячейки разных отправителей с помощью VCI.

    VPI/VCI

    Метка, используемая в сетях ATM для идентификации схем


    1.3. Акронимы и аббревиатуры

    ATM Asynchronous Transfer Mode - асинхронный режим передачи

    BGP Border Gateway Protocol - протокол внешней маршрутизации

    DLCI Data Link Circuit Identifier - идентификатор канала передачи данных

    FEC Forwarding Equivalence Class - класс переадресации

    FTN FEC to NHLFE Map - соответствие FEC и NHLFE

    IGP Interior Gateway Protocol - внутренний протокол маршрутизации

    ILM Incoming Label Map - таблица соответствия входящих меток

    IP Internet Protocol - протокол Интернет

    LDP Label Distribution Protocol - протокол пересылки меток

    L2 Layer 2 - уровень 2

    L3 Layer 3 - уровень 3

    LSP Label Switched Path - путь с коммутацией меток

    LSR Label Switching Router - маршрутизатор c коммутацией меток

    MPLS MultiProtocol Label Switching - многопротокольная коммутация меток

    NHLFE Next Hop Label Forwarding Entry - запись, содержащая адрес следующего шага при коммутации меток

    SVC Switched Virtual Circuit - переключаемая виртуальная схема

    SVP Switched Virtual Path - переключаемый виртуальный путь

    TTL Time-To-Live - время жизни

    VC Virtual Circuit - виртуальная схема

    VCI Virtual Circuit Identifier - идентификатор виртуальной схемы

    VP Virtual Path - виртуальный путь

    VPI Virtual Path Identifier - идентификатор виртуального пути.


    2. Основы MPLS

    В этом разделе, вводятся некоторые базовые концепции MPLS, и описывается используемый общий подход.


    2.1. Метки

    Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующемуся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает c этим адресом.

    Если Ru и Rd являются LSR, они могут договориться о том, что когда Ru передает пакет Rd, Ru снабжает пакет меткой с кодом L, если и только если пакет принадлежит определенному классу FEC F. То есть, они могут согласовать соответствие между меткой L и F для пакетов, транспортируемых от Ru к Rd. В результате такого соглашения L становится выходной меткой Ru, представляющей FEC F, а L становится входной меткой Rd.

    Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной.

    Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или, что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR.

    Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеет место соответствие межу меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR.


    2.2. Вышестоящие и нижестоящие LSR

    Предположим, что Ru и Rd договорились о соответствии метки L и FEC F, для пакетов, посланных из Ru в Rd. Тогда с учетом этого соответствия, Ru является "вышестоящим LSR", а Rd является "нижестоящим LSR".

    Узел является вышестоящим, а другой нижестоящим с учетом того, что в данной ассоциации (метки и класса) метка представляет определенный FEC для пакетов, транспортируемых от вышестоящего узла к нижестоящему. Это, вообще говоря, не означает, что пакеты в этом FEC будут действительно маршрутизированы от вышестоящего узла нижестоящему.


    2.3. Помеченные пакеты

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

    Метод кодирования метки должен быть согласован субъектом, ее формирующим и субъектом адресатом.


    2.4. Присвоение меток и рассылка

    В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются "снизу-вверх".

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


    2.5. Атрибуты ассоциации меток (Label Binding)

    Конкретная ассоциация метки L и класса FEC F, анонсируемая Rd для Ru, может иметь соответствующие атрибуты. Если Ru работает как нижестоящий LSR, и анонсирует ассоциацию метки и класса FEC F, тогда при определенных обстоятельствах, может оказаться нужно разослать соответствующий атрибут, полученный от Rd.


    2.6. Протоколы рассылки меток

    Протокол рассылки меток представляет собой набор процедур, с помощью которых один LSR информирует другие об ассоциациях метка/FEC, которые он сформировал. Два LSR, которые используют протокол рассылки меток для обмена данными об ассоциациях метка/FEC, называются "партнерами рассылки меток". Если два LSR являются партнерами по рассылки меток, мы будем говорить о смежности рассылки меток между ними.

    Протокол рассылки меток включает в себя также любые согласования, при которых партнеры изучают MPLS возможности друг друга.

    Архитектура не предполагает, что должен существовать только один протокол рассылки меток. В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылка меток можно было совместить друг с другом (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы специально для целей рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]).

    В данном документе, мы пытаемся использовать акроним "LDP" для ссылок на протокол, определенный в [MPLS-DP].


    2.7. Unsolicited Downstream против Downstream-on-Demand

    Архитектура MPLS позволяет LSR непосредственно посылать запросы узлу следующего шага относительно конкретного FEC, и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstream-on-demand).

    Архитектура MPLS позволяет также LSR посылать ассоциации другим LSR, которые напрямую эти данные не запрашивали. Такой обмен называется рассылкой меток нижележащим без запроса (unsolicited downstream).

    Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstream-on-demand, другие - только в режиме unsolicited downstream, а некоторые - в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена.


    2.8. Режим удержания меток (Retention Mode)

    LSR Ru может получить (или уже получил) от LSR Rd ассоциацию метка-FEC, даже несмотря на то, что Rd не является следующим шагом для Ru (для данного FEC).

    Ru теперь имеет выбор следует ли ему отслеживать такие ассоциации или отбрасывать их. Если Ru отслеживает такие ассоциации, тогда он может немедленно начать использование этой ассоциации, если Rd в конце концов, становится его следующим шагом для заданного FEC. Если Ru игнорирует такие ассоциации, тогда если Rd позднее станет следующим шагом, ассоциация должна быть воспринята снова. Если LSR поддерживает "свободный режим удержания меток" (Liberal label retention mode), он поддерживает ассоциации между меткой и FEC, который получен от LSR, не являющегося следующим шагом для этого FEC. Если LSR поддерживает "консервативный режим удержания меток" (Conservative label retention mode), он отбрасывает такие ассоциации.

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


    2.9. Стек меток

    До сих пор мы обсуждали проблему, как если бы помеченные пакеты несли в себе только одну метку. Как мы увидим, полезно иметь более обобщенную модель, в которой помеченные пакеты несут в себе несколько меток, уложенных в порядке "последний_вошел-первым_вышел". Мы будем называть это стеком меток.

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

    Непомеченный пакет может рассматриваться как пакет, чей стек меток пуст (т.e., глубина стека которого равна 0).

    Если стек пакетных меток имеет глубину m, мы считаем, что метка на дне стека размещена на уровне 1, метка над ней (если таковая имеется) имеет уровень 2, а метка наверху стека имеет уровень m.


    2.10. Запись Next Hop Label Forwarding (NHLFE)

    "Next Hop Label Forwarding Entry" (NHLFE) используется при переадресации помеченных пакетов. Здесь содержится следующая информация:

    1. Следующий шаг пакета

    2. Операция, которая должна быть произведена над стеком меток. Это одна из следующих операций:

    a) заместить метку на верху стека специфицированной новой меткой

    b) извлечь метку из стека

    c) заместить метку на верху стека специфицированной новой меткой, и затем ввести в стек одну или более специфицированных меток.

    Она может содержать:

    d) инкапсуляцию канальных данных, которая будет использована при пересылке пакета

    e) метод кодирования стека меток, при пересылке пакета

    f) другую информацию, необходимую для того чтобы корректно отобразить пакет.

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

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

    Если следующим шагом пакета является текущий LSR, тогда операцией над стеком меток должна быть "pop".


    2.11. Установление соответствия для входных меток ILM (Incoming Label Map)

    "Incoming Label Map" (ILM) устанавливает соответствие каждой входящей метки с набором NHLFE. Эта операция используется, когда переадресуемые пакеты являются помеченными.

    Если ILM связывает определенную метку с набором NHLFE, который содержит более одного элемента, только один элемент должен быть выбран из набора, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа. Используя технику установления соответствия ILM, можно работать с набором, содержащим более одного NHLFE, что может оказаться желательно, например, при необходимости сбалансировать трафик между несколькими путями, имеющими равные метрики.


    2.12. Установление соответствия между FEC и NHLFE (FTN)

    Методика "FEC-to-NHLFE" (FTN) устанавливает соответствие между каждым FEC и набором NHLFE. Она используется при переадресации непомеченных пакетов, при необходимости их пометки до переадресации. Если FTN устанавливает соответствие между конкретной меткой и набором NHLFE, который содержит более одного элемента, только один из них должен быть выбран, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа.


    2.13. Замена меток

    Замена меток (Label swapping) представляет собой использование следующих процедур для переадресации пакетов. Для того чтобы переадресовать помеченный пакет, LSR рассматривает метку на верху стека. Он использует ILM для установления соответствия этой метки набору NHLFE. Используя информацию из NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета, затем записывает новую метку в стек пакета и переадресует его.

    Для того чтобы переадресовать непомеченный пакет, LSR анализирует заголовок сетевого уровня, чтобы определить FEC пакета. Затем он использует FTN, для того чтобы установить соответствие с NHLFE. Используя информацию NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета. (Извлечение метки из стека в этом случае будет нелегальным).

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


    2.14. Область действия и уникальность меток

    Данный LSR Rd может связать метку L1 с FEC F, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L2 с FEC F, и переправить эту ассоциацию партнеру Ru2. Является ли L1 == L2 не определяется архитектурой, это вопрос исключительно локальный.

    Данный LSR Rd может связать метку L с FEC F1, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L с FEC F2, и переправить эту ассоциацию партнеру Ru2. Если и только если Rd может сообщить, когда он получает пакет с меткой на верху стека равной L, занесена ли она в стек RU1 или RU2, архитектура не требует равенства F1 == F2. В таких случаях, мы можем сказать, что Rd использует другое пространство для меток, которые он пересылает Ru1, чем для меток, посылаемых Ru2. Вообще, Rd может лишь сообщить, Ru1 или Ru2 положил данную метку со значением L на верх стека, если выполнены следующие условия:

    - Ru1 и Ru2 являются партнерами, обменивающимися метками, и которым Rd пересылает значение метки L, и

    - Ru1 и Ru2 оба соединены с Rd непосредственно через интерфейс точка-точка.

    Когда эти условия выполнены, LSR может использовать метки, имеющие область действия "per interface", т.e., которые являются уникальными для каждого интерфейса. Можно сказать, что LSR использует "пространство меток интерфейса". Когда эти условия не выполнены, метки должны быть уникальными для LSR, который их присвоил, и мы можем сказать, что LSR использует "пространство меток платформы".

    Если конкретный LSR Rd связан с некоторым LSR Ru через два интерфейса по схеме точка-точка, тогда Rd может пересылать Ru ассоциацию метки L с FEC F1, также как ассоциацию метки L с FEC F2, F1 != F2, если и только если каждая ассоциация корректна для пакетов, которые Ru посылает Rd через один из интерфейсов. Во всех других случаях, Rd не должен посылать ассоциации Ru, сопрягающие одну и ту же метку с двумя разными FEC.

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

    Возникает вопрос, может ли LSR использовать мультиплатформные пространства меток, или использовать много пространств меток интерфейса для одного и того же интерфейсного устройства. Это не запрещено архитектурой. Однако в таких случаях LSR должен иметь некоторые средства, не специфицированные архитектурой, определения для заданной входной метки, какому пространству принадлежит данная метка. Например, [MPLS-SHIM] специфицирует, что различные пространства меток используются для уникастных и мультикастных пакетов, а для разделения этих пространств используется код канального уровня.


    2.15. Маршрут с коммутацией меток (LSP), входной и выходной LSP

    "Маршрут с коммутацией меток (LSP) уровня m" для определенного пакета P является последовательностью маршрутизаторов <R1, ..., Rn> со следующими свойствами:

    1. R1, "вход LSP", является LSR, который вносит метку в стек пакета P, в результате формируется стек глубиной m;

    2. Для всех i, 1<i<n, P (когда он приходит в LSR Ri) имеет стек меток глубиной m;

    3. Никогда за время передачи P от R1 к R[n-1] глубина стека не будет меньше m;

    4. Для всех i, 1<i<n: Ri передает P в R[i+1] посредством MPLS, т.e., путем использования метки в верхней позиции стека (метка уровня m) в качестве индекса в ILM;

    5. Для всех i, 1<i<n: если система S получает и переадресует P, после того как P передан Ri, но до того как P получен R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую субсеть, и S может быть одним из переключателей информационного канала), далее решение переадресации S не базируется на метке уровня m, или на основе заголовка сетевого уровня. Это может быть, так как:

    a) решение не основано на содержимом стека или заголовка сетевого уровня;

    b) решение основано на содержимом стека, куда положены другие метки (т.e., на метке уровня m+k, где k>0).

    Другими словами, мы можем описать уровень m LSP для пакета P, как последовательность маршрутизаторов:

    1. Которая начинается с LSR ("вход LSP "), заносящий метку на уровень m.

    2. Все маршрутизаторы, чьи промежуточные LSR, принимают решение о переадресации согласно метке на уровне m.

    3. Которая завершается (в "выходном LSP"), когда решение переадресации делается на основе коммутации меток на уровне m-k, где k>0, или когда решение переадресации делается "традиционно", посредством не-MPLS процедур.

    Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы LSR ни занес метку в стек уже помеченного пакета, он должен быть уверен, что новая метка соответствует FEC, чьим выходом LSP служит LSR, который сформировал метку, которая сейчас является второй в стеке. Мы будем называть последовательность LSR "LSP для определенного FEC F", если он является LSP уровня m для заданного пакета P, когда уровень метки P соответствует FEC F.

    Рассмотрим набор узлов, которые могут быть входными LSP-узлами для FEC F. Тогда существует LSP для FEC F, который начинается с каждого из этих узлов. Если некоторое число этих LSP имеет идентичный выходной LSP, тогда можно рассматривать набор таких LSP как дерево, чьим корнем является выходной LSP. (Так как данные переносятся вдоль этого дерева по направлению к корню, эта структура может быть названа деревом мультиточка-точка). Мы можем, таким образом, говорить о "дереве LSP" для определенного FEC F.


    2.16. Извлечение предпоследнего шага

    Заметим, что согласно определениям из раздела 2.15, если <R1, ..., Rn> является LSP уровня m для пакета P, P может быть передан от R[n-1] к Rn с глубиной стека меток m-1. То есть, может быть выполнена операция pop для стека меток в предпоследнем LSR LSP, а не в выходном LSP.

    С архитектурной точки зрения это вполне приемлемо. Целью метки уровня m является доставка пакета в Rn. Раз R[n-1] решил послать пакет Rn, метка не имеет более значения и не должна далее транспортироваться.

    Имеется также практическое преимущество извлечения данных о предпоследнем шаге. Если так не сделать, тогда при получении пакета выходным LSP, он сначала просматривает верхнюю метку из стека, и определяет, что это действительно выходной LSP. Затем он должен извлечь из стека метку, и проверить, что осталось в стеке пакета. Если в стеке имеется другая метка, выходное устройство анализирует метку и осуществляет пересылку пакета на основе этого анализа. (В этом случае, выходное устройство для пакетов уровня m LSP является промежуточным узлом для его уровня m-1 LSP). Если в стеке нет других меток, тогда пакет переадресуется согласно его адресу места назначения сетевого уровня. Заметим, что это потребует от выходного устройства двух просмотров, либо просмотра двух меток, либо просмотра метки с последующим анализом адреса.

    Если, с другой стороны, используется извлечение предпоследнего шага из стека, тогда предпоследний узел просматривает метку и определяет:

    - это предпоследний шаг, и

    - какой узел является следующим.

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

    Создание в программе коммутации меток "fastpath" может существенно помочь, если известно, что требуется лишь один просмотр метки:

    ╥    код может быть упрощен, если можно предположить, что ожидается только один просмотр
    ╥    код может быть основан на "time budget", который предполагает, что ожидается только один просмотр.

    В действительности, когда предпоследний шаг извлечен из стека, конец LSP не должен быть обязательно LSR.

    Однако некоторые аппаратные переключатели не могут извлекать метки из стека, поэтому это не может быть универсальным требованием. Могут также встретиться ситуации, в которых извлечение из стека предпоследнего шага нежелательно. Следовательно, предпоследний узел извлекает метку из стека, только если это запрашивается выходным узлом, ИЛИ если следующий узел в LSP не поддерживает MPLS.

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

    Начальное согласование протокола рассылки меток должно позволять каждому LSR определить, способны ли соседние LSR извлекать метки из стека. LSR НЕ ДОЛЖЕН запрашивать своего партнера по обмену метками извлекать метку из стека, если только он не способен делать это.

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


    2.17. LSP следующего шага

    LSP Next Hop для определенного помеченного пакета в конкретном LSR является LSR, который представляет следующий шаг пути, как это выбрано записью NHLFE, использованной для переадресации пакета. LSP Next Hop для определенного FEC является следующим шагом пути, как это выбрано записью NHLFE, индексированной меткой, которая соответствует этому FEC.

    Заметим, что LSP следующего шага может отличаться от того, который был бы выбран алгоритмом маршрутизации сетевого уровня. Мы будем использовать термин "следующий шаг L3", когда будем иметь в виду такой маршрут.


    2.18. Неверные входные метки

    Что должен сделать LSR, если он получает помеченный пакет с определенной входной меткой, но не имеет ассоциации для этой метки? Соблазнительно думать, что можно просто удалить метки и пакеты будут переадресовываться как непомеченные IP. Однако в некоторых случаях, реализация этого приведет к зацикливанию пакетов. Если вышестоящий LSR полагает, что метка сопряжена с определенным маршрутом, а нижестоящий LSR не считает метку, связанной с чем бы то ни было, и если маршрутизация шаг-за-шагом непомеченных IP-пакетов приведет пакет назад к вышестоящему LSR, тогда образуется петля.

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

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


    2.19. LSP управление: Ordered против Independent

    Некоторые FEC соответствуют адресным префиксам, которые рассылаются алгоритмом динамической маршрутизации. Начальная установка LSP для этих FEC может быть выполнена двумя способами: независимым управлением LSP (Independent LSP Control) или упорядоченным управлением LSP (Ordered LSP Control).

    В независимом управлении LSP, каждый LSR, учитывая, что он распознает определенный FEC, принимает независимое решение об ассоциации метки с FEC и рассылает эту ассоциацию своим партнерам. Это соответствует способу, реализуемому традиционной маршрутизацией IP-дейтограмм. Каждый узел принимает независимое решение относительно того, как обрабатывать конкретный пакет, и полагается на алгоритм маршрутизации. При упорядоченном управлении LSP, LSR только связывает метки с определенным FEC, если он является выходным LSR для данного FEC, или если он уже получил ассоциацию метки с FEC из узла следующего шага.

    Если хочется гарантировать, чтобы трафик в конкретном FEC следовал пути с некоторыми специфицированными свойствами (например, чтобы трафик не пересекал один и тот же узел дважды, чтобы для трафика были выделены определенные ресурсы, чтобы трафик следовал определенному пути и т.д.) должен использоваться упорядоченное управление. При независимом управлении, некоторые LSR могут начать коммутацию трафика по меткам в FEC, до того как LSP полностью сконфигурирован, и таким образом часть трафика в FEC может следовать пути, который не имеет специфицированных свойств. Упорядоченное управление должно также использоваться, если распознавание FEC является следствием конфигурирования соответствующего LSP. Упорядоченное конфигурирование LSP может быть инициировано входным или выходным узлом.

    Упорядоченное и независимое управление полностью совместимы. Однако если только не все LSR в LSP используют упорядоченное управление, результирующее влияние на поведение сети более существенно, чем в случае независимого управления, так как нельзя быть уверенным, что LSP не будет использован до того, как будет полностью сконфигурирован.

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


    2.20. Агрегатирование

    Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS, это может вызвать определенные последствия для набора FEC, в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае, в пределах домена MPLS, объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC, или следует ли ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, который сам является FEC (внутри некоторого домена), и применения меток для трафика в объединении, называется "агрегатированием". Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.

    Данный набор FEC, который является "агрегатируемым" в одном FEC, допускается (a) агрегатировать их в один FEC, (b) агрегатировать их в набор FEC, или (c) не агрегатировать их совсем. Таким образом, мы можем говорить о "гранулярности" агрегатирования, начиная с (a) "грубой гранулярности", кончая (c) "тонкой гранулярностью".

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

    Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.

    Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. Это означает, что, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru, Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение делать это или нет, является исключительно локальным.

    Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m), имеется два варианта:

    - Можно принять более тонкий уровень гранулярности для Rd. Это бы потребовало отзыва разосланных m, и рассылки n меток. Это предпочтительная опция.

    - Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора, и, если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.

    В любом случае, каждый LSR должен знать (при конфигурации) какую гранулярность использовать для формируемых меток. Когда используется упорядоченное управление, требуется чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления, наилучший результат может быть получен, путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").


    2.21. Выбор маршрута

    Выбор маршрута сопряжен с методом, используемым при выборе LSP для определенного FEC. Предлагаемая архитектура протокола MPLS поддерживает две опции выбора маршрута: (1) маршрутизация шаг-за-шагом и (2) явная маршрутизация.

    Маршрутизация шаг-за-шагом позволяет каждому узлу независимо выбрать следующий шаг для каждого FEC. Это обычный режим существующих сегодня IP-сетей. "маршрутизируемый шаг-за-шагом LSP" является LSP, чей маршрут выбирается по схеме шаг-за-шагом.

    В LSP при явной маршрутизации, каждый LSR не выбирает следующий шаг независимо; скорее один LSR, обычно вход LSP или выход LSP, специфицирует несколько (или все) LSR в LSP. Если один LSR специфицирует весь LSP, LSP является явно маршрутизированным. Если один LSR специфицирует только некоторые LSP, LSP является "неточно" маршрутизированным.

    Последовательность LSR, за которой следует явно маршрутизированные LSP, могут быть выбраны при конфигурации, или могут быть выбраны динамически одним узлом (например, выходной узел может использовать топологическую информацию, полученную из базы данных состояния канала, для того чтобы вычислить весь путь для дерева с корнем в выходном узле).

    Явная маршрутизация может быть полезной для ряда целей, таких как политика маршрутизации или управление трафиком (TE). В MPLS, явный маршрут должен быть специфицирован в момент формирования метки, но явный маршрут не должен быть специфицирован для каждого IP-пакета. Это делает явную маршрутизацию MPLS более эффективной, чем альтернативная IP-маршрутизация отправителя.

    Процедуры формирования явных маршрутов, точных или неточных, находятся за пределами данного документа.


    2.22. Отсутствие выходной метки

    Когда помеченный пакет транспортируется вдоль LSP, может так случится, что он достигнет LSR, в котором ILM не устанавливает соответствия между меткой входящего пакета и NHLFE, даже при условии, что сам пакет корректен. Это может случиться из-за переходных обстоятельств или по причине ошибки в LSR, который должен быть следующим шагом пакета.

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

    - Если пакет попадает в LSP маршрутизируемый явно, это может привести к образованию петель.

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

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


    2.23. Время жизни (TTL)

    При традиционной IP переадресации, каждый пакет имеет в заголовке значение поля "Time To Live" (TTL). Когда бы пакет ни проходил через маршрутизатор, его TTL уменьшается на 1. Если TTL достигает 0, прежде чем пакет достигнет места назначения, он отбрасывается.

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

    (i)     TTL как способ подавления зацикливания;

    (ii)    TTL как метод реализации других функций, таких как ограничение области распространения пакета.

    Когда пакет движется по LSP, он должен появляться с тем же значением TTL, которое он бы имел, если бы он проходил через ту же последовательность маршрутизаторов, без коммутации меток. Если пакет проходит через иерархию LSP, полное число пройденных шагов-LSR должно быть отражено в его значении TTL. Способ, которым обрабатывается поле TTL, может варьироваться в зависимости от того, размещены ли значения меток MPLS в прослойке между заголовками [MPLS-SHIM], или метки MPLS транспортируются в заголовке L2, таком как заголовок ATM [MPLS-ATM] или заголовок frame relay [MPLS-FRMRLY].

    Если значения меток вставлены в "прослойку", которая размещается между канальным и сетевым заголовками, тогда эта прослойка должна иметь поле TTL, которое должно заполняться также, как аналогичное поле заголовка сетевого уровня, декрементироваться при каждом шаге LSR, и копироваться в TTL-поле заголовка сетевого уровня, когда пакет выходит из его LSP.

    Если значения меток записаны в заголовке канального уровня (например, поле VPI/VCI в заголовке AAL5 ATM), а помеченные пакеты переадресуются переключателем уровня L2 (например, ATM-переключателем), а канальный уровень сам не имеет поля TTL, тогда будет невозможно декрементировать TTL при каждом шаге LSR. Сегмент LSP, который состоит из последовательности LSR, которые не способны декрементировать TTL пакетов, будет называться сегментом "non-TTL LSP".

    Когда пакет выходит из сегмента non-TTL LSP, он должен, однако получить TTL, отвечающее числу шагов LSR, которые он проходит. В уникастном случае, это может быть достигнуто путем транспортировки длины LSP входным узлам, позволяя входным устройствам декрементировать значение TTL, прежде чем переадресовывать пакеты в non-TTL LSP сегмент.

    Иногда это может быть определено на входе сегмента non-TTL LSP так, что соответствующее значение TTL пакета достигнет нуля, прежде чем пакет дойдет выхода сегмента non-TTL LSP. В этом случае, LSR на входе non-TTL LSP сегмента коммутировать пакеты по меткам. Это означает, что должны быть разработаны специальные процедуры для поддержки функциональности traceroute, например, пакеты traceroute могут переадресовываться по стандартной схеме шаг-за-шагом.


    2.24. Контроль петель

    В non-TTL LSP сегменте, по определению, TTL не может использоваться для предотвращения петель маршрута. Важность контроля циклических путей зависит от конкретного оборудования, используемого для реализации LSR-функций в пределах non-TTL LSP сегмента.

    Предположим, например, что для коммутационных целей в MPLS используются ATM-переключатели, с метками, транспортируемыми в поле VPI/VCI. Так как ATM коммутаторы не могут декрементировать TTL, здесь нет защиты против появления циклических маршрутов. Если оборудование ATM способно обеспечить хороший доступ к буферному пулу для входящих ячеек, имеющих разные значения полей VPI/VCI, петли не могут иметь негативного эффекта на остальной трафик. Если оборудование ATM не может обеспечить хороший доступ к буферам, тогда переходные петли могут вызвать серьезную деградацию эксплуатационных характеристик LSR.

    Даже если может быть обеспечен хороший доступ к буферу, целесообразно иметь некоторые средства детектирования петель, которые имеют длину больше определенной. Кроме того, даже когда TTL и/или справедливая организация очередей в виртуальных каналах предоставляет возможности для сохранения петель, может быть желательно, где возможно избегать установления LSP с петлями. Все LSR, которые могут быть связаны с сегментами non-TTL LSP будут должны поддерживать общую методику детектирования петель; однако, использование детектирования петель является опционным. Методика детектирования петель специфицирована в [MPLS-ATM] и [MPLS-LDP].


    2.25. Кодирование меток

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


    2.25.1. MPLS-специфичное оборудование и/или программное обеспечение

    Если для переадресации помеченных пакетов используется MPLS-специфичное оборудование и/или программы, наиболее очевидным способом представления стека меток является определение нового протокола, который будет использоваться в пределах прослойки между заголовками канального и сетевого уровней. Эта прокладка могла бы реально быть инкапсуляцией пакетов сетевого уровня. Она является протокольно независимой, такой, чтобы использоваться для инкапсуляции любого сетевого уровня. Следовательно, мы будем называть это как "общая MPLS-инкапсуляция".

    MPLS-инкапсуляция будет в свою очередь инкапсулирована с привлечением протокола канального уровня. Общая MPLS-инкапсуляция специфицирована в [MPLS-SHIM].


    2.25.2. ATM-коммутаторы в качестве LSR

    Процедуры переадресации MPLS подобны тем, что используются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (cross-connect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства "ATM-LSR". Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно использовать AAL5):

    1. SVC кодирование

    Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может использоваться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды "push" или "pop" для стека меток.

    2. SVP кодирование

    Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей, здесь возможно переключение виртуальных каналов с помощью ATM "VP-switching". То есть, LSP реализуются как ATM SVP.

    Однако эта методика не может использоваться всегда. Если сеть включает виртуальный маршрут ATM через ATM-сеть, не поддерживающую MPLS, тогда поле VPI необязательно доступно для использования в MPLS.

    Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию "pop".

    3. Многоточечное кодирование SVP

    Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, используется часть поля VCI, остальная часть поля VCI служит для идентификации входного LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Как это будет показано в разделе 2.26, это позволяет нам осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но которые не имеют возможностей объединения VC.

    Эта методика зависит от наличия возможности присвоения 16-битовых значений VCI каждому ATM-коммутатору, так что ни одно значение VCI не будет соответствовать двум разным коммутаторам.

    Если имеется больше меток в стеке, чем места в заголовке ATM, тогда ATM представление должно комбинироваться с общей инкапсуляцией.


    2.25.3. Совместимость методов кодирования

    Если <R1, R2, R3> является сегментом LSP, возможно, что R1 будет использовать одно представление стека меток при передачи пакета P в R2, но R2 будет использовать другое представление при передаче пакета P в R3. Вообще, архитектура MPLS поддерживает LSP с разным представлением стека меток на разных шагах маршрута. Следовательно, когда мы обсуждаем процедуры обработки помеченных пакетов, мы делаем это в терминологии взаимодействия со стеком меток. Когда приходит помеченный пакет, LSR должен декодировать его для определения текущего значения метки в стеке, затем должен преобразовать стек, чтобы определить новое значение метки перед отправкой пакета в следующий узел маршрута.

    К сожалению, ATM-коммутаторы не имеют возможности осуществлять преобразование из одного представления стека меток в другое. Архитектура MPLS, следовательно, требует чтобы, когда два ATM-коммутатора оказываются последовательными LSR на уровне m LSP для определенных пакетов, эти два ATM-коммутатора используют одно и то же представление стека меток.

    Естественно будут существовать MPLS сети, которые содержат комбинацию ATM-коммутаторов, работающих в качестве LSR, и других LSR, использующих MPLS заголовок-прокладку. В таких сетях могут быть некоторые LSR, имеющие ATM-интерфейсы а также интерфейсы "MPLS Shim" (прослойки). Это лишь один пример LSR с различным представлением стека меток. Такие LSR могут осуществлять подмену структур стека меток из представления ATM на входном интерфейсе в MPLS формат стека на выходном.


    2.26. Объединение меток

    Предположим, что LSR связал несколько входящих меток с конкретным FEC. При переадресации пакетов в этом FEC, хотелось бы иметь одну выходную метку, которая используется всеми такими пакетами. Тот факт, что два разных пакета класса FEC приходят с разными входными метками является нерелевантным. Хотелось бы переадресовывать их с одной и той же выходной меткой. Реализация этого называется "объединением меток". Будем говорить, что LSR способен объединять метки, если он может получать два пакета от разных входных интерфейсов, и/или с разными метками, а посылать оба пакета с одной и той же выходной меткой. Раз пакеты переданы, информация о том, что они пришли от разных интерфейсов и/или с разными входными метками теряется.

    Будем считать, что LSR не способен объединять метки, если для любых двух пакетов, которые приходят из разных интерфейсов, или с разными метками, пакеты должны быть либо переданы через разные интерфейсы, или должны иметь разные выходные метки. ATM-LSR, использующие SVC или SVP представления, не могут реализовывать объединение меток.

    Если некоторый LSR не может выполнить объединение меток, тогда, если два пакета в одном и том же FEC приходят с разными входными метками, они должны быть переадресованы с разными выходными метками. При объединении меток, число выходных меток на один FEC должно быть равно 1. Без объединения меток, число выходных меток на один FEC может равняться числу узлов в сети.

    При объединении меток число входящих меток на FEC, которое необходимо конкретному LSR, никогда не превосходит числа смежных дистрибьюторов. В отсутствии объединения меток, число входящих меток на один FEC, которое необходимо конкретному LSR, достигает числа вышестоящих узлов, которые переадресуют трафик FEC данному LSR. В действительности, для LSR трудно даже определить, сколько входящих меток он должен поддерживать для конкретного FEC.

    Архитектура MPLS приспосабливает как объединяющие, так не объединяющие LSR, но допускает также возможность того, что имеются LSR, не поддерживающие коммутацию меток.


    2.26.1. Необъединяющие LSR

    Процедура переадресации MPLS очень схожа с используемой в ATM и Frame Relay. То есть, приходит блок данных, ищется метка в коммутационной таблице (VPI/VCI или DLCI), на основе результата поиска выбирается выходной порт, а значение метки переписывается. В действительности, можно использовать такие технологии для переадресации MPLS. Протокол рассылки меток может быть использован в качестве сигнального протокола для формирования коммутационных таблиц. К сожалению, эти технологии необязательно поддерживают возможности объединения меток. В ATM, если попытаться осуществить объединение меток, в результате можно получить перекрытие ячеек от различных пакетов. Если ячейки от разных пакетов оказываются перекрытыми, невозможно осуществить сборку пакетов. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на своих внутренних шинах (backplane). Эти коммутаторы могут также быть неспособными поддерживать объединение меток, по той же причине - ячейки разных пакетов могут перекрываться, и сборка исходных пакетов станет невозможной.

    Мы предлагаем поддержать два решения этой проблемы. Первое, MPLS будет поддерживать процедуры, которые позволяют определенным ATM-коммутаторам функционировать как LSR, способные объединять метки.

    Так как MPLS поддерживает объединяющие и необъединяющие LSR, MPLS содержит также процедуры, которые гарантируют корректное взаимодействие такого оборудования и программ.


    2.26.2. Метки для объединяющих и необъединяющих LSR

    Вышестоящий LSR, который поддерживает объединение меток, должен посылать только одну метку на FEC. Вышестоящий сосед, который не поддерживает объединение меток, должен посылать несколько меток на один FEC. Однако не существует метода узнать заранее, сколько нужно меток. Это будет зависеть оттого, сколько имеется вышестоящих LSR для оговоренного FEC.

    В архитектуре MPLS, если определенный вышестоящий сосед не поддерживает объединение меток, ему не посылаются какие-либо метки для заданного FEC, если только он напрямую не запрашивает метку для данного FEC. Вышестоящий сосед может сделать несколько таких запросов, и получать каждый раз новую метку. Когда нижестоящий сосед получает такой запрос "сверху", а сам он не поддерживает объединения меток, тогда он должен в свою очередь запросить у своего нижестоящего соседа новую метку для заданного FEC.

    Возможно, что существуют какие-то узлы, которые поддерживают объединение меток, но могут объединить лишь ограниченное число входящих меток в одну исходящую. Предположим, например, что из-за некоторых аппаратных ограничений узел может объединить четыре входящие метки в одну исходящую. Предположим, что этот конкретный узел получил шесть меток, пришедших для данного FEC. В этом случае этот узел может объединить их в две исходящие метки.


    2.26.3. Объединение потоков в ATM
    2.26.3.1. Методы исключения перекрытия ячеек

    Существует несколько методов исключения проблемы перекрытия ячеек в ATM, таким образом, позволяющих ATM-коммутатором поддерживать объединение потоков данных:

    1. Объединение VP, использующее мультиточечное представление SVP

    Когда используется объединение VP, несколько виртуальных путей объединяются в один путь, но пакеты от разных отправителей отличаются разными VCI в пределах данного VP.

    2. Объединение VC

    Когда используется объединение VC, коммутаторы должны буферизовать ячейки от пакетов до тех пор, пока не будет принят весь пакет (это может быть определено путем просмотра индикатора конца кадра для AAL5).

    Объединение VP имеет преимущество в том, что оно совместимо с подавляющим числом реализаций ATM-коммутаторов. Это делает более вероятным то, что объединение VP может использоваться в существующих сетях. В отличие от объединения VC, объединение VP не приводит к каким-либо задержкам в точках объединения, а также не накладывает никаких требований на буферы. Однако это имеет недостаток, так как требует координации пространства VCI в пределах VP. Существует несколько способов реализации этого.

    Этот компромисс между совместимостью с существующим оборудованием, сложностью протокола и масштабируемостью предполагает, что желательна поддержка протоколом MPLS объединения как VP, так и VC. Для того чтобы реализовать это каждый ATM-коммутатор, участвующий в MPLS, должен знать, могут ли ближайшие ATM соседи осуществлять объединение VP или VC.


    2.26.3.2. Взаимодействие: объединение VC, объединение VP, и отсутствие объединения

    Взаимодействие различных форм объединения в ATM наиболее просто описать на примере взаимодействия систем с объединением VC и без.

    В случае, когда соединены узлы, поддерживающие и не поддерживающие объединение VC, переадресация ячеек базируется во всех вариантах на VC (т.e., на соединении VPI и VCI). Для каждого вышестоящего узла, осуществляющего объединение VC, нужен только один набор VPI/VCI (это сходно с требованиями для одиночной метки в случае работы в среде кадров (frame media)). Если вышестоящий сосед не может осуществлять объединение, тогда он будет требовать одного VPI/VCI на поток для себя, плюс достаточное число VPI/VCI, чтобы осуществить передачу вышестоящему соседу. Необходимое число будет определено путем разрешения вышестоящим узлам посылать запросы дополнительных VPI/VCI от своих нижестоящих соседей (это аналогично методике объединения, используемой для кадров).

    Аналогично можно поддержать узлы, которые выполняют объединение VP. В этом случае объединяющий VP узел, вместо посылки запроса одного или нескольких VPI/VCI от нижестоящего соседа, может запросить один VP (идентифицируемого посредством VPI), но несколько VCI в пределах VP. Кроме того, предположим, что узел, не поддерживающий объединение ниже расположен по отношению к двум другим узлам, объединяющим VP. Этот узел может нуждаться в запросе одного VPI/VCI (для трафика, исходящего именно из этого узла) плюс два VP (по одному для каждого вышестоящего узла), ассоциированные со специфицированными наборами VCI (в соответствии с запросом от вышестоящего узла).

    Для того чтобы поддерживать узлы, объединяющие и не объединяющие VP и VC, необходимо разрешить вышестоящим узлам запрашивать комбинацию из нуля или более идентификаторов VC (состоящих из VPI/VCI), плюс нуль или более VP (идентифицируемых VPI), каждый из которых содержит специфицированное число VC (идентифицированное набором VCI, которые работают в пределах VP). Узлы, объединяющие VP, затребовали бы один VP, содержащий VCI для исходящего трафика (если таковой имеется) плюс VCI для каждого VC, запрошенного свыше (вне зависимости оттого, является или нет VC частью, содержащей VP). Узлы, объединяющие VC, затребовали бы только один VPI/VCI (так как они могут объединить весь трафик от вышестоящих узлов в один VC). Узлы, не поддерживающие объединение, передали бы любые запросы, полученные сверху, плюс запрос VPI/VCI для трафика, генерируемого ими самими (если таковой имеется).


    2.27. Туннели и иерархия

    Иногда маршрутизатор Ru предпринимает действия, чтобы доставить определенный пакет другому маршрутизатору Rd, даже если Ru и Rd не являются смежными углами на пути пакета, а Rd не является местом назначения пакета. Это может быть сделано, например, путем инкапсуляции пакета в пакет сетевого уровня, местом назначения которого является Rd. Это создает туннель от Ru к Rd .


    2.27.1. Туннель, маршрутизированный шаг-за-шагом

    Если туннелированный пакет следует маршрутом шаг-за-шагом от Ru к Rd , мы говорим, что это "туннель, маршрутизированный шаг-за-шагом", чье начало находится в Ru и чей конец в Rd.


    2.27.2. Туннель, маршрутизированный явно

    Если туннелированный пакет транспортируется из Ru в Rd по пути, отличному от маршрута шаг-за-шагом, мы говорим, что это "Туннель, маршрутизированный явно" с начальной точкой в Ru и конечной - в Rd. Например, мы можем послать пакет через туннель, маршрутизированный явно путем инкапсуляции его в пакет, маршрутизируемый отправителем.


    2.27.3. Туннели LSP

    Имеется возможность реализовать туннель в виде LSP и использовать коммутацию меток, а не инкапсуляцию сетевого уровня, чтобы заставить пакет идти через туннель. Туннель будет иметь вид LSP <R1, ..., Rn >, где R1 является началом туннеля, а Rn - концом туннеля. Это называется " LSP-туннелем".

    Набор пакетов, которые посланы через LSP-туннель, представляет собой FEC, а каждый LSR в туннеле должен установить ассоциацию между меткой и FEC (т.e., нужно присвоить туннелю определенную метку). Критерий установления соответствия пакета LSP-туннелю является внутренним вопросом начальной точки туннеля. Чтобы направить пакет в LSP-туннель, передающий конец туннеля вводит метку туннеля в стек и посылает помеченный пакет узлу следующего шага туннеля.

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

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


    2.27.4. Иерархия: LSP туннели в LSP

    Рассмотрим LSP <R1, R2, R3, R4>. Предположим, что R1 получил непомеченный пакет P, и заносит метку в его стек, чтобы пакет следовал заданным путем (путь шаг-за-шагом). Предположим далее, что R2 и R3 не являются непосредственно связанными, но они являются виртуальными соседями, так как представляют собой конечные точки LSP-туннеля. Итак, действительная последовательность LSR, через которые проходит P, соответствует <R1, R2, R21, R22, R23, R3, R4>. Когда P транспортируется из R1 в R2, он имеет глубину стека равную 1. R2, коммутирующий метки, определяет, что P должен войти в туннель. R2 сначала замещает входную метку меткой, имеющей смысл для R3. Затем он заносит метку в стек. Эта метка второго уровня имеет значение, понятное R21. Коммутация осуществляется для метки на уровне 2 устройствами R21, R22, R23. R23, который является предпоследним узлом в туннеле R2-R3, удаляет метку из стека до того, как будет выполнена переадресация пакета в R3. Когда R3 видит пакет P, P имеет только метку уровня 1, и покидает туннель. Так как R3 является предпоследним шагом P в LSP, он удаляет метку из стека, а R4 получает P непомеченным. Механизм стека меток допускает любую глубину вложения LSP-туннелей.


    2.27.5. Иерархия и партнерство в рассылке меток

    Предположим, что пакет P транспортируется на уровне 1 LSP <R1, R 2, R3, R4>, и при транспортировке из R2 в R3 движется по LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделах 3.6 и 3.7 рассмотрены некоторые способы реализации этой иерархии. Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются.

    Когда два LSR являются соседними IGP, мы называем их "локальными партнерам рассылки меток". Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их "удаленными партнерами распределения меток". В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток.

    Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering).

    Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это возможно одним из двух путей:

    1. Явное партнерство

    При явном партнерстве, метки пересылаются партнеру в протокольных сообщениях так же, как это делается при локальном обмене. Эта методика наиболее полезна, когда число удаленных партнеров мало, или число ассоциаций высокого уровня велико, или удаленные партнеры обмена метками размещены в удаленных областях или доменах. Конечно, может быть нужно знать, какие метки следует послать какому партнеру; это рассмотрено в разделе 3.1.2. Примеры использования явного партнерства представлены в разделе 3.2.1 и 3.6.

    2. Неявное партнерство

    При неявном партнерстве, протокольные сообщения рассылки меток, адресованные одному партнеру, не посылаются. Скорее, чтобы разослать метки высокого уровня удаленным партнерам, метка представляется в виде атрибута метки более низкого уровня, а затем производится рассылка метки низкого уровня вместе с этим атрибутом местным партнерам. Локальные партнеры обмена метками рассылают полученные данные дальше. Этот процесс продолжается до тех пор, пока информация не достигнет удаленных партнеров.

    Эта техника наиболее полезна, когда число удаленных партнеров обмена метками велико. Неявное партнерство не требует сетки партнеров n-квадрат, чтобы разослать метки удаленным партнерам, так как имеется подстраховка за счет локального обмена информацией. Однако неявное партнерство требует, чтобы промежуточные узлы запоминали информацию, в которой они могут быть заинтересованы. Пример использования неявного партнерства можно найти в разделе 3.3.


    2.28. Транспортировка протокольных сообщений рассылки меток

    Протокол рассылки меток используется между узлами в сети MPLS для установления и поддержания привязки меток. Для того чтобы MPLS работал корректно, информация, сопряженная с рассылкой меток, должна рассылаться совершенно надежно, а протокольные сообщения рассылки меток, имеющие отношение к определенному FEC, должны посылаться в определенном порядке. Управление потоком также желательно, так как имеется возможность транспортировки нескольких сообщений с метками в одной дейтограмме.

    Одним из способов достижения цели является использование TCP в качестве базового транспортного протокола, как это делается в [MPLS-LDP] и [MPLS-BGP].


    2.29. Зачем нужно более одного протокола рассылки меток?

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


    2.29.1. BGP и LDP

    Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1).

    Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами.


    2.29.2. Метки для RSVP Flowspecs

    Когда используется RSVP при резервировании ресурсов для конкретных потоков, может быть желательно, помечать пакеты в этих потоках, так что не нужно будет использовать RSVP filterspec в каждом из узлов . Можно обосновать, что осуществление рассылки меток в рамках RSVP в качестве части процесса формирования пути, и резервирования ресурсов является наиболее эффективным методом решения проблемы.


    2.29.3. Метки для явно маршрутизируемых LSP

    В некоторых приложениях MPLS, в частности сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода:

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

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

    Первый подход реализован в протоколе, описанном в [MPLS -RSVP-TUNNELS], второй - специфицирован в [MPLS-CR-LDP].


    3. Некоторые применения MPLS

    3.1. MPLS и трафик, маршрутизируемый шаг-за-шагом

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


    3.1.1. Метки для адресных префиксов

    Вообще, маршрутизатор R определяет следующий шаг для пакета P путем нахождения подходящего адресного префикса X в своей маршрутной таблице. То есть, пакеты в данном FEC - это пакеты, которые соответствуют заданному адресному префиксу в маршрутной таблице R. В этом случае, FEC может быть идентифицирован адресным префиксом.

    Заметим, что пакет P может быть приписан к FEC F, а FEC F может быть идентифицирован адресным префиксом X, даже если адрес места назначения P не согласуется с X.


    3.1.2. Рассылка меток для адресных префиксов

    3.1.2.1. Партнеры рассылки меток для адресного префикса

    LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий:

    1. Маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP.

    2. Маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2.

    3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля, R1 и R2 являются клиентами IGP, и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP, или в результате рассылки R1 данному IGP.

    4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1.

    Вообще, эти правила гарантируют то, что, если маршрут до определенного адресного префикса рассылается через IGP, партнеры рассылки меток для данного адресного префикса являются IGP-соседями. Если маршрут определенного адресного префикса рассылается через BGP, партнеры рассылки меток для данного адресного префикса являются BGP партнерами. В других случаях LSP-туннелирования конечные точки туннеля являются партнерами по рассылке меток.


    3.1.2.2. Рассылаемые метки

    Для того чтобы использовать MPLS для переадресации пакетов согласно маршруту шаг-за-шагом, соответствующему какому-либо адресному префиксу, каждый LSR должен:

    1. Связать один или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице.

    2. Для каждого такого адресного префикса X, использовать протокол рассылки меток для уведомления партнеров (в рамках Х) о существовании ассоциации метки с данным префиксом.

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

    3. Если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут.

    Эти правила гарантируют, что метки, ассоциированные с адресным префиксам, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам.

    Эти правила имею целью указать, какие ассоциации меток должны рассылаться данным LSR другим LSR.


    3.1.3. Использование маршрутов шаг-за-шагом в качестве LSP

    Если путь шаг-за-шагом, которому пакет P должен следовать, характеризуется <R1, ..., Rn >, тогда < R1, ..., Rn> может быть LSP до тех пор пока:

    1. Существует один адресный префикс X , такой, что для всех i, 1<=i<n , X является наилучшим соответствием в маршрутной таблице Ri для адреса места назначения P ;

    2. Для всех i, 1<i <n, Ri установил соответствие метки и X и разослал эту метку всем R[i-1].

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

    Предположим, например, что пакет P, с адресом места назначения 10.2.153.178 должен двигаться от R1 к R2 и далее к R3. Предположим также, что R2 анонсирует адресный префикс 10.2/16 для R1, но R3 анонсирует 10.2.153/23, 10.2.154/23 и 10.2/16 до R2. То есть, R2 анонсирует "агрегатный маршрут" для R1. В этой ситуации, пакет P может быть коммутируемым по метке до тех пор, пока он не достигнет R2, но так как R2 осуществил агрегатирование маршрутов, он должен запустит алгоритм поиска наилучшего соответствия, чтобы найти FEC для P.


    3.1.4. Конец LSP и прокси конец LSP

    LSR R считается конечным LSR LSP для адресного префикса X, если и только если выполнено одно из следующих условий:

    1. R имеет адрес Y, такой что X является адресным префиксом в маршрутной таблице R, который наилучшим образом соответствует Y, или

    2. R содержит в своей маршрутной таблице один или более адресных префиксов Y, таких что X является подходящей начальной субстрокой Y, но "предыдущие шаги LSP" R для X не содержат никакого адресного префикса Y. То есть, R является "точкой ликвидации агрегатирования" для адресного префикса X .

    LSR R1 считается "прокси концом LSP" LSR для адресного префикса X, если и только если:

    1. Следующим шагом R1 для X служит R 2, а R1 и R2 не являются партнерами по рассылке меток с точки зрения X (возможно потому, что R2 не поддерживает MPLS), или

    2. R1 был сконфигурирован, чтобы работать в качестве прокси конца LSP для X

    Определение LSP позволяет концу LSP быть узлом, который не поддерживает MPLS. В этом случае предпоследний узел в LSP является прокси выходным.


    3.1.5. Неявная метка NULL

    Неявная метка NULL представляет собой метку со специальной семантикой, которую LSR может связать с адресным префиксом. Если LSR Ru после получения справки в ILM видит, что помеченный пакет P должен быть переадресован следующему Rd, но что Rd разослал ассоциацию неявной метки NULL с соответствующим адресным префиксом, тогда вместо того, чтобы заменить значение метки на вершине стека, Ru опустошает стек меток, а затем переадресует полученный пакет в Rd.

    LSR Rd рассылает ассоциацию неявной метки NULL и адресного префикса X в LSR Ru, если и только если:

    1. Правила раздела 3.1.2 указывают, что Rd посылает Ru ассоциацию метки для X, и

    2. Rd знает, что Ru может поддерживать неявные метки NULL (т.e., что он может очистить стек меток), и

    3. Rd является концом LSP (а не прокси концом) для X.

    Это заставляет предпоследний LSR на LSP очистить стек меток. Это вполне приемлемо, если конец LSP является концом MPLS для X, далее если предпоследний LSR не очистит стек меток, конечный узел LSP будет должен просмотреть метку, извлечь метку из стека, и затем посмотреть следующую метку (или просмотреть адрес L3, если меток больше нет). При выполнении предпоследним LSR команды pop для стека меток, конец LSP избавляется от необходимости просмотра двух меток, для того чтобы принять свое решение переадресации.

    Однако если предпоследним LSR является ATM-коммутатор, он может не иметь возможности выполнить команду pop для стека меток. Следовательно, может быть послана ассоциация неявной метки в LSR, который может поддерживать эту функцию.

    Если предпоследний LSR в LSP для адресного префикса X является прокси концом LSP, он действует, как если бы конец LSP разослал ассоциацию неявной метки NULL для X.


    3.1.6. Опция: присвоение метки Egress Targeted

    Существуют ситуации, в которых начало LSP Ri, знает, что пакеты нескольких разных FEC должны следовать одним и тем же LSP, завершающимся, скажем, конечным Re. В этом случае, корректная маршрутизация может быть реализована использованием одной метки для всех таких FEC, необязательно иметь отличающиеся метки для каждого FEC. Если и только если выполняются следующие условия:

    1. Адрес LSR Re сам находится в маршрутной таблице (host route), и

    2. Существует некоторый способ для Ri определить, что Re является концом LSP для всех пакетов в конкретном наборе FEC.

    Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется "Egress-Targeted Label Assignment".

    Как может LSR Ri определить, что LSR Re является концом LSP для всех пакетов в конкретном FEC? Существует несколько возможных путей:

    - Если сеть реализует алгоритм маршрутизации состояния канала, а все узлы в области поддерживают MPLS, тогда алгоритм маршрутизации предоставляет Ri достаточно информации, чтобы определить маршрутизаторы, через которые пакеты в данном FEC должны покинуть домен маршрутизации или область.

    - Если сеть реализует BGP, Ri может определить, какие пакеты в заданном FEC должны покинуть сеть через некоторый конкретный маршрутизатор, который является "BGP Next Hop" для этого FEC.

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

    Если используется присвоение меток egress-targeted, число меток, которые необходимо поддерживать во всей сети может быть сокращено. Это может быть важно, если используется аппаратные переключатели для реализации MPLS, а коммутирующее оборудование может поддерживать ограниченное число меток.

    Возможным подходом могло бы быть конфигурирование сети для использования присвоения меток egress-targeted по умолчанию, но при конфигурации конкретных LSR не использовать присвоения меток egress-targeted для одного или более адресных префиксов, для которых он является концом LSP. Мы вводим следующее правило:

    - Если какой-то LSR не является концом LSP для некоторого набора адресных префиксов, тогда он должен присваивать метки адресным префиксам так же, как это делается узлом следующего шага LSP для этих адресных префиксов. То есть, предположим, Rd является маршрутизатором следующего шага (Ru) LSP для адресного префикса X1 и X2. Если Rd приписывает ту же метку X1 и X2, Ru должен сделать то же самое. Если Rd присваивает разные метки X1 и X2, тогда и Ru должен это сделать.

    Например, предположим, что хочется осуществить присвоение метки egress-targeted по умолчанию, но присвоить разные метки тем адресным префиксам, для которых существует несколько возможных концов LSP (т.e., для тех адресных префиксов, которые являются multi-homed). Можно сконфигурировать все LSR для использования присвоения меток egress-targeted, и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multi-homed. Для конкретного адресного префикса multi-homed X, было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X.

    Важно заметить, что если Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной.

    Аналогично, если Rd присваивает разные метки X1 и X2, но Ru присваивает им обоим метку, соответствующую адресу их конца LSP или прокси конца, переадресация будет, тем не менее, осуществляться корректно. Ru будет лишь устанавливать соответствие между входной меткой и меткой, которую сформировал Rd для адреса конца LSP .


    3.2. MPLS и LSP, маршрутизируемые явно

    Существует несколько причин, почему желательно использовать явную маршрутизацию, а не схему шаг-за-шагом. Например, это позволяет маршрутам основываться на административной политике, допускать маршруты, которые формируют LSP согласно соображения управления трафиком [MPLS-TRFENG].


    3.2.1. LSP-туннели, маршрутизируемые явно

    В некоторых ситуациях сетевые администраторы могут захотеть переадресовывать определенные классы трафика по определенным специфицированным заранее маршрутам, где эти пути отличаются от маршрутов шаг-за-шагом, по которым шел трафик первоначально. Это может быть сделано для поддержки политики маршрутизации, или для управления трафиком (ТЕ). Явный маршрут может быть сконфигурирован, или он может быть определен динамически посредством, например, маршрутизации на основе ограничений.

    MPLS позволяет выполнить это легко посредством LSP-туннелей, маршрутизированных явно. Для этого необходимо:

    1. Средства отбора пакетов, которые должны быть посланы в LSP-туннель, маршрутизированный явно;
    2. Средства формирования маршрутизированного явно LSP-туннеля;
    3. Средства, гарантирующие, что пакеты, посланные в туннель, не будут переадресованы принимающей стороной туннеля в направлении передающей стороны (отсутствие петель).

    Если передающий конец туннеля хочет поместить помеченный пакет в туннель, он должен сначала заменить метку на вершине стека меткой, присланной принимающей стороной туннеля. Затем он должен ввести в стек метку, которая соответствует самому туннелю и прислана маршрутизатором следующего шага в туннеле. Чтобы разрешить это, концы туннеля должны быть явными партнерами по обмену метками. Ассоциации меток, которыми они должны обменяться не представляют интереса для LSR в туннеле.


    3.3. Стеки меток и неявное партнерство

    Предположим конкретный LSR Re является прокси концом LSP для 10 адресных префиксов, и он имеет доступ к каждому адресному префиксу через отдельный интерфейс.

    Можно было бы присвоить одну метку всем 10 адресным префиксам. Тогда Re будет концом LSP для всех этих префиксов. Это гарантирует, что пакеты для всех 10 адресных префиксов будут доставлены Re. Однако Re был бы должен просматривать сетевой адрес каждого такого пакета, для того чтобы правильно выбрать интерфейс, через который его следует послать.

    В качестве альтернативы, можно было бы присвоить разные метки для каждого из интерфейсов. Тогда Re будет прокси концом LSP для 10 адресных префиксов. Это исключает необходимость для Re просматривать сетевые адреса пакетов, чтобы переадресовывать пакеты. Однако это может привести к использованию слишком большого числа меток.

    Альтернативой может быть объединение всех 10 адресных префиксов вокруг одной общей метки уровня 1 (которая ассоциирована также с адресом самого LSR), после чего можно связать каждый адресный префикс с отдельной меткой уровня 2. Метка уровня 2 будет рассматриваться как атрибут ассоциации метки уровня 1, который мы будем называть "атрибутом стека". Мы вводим следующие правила:

    - Когда LSR Ru помечает ранее непомеченные пакеты, если наилучшим соответствием адресу места назначения пакета равно X, а следующим шагом Ru LSP для X является Rd, и Rd послал Ru ассоциацию метки L1 и X, наряду с атрибутом стека L2, тогда

    1. Ru должен занести в стек меток L2, а затем L1, а после этого переадресовать пакет Rd;

    2. Когда Ru посылает ассоциацию метки для X своим партнерам по рассылке меток, он должен включить L2 в качестве атрибута стека.

    3. Когда бы атрибут стека изменился (возможно в результате изменения следующего шага Ru LSP для X), Ru должен разослать новый атрибут стека.

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

    Таким образом, прокси конец LSP для X становится "неявным партнером" каждого прочего LSR в области или домене маршрутизации. В этом случае, явное партнерство было бы слишком тяжеловесным, так как число партнеров стало бы слишком большим.


    3.4. MPLS и маршрутизация при нескольких путях

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

    Если специфицировано несколько ассоциаций меток для заданного адресного префикса, они могут иметь разные атрибуты.


    3.5. Деревья LSP как объекты мультиточка-точка

    Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой <R1, R2, R3>, а путем шаг-за-шагом для P2 является <R4, R2, R3>. Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3, и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3, и пошлет P2 в R3.

    Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и с точки зрения MPLS, они не различимы. Таким образом, вместо того чтобы говорить о двух разных LSP, <R1, R2, R3> и <R4, R2, R3>, мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.

    Это создает трудности, когда мы пытаемся использовать обычные ATM-коммутаторы в качестве LSR. Так как обычные ATM-коммутаторы не поддерживают соединения мультиточка-точка, должны существовать процедуры, гарантирующие, чтобы каждый LSP реализовал VC по схеме точка-точка. Однако если используются ATM-коммутаторы, которые поддерживают VC мультиточка-точка, тогда LSP может быть реализован эффективно по такой схеме. Альтернативой может служить ситуация, когда можно использовать многоточечное представление SVP (раздел 2.25.2), LSP может быть реализован как SVP мультиточка-точка.


    3.6. LSP-туннелирование между пограничными BGP маршрутизаторами

    Рассмотрим случай автономной системы A, которая пропускает трафик между другими автономными системами. Автономная система A будет иметь несколько пограничных маршрутизаторов BGP, и сеть BGP соединений между ними, через которые пересылаются BGP маршруты. Во многих таких случаях желательно избежать рассылки BGP-маршрутов маршрутизаторам, которые не являются пограничными. Если этого можно избежать, нагрузка по рассылке маршрутов этих маршрутизаторов существенно сокращается. Однако должны быть некоторые средства, гарантирующие, что транзитный трафик будет доставляться от одного BGP-маршрутизатора к другому с помощью внутренних маршрутизаторов.

    Это может быть легко сделано с помощью туннелей LSP. Предположим, что BGP маршруты рассылаются только пограничным BGP-маршрутизаторам, а не внутренними маршрутизаторами, которые расположены по пути. LSP-туннели могут использоваться следующим образом:

    1. Каждый пограничный маршрутизатор BGP посылает каждому другому пограничному маршрутизатору BGP в пределах автономной системы метку для каждого адресного префикса, которую он пересылает в рамках протокола BGP.

    2. IGP для автономной системы поддерживает маршрут для каждого BGP-маршрутизатора. Каждый внутренний маршрутизатор рассылает свои метки для этих маршрутов каждому своему IGP-соседу.

    3. Предположим, что:

    a) Пограничный маршрутизатор BGP B1 получает непомеченный пакет P.

    b) Адресный префикс X в маршрутной таблице B1 является наилучшим соответствием для адреса места назначения пакета P.

    c) Маршрут до X является маршрутом BGP.

    d) Следующим шагом BGP для X является B2.

    e) B2 имеет ассоциацию метки L1 и X, и посылает эту ассоциацию в B1.

    f) Следующий шаг IGP для адреса B2 является I1.

    g) Адрес B2 содержится в маршрутных таблицах B1 и I1 IGP, а

    h) I1 связывает метку L2 с адресом B2 и посылает эту ассоциацию B1.

    Далее прежде чем послать пакет P в I1, B 1 должен сформировать стек меток для P, затем заносит туда метку L1, а на верх стека записывает L2.

    4. Предположим, что пограничный BGP маршрутизатор B1 получает помеченный пакет P, где на верху стека размещена метка, соответствующая адресному префиксу X маршрута, и что условия 3b, 3c, 3d и 3e все выполнены. Тогда прежде чем посылать пакет P в I1, B1 должен заменить метку на верху стека на метку L1, и затем записать в стек метку L2.

    Эти процедуры эффективно формируют LSP-туннель, маршрутизированный шаг-за-шагом, между пограничными маршрутизаторами BGP.

    Так как пограничные BGP-маршрутизаторы обмениваются ассоциациями меток для адресных префиксов, которые неизвестны IGP, маршрутизаторы BGP должны стать партнерами по явному обмену метками.

    Иногда можно сформировать LSP-туннель, маршрутизированный шаг-за-шагом, между двумя пограничными маршрутизаторами BGP, даже если они не принадлежат общей автономной системе. Предположим, например, что B1 и B2 находятся в AS1. Предположим также, что B3 является EBGP-соседом B2, и находится в AS2. Наконец, предположим, что B2 и B3 находятся в некоторой сети, которая является общей для обеих автономных систем ("демилитаризованная зона"). В этом случае LSP-туннель может быть сформирован непосредственно между B1 и B3 следующим образом:

            B3 посылает маршруты B2 (используя EBGP), опционно присваивая метки адресным префиксам;

            B2 перераспределяет маршруты к B1 (используя IBGP), указывая, что следующим шагом BGP для каждого такого маршрута является B3. Если B3 присвоил метки адресным префиксам, B2 передает эти метки далее без изменений вплоть до B1.

            IGP автономной системы AS1 имеет host route для B3.


    3.7. Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом

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

    Если начальный узел туннеля намеревается направить помеченный пакет в туннель, он должен сначала заменить значение метки в стеке на значение, полученное от узла конца туннеля. Затем он должен занести в стек метку, которая соответствует самому туннелю. Чтобы разрешить это, конечные точки туннеля должны быть явными партнерами обмена метками. Ассоциации меток, которыми они должны обмениваться не играют никакой роли для LSR в пределах туннеля.


    3.8. MPLS и мультикастинг

    Мультикастная маршрутизация осуществляется путем формирования мультикаст-деревьев. Дерево, вдоль которого должен переадресовываться конкретный мультикаст пакет, зависит от адресов отправителя и получателя пакета. Когда конкретный LSR является узлом некоторого мультикаст-дерева, он связывает метку с этим деревом. Он рассылает эту ассоциацию вдоль данного дерева. Если рассматриваемый узел принадлежит локальной сети, и имеет партнеров в этой сети, он должен также рассылать указанные ассоциации своим партнерам. Это позволяет вышестоящим узлам использовать одну метку, когда осуществляется мультикатинг для всех нижестоящих объектов LAN.

    Когда приходит помеченный мультикастный пакет, NHLFE , соответствующий метке, указывает на набор выходных интерфейсов для данного пакета, а также на выходную метку. Если используется один и тот же формат представления метки для всех выходных интерфейсов, один и тот же пакет может быть послан всем нижестоящим объектам.


    4. Процедуры пересылки меток (Hop-by-Hop)

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


    4.1. Процедуры анонсирования и использования меток

    Существует некоторое число различных процедур, которые могут использоваться для рассылки ассоциаций меток. Некоторые исполняются нижестоящим LSR, а некоторые вышестоящим LSR. Нижестоящий LSR должен выполнить:

    - Процедуру рассылки и
    - Процедуру отзыва.


    Вышестоящий LSR должен выполнить:
    - Процедуру Request и
    - Процедуру NotAvailable и
    - Процедуру Release и
    - Процедуру labelUse.

    Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов. Набор поддерживаемых комбинаций будет обсужден в разделе 4.2, где рассматривается совместимость различных комбинаций.


    4.1.1. Нижестоящий LSR: Процедура рассылки

    Процедура рассылки используется нижестоящим LSR, чтобы определить, когда он должен разослать своим партнерам ассоциации меток для конкретного адресного префикса. Архитектура поддерживает четыре разные процедуры рассылки.

    Вне зависимости от используемой процедуры рассылки, если ассоциация метки для заданного адресного префикса была послана нижестоящим LSR Rd вышестоящему LSR Ru, и, если в какой-то момент атрибуты ассоциации (как это определено выше) изменились, тогда Rd должен проинформировать Ru о новых атрибутах.

    Если LSR поддерживает несколько маршрутов для заданного адресного префикса, то будет ли LSR ассоциировать несколько меток данному адресному префиксу (один на маршрут), и, следовательно, рассылать несколько ассоциаций, является исключительно локальной проблемой


    4.1.1.1. PushUnconditional

    Пусть Rd является LSR. Предположим, что:

    1. X является адресным префиксом в маршрутной таблице Rd

    2. Ru является партнером по рассылке меток Rd с точки зрения X

    Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd.

    Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.


    4.1.1.2. PushConditional

    Пусть Rd является LSR. Предположим, что:

    1. X является адресным префиксом в маршрутной таблице Rd

    2. Ru является партнером Rd по рассылке меток с учетом X

    3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd.

    Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.

    Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3.

    Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP.


    4.1.1.3. PulledUnconditional

    Пусть Rd является LSR. Предположим, что:

    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером Rd по рассылке меток с учетом X

    3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru

    Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию.

    Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе.

    Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP.


    4.1.1.4. PulledConditional

    Пусть Rd является LSR. Предположим, что:

    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером Rd по рассылке меток с учетом X
    3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
    4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd

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

    Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.

    Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.

    В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.


    4.1.2. Вышестоящий LSR: процедура запроса

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


    4.1.2.1. RequestNever

    Никогда не делай запросов. Эта процедура полезна, если нижестоящий LSR использует процедуры PushConditional или PushUnconditional, но она бесполезна, если нижестоящий LSR использует процедуры PulledUnconditional или PulledConditional.

    Эта процедура будет использоваться LSR, когда применена не запрошенная рассылка меток и свободный режим удержания меток.


    4.1.2.2. RequestWhenNeeded

    Осуществляет запрос всякий раз, когда меняется соотношение между следующим шагом L3 и адресным префиксом, или когда прислан новый адресный префикс, и нет уже ассоциации метки от следующего шага для заданного адресного префикса.

    Эту процедуру следует использовать LSR, когда применен консервативный режим удержания меток.


    4.1.2.3. RequestOnRequest

    Процедура посылает запрос всякий раз, когда приходит запрос в дополнение к необходимым протокольным запросам (как это описано в разделе 3.1.2.2). Если Ru не способен быть входом LSP, он может выдать запрос, только когда получает запрос сверху.

    Если Rd получает такой запрос от Ru, для адресного префикса, для которого Rd уже послал метку Ru, Rd присвоит новую метку, ассоциирует ее с X, и разошлет эту ассоциацию. Может ли Rd послать эту ассоциацию Ru немедленно или нет, зависит от используемой процедуры рассылки. Эту процедуру следует использовать LSR, которые осуществляют рассылку меток downstream-on-demand, но не выполняют объединения меток, например, ATM-LSR, которые не способны объединять VC.


    4.1.3. Вышестоящий LSR: процедура NotAvailable

    Если Ru и Rd являются соответственно вышестоящим и нижестоящим партнерами рассылки меток для адресного префикса X, Rd является следующим шагом Ru L3 для X, Ru запрашивает ассоциацию для X от Rd, но Rd отвечает, что не может предоставить ассоциацию в это время, так как он не имеет следующего шага для X. Далее процедура NotAvailable определяет, как должен реагировать Ru. Существует две возможные процедуры, управляющие поведением Ru:


    4.1.3.1. RequestRetry

    Ru должен выдать запрос снова спустя некоторое время. То есть, источник запроса ответственен за попытку получить необходимую ассоциацию позднее. Эту процедуру следует использовать, когда применена рассылка меток downstream-on-demand.


    4.1.3.2. RequestNoRetry

    Ru никогда не должен посылать запрос повторно, предполагая, что Rd предоставит необходимую ассоциацию автоматически, когда она станет доступной. Это полезно, если Rd использует процедуру PushUnconditional или PushConditional, т.e., если применена не запрошенная рассылка меток нижестоящим объектам.

    Заметим, что если Rd отвечает, что он не может предоставить ассоциацию Ru, из-за тех же условий ошибки, а не по причине того, что Rd не имеет следующего шага, поведение Ru будет управляться условиями восстановления после ошибки протокола рассылки меток, а не процедурой NotAvailable.


    4.1.4. Вышестоящий LSR: процедура Release

    Предположим, что Rd является LSR, который связывает метку с адресным префиксом X, и который послал эту ассоциацию LSR Ru. Если Rd не оказался следующим шагом Ru L3 для адресного префикса X, или перестал быть следующим шагом Ru L3 для адресного префикса X, Ru перестанет использовать метку. Процедура Release определяет то, как Ru работает в этом случае. Существует две возможные процедуры, управляющие поведением Ru:


    4.1.4.1. ReleaseOnChange

    Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Label Retention Mode).


    4.1.4.2. NoReleaseOnChange

    Ru должен поддерживать ассоциацию, так что он сможет использовать ее немедленно, если Rd станет позднее следующим шагом Ru L3 для X . Эту процедуру следует использовать для реализации свободного режима удержания меток ( Liberal Label Retention Mode).


    4.1.5. Вышестоящий LSR: процедура labelUse

    Предположим, что Ru является LSR, который получил ассоциацию метки L для адресного префикса X от LSR Rd. Ru является вышестоящим по отношению к Rd с учетом X , и в действительности Rd является следующим шагом Ru L3 для X.

    Ru воспользуется ассоциацией, если Rd является следующим шагом Ru L3 для X. Если в момент получения ассоциации Ru, Rd не является следующим шагом Ru L3 для X , Ru не будет использовать эту ассоциацию. Ru может однако начать использовать ассоциацию позже, если Rd станет следующим шагом Ru L3 для X. Процедура labelUse определяет, как Ru использует ассоциацию Rd. Существует две процедуры, которые может использовать Ru:


    4.1.5.1. UseImmediate

    Ru может начать использовать ассоциацию немедленно. В любое время, когда Ru получил ассоциацию для X от Rd , а Rd является следующим шагом Ru L3 для X, Rd будет также следующим шагом Ru LSP для X . Эта процедура применяется, когда не используется детектирование петель.


    4.1.5.2. UseIfLoopNotDetected

    Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd.

    Эта процедура используется, когда работает детектирование петель маршрутов. Это будет продолжаться до тех пор, пока не изменится следующий шаг для X, или пока не будет ликвидирован петлевой маршрут.


    4.1.6. Нижестоящий LSR: процедура отзыва

    В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y меткой L.

    Рассылка и отзыв ассоциаций меток осуществляется через протокол рассылки меток. Все протоколы рассылки меток требуют, чтобы был установлен контакт между партнерами рассылки меток (за исключением неявных партнеров). Если LSR R1 установил контакт по рассылке меток с LSR R2, и получил ассоциации меток от LSR R2 через это соединение, тогда если соединение будет разорвано одним из партнеров (либо в результате поломки, либо обычной работы), все ассоциации, полученные через это соединение, должны рассматриваться как отозванные.

    Пока эффективное соединение по обмену метками остается в силе, отзыв ассоциаций меток должен производиться явно. Если вторая метка ассоциирована с адресным префиксом, первая метка при этом не отзывается, будут существовать обе ассоциации. Это необходимо, чтобы поддерживать маршрутизации с несколькими маршрутами. Если второй адресный префикс ассоциирован с меткой, ассоциация с первым префиксом при этом не отзывается, метка будет использоваться для обоих адресных префиксов.


    4.2. Схемы MPLS: поддерживаемые комбинации процедур

    Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd - нижестоящим.

    Схема MPLS, которая управляет взаимодействием Ru и Rd может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены, означает, что в данной категории возможна любая процедура; появление "N/A" в некоторой позиции указывает, что не нужна никакая процедура данной категории.

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


    4.2.1. Схемы для LSR, которые поддерживают объединение меток

    Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем:

    1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate >

    Это не затребованная рассылка меток "вниз по течению" с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель.

    2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

    Это не затребованная рассылка меток "вниз по течению" с независимым управлением, свободным режимом удержания меток и детектированием петель.

    3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*>

    Это не затребованная рассылка меток "вниз по течению" с упорядоченным управлением (со стороны конца) и консервативным режимом удержанием меток. Детектирование петель опционно .

    4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

    Это не затребованная рассылка меток "вниз по течению" с упорядоченным управлением (со стороны конца) и свободным режимом удержанием меток. Детектирование петель опционно.

    5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

    Это рассылка меток "вниз по течению по запросу" (downstream-on-demand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель.

    6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>

    Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и без детектирования петель.

    7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>

    Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и детектированием петель.


    4.2.2. Схемы для LSR, которые не поддерживают объединение меток

    Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4>, и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.

    Следовательно, если R1 и R2 являются MPLS-партнерами, и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек), или по какой то иной причине не способен осуществлять объединение меток, используемая схема MPLS между R1 и R 2 должна быть одной из следующих:

    1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

    Это рассылка меток "вниз по течению по запросу" с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием маршрутных петель.

    Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X; R3 пошлет R22 метки для X, а R2 пошлет одну метку R1 для X.

    2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>

    Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и без детектирования петель.

    3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

    Это рассылка меток "вниз по течению по запросу" с независимым управлением, консервативным режимом удержания меток и с детектированием петель.


    4.2.3. Соображения совместимости

    Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например:

    - <PulledUnconditional, RequestNever, *, *, *>

    <PulledConditional, RequestNever, *, *, *>

    В этих схемах MPLS, нижестоящий LSR Rd пересылает ассоциации меток вышестоящему LSR Ru только по запросу от Ru, но Ru никогда не делает таких запросов. Очевидно, эти схемы нежизнеспособны, так как они не способны осуществлять корректную рассылку ассоциаций меток.

    - <*, RequestNever, *, *, ReleaseOnChange>

    В этих схемах MPLS, Rd аннулирует ассоциации, если он их не использует, но он никогда не запрашивает их снова, даже если они ему позднее понадобятся. Эти схемы, таким образом, не гарантируют того, что ассоциации меток будут разосланы корректно.

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

    1. Каждый субъект должен объявить, поддерживает ли он объединение меток.

    2. Если Rd не поддерживает объединение меток, Rd должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry.

    То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет, при выборе схем MPLS.

    3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional.

    То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет, при выборе схем MPLS.

    4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо использование RequestWhenNeeded/ReleaseOnChange (консервативный), или использовать RequestNever/NoReleaseOnChange (свободный). Однако, выбор push либо pull и "условный" либо "безусловный" принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional. Такой выбор определяет использование схемы MPLS .


    5. Соображения безопасности

    Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом.


    6. Ссылки

    [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.

    [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.

    [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.

    [MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.

    [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.

    [MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.

    [MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

    [MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.


    previous up down next index index
    Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.5 Процедуры Интернет

    4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Перевод RFC-3353
    Аннотация

    В данном документе формулируются принципы внедрения IP -мультикастинга в среду MPLS. Представлен обзор последствий внедрения технологии MPLS в IP-мультикастинг. Рассматриваются плюсы и минусы существующих IP-мультикастинговых протоколов маршрутизации в контексте и обсуждаются соотношения различных способов запуска процессов формирования виртуальных путей на основе использования меток. Перечислены последствия применения различных технологий уровня 2 (L2). Обсуждаются сетевые схемы точка-точка и сети с множественным доступом.

    Таблица сокращений

    CoS

    Class of Service

    Класс услуг

    DLCI

    Data Link Connection Identifier

    Идентификатор информационного канала

    Drrecv

    Designated Router of the receiver    

    Выделенный маршрутизатор получателя

    Drsend

    Designated Router of the sender

    Выделенный маршрутизатор отправителя

    LSP

    Label Switched Path

    Маршрут с коммутацией по меткам

    LSR

    LABEL Switching Router

    Маршрутизатор с коммутацией по меткам

    LSRd

    Downstream LSR

    Нижестоящий LSR

    LSR-Up

    Upstream LSR

    Вышестоящий LSR

    MOSPF

    Multicast OSPF

    Мультикастинг OSPF

    mp2mp

    multipoint-to-multipoint

    Мультиточка-мультиточка

    MRT

    Multicast Routing Table

    Мультикастинг таблица маршрутизации

    p2mp

    point-to-multipoint

    точка мультиточка

    RP

    Rendezvous Point

    Точка встречи

    RPT-bit

    RP Tree bit [DEER]

    Бит дерева RP

    SPT-bit

    Shortest Path Tree [DEER]

    Дерево кратчайших путей

    1. Введение

    В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д.

    Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья.

    Обсуждение в данном документе концентрируется на протоколах внутридоменной мультикастинг маршрутизации.

    2. Характеристики уровня 2

    Хотя MPLS является мультипротокольным как для L3, так и L2, на практике IP рассматривается в качестве единственного протокола для L3. MPLS может работать поверх нескольких технологий L2 (PPP/Sonet, Ethernet, ATM, FR и т.д.).

    Когда переключение на основе меток переносится на уровень L2 (например, в качестве метки используются поля VPI/VCI), внимание фокусируется в основном на ATM [DAVI]. ATM предлагает высокие переключающие возможности и доступность обеспечения QoS, но в контексте имеет ряд ограничений, которые описаны в [DAVI]. Аналогичные соображения представлены для случая Frame Relay на уровне L2 в [CONT]. Ограничения можно суммировать как:

    • Ограниченное пространство меток : стандартизованное или реализованное число бит метки может быть мало (например, область VPI/VCI, пространство DLCI), ограничивая число LSP, которое может быть сформировано.
    • Объединение : некоторые технологии или реализации L2 не поддерживают соединения многоточка-точка и/или многоточка-многоточка, блокируя объединение LSP.
    • TTL : технологии L2 не поддерживают функцию TTL-декрементации.

    Все три ограничения могут оказать сильное влияние на реализацию мультикастинга в MPLS.

    Когда базовый MPLS будет разработан эти ограничения исчезнут. Более того, для каналов PPP и Ethernet может быть использована одна и та же метка для уникастного и мультикастного LSP, так как для уникастного и мультикастного определены разные коды EtherTypes [ROSE].

    3. Систематика мултикастных IP протоколов маршрутизации в контексте MPLS

    В настоящее время предложено и разрабатывается много мультикастинг протоколов маршрутизации. Все эти протоколы имеют различные характеристики (масштабируемость, вычислительную сложность, задержку, избыточность сообщений управления, тип дерева и т.д.). Целью данного документа не является осуществление исчерпывающей систематики мультикастинг протоколов маршрутизации, а только рассмотрение их характеристик, имеющих отношение к технологии MPLS. Рассматриваются следующие характеристики:

    - Агрегатирование
    - Широкая рассылка и отсекание ветвей (Flood &Prune)
    - Деревья с общим отправителем
    - Сосуществование деревьев отправителя и совмещенных деревьев
    - Одно и двунаправленные совмещенные деревья
    - Инкапсулированные мультикастинг-данные
    - Отсутствие петель

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

    3.1. Агрегатирование

    В уникастинге различные адреса места назначения объединяются в одной записи маршрутной таблицы, предоставляя один FEC и один LSP.

    Гранулярность мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где S - адрес отправителя, а G - мультикастинг адрес группы.

    3.2. Широкая рассылка и отсекание ветвей

    Чтобы сформировать мультикаст дерево протоколы маршрутизации (например, DVMRP, PIM-DM) широко рассылают мультикаст-данные. Отдельные ветви могут быть затем отсечены узлами, которые не хотят получать данные определенных мультикастинг-групп. Этот процесс периодически повторяется.

    Широкая рассылка и отсекание ветвей протоколов мультикастинг-маршрутизации имеет некоторые характеристики, которые значительно отличаются от параметров уникастных маршрутных протоколов:

    1. Изменчивость . Из-за особенностей протокола Flood & Prune, генерируются деревья с разными структурами. Решения о соответствии динамических деревьев L3 p2mp и L2 p2mp LSP должны быть эффективными с точки зрения сигнальных издержек и времени установления LSP. Варьируемые L2 LSP потребуют большого числа меток, что является недостатком при ограниченном их многообразии.
    2. Управление трафиком . Маршрутизатор лишь определяет состояние для определенной группы, когда для нее поступают данные. Маршрутизаторы также независимо принимают решение об удалении состояния, когда истекает время таймера пассивности.

    - Таким образом, LSP не могут быть сформированы заранее, как это обычно делается в случае уникастинга. Чтобы минимизировать время между поступлением данных и формированием LSP, желателен достаточно быстродействующий метод конфигурации LSP (setup method).

    - Так как формирование и ликвидация маршрута L3 в каждом узле запускается самим трафиком, это предполагает, что LSP, ассоциированный с маршрутом, формировался и уничтожался также процедурой, управляемой трафиком.

    - Если LSR не поддерживает переадресацию L3, технология управления трафиком требует, чтобы вышестоящий LSR брал на себя инициативу формирования LSP (анонсирование меток Upstream Unsolicited или Downstream on Demand).

    3.3. Деревья с общим отправителем

    Мультикастные IP протоколы маршрутизации формируют либо деревья отправителя (S,G), т.е. по дереву для каждого отправителя (S) и для группы (G), или деревья с совмещением (*, G), т.е. одно дерево для каждой мультикаст-группы (Рис. 1).

    Рис. 1. Дерево с совмещением и деревья отправителя

    Преимуществом использования деревьев с совмещением, в случае применения переключения по меткам, является то, что деревья с совмещением требуют меньше меток, чем деревья отправителя (1 метка на группу против одной метки на отправителя и на группу). Однако проецирование деревьев с совмещением на уровень L2 подразумевает формирование LSP мультиточка-мультиточка (mp2mp).

    Заметим, что на практике деревья с совмещением часто используются только для выявления новых отправителей групп, а переключение на дерево отправителя производится при низких потоках данных.

    3.4. Сосуществование деревьев с совмещением и деревьев отправителя

    Некоторые протоколы поддерживают как деревья отправителя, так и деревья с совмещением (например, PIM-SM) и один маршрутизатор может содержать (*, G) и (S,G) состояния для одной и той же группы G. Два случая сосуществования описаны ниже. Рассмотрим топологии с отправителями Si и получателями Ri. RP является точкой встречи (Rendezvous Point). Ni представляют собой LSR. Числа являются номерами интерфейсов, "Reg" - интерфейс Register. Все сообщения IGMP и PIM Join/Prune показаны на рисунках. Индицируется состояние бита RPT для состояния (S,G).

    1) На рис. 2 показан переход от совмещенного дерева к дереву отправителя. Предположим, что кратчайший путь от R1 к RP пролегает через N1-N2-N5. N1, выделенный маршрутизатор получателя (Designated Router) R1, (DRrecv) решает инициализировать дерево отправителя для S1. После получения данных через дерево отправителя в N2, N2 пошлет команду отсечения в N5 для отправителя S1. Состояние сосуществования реализуется в узле, где начинается перекрытие деревьев с совмещением и отправителя (N2), и в узле, где S1 не нуждается более в переадресации на дерево с совмещением (N5).

    IJ=Igmp Join; PJ=Pim Join (*,G); PJS=Pim Join (S1,G); PPS=Pim Prune (S1,G)

    Рис. 2

    Ниже перечислены состояния, которые формируются в мультикастинг таблице маршрутизации (MRT):

    в RP: (*,G):Reg->1 (т.е. входящее itf=Reg; исходящее itf=1)
    в N1: (*,G):2->1
    в N2: (*,G):3->1
       (S1,G):2->1
    в N3: (S1,G):2->Reg,1
    в N4: (*,G):2->1
    в N5: (*,G):2->1,3
      (S1,G)RPT-бит:2->1

    2) На рис. 3 показано, что состояние сосуществования может иметь место даже без переключения. Мультикастный трафик от отправителя сформирует состояние (S, G) в выделенном маршрутизаторе отправителя (DRsend; N3 на рис. 3 является DRsend отправителя S). Каждый узел совмещенного дерева имеет состояние (*,G). Таким образом Rsend имеет состояния (*, G) и (S,G). Если DRsend находится на дереве, он пошлет команду отсечения (prune) для S в направлении RP, формируя состояние (S,G) во всех узлах вплоть до первого маршрутизатора, который имеет ответвление (N1 и N2 на рис. 3).

    Рис. 3

    Состояния, формируемые при мультикастинг-маршрутизации в MRT, представлены ниже:

    в RP (*,G):Reg->1 (т.е. входящее itf=Reg; исходящее itf=1)
    в N1: (*,G):1->2,3
      (S,G)RPT-бит:1->2
    в N2: (*,G):1->2
      (S,G)RPT-бит:1->none
    в N3: (*,G):1->3
      (S,G):2->Reg,3
    в N4: (*,G):1->2
    в N5: (*,G):1->2

    В данных примерах можно видеть, что могут иметь место два типа сосуществования:

    1. (S,G) с нулевым RPT-битом (N2 на рис. 2, N3 на рис. 3). Состояния (*,G) и (S,G) имеют разные входные интерфейсы, но некоторые выходные интерфейсы являются общими. Возможно, что трафик S приходит через интерфейсы (*, G) и (S,G). При обычной переадресации L3 (S,G) SPT-бит запрещает переадресацию трафика из S, приходящего через входной интерфейс (*,G). Трафик S может только временно приходить через входные интерфейсы как (*, G), так и (S,G) (вплоть до N5 на рис. 2 и N1 на рис. 3 обработали сообщения prune). Чтобы избежать временной переадресации дубликатов пакетов L3, переадресация может быть применена к этому типу узлов. Если не предполагается временной переадресации дубликатов пакетов, может быть применена переадресация на уровне L2. В этом случае потоки (*, G) и (S,G) должны быть совмещены в (*, G) LSP выходного интерфейса.
    2. (S,G) с RPT-битом =1 (N5 на рис. 2, N1 и рис. 3). Состояние (*,G) и (S,G) имеет тот же входной интерфейс. Трафик (S,G) должен извлекаться из потока (*,G). В MPLS это состояние сосуществования может обрабатываться разными способами. Будет рассмотрено четыре подхода к решению этой проблемы:
    1. Первый метод обработки этого состояния сосуществования заключается в завершении LSP и переадресация всего трафика этой группы на L3. Однако можно избежать возврата на L3 в случае (S,G), когда к MRT не добавляется исходящий интерфейс (N2 на рис. 3). Этот вход будет принимать трафик только временно. В этом конкретном случае можно игнорировать состояние (S,G) и поддерживать существующий (*, G) LSP. Недостатком этого варианта является дублирование трафика в течение короткого времени.
    2. Вторым подходом является присвоение отправителю специфических меток для узлов, принадлежащих совмещенным деревьям. Одному набору (*, G) будет присвоено несколько меток, по одной на каждый активный источник пакетов. Так как узлы знают только, какие отправители активны, когда получают от них трафик, LSP не могут быть сформированы заранее и нужны быстрые способы установления LSP.
    3. Третий способ заключается в том, что только деревья отправителя используются для коммутации по меткам, а трафик в совмещенных деревьях всегда переадресуется на уровне L3. Это предполагает, что используются только совмещенные деревья, как средство для получателей выяснить, кто является отправителем. Конфигурируя порог переключения для низких скоростей передачи, можно гарантировать, что получатели переключаются на дерево отправителя достаточно быстро.
    4. В четвертом подходе LSR, который имеет состояние (S,G) RPT-бит с ненулевым oif, анонсирует метку для (S,G) вышестоящему LSR и это анонсирование распространяется затем каждым вышестоящим LSR в направлении RP. Таким способом выделенный LSP формируется для трафика (S,G) от RP к LSR с состоянием (S,G) RPT-бит. В последнем LSR, (S,G) LSP объединяется в (*,G) LSP для соответствующих выходных интерфейсов. Это гарантирует, что пакеты (S,G), движущиеся вдоль совмещенного дерева, не пройдут через LSR, которые отсечены от S.

    3.5. Одно и двунаправленные деревья с совмещением

    Двунаправленные деревья с совмещением (например, CBT [BALL]) имеют недостаток, который связан с формированием большого числа точек смежности (M) в узлах (N) совмещенного дерева. На рис. 4 показаны эти точки, полученные при двух отправителях S1 и S2 двунаправленного дерева.

    Рис. 4. Потоки мультикаст-данных от двух отправителей для двунаправленного дерева

    На рис. 5 показана та же ситуация для однонаправленных деревьев. В этом случае данные отправителя направляются через туннель к корневому узлу R, формируя всего одну точку смежности (сам корень дерева).

    Рис. 5. Потоки мультикаст-данных от двух отправителей для однонаправленного дерева

    3.6. Инкапсулированные мультикастинг данные

    Отправители однонаправленных совмещенных деревьев и отправители, не являющиеся узлами двунаправленных совмещенных деревьев, инкапсулируют данные на пути к корневому узлу. Данные затем декапсулируются в корневом узле. Инкапсуляция и декапсуляция мультикастных данных осуществляется на уровне L3.

    Таким образом, в случае инкапсуляции/декапсуляции путь может вообще не совпадать с LSP: трафик не может быть ни переадресован на L2 через интерфейс Register DRsend (инкапсуляция), ни попасть в корневой узел на L2 (декапсуляция).

    Замечания

    1. Если LSR поддерживает смешанную L2/L3 переадресацию (раздел 4), трафик (S,G) в DRsend может переадресовываться на L2 через любой выходной интерфейс, отличный от Register.
    2. Инкапсулированный трафик может выиграть от использования переключения по меткам.
    3. Если корневой узел решает присоединиться к отправителю (чтобы избежать инкапсуляции/декапсуляции), может быть сформирован LSP точка-точка (S,G).

    3.7. Отсутствие петель

    Протоколы мультикаст маршрутизации, которые зависят от уникастного протокола маршрутизации подвержены зацикливаниям при переходных процессах, как и все уникастные, однако воздействие таких петель в случае мультикаста много тяжелей. Это происходит по следующей причине, каждый раз, когда мультикаст пакет идет вдоль петли, копии этого пакета могут выходить за пределы этого кольцевого маршрута, если имеет место его ветвление.

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

    3.8. Характеристики существующих протоколов

    Выше перечисленные характеристики суммированы в таблице 1 для неполного списка существующих мультикастных протоколов маршрутизации: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL].

    Таблица 1.Систематика протоколов маршрутизации для IP-мультикастинга

     

    DVMRP

    MOSPF

    CBT

    PIM-DM

    PIM-SM

    SSM

    SM

    Агрегация

    нет

    нет

    нет

    нет

    нет

    нет

    нет

    Flood & Prune

    да

    нет

    нет

    да

    нет

    нет

    опция

    Tree Type

    Отправитель

    Отправитель

    Совмещение

    Отправитель

    оба

    Отправитель

    Совмещение

    Состояние сосуществования

    нет

    нет

    нет

    нет

    да

    нет

    нет

    Направления

    -

    -

    2

    -

    1

    1

    2

    Инкапсуляция

    нет

    нет

    да

    нет

    да

    нет

    да

    Без циклов

    нет

    нет

    нет

    нет

    нет

    нет

    нет

    Из таблицы 1 можно видеть, например, что DVMRP использует большое число меток, когда дерево Flood & Prune L3 проектируется на дерево L2. Более того, так как DVMRP использует деревья отправителя, он не сталкивается с проблемой объединения, когда используется коммутация по меткам. Таблица может быть интерпретирована аналогичным образом для других протоколов.

    4. Смешанная переадресация L2/L3 в отдельном узле

    Так как уникастный трафик имеет один входной и один выходной интерфейс, трафик переадресуется либо на уровне L2, либо на уровне L3 (Рис. 6). Так как мультикастный трафик может переадресовываться более чем через один выходной интерфейс, можно считать, что трафик в некоторых ветвях переадресуется на уровне L2, а в других на уровне L3 (Рис. 7).

    Рис. 6. Уникастная переадресация на уровне L3 или L2

    Рис. 7. Мультикастная переадресация на уровне L3, смешанном L2/L3 или L2

    Узлы, которые поддерживают эту возможность смешанной переадресации L2/L3, позволяют расщеплять мультикастное дерево на ветви, с переадресацией L3 и L2.

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

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

    a) Пусть LSR A (Рис. 8) является оконечным узлом для ветви к LSR B и узлом ветвления для LSR C. Смешанная переадресация L2/L3 допускает, чтобы ветвь к C не загружалась проблемой возврата на уровень L3 в LSR A

    Рис. 8. Смешанная L2/L3-переадресация в узле A

    b) Допускает использование триггера, управляемого трафиком, с режимом рассылки меток Downstream Usolicited или Upstream on Demand, как это объяснено в разделе 5.3.1.

    5. Систематика IP-мульткаст LSP триггеров

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

    1. Запуск запросом : перехватывает отправку или получение управляющих сообщений (например, мультикастные маршрутные сообщения, сообщения резервирования ресурсов).
    2. Запуск топологией : устанавливает соответствие между деревом уровня L3, которое имеется в мультикастной таблице маршрутизации, и деревом L2. Установление соответствия осуществляется даже при отсутствии трафика.
    3. Запуск трафиком : устанавливается соответствие между деревом L3 и деревом L2 тогда , когда поступают данные.

    5.1. Управление запросами
    5.1.1. Общая часть

    Установление LSP может быть запущено путем перехвата исходящих (метка должна быть затребована нижестоящим LSR) или входящих (метка должна быть затребована вышестоящим LSR) управляющих сообщений. На рис. 9 проиллюстрированы эти два случая.

    Входящие           Исходящие

    Рис. 9. Запуск по запросу (перехват resp. входящих и исходящих управляющих сообщений)

    Нижестоящий LSR (LSR-Dn) посылает управляющее сообщение вышестоящему LSR (LSR-Up). В случае, когда входные управляющие сообщения перехватываются и модуль в LSR-Up решает установить LSP, он пошлет LSR-Dn команду LDP bind (режим Upstream nsolicited) или запрос LDP bind (режим Downstream on Demand).

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

    5.1.2. Сообщения мультикаст-маршрутизации

    В принципе этот механизм может быть использован только мультикастинг протоколами маршрутизации, в которых применяется прямая сигнализация: например, сообщения Join в PIM-SM или CBT. Заметим, что DVMRP и PIM-DM могут быть адаптированы для поддержки этого типа запуска [FARI], однако ценой модификации самого протокола мультикаст-маршрутизации!

    IP-сообщения мультикаст-маршрутизации могут формировать как жесткие состояния (например, CBT Join + CBT Join-Ack) так и "мягкие состояния" (например, периодически посылаются сообщения PIM-SM Join). Последние генерируют больше управляющего трафика для поддержания дерева и таким образом требуют больше обработки в модуле.

    Запуски формирования маршрута, базирующиеся на сообщениях мультикастинг-протоколов маршрутизации, имеют недостаток, который заключается в том, что вычисление мультикастинг таблицы маршрутизации, выполняемые мультикастным маршрутным демоном, повторяются модулем. Первый определяет дерево, которое будет использоваться на уровне L3, последний вычисляет идентичное дерево, которое будет использоваться на уровне L2. Так как одна и та же задача решается дважды, лучше сформировать мультикастный LSP на основе информации, извлеченной из самой мультикастинг таблицы маршрутизации (смотри раздел 5.2 и 5.3). Вычисление маршрута становится более сложным для протоколов, которые поддерживают переключение от дерева (*, G) к дереву (S, G), так как нужно интерпретировать больше сообщений.

    Когда ЭВМ имеет соединение с первым маршрутизатором по схеме точка-точка, может быть сформированы LSP до конечных пользователей путем перехвата не только маршрутных мультикастинг-сообщений, но и сообщений IGMP Join/Prune ([FENN]).

    5.1.3. Сообщения резервирования ресурсов

    В случае уникаста для запуска процесса формирования маршрута LSP могут использоваться сообщения RSVP Resv. Отправитель мультикастной группы пошлет вниз по дереву сообщение RSVP Path, получатели могут затем откликнуться сообщением RSVP Resv. RSVP хорошо адаптируется и для мультикастинга

    a) Сообщения RSVP Resv могут быть совмещены.
    b) Сообщения RSVP посылаются только первой ветви, которая выполнила нужное резервирование.

    5.2. Управление топологией

    Мультикастинг таблица маршрутизации (MRT) поддерживается демоном протокола мультикастинг маршрутизации. Модуль устанавливает соответствие (мэпинг) этих топологических данных дерева L3 и маршрутов LSP L2 p2mp.

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

    5.3. Управление трафиком
    5.3.1. Общая часть

    Метод запуск формирования маршрута с помощью трафика создает LSP для деревьев, по которым проходит трафик. Он расходует меньше меток, чем способ, запускаемый топологией, так как метки резервируются лишь тогда, когда через дерево проходит реальный трафик.

    Если смешанная переадресация L2/3 не поддерживается (смотри раздел 4), запуск формирования LSP от трафика требует установления режима рассылки меток, в котором метки запрашиваются LSR-Up (режим Downstream on Demand или Upstream Unsolicite). На рис. 10 предполагается, что для определенной группы существует LSP до LSR-Dn1, а другой LSR-Dn2 хочет присоединиться к дереву. Для того чтобы LSR-Dn2 инициировал формирование прохода, он должен уже получать трафик от этого дерева. Это может быть реализовано на L2 или L3. Первый вариант представляет собой проблему цыпленок-яйцо. В последнем случае для добавления ветви L3 необходима поддержка смешанной переадресации L2/L3 в LSR-Up.

    Рис. 10. LSR-Up должен запросить метку.

    5.3.2. Пример реализации

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

    Современные реализации на Unix-платформах мультикастинг протоколов маршрутизации (DVMRP, PIM) имеют MFC (Multicast Forwarding Cache). MFC является кэшированной копией мультикастинг таблицы маршрутизации. MFC запрашивает рекорд для определенной мультикаст-группы, когда обнаруживает отсутствие нужной информации в кэше для входящего пакета. Недостающая маршрутная информация предоставляется мультикаст-демоном. Если позднее ситуация с маршрутами изменится (добавлен или удален выходной интерфейс), мультикаст-демон обновит MFC.

    MFC реализован как общая часть (ядра), которая делает этот вид запуска привлекательным, так как он может быть прозрачно использован для любого мультикастного протокола маршрутизации.

    Рекорды в MFC удаляются, когда нет трафика для этого рекорда в течение определенного периода времени. Когда используется коммутация по меткам для определенного рекорда MFC, уровень L3 вообще не будет видеть приходящих пакетов. Чтобы поддержать нормальную работу MFC, счетчики L3 MFC должны быть скорректированы с учетом измерений на уровне L2.

    5.4. Комбинации режимов запуска и рассылки меток

    В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3.

    Таблица 2. Допустимые комбинации методов запуска и рассылки меток

     

    Метка запрашивается

    LSR-Up

    LSR-Dn

    upstream unsolicited

    downstream on demand

    downstream unsolicited

    upstream on demand

    Request Driven (входные сообщения)

    X

    X

     

     

    Request Driven (выходные сообщения)

     

     

    X

    X

    Topology Driven

    X

    X

    X

    X

    Traffic Driven

    X

    X

    (X)

    (X)

    6. Перенос меток (Piggy-backing)

    На рис. 9 (outgoing case) можно видеть, что вместо отправки двух отдельных сообщений, анонсирование метки может осуществляться посредством существующих управляющих сообщений. Для мультикастинга имеется два кандидата для транспортировки (piggy-back):

    1. Мультикастные маршрутные сообщения: протоколы, такие как PIM-SM и CBT, имеют сообщения Join, которые могут нести в себе мэппинг меток. Этот подход описан в [FARI]. Когда установлены различные протоколы для мультикастинг-маршрутизации, должны быть определены расширения для каждого из этих протоколов.
    2. Сообщения Resv RSVP: объект расширения мэппинга меток для RSVP, также применим в мультикастинге (предложено в [AWDU]).

    За и против транспортировки меток с привлечением мультикаст маршрутных сообщений рассматриваются ниже. Такой вид транспортировки имеет следующие преимущества:

    1. Если анонсирование меток осуществляется мультикаст маршрутными сообщениями, тогда рассылка маршрутов и меток оказываются синхронизованными. Это исключает сложные ситуации типа "что я должен делать с меткой, если у меня пока нет подходящего рекорда в маршрутной таблице?". Это также минимизирует интервал между установлением мультикаст-маршрута и ассоциацией метки и маршрута.
    2. Число управляющих сообщений, необходимое для поддержания анонсирования меток, помимо используемых для осуществления мультикастной маршрутизации, равно нулю.

    Можно отметить следующие недостатки такого типа транспортировки:

    1. В некоторых протоколах нет сообщений, с помощью которых можно доставлять сообщения о метках. Для таких протоколов предлагается [FARI] добавить периодически рассылаемые сообщения, которые сильно влияют на работу мультикастинг маршрутного протокола и сводят на нет выгоды совмещенной транспортировки (piggy-backing).
    2. Второе решение проблемы сосуществования состояний (смотри 3.4) не может быть применено в сочетании с совмещенной транспортировкой (с piggy-backing).
    3. Совмещенная транспортировка требует расширения мультикастного протокола маршрутизации, и следовательно становится менее привлекательной, если анонсирование меток требует поддержки нескольких мультикастных протоколов маршрутизации.
    4. Совмещенная транспортировка предполагает режим рассылки меток Downstream Unsolicited, это исключает несколько методов запуска процесса формирования LSP (смотри таблицу 2).
    5. LDP обычно работает поверх TCP, предполагая надежный обмен между узлами-партнерами. Совмещенная транспортировка сообщений о метках часто замещает надежный обмен на периодическую рассылку анонсирований меток. Из-за этого периодического анонсирования меток управляющий трафик (в байтах) увеличится.
    6. Если необходим механизм оповещения VCID [NAGA], он может быть реализован путем посылки сообщений LDP bind через вновь сформированный виртуальный канал VC. Для этого необходимо лишь одно сообщение. Такой метод не может комбинироваться с совмещенной транспортировкой, так как маршрутные сообщения посылаются до того как будет сформирован VC. Таким образом, необходим дополнительный диалоговый обмен, сокращающий выгоды совмещенной транспортировки.

    Совмещенная транспортировка является лишь одним возможным компонентом мультикастного решения для.

    7. Непосредственная маршрутизация

    Явная маршрутизация для уникастинга сопряжена с переписыванием уникастной маршрутной таблицы, с использованием LSP. " Мультикастная явная маршрутизация" может быть определена как перепись дерева, сформированного мультикастным протоколом маршрутизации, с привлечением другого дерева LSP (например, дерева Штайнера, вычисленного где-то off-line). В этой интерпретации современный мультикастинг протокол маршрутизации 'кратчайшего пути' становится устаревшим и может быть заменен сообщениями рассылки меток, которые следуют явным маршрутом (например, ветвь дерева Штайнера).

    Другой способ интерпретации "Мультикастная явная маршрутизация" предполагает, что работают мультикастные протоколы маршрутизации, но что сообщения, генерируемые этими протоколами, для формирования дерева используют явно уникастные маршруты (вместо кратчайших путей IGP).

    8. QoS/CoS
    8.1. DiffServ

    Концепция дифференцированных услуг может быть применена и к мультикастингу. Это приводит к более тонкой гранулированности потоков (DSCP в качестве дополнительного средства разделения потоков). Отправитель может сформировать одно или более деревьев с разными DSCP.

    Эти деревья (S,G, DSCP) или (*, G, DSCP) могут быть легко спроектированы на LSP, если используется механизм формирования пути, запускаемый трафиком. В этом случае можно сформировать LSP с разными атрибутами для разных DSCP. Заметим, однако, что эти LSP используют тот же маршрут, так как механизм формирования дерева не использовал значения DSCP.

    8.2. IntServ и RSVP

    RSVP может использоваться для формирования мультикастных деревьев с заданным QoS. Важным следствием использования мультикастинга является проблема, как связать парадигму 'гетерогенных получателей' с уровнем L2 (заметим, что эта задача не решена и в IP). Этот предмет серьезно обсуждается в [CRAW]. Прагматическими подходами являются модель ограниченной гетерогенности, которая допускает уровень услуг "максимальных усилий" (best effort) и один уровень QoS (например, QoS, предложенный отправителем в сообщении RSVP Path) и гомогенная модель, которая допускает только один уровень QoS.

    Первый поход приводит к формированию полных деревьев для каждого класса услуг. Отправитель должен послать свой трафик в сеть дважды (например, 1 в дерево "максимальных усилий" и 1 - в дерево QoS). В обоих деревьях может использоваться коммутация по меткам.

    При втором подходе конструируется одно дерево и пользователи услуги "максимальных усилий" подключаются к дереву QoS. Если ветви, созданные для пользователей "максимальных усилий" не используют коммутацию по меткам, (таким образом, следуя шаг-за-шагом вдоль LSP), мультикастный QoS-трафик должен следовать этим LSP по умолчанию. Эта функция может быть предоставлена системой смешанной переадресации L2/L3, описанной в разделе 4. Если она недоступна, объединение необходимо, чтобы избежать возврата на L3 в QoS LSP.

    9. Сети с множественным доступом

    Мультикастный в сетях с множественным доступом представляет собой определенную проблему. LSR, который хочет присоединиться к группе, должен всегда быть готов воспринять метку, которая уже приписана группе LSP. Это может быть достигнуто тремя путями:

    1. Каждый LSR канала с множественным доступом запоминает все анонсированные метки канала, даже если он не получил сигнал join для соответствующей группы. Если LSR добавлен к каналу с множественным доступом, он должен получить эту информацию от другого LSR канала или в случае soft state анонсирования меток, он может ждать некоторое время, прежде чем сам сможет сформировать метку. Если LSR формируют метки в один и тот же момент, LSR с более высоким кодом IP-адреса может ее сохранить, в то время как другой LSR отзывает свою метку.
    2. Каждый LSR получает свой собственный диапазон меток. Механизм распределения меток описан в [FARI]. Если LSR добавляется к каналу с множественным доступом, диапазон меток должен быть согласован снова и, возможно, некоторые существующие каналы LSP разрываются и восстанавливаются с другими метками.
    3. В каждом канале с множественным доступом один LSR может быть выбран ответственным за выделение меток. Когда LSR нужна метка, он может запросить ее у этого LSR, осуществляющим присвоение меток.

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

    1. [FARI] предлагает рассылать анонсирования меток мультикастно всем LSR, подключенным к общему каналу. Так как мультикастинг не является надежным, это требует периодического анонсирования меток, что приведет повторным оповещениям об одних и тех же метках.
    2. Другой подход заключается в том, что LSR рассылает анонсирования меток уникастно с привлечением, например, протокола TCP всем другим (или всем заинтересованным) LSR, подключенным к общему каналу.

    Так как LSP оправданы, если они живут долго, и так как число LSR в используемом совместно канале ограничено, второй подход представляется предпочтительным.

    Другой момент, связанный с мультикастингом в сетях с множественным доступом, сопряжен с тем, следует ли использовать для присвоения меток вышестоящий или нижестоящий LSR. Для мультикастного трафика, использование вышестоящего LSR проще, так как там может быть только один вышестоящий узел, принадлежащий данному мультикастному дереву. Этот (вышестоящий) узел может присвоить уникальную метку для заданного FEC. Рассылка меток "вниз по течению" должна учитывать тот факт, что может быть много нижестоящих узлов в заданном дереве для канала с множественным доступом; каждый узел может предложить свою метку для FEC, что потребует некоторого разбирательства, чтобы каждому мультикастному FEC была присвоена лишь одна метка.

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

    10. Дополнительные выводы
    10.1. Поле TTL

    Поле TTL в IP-заголовке обычно используется для детектирования петель. В IP мультикастинге оно также используется для ограничения области распространения пакетов. Таким образом, в LSR, которые не поддерживают функция декрементации TTL (например, ATM LSR), функция ограничения области действия пострадает. Предположим, что можно вычислить заранее число шагов для заданного LSP. В уникастном LSP значение TTL может декрементироваться на входе или выходе из узла. В случае мультикаста все ветви дерева могут иметь разную длину, так что TTL может декрементироваться только на выходе, потенциально растрачивая полосу пропускания, если TTL окажется меньше или равным нулю.

    10.2. Независимое управление рассылкой меток против упорядоченного

    Существующая терминология для рассылки меток определена лишь для уникастного случая. Далее рассматривается, какой смысл эти термины могут иметь в случае мультикастинга.

    При независимом управлении ([ANDE]) каждый LSR может взять на себя инициативу присвоения меток. При упорядоченном управлении ([ANDE]) LSR ассоциирует метку, когда он уже получил ее от последующего узла.

    Все описанные выше методы запуска процесса формирования дерева (раздел 5) имеют отношение к независимому управлению. Заметим, что если используется подход с запуском по запросу при независимом управлении, рассылка меток осуществляется, как если бы применялось упорядоченное управление: управляющие сообщения направляются от выходного узла "вверх по течению", реализуя ту же последовательность анонсирования меток.

    Упорядоченное управление не применимо для запуска, управляемого трафиком в случае, когда узел не поддерживает смешенную L2/L3 переадресацию. Согласно таблице 2, этот случай предполагает, что метки запрашиваются вышестоящим LSR. Предположим, что на рис. 11 имеется LSP от S до R1 и нужно проложить новую вервь до R2. B будет воспринимать метки канала A - B только если они уже ассоциированы с каналом B-C. Однако для того чтобы определить метку для канала B-C, B должен уже получать трафик со стороны канала A-B.

    Рис. 11.

    10.3. Режимы консервативного и либерального удержания меток

    В консервативном режиме ([ANDE]) только метки, которые используются для переадресации (если следующим шагом для FEC является LSR, который анонсировал метку), присваиваются и поддерживаются. В либеральном режиме метки анонсируются и поддерживаются для всех соседей. Либеральный режим не чувствителен к мультикастингу. Для этого имеется две причины:

    1. Все LSR имеют маршрут для каждого уникастного FEC. Это не верно для мультикастных FEC.
    2. Для мультикастинга LSR всегда знает, какому соседу следует посылать запросы метки или сообщения о присвоении. Например, в уникастном режиме Downstream Unsolicited (смотри ниже) LSR не знает, куда посылать ассоциацию метки, и в результате должен посылать ее всем своим соседям. В этом случае при поддержке либерального режима лишние сообщения не посылаются (необходима дополнительная статусная информация и некоторое пространство меток) и таким образом порог поддержки либерального режима следует рассмотреть ниже.

    В таблице 3 показаны случаи, когда LSR знает, куда посылать запрос на метку.

    Таблица 3. Знает ли LSR, куда посылать запросы меток?

     

    Метка запрошена

    LSR-Up

    LSR-Dn

    Уникаст

    Да

    Нет

    Мультикаст

    Да

    Да

    Для уникастного потока, LSR могут определить LSR следующего шага, которому следует послать запрос в случае режима работы Upstream Unsolicited или Downstream on Demand. LSR, однако, не может определить маршрутизатор предшествующего шага. Предыдущий шаг необязательно является следующим шагом в направлении отправителя, так как путь от A к B не обязательно совпадает с путем от B к A. Такая ситуация может случиться в результате асимметричных метрик в канале или в случае, когда имеется несколько маршрутов с идентичной метрикой [PAXS].

    В случае мультикастинга, LSR знает как следующий шаг, так и предыдущий. Так как мультикастные деревья формируются реверсивным методом кратчайших путей, предшествующим шагом всегда является следующий узел по направлению к отправителю или корню дерева.

    10.4. Выделение меток "вверх и вниз по течению"

    Метка может быть выделена либо нижестоящим LSR (режимы Downstream on Demand, Downstream Unsolicited) или вышестоящим LSR (режимы Upstream on Demand, Upstream Unsolicited, неявный). Преимущества выделения меток "вниз по течению" перечислены ниже:

    1. Это тот же самый режим, что и в случае уникастного LDP, таким образом исключается необходимость разработки процедур рассылки меток "вверх по течению".
    2. Можно использовать ту же метку, когда меняется вышестоящий LSR из-за изменения маршрута, что является преимуществом для сетей с множественным доступом (смотри раздел 9).
    3. Совместимо с piggy-backing (особенно для режима рассылки "вниз по течению").

    Преимущество присвоения меток вышестоящим объектом заключаются в следующем:

    1. Проще выделение меток для сетей с множественным доступом (смотри раздел 9).
    2. Может использоваться та же метка, когда нижестоящий LSR (который мог быть инициатором выделения метки в режиме "вниз по течению" в сети с множественным доступом) покидает группу (смотри раздел 9).
    3. Режимы рассылки "вверх по течению" и неявный допускают более быстрое установление LSP, когда осуществляется запуск LSP трафиком.

    10.5. Явная и неявная рассылки меток

    Помимо режимов явной рассылки меток (которые используют сигнальный протокол), [ACHA] предлагается метод неявной рассылки меток, использующий неизвестные метки. Этот метод имеет все преимущества выделения меток "вверх по течению" и является, вероятно, самым быстродействующим способом анонсирования меток для запуска формирования LSP трафиком.

    Неявная рассылка меток не применима, если ассоциация FEC-метка была анонсирована до прихода трафика, например, явная маршрутизация (т.е. если в пакете нет всей необходимой информации, чтобы идентифицировать FEC). Явная рассылка меток допускает предварительное установление LSP (до прихода данных) по топологии или по запросу.

    Ссылки

    [ACHA] A. Acharya, R. Dighe и F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97.

    [ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.

    [ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. и R. Thomas, "LDP Specification", RFC 3036, January 2001.

    [AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. yes"> и V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

    [BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.

    [CONT] Conta, D., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.

    [CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. и J. Krawczyk, "A Framework for Integrated Services и RSVP over ATM", RFC 2382, August 1998.

    [DAVI] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. и P. Doolan, "MPLS using LDP и ATM VC switching", RFC 3035, January 2001.

    [DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. и L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.

    [FARI] D. Farinacci, Y. Rekhter, E. Rosen и T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress.

    [FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.

    [GARR] Garrett, M. и M. Borden, "Interoperation of Controlled-Load Service и Guaranteed Service with ATM", RFC 2381, August 1998.

    [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.

    [MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

    [NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. и P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.

    [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.

    [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress.

    [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615.

    [ROSE] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

    Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.5 Процедуры Интернет


    previous up down next index index
    Previous: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.20 Требования для управления трафиком

    4.4.19 Кодирование меток в MPLS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    E. Rosen, RFC-3032, MPLS Label Stack Encoding

    Аннотация

    "Многопротокольная коммутация меток (MPLS)" [1] требует наличия набора процедур для пакетов со стеком меток (помеченных пакетов). Маршрутизаторы, которые поддерживают MPLS, называются LSR (Label Switching Routers). Для того чтобы переслать помеченный пакет по конкретному каналу, LSR должен поддерживать систему представления стека меток и обработки пакетов сетевого уровня. В данном документе специфицирована система представления стека меток, используемая LSR, для того чтобы передавать помеченные пакеты по каналам PPP (Point-to-Point Protocol), по каналам данных LAN, и возможно по другим каналам. В других каналах кодирование может быть иным, но представление стека меток должно быть стандартным. Здесь также специфицируются правила и процедуры для обработки различных полей записей в стеке меток.


    1. Введение

    "Многопротокольная коммутация меток (MPLS)" [1] требует набора процедур для дополнения пакетов сетевого уровня "стеком меток", таким образом превращая их в помеченные пакеты. Маршрутизаторы, которые поддерживают протокол MPLS, называются LSR (Label Switching Routers). Для того чтобы передать помеченный пакет по определенному каналу, LSR должен поддерживать методику кодирования, и анализа помеченных пакетов. Данный документ специфицирует кодирование, используемое LSR, для того чтобы передать помеченный пакет по каналу данных PPP и LAN. Специфицированная кодировка может быть применена и в других каналах данных.

    Этот документ специфицирует также правила и процедуры обработки различных полей стека меток. Так как MPLS не зависит от сетевого протокола, большинство таких процедур являются протокольно независимыми. Некоторые, однако, являются разными для различных протоколов. В этом документе, мы специфицируем протокольно независимые процедуры, а также протокольно зависимые процедуры для IPv4 и IPv6.

    LSR, которые реализованы на определенном коммутационном оборудовании (таком как ATM-коммутаторы) могут использовать различные системы кодирования верхних записей в стеке.


    2. Стек меток

    2.1. Кодирование стека меток

    Стек меток представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 1.

    Рис. 1. Формат записи стека меток

    Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно - последним. Сетевой заголовок следует сразу вслед за записью стека меток с битом S=1. Каждая запись стека меток содержит в себе следующие поля:

    1. Дно стека (S)

    Этот бит устанавливается равным 1 для последней записи в стеке меток (т.e., для дна стека), и нулю для всех прочих записей.

    Замечание переводчика . Следует заметить, что данный формат меток не является единственно возможным (я здесь не имею в виду ATM или FR). В IP-телефонии, например, предлагается использовать метку, которая содержит (слева-направо) код 0х8100, за которым идет 3-битовое поле приоритета (0-7) и идентификатор VPN (0-4095). Смотри журнал LANline N10, 2002, стр 140).

    2. Время жизни (TTL)

    Это 8-битовое поле служит для представления значения времени жизни пакета. Обработка этого поля описана в разделе 2.4.


    3. Экспериментальное поле

    Это 3-битовое поле зарезервировано для экспериментальных целей (QoS).

    4. Значение метки

    Это 20-битовое поле несет в себе код метки.

    Когда получен помеченный пакет, анализируется значение метки на верху стека. В результате этого анализа определяется:

    a) следующий шаг, куда должен быть переадресован пакет;

    b) операция, которая должна быть выполнена со стеком меток до переадресации; эта операция может быть заменой метки на вершине стека, или удаление записи из стека, или замещение верхней позиции в стеке и занесение туда затем одной или более новых записей.

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

    i. Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен, и переадресация пакета должна основываться на IPv4-заголовке.

    ii. Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой, в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах [5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.

    iii. Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.

    iv. Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую, и эта новая метка является "Implicit NULL", LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.

    v. Значения 4-15 зарезервированы.


    2.2. Определение протокола сетевого уровня

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

    Следовательно, когда в сетевой пакет заносится первая метка, она должна быть уникальной для конкретного сетевого уровня или для набора сетевых протоколов. Кроме того, когда бы в процессе передачи метка ни была заменена другой, новая метка также должна отвечать тем же критериям. Если эти условия не выполнены, LSR, который удаляет последнюю метку из пакета, не сможет идентифицировать сетевой протокол.

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

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

     

    2.3. Генерация ICMP-сообщений для помеченных пакетов

    В разделах 2.4 и 3 обсуждаются ситуации, в которых желательно формировать ICMP-сообщения для помеченных IP-пакетов. Для того чтобы конкретный LSR мог формировать и посылать ICMP пакеты отправителям IP-пакетов, должны выполняться два условия:

    1. Данный LSR должен быть способен определить, что конкретный помеченный пакет является IP-пакетом.

    2. Данный LSR должен быть способен проложить путь до места назначения IP-пакета.

    Условие 1 обсуждается в разделе 2.2. В следующих двух подразделах обсуждается условие 2. Однако встречаются ситуации, когда условие 2 совсем не выполняется, и в этих случаях невозможно сформировать сообщение ICMP.


    2.3.1. Туннелирование через транзитную область маршрутизации

    Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадает к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF, и могут только знать, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Routers), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, и LSR, которые не являются ASBR, поддерживают BGP.

    В этом примере, только ASBR будет знать, как проложить маршрут до отправителя некоторого произвольного пакета. Если внутренний маршрутизатор должен послать сообщение ICMP отправителю IP-пакета, он не будет знать как маршрутизовать это ICMP-сообщение.

    Одним из решений является занесение ASBR маршрута по умолчанию в IGP. Это бы гарантировало то, что любой непомеченный пакет, который должен выйти из домена (такой как ICMP-пакет), попадет в маршрутизатор, который имеет полную маршрутную информацию. Маршрутизаторы с полной маршрутной информацией будет помечать пакеты, прежде чем их послать через транзитную область, так что использование маршрутов по умолчанию в пределах транзитного домена не приводило к образованию циклических путей.

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


    2.3.2. Туннелирование частных адресов через общедоступную опорную сеть

    В некоторых случаях, когда MPLS используется для туннелирования через домен маршрутизации, может быть вообще невозможно проложить путь до адреса отправителя фрагментированных пакетов. Такая ситуация возникла бы, например, если IP-адреса в пакетах были частными адресами (т.e., не были глобально уникальными), и MPLS использовался для туннелирования таких пакетов через общедоступную опорную сеть. Маршруты по умолчанию в ASBR не будет работать в таких условиях.

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

    Эта технология может быть весьма полезной, если ICMP-сообщением является "Time Exceeded" (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1).

    При копировании стека меток из исходного пакета в сообщение ICMP, значения меток должны копироваться точно, но значения TTL должны устанавливаться равными величине, размещенной в IP-заголовке ICMP-сообщения. Это значение TTL должно быть достаточным, чтобы позволить кружной маршрут, которому должен следовать ICMP-сообщение.

    Заметим, что если истечение TTL сопряжено с наличием петли маршрута, тогда в случае использования этой техники, ICMP-сообщение может циклить. Так как сообщение ICMP никогда не посылается в ответ на ICMP-пакет, и так как многие реализации ограничивают частоту посылки ICMP-сообщений, проблем это создать не должно.


    2.4. Обработка поля времени жизни

    2.4.1. Определения

    "Входное TTL" помеченного пакета по определению должно равняться значению поля TTL в записи наверху стека меток на момент получения пакета. "Выходное TTL" помеченного пакета по определению должно равняться большему из:

    a) входное значение TTL минус один,

    b) нуль.


    2.4.2. Протокольно независимые правила

    Если выходное TTL помеченного пакета =0, тогда помеченный пакет не должен более переадресовываться и пакет следует далее непомеченным. Время жизни пакета в сети считается истекшим. В зависимости от значения метки в стеке, пакет может быть просто отброшен, или он может быть передан сетевому слою для обработки ошибки (например, для генерации ICMP сообщения об ошибке, смотри раздел 2.3).

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

    Заметим, что выходное значение TTL является функцией входного значения TTL, и зависит оттого, были ли перед этим в стек занесены или извлечены какие то метки до переадресации пакета. Значения поля TTL в записях, за исключением верхней, никакого влияния не оказывают.


    2.4.3. Правила, зависящие от IP

    Мы определяем поле "IP TTL" равным величине поля IPv4 TTL, или значению поля IPv6 Hop Limit, в зависимости оттого, что используется.

    Когда IP-пакет помечен впервые, поле TTL в стеке должно быть установлено равным значению поля IP TTL.

    Когда все метки извлекаются из стека, и он оказывается пустым, значение поля IP TTL должно быть замещено величиной выходного TTL, как это определено выше. В случае IPv4 это потребует также корректировки контрольной суммы IP заголовка.

    Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.


    2.4.4. Преобразование различных инкапсуляций

    Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [9], и должен будет послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, описанной в данном документе, а будет послан уже с применением такой инкапсуляции.

    В этом случае значение "входное TTL" определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN, и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения "выходного TTL" определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.


    3. Фрагментация и определение MTU пути

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

    Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток. При коммутации меток, пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных, и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта.

    В этом разделе специфицируются правила обработки помеченных пакетов, которые являются "слишком большими". В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [4], и ЭВМ, работающие с IPv6 [7,8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.

    Вообще, ЭВМ IPv4, которые не используют определение MTU пути [4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.

    Некоторые ЭВМ, которые не используют определение MTU пути [4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы, и, следовательно, не будут фрагментироваться

    Если же IP-адрес отправителя и получателя находятся в разных автономных системах, это единственный случай, когда имеется риск фрагментации при пометке пакета.

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


    3.1. Терминология

    Что касается конкретного канала данных, можно использовать следующие термины:

    - Поле данных кадра:

    Содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы, и т.д.).

    Когда кадр несет в себе непомеченную IP-дейтограмму, поле данных кадра представляет собой саму IP-дейтограмму. Когда кадр несет в себе помеченную IP-дейтограмму, поле данных кадра состоит из записей стека меток и IP-дейтограммы.

    - Обычный максимальный размер поля данных кадра:

    Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов.

    - Истинный максимальный размер поля данных кадра:

    Максимальный размер поля данных кадра, который можно послать и получить через интерфейс канала данных.

    Для сетей Ethernet и 802.3, считается, что истинный максимальный размер поля данных кадра на 4-8 байта больше обычного максимального размера поля данных (поскольку ни переключатель, ни бридж не могут увеличить размер заголовка в процессе транспортировки пакета до следующего узла сети). Например, считается, что большинство оборудования Ethernet может принимать и посылать пакеты, содержащие, по крайней мере, 1504 или даже 1508 байт, поскольку заголовок Ethernet не имеет полей 802.1Q или 802.1p. В каналах PPP, истинный максимальный размер поля данных кадра может быть неограниченным.

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

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

    - Первично помеченная IP-дейтограмма:

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

    - Ранее помеченная IP-дейтограмма:

    IP-дейтограмма, которая уже была помечена до того, как была получена конкретным LSR.


    3.2. Максимальный исходный размер помеченной IP-дейтограммы

    Каждый LSR, который способен

    a) получать непомеченные IP-дейтограммы,

    b) добавлять метки в стек дейтограммы, и

    c) переадресовывать полученный в результате помеченный пакет,

    должен поддерживать конфигурационный параметр, называемый "максимальный размер первично помеченной IP-дейтограммы", который может быть установлен неотрицательным. Если этот конфигурационный параметр установлен равным нулю, он ни на что не влияет. Если он имеет положительное значение, то он используется следующим образом. Если:

    a) получена непомеченная IP-дейтограмма, и

    b) эта дейтограмма имеет в заголовке бит DF=0, и

    c) дейтограмма перед переадресацией должна быть помечена, и

    d) размер дейтограммы (до пометки) превышает значение данного параметра, тогда

    a)     Дейтограмма должна быть разделена на фрагменты с размером не больше, чем указано в данном параметре, и

    b)     Каждый фрагмент должен быть помечен и после этого переадресован.

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

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

    Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути.


    3.3. Когда помеченная IP-дейтограмма слишком велика?

    Помеченная IP-дейтограмма, чей размер превышает обычный максимальный размер поля данных канала, может рассматриваться как "слишком большая".

    Помеченная IP-дейтограмма, чей размер превышает истинный максимальный размер поля данных кадра канала, через который она должна переадресоваться, считается "слишком большой".

    Помеченная IP-дейтограмма, которая не является "слишком большой" должна передаваться без фрагментации.


    3.4. Обработка помеченных дейтограмм Ipv4, которые слишком длинны

    Если помеченная IPv4 дейтограмма "слишком велика", и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.

    Заметим, что отбрасывание таких дейтограмм является разумным, только если "Максимальный размер первично помеченной IP-дейтограммы" установлен равным ненулевому значению во всех LSR сети, способных добавлять метки в стек непомеченных IP-дейтограмм.

    Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должен быть выполнена следующая последовательность операций:

    1. Удалить записи в стеке, чтобы получить IP-дейтограмму.

    2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).

    3. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =0:

    a.      Разбить ее на фрагменты, каждый из которых должен иметь размер, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля данных кадра.

    b.      Преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма.

    c.      Переадресовать фрагменты.

    4. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =1:

    a.      Дейтограмма не должна переадресовываться.

    b.      Сформировать ICMP-сообщение "Адресат недостижим":

    i.            Установить значение поля [3] равным "Fragmentation Required and DF Set",

    ii.         Установить значение поля Next-Hop MTU [4] равным разности между эффективным максимальным размером поля данных кадра и величиной N

    c.      Если возможно, послать ICMP-сообщение "Адресат недостижим" отправителю отброшенной дейтограммы.


    3.5. Обработка помеченных дейтограмм IPv6, которые слишком длинны

    Чтобы обработать помеченную IPv6-дейтограмму, которая слишком велика, LSR должен реализовать следующий алгоритм:

    1. Удалить записи в стеке, чтобы получить IP-дейтограмму.

    2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).

    3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда:

    a.      Сформировать ICMP-сообщение "Too Big Message", и установить значение поля Next-Hop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N.

    b.      Если возможно, послать отправителю дейтограммы ICMP-сообщение "Too Big Message".

    c.      Отбросить помеченную IPv6-дейтограмму.

    4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда

    a.      Преобразовать ее в фрагменты, каждый из которых должен быть по крайней на N байт меньше, чем эффективный максимальный размер поля данных кадра.

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

    c.      Переадресовать фрагменты.

    Восстановление сообщения из фрагментов осуществляется конечным получателем.


    3.6. Реализация с учетом определения MTU пути

    Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются "слишком большими", связаны с процедурами определения MTU пути RFC 1191 [4]. ЭВМ, которые используют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n маркеров, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.

    Другими словами, дейтограммы от ЭВМ, которые используют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1, и таким образом не могут быть фрагментированы в любом случае.

    Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна посылка отправителю ICMP сообщения "Destination Unreachable". Смотри раздел 2.3. Если невозможна посылка отправителю слишком большой дейтограммы ICMP-сообщения из MPLS "туннеля", но конфигурация сети предоставляет возможность LSR конца туннеля получать слишком большие пакеты, которые должны проходить через туннель, тогда:

    - LSR на передающем конце туннеля должен уметь определять MTU туннеля в целом. Он может это сделать путем посылки пакетов через туннель в направлении его приемной части, и выполняя процедуру определения MTU пути для этих пакетов.

    - Всякий раз, когда передающий конец туннеля должен посылать пакет в туннель, и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение "Destination Unreachable" узлу, приславшему пакет с кодом "Fragmentation Required and DF Set ", и полем Next-Hop MTU установленным так, как показано выше.


    4. Передача помеченных пакетов через PPP

    Протокол PPP (Point-to-Point Protocol) [6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.

    В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP.


    4.1. Введение

    PPP содержит три основные компонента:

    1. Метод инкапсуляции мультипротокольных дейтограмм.

    2. Протокол управления каналом LCP (Link Control Protocol ) установления, конфигурации и тестирования канала.

    3. Семейство протоколов управления сетью для установления и конфигурирования различных протоколов сетевого уровня.

    Для того чтобы установить связь через канал точка-точка, каждый конец PPP канала должен сначала послать LCP-пакеты, чтобы сконфигурировать и протестировать канал. После того как канал установлен и согласованы опционные возможности, как это требует LCP, PPP должен послать пакеты "MPLS Control Protocol", чтобы разрешить посылку помеченных пакетов. Как только "MPLS Control Protocol" оказался открыт, можно посылать помеченные пакеты через канал. Канал будет оставаться сконфигурирован для коммуникаций, пока управляющие протокольные пакеты LCP или MPLS его не закроют, или пока не произойдет какое-то внешнее событие (сработает таймер пассивности или не вмешается сетевой администратор).


    4.2. Протокол управления PPP для MPLS

    Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться.

    Протокол управления MPLS тождественен протоколу управления каналом [6] за следующими исключениями:

    1. Модификации кадра

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


    2. Поле протокола канального уровня

    В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS).


    3. Поле кода

    Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects.


    4. Таймауты

    Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит таймаут в ожидании Configure-Ack или других откликов.


    4.3. Посылка помеченных пакетов

    Прежде чем какие-либо пакеты будут посланы, PPP должен достичь фазы протокола сетевого уровня, и управляющий протокол MPLS должен стать активным (состояние Opened).

    В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же что и максимальная длина информационного поля инкапсулированного пакета PPP.

    Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.


    5. Пересылка помеченных пакетов в среде LAN

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

    Шестнадцатеричный код Ethertype 8847 используется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.

    Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов. Процедура выбора одной из этих инкапсуляций находится вне пределов рассмотрения данного документа.


    6. Соображения IANA

    Значения меток 0-15 включительно имеют специальное назначение, как это определено в данном документе, или как позднее будет задано IANA. В этом документе, значения меток 0-3 специфицированы в разделе 2.1. Значения меток 4-15 могут быть определены IANA, на основе согласия с IETF.


    7. Соображения безопасности

    Инкапсуляция MPLS, которая специфицирована здесь, не предполагает какой-либо дополнительной безопасности, помимо той, что заложена в архитектуре MPLS [1] или в структуре протокола сетевого уровня.

    Существует два соображения безопасности, следующие из архитектуры MPLS и рассматриваемые здесь:

    - Некоторые маршрутизаторы могут реализовать процедуры безопасности, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Эти процедуры не будут работать, когда используется MPLS-инкапсуляция, так как эта инкапсуляция имеет варьируемый размер.

    - Метка MPLS имеет силу в результате соглашения между LSR, который заносит метку в стек ("автор метки"), и LSR, который интерпретирует эту метку ("читатель метки"). Однако стек меток не предлагает никаких средств определения того, кто является автором конкретной метки. Если помеченные пакеты восприняты от ненадежных источников, результатом может стать то, что пакеты будут маршрутизированы незаконным образом.


    8. Библиография

    [1] Rosen, E., Viswanathan, A., и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

    [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

    [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

    [4] Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

    [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

    [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

    [7] Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995.

    [8] McCann, J., Deering, S. и J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

    [9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, "MPLS Using LDP и ATM VC Switching", RFC 3035, January 2001.

    Previous: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.20 Требования для управления трафиком


    previous up down next index index
    Previous: 4.4.19 Кодирование меток в MPLS    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)

    4.4.20 Требования для управления трафиком
    Семенов Ю.А. (ГНЦ ИТЭФ)

    D. Awduche, Requirements for Traffic Engineering Over MPLS, RFC-2702


    1.0. Введение

    Мультипротокольная коммутация пакетов по меткам (MPLS) [1,2] интегрирует в себе технику операций с метками и сетевую маршрутизацию. Базовой идеей является присвоение меток фиксированной длины пакетам на входе облака MPLS (базирующегося на концепции переадресации классов эквивалентности [1,2]). Всюду внутри домена MPLS, метки, присвоенные пакету, используются для принятия решения о переадресации (обычно без рассмотрения исходных заголовков пакета).

    Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [1,2,3]).

    Этот документ ориентирован исключительно на управление трафиком (Traffic Engineering) в рамках MPLS. Главной целью является рассмотрение требований управления трафиком в больших опорных сетях Интернет. Описаны базовые возможности и функциональности, которым должна соответствовать реализация MPLS.

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

    Предлагается архитектура, которая включает в себя MPLS и RSVP, чтобы предоставить масштабируемые дифференцированные услуги и управление трафиком в Интернет.


    2.0. Управление трафиком

    В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами. В этом разделе обосновываются требования, предъявляемые к MPLS.

    Управление трафиком (TE) связано с оптимизацией рабочих характеристик сетей. Вообще, ТЕ включает в себя технологию и научные принципы измерения, моделирования, описание, управление трафиком Интернет и приложение таких знаний и техники для получения определенных рабочих характеристик.

    Главной целью управления трафиком в Интернет является достижение эффективной и надежной работы сети. Управление трафиком стало непременной функцией многих автономных систем, из-за высокой стоимости услуг Интернет.


    2.1. Объективные характеристики управления трафиком

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

    1. ориентированные на трафик или

    2. ориентированные на ресурсы.

    Задачи, ориентированные на управление трафиком, включают в себя аспекты улучшения QoS информационных потоков. В модели "оптимальных усилий" для Интернет-сервиса ключевая задача управления трафиком включает в себя: минимизацию потерь пакетов и задержек, оптимизацию пропускной способности и согласование наилучшего уровня услуг. В данной модели минимизация вероятности потери пакетов является наиболее важным аспектом. Статистически заданные характеристики трафика (такие как разброс времени доставки пакетов, вероятность потери и максимальное время доставки) становятся важными в грядущих дифференцированных услугах Интернет. Одним из подходов решения таких проблем является оптимизация использования всех имеющихся ресурсов сети. В частности, желательно гарантировать, чтобы субнаборы сетевых ресурсов не были перегружены, в то время как аналогичные ресурсы на альтернативных маршрутах недогружены. Полоса пропускания является критическим ресурсом современных сетей. Следовательно, центральной функцией управления трафиком является эффективное управление пропускной способностью.

    Минимизация перегрузок является первичной задачей. Здесь речь идет не о кратковременных перегрузках, а о долгосрочных, влияющих на поведение сети в целом. Перегрузка обычно проявляется двояко:

    1. Когда сетевых ресурсов недостаточно или они не соответствуют существующей загрузке.

    2. Когда потоки трафика неэффективно распределены по имеющимся ресурсам.

    Первый тип проблем перегрузки может быть решен путем:

    (i)                 расширения ресурса, или

    (ii)               применением классических средств управления перегрузкой, или

    (iii)           сочетанием этих подходов. Классическое управление перегрузкой пытается регулировать уровень потребности, снижая его до имеющегося в распоряжении уровня ресурсов. Классическое управление перегрузкой включает в себя: ограничение потока, управление шириной окна для потока, управление очередями в маршрутизаторе, диспетчеризацию и т.д. (смотри [8]).

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

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

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


    2.2. Управление трафиком и ресурсами

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

    В идеале управляющие действия должны включать:

    1. Модификацию параметров управления трафиком,

    2. Модификацию параметров, связанных с маршрутизацией, и

    3. Модификацию атрибутов и констант, связанных с ресурсами.

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


    2.3. Ограничения механизмов управления IGP

    В этом подразделе рассматриваются некоторые хорошо известные ограничения современных IGP с точки зрения управления трафиком.

    Возможности управления, предлагаемые существующими внутренними протоколами маршрутизации шлюзов Интернет, не соответствуют требованиям управления трафиком. Это делает трудным актуализировать эффективные политики, предназначенные для решения проблем совершенствования работы сети. Действительно, IGP, базирующиеся на алгоритмах кратчайшего пути, вносят заметный вклад в проблемы перегрузки в автономных системах Интернет. Алгоритмы SPF базируются на простой аддитивной метрике. Эти протоколы управляются топологией, так что полоса пропускания и параметры трафика не являются факторами, рассматриваемыми в процессе принятия маршрутных решений. Следовательно, перегрузка часто происходит, когда:

    1. кратчайшие пути нескольких потоков трафика объединяются в каких-то каналах или интерфейсах маршрутизатора, или

    2. данный трафик потока маршрутизирован через канал или интерфейс маршрутизатора, который не имеет достаточной полосы пропускания.

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

    Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких как IP поверх ATM или IP поверх frame relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загруженные каналы.

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


    3.0. MPLS и управление трафиком

    В этом разделе дается обзор применимости MPLS для управления трафиком. В последующих разделах обсуждается набор возможностей, необходимых для удовлетворения требований управления трафиком.

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

    Концепция каналов передачи данных MPLS используется достаточно широко в данном документе. Согласно Li и Rekhter [3], канал передачи данных представляет собой объединение потоков данных одного и того же класса, которые следуют маршруту с коммутацией пакетов по меткам. Канал передачи данных представляет собой абстракцию трафика, с которой могут быть ассоциированы определенные характеристики. Полезно рассматривать каналы передачи данных как объекты, которые можно маршрутизировать, то есть, путь, по которому переносятся данные, может меняться. С этой точки зрения, каналы передачи данных подобны виртуальным каналам в сетях ATM и Frame Relay. Важно, однако, подчеркнуть, что существует фундаментальное отличие между каналом передачи данных и путем. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит трафик. На практике, термины LSP и канал передачи данных часто используются синонимично.

    Привлекательность MPLS для управления трафиком может быть ассоциирована со следующими факторами:

    (1)         явные пути с коммутацией меток (которые не ограничиваются парадигмой переадресации, когда маршрут определяется на основе адреса места назначения) могут быть легко сформированы сетевым администратором или посредством стандартных протоколов,

    (2)         LSP могут поддерживаться эффективно,

    (3)         Каналы передачи данных могут быть смоделированы и поставлены в соответствие LSP,

    (4)         Набор атрибутов может быть ассоциирован с каналами передачи данных, которые регулируют их рабочие характеристики,

    (5)         Набор атрибутов может быть ассоциирован с ресурсами, которые ограничивают положение LSP и каналов передачи данных,

    (6)         MPLS позволяет как агрегацию так и дисагрегацию трафика, в то время как классическая переадресация на основе IP-адреса места назначения допускает только агрегацию,

    (7)         Относительно легко интегрировать "маршрутизацию на основе ограничений" в рамках MPLS,

    (8)      Хорошая реализация MPLS может предложить заметно более низкую избыточность, чем конкурирующие альтернативы управления трафиком.

    Кроме того, через механизм коммутации меток MPLS позволяет наложить на современную модель маршрутизации Интернет квазиканальную коммутацию. Многие существующие предложения для управления трафиком посредством MPLS концентрируются на возможности формирования LSP. Хотя такая возможность является фундаментальной для управления трафиком, этого реально недостаточно.


    3.1. Наведенный MPLS-граф

    В данном подразделе вводится концепция "наведенного MPLS-графа", которая является центральной при управлении трафиком в сфере MPLS. Наведенный MPLS-граф аналогичен виртуальной топологии в модели наложений. Он логически проектируется на физическую сеть путем выбора LSP для каналов транспортировки трафика.

    Наведенный MPLS-граф состоит из набора LSR, которые представляют собой узлы графа, и набора LSP, которые предоставляют логические соединение точка-точка между указанными LSR, и, следовательно, служат в качестве каналов наведенного графа. Имеется возможность сформировать иерархический наведенный MPLS-граф, базирующийся на концепции стеков меток (смотри [1]).

    Наведенные MPLS-графы важны потому, что базовые проблемы управления полосой пропускания в MPLS определяются тем, как эффективно совместить наведенный MPLS-граф с физической топологией сети. Абстракция наведенного MPLS-графа формализуется ниже.

    Пусть G = (V, E, c) является графом, отражающим физическую топологию сети. Здесь, V - набор узлов сети и E - набор каналов; то есть, для v и w из V, объект (v,w) содержится в E, если v и w являются непосредственно связанными в рамках G. Параметр "c" представляет собой набор емкостей и других ограничений, сопряженных с E и V. Мы будем рассматривать G как "основу" сетевой топологии.

    Пусть H = (U, F, d) является наведенным MPLS-графом, где U является субнабором V, представляющим набор LSR в сети, или более точно набор LSR, которые являются конечными точками, по крайней мере, одного LSP. Здесь, F представляет собой набор LSP, так что для x и y из U, объект (x, y) находится в F, если существует LSP с x и y в качестве конечных точек. Параметр "d" представляет собой набор требований и ограничений, ассоциированных с F. Очевидно, H является ориентированным графом. Можно видеть, что H зависит от переходных характеристик G.


    3.2. Фундаментальные проблемы управления трафиком в MPLS

    Существует три фундаментальных проблемы, относящиеся к управлению трафиком в MPLS.

    - Первая проблема касается того, как определять соответствие пакетов определенному классу FEC (Forwarding Equivalence Class).

    - Вторая проблема касается того, как определять соответствие FEC и каналов передачи данных.

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

    Данный документ не касается первых двух перечисленных проблем (хотя они весьма важны). Вместо этого, остальная часть документа посвящена возможностям, которые позволяют третей функции осуществлять эффективную и надежную работу сетей. Установление соответствия между наведенным MPLS-графом (H) и базовой топологией сети (G) является достаточно важной проблемой.


    4.0. Расширенные возможности управления трафиком с помощью MPLS

    В предыдущих разделах рассмотрены базовые функции управления трафиком в современном Интернет. Остальная часть документа описывает функциональные возможности, необходимые для полномасштабного поддержания управления трафиком в больших сетях через посредство MPLS .

    Предлагаемые возможности включают в себя:

    1. Набор атрибутов, связанных с каналами передачи данных, совокупность которых характеризует рабочее состояние сети.

    2. Набор атрибутов, связанных с ресурсами, которые ограничивают размещение пути информационных потоков. Они могут рассматриваться также как топологические ограничения.

    3. "Маршрутизация на основе ограничений", которая используется для выбора пути для канала передачи данных в соответствии с набором параметров пунктов 1 и 2, приведенных выше. Маршрутизация на основе ограничений не должна являться частью протокола MPLS. Однако они должны быть тесно связаны.

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

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


    5.0. Атрибуты и характеристики канала передачи данных

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

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

    - В одноклассной модели обслуживания, такой как современный Интернет, канал передачи данных может включать в себя все потоки между входным LSR и выходным LSR.

    - Каналы передачи данных являются маршрутизируемыми объектами (аналогично ATM VC).

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

    - Каналы передачи данных являются однонаправленными.

    На практике, канал передачи данных может характеризоваться своими входным и выходным LSR, FEC, которому он соответствует, и набором атрибутов, которые определяют его рабочие характеристики.

    Имеется два пункта особой важности: (1) параметризация каналов передачи данных и (2) положение маршрута и правила управления каналом передачи данных.


    5.1. Двунаправленные каналы передачи данных

    Хотя каналы передачи данных (traffic trunks) являются концептуально однонаправленными, во многих практических контекстах, полезно одновременно анализировать два канала передачи данных с идентичными конечными точками, но с разным направлением потоков. Два канала передачи данных логически связаны друг с другом. Один канал, называемый прямым, транспортирует трафик от исходного узла к узлу места назначения. Другой канал, называемый обратным, транспортирует трафик от узла места назначения к исходному узлу. Объединение двух таких каналов называется двунаправленным каналом передачи данных BTT (bidirectional traffic trunk), если выполняются следующие два условия:

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

    - Ни один из образующих такую пару каналов не может существовать отдельно. То есть, оба создаются и исчезают одновременно.

    Следует также рассмотреть топологические свойства BTT. BTT может быть топологически симметричным или асимметричным. BTT считается "топологически симметричным", если составляющие его каналы передачи данных имеют одни и те же физические маршруты. Если, однако, составляющие его каналы передачи данных маршрутизированы через разные пути, тогда BTT называется "топологически асимметричным".

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


    5.2. Базовые операции для канала передачи данных

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

    - Установить (Establish): создать канал передачи данных.

    - Активировать (Activate): запустить информационный обмен через канал передачи данных. Установление и активизация канала передачи данных логически не связанные события. Они могут, однако, быть реализованы в рамках одной операции.

    - Деактивировать (Deactivate): Останавливать информационный поток через канал передачи данных.

    - Модифицировать атрибуты (Modify Attributes): Изменить атрибуты канала передачи данных.

    - Сменить маршрут (Reroute): Изменить маршрут канала передачи данных. Это может быть сделано административно или автоматически с помощью базовых протоколов.

    - Ликвидировать (Destroy): Ликвидировать канал передачи данных и уведомить об имеющихся ресурсах. К таким ресурсам относится пространство меток и, возможно, дополнительная полоса пропускания.

    Выше рассматривались базовые операции каналов передачи данных. Возможны и дополнительные операции, сопряженные с реализацией политики и формированием трафика.


    5.3. Мониторирование аккоунтинга и работы

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

    Возможность получения статистики на уровне канала передачи данных так важна, что это следует рассматривать как существенное требование управления трафиком через MPLS.


    5.4. Базовые атрибуты управления трафиком каналов передачи данных

    Атрибут канала передачи данных является параметром, который влияет на рабочие характеристики канала.

    Атрибуты могут быть явно присвоены каналам передачи данных администратором или заданы неявно базовыми протоколами, когда пакеты классифицируются и сортируются по классам эквивалентности (FEC) на входе в область MPLS. Независимо оттого как атрибуты были первоначально присвоены, для целей управления трафиком нужно допустить их административную модификацию.

    Основные атрибуты каналов передачи данных наиболее важные для управления трафиком перечислены ниже.

    - Атрибуты параметров трафика

    - Атрибуты управления и выбора пути

    - Атрибут приоритета

    - Атрибут приоритетной подмены (Preemption)

    - Атрибут устойчивости (Resilience)

    - Атрибут политики (Policing)

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

    Приоритет и приоритетная подмена (preemption) могут рассматриваться как относительные атрибуты, так как они выражают определенные отношения между каналами передачи данных. Концептуально, эти двоичные отношения определяют способ взаимодействия каналов между собой, когда они соревнуются за получения сетевых ресурсов в процессе установления пути и его рабочих параметров.


    5.5. Атрибуты параметров трафика

    Параметры трафика могут использоваться при сборе данных об информационных потоках (или более точно FEC), которые надлежит транспортировать через информационный канал. Такие характеристики могут включать пиковые загрузки, средние потоки. Параметры трафика важны потому, что они указывают требования к ресурсам канала передачи данных. Это полезно для выделения ресурсов и исключения перегрузки за счет политики предвидения.


    5.6. Атрибуты управления и выбора пути

    Атрибуты управления и выбора пути определяют правила выбора пути канала передачи данных, а также правила работы с маршрутами, которые уже существуют.

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

    В разделе 7 описана маршрутизация, где путь вычисляется на основе определенных ограничений.

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

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


    5.6.1. Административно специфицированные маршруты

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

    Атрибут "path preference rule" (правило предпочтения пути) должно быть ассоциировано с административно специфицированными путями. Атрибут "правила предпочтения пути" представляет собой двоичную переменную, которая указывает, является ли административно сконфигурированный путь "обязательным" или нет.

    Если административно сконфигурированный путь выбран с "обязательным" атрибутом, должен использоваться этот (и только этот) путь. Если обязательный путь недопустим (например, конечные пункты топологически разделены), или, если путь не может быть использован, так как его ресурсы неадекватны, тогда процесс установки пути (setup) потерпит неудачу. Другими словами, если путь специфицирован как обязательный, тогда альтернативный путь не может использоваться ни при каких обстоятельствах. Обязательный путь, который успешно приписан, является неявно закрепленным. Раз путь присвоен, его нельзя изменить, а только ликвидировать или заменить новым.

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


    5.6.2. Иерархия предпочтений для мультимаршрутов

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


    5.6.3. Атрибуты сродства классов ресурсов (Resource Class Affinity)

    Атрибуты сродства классов ресурсов, ассоциированные с каналом передачи данных, могут использоваться для спецификации класса ресурсов (смотри раздел 6), которые следует включить явно или исключить из пути канала передачи данных. Эти атрибуты политики, которые могут использоваться для введения дополнительных ограничений для маршрута канала передачи данных. Атрибуты сродства классов ресурсов могут быть специфицированы для трафика в виде последовательности пар:

    <resource-class, affinity>; <resource-class, affinity>;

    Параметр resource-class идентифицирует класс ресурса, для которого определено соотношение сродства в отношении канала передачи данных. Параметр affinity указывает на соотношение сродства; то есть, включены или исключены члены класса ресурсов в путь канала передачи данных. В частности, параметр affinity может быть двоичной величиной, которая принимает одно из следующих значений: (1) явное включение, и (2) явное исключение.

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

    Если не специфицировано никакого атрибута сродства класса, тогда предполагается значение отношения сродства " don't care" (безразлично) между каналом передачи данных и ресурсами. То есть, не существует никаких требований по включению или исключению каких-либо ресурсов для пути канала передачи данных. На практике - это режим по умолчанию.

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

    "Маршрутизация на основе ограничений" (смотри раздел 7.0) может использоваться для вычисления точного пути для канала передачи данных так, чтобы удовлетворить ограничениям сродства класса ресурсов следующим образом:

    1. Для прямого включения, перед началом вычисления пути удалить все ресурсы, не принадлежащие специфицированным классам.

    2. Для прямого исключения перед началом вычисления пути, удалить все ресурсы, принадлежащие специфицированным классам.


    5.6.4. Атрибут адаптивности

    Характеристики сети и ее состояние изменяются со временем. Например, появляются новые ресурсы, утраченные ресурсы могут быть снова активизированы, а выделенные ресурсы могут оказаться недоступными. Вообще, иногда могут оказаться доступными более эффективные пути. Следовательно, с точки зрения управления трафиком, необходимо иметь административные параметры управления, которые могут использоваться для спецификации того, как канал передачи данных будет реагировать на этот динамизм. При некоторых сценариях, может оказаться желательным динамически изменить пути некоторых информационных каналов в ответ на изменения состояния сети. Этот процесс называется реоптимизацией. При других сценариях реоптимизация может оказаться нежелательной.

    Атрибут адаптивности (adaptivity) является частью блока параметров пути, ассоциированного с каналом передачи данных. Атрибут адаптивности, ассоциированный с каналом передачи данных, указывает на то, является ли канал субъектом реоптимизации. То есть, атрибут адаптивности представляет собой двоичную переменную, которая принимает одно из следующих значений: (1) разрешить реоптимизацию и (2) запретить реоптимизацию.

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

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

    Следует заметить, что реоптимизация не то же самое что и устойчивость к внешним воздействиям. Для спецификации характеристик устойчивости канала передачи данных используются другие атрибуты (смотри раздел 5.9). На практике, представлялось бы разумным ожидать, что канал передачи данных, подвергающийся реоптимизации, должен быть устойчив против отказов вдоль его пути. Однако канал передачи данных, который не подвергается реоптимизации и чей маршрут не специфицирован административно как "обязательный", также должен быть устойчивым против отказов связей и узлов вдоль своего пути.

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


    5.6.5. Распределение нагрузки в параллельных каналах передачи данных

    Распределение нагрузки по нескольким параллельным каналам передачи данных между двумя узлами является крайне важным. Во многих практических контекстах, суммарный трафик между узлами может быть таким, что ни один канал в отдельности (следовательно, и ни один маршрут) не сможет его пропустить. Однако суммарный поток может быть меньше, чем максимально допустимый поток через поперечное сечение ("min-cut"), разделяющее два узла. В этом случае, единственно возможным решением может быть деление трафика на несколько потоков.

    В домене MPLS, эта проблема может быть решена с помощью нескольких каналов, соединяющих два узла. Следовательно, нужны гибкие средства назначения нагрузки для параллельных каналов передачи данных, соединяющих два узла.

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


    5.7. Атрибут приоритета

    Атрибут priority (приоритет) определяет относительную важность канала передачи данных. Если с MPLS используется маршрутизация, базирующаяся на ограничениях, тогда приоритеты становятся очень важными, так как они используются в случае отказов для определения порядка, в котором выбираются пути для канала передачи данных из имеющегося списка.

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


    5.8. Атрибут Preemption

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

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

    Атрибут preemption может использоваться для спецификации четырех режимов приоритетного замещения для канала передачи данных: (1) замещающий объект активирован (preemptor enabled), (2) non-preemptor, (3) допускающий подмену и (4) не допускающий подмены. Канал передачи данных, где разрешено приоритетное замещение (preemptor enabled) может заменять каналы с более низким приоритетом, признанные, как приемлемые для замены. Канал передачи, специфицированный, как не подлежащий подмене, не может быть замещен каким-либо иным каналом, вне зависимости от их относительных приоритетов. Канал передачи данных, допускающий замещение, может быть замещен другим каналом с более высоким приоритетом, который имеет атрибут preemptor enabled.

    Достаточно просто понять, что некоторые режимы замещения являются взаимно исключающими. Используя схему нумерации, описанную выше, можно назвать допустимые комбинации режимов для канала передачи данных: (1, 3), (1, 4), (2, 3) и (2, 4). Комбинация (2, 4) является режимом по умолчанию.

    Канал передачи данных, скажем "A", может заместить другой канал, скажем "B", только если все следующие пять условий будут выполнены:

    (i)                 " A" имеет относительно более высокий приоритет, чем "B",

    (ii)               " A" претендует на ресурс, используемый "B",

    (iii)             ресурс не может одновременно поддерживать "A" и "B",

    (iv)              " A" может быть приемником, и

    (v)                "B" допускает подмену.

    Атрибут preemption не рассматривается, как обязательный атрибут современной модели обслуживания в Интернет (best effort service), хотя и является полезным. Однако, в сценарии с дифференциальными услугами, необходимость подмены становится очевидной. Более того, в появляющихся архитектурах оптического Интернет, где функции защиты и восстановления, чтобы уменьшить цену, могут быть перенесены с оптического уровня на информационные сетевые элементы (такие как гигабитные и терабитные маршрутизаторы с коммутацией по меткам), стратегии приоритетного замещения могут использоваться для сокращения времени восстановления канала в условиях сбоев.


    5.9. Атрибут устойчивости (Resilience)

    Атрибут resilience определяет поведение канала передачи данных в случае возникновения ошибок. То есть, когда ошибка происходит на пути, через который проходит канал. При таких обстоятельствах должны быть рассмотрены следующие проблемы: (1) детектирование ошибки, (2) уведомление об ошибке, (3) восстановление после сбоя. Очевидно, реализация MPLS должна содержать механизмы для решения всех этих задач.

    Многие политики восстановления могут быть специфицированы для каналов передачи данных, чьи маршруты подвержены отказам. Ниже представлены примеры приемлемых схем:

    1. Не нужно изменять маршрут канала передачи данных (traffic trunk). Например, схема живучести может уже существовать и быть реализована за счет альтернативного механизма, который гарантирует непрерывность обслуживания в случае сбоя без необходимости изменения маршрута канала передачи данных. Примером такой альтернативной схемы (конечно существует и много других), является ситуация, когда между двумя узлами имеется несколько параллельных каналов, и в случае отказа одного LSP, его трафик будет перераспределен между остальными LSP согласно некоторой заданной политике.

    2. Перенаправить маршрут на приемлемый путь с достаточными ресурсами. Если такового нет, тогда маршрут не изменять.

    3. Поменять маршрут на любой доступный, игнорируя ограничения по ресурсам.

    4. Возможно много других схем, включая комбинации перечисленных выше.

    "Базовый" атрибут resilience указывает на процедуру восстановления, которая должна быть запущена для данного канала, при возникновении отказа. В частности, "базовый" атрибут resilience является двоичной переменной, которая определяет, будет ли данный канал изменять маршрут, если сегмент его пути выдал отказ. "Расширенный" атрибут resilience может использоваться для подробной спецификации действий в случае сценария отказа. Например, расширенный атрибут resilience может специфицировать набор альтернативных путей, которые следует использовать в случае отказа, а также правил, которые управляют относительным предпочтением для каждого специфицированного пути. Атрибуты resilience обеспечивают тесное взаимодействие между MPLS и маршрутизацией.


    5.10 Атрибут Policing

    Атрибут policing определяет действия, которые следует предпринять в рамках базовых протоколов, когда канал передачи данных становится нерабочим. То есть, когда какие-то параметры канала отклонились за оговоренные пределы. Вообще, атрибуты policing могут указывать, является ли неуправляемый канал передачи данных лимитированным по полосе пропускания, или он просто переадресуется без каких-либо действий, учитывающих местную политику. Если используется политика, тогда для реализации таких функций могут использоваться адаптации алгоритмов, таких как ATM GCRA [11].

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

    Следовательно, с точки зрения управления трафиком необходимо иметь возможность административно разрешать и запрещать использование политики для каждого канала передачи данных (traffic trun).


    6.0. Атрибуты ресурсов

    Атрибуты resource являются частью параметров состояния топологии, которые используются, чтобы установить ограничения на маршрутизацию каналов передачи данных в рамках имеющихся ресурсов.


    6.1. Максимально выделяемая доля (Maximum Allocation Multiplie)

    Максимально выделяемая доля MAM (maximum allocation multiplier) ресурса является административно задаваемым атрибутом, который определяет долю ресурса, доступную для канала передачи данных. Этот атрибут используется в основном для распределения полосы пропускания. Однако он может быть применен также для резервирования ресурсов LSR. Концепция MAM аналогична концепции параметров подписки и резервирования в сетях frame relay и ATM.

    Значения MAM могут быть выбраны так, чтобы ресурс был недораспределен или перераспределен. Ресурс считается недораспределенным, если суммарные требования всех каналов передачи данных, которые могут его использовать, меньше емкости ресурса. В противном случае ресурс считается перераспределенным.

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

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


    6.2. Атрибут класса ресурса

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

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

    1. Реализации одинаковых политик для набора ресурсов, которые не обязательно находятся в одной и той же топологической области.

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

    3. Ограничения положения каналов передачи данных для заданного субнабора ресурсов.

    4. Реализации обобщенного включения/исключения политик.

    5. Реализации политики ограничения локальности трафика. То есть, политики, которая ищет способы размещения трафика в пределах оговоренных топологических областей сети.

    Кроме того, атрибуты класса ресурса могут использоваться для целей идентификации.

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


    7.0. Маршрутизация, базирующаяся на ограничениях

    В этом разделе обсуждается вопросы, связанные с маршрутизацией, основанной на ограничениях, используемой в доменах MPLS. В современной терминологии, маршрутизация, основанная на ограничениях, часто называется "QoS маршрутизацией", смотри [5,6,7,10].

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

    Маршрутизация на основе ограничений делает возможным резервирование ресурсов по запросу, сосуществование с имеющимися внутренними протоколами маршрутизации Интернет, работающими по принципу шаг-за-шагом.

    Маршрутизация на основе ограничений, использует следующие данные в качестве входных:

    - Атрибуты, связанные с каналами передачи данных (traffic trunks).

    - Атрибуты, связанные с ресурсами.

    - Другую информацию, характеризующую состояние топологии сети.

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

    Маршрутизация на основе ограничений может существенно сократить уровень ручной конфигурации и необходимого вмешательства для актуализации политики управления трафиком (Traffic Engineering policies).

    На практике инженер трафика, оператор, или даже автоматическая система специфицирует конечные точки канала передачи данных (traffic trunk) и приписывает набор атрибутов, который объединяет ожидаемые рабочие характеристики канала. Предполагается, что маршрутизация на основе ограничений найдет приемлемый путь, который удовлетворит имеющимся ожиданиям. Если необходимо для более тонкой оптимизации, инженер трафика или система поддержки управления трафиком может затем использовать административно сконфигурированные маршруты.


    7.1 Базовые характеристики маршрутизации на основе ограничений

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

    Вообще, известно, что проблема маршрутизации на основе ограничений трудно разрешима для большинства реалистичных ограничений. Однако, на практике для нахождения приемлемого пути, если он существует, может использоваться очень простая хорошо известная эвристика (смотри, например, [9]):

    - Сначала отбрасываются ресурсы, которые не удовлетворяют требованиям атрибутов канала передачи данных.

    - Затем, для оставшегося графа связей запускается алгоритм поиска кратчайшего пути.

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


    7.2 Соображения реализации

    Многие коммерческие реализации коммутаторов frame relay и ATM уже поддерживают некоторые аспекты маршрутизации на основе ограничений. Для таких приборов или для новых MPLS-реализаций должно быть относительно просто расширить существующие реализации маршрутизации на основе ограничений, чтобы удовлетворить специфическим требованиям MPLS.

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

    1. Путем расширения существующих IGP протоколов, таких как OSPF и IS-IS для поддержки маршрутизации на основе ограничений. Прилагаются усилия для решения этой задачи в отношении протокола OSPF (смотри [5,7]).

    2. Путем добавления процесса маршрутизации на основе ограничений в каждый маршрутизатор, который может сосуществовать с имеющимися IGP. Этот сценарий представлен на рис. 1.

    Рис. 1. Процесс маршрутизации, базирующийся на ограничениях, на уровне 3 LSR

    Существует много важных деталей, связанных с реализацией маршрутизации на основе ограничений в устройствах уровня 3, которые здесь не обсуждались. Сюда входит следующее:

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

    - Механизмы работы с топологической статусной информацией.

    - Взаимодействие между процессами маршрутизации на основе ограничений и процессами традиционных IGP.

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

    - Механизмы выполнение требований устойчивости и живучести каналов передачи данных.

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


    8.0. Заключение

    В данном документе представлен набор требований для реализации управления трафиком (Traffic Engineering) посредством MPLS. Описаны многие возможности, целью которых является улучшение применимости MPLS для управления трафиком в Интернет.

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


    9.0. Библиография

    [1] Rosen, E., Viswanathan, A. и R. Callon, "A Proposed Architecture for MPLS", Work in Progress.

    [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. и A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress.

    [3] Li, T. и Y. Rekhter, "Provider Architecture for Differentiated Services и Traffic Engineering (PASTE)", RFC 2430, October 1998.

    [4] Rekhter, Y., Davie , B., Katz, D., Rosen, E. и G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997.

    [5] Zhang, Z., Sanchez, C., Salkewicz, B. и E. Crawley "Quality of Service Extensions to OSPF", Work in Progress.

    [6] Crawley , E., Nair, F., Rajagopalan, B. и H. Sandick, "A Framework for QoS Based Routing in the Интернет", RFC 2386, August 1998.

    [7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. и D. Williams, "QoS Routing Mechanisms и OSPF Extensions", RFC 2676, August 1999.

    [8] C. Yang и A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995.

    [9] W. Lee, M. Hluchyi, и P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks,"IEEE Network, July 1995, pp 46-55.

    [10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996.

    Previous: 4.4.19 Кодирование меток в MPLS    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)


    previous up down next index index
    Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.5 Процедуры Интернет

    4.4.21 BGP/MPLS VPN
    Семенов Ю.А. (ГНЦ ИТЭФ)

    E. Rosen. RFC-2547, March 1999 (Перевод Семенова Ю.А.)


    Аннотация

    Описан метод, с помощью которого, например, сервис провайдер на IP опорной сети, может организовать для клиентов частные виртуальные сети (VPN). MPLS (мультипротокольная коммутация пакетов по меткам - Multiprotocol Label Switching) используется для переадресации пакетов по опорной сети, а BGP (Border Gateway Protocol) служит для прокладки маршрутов через опорную сеть. Главной целью метода является поддержка внешних опорных IP сетей, предлагающих услуги корпоративным сетям. Это делается достаточно просто для предприятия, сохраняя гибкость и масштабируемость для сервис провайдеров. Данная технология может быть также использована, чтобы формировать VPN , которая сама предоставляет IP-услуги клиентам.


    1. Введение

    1.1. Частные виртуальные сети

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

    Субнаборы, которые создаются, являются "Частными виртуальными сетями" (VPN). Два сайта имеют IP коннективность через опорную сеть, только если существует VPN, которая содержит в себе оба эти сайта. Два сайта, которые не имеют общих VPN, не имеют связи через опорную сеть.

    Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной "интранет". Если разные сайты в VPN принадлежат различным компаниям, VPN считается "экстранетом". Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты, как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами.

    Будем рассматривать случай, когда опорная сеть принадлежит и обслуживается одним или несколькими сервис провайдерами (SP). Владельцы сайтов являются клиентами SP. Будет ли конкретный набор сайтов VPN, определяется политикой клиентов. Некоторые клиенты могут пожелать, чтобы реализация политики осуществлялась исключительно SP. Другие клиенты могут осуществлять политику самостоятельно, или делить ответственность с SP. В данном документе, обсуждаются механизмы, которые могут быть применены для реализации такой политики. Механизмы, которые рассматриваются, являются достаточно общими, чтобы реализовать политику либо самим SP, либо клиентом VPN совместно с SP . Большая часть обсуждения, однако, посвящена последнему варианту.

    Механизмы, обсуждаемые в данном документе, допускают реализацию широкого диапазона политик. Например, в пределах данной VPN, каждому сайту позволяется иметь прямой маршрут до любого другого сайта ("полная сетка"), или можно выделить определенные пары сайтов, которые будут связаны друг с другом ("частичная сетка").

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


    1.2. Оконечные устройства

    Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge).

    Если конкретный сайт имеет одну ЭВМ, эта машина может быть оконечным устройством CE. Если конкретный сайт имеет одну субсеть, оконечным устройством CE может стать сетевой переключатель. Вообще, устройством CE может быть маршрутизатор, который называется в этом случае CE-маршрутизатором.

    Будем говорить, что PE-маршрутизатор подключен к определенной VPN, если он подключен к оконечному устройству CE, которое находится в VPN. Аналогично, будем считать, что маршрутизатор PE подключен к определенному сайту, если он подсоединен к устройству CE, которое находится в пределах этого сайта. Когда в качестве CE выступает маршрутизатор, он является маршрутным партнером PE, к которому подключен, но не является маршрутным партнером CE-маршрутизаторов в других сайтах. Маршрутизаторы в различных сайтах непосредственно не обмениваются маршрутной информацией. В действительности, они даже могут не знать о существовании друг друга (за исключением случая, когда это необходимо из соображений безопасности, смотри раздел 9). Как следствие, очень большие VPN (т.e., VPN с большим числом сайтов) хорошо поддерживаются, в то же время маршрутные стратегии каждого индивидуального сайта существенно упрощаются.

    Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, а клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP).


    1.3. VPN с перекрывающимися адресными пространствами

    Предположим, что любые две не пересекающиеся VPN (т.e., VPN, не имеющих общих сайтов) могут иметь перекрывающиеся адресные пространства. Один и тот же адрес может использоваться повторно для разных систем в различных VPN. Поскольку оконечное устройство имеет уникальный адрес в области VPN, которой оно принадлежит, оконечное устройство не нуждается в какой-либо дополнительной информации о VPN.

    В этой модели, владельцы VPN не имеют опорной сети, которую нужно администрировать, не имеют даже виртуальной опорной сети. SP не должен администрировать опорную сеть для каждой VPN. Оптимальной маршрутизацией является путь в опорной сети от сайт-к-сайту (в рамках ограничений политики, использованной при формировании VPN).


    1.4. VPN с разными маршрутами до одной и той же системы

    Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе в сайте будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C, а также экстранет, включающий в себя A, B, C и "чужой" сайт D. Будем считать, что сайт A является сервером, и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так что может контролироваться доступ трафика из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет.

    Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, он затем рассматривается как трафик, приходящий из сайта B, и следует маршрутом до узла A.


    1.5. Таблицы переадресации в PE

    Каждый маршрутизатор PE должен поддерживать несколько различных таблиц переадресации. Каждому сайту, к которому подключен PE, должна быть поставлена в соответствие такая таблица переадресации. Когда пакет получен от определенного сайта, происходит обращение к ассоциированной с этим сайтом таблицей переадресаций, чтобы определить, как маршрутизовать данный пакет. В таблицу переадресации, ассоциированную с сайтом S, записываются только маршруты, которые ведут к другим сайтам, которые принадлежат, по крайней мере, одной VPN общей с S. Это предотвращает коммуникации между сайтами, которые не принадлежат общим VPN, и это позволяет двум VPN, не имеющим общих сайтов, использовать общее или перекрывающееся адресное пространство.


    1.6. Маршрутизаторы опорной сети SP

    Опорная сеть SP состоит из PE-маршрутизаторов, а также их других маршрутизаторов (P-маршрутизаторы), которые не подключены к CE устройствам.

    Если каждый маршрутизатор в опорной сети SP должен поддерживать маршрутную информацию для всех VPN, поддерживаемых SP, такая модель будет иметь серьезные проблемы с масштабируемостью. Число поддерживаемых сайтов, будет лимитировано объемом маршрутной информации, хранимой одним маршрутизатором. Важно, следовательно, потребовать, чтобы маршрутная информация о конкретном VPN присутствовала только в тех PE-маршрутизаторах, которые соединены с этой VPN. В частности, P-маршрутизаторы не должны иметь какой-либо маршрутной информации о любых VPN.

    VPN может пользоваться услугами нескольких сервис-провайдеров. Предполагается, что когда путь между PE-маршрутизаторами пересекает границу между сетями SP, это делается согласно пиринговому соглашению, в рамках которого существует договоренность между двумя провайдерами. В частности, каждый провайдер должен доверять друг другу пересылку только корректной маршрутной информации, и передавать ее, в помеченных (в значении MPLS [9]) пакетах, только если эти пакеты были помечены отправителями, достойными доверия. Предполагается, что для маршрутов, коммутируемых по меткам, разрешается пересекать границы между сервис провайдерами.


    2. Сайты и CE

    С точки зрения конкретной опорной сети, набор IP-систем представляет собой сайт, если эти системы имеют взаимную коннективность, а коммуникации между ними происходят без использования опорной сети. Вообще, сайт образуется из набора систем, которые географически близки. Однако это не является верным всегда; две географические позиции, соединенные через выделенную линию и отстоящие друг от друга сколь угодно далеко, будут представлять собой один сайт, так как коммуникация между ними не предполагает применение опорной сети.

    CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя как мы это увидим, сайт может состоять из множества "виртуальных сайтов"). Сайт, однако, может принадлежать многим VPN.

    PE-маршрутизатор может быть подключен к CE-устройствам нескольких различных сайтов, если эти устройства CE размещены в одной или разных VPN. CE-устройства могут для надежности быть присоединены к нескольким маршрутизаторам PE, одного или нескольких сервис-провайдеров. Если CE устройством является маршрутизатор, то PE- и CE-маршрутизатор окажутся смежными.

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


    3. Таблицы переадресации сайта в PE

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

    Как заполняются таблицы переадресации сайтов?

    В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами, и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает, от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V.

    Если сайт является множественной VPN, таблица переадресации, ассоциированная с этим сайтом, может содержать маршруты от полного набора сетей VPN, членом которого является сайт.

    PE содержит вообще только одну таблицу переадресации на сайт, даже если он соединен с сайтом несколькими путями. Различные сайты могут использовать одну и ту же таблицу переадресации, если они намерены пользоваться одним и тем же набором маршрутов.

    Предположим, что пакет получен PE-маршрутизатором от определенного сайта, соединенного с ним непосредственно, но место назначения пакета не связано ни с одной из записей таблицы переадресации данного сайта. Если SP не предоставляет доступа к Интернет для данного сайта, тогда пакет отбрасывается. Если SP предоставляет доступ к Интернет для данного сайта, тогда просматривается таблица переадресации PE.

    Для поддержки надежной изоляции одной VPN от другой, важно, чтобы ни один маршрутизатор в опорной сети не принимал помеченных пакетов от смежных устройств неопорной сети, если только выполняются следующие условия:

    (a)            метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и

    (b)            маршрутизатор опорной сети может определить, что использование этой метки вызовет уход пакета из опорной сети, до того как будет рассмотрена какая-либо ниже лежащая в стеке метка, и до того как будет проанализирован IP-заголовок. Эти ограничения необходимы, для того чтобы препятствовать попаданию пакетов в VPN, которой они не принадлежат.

    Таблицы переадресации сайта в PE используются только для пакетов, которые приходят от сайта, непосредственно связанного с PE. Они не используются для маршрутизации пакетов, которые присылаются другими маршрутизаторами, принадлежащими опорной сети SP. В результате может существовать несколько разных маршрутов до одной и той же системы, которые определяются сайтом, из которого пакет попадает в опорную сеть. Например, может существовать маршрут до данной системы для пакетов из экстранет (где маршрут ведет через firewall), и другой маршрут для пакетов из интранет (включая пакеты, которые уже идут через firewall).


    3.1. Виртуальные сайты

    В некоторых случаях, конкретный сайт может быть поделен клиентом на несколько виртуальных, возможно с привлечением техники VLAN. Виртуальные сайты могут быть членами различных наборов VPN. PE должен тогда содержать разные таблицы переадресации для каждого виртуального сайта. Например, если CE поддерживает VLAN, и нужно установить соответствие между VLAN и VPN, пакеты, пересылаемые между CE и PE, могут инкапсулироваться с использованием техники VLAN внутри сайта, это может осуществляться PE, совместно с интерфейсом, через который получен пакет, чтобы установить соответствие пакета и определенного виртуального сайта.

    В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов, (в частности, если интерфейс следует стандарту Frame Relay или ATM), и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. В любом случае, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные маршрутизаторы CE для каждого виртуального сайта.

    Заметим, что во всех случаях, механизмы, как и политика для управления того, какой трафик пропускать и для какого VPN, находится в руках клиента.

    Если желательно иметь определенную ЭВМ в составе нескольких виртуальных сайтов, тогда эта машина должна определять для каждого пакета, с каким виртуальным сайтом следует его ассоциировать. Это можно сделать, например, путем посылки пакетов из разных виртуальных сайтов в различные VLAN, или через разные сетевые интерфейсы.

    Эти схемы не требуют от CE поддержки MPLS. Раздел 8 содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS.


    4. Распределение маршрутов VPN посредством BGP

    Маршрутизаторы PE используют BGP для рассылки маршрутов между VPN (точнее, для вынуждения VPN обмениваться маршрутами между собой).

    Отправитель BGP может анонсировать и разослать маршрут для данного адресного префикса. Каждая VPN может иметь свое адресное пространство, это означает, что некоторые адреса могут использоваться в любом числе VPN, где в каждой VPN адрес соотносится с разной системой. Отсюда следует, что нужно позволить BGP инсталлировать и рассылать по несколько маршрутов для одного IP-адресного префикса. Более того, нужно гарантировать, что для определения того, какой маршрут из списка, предоставленного BGP, может использовать сайт и какой из них будет прописан в таблице переадресации, служит политика.


    4.1. Адресное семейство VPN-IPv4

    Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими "адресными семействами". Введем обозначение "VPN-IPv4 address family". Адрес VPN-IPv4 имеет 12-байт и начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса по одному для каждого VPN.

    RD не предполагает какой-либо семантики, он не содержит информации о происхождении маршрута или о наборе VPN, куда маршруты следует рассылать. Целью RD является позволить формирование пути к общему адресному префиксу IPv4.

    RD может также использоваться для формирования множественных путей к одной и той же системе. В разделе 3, приводится пример, где маршрут к определенному серверу должен быть разным для интранет и экстранет. Это может быть достигнуто путем создания двух разных VPN-IPv4 маршрутов, которые имеют идентичную IPv4 часть, но разные RD. Это позволяет BGP установить несколько разных путей к одной и той же системе и разрешить использование политики (смотри раздел 4.2.3), чтобы решить, какие пакеты будут пользоваться данным маршрутом.

    RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number), и чье поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, для того, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые.

    Данная таблица переадресации сайта будет иметь только один маршрут VPN-IPv4 для любого заданного адресного префикса IPv4. Когда место назначения пакета соответствует маршруту VPN-IPv4, это соответствие касается только IPv4-части.

    PE должен быть сконфигурирован так, чтобы установить соответствие между маршрутами, ведущими к конкретному CE, и их RD. PE может быть сконфигурирован так, чтобы установить соответствие между всеми маршрутами, ведущими к одному CE и имеющими данный RD. Он может быть сконфигурирован и так, чтобы установить соответствие между разными маршрутами, имеющими различные RD даже если они ведут к одному и тому же CE.


    4.2. Управление рассылкой маршрутов

    В данном разделе, обсуждается способ управления рассылкой маршрутов VPN-IPv4.


    4.2.1. Атрибут Target VPN

    Каждая таблица переадресации соответствует одному или более атрибутам "Target VPN". Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами " Target VPN". Они рассматриваются протоколом BGP как атрибуты маршрута.

    Любой маршрут, ассоциированный с Target VPN T должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов.

    Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны, и не должны быть идентичны.

    Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities Attribute. Однако формат последнего не является адекватным, так как он позволяет только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities. Должно быть также возможно структурировать формат, аналогично тому, как это описано для RD (смотри раздел 4.1), так что поле тип определит длину поля администратор, а оставшаяся часть атрибута является номером из пространства нумерации администратора.

    Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов.

    Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами. Можно пренебречь атрибутом Target VPN, создавая больше маршрутов (т.e., используя большее число RD), но тогда свойства масштабируемости окажутся менее привлекательными.

    Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом? Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретномусайту с одним Target VPN, а к другому с другим. Или CE-маршрутизатор, когда он рассылает маршруты (смотри раздел 6), можно специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если используется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая согласно его конфигурации является обязательной. Более точно было бы называть этот атрибут " Route Target" вместо "VPN Target".


    4.2.2. Расылка маршрутов между PE посредством BGP

    Если два сайта VPN подключены к PE, которые размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP.

    Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), тогда PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router), или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден использовать EBGP, чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам.Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет.

    Если имеется много VPN, содержащих сайты, подсоединенные к различным автономным системам, не обязательно иметь только один ASBR между двумя AS, которые содержат все маршруты для всех VPN; могут быть несколько ASBR, каждый из которых содержит только маршруты для конкретного субнабора VPN.

    Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве " BGP next hop". Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек, и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого он узнал о маршруте. Метка может также определить инкапсуляцию данных в канале.

    В большинстве случаев, метка присвоенная PE, заставит послать пакет непосредственно к CE, а PE , который получает пакет с меткой, не будет искать адрес места назначения пакета в какой-либо таблице переадресации. Однако для PE возможно также присвоить метку, которая неявно идентифицирует некоторую таблицу переадресации. В этом случае, PE, получающий пакет, будет искать адрес места назначения пакета с меткой в одной из его таблиц переадресации.

    Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно, или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут ("best effort"), или это может быть маршрут созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно с разными характеристиками QoS.

    Доступны все обычные методы использования отражателей маршрутов [2] для улучшения масштабируемости, например, иерархии отражателей маршрутов. Если используются отражатели маршрута, нет нужды иметь отражатель маршрутов, который знает все VPN-IPv4 маршруты для всех VPN, поддерживаемых опорной сетью. Можно иметь отдельные отражатели маршрута, которые не взаимодействуют друг с другом, каждый из которых поддерживает субнабор общего набора VPN.

    Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE или рефлекторы маршрута, которые посылают ему маршруты должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, ни анонсируя и не пересылая его.

    Маршрутизатор, который не подключен к какой-либо VPN, т.e., P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4.

    Эти правила рассылки маршрутной информации гарантируют, что не будет устройства, которое должно знать все VPN-IPv4 маршруты, которые поддерживаются через опорную сеть. В результате полное число таких маршрутов, которые могут поддерживаться через опорную сеть не ограничивается емкостью какого-либо отдельного устройства, и, следовательно, может увеличиваться виртуально беспредельно.


    4.2.3. Атрибут VPN of Origin

    Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и идентифицирует соответствующий маршрут, как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут, он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities.

    В ситуации, в которой необходимо идентифицировать источник маршрута, используется именно этот атрибут, а не RD. Этот атрибут может использоваться при формировании VPN, как это описано ниже.

    Возможно более корректно называть этот атрибут "Начало маршрута", а не " VPN of Origin". Он в действительности идентифицирует маршрут, приходящий из определенного набора сайтов вне зависимости оттого, составляет ли этот набор VPN.


    Путем соответствующей установки атрибутов Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа.

    Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов.

    В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа "hub and spoke" (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением " Hub" а другой со значением "Spoke". Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении.

    Предположим, имеется определенное число сайтов, размещенных в интранет и экстранет, и некоторое число сайтов, принадлежащих только интранет. Далее могут существовать маршруты интранет и экстранет, которые имеют Target VPN, идентифицирующий весь набор сайтов. Сайты, которые содержат маршруты только интранет, могут отфильтровывать все маршруты с некорректным VPN of Origin.

    Эти два атрибута допускают большую гибкость, позволяя управлять процессом рассылки маршрутной информации между различными наборами сайтов, которые в свою очередь упрощают построение VPN.


    5. Переадресация в опорной сети

    Если промежуточные маршруты в опорной сети не имеют никакой информации о маршрутах в VPN, как пакеты будут переадресованы из одного сайта VPN к другому? Это делается с помощью MPLS с двумя уровнями в стеке меток.

    Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPN-IPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS, в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.)

    Когда PE получает пакет от CE-устройства, он выбирает определенную таблицу переадресации сайта, в которой ищется адрес места назначения пакета. Предположим, что такой адрес найден. Если пакет адресован устройству CE, подключенному к тому же самому PE, пакет посылается непосредственно устройству CE.

    Если пакет адресован не устройству CE, подключенному к тому же PE, важен "BGP Next Hop" пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага, и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же что и для IGP, вторая метка может не извлекаться из стека).

    В этой точке MPLS будет транспортировать пакет через опорную сеть и в соответствующее CE-устройство. То есть, все решения о переадресации в P- и PE-маршрутизаторах принимаются на уровне MPLS, а IP-заголовки пакетов не анализируются повторно до тех пор, пока они не достигнут устройства CE. Оконечный маршрутизатор PE прежде чем посылать пакет устройству CE, извлекает из стека MPLS очередную метку, таким образом, устройство CE получит обычный IP-пакет.

    Когда пакет входит в опорную сеть из определенного сайта через конкретный PE маршрутизатор, путь пакета определяется содержимым таблицы переадресации. Таблицы переадресации маршрутизатора PE, через который пакет покидает опорную сеть не существенны. В результате можно иметь несколько маршрутов до одной и той же системы, где конкретный маршрут, выбранный для конкретного пакета, определяется сайтом, через который пакет попал в опорную сеть.

    Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это в свою очередь важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE).


    6. Как PE узнают о маршрутах от CE

    Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN.

    В случае, когда CE-устройство является ЭВМ или сетевым переключателем, этот набор адресов будет конфигурироваться в маршрутизаторе PE, подключающем данное устройство. В случае, когда CE-устройство является маршрутизатором, существует много способов, с помощью которых PE-маршрутизатор может получить этот набор адресов.

    PE транслирует эти адреса в адреса VPN-IPv4, используя сконфигурированный RD. PE далее рассматривает эти маршруты в качестве входной информации протокола BGP. Ни при каких обстоятельствах маршруты из сайта не должны уходить в IGP опорной сети.

    Какой из методов рассылки маршрутов PE/CE возможен, зависит от того, является ли конкретное устройство CE "транзитным VPN" или нет. "Транзитная VPN" - это сеть, которая содержит маршрутизатор, получающий маршруты от "третей стороны" (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором), и который перераспределяет эти маршруты в маршрутизатор PE. VPN, которая не является транзитной VPN, представляет собой "частичную VPN". Подавляющее большинство VPN, включая практически все корпоративные сети, следует считать такими. Возможные механизмы рассылки PE/CE:

    1. Может использоваться статическая маршрутизация (т.e., конфигурация).

    2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE, скажем PE1, получает VPN-IPv4 маршрут R1, и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE, скажем PE2, (где PE1 и PE2 может быть тем же маршрутизатором или разными маршрутизаторами), если только PE2 не ставит в соответствие R2 и маршрут VPN-IPv4, который отличается от (т.e., содержит другой RD) R1.

    3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае, сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора кроме тех, что существуют до CE, размещенном в том же сайте. (Этот метод должен использоваться только в частичных VPN.)

    4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP (В частности, EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. (Эта технология может использоваться в частичных или транзитных VPN).

    С чисто технической точки зрения это далеко не совершенная методика:

    a) В отличии от альтернатив IGP, это не требует от PE запускать несколько запросов алгоритму маршрутизации, для того чтобы взаимодействовать с несколькими CE.

    b) BGP сконструирован как раз для решения таких задач: пересылки маршрутной информации между системами, управляемыми разными администраторами.

    c) Если сайт содержит "BGP backdoors", т.e., маршрутизаторы с BGP-соединениями с маршрутизаторами, отличными от PE-маршрутизаторов, эта процедура будет работать корректно при любых обстоятельствах. Другие процедуры могут работать или нет, в зависимости от конкретных обстоятельств.

    d) Использование BGP упрощает для CE передачу атрибутов маршрутов PE. Например, CE может предложить определенный Target для каждого маршрута, из числа атрибутов Target, которые авторизованы PE для присвоения маршруту.

    С другой стороны, использование BGP вероятно является чем-то новым для CE администраторов, за исключением случая, когда клиент сам является Интернет сервис-провайдером. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже).

    Если набор сайтов представляет собой транзитную VPN, удобно представить их как BGP конфедерацию, так что внутренняя структура VPN окажется спрятанной от любого маршрутизатора, который находится вне VPN. В этом случае, каждый сайт в VPN потребует двух BGP-соединений с опорной сетью, одно будет внутренним по отношению к конфедерации, а другое - внешним. Обычные интра-конфедерационные процедуры должны будут слегка модифицированы, для того чтобы учесть возможность того, что опорная сеть и сайты могут иметь разную политику. Опорная сеть является членом конфедерации на одном из соединений, но не будет членом конфедерации на другом. Такие методики могут быть полезны, если клиентом для услуг VPN является ISP. Эта методика позволяет клиенту, который является ISP, получить услуги опорной сети VPN от одного из партнеров ISP.

    Когда нам не нужно различать разные пути, которыми PE может быть проинформирован об адресном префиксе, который существует в данном сайте, мы просто говорим, что PE узнал маршруты от сайта.

    Прежде чем PE сможет передать VPN-IPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута:

    - Исходный сайт (Site of Origin)

    Этот атрибут однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE, или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities (раздел 4.2.1).

    - VPN of Origin

    Смотри раздел 4.2.1.

    - Target VPN

    Смотри раздел 4.2.1.


    7. Как CE узнает маршруты от PE

    В данном разделе мы предполагаем, что устройством CE является маршрутизатор. Вообще, PE может послать любой маршрут в CE, который PE поместил в таблицу переадресации, которую он использует для маршрутизации пакетов из CE. Существует одно исключение: если атрибут маршрута Site of Origin идентифицирует конкретный сайт, такой маршрут не должен никогда посылаться какому-либо CE этого сайта.

    В большинстве случаев, однако будет достаточно для PE просто послать CE маршрут по умолчанию. В некоторых случаях, может быть даже достаточно сконфигурировать CE с маршрутом по умолчанию, указывающим на PE. Это работает для любого сайта, который не требует рассылки маршрута по умолчанию другим сайтам. Например, если один сайт в корпоративной VPN имеет корпоративный доступ к Интернет, это сайт может нуждаться в рассылке маршрута по умолчанию другому сайту.

    Какая бы из процедур ни использовалась для рассылки маршрутов от CE к PE, она же может служить для передачи маршрутов от PE к CE.


    8. Если CE поддерживает MPLS?

    В случае, когда CE поддерживает MPLS, и хочет импортировать весь набор маршрутов из своего VPN, PE может разослать метку для каждого такого маршрута. Когда PE получает пакет от CE с такой меткой, он (a) замещает эту метку соответствующей меткой, которую он получил через BGP, и (b) заносит метку в стек поверх метки, соответствующей BGP следующего шага для заданного маршрута.


    8.1. Виртуальные сайты

    Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутом Origin and Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет должен просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел.


    8.2. Представление ISP VPN в качестве части VPN

    Если определенная VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес, обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE.


    9. Безопасность

    a) Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников не внушающих доверия, если только не известно, что такие пакеты покинут опорную сеть до того как будут проанализированы IP-заголовки или какие-либо метки в стеке, и

    b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия, безопасность предоставляемая этой архитектурой виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

    Не имеет никакого значения тот факт, что использование MPLS упрощает достижение уровня безопасности, который возможен при создании туннеля IP-поверх-IP вместо MPLS. Довольно просто отказать в допуске помеченных пакетов, если только не реализуется первое из указанных выше условий. Много труднее сконфигурировать маршрутизатор так, чтобы заблокировать прием IP-пакетов, если эти пакеты представляют собой IP-поверх-IP, идущие в "неправильное" место.

    Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

    Для пользователя VPN возможно также обеспечить себя повышенной безопасностью путем применения туннельного режима IPSEC [5].

    Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC.

    Однако процедуры, описанные до сих пор, не позволяют маршрутизатору CE, посылающему пакет, определить идентичность следующего маршрутизатора CE, через который пройдет пакет. Эта информация необходима, для того чтобы использовать туннельный режим IPSEC. Итак, мы должны расширить данные процедуры, чтобы сделать эту информацию доступной.

    Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, который идентифицирует следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, может использоваться стандартный туннельный режим IPSEC.

    Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

    Каждый CE, который должен использовать IPSEC, должен быть так сконфигурирован, чтобы запретить посылку небезопасного трафика по любому из оговоренных адресов. Это блокирует посылку небезопасного трафика CE, если по какой-то причине ему не удалось получить необходимую информацию.

    Когда MPLS используется для переноса пакетов между двумя конечными точками туннеля IPSEC, внешний заголовок IPSEC не выполняет в действительности никакой функции. Может быть желательно разработать форму туннеля IPSEC, которая позволяет отбрасывать внешний заголовок, в тех случаях, когда используется MPLS.


    9.2. Многокомпонентные безопасные ассоциации

    Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE, может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации, все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, оно должно знать какой сети VPN предназначена эта информация. CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

    Существенным преимуществом схемы, подобной этой, является то, что изменение в маршрутизации (в частности, изменение выхода CE для конкретного адресного префикса) прозрачны для механизма безопасности. Это может быть важным, в частности, в случае мультипровадерских VPN, где нужно пересылать информацию об изменении маршрутов с целью поддержания механизмов безопасности.

    Другим преимуществом является то, что исключена необходимость внешнего IP-заголовка, так как инкапсуляция MPLS берет на себя эту функцию.


    10. Качество обслуживания

    Качество обслуживания (QoS) является ключевым компонентом любой системы VPN. В MPLS/BGP VPN, существующие возможности L3 QoS могут быть применены к помеченным пакетам посредством использования "экспериментальных" битов в промежуточном заголовке [10], или, в случае применения в качестве опорной сети ATM, за счет использования QoS-возможностей самой сети ATM. Управление трафиком, обсуждаемое в работе [1], также применимо к сетям VPN MPLS/BGP. Управление трафиком, если это желательно, может использоваться даже для установления LSP с конкретными параметрами QoS между определенными парами сайтов. Когда MPLS/BGP VPN охватывает нескольких SP, может быть применена архитектура, описанная в [7]. SP может реализовать либо intserv или diffserv возможности конкретной сети VPN.


    11. Масштабируемость

    Мы обсуждали масштабируемость на протяжении всего документа. В данном разделе, кратко суммируются основные характеристики модели с точки зрения масштабирования. Опорная сеть сервис провайдера состоит из следующих компонентов:

    (a)             PE-маршрутизаторов,

    (b)               BGP отражателей маршрута,

    (c)          P-маршрутизаторов (которые являются либо PE-маршрутизаторами, либо рефлекторами маршрута), и в случае мульти-провайдерской VPN,

    (d)               ASBR.

    P-маршрутизаторы не поддерживают никакие VPN маршруты. Для того чтобы правильно маршрутизовать VPN трафик, P-маршрутизаторы должны поддерживать только маршруты до PE-маршрутизаторов и ASBR. Использование двух уровней пометки позволяет увести маршруты VPN от P-маршрутизаторов.

    Маршрутизатор PE поддерживает VPN маршруты, но только для тех VPN, с которыми связан непосредственно.

    Рефлекторы маршрутов и ASBR могут быть распределены в сетях VPN так, что каждая составная часть содержит маршруты только для субнабора VPN, обслуживаемого провайдером. Таким образом, одного рефлектора маршрутов или ASBR не достаточно для поддержания всех VPN.

    В результате ни один компонент в сети сервис-провайдера не должен поддерживать все маршруты для всех VPN. Итак, полная возможность сети для поддержания увеличивающегося числа участников VPN не ограничивается возможностями одного компонента.


    12. Ссылки

    [1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.

    [2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.

    [3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.

    [4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.

    [5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

    [6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.

    [7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC2430, October 1998.

    [8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.

    [9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.

    [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.

    Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.5 Процедуры Интернет


    previous up down next index index
    Previous: 4.4.9.6 Протокол резервирования ресурсов RSVP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
        Next: 4.4.10 Протокол загрузки BOOTP

    4.4.9.7 Протокол COPS (Common Open Policy Service)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP) и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике [RSVP]. Мы предполагаем, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [WRK]. Характеристики протокола COPS содержат следующие моменты (RFC-2748):

    1.

    Протокол использует модель клиент-сервер, где PEP посылает запросы, осуществляет актуализацию данных, отправляет сообщения о ликвидации удаленным PDP, а PDP возвращает отклики-решения узлам PEP.

    2.

    Протокол использует TCP для надежного обмена сообщениями между клиентами и сервером. Следовательно, не нужно никакого дополнительного механизма для обеспечения надежного взаимодействия между сервером и клиентами.

    3.

    Протокол является расширяемым и может работать с любой специфической информацией клиентов без модификации самого протокола COPS. Протокол был создан для общего администрирования, конфигурации и реализации политики.

    4.

    COPS предоставляет безопасность на уровне сообщений для целей аутентификации, защиты отклика и целостности сообщения. COPS может также использовать для цели безопасности существующие протоколы, такие как IPSEC [IPSEC] или TLS для осуществления аутентификации и безопасного канала между PEP и PDP.

    5.

    COPS представляет собой протокол состояний. (1) Состояние запрос/решение является общим для системы клиент-сервер. (2) Состояние различных событий (пар запрос/решение) могут ассоциироваться. Под пунктом (1) подразумевается, что запросы клиента PEP инсталлируются или запоминаются удаленным PDP до тех пор, пока они не будут аннулированы PEP. В то же время, для заданного состояния запроса решения удаленного PDP могут генерироваться асинхронно. Под пунктом (2) подразумевается, что сервер может реагировать на новые запросы по-разному в зависимости от поступивших ранее запросов/решений.

    6.

    Кроме того, COPS является протоколом состояний, так как он позволяет серверу конфигурировать клиента, а затем аннулировать это состояние, если оно более не нужно.

    1. Базовая модель

    Рис. .1. Схема взаимодействия различных частей COPS.

    На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.

    Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.

    PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.

    После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.

    Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.

    Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.

    Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет >PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.

    Наконец, допустимость ошибки (fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive ("еще жив?"). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.

    2. Протокол

    2.1. Общий заголовок

    Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.

    0

    1

    2

    3

    Версия

    Флаги

    Код операции

    Тип клиента

    Длина сообщения

    //// далее обозначает зарезервированное поле и должно содержать 0.

    В заголовке имеются поля:

    Версия: 4 бита

    Номер версии COPS. Текущее значение версии 1.

    Флаги: 4 бита

    Определенные значения флага (все другие флаги должны быть установлены в нулевое состояние): 0x1 Solicited Message Flag Bit. Этот флаг устанавливается, когда поступает запрос COPS. Этот флаг не должен устанавливаться (значение=0), если только не специфицировано обратное в разделе 3

    Ниже в таблице представлены значения поля код операции.

    Код
    операции (8 бит)

    Функция

    Название операции

    1

    Запрос

    REQ

    2

    Решение

    DEC

    3

    Отчет о состоянии

    RPT

    4

    Стереть состояние запроса

    DRQ

    5

    Синхронизовать состояние запроса>

    SSQ

    6

    Client-Open

    OPN

    7

    Client-Accept

    CAT

    8

    Client-Close

    CC

    9

    Keep-Alive

    KA

    10

    Завершить синхронизацию

    SSC

    Поле Тип клиента: 16 бит

    Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи.

    Длина сообщения: 32 бит

    Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам.

    2.2. Форматы специфических объектов COPS

    Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:

    0

    1

    2

    3

    Длина (октеты)

    C-Num

    C-Type

    ( Содержимое объекта)

    Длина характеризуется двухоктетной величиной, которая описывает число октетов (включая заголовок), которые образуют объект. Если длина в октетах не попадает на границу слова, кратную 32-бит, должно использоваться заполнение вплоть до конца объекта, так чтобы обеспечивать выравнивание, прежде чем объект будет послан. На принимающей стороне соответствующая граница объекта определяется округлением объявленной ранее длины объекта до значения кратного ближайшим 32-бит.

    Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте.

    C-num: 8 бит

    1

    Дескриптор (Handle)

    2

    Контекст

    3

    Входной интерфейс

    4

    Выходной интерфейс

    5

    Код причины

    6

    Решение

    7

    LPDP решение

    8

    Ошибка

    9

    Специфические данные клиента

    10

    Таймер Keep-Alive

    11

    Идентификация PEP

    12

    Тип отчета

    13

    Адрес переадресации PDP

    14

    Последний PDP-адрес

    15

    Таймер аккоунтинга

    16

    Целостность сообщения

    C-type: 8 бит. Значения, определенные для C-num.

    2.2.1. Объект дескриптор (Handle)

    Объект Handle (дескриптор) содержит уникальную величину, которая идентифицирует инсталлированное состояние. Эта идентификация используется большинством операций COPS. Состояние, соответствующее дескриптору, должно быть непосредственно удалено, когда оно более не применимо.

    C-Num = 1
    C-Type = 1, дескриптор клиента.

    Поле дескриптора имеет переменную длину, дескриптор должен отличаться от других дескрипторов клиента того же самого PEP (соединение COPS TCP)для определенного типа клиента. Он всегда выбирается PEP в исходный момент и ликвидируется, когда он более не нужен. Дескриптор клиента используется, чтобы осуществить ссылку на состояние запроса инициализированного некоторым PEP и инсталлированным для типа клиента PDP. PEP специфицирует дескриптор клиента в своих сообщениях запроса (Request), отклика (Report) и ликвидации (Delete), посланных к PDP. Во всех случаях, дескриптор клиента служит для однозначной идентификации конкретного запроса PEP для данного типа клиента.

    Значение дескриптора клиента устанавливается PEP и является непрозрачным для PDP. PDP просто выполняет побайтовое сравнение со значением этого объекта с учетом значений дескрипторов объектов других поступивших запросов.

    2.2.2. Объект Context

    Специфицирует тип события(ий), которое вызвало запрос. Этот объект необходим для сообщений-запросов. Запросы управления доступом, выделения ресурсов, и переадресации зависят от типов клиентов. Для допустимых типов клиента PEP может также послать запрос PDP с целью получения именованной конфигурационной информации. Эта именованная конфигурационная информация может иметь форму, полезную для установления системных атрибутов в PEP, или она может иметь форму правил политики, которые могут быть непосредственно проверены PEP.

    В одном запросе может присутствовать несколько флагов. Это, однако, допустимо, только если набор специфической информации клиента в комбинированном запросе идентичен набору, который был бы специфицирован в случае посылки отдельного запроса для каждого из флагов.

    C-num = 2, C-тип = 1

    0

    1

    2

    3

    R-Type

    M-Type

    R-тип (флаг типа запроса)

    0x01

    Запрос входящего сообщения/Управления доступом (Incoming-Message/Admission Control)

    0x02

    Запрос выделения ресурсов

    0x04

    Запрос исходящего сообщения

    0x08

    Запрос конфигурации

    M-Type (Тип сообщения специфичные для клиента (Client Specific) 16-битовые значения типов протокольного сообщения.

    2.2.3. Объект In-Interface (IN-Int)

    Объект In-Interface используется для идентификации входного интерфейса, к которому относится запрос, и PEP, используется обратный адрес и ifindex.

    Объект Interface используется также для идентификации принимающего интерфейса через его ifindex. Поле ifindex может быть использовано, чтобы отличать субинтерфейсы от ненумерованных интерфейсов (смотри, например RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.

    Поле ifindex специфицированное в In-Interface обычно имеет отношение к ниже лежащему потоку протокольных сообщений. Поле ifindex является интерфейсом, через который получаются протокольные сообщения.

    C-Num = 3
    C-Type = 1, IPv4-адрес + Интерфейс

    0

    1

    2

    3

    IPv4 Address format

    ifindex

    Для этого типа объекта интерфейса, IPv4-адрес специфицирует адрес, откуда пришло сообщение.

    C-Type = 2, IPv6-адрес + Интерфейс

    0

    1

    2

    3

     

    IPv6 Address format

     

    ifindex

    Для данного типа объекта интерфейса, IPv6-адрес специфицируетIP-адрес, откуда пришло входное сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II PEP, как это описано выше.

    2.2.4. Объект Out-Interface (OUT-Int)

    Объект Out-Interface используется для идентификации выходного интерфейса, которому адресован запрос, и адреса, куда должен быть переправлено сообщение. Для потоков или сообщений, направляемых локальной ЭВМ PEP, используется обратный адрес и ifindex. Out-Interface >имеет те же форматы, что и объект In-Interface. Этот интерфейсный объект используется также для идентификации выходного интерфейса через его ifindex. Поле ifindex может быть использовано для отличия субинтерфейсов от ненумерованных интерфейсов (смотри, например, RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.

    Поле ifindex специфицированное в Out-Interface обычно связано с потоком протокольных сообщений. Поле ifindex определяет один из адресов, куда протокольное сообщение может быть переадресовано.

    C-Num = 4
    C-Type = 1, IPv4-адрес + интерфейс

    Некоторые форматы C-типа выступают в качестве объекта In-Interface. IPv4-адрес специфицирует адрес, куда направлено исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.

    C-Type = 2, IPv6-адрес + интерфейс

    Тот же формат C-типа, что и в случае объекта In-Interface. Для этого типа объекта интерфейса, адрес IPv6 специфицирует IP-адрес, которому адресовано исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.

    2.2.5. Объект Reason

    Этот объект специфицирует причину, почему состояние запроса было стерто. Объект появляется в запросах стирания (DRQ). Поле субкода причины зарезервировано для более подробного описания причины, специфической для клиента и описанной в соответствующих документах.

    C-Num = 5, C-тип = 1

    0

    1

    2

    3

    Reason-Code

    Reason Sub-code

    Код причины

     

    1

    Не специфицировано

    2

    Управление

    3

    Preempted (Другое состояние запроса получает предпочтение)

    4

    Tear (Используется для сообщения об удалении указанного состояния)

    5

    Таймаут (время локального состояния истекло)

    6

    Route Change (Изменение делает некорректным состояние запроса)

    7

    Недостаточные ресурсы (локальные ресурсы исчерпаны)

    8

    Директива PDP (решение PDP вызвало аннулирование)

    9

    Неподдерживаемое решение (решение PDP не поддерживается)

    10

    Synchronize Handle Unknown (дескриптор не известен)

    11

    Промежуточный дескриптор (stateless event)

    12

    Malformed Decision (восстановление не возможно)

    13

    Неизвестный объект COPS от PDP:
    Субкод (октет 2) содержит неизвестный C-Num объекта (октет 3) содержит неизвестный C-тип объекта

    2.2.6. Объект Decision

    Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента.

    C-Num = 6
    C-тип = 1, флаги решения (обязательные)

    0

    1

    2

    3

    Код команды

    Флаги

    Команды:

    0 = Решение NULL (Конфигурационные данные недоступны)
    1 = Инсталлировать (Admit request/Install configuration)
    2 = Удалить (запрос/конфигурацию)

    Флаги:

    0x01 = Trigger Error (сообщение об ошибке срабатывания, если установлена)

    Trigger Error применима для типов клиентов, которые могут посылать уведомления об ошибках для сигнальных сообщений.

    Значения поля флаги не применимые для данного контекста R-типа или типа клиента должны игнорироваться PEP.

    C-тип = 2, Stateless Data

    Этот тип объекта решения несет в себе дополнительную информацию (stateless), которая может быть использована PEP локально. Этот объект имеет переменную длину и его внутренний формат должен специфицироваться для данного типа клиента в соответствующем расширительном документе COPS. Этот объект для сообщений-решений является опционным и интерпретируется согласно текущему контексту.

    Ожидается, что даже посторонние PEP могут принимать некоторые простые политические решения в рамках их LPDP

    Так как этот набор хорошо известен и используется повсеместно, PDP обслуживает и его (обычным образом, через конфигурацию, или используя сообщение Client-Open). PDP может также включать эту информацию в свои решения, а PEP должен использовать ее в случае запросов выделения ресурсов.

    C-тип = 3, Данные замещения

    Этот тип объекта решения несет в себе информацию замещения, которая призвана заменить существующие данные в указанном сообщении. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе-расширении COPS. Он является опционным в сообщениях решениях и интерпретируется согласно текущему контексту.

    C-тип = 4, Данные решения, специфические для клиента

    Дополнительные типы решений могут быть введены с помощью информационного объекта специфического решения клиента (Client Specific Decision Data Object). Он имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе расширения COPS. Он является опционным в сообщениях-решениях и интерпретируется в соответствии с данным контекстом.

    C-тип = 5, именованные данные решения

    Информация об именованной конфигурации инкапсулируется в поле версии объекта решения, это делается в ответ на запрос конфигурации. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован в соответствующих документах расширения COPS для данного типа клиента. Для сообщений решения этот объект является опционным и интерпретируется в зависимости от контекста и флагов решения.

    2.2.7. Объект LPDP-решение (LPDPDecision)

    Решение принятое LPDP PEP (Local Policy Decision Point) может присутствовать в запросах. Эти объекты имеют формат, идентичный формату объектов специфических решений клиента, описанному выше.

    C-Num = 7

    C-тип = (тот же C-Type что и для объектов решения)

    2.2.8. Объект Error

    Этот объект используется для идентификации конкретных протокольных ошибок COPS. Поле субкода ошибки содержит дополнительную спецификацию ошибки, характерную для данного клиента. Субкоды ошибки для конкретного типа клиента должны специфицироваться в соответствующем документе расширения.

    C-Num = 8, C-тип = 1

    0

    1

    2

    3

    Код ошибки

    Субкод ошибки

    Код ошибки

    Причина

    1

    Плохой дескриптор

    2

    Неверный указатель ссылки (Invalid handle reference)

    3

    Плохой формат сообщения (Malformed Message)

    4

    Невозможна обработка (сервер не может обслужить запрос)

    5

    Отсутствует обязательная информация, специфическая для клиента

    6

    Неподдерживаемый тип клиента

    7

    Отсутствует обязательный объект COPS

    8

    Отказ клиента

    9

    Коммуникационный отказ (Communication Failure)

    10

    Не специфицировано

    11

    Закрытие сессии

    12

    Переадресация на предпочтительный сервер

    13

    Неизвестный объект COPS:
    Субкод (октет 2) содержит C-Num и C-Type (октет 3) неизвестного объекта.

    14

    Неуспех аутентификации

    15

    Необходима аутентификация

    2.2.9. Объект специфической информации клиента (ClientSI)

    Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа.

    C-Num = 9,
    C-Type = 1, Signaled ClientSI.

    Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента.

    C-Type = 2, Именованный ClientSI.

    Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP.

    2.2.10. Объект Keep-Alive-таймер (KATimer)

    Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение.

    C-Num = 10,
    C-Type = 1, значение таймера Keep-alive

    Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.

    0

    1

    2

    3

    //////////////

    Значение таймера KA

    2.2.11. Объект идентификации PEP (PEPID)

    Объект идентификации PEP используется, для того чтобы идентифицировать PEP-клиента удаленному PDP. Это необходимо для сообщений Client-Open.

    C-Num = 11, C-Type = 1

    Поле переменной длины. Это ASCII-строка, завершающаяся нулем, которая дополняется нулями до границы, кратной 32 бит. Идентификатор PEPID должен содержать ASCII-строку, однозначно идентифицирующую PEP в пределах политической области PEP. Например, он может быть статически приписанным IP-адресом PEP или DNS-именем. Этот идентификатор может использоваться PDP в качестве дескриптора для идентификации PEP в его политических правилах.

    2.2.12. Объект тип отчета (Report-Type)

    Тип отчета, соответствующий запросу состояния для данного дескриптора:

    C-Num = 12, C-Type = 1

    0

    1

    2

    3

    Report-Type

    /////////////

    Report-Type:

    1 = Success : Решение было успешным для PEP 2 = Failure : Решение не могло быть реализовано PEP
    3 = Accounting: Актуализация аккоунтинга для инсталлированного состояния.

    2.2.13. Адрес пересылки PDP (PDPRedirAddr)

    PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:

    C-Num = 13,
    C-Type = 1, IPv4-адрес+ TCP порт

    0

    1

    2

    3

    Формат IPv4-адреса

    /////////////////////////

    TCP Port Number

    C-Type = 2, IPv6-адрес + TCP порт

    0

    1

    2

    3

     

    Формат IPv6-адреса

     

    2.2.14. Последний адрес PDP (LastPDPAddr)

    Когда PEP имеет определенный тип клиента, он должен специфицировать последний PDP, который он успешно открыл (им получено сообщение Client-Accept) со времени, когда PEP последний раз перезагружался. Если со времени последней загрузки не использовалось никакого PDP, PEP просто не включит этот объект в сообщение Client-Open.

    C-Num = 14,
    C-Type = 1, IPv4-адрес (тот же формат, что и для PDPRedirAddr)
    C-Type = 2, IPv6-адрес (имеет тот же формат, что и PDPRedirAddr)

    2.2.15. Объект Accounting-таймер (AcctTimer)

    Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями.

    C-Num = 15,
    C-Type = 1, Значение таймера аккоунтинга

    Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.

    0

    1

    2

    3

    //////////////

    ACCT Timer Value

    2.2.16. Объект целостность сообщения (Message Integrity)

    Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity.

    C-Num = 16,
    C-Type = 1, HMAC дайджест

    Объект HMAC-целостности для вычисления дайджеста сообщения привлекает HMAC (ключевое хэширование для аутентификации сообщения) [HMAC], при этом используется ключ, общий для PEP и PDP.

    Объект Integrity специфицирует 32-битовый ID ключа, который определяет специфический ключ, используемый конкретным PEP и его PDP, а также используемый криптографический алгоритм. Для заданного PEPID ID ключа допускает существование одновременно нескольких ключей для PEP и оответствующих ключей PDP. Ключ, идентифицированный ID ключа, используется для вычисления дайджеста сообщения в объекте Integrity. Все программные реализации, как минимум должны поддерживать HMAC-MD5-96, который реализует алгоритм MD5 [MD5] вычисляющий дайджест сообщения длиной 96-бит.

    Этот объект включает в себя также порядковый номер, который представляет собой 32-битовое целое число без знака, которое служит для предотвращения атак откликов. Порядковый номер инициируется на фазе обмена сообщениями Client-Open, Client-Accept и инкрементируется каждый раз при посылке очередного сообщения тому же получателю через существующее TCP-соединение. Если порядковый номер достигает значения 0xFFFFFFFF, следующим номер будет равен нулю и процесс продолжится.

    Дайджест сообщения COPS вычисляется для области, начиная с заголовка, и вплоть до объекта Integrity (который должен быть последним объектом в сообщении COPS). В эту область попадают заголовок объекта Integrity, ID ключа и порядковый номер (Sequence Number). В случае HMAC-MD5-96, HMAC-MD5 выдает 128-битовый дайджест, который далее укорачивается до 96 бит.

    0

    1

    2

    3

    Key ID

    Sequence Number

     

    ...Keyed Message Digest...

     

    2.3. Коммуникация

    Протокол COPS использует одно устойчивое TCP соединение между PEP и удаленным PDP. Реализация PDP на сервере должна прослушивать стандартный номер TCP-порта (COPS=3288 [IANA]). PEP ответственен за инициативу TCP-соединения с PDP. Положение удаленного PDP может быть сконфигурировано или получено с помощью механизма локации услуг [SRVLOC].

    Если один PEP может поддерживать несколько типов клиентов, он может посылать соответствующее число сообщений Client-Open, адресованных PDP, через одно или более TCP-соединений. Аналогично, PDP с заданным адресом и номером порта может поддерживать один или более типов клиента. Для заданного набора поддерживаемых типов клиентов PDP может в каждом конкретном случае независимо воспринять или отвергнуть любой тип клиента. Если тип клиента отвергнут, PDP может перенаправить PEP на альтернативный PDP-адрес и TCP-порт для данного типа клиента через COPS. Различные TCP-порты могут использоваться для перенаправления PEP на другие программные реализации PDP, работающие на том же сервере.

    Один PEP может сформировать соединения с несколькими PDP. Это может происходить, когда физически различные PDP поддерживают разные типы клиентов (как это показано на рис.).

    Рис. .2. Пример с несколькими PDP.

    Когда TCP-соединение разорвано, PDP ожидает, что необработанное состояние запроса, соответствующее обмену запрос/решение, будет удалено. Когда PEP регистрирует потерю соединения из-за таймаута, он должен послать сообщение Client-Close каждому открытому типу клиенту, содержащему объект <Error>, который указывает на код ошибки "Communication Failure". Кроме того, PEP должен постоянно пытаться контактировать с первичным PDP или, если не удается, с любым известным запасным PDP. В частности PEP должен проверить все доступные PDP, с которыми он был сконфигурирован до того, как он сможет установить соединение. Если PEP соединен с запасным PDP, а первичный PDP становится доступным, запасной PDP является ответственным за переадресацию PEP на первичный PDP (через сообщение <Client-Close>, содержащее объект <PDPRedirAddr>, идентифицирующий первичный PDP для каждого из типов клиента). В разделе 2.5 рассмотрены детали синхронизации PEP и PDP.

    2.4. Использование дескриптора клиента (Client Handle)

    Дескриптор клиента служит для идентификации уникального состояния запроса для каждого из типов клиента для одного PEP. Дескрипторы клиента выбираются PEP и являются недоступными для PDP. PDP просто использует дескриптор запроса, чтобы однозначно идентифицировать состояние запроса для конкретного типа клиента, для конкретного TCP-соединения, и тем самым связать его решения с соответствующим запросом. Дескрипторы клиента инициализируются в сообщениях запроса и используются в последующих сообщениях запроса, решения и отчета для ссылки на то же состояние запроса. Когда PEP готов удалить состояние локального запроса, он посылает сообщение удаления (delete) PDP для соответствующего дескриптора клиента. Дескрипторы, относящиеся к различным состояниям запроса, должны быть уникальны в рамках контекста конкретного TCP-соединения и типа клиента.

    2.5. Синхронизация

    При отсоединении от PDP, PEP должен перейти к принятию локальных решений. При восстановлении соединения PEP информирует PDP обо всех событиях, которые произошли под локальным управлением. Кроме того, удаленный PDP может потребовать, чтобы внутренние состояния всех PEP были заново синхронизованы (все ранее поступившие запросы были заново посланы) путем передачи сообщения синхронизации состояний (Synchronize State).

    После неудачи и до полного установления нового соединения, ухудшение сервиса может быть минимизировано, если PEP кэширует переданные ранее решения и продолжает использовать их в течение некоторого времени.

    PEP, который кэширует состояние предыдущего обмена PDP, должен сообщить о факте разрыва соединения любому PDP, с которым он может восстановить соединение. Это выполняется путем включения адреса и номера TCP-порта последнего PDP, для которого PEP кэширует состояние в сообщении Client-Open. Объект <LastPDPAddr> будет включен для последнего PDP, с которым PEP был полностью синхронизован. Если прерывание обслуживания было временным и PDP все еще содержит полное состояние для PEP, PDP может выбрать вариант, когда не все состояния синхронизованы. PEP ответственен за актуализацию всех состояний PDP, которые изменились за время прерывания обслуживания. Если PEP выходит из строя и теряет все кэшированные состояния для некоторого типа клиента, он просто не включает <LastPDPAddr> в свое сообщение Client-Open.

    3. Содержимое сообщения

    Объект Integrity, если он включен, должен всегда быть последним объектом сообщения. Если необходимо обеспечить безопасность, а полученное сообщение не содержит корректного объекта Integrity, получатель должен послать сообщение Client-Close для Client-Type=0, определяющее соответствующий код ошибки.

    3.1. Запрос (REQ) PEP -> PDP

    PEP устанавливает дескриптор состояния запроса клиента, для которого PDP может обеспечить нужное состояние. Удаленный PDP затем использует дескриптор, для ссылки на информацию и решения, переданные по TCP-каналу конкретному PEP для данного типа клиента.

    Раз для нового запроса определен дескриптор, любые последующие модификации запроса могут производиться с помощью сообщения REQ, специфицирующего инсталлированный дескриптор. PEP ответственен за уведомление PDP всякий раз, когда изменения его локального состояния отслеживает состояния PEP. Формат сообщения-запроса имеет вид:

    <Request Message> ::= <Common Header>
    <Client Handle>
    <Context>
    [<IN-Int>]
    [<OUT-Int>]
    [<ClientSI(s)>]
    [<LPDPDecision(s)>]
    [<Integrity>]
    <ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
    <LPDPDecision(s)> ::= <LPDPDecision> | <LPDPDecision(s)> <LPDPDecision>
    <LPDPDecision> ::= [<Context>]
    <LPDPDecision: Flags>
    [<LPDPDecision: Stateless Data>]
    [<LPDPDecision: Replacement Data>]
    [<LPDPDecision: ClientSI Data>]
    [<LPDPDecision: Named Data>]

    Объект context используется для определения контекста, в рамках которого следует интерпретировать все другие объекты. Он также служит для определения вида решения, которое должен послать сервер, определяющий политику. Это решение может относиться к управлению доступом, размещению ресурсов, переадресации или замене объектов, а также в конфигурации.

    Объекты interface используются, чтобы определить соответствующий интерфейс, через который было получено или предполагается послать протокольное сообщение. Они обычно используются, если клиент запрашивает конфигурационные данные для какого-то конкретного интерфейса.

    ClientSI является информационным объектом клиента и содержит в себе специфическую информацию, для которой должно быть принято политическое решение. В случае конфигурации именованное ClientSI может включать в себя именованные данные о модуле, интерфейсе или функции, которые следует конфигурировать. Порядок следования для кратных ClientSI не существенен.

    Наконец, объект LPDPDecision содержит информацию согласно локальному решению, принятому LPDP.

    Сообщения Request с неверным форматом должны вызывать сообщения Decision PDP с соответствующим кодом ошибки.

    3.2. Решение (DEC) PDP -> PEP

    PDP реагирует посредством REQ с сообщением DEC, которое включает в себя ассоциированный дескриптор клиента и один или более объектов решения, сгруппированные относительно пар типов объектов Context и флагов решения (Decision Flags). Если имела место протокольная ошибка, вместо этого присылается объект ошибки.

    Требуется, чтобы первое сообщение решения для нового или актуализованного запроса имело флаг требования в заголовке COPS равный 1. Это исключает отслеживание того, какому модифицированному запросу соответствует конкретное решение (т.е., запрос посылается повторно для того же самого дескриптора). Важно, чтобы для данного дескриптора существовало одно предпочтительное решение, соответствующее определенному запросу. Это по существу означает, что PEP не должен посылать более одного REQ (для данного дескриптора), прежде чем он получит соответствующий DEC с заданным набором флагов сообщения. PDP должен всегда посылать решения для запросов в порядке их получения и каждому запросу должно соответствовать решение.

    Чтобы избежать тупиков, PEP может делать выдержку после посылки запроса, пока не будет получено решение. Он должен аннулировать дескриптор, для которого время выдержки истекло, а решение не получено, новая попытка может быть осуществлена с новым дескриптором.

    Формат сообщения Decision представлен ниже:

    <Decision Message> ::= <Common Header>
    <Client Handle>
    <Decision(s)> | <Error>
    [<Integrity>]
    <Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
    <Decision> ::= <Context>
    <Decision: Flags>
    [<Decision: Stateless Data>]
    [<Decision: Replacement Data>]
    [<Decision: ClientSI Data>]

    Сообщение Decision может включать либо объект Error, либо один или более объекта context и соответствующего объекта decision. О проблемах протокола COPS сообщается в объекте Error. Объект Decision зависит от контекста и типа клиента.

    3.3. Состояние отчета (RPT) PEP -> PDP

    Сообщение RPT используется PEP, чтобы сообщить PDP об успехе или неудаче реализации решения PDP, или уведомить об изменении состояния. Report-Type специфицирует вид отчета и опционный ClientSI и может содержать дополнительную информацию для типа клиента.

    Для каждого сообщения DEC, содержащего контекст конфигурации, которое получено PEP, он должен сформировать соответствующее сообщение-отчет о состоянии с флагом запрошенного сообщения (Solicited Message flag), который указывает на то успешно или нет реализовано конфигурационное решение. RPT-сообщения, запрошенные решением для данного дескриптора клиента, должны устанавливать флаг запрошенного сообщения и должны быть посланы в том же порядке, к каком получены соответствующие сообщения решения. Не должно быть более одного сообщения отчета о состоянии, соответствующему флагу-требованию, установленному для заданного решения.

    Состояние отчета может также использоваться для реализации периодических модификаций специфической информации клиента для целей мониторирования состояния, зависящего от типа клиента. В таких случаях тип аккоунтинг-отчета должен специфицироваться с помощью соответствующего информационного объекта клиента.

    <Report State> ::== <Common Header>
    <Client Handle>
    <Report-Type>
    [<ClientSI>]
    [<Integrity>]

    3.4. Состояние аннулирования запроса DRQ (Delete Request State) PEP -> PDP

    При посылке это сообщение PEP указывает, что удаленный PDP, чье состояние идентифицируется дескриптором клиента, более недоступно или неверно. Эта информация будет затем использоваться удаленным PDP для инициации соответствующих служебных операций. Объект кода причины интерпретируется с учетом типа клиента и определяет причину аннулирования. Формат сообщения Delete Request State представлен ниже:

    <Delete Request> ::= <Common Header>
    <Client Handle>
    <Reason>
    [<Integrity>]

    Важно, что когда состояние запроса окончательно удаляется из PEP, сообщение DRQ для состояния запроса посылается PDP, так что соответствующее состояние может быть также удалено в PDP. Состояния запроса, не удаленные явно PEP, будут поддерживаться PDP, пока не будет закрыта сессия или пока не будет разорвано соединение.

    Сообщения Decision с неверным форматом должны запустить DRQ, специфицирующее соответствующий код ошибки (Bad Message Format) и любое ассоциированное состояние PEP должно быть либо удалено, либо повторно запрошено. Если Decision содержится в неизвестном объекте COPS Decision, PEP должен аннулировать его запрос, специфицирующий код причины объекта COPS Unknown, так как PEP будет неспособен работать с информацией, содержащейся в неизвестном объекте. В любом случае, после отправки DRQ, PEP может попытаться послать соответствующий запрос повторно.

    3.5. Запрос состояния синхронизации (SSQ) PDP -> PEP

    Сообщение запроса состояния синхронизации имеет следующий формат:

    <Synchronize State> ::= <Common Header>
    [<Client Handle>]
    [<Integrity>]

    Это сообщение указывает, что удаленный PDP хочет, чтобы клиент повторно прислал свое состояние. Если имеется опционный дескриптор клиента, только состояние, ассоциированное с этим дескриптором, синхронизуется. Если PEP не распознает запрошенный дескриптор, он должен немедленно послать сообщение DRQ PDP для дескриптора, специфицированного в SSQ-сообщении. Если в SSQ-сообщении не специфицировано никакого дескриптора, все активные состояния клиента должны быть синхронизованы с PDP.

    Клиент выполняет синхронизацию состояний путем повторной посылки запросов специфицированного типа клиента для существующего состояния PEP. Когда синхронизация завершена, PEP должен направить завершающее сообщение синхронизованного состояния в PDP.

    3.6. Client-Open (OPN) PEP -> PDP

    Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния).

    <Client-Open> ::= <Common Header>
    <PEPID>
    [<ClientSI>]
    [<LastPDPAddr>]
    [<Integrity>]

    PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11).

    Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента).

    PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5).

    Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки.

    3.7. Client-Accept (CAT) PDP -> PEP

    Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами.

    <Client-Accept> ::= <Common Header>
    <KA Timer>
    [<ACCT Timer>]
    [<Integrity>]

    Если PDP отказывает клиенту, он пошлет сообщение Client-Close.

    Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения.

    Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации.

    Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки.

    3.8. Client-Close (CC) PEP -> PDP, PDP -> PEP

    Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается.

    <Client-Close> ::= <Common Header>
    <Error>
    [<PDPRedirAddr>]
    [<Integrity>]

    Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента).

    PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке.

    3.9. Keep-Alive (KA) PEP -> PDP, PDP -> PEP

    Сообщение keep-alive должно передаваться PEP в пределах периода, определенного минимальным значением выдержки KA-таймера, которая определяется в сообщениях CAT для данного соединения. Сообщение KA должно генерироваться случайным образом в пределах между 1/4 и 3/4 этого минимального интервала KA-таймера. Когда PDP получает сообщение keep-alive от PEP, он должен откликнуться таким же сообщением, адресованным PEP. Это сообщение обеспечивает подтверждение для каждой из сторон того, что соединение функционирует даже в случае, когда нет никаких других сообщений.

    Тип клиента в заголовке должен всегда быть установлен равным 0, так как KA используется для верификации соединения (а не для верификации сессии клиента).

    <Keep-Alive> ::= <Common Header>
    [<Integrity>]

    Как клиент, так и сервер могут предполагать, что TCP-соединение недостаточно для типа клиента с минимальным значением времени (специфицировано в сообщении CAT), если не зарегистрировано никакой телекоммуникационной активности в течение периода времени, превосходящего выдержку таймера. При этом PEP предполагает, что удаленный PDP или соединение не работает и PEP должен пытаться использовать альтернативный/запасной PDP.

    3.10. Завершение состояния синхронизации (SSC) PEP -> PDP

    Сообщение завершения состояния синхронизации (Synchronize State Complete) посылается от PEP к PDP, после того как PDP пошлет запрос синхронизации состояния PEP и PEP завершит синхронизацию. Полезно, чтобы PDP знал, когда все старые состояния клиента успешно повторно запрошены и, таким образом, PEP и PDP полностью синхронизованы. Объект дескриптора клиента (Client Handle) следует включать только тогда, когда соответствующее сообщение синхронизации состояний (Synchronize State Message) непосредственно ссылается на определенный дескриптор (handle).

    <Synchronize State Complete> ::= <Common Header>
    [<Client Handle>]
    [<Integrity>]

    4. Общие операции
    4.1. Согласование уровня безопасности и номера по порядку

    Безопасность сообщения COPS согласуется один раз на соединение и работает для всего последующего обмена через это соединение. Если требуется определенный уровень безопасности COPS, он должен быть согласован во время начального обмена сообщениями Client-Open/Client-Accept, специфицирующего тип клиента равный нулю (который зарезервирован для согласования уровня соединения и верификации соединения).

    Если PEP не конфигурировался для использования средств безопасности COPS, он просто пошлет PDP сообщения Client-Open для поддерживаемых типов клиента, как это задано в разделе 4.3 и не будет включать объект Integrity в какие-либо сообщения COPS.

    В противном случае, средства безопасности могут быть инициализированы PEP, если он посылает PDP сообщение Client-Open с Client-Type=0 до открытия любого другого типа клиента (Client-Type). Если PDP получает Client-Open с Client-Type=0, после того как другой тип клиента уже успешно открыт, он должен прислать сообщение Client-Close (для Client-Type=0) к PEP. Это первое сообщение Client-Open должно специфицировать Client-Type=0 и должно предоставить объекты PEPID и COPS Integrity. Этот объект Integrity будет содержать начальный порядковый номер, который PDP должен инкрементировать в дальнейшем, после исходного обмена Client-Open/Client-Accept и Key ID, идентифицирующего алгоритм и ключ, которые используются для вычисления дайджеста.

    Аналогично, если PDP принимает ключ безопасности PEP и алгоритм путем проверки дайджеста сообщения с использованием идентифицированного ключа, PDP должен послать PEP сообщение Client-Accept с Client-Type =0, содержащего объект Integrity. Этот объект Integrity будет включать исходный порядковый номер, идентификатор ключа (Key ID), задающий ключ и алгоритм, использованные для вычисления дайджеста.

    Если PEP, от перспективного PDP, который требует безопасности, потерпит неудачу или вообще не выполнит согласование требований безопасности, не послав исходное сообщение Client-Open с Client-Type=0, содержащее корректный объект Integrity, PDP должен послать PEP сообщение Client-Close с Client-Type=0, специфицирующее соответствующий код ошибки. Аналогично, если PDP, в процессе диалога с PEP, который требует безопасности, не выполнил согласования параметров, не послав сообщение Client-Accept со значением Client-Type=0 и корректным объектом Integrity, PEP должен послать PDP сообщение Client-Close со значением Client-Type=0, специфицируя соответствующий код ошибки. Такое сообщение Client-Close не должно нести в себе объект integrity (так как согласование безопасности еще не завершено).

    Инициализация безопасности может потерпеть неудачу по одной из следующих причин:

    1.

    Партнер, получающий сообщение требует обеспечения уровня безопасности COPS, но объект Integrity не прислан.

    2.

    Объект Integrity COPS был прислан, но с неизвестным или неприемлемым C-Type (код ошибки Unknown COPS Object, специфицирующий неподдерживаемые C-Num и C-Type).

    3.

    Дайджест сообщения или идентификатор ключа в присланном объекте Integrity был некорректен и, следовательно, сообщение не может быть аутентифицировано с помощью ключа (код ошибки - Authentication Failure).

    Раз начальное согласование уровня безопасности завершено, PEP знает, какие порядковые номера ожидает PDP, а PDP знает, какие порядковые номера ожидает PEP. Все сообщения COPS должны включать согласованный объект Integrity, специфицирующий корректный порядковый номер с соответствующий дайджест сообщения (включая сообщения Client-Open/Client-Accept для специфических типов клиента). Все последующие сообщения от PDP к PEP должны вызывать инкрементацию порядкового номера, осуществляемую PEP в объекте Integrity исходного сообщения Client-Open. Аналогично, все последующие сообщения от PEP к PDP должны вызывать инкрементацию порядкового номера, осуществляемую PDP в объекте Integrity исходного сообщения Client-Accept. Порядковые номера увеличиваются на 1, начиная с исходного значения. Например, если порядковый номер задан для PEP в исходном сообщении Client-Accept равным 10, следующее сообщение PEP посылаемое к PDP, предоставит объект Integrity с порядковым номером 11. Следующее сообщение, которое посылает PEP в направлении PDP, будет иметь порядковый номер 12 и т.д. Если любое последующее сообщение содержит неверный порядковый номер, неопределенный Key ID, некорректный дайджест сообщения, или не имеет объекта Integrity при условии, что параметры безопасности согласованы, то для Client-Type=0 должно быть сгенерировано сообщение Client-Close, содержащее корректный объект Integrity, где специфицируется соответствующий код ошибки. После этого соединение должно быть разорвано.

    4.2. Работа с ключами

    Процедура работы с ключами находится за пределами данного документа, но реализации COPS должны, по крайней мере, предоставить возможность ручной конфигурации ключей и задания их параметров. Ключ, используемый для формирования дайджеста сообщения с объектом Integrity, идентифицируется с помощью поля Key ID. Таким образом, параметр Key ID используется для идентификации одного из множества ключей, используемых совместно PEP и PDP. Key ID имеет отношение к определенному PEPID для PDP, или к определенному PDP для PEP. Для каждого ключа должны быть также определены параметры времени действия и параметры, задающие криптографический алгоритм. Как минимум, все реализации COPS должны поддерживать криптографический алгоритм HMAC-MD5-96 [HMAC][MD5] для вычисления дайджеста сообщения, который включается в объект Integrity (Keyed Message Digest), присоединяемый к сообщению.

    Регулярное изменение ключей является хорошей практикой. Ключи должны быть конфигурируемы так, чтобы их время действия перекрывались, обеспечивая плавный переход с одного набора на другой. В середине периода действия ключа отправитель должен запустить процедуру перехода на следующий ключ. Тем временем, получатели просто воспринимают любой идентифицированный ключ, полученный в пределах его периода существования (lifetime) и отклоняют любые другие ключи.

    4.3. Инициализация PEP

    Спустя некоторое время после установления соединения между PEP и удаленным PDP, после согласования условий обеспечения безопасности (если это требуется), PEP пошлет удаленному PDP одно или более сообщение Client-Open, по одному для каждого поддерживаемого PEP типов клиента. Сообщение Client-Open должно содержать адрес последнего PDP, с которым PEP хранит полный набор решений. Если не поступило ни одного решения от предыдущего PDP, объект LastPDPAddr не должен быть включен в сообщение Client-Open (смотри раздел 2.5). Каждое сообщение Client-Open должно, по крайней мере, содержать общий заголовок, указывающий на один тип клиента, который поддерживает PEP. Удаленный PDP откликнется сообщениями Client-Accept для каждого типа клиента, запрошенного PEP и поддерживаемого PDP.

    Если какой-то конкретный тип клиента не поддерживается PDP, PDP будет реагировать с помощью Client-Close, специфицируя неподдерживаемый тип клиента, и возможно предлагая альтернативный PDP-адрес и номер порта. В противном случае, PDP пошлет Client-Accept, специфицируя временную выдержку между сообщениями keep-alive, а PEP может начать посылку запросов PDP.

    4.4. Нестандартные операции

    Когда PEP сталкивается с ситуацией, которая требует нового политического решения, он посылает удаленному PDP сообщение-запрос. То, что квалифицируется как случай определенного типа клиента, должно быть специфицировано в соответствующем документе, посвященном этому client-type. Удаленный PDP принимает решение и посылает сообщение-решение PEP. Так как запрос определяет состояние, запрос будет запомнен или инсталлирован на удаленном PDP. Уникальный дескриптор (уникальный для TCP-соединения и типа клиента), специфицированный в запросе и соответствующем ему решении идентифицирует состояние запроса. PEP отвечает за удаление этого состояния запроса, если запрос уже более не применим.

    PEP может актуализовать ранее инсталлированное состояние запроса путем повторной посылки запроса для соответствующего дескриптора. Удаленный PDP примет новые решения и пошлет сообщения-решения к PEP. Аналогично, сервер может изменить принятое ранее решение на любое инсталлированное состояние запроса в любое время путем посылки не запрошенного сообщения-решения. В любое время модуль PEP ожидает решения PDP и уведомляет PDP о любых изменениях.

    4.5. Операции конфигурирования

    В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.

    В любом случае, PEP может уведомить удаленный PDP о локальном статусе инсталлированного состояния, используя сообщение-отклик. Это сообщение, если нужно, может содержать специфическую информацию клиента.

    4.6. Операции Keep-Alive

    Сообщение Keep-Alive используется для проверки соединения между клиентом и сервером, чтобы проверить функциональность соединения даже в отсутствие обмена сообщениями между PEP и PDP. PEP должен формировать COPS KA-сообщение случайным образом в диапазоне от одной четвертой до 3/4 минимальной величины выдержки KA таймера, заданной PDP в сообщении Client-Accept. При получении сообщения Keep-Alive от PEP, PDP должен реагировать на это сообщение Keep-Alive посылкой отклика Keep-Alive к PEP. Если любая из сторон не получит сообщение Keep-Alive или любого другого сообщения COPS за время выдержки KA-таймера, соединение должно считаться разорванным.

    4.7. Закрытие PEP/PDP

    Наконец, сообщения Client-Close используются для аннулирования влияния соответствующих сообщений Client-Open, оповещающих партнера о том, что специфицированный тип клиента не поддерживается или не является активным. Когда PEP регистрирует потерю связи, связанную с таймаутом keep-alive он должен послать сообщение Client-Close для каждого открытого типа клиента, специфицирующего код ошибки разрыва соединения. Затем PEP может разорвать соединение с PDP, попытаться восстановить связь или использовать альтернативный PDP. Когда PDP завершает работу, он должен послать сообщения Client-Close всем PEP для всех типов клиента, при этом может специфицироваться альтернативный PDP, который может заменить прежний.

    5. Соображения безопасности

    Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.

    Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.

    Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.

    TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.

    Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.

    Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].

    Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу "первым пришел - первым обслужен", как это определено в [IANA-CONSIDERATIONS].

    6. Ссылки

    [RSVP]

    Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC-2205, September 1997.

    [WRK]

    Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000.

    [SRVLOC]

    Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC-2608, June 1999.

    [IPSEC]

    Atkinson, R., "Security Architecture for the Internet Protocol", RFC-2401, August 1995.

    [HMAC]

    Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997.

    [MD5]

    Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992.

    [RSVPPR]

    Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC-2209, September 1997.

    [TLS]

    Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999.

    [IANA]

    http://www.isi.edu/in-notes/iana/assignments/port-numbers

    [IANA-CONSIDERATIONS]

    Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998

    Previous: 4.4.9.6 Протокол резервирования ресурсов RSVP    UP: 4.4 Интернет
    Down: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    Next: 4.4.10 Протокол загрузки BOOTP


    previous up down next index index
    Previous: 4.4.14.4 Многоцелевое расширение почты Интернет (MIME)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет
        Next: 4.4.15 Сетевой протокол времени NTP

    4.4.14.5 Программа Sendmail
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Одной из досадных особенностей программы Sendmail является огромное количество опций. К счастью большинство из них обычно не используются. Иной раз может показаться, что назначение некоторых опций знает только их автор. Часть этих опций служит для тестирования конфигурационного файла и файла псевдонимов. Такие опции как -bt и -bv используются при изменении конфигурационного файла, чтобы гарантировать, что новые наборы правил работают безошибочно. Наиболее важные опции служат администратору для установления отладочного уровня (-d#), или для установки программы в фоновый режим или режим демона (-bd), или для установки самого отладочного режима (-v).

    Почтовая программа sendmail должна запускаться в фоновом режиме с помощью строки в стартовом скрипте. Например:

    /usr/lib/sendmail -bd -q30m

    Эта командная строка предлагает обрабатывать занесенные в очередь сообщения каждые 30 минут. Время после опции -q может быть задана как произвольная комбинация дней, часов, минут и секунд. В этом случае за числами должны следовать соответственно символы d, h, m или s. Так, например, запись: -q1d2h30m15s указывает, что очередь будет обрабатываться с периодичностью 1 день, 2 часа, 30 минут и 15 секунд.

    Конфигурационный файл sendmail является читаемым текстовым. Этот файл начинается с перечня опций и макросов, далее следует набор правил. Эти правила определяют метод дешифровки адресов почтовых сообщений. Обычно настройке подвергаются опции и макросы.

    Макросы начинаются с символа D, за которым следует одна буква, определяющая имя макро, и текст расширения. Буква-имя чувствительна к регистру в котором она напечатана. Макросы используются для определения имен (имя ЭВМ, имя домена и т.д.). Практически все опции, доступные при запуске программы sendmail, могут быть описаны и в конфигурационном файле (буквенные имена совпадают).

    Описание опции начинается с символа О. В остальном справедливы замечания, представленные в предыдущем абзаце о макро.

    Прежде чем изменять конфигурационный файл рекомендуется сделать его копию. Усовершенствования не всегда работают так, как ожидает их автор.

    Опция OL# определяет уровень работы журнала операций. Эта опция управляет объемом информации, которая записывается в log-файл при работе программы sendmail. Чем больше число, проставленное вместо символа #, тем больше информации будет записано. Наибольшему уровню соответствует цифра 9.

    Опция Om служит для расширения псевдонимов. Если пользователь посылает сообщение адресату, обозначенному псевдонимом, и имя отправителя присутствует в списке псевдонимов, действием по умолчанию будет блокировка посылки самому себе. Опция Om переписывает значение по умолчанию и отправитель также получит свое сообщение. Некоторые пользователи используют такую возможность для контроля того, что сообщение было действительно послано.

    Опции Or<время> и OT<время> являются опциями таймаута. Опция ОТ производит запись проблемного сообщения в очередь и осуществляет повторную попытку через специфицированный промежуток времени, прежде чем отправитель будет проинформирован о неудаче. Опция Or специфицирует значение таймаута для операций чтения. Если при получении почты от удаленной ЭВМ возникает пауза, в течение которой не приходит ничего, sendmail по истечение заданного времени прерывает процесс и закрывает соединение. Так как эта опция, вообще говоря, нарушает стандарт RFC-821, значение таймаута должно быть достаточно велико.

    Опция OW специфицирует пароль для операций процессора. По существу это лазейка для выполнения пользователем некоторых операций, которые непосредственно для почтовой программы не нужны. Эта опция используется программистами для выявления проблем в работе основной программы, реализующей почтовый протокол.

    Сразу после инсталляции следует поменять значение этого пароля (заменить значение, установленное по умолчанию). Удаление строки соответствующей данной опции, автоматически приведет к установлению пароля по умолчанию.

    Опция или Оо означает, что имена получателей могут разделяться пробелами (стандарт требует применения запятых).

    Опция OD служит, для того чтобы автоматически осуществлять актуализацию базы данных при изменении файла псевдонимов (alias).

    Привилегированные пользователи могут изменить имя поля From, которое используется при посылке сообщений об ошибках. Это имя может быть изменено с помощью команды -f<пользователь>.

    Файл alias обычно размещается в каталоге /usr/lib/aliases и служит для создания почтовых ящиков, которым не соответствует никакой аккоунт пользователя. В этом файле определяется, в какой почтовый ящик следует направлять сообщение, адресованное субъекту с указанным псевдонимом. Допускается направление сообщений вместо какого-либо почтового ящика на stdin. Стандартная строка переадресации в этом файле выглядит как.

    alias: имя_пользователя или
    alias: имя_пользователя_1, имя_пользователя_2, имя_пользователя_3, .

    Первая строка перенаправляет все сообщения, адресованные alias пользователю с указанным именем. Второй пример соответствует случаю, когда все сообщения, адресованные alias переадресовываются всем пользователям из предлагаемого списка. Этот список может быть продолжен на следующей строке, если пред CR ввести символ \. В качестве имен пользователей могут быть записаны полные почтовые адреса типа vanja.ivanov@somewhere.ru или локальное имя. Для особо длинных списков имен можно указать файл, где этот список содержится. Для этого в файл /usr/lib/aliases нужно занести стоку типа.

    Participants: ":include:/usr/local/lib/participants.list"

    Обычно желательно включать псевдоним "почтмейстера" и администратора. Когда пользователь на удаленной ЭВМ не может найти имя аккоунта или ЭВМ, он может послать запрос по одному из этих псевдонимов.

    Одной из наиболее эффективных (и опасных в то же самое время) особенностей файла alias является возможность перенаправлять приходящую почту программе, базирующейся на псевдониме. Когда первый символ имени аккоунта в псевдониме является вертикальной чертой (|), имя воспринимается как наименование программы, которой следует передать управление. Приходящее сообщение будет передано этой программе, как если бы этот текст был введен с консоли. В файле псевдонимов вертикальная черта работает также как в ядре UNIX. Таким образом, строка:

    listserv: "|/usr/local/bin/listserv -l"

    пошлет почтовый файл программе listserv, как если бы вы выполнили команду cat mailfile|listserv -l. В действительности так работают серверы подписных листов (LISTSERV). Администратор устанавливает псевдоним, а программа listserv транслирует строку поля Subject или тела сообщения в качестве команды, управляющей работой почтового сервера рассылки. Следует иметь в виду, что эта техника представляет достаточно серьезную угрозу безопасности. По этой причине ее использование должно быть обставлено соответствующими мерами (например, аутентификацией с использованием шифрованных паролей).

    Previous: 4.4.14.4 Многоцелевое расширение почты Интернет (MIME)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5 Процедуры Интернет    Next: 4.4.15 Сетевой протокол времени NTP


    previous up down next index index
    Previous: 4.5.1 Ping и Traceroute    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.3 Удаленный доступ (Telnet)

    4.5.2 Finger
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Finger является простым протоколом (RFC-1288), который служит для получения информации о пользователях узлов Internet. Протокол использует TCP-порт 79. Команда Finger может дать вам данные о списке пользователей, которые работают в данный момент на интересующей вас ЭВМ, о конкретном пользователе (дата последнего сеанса входа в систему и т.д.), о списке загруженных задач, о типах интерфейсов (например, терминалов). Данный протокол обеспечивает интерфейс для удаленной информационной программы пользователя (RUIP - Remote User Information Program).

    Первоначальная версия такой программы была написана Les Earnest. Окончательная версия протокола была подготовлена Earl Killian из Мессачусетского Технологического Института и Brian Harvey (SAIL).

    Протокол Finger базируется на TCP. Локальная ЭВМ осуществляет TCP-соединение с удаленным узлом через указанный порт. После этого становится доступной программа RUIP и пользователь может посылать ей свои запросы. Каждый запрос представляет собой строку текста. RUIP, получив запрос, анализирует его и присылает ответ, после чего соединение закрывается.

    Любые пересылаемые данные должны иметь формат ASCII, не иметь контроля по четности и каждая строка должна завершаться последовательностью CRLF (ASCII 13, за которым следует ASCII 10).

    Программа RUIP должна воспринимать любые запросы Finger. Такие запросы могут иметь следующий формат:

    {Q1} ::= [{W}|{W}{S}{U}]{C}
    {Q2} ::= [{W}{S}][{U}]{H}{C}

    где {U} ::= имя_пользователя

    {H} ::= @hostname | @hostname{H}
    {W} ::= /W
    {S} ::= | {S}
    {C} ::=

    {H}, является рекурсивным, по этой причине не существует каких-либо ограничений на число лексем типа @hostname в запросе. В примере спецификации {Q2}, число лексем @hostname не может превышать двух.

    Следует иметь в виду, что в случае запросов "finger user@host". Программа RUIP в действительности получит "user".

    Запрос {Q2} требует переадресации запроса другой программе RUIP. Программа RUIP может либо осуществить эту процедуру, либо отказать в переадресации. В случае выполнения запроса она должна это подтвердить:

    Сообщая, что:

    ЭВМ <H1> открывает соединение Finger <F1-2> с RUIP на ЭВМ <H2>.

    <H1> выдает <H2> RUIP запрос <Q1-2> типа {Q2} (например, FOO@HOST1@HOST2).

    При этом следует извлечь информацию о том, что:

    ЭВМ <H2> является самой правой ЭВМ в запросе <Q1-2> (например, HOST2)

    Запрос <Q2-3> является остатком запроса <Q1-2> после удаления правой части "@hostname" (например, FOO@HOST1)

    Таким образом:

    <H2> RUIP должна открыть соединение <F2-3> с <H3>, используя <Q2-3>.
    <H2> RUIP должна прислать любую информацию, посланную от <F2-3> к <H1> через <F1-2> .
    <H2> RUIP должна закрыть <F1-2> в нормальных обстоятельствах только когда <H3> RUIP закрывает <F2-3> .

    По большей части вывод RUIP не следует каким-либо жестким регламентациям, так как он предназначен для чтения людьми, а не программами. Главное требование - информативность может ограничиваться только соображениями безопасности.

    Запрос {C} требует выдачи списка всех работающих пользователей. RUIP должна либо ответить, либо активно отказаться. Если она отвечает, тогда она должна выдать, по крайней мере, полные имена пользователей. Системный администратор может включить в выдачу и другую полезную информацию, такую как:

    • Положение терминала
    • Расположение офиса
    • Рабочий номер телефона
    • Должность
    • Время пребывания в пассивном состоянии (число минут с момента ввода последнего символа или со времени завершения последней сессии).

    Запрос {U}{C} является требованием присылки информации о статусе определенного пользователя {U}. Если вы не хотите выдавать такую информацию, тогда следует заблокировать работу Finger.

    Ответ должен включать в себя полное имя пользователя. Если пользователь активно работает в сети, то присылаемые данные должны включать, по крайней мере, тот же объем информации что и при запросе {C}.

    Так как это запрос информации об отдельном пользователе, администратор может добавить определенную информации об этом человеке, например:

    • Расположение офиса
    • Рабочий номер телефона
    • Номер домашнего телефона
    • Статус работы в системе (not logged in, logout time, и т.д.)
    • Информационный файл пользователя

    Информационный файл пользователя может содержать короткое сообщение, которое оставляет пользователь для передачи по запросу Finger. (Это иногда называется "plan" файлом). Это легко реализуется путем поиска программой в корневом каталоге (или в специально выделенном каталоге) пользователя файла с заданным именем. Системному администратору должно быть разрешено включать и выключать эту опцию.

    При запросе Finger существует возможность запуска определенной программы пользователя. Если такая опция предусмотрена, системному администратору должно быть позволено запрещать эту процедуру. Данная опция, создавая определенные угрозы, практически беспредельно расширяет возможности Finger (см. примеры в конце раздела).

    В командной строке допустимо имя пользователя или имя, под которым он входит в систему. Если имя неопределенно, реакция системы определяется системным администратором.

    Лексема /W в запросе типа {Q1} или {Q2} в лучшем случае интерпретируется последней RUIP и означает требование выдачи максимально возможной информации о пользователе, в худшем случае она игнорируется.

    Продающие автоматы должны реагировать на запрос {C} выдачей списка всех предметов, предлагаемых для продажи в данный момент Продающие автоматы должны откликаться на запросы {U}{C}, сообщая число различных продуктов или отделений для размещения продуктов.

    Корректная реализация Finger крайне важна. В частности, RUIP должна защищать себя от некорректного ввода. Конкретная реализация программы должна проходить столь же тщательную проверку, как Telnet, FTP или SMTP.

    Следует учитывать, что Finger раскрывает информацию о пользователях. Лица, ответственные за сетевую безопасность, должны решить разрешать или нет работу Finger, и какую информацию о пользователях следует рассылать.

    Сетевой администратор должен иметь возможность разрешать и запрещать прохождение запросов {Q2}. Если обработка запросов {Q2} RUIP заблокировано, программа должна отсылать соответствующее сообщение (например, "Finger forwarding service denied"). По умолчанию обработка запросов {Q2} должна быть запрещена.

    Программа RUIP при отправке данных должна отфильтровывать все символы вне диапазона (ASCII 32 - ASCII 126), за исключением TAB (ASCII 9) и CRLF. Такая мера обезопасит получателя.

    Примеры реализации запросов.

    Узел: elbereth.rutgers.edu

    Командная строка: <CRLF>

    Login Name TTY Idle When Office
    rinehart Mark J.Rinehart p0 1:11 Mon 12:15 019 Hill x3166
    greenfie Stephen J.Greenfiel p1 Mon 15:46 542 Hill x3074
    rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
    pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
    dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
    dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
    cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
    harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
    brisco Thomas P.Brisco pe 2:09 Mon 13:37 h055 x2351
    laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
    cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
    Узел: dimacs.rutgers.edu
    Командная строка: pirmann<CRLF>
    Login name: pirmann In real life: David Pirmann
    Office: 016 Hill, x2443 Home phone: 989-8482
    Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
    Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
    No unread mail
    Project:
    Plan:
    Work Schedule, Summer 1990
    Rutgers LCSR Operations, 908-932-2443
    Monday 5pm - 12am
    Tuesday 5pm - 12am
    Wednesday 9am - 5pm
    Thursday 9am - 5pm
    Saturday 9am - 5pm
    larf larf hoo hoo
    Login name: surak In real life: Ron Surak
    Office: 000 OMB Dou, x9256
    Directory: /u2/surak Shell: /bin/tcsh
    Last login Fri Jul 27 09:55 on ttyq3
    No Plan.
    Login name: etter In real life: Ron Etter
    Directory: /u2/etter Shell: /bin/tcsh
    Never logged in.
    No Plan.

    Узел: dimacs.rutgers.edu

    Командная строка: hedrick@math.rutgers.edu@pilot.njin.net
    [pilot.njin.net]
    [math.rutgers.edu]
    Login name: hedrick In real life: Charles Hedrick
    Office: 484 Hill, x3088
    Directory: /math/u2/hedrick Shell: /bin/tcsh
    Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
    No unread mail
    No Plan.

    Формат применения команды Finger:

    finger [ опции ] имя...

    По умолчанию finger отображает информацию обо всех активно работающих пользователях, включая имя-идентификатор, полное имя, имя терминала и т.д. В качестве имени может использоваться имя-идентификатор, фамилия или имя пользователя. Ниже приводится краткий перечень допустимых опций.

    -l

    Запрос подробной информации

    -s

    Запрос краткой информации

    -q

    Запрос имени-идентификатора, имени терминала и времени входа в систему

    -i

    Запрос, аналогичный -q, но выдается и время пребывания терминала в пассивном состоянии

    -w

    Блокирует печать полного имени для -s

    -h

    Блокирует печать файла .project в режиме -l

    -p

    Блокирует печать файла .plan в режиме -l

    Список работающих пользователей хранится в файле /etc/utmp, полный список имен пользователей размещен в файле /etc/passwd, времена и даты входа в систему записаны в файле /var/adm/lastlog, имена и расположение терминалов можно найти в файле /etc/ttytab, для записи информации о планах и проектах используются файлы ~/.plan и ~/.project, соответственно.

    Ниже приведен пример отклика на команду finger -l (запрос подробной информации, ЭВМ SUN):

    Login name: Ivanov

    In real life: Andrey Bobyshev

    Directory: /u1/SunITEP/bobyshev

    Shell: /bin/csh

    On since Aug 10 10:16:35 on ttyp0 from x4u2.desy.de

    1 minute 37 seconds Idle Time

    Mail last read Thu Aug 10 12:06:20 1995

    No Plan.

    (Никаких планов)

    Login name: Petrov

    In real life: Yuri Semenov

    Directory: /u1/SunITEP/semenov Shell: /bin/csh
    On since Aug 10 12:14:19 on ttyp3 from semenov.itep.ru
    33 seconds Idle Time
    No unread mail
    No Plan.

    Login name: Sidorov In real life: UU

    Ekatirin

    Directory: /var/spool/uucppublic Shell:
    /usr/local/lib/uucp/uucico
    On since Aug 10 12:16:04 on ttyy01 57 minutes Idle Time
    Mail last read Wed Nov 16 18:17:50 1994
    No Plan.

    В общем случае при обращении к finger может использоваться символьный Интернет-адрес:

    Finger <имя_адресата>@Internet_адрес.

    Возможности команды Finger варьируются в широких пределах в зависимости от конкретной реализации. Так команда (PCTCP): finger semenov@vxdesy.desy.de выдаст на экран:

    [vxdesy.desy.de]
    SEMENOV Semenov, Yuri SEMENOV not logged in (и это истинная правда)
    Last login Thu 5-Jan-95 2:35PM-CET
    [No plan]

    Дополнительную информацию о команде finger можно получить:

    Описание протокола

    ftp nic.merit.edu

    documents/rfc/rfc1288.txt

    ftp.csd.uwm.edu

    pub/fingerinfo

    Информация по электронной почте

    dlangley@netcom.com

    в поле subject:"#finger USER@HOST.DOMAIN"

    Через удаленный доступ

    telnet rpi.edu :79

    Через WWW

    http www.dlr.de cgi-greving/mfinger
    http sundae.triumf.ca fingerinfo.html

    Через finger

    finger help@dir.su.oz.au

    Цифра после двоеточия - номер порта. Последняя строка говорит о некоторых необычных возможностях Finger. Опция выдачи содержимого файла пользователя и исполнения программы пользователя расширяет возможности Finger почти беспредельно. Так, выдав команду finger help@dir.su.oz.au (Австралия), получим:

    [extra.ucc.su.OZ.AU]
    **** This is an experimental service offered free of charge by ****
    **** The University Computing Service, University of Sydney. ****
    **** Please mail support@is.su.edu.au if you have any queries. ****

    Finger offers these additional services (Finger предлагает некоторые дополнительные возможности):

    • Access to a database facility (доступ к базе данных)
      Usage (использование): finger %@dir.su.edu.au

    is usually an "egrep" regular expression and can be (в качестве обычно используется стандартное "egrep"-выражение, а вместо можно записать):

    Aarnet

    resources available on AARNet (ресурсы AARNet)

    Buildings

    buildings and their codes at Sydney Uni (коды зданий сиднейского университета)

    Archie

    query anonymous FTP databases (анонимный поиск по FTP-депозитариям)

    Internet

    resources available on the Internet (ресурсы Internet)

    Library

    library access available via AARNet (доступ к библиотечным базам данных)

    Newsgroups

    find NetNews newsgroups (поиск новостей)

    Phone

    The Sydney Uni Phone Book (телефонная книга Сиднейского университета)

    Postcodes

    Australian Postcodes (австралийские почтовые коды)

    Shop

    prices at the UCS shop (цены в университетском магазине)

    Usage (использование):

    Finger help@dir.su.edu.au

    this help (данный справочный материал)

    Finger help%@dir.su.edu.au

    on a particular database facility

    Finger copyright@dir.su.edu.au

    please read this copyright notice

    Finger egrep@dir.su.edu.au

    a manual on egrep regular expressions (справочные материалы по допустимым egrep-выражениям).

    Замечание. Задавая ключевые слова, избегайте применения специальных символов, пробелы относятся к их числу.

    Выдав команду:

    Finger 2%AArnet@dir.su.edu.au

    (запрос содержимого второй раздела базы данных aarnet);

    получим:

    [extra.ucc.su.oz.au]
    Index for Chapter 2 (список библиотек):
    Australian Defense Force Academy Library
    The Australian National University Library
    Curtin University Of Technology T.L. Robertson Library
    Deakin University Library
    Griffith University, Division of Information Services
    La Trobe University Library
    Macquarie University Library
    Murdoch University Library
    R.M.I.T. Library - MATLAS Library Catalogue.
    Swinburne Library
    The University of Adelaide, Barr Smith Library
    The University of Melbourne Baillieu Library
    The University of New England Library
    The University of New South Wales
    The University of Newcastle Libraries
    The University of Queensland Libraries
    The University of Western Australia, Reid Library
    The University of Wollongong Library
    University College of Central Queensland Library
    University of South Australia Library Systems Dept
    Victoria University of Wellington

    Таким образом, даже с помощью Finger можно организовать доступ к базам данных. Finger не сработает для узлов, не имеющих IP-адресов (например, электронный почтовый адрес). Эта команда всегда позволит руководителю проекта узнать, например, когда последний раз тот или иной участник проекта работал на ЭВМ. :-)

    Previous: 4.5.1 Ping и Traceroute    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.3 Удаленный доступ (Telnet)


    previous up down next index index
    Previous: 4.5.2 Finger    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS

    4.5.3 Удаленный доступ (Telnet)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    TELNET позволяет пользователю установить TCP-соединение с сервером и затем передавать коды нажатия клавиш так, как если бы работа проводилась на консоли сервера. TELNET (RFC-854, в некоторых реализациях tn) служит для выполнения удаленного доступа к вычислительным ресурсам и базам данных (например, к базам ядерных данных в Вене, Брукхейвене или STN-international в Карлсруэ). Для входа в базу данных или ЭВМ обычно нужна аутентификация (ввод имени-идентификатора пользователя и его слова-пропуска). В некоторых реализациях допускается использование параметров, которые подключают необходимые эмуляторы терминалов.

    TELNET предлагает три услуги:

    1. Определяет сетевой виртуальный терминал (NVT - network virtual terminal), который обеспечивает стандартный интерфейс к удаленной системе.
    2. Включает механизм, который позволяет клиенту и серверу согласовать опции обмена
    3. Обеспечивает симметрию соединения, допуская любой программе (например FTP) выступать в качестве клиента

    Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в кодах ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т. д.). На прикладном уровне над TELNET находится либо программа поддержки реального терминала, либо прикладной процесс в обслуживающей машине, к которому осуществляется доступ с терминала. Формат NTV достаточно прост. Для данных используются 7-битовые ASCII коды. 8-битовые же октеты зарезервированы для командных последовательностей.

    Telnet взаимодействует с другой ЭВМ через протокол TELNET. Если команда TELNET вводится без аргументов ЭВМ переходит в командный режим, напечатав приглашение telnet>. В этом режиме она воспринимает и исполняет команды, описанные ниже.

    При вводе TELNET с аргументами программа осуществит связь вашей ЭВМ с удаленным компьютером, имя или адрес которого вы ввели в качестве одного из аргументов.

    После того как TELNET связь установлена, начинаются переговоры об используемых опциях (см. табл. 4.5.3.1). Каждая из договаривающихся сторон может послать другой один из четырех запросов will, do, wont и dont (см табл. 4.5.3.4).

    Далее TELNET переходит в режим ввода. В этом режиме любой введенный текст пересылается удаленной ЭВМ. Ввод может производиться посимвольно или построчно. При посимвольном режиме каждый введенный символ пересылается немедленно, при построчном режиме отклик на каждое нажатие клавиши производится локально, а пересылка выполняется лишь при нажатии клавиши <Enter>. Некоторые опции требуют дополнительных данных, такая информация ожет быть получена с помощью субопций (RFC-1091). При этом клиент посылает трехбайтовую последовательность IAC WILL 24, где 24 - код-идентификатор терминала. Получатель может откликнуться последовательностью IAC DO 24, если все в порядке. Сервер в свою очередь посылает последовательность IAC SB 24 1 IAC SE, запрашивая тип терминала клиента. Здесь код 24 означает, что это субопция для опции типа терминала (см. табл. 4.5.3.1), а следующая 1 является командой "пришлите код вашего терминала". Клиент в свою очередь может откликнуться, послав последовательность - IAC SB 24 0 I B M P C IAC SE. Здесь байт 0 имеет значение "мой терминал имеет тип". Список кодов терминалов содержится в RFC-1700.

    Таблица 4.5.3.1. Коды опций в Telnet

    Код опции в Telnet

    Описание

    Номер RFC

    0

    Двоичный обмен

    856

    1

    Эхо

    857

    2

    Повторное соединение

    NIC 15391

    3

    Подавление буферизации ввода

    858

    4

    Диалог о размере сообщения

    NIC 15393

    5

    Статус

    859

    6

    Временная метка

    860

    7

    Удаленный доступ и отклик

    726

    8

    Длина выходной строки

    nic 20196

    9

    Размер выходной страницы

    nic 20197

    10

    Режим вывода символов <возврат каретки>

    652

    11

    Вывод горизонтальной табуляции

    653

    12

    Установка положения табуляции при выводе

    654

    13

    Режим вывода команды смены страницы

    655

    14

    Вывод вертикальной табуляции

    656

    15

    Определяет положение вертикальной табуляции

    657

    16

    Режим вывода символа <перевод строки>

    658

    17

    Расширенный набор кодов ASCII

    698

    18

    Возврат (logout)

    727

    19

    Байт-макро

    735

    20

    Терминал ввода данных

    732

    21

    Supdup

    736

    22

    Supdup вывод

    747

    23

    Место отправления

    779

    24

    Тип терминала

    930

    25

    Конец записи

    885

    26

    Tacacs- идентификация пользователя

    927

    27

    Пометка вывода

    933

    28

    Код положения терминала

    946

    29

    Режим 3270

    1041

    30

    X.3 PAD

    1053

    31

    Размер окна

    1073

    Когда связь с удаленной ЭВМ уже осуществлена, переход в командный режим может быть выполнен с помощью нажатия '^]' (escape).

    В этом режиме доступны команды:

    open имя_ЭВМ [ порт ]

    open открывает связь с ЭВМ, имя которой указано в обращении. Если номер порта явно не указан, telnet пытается использовать для связи с сервером номер порта по умолчанию. Вместо имени ЭВМ-сервера может использоваться ее IP-адрес.

    display [ аргумент ... ]

    Отображает все, или часть, набора параметров telnet (см. описание команды send).

    close

    Закрывает сессию telnet и возвращает систему в командный режим.

    quit

    Закрывает любую сессию telnet.

    mode type

    Управляет режимом ввода ("построчный" или "посимвольный"). Удаленной машине посылается запрос на переход в соответствующий режим. Если она готова (способна) работать в запрошенном режиме, будет произведено соответствующее переключение.

    status

    Отображает текущий статус telnet. В перечень информации входит имя удаленной ЭВМ и действующий режим обмена.

    ? [ команда ]

    Выдает справочную информацию о команде, название которой приведено в качестве аргумента

    send arguments

    Посылает удаленной ЭВМ один или несколько символьных аргументов. В качестве аргументов могут использоваться: escape, synch, brk, ip, ao, ayt, ecel, ga и др. Смотри таблицу 4.5.3.3.

    escape

    Посылает escape символ (например, `^]').

    SYNCH

    Посылает synch-последовательность. Эта последовательность позволяет аннулировать все, что было до этого напечатано, но еще не считано. Эта последовательность посылается как срочная (важная) TCP-информация (может не сработать, если удаленной системой является 4.2 BSD). Если она не сработала, на терминал будет послан символ "r".

    brk

    Посылает Break-последовательность при нажатии клавиши Break (Pause). (Исчерпывающую информацию об аргументах можно найти в описании используемого программного обеспечения или с помощью команд Help или Man)

    set argument value

    Присваивает любому числу переменных telnet новые значения. Специальное значение "off" выключает функцию, соответствующую данной переменной

    Значения переменных можно узнать с помощью команды display. Такими переменными могут быть: echo, escape, interrupt, quit, flushoutput, erase, kill, eof, echo. Последняя переменная (в исходном состоянии `^E') в построчном режиме осуществляет переключение между локальным эхо на ввод символа (режим по умолчанию) и подавлением эхо, например при вводе пароля. Переменные процедуры telnet представлены в таблице 4.5.3.2.

    Практически стандарт TELNET описан во многих RFC документах, которые определяют различные варианты реализации этой команды. Список опций команды telnet приведен в таблице 4.5.3.1 (не все эти возможности доступны в конкретных программных продуктах).

    Таблица 4.5.3.2. Переменные telnet

    Название переменной

    Назначение

    Echo

    Определяет, будет ли отображаться на экране то, что вы вводите с клавиатуры. При значении off ввод не отображается, например, при вводе пароля.

    Escape

    Задает символ, который используется в качестве escape. Появление этого символа во входном потоке заставляет его и последующие символы интерпретироваться в ЭВМ, где функционирует процесс telnet, как команда

    Interrupt

    Специфицирует символ прерывания процесса. Ввод его приводит к остановке процесса пользователя, работающего на удаленной ЭВМ.

    Quit

    Специфицирует символ, который используется пользователем на его клавиатуре для выполнения команд brake или attention.

    Flushoutput

    Определяет символ, который служит для прерывания процедуры вывода на удаленной ЭВМ.

    EOF

    Специфицирует символ, который используется для обозначения конца файла на удаленной машине.

    Таблица 4.5.3.3. Последовательности символов, используемые совместно с командой send

    Последовательность символов

    Назначение

    ?

    Отображает справочную информацию о команде send

    escape

    Посылает символ escape (без прерывания посылки символов для Telnet)

    ip

    Посылает протокольную последовательность telnet. Удаленная машина должна прервать процесс, запущенный для вас.

    ec

    Посылает протокольную EC-последовательность telnet. Удаленная ЭВМ должна стереть последний напечатанный вами символ

    el

    Посылает протокольную EL-последовательность TELNET. Удаленная ЭВМ должна стереть последнюю напечатанную вами строку.

    ao

    Посылает протокольную AO-последовательность TELNET. Удаленная ЭВМ должна направить весь вывод на ваш терминал.

    brk

    Посылает протокольную BRK-последовательность TELNET. Удаленная ЭВМ должна обеспечить отклик.

    ayt

    Посылает протокольную AYT-последовательность TELNET (Are You There). Удаленная ЭВМ должна обеспечить отклик.

    В таблице 4.5.3.4 представлены наименования и коды команд Telnet, которые используются как клиентом, так и сервером в сочетании с префиксным байтом 0xff (IAC - "интерпретировать как команду"). Если нужно послать код данных, равный 255, посылается два байта с кодами 255.

    Таблица 4.5.3.4. Коды команд TELNET

    Имя субкоманды TELNET

    Код

    Описание

    EOF

    236

    Признак конца файла

    SUSP

    237

    Отложить исполнение текущего процесса

    ABORT

    238

    Абортировать процесс

    EOR

    239

    Конец записи

    NOP

    241

    Никаких действий

    DM(Метка данных)

    242

    Блок данных процедуры SYNCH

    BRK (Остановка)

    243

    brk-символ (break);

    IP(Прерывание процесса)

    244

    IP-функция

    io (Прерывание вывода)

    245

    AO-функция

    AYT (Вы здесь?)

    246

    ayt-функция

    EC (Стереть символ)

    247

    EC-функция

    EL (Стереть строку)

    248

    EL-функция

    GA (Продолжайте)

    249

    GA-функция

    SB

    250

    Начало субопции

    SE

    240

    Завершение согласования параметров (конец субопции)

    Will ("будет")

    251

    Начало исполнения (опционно)

    Won't (не будет)

    252

    Отказ исполнения или продолжения выполнения (опционно)

    Do("исполнить")

    253

    Индицирует запрос, который другая система исполняет (опционно)

    Don't ("Нет")

    254

    Требует, чтобы другая система остановила исполнение (опционно)

    IAC

    255

    Интерпретируется как начало командной последовательности

    Операция прерывание процесса (IP) позволяет прервать, удалить или завершить процесс пользователя (например, выйти из бесконечного цикла).

    Процедура прерывание вывода (AO) позволяет процессу пользователя продолжаться, но вывод на его рабочую станцию прерывается, при этом очищается буфер от уже записанной, но не отображенной информации.

    Запрос "Вы здесь?" (AYT) удобен, когда необходимо выяснить выполняется ли пользовательская задача или нет.

    Операция стереть символ (EC) позволяет пользователю удалить символ из потока данных, применяется для редактирования текста на экране.

    Операция стереть строку (EL) позволяет пользователю при редактировании удалить целую строку.

    Команда "go ahead" (GA, "продолжайте") устанавливает полудуплексный режим передачи данных. Каких-либо воздействий на удаленную ЭВМ обычно не производит. В таблице 4.5.3.5 приведен список комбинаций клавиш, нажатие которых вызывает определенный результат.

    Таблица 4.5.3.5. Управляющие комбинации клавиш

    Комбинация клавиш

    Достигаемый результат

    Ctrl+E

    Echo

    Ctrl+]

    Escape

    Ctrl+?

    Erase

    Ctrl+O

    flushoutput

    Ctrl+C

    Interrupt (прерывание исполнения программы)

    Ctrl+U

    Kill

    Ctrl+\

    Quit

    Ctrl+D

    EOF

    Блок данных процедуры TELNET содержит три байта и называется командой. Формат этого блока показан на рис. 4.5.3.1.

    Рис. 4.5.3.1. Формат блока данных Telnet

    Первый байт в соответствии с таблицей содержит 8 единиц, далее следует байт команды (табл. 4.5.3.4). Третий октет служит для размещения кода опции, он может и отсутствовать.

    Рассмотрим несколько примеров этих команд. Допустим, вы хотите, чтобы обмен данными производился в виде 8-битовых посылок. Для реализации вашего пожелания достаточно выдать команду:

    IAC WILL TRANSMIT-BINARY,

    которая в цифровых кодах выглядит как - (255 251 0).

    Для прекращения этого (двоичного) режима передачи нужно выдать команду:

    IAC DON'T TRANSMIT-BINARY (255 254 0).

    Субкоманды Telnet позволяют управлять откликом при работе с клавиатурой. Обычно отклик-эхо присылается удаленной ЭВМ, реже формируется локально. Для включения отклика можно выдать команду: IAC WILL ECHO (255 251 1) (часто это реализовано по умолчанию). Далее можете поупражняться самостоятельно и проверить какие команды и их опции доступны в используемом вами программном продукте.

    При работе с Telnet рекомендуется сначала ознакомиться с конкретными возможностями команды с помощью описания (или F10/?). Это позволит вам, например, спасать результаты поиска в файле с указанным вами именем и т.д. Например, для PCTCP такая команда выдаст на экран:

    Telnet with VT220 and 3270 emulation, escape character is alt-F10 or F10
    Copyright (c) 1989-1992 by FTP Software, Inc. All rights reserved.

    ?

    display this help message

    a

    sends Telnet AYT request

    ^h

    debugging command help

    b

    send Telnet Interrupt Process

    o

    write receive data to output file

    z

    send Telnet Abort output

    i

    read keystrokes from an input file

    t

    send Telnet Break

    c

    close connection gracefully

    !

    escape to command interpret

    q/Q

    quit current/all telnet connections

    I

    show local internet address

    F

    toggle build-in FTP-server on/off

    U

    turn status line on

    W

    toggle FTP server write-protect mode

    u

    turn status line off

    0-9

    switch to connection #

    s

    Enable pop-up TSR with hot-key

    p

    Select code page remapping

    S

    Toggle screen-saver key-passing

    -------------------------- VT220 emulator commands ------------------------------

    R

    Enter key send CR

    l

    local echo mode

    N

    Enter key send newline (CRLF)

    r

    remote echo mode

    E

    send characters as typed

    w

    turn end-of-line wrap on

    E

    send line when ENTER is typed

    d

    turn end-of-line wrap off

    B

    <-key sends BS; CTL_<-key sends DEL

    set emulator mode (VT52|100|220)

    D

    <- key sends DEL; CTL_<-key sends BS

    ---------------------------- 3270 emulator commands ----------------------------

    y

    set Yale Null Processing off

    Y

    set Yale Null Processing on

    [Press SPACE to return to session, or enter another command (? for Help]

    Многие telnet-клиенты позволяют также указывать явно номер порта, через который должна быть установлена связь. По умолчанию это порт 23. Обычный пользователь не интересуется, через какой порт он работает. Но иногда желательно реализовывать telnet через разные порты системы, обеспечивающие различные услуги, это бывает полезно и с отладочными целями. Используя команду:

    telnet XXXXXX.domain <номер порта>

    можно осуществить связь через порт с заданным номером с узлом XXXXXX.domain. Многие библиотеки используют метод портов для обеспечения доступа к своим ресурсам внешних Inernet-пользователей. Ссылки на RFC-документы по протоколу TELNET смотрите в приложении. Помимо telnet существуют и другие стандартные процедуры, выполняющие схожие задачи.

    SUN Microsistems разработала и широко использует программный модуль RPC (Remote Procedure Call, RFC-1057), он используется для удаленного вызова программ почти во всех системах, базирующихся на UNIX. RPC может использоваться как на TCP, так и UDP транспортных уровнях.

    Для удаленного исполнения программ может служить команда REXECD, которая активно используется на IBM-системах в рамках ОС AIX и DOS. Уязвимость протокола Telnet для хакеров привела к тому, что в последнее время эта утилита часто заменяется SSH (Secure Shell) или другими программами, обеспечивающими безопасный удаленный доступ.

    Previous: 4.5.2 Finger    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS


    previous up down next index index
    Previous: 4.5.3 Удаленный доступ (Telnet)    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.4 Протокол пересылки файлов FTP

    4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    (RFC-2138. Remote Authentication Dial In User Service, P. Vixie, S. Thomson, Y. Rekhter, J. Bound.)

    1. Введение

    Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin).

    Модель клиент/сервер

    Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные.

    Серверы RADIUS принимают запросы от пользователей, осуществляют аутентификацию и выдают конфигурационную информацию, которая необходима клиенту, чтобы предоставить пользователю запрошенный вид услуг.

    Сервер RADIUS может выполнять функцию прокси-клиента по отношению к другим серверам RADIUS или прочим аутентификационным серверам.

    Сетевая безопасность

    Взаимодействие клиента и сервера RADIUS аутентифицируются с использованием общего секретного ключа (пароля), который никогда не пересылается по сети. Кроме того, каждый пароль пользователя пересылается от клиента к серверу в зашифрованном виде, чтобы исключить его перехват.

    Гибкие аутентификационные механизмы

    Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами.

    Масштабируемый протокол

    Все операции подразумевают использование ансамблей атрибут-длина-значение. Новое значение атрибута может быть добавлено без редактирования существующей версии реализации протокола.

    1.1. Терминология

    В этом документе используются следующие термины:

    Услуга

    NAS обеспечивает пользователю, подключенному через модем, определенные услуги, такие как PPP или Telnet.

    Сессия

    Каждый вид услуг, предоставляемый NAS через модемную связь, представляет собой сессию. Начало сессии сопряжено с моментом начала предоставления данной услуги, а конец - со временем завершения этого процесса. Пользователь может иметь несколько сессий одновременно, если сервер поддерживает такой режим.

    Молчаливое удаление (silently discard)

    Это означает, что программа выбрасывает пакет без какой-либо обработки. Программная реализация должна предоставлять возможность диагностирования таких случаев и записи их статистики.

    2. Работа

    Когда клиент сконфигурирован для использования RADIUS, любой пользователь предоставляет аутентификационные данные клиенту. Это может быть сделано с помощью традиционной процедуры login, когда пользователь вводит свое имя и пароль. В качестве альтернативы может использоваться протокол типаPPP, который имеет специальные пакеты, несущие аутентификационную информацию.

    Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]).

    Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен.

    Когда сервер RADIUS получил запрос, он проверяет корректность клиента-отправителя. Запрос, для которого сервер RADIUS не имеет общего секретного ключа (пароля), молча отбрасывается. Если клиент корректен, сервер RADIUS обращается к базе данных пользователей, чтобы найти пользователя, чье имя соответствует запросу. Пользовательская запись в базе данных содержит список требований, которые должны быть удовлетворены, прежде чем будет позволен доступ. Сюда всегда входит сверка пароля, но можно специфицировать клиента или порт, к которому разрешен доступ пользователя. Сервер RADIUS может посылать запросы к другим серверам, для того чтобы выполнить запрос, в этом случае он выступает в качестве клиента.

    Если хотя бы какое-то условие не выполнено, сервер посылает отклик "Access-Reject" (отклонение Access-Reject текст комментария.

    Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge). Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. Отклик-приглашение может содержать атрибут состояния (State). Если клиент получает Access-Challenge, он может отобразить текст сообщения и затем предложить пользователю ввести текст отклика. Клиент при этом повторно направляет свой Access-Request с новым идентификатором, с атрибутом пароля пользователя, замененным зашифрованным откликом. Этот запрос включает в себя атрибут состояния, содержащийся в приглашении Access-Challenge (если он там был). Сервер может реагировать на этот новый запрос откликами Access-Accept, Access-Reject, или новым Access-Challenge.

    Если все условия выполнены, список конфигурационных значений для пользователя укладываются в отклик Access-Accept. Эти значения включают в себя тип услуги (например: SLIP, PPP, Login User) и все параметры, необходимые для обеспечения запрошенного сервиса. Для SLIP и PPP, сюда могут входить такие значения как IP-адрес, маска субсети, MTU, желательный тип компрессии, а также желательные идентификаторы пакетных фильтров. В случае символьного режима это список может включать в себя тип протокола и имя ЭВМ.

    2.1. Запрос/Отклик

    При аутентификации приглашение/отклик, пользователю дается псевдослучайное число и предлагается его зашифровать и вернуть результат. Авторизованные пользователи снабжаются специальными средствами, такими как смарт-карта или программой, которая облегчает вычисление отклика.

    Пакет Access-Challenge обычно содержит сообщение-ответ, включая приглашение (challenge), которое должно быть отображено для пользователя. Обычно оно имеет форму числа и получается от внешнего сервера, который знает, какого типа аутентификатор должен быть применен для данного авторизованного пользователя и, следовательно, может выбрать псевдослучайное число заданной длины.

    Пользователь вводит приглашение в свое устройство или программу и вычисляет отклик, который через клиента транспортируется серверу RADIUS посредством второго сообщения Access-Request. Если отклик соответствует ожидаемому значению, сервер присылает сообщение Access-Accept, в противном случае - Access-Reject.

    Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение "challenge", но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой "Challenge 12345678, enter your response at the prompt", которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge.

    2. Работа с PAP и CHAP

    Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя.. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP.

    Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP.

    Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае - Access-Reject.

    Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он должен прислать сообщение Access-Reject. Например, CHAP требует, чтобы пароль пользователя должен быть доступен серверу в открытом текстовом виде, чтобы он мог зашифровать CHAP-вызов и сравнить его с CHAP-откликом. Если пароль не доступен серверу RADIUS в таком виде, он должен послать клиенту сообщение Access-Reject.

    2.3. Почему UDP?

    Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:

    1.

    Если запрос к первичному аутентификационному серверу не прошел, он должен быть переадресован вторичному серверу. Чтобы удовлетворить этому, копия запроса должна храниться на уровне выше транспортного, с тем, чтобы позволить альтернативную попытку. Отсюда следует, что необходим таймер ретрансмиссии.

    2.

    Временные требования данного конкретного протокола значительно отличаются от тех, которые обеспечивает TCP.

    3.

    Природа данного протокола не требует контроля состояния, что упрощает применение протокола UDP.

    Клиенты и серверы приходят и уходят. Системы перезагружаются, а сетевое питание выключается и включается... UDP полностью исключает влияние всех этих событий на работу системы. Любой клиент и сервер может открыть UDP обмен однажды и оставлять его в таком состоянии, игнорируя какие-либо сбои в сетевой среде.

    2.4. UDP упрощает реализацию сервера.

    В ранних реализациях RADIUS сервер поддерживал один процесс (single threaded). Это означает, что только один запрос принимался, обрабатывался и отправлялся. Это оказалось неприемлемым для сред, где механизм обеспечения безопасности требует определенного времени (1 или более секунд). Очередь запросов в сервере будет значительной и в средах, где сотни людей требуют аутентификации каждую минуту, время обслуживания запроса становится настолько большой, что начинает нервировать пользователей. Очевидным решением проблемы является многопроцессный сервер. Достичь этого проще всего с помощью UDP. Порождаются отдельные процессы для обслуживания каждого запроса, а эти процессы могут напрямую взаимодействовать с клиентом NAS путем отправки UDP-пакета.

    Это не панацея. Применение UDP требует организации повторных передач, для чего нужно на сервере запускать соответствующие таймеры. В этом UDP уступает TCP, но это небольшая плата за полученные преимущества.

    3. Формат пакета

    Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на рис. .1. Разряды пронумерованы в порядке их передачи.


    Рис. .1. Формат пакета RADIUS

    Поле код содержит один октет и идентифицирует тип пакета RADIUS. Если получен пакет с неверным значением поля код, он молча отбрасывается.

    Стандартизованы следующие значения поля код:

    Код

    Назначение

    1

    Запрос доступа (Access-Request)

    2

    Доступ разрешен (Access-Accept)

    3

    Доступ не разрешен (Access-Reject)

    4

    Accounting-Request

    5

    Accounting-Response

    11

    Access-Challenge

    12

    Сервер состояния (экспериментальный)

    13

    Клиент состояния (экспериментальный)

    255

    Зарезервировано

    Коды 4 и 5 будут описаны в документе [RFC-2139]. Коды 12 и 13 зарезервированы для возможного использования.

    Поле идентификатор имеет один октет, и служит для установления соответствия между запросом и откликом.

    Поле длина имеет два октета. Оно определяет длину пакета, включая поля код, идентификатор, длина, аутентификатор и атрибуты. Октеты за пределом, указанным полем длина, рассматриваются как заполнитель и игнорируются получателем. Если пакет короче, чем указано в поле длина, он должен быть молча выкинут. Минимальная длина равна 20, а максимальная - 4096.

    Поле аутентификатор имеет 16 октетов. Старший октет пересылается первым. Этот параметр служит для аутентификации отклика от сервера RADIUS, и используется в алгоритме сокрытия пароля.

    В пакетах Access-Request, значение поля аутентификатор равно 16-октетному случайному числу, называемому аутентификатор запроса. Его значение должно быть непредсказуемым и уникальным на протяжении жизни секретного пароля, совместно используемого клиентом и RADIUS-сервером.

    Значение аутентификатора запроса в пакете Access-Request должно быть также непредсказуемым, чтобы исключить возможные атаки.

    Хотя протокол RADIUS не может исключить всех возможных атак, в частности с использованием подключения к линии в реальном масштабе времени, но генерация псевдослучайных аутентификаторов все же обеспечивает относительную безопасность.

    NAS и сервер RADIUS используют секретный пароль совместно. Этот секретный пароль и аутентификатор запроса пропускаются через хэширование MD5, чтобы получить 16-октетный дайджест, который объединяется посредством операции XOR с паролем, введенным пользователем, результат помещается в атрибут пароля пользователя пакета Access-Request.

    Значение поля аутентификатор в пакетах Access-Accept, Access-Reject, и Access-Challenge называется аутентификатором отклика (Response Authenticator). Оно представляет собой однопроходную хэш-функцию MD5, вычисленную для потока октетов, включающих в себя: пакет RADIUS, начинающийся с поля код, и включающий поля идентификатор, длина, аутентификатор запроса из пакета Access-Request, и атрибуты отклика, за которыми следует общий секретный пароль. То есть ResponseAuth = MD5(Код+ID+длина+RequestAuth+атрибуты+секретный_пароль) где знак + означает присоединение.

    Секретный пароль, совместно используемый клиентом и сервером RADIUS, должен быть достаточно большим и непредсказуемым, как хороший пароль. Желательно, чтобы секретный пароль имел, по крайней мере, 16 октетов. Сервер RADIUS должен использовать IP-адрес отправителя UDP-пакета, чтобы решить, какой секретный пароль использовать.

    Когда используется переадресующий прокси-сервер, он должен быть способен изменять пакет при проходе в том или ином направлении. Когда прокси переадресует запрос, он может добавить атрибут Proxy-State, а при переадресации отклика, он удаляет атрибут Proxy-State. Так как ответы Access-Accept и Access-Reject аутентифицированы по всему своему содержимому, удаление атрибута Proxy-State сделает сигнатуру пакета некорректной. По этой причине прокси должен вычислить ее заново.

    Атрибуты

    Многие атрибуты могут быть записаны несколько раз, в этом случае порядок следования атрибутов одного и того же типа должен быть сохранен. Порядок атрибутов различных типов может быть изменен.

    В данном документе регламентированы атрибуты для пакетов с полем код, равным 1, 2, 3 и 11. Чтобы определить, какие атрибуты допускаются для пакетов с полем код=4 и 5, смотри [9].

    4. Типы пакетов

    Тип пакета RADIUS определяется полем тип, размещенным в первом октете.

    4.1. Запрос доступа

    Пакеты Access-Request посылаются серверу RADIUS, и передают информацию, которая используется для определения того, позволен ли данному пользователю доступ к специфицированному NAS, и допустимы ли запрошенные услуги. Программная реализация, желающая аутентифицировать пользователя, должна послать пакет RADIUS с кодом поля тип=1 (Access-Request).

    При получении запроса (Access-Request) доступа от корректного клиента, должен быть передан соответствующий ответ. Запрос доступа (Access-Request) должен содержать атрибут имени пользователя. Он должен включать в себя атрибут NAS-IP-адреса или атрибут NAS-идентификатора (или оба эти атрибута, хотя это и не рекомендуется). Он должен содержать атрибут пароля пользователя (User-Password) или атрибут CHAP-пароля. Желательно, чтобы он содержал атрибут NAS-порта или NAS-Port-Type или оба эти атрибута, если только тип запрошенного доступа не содержал номер порта.

    Запрос доступа (Access-Request) может содержать дополнительные атрибуты - подсказки серверу, но последний не обязан следовать этим подсказкам. Когда присутствует пароль пользователя (User-Password), он защищается с использованием метода, базирующегося на RSA алгоритме MD5 [1]. Формат пакета Access-Request аналогичен показанному на рис. .1. Только на месте поля аутентификатор размещается поле аутентификатор запроса (Request Authenticator), а в поле код записывается 1.

    Поле идентификатор должно измениться при изменении содержимого поля атрибуты, и при получении корректного ответа на предыдущий запрос. При повторных передачах поле идентификатор остается неизменным.

    Значение поля аутентификатор запроса (Request Authenticator) должно изменяться, когда используется новый идентификатор.

    Поле атрибуты имеет переменную длину и содержит список атрибутов, которые необходимы для заданного типа сервиса, а также любых дополнительных опционных атрибутов.

    4.2. Пакеты Access-Accept

    Пакеты Access-Accept посылаются сервером RADIUS, и предоставляют специфическую конфигурационную информацию, необходимую для предоставления пользователю соответствующего сервиса. Если все значения атрибутов, полученных с запросом Access-Request, приемлемы, тогда реализация RADIUS должна послать пакет с полем код=2 (Access-Accept). При получении сообщения Access-Accept, поле идентификатор соответствует обрабатываему запросу (Access-Request). Кроме того, поле аутентификатор отклика должно содержать корректный отклик на полученный запрос Access-Request. Пакеты неверного формата молча отбрасываются. Формат пакета Access-Accept идентичен показанному на рис. .1. Но здесь вместо поля аутентификатор используется поле аутентификатор отклика, имеющее тот же размер. В поле код при этом записывается число 2.

    Поле идентификатор является копией одноименного поля в запросе Access-Request, который инициировал сообщение Access-Accept.

    Значение поля аутентификатор отклика (Response Authenticator) вычисляется на основе значения Access-Request, как это описано выше. Поле атрибуты имеет переменную длину и содержит список из нуля или более атрибутов.

    4.3. Сообщение Access-Reject

    Если какое-либо значение полученного атрибута неприемлемо, тогда сервер RADIUS должен послать пакет с полем код= 3 (Access-Reject). Пакет может содержать один или более атрибутов Reply-Message с текстом, который может быть отображен NAS для пользователя. Поле идентификатор для данного пакета копируется из одноименного поля пакета Access-Request, вызвавшего данный отклик.

    Значение поля аутентификатор отклика вычисляется на основе содержимого сообщения Access-Request, как это описано выше.

    4.4. Сообщение Access-Challenge

    Если сервер RADIUS хочет послать пользователю вызов, требующий отклика, то сервер должен реагировать на запрос Access-Request посылкой пакета с полем код=11 (Access-Challenge). Поле атрибуты может содержать один или более атрибутов Reply-Message, и может опционно включать атрибут состояния. Никакие другие атрибуты здесь не применимы.

    При получении Access-Challenge, поле идентификатор соответствует содержимому пакета Access-Request. Кроме того, поле аутентификатор отклика должно содержать корректный отклик на обрабатываемый запрос Access-Request. Некорректные пакеты молча отбрасываются. Если NAS не поддерживает обмен вызов/отклик (challenge/response), он должен обрабатывать сообщение Access-Challenge, как если бы это был запрос Access-Reject.

    Если сервер NAS поддерживает обмен вызов/отклик, получение корректного сообщения Access-Challenge указывает, что следует послать новый запрос Access-Request. Сервер NAS может отобразить текстовое сообщение для пользователя, если таковое имеется, а затем предложить ему ввести отклик. Затем сервер посылает исходное сообщение Access-Request с новым идентификатором запроса и аутентификатором отклика, с атрибутом пароля пользователя, содержащим зашифрованный отклик пользователя. Кроме того, это сообщение содержит атрибут состояния (State) сообщения Access-Challenge, если таковой имелся.

    NAS, который поддерживает PAP может переадресовать сообщение Reply-Message клиенту, подключенному по модемному каналу, и принять PAP-отклик, который он может использовать как отклик, введенный пользователем. Если NAS этого сделать не может, он должен воспринимать Access-Challenge, как если бы он получил сообщение Access-Reject. Формат пакета Access-Challenge совпадает с форматом Access-Accept и Access-Request.

    Поле идентификатор является копией одноименного поля пакета Access-Request, который вызвал посылку Access-Challenge.

    Значение аутентификатора отклика вычисляется так, как это было описано выше. Поле атрибуты имеет переменную длину, и содержит список из нуля или более атрибутов.

    5. Атрибуты

    Атрибуты RADIUS несут в себе специфическую аутентификационную и конфигурационную информацию для запросов и откликов. Некоторые атрибуты могут быть включены в список более одного раза. Воздействие такого использования зависит от типа атрибута.

    Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина. Формат записи атрибута показан на рис. .2.


    Рис. .2. Формат записи атрибута

    Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 "Assigned Numbers" [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа.

    Таблица .1. Cпецификация стандартизованных значений атрибутов

    Код

    Назначение

    1

    Имя пользователя (User-Name)

    2

    Пароль пользователя (User-Password)

    3

    CHAP-пароль

    4

    NAS-IP-адрес

    5

    NAS-порт

    6

    Тип услуги (Service-Type)

    7

    Framed-Protocol

    8

    Framed-IP-адрес

    9

    Framed-IP-Netmask

    10

    Framed-Routing

    11

    Filter-Id

    12

    Framed-MTU

    13

    Framed-Compression

    14

    Login-IP-Host

    15

    Login-Service

    16

    Login-TCP-Port

    17

    (unassigned)

    18

    Сообщение-отклик (Reply-Message)

    19

    Callback-Number

    20

    Callback-Id

    21

    (не определено)

    22

    Framed-Route

    23

    Framed-IPX-Network

    24

    Состояние

    25

    Класс

    26

    Vendor-Specific

    27

    Таймаут сессии (Session-Timeout)

    28

    Idle-Timeout (таймаут пассивного состояния)

    29

    Termination-Action (процедура завершения)

    30

    Called-Station-Id

    31

    Calling-Station-Id

    32

    NAS-Идентификатор

    33

    Proxy-State

    34

    Login-LAT-Service

    35

    Login-LAT-Node

    36

    Login-LAT-Group

    37

    Framed-AppleTalk-Link

    38

    Framed-AppleTalk-Network

    39

    Framed-AppleTalk-Zone

    40-59

    (зарезервировано для акоунтинга)

    60

    CHAP-вызов (CHAP-Challenge)

    61

    NAS-Port-Type

    62

    Port-Limit

    63

    Login-LAT-Port

    Поле длина является однооктетным, оно определяет длину данного атрибута, включая субполя тип, длина и величина. Если атрибут получен в запросе Access-Request, но с неверной длиной, следует послать сообщение Access-Reject. Если атрибут прислан в пакете Access-Accept, Access-Reject или Access-Challenge и имеет некорректную длину, пакет должен рассматриваться как Access-Reject или молча отбрасываться.

    Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина. Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.

    строка

    0-253 октетов

    адрес

    32 битовый код, старший октет передается первым.

    целое

    32 битовый код, старший октет первый.

    время

    32 битовый код (старший октет первый) равен числу секунд с момента 00:00:00 GMT, 1-го января, 1970. Стандартные атрибуты не используют этот тип данных, но он представлен здесь, так как может быть применен в атрибутах зависящих от производителя (Vendor-Specific).

    5.1. Имя пользователя

    Этот атрибут указывает имя пользователя, который должен быть аутентифицирован. Он используется в пакетах Access-Request. Формат атрибута показан на рис. .3.


    Рис. .3. Формат атрибута

    Поле тип=1, длина ³ 3. Поле строка имеет один или более октетов. NAS может ограничить максимальную длину имени пользователя, но рекомендуется, чтобы программа была способна обрабатывать как минимум 63 октета. Применяется несколько форматов имени пользователя:

    монолитный

    Состоит только из буквенно-цифровых символов. Эта простая форма может использоваться для локального управления NAS.

    простой

    Состоит только из печатных символов ASCII.

    name@fqdn SMTP адрес

    Стандартное имя домена (Fully Qualified Domain Name; с или без завершающей точкой) указывает область, где применимо имя.

    уникальное имя

    Имя в формате ASN.1 используется в аутентификационных системах с общедоступным ключом.

    5.2. Пароль пользователя

    Этот атрибут указывает на пароль аутентифицируемого пользователя или на вводимые пользователем данные в ответ на Access-Challenge. Этот атрибут используется только в пакетах Access-Request.

    При передаче пароль шифруется. Пароль сначала дополняется нулями до границы кратной 16 октетам. Затем согласно алгоритму MD5 вычисляется хэш-функция. Это вычисление производится для потока октетов, состоящего из о бщего секретного пароля, за которым следует аутентификатор запроса (Request Authenticator). Для полученного кода и первых 16 октетов пароля производится операция XOR. Результат кладется в первых 16 октетов поля строка атрибута пароля пользователя.

    Если пароль длиннее 16 символов, вычисляется вторая хэш-функция для потока данных, включающего в себя общий секретный пароль и результат предыдущей операции XOR. Полученный результат и вторые 16 октетов пароля объединяются с помощью операции XOR, а полученный код кладется во вторые 16 октетов поля строка атрибута User-Password. Если необходимо, эта операция повторяется. Следует только иметь в виду, что поле строка не может превышать 128 символов.

    Данный метод заимствован из книги "Network Security" Кауфмана, Пелмана и Спесинера [4; стр. 109-110]. Более формализовано алгоритм можно описать следующим образом:

    Берется общий секретный ключ S и псевдослучайный 128-битный аутентификатор запроса RA. Пароль разбивается на 16-октетные блоки p1, p2, ., pi. последний из них дополняется нулями до размера кратного 16 октетам. Далее реализуется алгоритм MD5. Берутся блоки шифрованного текста c(1), c(2), ., c(i), получаются промежуточные значения b1, b2, . bi:

    b1 = MD5(S + RA)

    c(1) = p1 XOR b1

    b2 = MD5(S + c(1))

    c(2) = p2 XOR b2

    .

    .

    .

    .

    .

    .

    bi = MD5(S + c(I-1))

    c(i) = pi XOR bi

    Поле строка будет содержать c(1)+c(2)+...+c(i), где знак + означает присоединение.

    При получении осуществляется обратный процесс и получается исходная форма пароля. В результате формируется атрибут, где в поле тип записан код 2, в поле длина число в интервале 18-130, а в поле строка - 16-128 октетов зашифрованного пароля.

    5.3. Атрибут CHAP-пароль

    Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае - в поле аутентификатор запроса. Формат атрибута CHAP-Password показан на рис. .4.


    Рис. .4. Формат атрибута CHAP-Password

    Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя.

    5.4. Атрибут NAS-IP-Address

    Этот атрибут указывает IP-адрес сервера NAS, который запрашивает аутентификацию пользователя. Атрибут применяется только в пакетах Access-Request. В пакете Access-Request должен присутствовать NAS-IP-адрес или NAS-идентификатор. Формат атрибута NAS-IP-Address представлен на рис. .5.


    Рис. .5 Формат атрибута NAS-IP-Address

    Поле адрес имеет протяженность 4 октета (IPv4).

    5.5. Атрибут NAS-порт

    Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на рис. .6.


    Рис. .6. Формат атрибута NAS-порт

    Диапазон кодов в поле значение составляет 0 - 65535.

    5.6. Атрибут тип услуги (Service-Type)

    Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт. Только поле тип=6. Коды поля значение перечислены в таблице .2..

    Таблица .2. Коды поля значение

    Код поля значение

    Назначение

    1

    Login

    2

    Framed

    3

    Callback Login

    4

    Callback Framed

    5

    Outbound

    6

    Administrative

    7

    NAS Prompt

    8

    Authenticate Only

    9

    Callback NAS Prompt

    Таково назначение кодов атрибута типа услуг при использовании в сообщениях Access-Accept. Когда они применяются в пакетах Access-Request, они должны рассматриваться как подсказки серверу RADIUS и говорят, что NAS имеет причины полагать, что пользователь предпочтет указанные услуги, но сервер не обязан следовать этим подсказкам.

    Login

    Пользователь должен быть подключен к ЭВМ.

    Framed

    Для пользователя должен быть запущен пакетный протокол, такой как PPP или SLIP.

    Callback Login

    Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего осуществлено соединение с ЭВМ.

    Callback Framed

    Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего для пользователя запущен пакетный протокол типа PPP или SLIP.

    Outbound

    Пользователю предоставляется доступ к выходным устройствам.

    Administrative

    Пользователю предоставляется доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды.

    NAS Prompt

    Пользователю предоставляется возможность вводить непривилегированные команды NAS.

    Authenticate Only

    Запрашивается только аутентификация, ненужно возвращать никакой авторизационной информации Access-Accept (обычно используется прокси-серверами, а не самим NAS).

    Callback NAS Prompt

    Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего ему предоставляется возможность ввода непривилегированных команд NAS.

    5.7. Атрибут Framed-Protocol

    Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (рис. .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3.

    Таблица .3. Коды поля значение

    Код поля значение

    Назначение

    1

    PPP

    2

    SLIP

    3

    Протокол удаленного доступа AppleTalk (ARAP)

    4

    Gandalf владелец протокола SingleLink/MultiLink

    5

    Xylogics владелец IPX/SLIP

    5.8. Атрибут Framed-IP-Address

    Этот атрибут указывает на адрес, который следует сконфигурировать для пользователя. Атрибут может использоваться пакетами Access-Accept. Он может использоваться в пакетах Access-Request в качестве подсказки NAS, указывающей на то, что сервер предпочитает данный адрес. Сервер не обязан следовать этой подсказке. Формат атрибута идентичен представлению атрибута NAS-IP-адрес (рис. .5).

    Поле тип = 8, поле длина = 6.

    Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя.

    5.9. Атрибут Framed-IP-Netmask

    Этот атрибут указывает на сетевую IP-маску, которая должна быть сконфигурирована для пользователя, когда он является маршрутизатором сети. Атрибут может использоваться в пакетах Access-Accept. Он может использоваться в пакете Access-Request в качестве подсказки NAS серверу относительно того, какую сетевую маску он предпочитает. Но сервер не обязан следовать этой подсказке. Формат записи атрибута аналогичен формату атрибута NAS-IP-адрес. Поле тип = 9, поле длина = 6. Поле адрес имеет 4 октета и определяет сетевую IP-маску.

    5.10. Атрибут Framed-Routing

    Этот атрибут указывает метод маршрутизация для пользователя, когда пользователем является маршрутизатор сети. Атрибут может использоваться в пакетах Access-Accept. Формат записи атрибута аналогичен показанному на рис. .6 (NAS-порт). Поле тип = 10, поле длина = 10. Допустимые коды и их назначения собраны в таблице .4

    Таблица .4. Допустимые коды поля значение и их назначения

    Код поля значение

    Назначение

    0

    Ничего не делать

    1

    Посылать маршрутные пакеты

    2

    Принимать маршрутные пакеты

    3

    Посылать и принимать

    5.11. Атрибут Filter-Id

    Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует рис. .3. поле тип = 11, поле длина ³ 3.

    Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов.

    5.12. Атрибут Framed-MTU

    Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535.

    5.13. Атрибут Framed-Compression

    Этот атрибут указывает на протокол сжатия, который следует использовать при передаче данных. Атрибут используется в пакетах Access-Accept. Атрибут используется в пакетах Access-Request в качестве подсказки серверу о том, какой вид компрессии предпочитает использовать NAS, но сервер не обязан следовать этой рекомендации.

    Можно использоваться несколько атрибутов данного типа. Окончательное решение о применении того или иного метода компрессии принимает сервер NAS.

    Формат атрибута аналогичен показанному на рис. 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5.

    Таблица .5. Возможные коды поля значение

    Код поля значение

    Назначение

    0

    Никакого

    1

    Сжатие заголовка VJ TCP/IP [5]

    2

    Сжатие заголовка IPX

    5.14. Атрибут Login-IP-Host

    Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на рис. .5. Поле тип = 14, а поле длина = 6.

    Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя.

    5.15. Атрибут Login-Service

    Этот атрибут указывает на услугу, которая будет использоваться для соединения пользователя с ЭВМ. Атрибут применяются только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 15, а поле длина = 6. Возможные коды поля значение собраны в таблице .6.

    Таблица .6. Возможные коды поля значение

    Код поля значение

    Назначение

    0

    Telnet

    1

    Rlogin

    2

    Сброс TCP

    3

    PortMaster (собственник)

    4

    LAT

    5.16. Атрибут Login-TCP-Port

    Этот атрибут указывает порт TCP, с которым следует соединить пользователя при наличии атрибута Login-Service. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 16, а поле длина = 6. Поле значение имеет четыре октета и может содержать величины в диапазоне 0 - 65535.

    5.17. Атрибут типа 17 в настоящее время не определен.

    5.18. Атрибут Reply-Message

    Этот атрибут содержит текст, который может быть отображен для пользователя. Если используется в пакете Access-Accept, это сообщение об успешном выполнении. При использовании с Access-Reject, это уведомление о неудаче. Это может быть элемент диалога с пользователем перед очередной попыткой послать запрос доступа (Access-Request).

    Когда атрибут используется в Access-Challenge, он может содержать приглашение пользователю ввести отклик. Допускается применение нескольких атрибутов Reply-Message, в этом случае они должны отображаться в порядке из записи в пакете. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 18, а поле длина ³ 3.

    Поле строка содержит один или более октетов. Его содержимое может зависеть от конкретной программной реализации. Содержимое должно быть читабельным и не должно влиять на работу протокола. Рекомендуется, чтобы текст состоял из печатных ASCII символов с кодами 10, 13 и 32 - 126.

    5.19. Атрибут Callback-Number

    Этот атрибут представляет собой телефонный номер, используемый для обратного дозвона. Атрибут может использоваться в пакетах Access-Accept, а также в Access-Request в качестве подсказки серверу о том, что желателен обратный дозвон, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 19, а поле длина ³ 3.

    Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.20. Атрибут Callback-Id

    Этот атрибут содержит имя места вызова, которое должно быть интерпретировано сервером NAS. Атрибут может использоваться пакетами Access-Accept. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 20, а поле длина ³ 3.

    Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.21. Атрибут типа 21 в настоящее время не определен

    5.22. Атрибут Framed-Route

    Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 22, а поле длина ³ 3.

    Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 - 126.

    Для IP-маршрутов, атрибут должен содержать префикс места назначения в десятично-точечном представлении (как IP-адрес). Далее опционно может следовать косая черта и число старших бинарных единиц, указывающее на количество разрядов префикса, которые следует использовать. Далее следует пробел, адрес шлюза, еще один пробел и один или более кодов метрики, разделенных пробелами. Например, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". Длина спецификатора может быть опущена, тогда для префикса класса А подразумевается длина в 8 бит, для класса В - 16 и для класса С - 24 бита. Например, "192.168.1.0 192.168.1.1 1". Если адрес шлюза равен "0.0.0.0", тогда в качестве IP-адреса шлюза следует использовать адрес пользователя.

    5.23. Атрибут Framed-IPX-Network

    Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя. Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 23, а поле длина = 6.

    Поле значение имеет 4 октета. Значение 0xFFFFFFFE указывает, что сервер NAS должен выбрать для пользователя сеть IPX (т.е. выбрать одну или более IPX-сетей из имеющегося списка). Остальные значения должны рассматриваться как IPX-сети, предназначенные для подключения.

    5.24. Атрибут State

    Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Challenge и должен быть передан немодифицированным от клиента к серверу в новом отклике Access-Request на исходный вызов, если таковой имеется.

    Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 24, а поле длина ³ 3.

    Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.25. Атрибут Class

    Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 25, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.26. Атрибут Vendor-Specific

    Этот атрибут служит для того, чтобы позволить производителям обеспечить поддержку их собственных атрибутов, непригодных для общего применения. Атрибут не должен влиять на работу протокола RADIUS.

    Серверы, не приспособленные для интерпретации информации, специфической для производителя оборудования или программ, должны игнорировать эти атрибуты (хотя могут и оповещать об этом). Клиенты, которые не получили желательной информации, специфической для изготовителя, должны предпринять попытку работать без этих данных. При этом функциональность может быть сужена (о чем клиент может сообщить пользователю). Формат записи атрибута показан на рис. .7. Поле тип = 26, а поле длина ³ 7.


    Рис. .7. Формат записи атрибута Vendor-Specific

    Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой.

    Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Строка должна кодироваться в виде последовательности тип производителя / длина / поля значений, специфические для производителя. Пример формата строки показан на рис. .8.


    Рис. .8. Пример формата строки

    Поле строка предназначено для записи параметров, специфических для данного производителя.

    5.27. Атрибут Session-Timeout

    Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 27, а поле длина = 6.

    Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS).

    5.28. Атрибут Idle-Timeout

    Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 28, а поле длина = 6.

    Поле значение содержит 4 октета и несет в себе 32-битовое целое число без знака, соответствующее максимальному времени пассивности клиента в секундах. По истечении этого времени соединение с сервером разрывается.

    5.29. Атрибут Termination-Action

    Этот атрибут указывает, какие действия должен выполнить сервер NAS, когда процедура будет завершена. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 29, а поле длина = 6. Поле значение имеет 4 октета. Ниже приведены разрешенные коды поля значения.

    0

    Значение по умолчанию

    1

    RADIUS-Request

    Если поле значение соответствует RADIUS-Request, по завершении соответствующего сервиса NAS может послать новый запрос Access-Request серверу RADIUS, включив атрибут State, если он имеется.

    5.30. Атрибут Called-Station-Id

    Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь. При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 30, поле длина ³ 3.

    Поле строка содержит один или более октетов, содержащих телефонный номер, через который пользователь дозвонился до системы. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.31. Атрибут Calling-Station-Id

    Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI - Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 31, поле длина ³ 3.

    Поле строка содержит один или более октетов, где записан номер телефона, с которого позвонил пользователь. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Рекомендуется использование печатных ASCII-символов.

    5.32. Атрибут NAS-идентификатор

    Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 32, а поле длина ³ 3.

    Поле строка содержит один или более октетов, и должна быть уникальной для NAS в области действия сервера RADIUS. Например, полное имя домена вполне подходит в качестве NAS-идентификатора. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.33. Атрибут Proxy-State

    Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge. Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 33, а поле длина ³ 3.

    Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

    5.34. Атрибут Login-LAT-Service

    Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации.

    Администраторы используют атрибут сервиса, когда имеют дело с кластерными системами, такими как VAX или Alpha-кластер. В такой среде несколько процессоров совместно используют общие ресурсы (диски, принтеры и т.д.), и администраторы конфигурируют каждый из них для обеспечения к каждому из ресурсов. В этом случае каждая ЭВМ в кластере оповещает о предоставляемых услугах через широковещательные сообщения LAT.

    Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 34, а поле длина ³ 3.

    Поле строка имеет один или более октетов и содержит идентификатор LAT-сервиса. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, буквы верхнего и нижнего регистров, а также расширенный символьный набор ISO Latin-1 [6]. Все сравнения в LAT не зависят от регистра символов.

    5.35. Атрибут Login-LAT-Node

    Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 35, а поле длина ³ 3.

    Поле строка имеет один или более октетов и содержит идентификатор узла LAT, с которым следует соединиться пользователю. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), числа, буквы нижнего и верхнего регистров, а также расширяющий символьный набор ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

    5.36. Атрибут Login-LAT-Group

    Этот атрибут содержит строку, идентифицирующую групповой код LAT, который данный пользователь авторизован использовать. Атрибут может использоваться в пакетах Access-Accept, но только когда специфицирован LAT в качестве Login-Service. Он может быть использован в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. LAT поддерживает 256 различных групповых кодов, которые LAT использует как некую форму прав доступа. LAT преобразует эти групповые коды в 256 битовую карту соответствия (bitmap).

    Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту. Старший октет передается первым.

    5.37. Атрибут Framed-AppleTalk-Link

    Этот атрибут содержит сетевой номер AppleTalk, который должен быть использован для последовательного канала пользователя, являющимся маршрутизатором сети AppleTalk. Атрибут применяется только в пакетах Access-Accept. Он никогда не используется, когда пользователь не является маршрутизатором. Формат записи атрибута показан на рис. .6. Поле тип = 37, а поле длина =6.

    Поле значение имеет 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk.

    5.38. Атрибут Framed-AppleTalk-Network

    Этот атрибут представляет собой сетевой номер AppleTalk, который сервер NAS должен попытаться присвоить узлу AppleTalk. Атрибут используется только в пакетах Access-Accept. Атрибут никогда не используется, если пользователем является маршрутизатор. Многократное использование атрибута в пакете указывает на то, что NAS может попытаться использовать один из сетевых номеров, приведенных в атрибутах. Формат записи атрибута показан на рис. .6. Поле тип = 38, а поле длина =6.

    Поле значение содержит 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что NAS должен назначить сеть для пользователя. Значения в интервале 1 - 65535 (включительно) указывает на сеть AppleTalk, адрес которой должен найти сервер NAS для пользователя.

    5.39. Атрибут Framed-AppleTalk-Zone

    Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на рис. .3. Поле тип = 39, а поле длина ³ 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя.

    5.40. Атрибут CHAP-Challenge

    Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на рис. .3. Поле тип = 60, а поле длина ³ 7. Поле строка содержит сообщение CHAP Challenge.

    5.41. Атрибут NAS-Port-Type

    Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на рис. .6. Поле тип = 61, а поле длина =6.

    Поле значение имеет 4 октета. "Виртуальный" (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом.

    Таблица .7. Код поля значение атрибута NAS-Port-Type

    Код поля значение

    Назначение

    0

    Async

    1

    Sync

    2

    ISDN Sync

    3

    ISDN Async V.120

    4

    ISDN Async V.110

    5

    Виртуальный

    5.42. Атрибут Port-Limit

    Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на рис. .6. Поле тип = 62, а поле длина = 6.

    Поле значение имеет 4 октета и содержит 32-битовое целое число без знака, которое определяет максимальное число портов, к которым пользователь может быть подключен сервером NAS.

    5.43. Атрибут Login-LAT-Port

    Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на рис. .3. Поле тип = 63, а поле длина ³ 3.

    Поле строка имеет один или более октетов и содержит идентификатор порта LAT, который следует использовать. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), цифры, буквы верхнего и нижнего регистра, а также расширенный набор символов ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

    5.44. Таблица атрибутов

    В таблице собраны основные характеристики атрибутов, типы пакетов, где они используются, а также возможное число атрибутов в пакете.

    Таблица .8. Основные характеристики атрибутов

    Request

    Accept

    Reject

    Challenge

    #

    Атрибут

    1

    0

    0

    0

    1

    User-Name

    0-1

    0

    0

    0

    2

    User-Password [*]

    0-1

    0

    0

    0

    3

    CHAP-Password [*]

    0-1

    0

    0

    0

    4

    NAS-IP-Address

    01

    0

    0

    5

    NASPort

    0-1

    0-1

    0

    0

    6

    Service-Type

    0-1

    0-1

    0

    0

    7

    Framed-Protocol

    0-1

    0-1

    0

    0

    8

    Framed-IP-Address

    0-1

    0-1

    0

    0

    9

    Framed-IP-Netmask

    0

    0-1

    0

    0

    10

    Framed-Routing

    0

    0+

    0

    0

    11

    Filter-Id

    0

    0-1

    0

    0

    12

    Framed-MTU

    0+

    0+

    0

    0

    13

    Framed-Compression

    0+

    0+

    0

    0

    14

    Login-IP-Host

    0

    0-1

    0

    0

    15

    Login-Service

    0

    0-1

    0

    0

    16

    Login-TCP-Port

    0

    0+

    0+

    0+

    18

    Reply-Message

    0-1

    0-1

    0

    0

    19

    Callback-Number

    0

    0-1

    0

    0

    20

    Callback-Id

    0

    0+

    0

    0

    22

    Framed-Route

    0

    0-1

    0

    0

    23

    Framed-IPX-Network

    0-1

    0-1

    0

    0-1

    24

    State

    0

    0+

    0

    0

    25

    Class

    0+

    0+

    0

    0+

    26

    Vendor-Specific

    0

    0-1

    0

    0-1

    27

    Session-Timeout

    0

    0-1

    0

    0-1

    28

    Idle-Timeout

    0

    0-1

    0

    0

    29

    Termination-Action

    0-1

    0

    0

    0

    30

    Called-Station-Id

    0-1

    0

    0

    0

    31

    Calling-Station-Id

    0-1

    0

    0

    0

    32

    NAS-Identifier

    0+

    0+

    0+

    0+

    33

    Proxy-State

    0-1

    0-1

    0

    0

    34

    Login-LAT-Service

    0-1

    0-1

    0

    0

    35

    Login-LAT-Node

    0-1

    0-1

    0

    0

    36

    Login-LAT-Group

    0

    0-1

    0

    0

    37

    Framed-AppleTalk-Link

    0

    0+

    0

    0

    38

    Framed-AppleTalk-Network

    0

    0-1

    0

    0

    39

    Framed-AppleTalk-Zone

    0-1

    0

    0

    0

    60

    CHAP-Challenge

    0-1

    0

    0

    0

    61

    NAS-Port-Type

    0-1

    0-1

    0

    0

    62

    Port-Limit

    0-1

    0-1

    0

    0

    63

    Login-LAT-Port

    [*] Запрос Access-Request должен содержать пароль пользователя или CHAP-пароль, но не должен содержать и то и другое.

    Ниже в таблице представлены обозначения, использованные в таблице 8.

    0

    Этого атрибута не должно быть в пакете.

    0+

    Атрибут может использоваться в пакете нуль или более раз.

    0-1

    Атрибут может использоваться в пакете нуль или один раз.

    1

    Атрибут должен присутствовать в пакете обязательно один раз.

    6. Примеры

    Предлагается несколько примеров для иллюстрации потока пакетов и использования типовых атрибутов.

    6.1. Удаленный доступ пользователя на указанную ЭВМ (Telnet)

    Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3.

    Code = 1 (Access-Request)
    ID = 0
    Request Authenticator = {16-октетное случайное число}
    Атрибуты:
    User-Name = "NEMO"

    User-Password = {16-октетный пароль, дополненный в конце нулями и объединенный операцией XOR с MD5(общий секретный пароль|Request Authenticator)}

    NAS-IP-Address = 192.168.1.16
    NAS-Port = 3

    Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом.

    Code = 2 (Access-Accept)
    ID = 0 (то же самое, что и в Access-Request)
    Response Authenticator = {16-октетная контрольная сумма MD-5 кода (2),

    id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля }

    Атрибуты:
    Service-Type = Login-User
    Login-Service = Telnet
    Login-Host = 192.168.1.3

    6.2. Кадровая аутентификация пользователя посредством CHAP

    Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP-пакете серверу RADIUS для пользователя с именем VANYA для подключения к порту 20 в рамках протокола PPP. Аутентификация осуществляется посредством CHAP. NAS посылает атрибуты Service-Type и Framed-Protocol в качестве рекомендаций серверу RADIUS воспользоваться PPP, хотя NAS необязательно этому последует.

    Code = 1 (Access-Request)
    ID = 1

    Request Authenticator = {16-октетное случайное число, используется также в вызове CHAP (CHAP challenge)}

    Атрибуты:
    User-Name = " VANYA"

    CHAP-Password = {1 октет идентификатора CHAP, за которым следует 16 октетов CHAP-отклика}

    NAS-IP-Address = 192.168.1.16
    NAS-Port = 20
    Service-Type = Framed-User
    Framed-Protocol = PPP

    Сервер RADIUS аутентифицирует VANYA и посылает запрос Access-Accept в UDP-пакете серверу NAS, сообщая, что он отрывает PPP-сессию и приписывает адрес пользователю из имеющегося у него списка.

    Code = 2 (Access-Accept)
    ID = 1 (тот же, что и в Access-Request)
    Response Authenticator = {16-октетов контрольной суммы MD-5 кода (2), ID (1), Request Authenticator, приведенного выше, атрибутов этого отклика и общего секретного пароля}

    Атрибуты:
    Service-Type = Framed-User
    Framed-Protocol = PPP
    Framed-IP-Address = 255.255.255.254
    Framed-Routing = None
    Framed-Compression = 1 (Компрессия заголовка VJ TCP/IP)
    Framed-MTU = 1500

    6.3. Пользователь с картой вызова-отклика (Challenge-Response)

    Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request серверу RADIUS для пользователя с именем MANYA, подключаемого к порту 7.

    Code = 1

    (Access-Request)

    ID = 2
    Request Authenticator = {16 октетов случайного числа }

    Атрибуты:
    >User-Name = " MANYA"
    User-Password = {16 октетов пароля дополненные в конце нулями,
    объединенный функцией XOR с MD5 (общий секретный ключ |Request Authenticator)}
    NAS-IP-Address = 192.168.1.16
    NAS-Port = 7

    Сервер RADIUS решает вызвать MANYA, отсылая назад строку вызова и ожидая отклика. Сервер RADIUS посылает запрос Access-Challenge серверу NAS.

    Code = 11

    (Access-Challenge}

    ID = 2

    (тот же что и в Access-Request)

    Response Authenticator = {16-октетов контрольной суммы MD-5 кода (11), ID (2), Request Authenticator, представленный выше, атрибуты данного отклика и общий секретный пароль}

    Атрибуты:
    Reply-Message = "Challenge 32769430. Enter response at prompt."
    State = {Код, который должен быть прислан вместе с откликом пользователя }

    Пользователь вводит свой отклик, а NAS посылает новый запрос Access-Request с этим откликом и атрибутом State.

    Code = 1

    (Access-Request)

    ID = 3

    (Заметьте, что он изменяется)

    Request Authenticator = {Новое 16-октетное число}

    Атрибуты:

    User-Name = " MANYA"

    User-Password = {16 октетов отклика дополненного в конце нулями и объединенного функцией XOR с контрольной суммой MD5 общего секретного пароля и представленного выше аутентификатора запроса (Request Authenticator)}

    NAS-IP-Address = 192.168.1.16

    NAS-Port = 7

    State =

    {Код из пакета Access-Challenge}

    Отклик был некорректен, поэтому сервер RADIUS предлагает NAS отклонить попытку входа в систему.

    Code = 3

    (Access-Reject)

    ID = 3

    (то же что и в Access-Request)

    Response Authenticator = {16-октетов контрольной суммы MD-5 кода (3), ID (3), описанного выше Request Authenticator, атрибутов этого отклика (если таковые имеются) и общего секретного пароля}

    Атрибуты:

    (отсутствуют, хотя сообщение Reply-Message может быть послано)

    На практике, с сервером RADIUS связывается база данных, где хранятся имена пользователей и соответствующие им секретные пароли. Конкретный именованный пользователь должен аутентифицироваться только одним способом. Это уменьшает возможности атаки путем согласования использования наименее безопасного метода аутентификации. Если пользователь нуждается в использовании разных аутентификационных методов в различных ситуациях, тогда следует данному пользователю в каждом из этих вариантов выступать под разными именами.

    Пароли должны храниться в местах с ограниченным доступом. Эти данные должны быть доступны только процессам, которые с ними работают.

    Ссылки

    [1]

    Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992.

    [2]

    Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.

    [3]

    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

    [4]

    Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.

    [5]

    Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.

    [6]

    ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.

    [7]

    Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP Multilink Protocol (MP)", RFC 1717, University of California Berkeley, Lloyd Internetworking, Newbridge Networks Corporation, November 1994.

    [8]

    Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes LAN Systems, Inc., MIT Laboratory for Computer Science, July 1992.

    [9]

    Rigney, C., "RADIUS Accounting", RFC 2139, January 1997.

    [10]

    B. Aboba, G. Zorn, RADIUS Authentication Client MIB. RFC-2618, June 1999.

    [11]

    G. Zorn, B. Aboba, RADIUS Authentication Server MIB. RFC-2619, June 1999.

    [12]

    B. Aboba, G. Zorn, RADIUS Accounting Client MIB. RFC-2620, June 1999.

    [13]

    G. Zorn, B. Aboba, RADIUS Accounting Server MIB. RFC-2621, June 1999.

    Previous: 4.5.3 Удаленный доступ (Telnet)    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.4 Протокол пересылки файлов FTP


    previous up down next index index
    Previous: 4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.4.1 Протокол TFTP

    4.5.4 Протокол пересылки файлов FTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    FTP (RFC-959) обеспечивает файловый обмен между удаленными пользователями. Протокол FTP формировался многие годы. Первые реализации в МТИ относятся к 1971. (RFC 114 и 141). RFC 172 рассматривает протокол, ориентированный на пользователя, и предназначенный для передачи файлов между ЭВМ. Позднее в документах RFC 265 и RFC 281 протокол был усовершенствован. Заметной переделке протокол подвергся в 1973, и окончательный вид он обрел в 1985 году. Таким образом, данный протокол является одним из старейших.

    Для реализации обмена между двумя персональными ЭВМ в пределах сети (программные пакеты PCTCP, и т.д.) можно резидентно загрузить FTPSRV или другую эквивалентную программу. Также как и в случае TELNET необходима идентификация, но многие депозитарии допускают анонимный вход (имя пользователя ANONYMOUS, RFC-1635), который не требует слова пропуска (пароля) или допускает ввод вашего почтового адреса вместо него.

    Работа FTP на пользовательском уровне содержит несколько этапов:

    1.

    Идентификация (ввод имени-идентификатора и пароля).

    2.

    Выбор каталога.

    3.

    Определение режима обмена (поблочный, поточный, ascii или двоичный).

    4.

    Выполнение команд обмена (get, mget, dir, mdel, mput или put).

    5.

    Завершение процедуры (quit или close).

    FTP довольно необычная процедура, так как поддерживает две логические связи между ЭВМ (Рис 4.5.4.1). Одна связь служит для удаленного доступа и использует протокол Telnet. Другая связь предназначена для обмена данными. Сервер производит операцию passive open для порта 21 и ждет соединения с клиентом. Клиент осуществляет операцию active open для порта 21. Канал остается активным до завершения процедуры FTP. TOS (тип IP-сервиса) соответствует минимуму задержки, так как этот канал используется для ручного ввода команд. Канал для передачи данных (TCP) формируется каждый раз для пересылки файлов. Канал открывается перед началом пересылки и закрывается по коду end_of_file (конец файла). IP-тип сервиса (TOS) в этом случае ориентирован на максимальную пропускную способность.

    Конечный пользователь взаимодействует с протокольным интерпретатором, в задачи которого входит управление обменом информацией между пользователем и файловой системой, как местной, так и удаленной. Схема взаимодействия различных частей Internet при работе FTP изображена на рис. 4.5.4.1.

    Сначала по запросу клиента формируется канал управления, который в дальнейшем используется для передачи команд от клиента и откликов от сервера. Информационный канал формируется сервером по команде клиента, он не должен существовать постоянно на протяжении всей FTP-сессии и может формироваться и ликвидироваться по мере необходимости. Канал управления может быть закрыт только после завершения информационного обмена. Для канала управления используется протокол Telnet. После того как управляющий канал сформирован, клиент может посылать по нему команды. Сервер воспринимает, интерпретирует эти команды и передает отклики.

    Рис. 4.5.4.1 Схема работы протокола ftp.

    Возможна и другая схема взаимодействия, когда по инициативе клиента осуществляется файловый обмен между двумя ЭВМ, ни одна из которых не является машиной клиента (см. рис. 4.5.4.2).

    Рис. 4.5.4.2. Организация информационного обмена между двумя удаленными машинами

    На фазе задания режима обмена предоставляются следующие возможности:

    Команда Block сохраняет структуру логических записей файла.

    Команда Stream устанавливает режим, при котором не производится пересылки контрольной информации для блоков. Это наиболее быстрый режим обмена, он работает по умолчанию.

    Команда TYPE может задать режимы обмена IMAGE, ASCII или EBCDIC. Из них ASCII - используется по умолчанию. Режим EBCDIC применяется для обменов между ЭВМ, работающими с набором символов EBCDIC. Режим IMAGE предполагает обмен 8-битными байтами, используется для передачи двоичной (а не текстовой) информации. Более подробный список команд помещен ниже. Структурно информация может передаваться в виде файлов (структура по умолчанию), в виде последовательности записей (применимо для текстовых файлов ASCII или EBCDIC) или постранично (последняя структура не относится к числу рекомендуемых).

    Для копирования файла из удаленного сервера используется команда GET, для копирования группы файлов - MGET, в последнем случае применяются символы заменители, например, MGET *.txt (или RFC-18*.txt, при этом скопируются файлы с RFC-1800.txt до RFC-1899.txt, если таковые существуют в текущем каталоге). Аналогом команды GET в какой-то степени является команда DIR (ls), только она переносит содержимое каталога, что для некоторых операционных систем эквивалентно. При использовании модификации mget проявляйте осторожность - вы можете заблокировать телекоммуникационный канал длительным копированием. Для записи файла в удаленный сервер применяется команда PUT. При операциях обмена обычно используется текущий каталог локальной ЭВМ. В вашем распоряжении всегда имеется возможность поменять местный каталог с помощью команды LCD или ее аналога. Любая команда обмена выполняется в несколько этапов:

    1. Формирование канала под управлением клиента, так как именно клиент выдал команду get, dir, put и т.д.
    2. Клиент выбирает произвольный номер порта на своей ЭВМ и осуществляет процедуру passive open для этого порта.
    3. Клиент посылает номер порта серверу по каналу управления (порт 21), используя команду PORT. Можно обойтись и без команды PORT (используется тот же порт, что и в командном канале), но это увеличивает задержки и по этой причине не рекомендуется.
    4. Сервер получает номер порта по каналу управления и выдает команду active open в указанный порт ЭВМ-клиента. Сервер для канала данных всегда использует порт с номером 20.

    Рассмотрим пример FTP-сессии. Для этого выдадим команду (тексты, набираемые с клавиатуры, выделены курсивом):

    FTP -d ns.itep.ru

    (флаг -d означает установку отладочного режима, при котором выдаются все сообщения и внутренние команды на экран терминала).

    FTP Trying...Open
    220- *** Welcome at FTP-Server ftp.ITEP.RU ***
    220-
    220 ns.itep.ru FTP server ready.
    Userid for logging in on ns.itep.ru (SEMENOV)? semenov

    FTP command: USER semenov
    FTP response: 331 Password required for semenov.
    331 Password required for semenov.
    Password for logging in as semenov on ns.itep.ru? XXXXXXXX

    PASS XXXXXXXX

    (ввод пароля не отображается на экране)

    FTP response: 230 User semenov logged in.
    230 User semenov logged in.

    ftp:ns.itep.ru> hel

    (просьба выдать список доступных на данном сервере FTP-команд)

    Any unambiguous abbreviation for a command may be used.

    Available commands are:

    !

    ?

    acct

    append

    ascii

    binary

    bye

    cd

    debug

    delete

    dir

    drive

    exit

    fcd

    fdir

    fpwd

    get

    help

    iget

    image

    iput

    lcd

    ldir

    lmkdir

    local

    login

    lpwd

    ls

    mdelete

    mget

    mkdir

    mput

    option

    parent

    passive

    put

    pwd

    quit

    quote

    rename

    retrieve

    rmdir

    send

    server

    show

    stat

    store

    take

    tenex

    tget

    tput

    type

    user

    verbose

    version

    ftp:ns.itep.ru> quit
    FTP command: QUIT
    FTP response: 221 Goodbye.

    Уход из FTP производится по команде quit. В приведенном примере файловый обмен не производился, но и команда HELP требует переноса информации (также как и dir), так как вам выдается список команд, доступных на удаленном сервере. Из воспроизведенного списка команд, самая опасная mdelete, так как способна стереть целый каталог. Нетекстовые файлы (архивированные, графические и программные) следует пересылать в режиме binary. Для перевода в этот режим используется одноименная команда. Для перехода из одного каталога в другой на удаленном сервере служит команда cd имя_каталога, а для возврата в предшествующий cd .. . Например, cd /pub/msdos.

    Ссылка на объект, доступный через анонимное FTP, обычно записывается в виде:

    Название ресурса

    Имя сервера

    Имя каталога в сервере.

    Например:

    Internet-cmc

    ftp.rpi.edu

    /pub/communications/internet-cmc.txt

    ftp://ftp.rpi.edu/pub/communications/internet-cmc.txt

    Internet-cmc (CMC - computer-mediated communication) -это межкомпьютерный обмен по сети Internet.

    Ниже приведен список базовых команд FTP. Следует разделять внутренний набор команд FTP, которыми обмениваются клиент и сервер по командному каналу, и набор команд доступный пользователю. Служебные команды содержат три или четыре заглавные буквы. Эти наборы команд перекрываются лишь частично. Служебные команды унифицированы (они выделены в приведенном выше примере FTP-сессии жирным шрифтом, в помещенной ниже таблице эти команды представлены в ее верхней части), пользовательский же набор команд может варьироваться от реализации к реализации. Если выдать команду FTP без аргументов, система обычно откликается приглашением FTP> и вы можете выполнить некоторые из приведенных ниже команд (весь набор становится доступным только после идентификации).

    Таблица 4.5.4.1

    Субкоманды FTP

    Описание

    ABOR

    Прерывание исполнения предыдущей FTP-команды и связанного с ней обмена

    ACCT<SP> <account-information>

    Ввод идентификатора пользователя (ID);

    ALLO <SP> <десятичное целое> [<SP> R <SP> <десятичное целое>]

    Зарезервировать достаточно места (в байтах) для пересылки файла. Для файлов с постраничной структурой после символа R указывается число записей

    APPE <SP> <проход>

    Присовокупить передаваемые данные к файлу, указанному в параметре проход

    CDUP

    Переход в каталог прародитель

    CWD <SP> <проход>

    Изменить рабочий каталог (CD);

    DELE <SP> <проход>

    Стереть файл (del);

    HELP

    Выдать справочную информацию о выполнимых командах

    HELP [<SP> <строка>]

    Выдать описание работы данной команды

    LIST [<SP> <проход>]

    Вывод списка файлов или каталогов (dir);

    MKD <SP> <проход>

    Создать каталог

    MODE <SP> <код режима>

    Режим обмена = поток, блоки или со сжатием

    NLST [<SP> <проход>]

    Переслать оглавление каталога от сервера к клиенту

    NOOP

    Пустая команда

    PASS <SP> <пароль>

    Слово-пропуск (пароль) пользователя, заполняется пользователем

    PASV

    Перевести сервер в режим прослушивания информационного порта на предмет установления соединения

    PORT <SP> <порт ЭВМ>

    IP-адрес и номер порта клиента

    PWD

    Выдать имя текущего каталога

    QUIT

    Уход из FTP

    REIN

    Завершение сессии и открытие новой

    REST <SP> <маркер>

    Возобновление обмена, начиная с места, указанного маркером

    RETR <SP> <проход>

    Переслать копию файла (get) другому адресату

    RMD <SP> <проход>

    Удалить каталог

    RNFR <SP> <проход>

    Начало процедуры переименования файла (Rename From)

    RNTO <SP> <проход>

    Указание нового имени файла при переименовании (Rename To)_

    SITE <SP> <строка>

    Используется сервером для реализации локально специфических команд

    SMNT <SP> <проход>

    Позволяет пользователю смонтировать нужную файловую систему

    STAT

    Выдать текущие значения параметров (STATUS)

    STOR <SP> <проход>

    Сервер должен запомнить полученные данные в виде файла

    STOU

    Аналог команды STOR но записывает файл в текущий каталог и присваивает файлу уникальное имя

    STRU <SP> <код структуры>

    Структура файла = файл, запись или страница

    SYST

    Сервер сообщает тип системы

    TYPE <SP> <код типа>

    Специфицирует тип информации, часто для этой цели используются команды binary и ASCII

    USER <SP> < [имя [пропуск]] >

    Идентифицирует пользователя, запрашивается сервером

    ?

    тоже что и HELP;

    lcd

    Изменить локальный каталог (на вашей ЭВМ);

    !

    Выйти временно из FTP и уйти в Shell (UNIX)

    ! команда

    Исполнить команду Shell (UNIX)

    close

    Прервать связь с удаленным сервером, оставаясь в FTP

    open [имя_ЭВМ]

    Установить связь с указанным удаленным сервером

    dir

    Выдать содержимое удаленного каталога

    <SP> пробел; все команды завершаются последовательностью <CRLF> возврат каретки + перевод строки. В квадратных скобках записан опционный аргумент. Выполнение любой команды можно прервать с помощью Ctrl-C.

    Возможная форма обращения к FTP (SunOS 4.1): FTP [ -опции ] [ имя_ЭВМ ]

    Допустимы следующие опции (модификаторы) команды:

    -d

    включение отладочного режима.

    -g

    блокировка группового исполнения команд.

    -i

    Выключение интерактивного приглашения при множественной пересылке файлов.

    -v

    Отображает все отклики удаленного сервера и статистику обмена; этот режим работает обычно по умолчанию.

    В рамках процедуры FTP доступны следующие команды (приведенный перечень команд является неполным):

    ! [ команда ]

    Исполняется команда интерпретатора shell вашей ЭВМ (UNIX). Если имя команды явно не введено, система переходит в интерактивный режим shell.

    $ имя-макро [ аргументы ]

    Выполняется макро, имя которого введено, аргументы используются этим макро.

    account [ пароль ]

    Позволяет ввести пароль, необходимый для доступа в удаленный сервер.

    append имя_местного_файла
    [ имя_удаленного_файла ]

    Добавить местный файл к файлу на удаленном сервере.

    Bye

    Завершает FTP-сессию.

    case

    Переключает регистр символов, которыми записаны имена файлов на удаленной ЭВМ, в процессе выполнения команды MGET. Если case включен (по умолчанию выключен), все прописные буквы в именах файлов на удаленной ЭВМ, меняются при переносе в вашу ЭВМ на строчные.

    close

    Завершает FTP-сессию и возвращает систему в интерактивный командный режим. Все описанные ранее макро стираются.

    debug [ debug-value ]

    Включает/выключает режим отладки. Значение debug-value определяет отладочный уровень. Если отладка включена, FTP отображает на экране каждую команду, посылаемую удаленной ЭВМ. Эта информация помечается символом '-->'.

    dir [ удаленный каталог ]
    [ местный файл ]

    Выдает на экран содержимое удаленного каталога. Если в качестве параметра указано имя местного файла, результат заносится в него. Если имя удаленного каталога не указано, команда выполняется для текущего каталога.

    disconnect

    синоним close.

    hash

    включает/выключает знак (#). Во включенном состоянии отмечается пересылка каждого блока, что позволяет визуально контролировать процесс обмена.

    macdef macro-name

    Определяет макро. Последующие строки запоминаются в качестве текста макро с именем macro-name. Нулевая строка (двойное нажатие клавиши RETURN) завершает ввод текста макро. Можно ввести до 16 макро с суммарным объемом до 4096 символов.

    mdelete [ имена_файлов_на удаленной_ЭВМ ]

    удаляет файлы на удаленной ЭВМ.

    open имя-ЭВМ [ port ]

    устанавливает связь с указанным FTP-сервером (ЭВМ) через специфицированный порт.

    prompt

    включает/выключает нтерактивные запросы со стороны ЭВМ. Это бывает полезным при выполнении групповых команд MPUT, MGET или MDELETE и позволяет проводить соответствующие операции над файлами выборочно.

    proxy

    ftp-команда выполняет FTP-команду на вторичной удаленной ЭВМ. Эта команда позволяет связать два удаленных FTP-сервера и осуществить пересылку файлов между ними. Первой proxy-командой должна быть команда open, необходимая для связи со вторичным сервером. Введите команду proxy ?, чтобы проверить выполнимость этих команд на данном сервере.

    quit

    синоним bye.

    recv

    удаленный_файл [ местный_файл ] синоним команды get.

    remotehelp [ имя_команды ]

    Запрашивает справочную информацию у удаленного FTP-сервера. Если имя_команды задано, запрашивается информация о конкретной команде.

    runique

    Включает режим записи файлов в вашу ЭВМ только с уникальными именами. Если файл с таким именем уже существует, то новому файлу будет присвоено имя с расширением .1, если и такое имя уже есть, то с расширением .2. Это может продолжаться вплоть до расширения .99, после чего будет выдано сообщение об ошибке. Впрочем, такую ситуацию вообразить крайне трудно, если вы сами не наплодили файлов с цифровыми расширениями. Для команды mget это крайне полезная функция, которая застрахует вас от стирания ваших файлов из текущего каталога, имеющих имена, совпадающие с именами на удаленном сервере. По умолчанию runique не включено.

    send local-file [ remote-file ]

    Синоним команды put.

    status

    Отображает текущее состояние ftp.

    В депозитариях можно встретить файлы следующих разновидностей (все виды ниже перечисленных файлов пересылаются в режиме binary, а не ASCII):

    Таблица 4.5.4.2

    Тип файла

    Пример записи имени файла

    Программа обработки файла

    Архивированный файл

    файл.Z

    compress, uncompress

    tar-файл

    файл.tar

    tar

    Архивированный tar-файл

    файл.tar.Z

    tar, compress, uncompress

    файл.tar.gz

    Применен архиватор GZIP

    uuencode-файл

    файл.uue

    uuencode, uudecode

    Архивированный uuencode-файл

    файл.uue.Z

    uuencode, uudecode, compress, uncompress

    zip-файл

    файл.zip

    pkzip, pkunzip

    shar-файл

    файл.shar

    shar, sh, unshar

    сжатый shar-файл

    файл.shar.Z

    shar, sh, unshar, compress, uncompress

    При выполнении FTP система возвращает трехразрядные десятичные коды-отклики, которые позволяют судить о корректности обмена и диагностировать процедуру. Выдача кода сопровождается текстом-комментарием. Первая цифра может принимать значения от 1 до 5. Структура кодов показана в таблице 4.5.4.3:

    Таблица 4.5.4.3. Коды диагностики

    Значение кода-отклика

    Описание

    1yz

    Позитивный предварительный отклик, который означает, что операция начата. До завершения процедуры следует ожидать как минимум еще один отклик

    2yz

    Сигнал успешного завершения процедуры, говорящий о том, что можно ввести новую команду

    3yz

    Положительный промежуточный отклик, указывающий на то, что команда воспринята, но для продолжения требуется дополнительная информация

    4yz

    Негативный отклик, свидетельствующий о том, что команда не воспринята, но можно попробовать ее исполнить еще раз

    5yz

    Отклик, говорящий о том, что команда не выполнена и не может быть выполнена вообще

    Значение кода "y" в вышеприведенной таблице может принимать значения от 0 до 5. Значения кодов "y" приведены ниже:

    Значение кода-отклика

    Описание

    x0z

    Указывает на синтаксическую ошибку; синтаксис верен но команда не имеет смысла

    x1z

    Указание на необходимость ввода дополнительной информации

    x2z

    Отклик, связанный с управлением каналом связи

    x3z

    Отклик для команд идентификации пользователя и проверки пароля

    x4z

    Функция не определена

    x5z

    Отклик, характеризующий состояние файловой системы

    Далее в тексте встречается выражение "анонимное FTP", это подразумевает следующую процедуру (см. также RFC-1635):

    ftp> login: anonymous
    ftp> password: [ваш полный E-mail адрес]

    ftp> cd <имя_каталога >

    (смена каталога)

    ftp> binary

    (если текст, например, архивирован, в противном случае команду выдавать не нужно)

    ftp> get <имя_файла>

    (копирование файла)

    ftp> quit

    (уход из процедуры)

    Следует иметь в виду, что некоторые анонимные FTP-серверы (также как, например, GOPHER-серверы) требуют, чтобы ЭВМ, с которой осуществляется ввод, имела не только IP-адрес, но и зарегистрированное в локальном DNS-сервере имя. Эти FTP-серверы, получив запрос, пытаются выяснить имя ЭВМ, так как они ведут "журнал посещений", и в случае неуспеха прерывают сессию. Таким образом, анонимное FTP может считаться таковым лишь условно, в смысле ненужности быть авторизованным на сервере, чтобы иметь к нему доступ. Конкретные примеры кодов статуса обмена для FTP

    Таблица 4.5.4.4. Коды откликов

    Код-отклик

    Описание

    110

    Комментарий

    120

    Функция будет реализована через nnn минут

    125

    Канал открыт, обмен данными начат

    150

    Статус файла правилен, подготавливается открытие канала

    200

    Команда корректна

    211

    Системный статус или отклик на справочный запрос

    212

    Состояние каталога

    213

    Состояние файла

    214

    Справочное поясняющее сообщение

    220

    Слишком много подключений к FTP-серверу (можете попробовать позднее). В некоторых версиях указывает на успешное завершение промежуточной процедуры

    221

    Благополучное завершение по команде quit

    225

    Канал сформирован, но информационный обмен отсутствует

    226

    Закрытие канала, обмен завершен успешно

    230

    Пользователь идентифицирован, продолжайте

    250

    Запрос прошел успешно

    331

    Имя пользователя корректно, нужен пароль

    332

    Для входа в систему необходима аутентификация

    421

    Процедура не возможна, канал закрывается

    425

    Открытие информационного канала не возможно

    426

    Канал закрыт, обмен прерван

    450

    Запрошенная функция не реализована, файл не доступен, например, занят

    451

    Локальная ошибка, операция прервана

    452

    Ошибка при записи файла (не достаточно места)

    500

    Синтаксическая ошибка, команда не может быть интерпретирована (возможно она слишком длинна)

    501

    Синтаксическая ошибка (неверный параметр или аргумент)

    502

    Команда не используется (нелегальный тип MODE)

    503

    Неудачная последовательность команд

    504

    Команда не применима для такого параметра

    530

    Система не загружена (not logged in)

    532

    Необходима аутентификация для запоминания файла

    550

    Запрошенная функция не реализована, файл не доступен, например, не найден

    552

    Запрошенная операция прервана, недостаточно выделено памяти

    В настоящее время разработаны версии FTP для работы с IPv6 (RFC-2428).

    Previous: 4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.4.1 Протокол TFTP


    previous up down next index index
    Previous: 4.5.4 Протокол пересылки файлов FTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.5 Протокол X-Windows

    4.5.4.1 Протокол TFTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    TFTP (Trivial FTP, RFC-1350, -783, RFC-906, STD0033) представляет собой упрощенную версию FTP. TFTP не имеет системы безопасности и идентификации, она в отличии от FTP базируется на протоколе UDP (порт 69), а не TCP. Обычно передача осуществляется блоками по 512 байт с ожиданием подтверждения приема каждого пакета (протокол "стой-и-жди"). TFTP используется при загрузке операционной системы в бездисковые рабочие станции (напр. X-терминалы, см. BOOTP) или для загрузки конфигурационных файлов в маршрутизатор. Возможно и непосредственное исполнение команды TFTP (TFTP имя_ЭВМ), хотя эта процедура и не дает каких-либо серьезных преимуществ перед FTP (кроме скорости обмена). При выполнении команды без параметров машина выдает приглашение TFTP> и вам предоставляется возможность выполнить определенные команды (ЭВМ SUN):

    connect имя_ЭВМ [ порт ]

    Задает имя ЭВМ, с которой будет осуществляться обмен, и, если это необходимо порт. Но реального соединения не производится, так как это не предусмотрено протоколом.

    mode модификация_обмена.

    В качестве модификаций обмена данными могут использоваться аргументы ASCII или BINARY. По умолчанию используется ASCII.

    put имя_файла
    put местный_файл удаленный_файл
    put имя_файла1 имя_файла2 ... имя_файлаn удаленный_каталог

    Копирование файла или группы файлов в указанный файл или каталог. Здесь предполагается, что имя удаленной ЭВМ было указано ранее. Если же это не так, возможно одновременное указание имени удаленной ЭВМ и имя файла-адресата: имя_ЭВМ:имя_файла. Имя_ЭВМ становится именем по умолчанию для последующих обменов. Субкоманда GET имеет аналогичную форму обращения. Субкоманда trace позволяет отследить путь пакетов, а команда status сообщит текущее состояние системы. Уход из TFTP по команде exit или quit.

    Существует пять форматов пакетов tftp:

    Рис. 68. Форматы TFTP-сообщений

    Операции запросов (RRQ и WRQ) требуют присылки пакета-отклика (ACK). Сначала устанавливается связь между клиентом и сервером, для этого посылаются запросы read или write. При этом сообщается имя файла и режим доступа (Mode). Предусмотрено три режима доступа, которые определяются значением поля MODE: NetASCII (американский стандарт для информационных обменов), побайтный (режим binary) и почтовый (данные поступают пользователю, а не заносятся в файл, при этом используется система кодов NetASCII). Предусмотрено шесть типов сообщений об ошибках:

    0 - не определен;
    1 - файл не найден;
    2 - ошибка доступа;
    3 - переполнение диска или превышение выделенной квоты;
    4 - нелегальная TFTP-операция;
    5 - неизвестный идентификатор обмена.

    Если запросы read или write успешно выполнены, сервер использует IP-адрес и номер UDP-порта клиента для идентификации последующих операций. Таким образом, ни при пересылке данных, ни при передаче подтверждений (ACK) не нужно указывать явно имя файла. Блоки данных нумеруются, начиная с 1, подтверждение получения пакета имеет тот же номер. Получение блока с размером менее 512 байт означает конец файла. Получение сигнала об ошибке прерывает обмен. При возникновении тайм-аута производится повторная передача последнего блока данных или подтверждения. При задержке отклика, превышающей значение тайм-аута, возможно удвоение всех последующих блоков. Это происходит в некоторых реализациях программного обеспечения оттого, что из-за тайм-аута происходит повторная пересылка блока, а запоздавший отклик на блок i вызовет посылку блока i+1. Это будет продолжаться вплоть до конца пересылки файла. TFTP-протокол используется также и при реализации электронной почты (посылка файлов почтовой программе).

    Отсутствие авторизации делает доступность TFTP одной из угроз безопасности. Именно по этой причине во многих инструкциях вы можете найти рекомендацию запретить применение этой утилиты.

    Previous: 4.5.4 Протокол пересылки файлов FTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.5 Протокол X-Windows


    previous up down next index index
    Previous: 4.5.4.1 Протокол TFTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.6 WWW

    4.5.5 Протокол X-Windows
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Система X-windows была разработана в Массачусетском Технологическом институте (сотрудники этого института внесли существенный вклад и в разработку всего комплекса TCP/IP-протоколов) в качестве многооконного программного интерфейса для ЭВМ с побитовым отображением графической информации. Система предполагала отображение результатов работы нескольких программ одновременно. Сегодня это одна из наиболее популярных систем. Для каждой программы выделялась отдельная область на экране - "окно". С самого начала система предназначалась для работы в различных сетях (TCP, IPX/SPX и т.д.). Система может управлять окнами как на локальной, так и удаленной ЭВМ. Для управления окнами используются специальные сообщения. Для обмена этими сообщениями разработан x-windows протокол. Система X-windows состоит из двух частей Xlib и X-сервера (RFC-1198).

    Рис. 4.5.5.1. Схема взаимодействия различных частей X-windows

    xlib является интерфейсом для любого прикладного процесса и обычно представляет собой программу, написанную на C. Xlib отвечает за обмен информацией между сервером и терминалом пользователя (X-клиент). Под приложениями здесь подразумеваются независимые процессы. Для каждого терминала инсталлируется отдельный X-сервер. Один X-сервер может обслуживать несколько клиентов. X-сервер осуществляет отображение на экране всех окон, в то время как функция клиентов - управление окнами. Для управления окнами используются структуры типа стеков.

    Прикладная программа-клиент и сервер взаимодействуют друг с другом через системный протокол X-windows (RFC-1013 и RFC-1198). При этом используется четыре вида сообщений:

    1. Запрос: инструкция, направляемая серверу рабочей станции, например, нарисовать окружность.
    2. Отклик: направляется от сервера в ответ на запрос.
    3. Событие: используется сервером, чтобы сообщить прикладной программе об изменениях, которые могут повлиять на ее работу (например, нажатие клавиши на терминале или мышке, запрос из сети и т.д.).
    4. Ошибка: посылается сервером прикладной программе, если что не так (переполнение памяти, неправильно заданные параметры делают выполнение задания невозможным и пр.).

    Форматы таких сообщений представлены на рис. 4.5.5.2.

    Рис. 4.5.5.2 Форматы сообщений об ошибках

    Некоторые X-запросы не нуждаются в откликах (например, связанные с перемещением манипулятора мышь), такие сообщения могут группироваться и посылаться единым потоком (batch stream). Такой подход позволяет пользователю выдать Xlib-запрос и перейти к выполнению других операций, в то время как схема запрос-отклик требует ожидания.

    Сообщение типа событие посылается прикладной программе только в случае, если она запрашивала такого рода информацию.

    X-Windows приложения должны установить канал связи между собой, прежде чем они смогут обмениваться сообщениями. Приложение для того, чтобы установить связь с рабочей станцией использует запрос XOpenDisplay из библиотеки Xlib. Xlib формирует структуру дисплея, которая содержит необходимую информацию, определяющую режим обмена прикладная программа <-> рабочая станция. После того как связь установлена прикладная программа и рабочая станция готовы к работе. Если была нажата клавиша мышки (событие - ButtonPress), а не известно, в каком из окон находится ее указатель, прикладная программа выдает в Xlib запрос XQueryPointer. Положение указателя будет прислано в отклике на этот запрос.

    Данный протокол, строго говоря, не входит в набор TCP/IP хотя, как было сказано, он описан в RFC. Но мне представлялось важным дать в руки операторов сетей информацию, которая позволит им лучше понимать, что "гуляет" по их кабельным сегментам.

    Previous: 4.5.4.1 Протокол TFTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.6 WWW


    previous up down next index index
    Previous: 4.5.5 Протокол X-Windows    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.6.1 Гипертекстный протокол HTTP

    4.5.6 WWW
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Определения и понятия

    Прежде чем передать что-то, надо это иметь. Люди общаются, используя естественные языки, ЭВМ обмениваются нуликами и единицами. Но даже в привычном для всех нас общении на родном языке иногда возникают проблемы, и тогда мы переспрашиваем партнера (это прием используют и коммуникационные системы). Когда же мы читаем, перед нами возникает последовательность символов из хорошо известного с детства алфавита. Символы эти могут существенно варьироваться по форме своего изображения, но мы их все равно без труда распознаем.

    Получаемая нами информация поступает не только от общения с людьми, книгами или телевизором. Не мало крайне важных для жизни данных мы получаем о себе и окружающем мире по имеющимся у нас каналам органов чувств. Мы научились сопоставлять и перепроверять эти данные, когда это требуется. Успешное функционирование этих каналов передачи данных и средств их обработки позволяет нам прожить относительно долгую жизнь. Любые же сбои могут повлиять на нашу судьбу самым драматическим образом.

    Человечество научилось усовершенствовать данные нам природой каналы информационного обмена. Сначала это были примитивные сигнальные системы типа костров на вершинах холмов (пропускная способность 0,5 бит/час). Появление письменности открыло возможность общения уже умерших людей с живыми, обеспечив процесс накопления знаний. Довольно большие объемы информации могли уже передаваться с использованием лошадей и кораблей на практически неограниченные расстояния. Но скорость такого обмена была ничтожна, доставка сообщения занимала часы, дни, а иногда и годы (никакого намека на работу современной почты я здесь не делаю).

    Гигантским шагом вперед стало изобретение электрического телеграфа, а позднее радио. Сегодня же мы узнаем о землетрясении в 20000 км от нас максимум через час из очередного телевизионного сборника новостей. Люди объясняются в любви с использованием электронной почты и делают покупки, не выходя из дома.

    На нас обрушилась лавина информации. Диабетик узнает о прелестях сникерса, мужчины маются, слушая информацию о потрясающих особенностях прокладок с крылышками, о несмываемой губной помаде и т.д. и т.д.

    Мы стали получать слишком много совершенно ненужной информации. Миллионером станет человек, который предложит покупателям телевизор, отфильтровывающий информацию согласно требованиям зрителя. Таким образом, мы уже сталкиваемся с новыми информационными проблемами, хотя нельзя сказать, что мы решили все старые. Сплошь и рядом мы узнаем слишком поздно о своих болезнях, об угрозах стихийных бедствий или об истинных свойствах того или иного политика.

    Эти же проблемы относятся и к Интернет. По электронной почте вы получаете сообщения от совершенно незнакомых людей, которые утверждают, что очень хотят вашего быстрого обогащения (хотя их цели диаметрально противоположны), или предлагающих вам какие-то товары или услуги, хотя вы их об этом не просили.

    К Интернет получили доступ десятки миллионов людей. Если в издательствах редакторы, заботясь о доходах и избегая убытков, блокируют доступ графоманов к широким массам читателей, такого механизма в Интернет не существует. Таким образом, программные средства, фильтрующие поток данных на входе вашего почтового или web-сервера, здесь также весьма актуальны. Ниже даются некоторые определения понятий, используемых в разделах о протоколе http, www и информационном поиске.

    Рассмотрим некоторые свойства информации, например структурированность и ценность. Структурированность - это свойство, которое позволяет принимающей стороне выделить информацию в виде некоторого сигнала, обладающего некоторыми свойствами. Ценность данных выражается через содержательность, полноту, оперативность и достоверность.

    При обработке и передаче данных важную роль играют знаки и знаковые системы. Знак - это материальный объект, который служит для обозначения другого объекта и используется для передачи информации о последнем. Примерами знаков могут служить ноты, цифры, жесты азбуки глухонемых, знаки регулирования уличного движения и т.д. Одной из разновидностей знака является символ. Разновидностью знаковых систем являются языки, самым сложным из которых является естественный человеческий язык. Все проявления и применения знаков и знаковых систем изучает семиотика. Предметом семиотики является связь знаков друг с другом, с обозначаемыми ими объектами и явлениями, а также с субъектами их использующими для целей коммуникаций. Семиотика содержит в себе три раздела: семантика, синтактика и прагматика.

    Семантика изучает отношения между знаком и тем, что он обозначает или замещает. Синтактика знаковых систем изучает их структуру и правила соединения знаков.Прагматика изучает законы функционирования знаковой системы, как средства коммуникации субъектов. С прагматикой связаны такие понятия как ценность и цель.

    World Wide Web (всемирная сеть, WWW или 3W) представляет собой информационную систему, базирующуюся на использовании гипертекста. Разработка этой системы была начата Тимом Бернерс-Ли, которому в 1989 году пришла в голову мысль объединить гипертекст с Интернет. Идея впервые реализована в ЦЕРН (Женева). Доступ к WWW возможен только в рамках протоколов TCP/IP, но для использования 3w необязательно иметь сервер-клиент (browser) на вашей машине. С некоторыми ограничениями возможен доступ и через электронную почту (listserv@info.cern.ch). Если WWW-клиент-сервер не установлен, можно работать в режиме удаленного терминала. Весьма удобным программным интерфейсом для WWW является ms explorer, netscape и некоторые другие. Для подготовки документов в рамках HTML (Hypertext Markup Language) пригоден любой текстовый редактор (например, emacs в UNIX-машинах, ME в MS-DOS или Winword, в последних версиях которого уже допускаются гиперссылки). При подготовке гипертекстов вы можете использовать язык HTML или взять одно из множества доступных программных средств, которые позволяют преобразовать ваш документ в необходимый формат. Документы в гипертексте связываются друг с другом определенным набором слов. Пользователю не нужно знать, где находится тот или иной документ. Часто ссылки на серверы WWW начинаются с сокращения http:// (Hypertext Transfer Protocol). Гипертекст позволяет осуществлять ссылки-разъяснения на статьи, хранящиеся на удаленном сервере. Гипертекст подразумевает не только текстовые объекты (но и графические или звуковые), поэтому термин гиперсреда (hypermedia) более правилен. WWW может проводить поиск ключевых слов и в специфических документах-индексах, в этом случае выдаются указатели на искомые документы. WWW может использовать различные форматы документов и работать с разнообразными структурами информации, обеспечивая доступ к информационной вселенной. На рис. 4.5.6.1 показан рост числа WEB-серверов, базирующихся на разных программных продуктах (www.netcraft.com). В 2000 году скорость регистрации web-серверов достигла 1 в секунду.

    Рис. 4.5.6.1. Рост числа web-серверов в период 1995-99 годов

    На февраль 1999 года число www-серверов равнялось 4.301.512.

    Что же такое гипертекст?

    Прежде всего, следует отметить, что гипертекст - это текст, состоящий из ascii-символов. Для обеспечения верстки и организации перекрестных ссылок в гипертексте используются слова-метки. Основу гипертекста составляют HTML-элементы. Такой элемент включает в себя имя, атрибуты, текст или гипертекст. HTML-элемент записывается в документ в виде (более подробное описание смотри в статье о html):

    <имя_метки> текст </имя_метки>
    <имя_метки> имя_атрибута=аргумент текст </имя_метки>

    html-документ состоит из одного элемента: <html>

    .... </html>, который состоит из html-элементов: <head>

    ... </head> и <body> ... </body>, последние в свою очередь могут содержать различные списки, внутренние и внешние метки и т.д.. Элементы <html>, <head> и <body> для совместимости с более старыми текстами сделаны пока необязательными. В html имеется 6 уровней заголовков (<h1>, .... <h6>), из них первый - главный. В версии HTML+ (и более поздних версиях) предусмотрены операторы позиционирования текста, например, <p align="center">. head-элементы могут содержать в себе:

    <isindex>

    говорит о том, что данный документ допускает индексный поиск (база данных).

    <title> . . . </title>

    описывает заголовок документа, этот заголовок характеризует содержимое окна.

    <base href="url">

    сообщает имя файла, в котором хранится данный документ.

    <link rev="relationship" rel="relationship" href="url">

    этот элемент позволяет установить связь между документом, содержащим метку (якорь), и документом, указанным в URL (Uniform Resource Locator). Атрибут rel устанавливает связь между HTML-файлом и URL. Атрибут rev (reverse) описывает взаимоотношения между URL и HTML-файлом.

    Элементы body могут содержать элементы:

    Текстовые элементы:

    <p> индицирует конец параграфа и начало нового.

    <pre> . . . </pre>

    выделяет текст, который уже был сформатирован ранее (таблицы, программы, стихи, ...).

    <blockquote> . . . </blockquote>

    ограничивает часть текста, который должен быть выделен кавычками.

    Гиперсвязи или якоря

    <a name="anchor_name"> . . . </a>

    определяет заданную позицию в документе.

    <a href="#anchor_name"> . . . </a>

    описывает ссылку на определенное место текущего документа.

    <a href="url"> . . . </a>

    устанавливает связь с другим файлом или ресурсом.

    <a href="url#anchor_name"> . . . </a>

    устанавливает связь с заданным местом в другом документе.

    <a href="url?search_word+search_word"> . . . </a>

    посылает серверу эталонную строку для поиска.

    Различные системы поиска могут интерпретировать эту строку по-разному. Для того чтобы читатель незнакомый с гипертекстом, получил некоторое представление о том, как он выглядит, приведу пример:

    <title> Протоколы и ресурсы Интернет </title>
    <h1> Это уровень первого заголовка </h1>
    <h2> Уровень второго заголовка </h2>
    <p> Начало параграфа ....

    Вам уже ясно, что подготовка гипертекстов "вручную" изнурительная задача и вспомогательные программные средства не повредят, особенно если вы хотите, чтобы ваш текст выглядел привлекательно. Заметим, что управляющие слова-метки могут записываться как строчными, так и прописными буквами (<H1> = <H1>), но они могут восприниматься различными программами просмотра по-разному (могут и игнорироваться вовсе). HTML поддерживает нумерованные (OL), ненумерованные (UL), и описательные списки (DL). Пример нумерованного списка:

    Записано в гипертексте

    Отображено на экране

    <ol>

    <li> Белоруссия</li>

    1. Белоруссия

    <li> Россия</li>

    2. Россия

    <li> Украина</li>

    3. Украина

    </ol>

    Примером описательного списка может служить:

    <dl>
    <dt> ИТЭФ
    <dd> Институт Теоретической и Экспериментальной Физики, Москва, Россия.
    <dt> ИФВЭ
    <dd> Институт Физики Высоких Энергий, Протвино.
    </dl>

    На экране это будет выглядеть примерно так:

    ИТЭФ

    Институт Теоретической и Экспериментальной Физики, Москва.

    ИФВЭ

    Институт Физики Высоких Энергий, Протвино.

    <dt> - метка определения, а <dd> - метка данных описания. Как <dt> так и <dd> могут содержать много параграфов, разделенных меткой <p>. Допускается вложение списков друг в друга, например <fsu.html>:

    <ul>
    <li> Белоруссия</li>
    <li> Россия</li>
    <dl>
    <dt> ИТЭФ
    <dd> Институт Теоретической и Экспериментальной Физики, Москва.
    <dt> ИФВЭ
    <dd> Институт Физики Высоких Энергий, Протвино.
    </dl>
    <li> Украина</li>
    </ul>

    Некоторые символы являются служебными для html и для их отображения на экране требуются определенные ухищрения. Например:

    Символ

    записывается как

    <

    &lt;

    >

    &gt;

    &

    &amp;

    &nbsp; (неразрывный пробел)

    Символ ; (точка с запятой) является составной частью описания. Все предшествующее относилось к описанию представления текстов на экране. Теперь рассмотрим, как можно обозначить смысловые связи и ссылки друг на друга различных частей текста. Собственно именно ради этого и создавалась идеология гипертекстов. Метка, означающая наличие связи, имеет вид <a> и происходит от слова anchor (якорь). В общем виде ссылка имеет следующий формат:

    <a href="url"> текст </a>

    URL (universal resource locator) в простейшем случае может быть именем файла. Текст обозначает действительный текст в документе, который может быть подсвечен, выделен другим цветом или помечен цифрой. Этот текст говорит программе просмотра, что в URL можно найти связанную с данным документом информацию или изображение. При использовании программы типа MS IE (или Netscape) для вызова этой информации или изображения на экран достаточно указать мышкой на текст и нажать кнопку. Если URL указывает на объект, находящийся не в вашей сети эта процедура может занять некоторое время. Чтобы вас как-то развлечь, программа показывает вам вращающийся земной шар в верхнем правом углу экрана. Метка <A> может использоваться и для ссылки на определенный раздел документа:

    <a name="refname"> текст </a>,

    где refname является меткой в вашем документе. Пусть в файле fsu.html определена следующая ссылка-якорь:

    <a name="итэф"> ИТЭФ </a>

    тогда, находясь в пределах этого документа, можно попасть в нужную точку с помощью:

    <a href=#итэф> У-10 </a> протонный синхротрон.

    В другом документе может присутствовать встречная ссылка, например:

    У-10 в <a href="fsu.html#итэф"> ИТЭФ>/a>

    Теперь, при нажатии кнопки мышки на слове ИТЭФ, программа отобразит fsu.html и отметит позицию со словом ИТЭФ (ссылка name=итэф). Вообще говоря, вы можете ссылаться на метки-якоря в файлах, находящихся на другой машине (на другом конце земли :-) ), приводя полное наименование URL. В общем случае url указывает тип и место расположения ресурса:

    сервер://host.domain[:port]/path/объект,

    где в качестве сервера может стоять: FTP, Telnet, HTTP, Gopher, Wais, News. Path описывает проход к каталогу, где лежит объект. Если программа просмотра (Netscape) способна воспроизводить изображения, можно ввести ссылки на файлы, содержащие нужные для пояснения текста картинки, например:

    <img src="имя_файла.gif">

    Обратите внимание, что здесь используется графический стандарт gif (Graphics Interchange Format). Приемлемы также графические форматы tiff, jpeg, rgb и hdf. Читатели, желающие сформировать титульную страницу (home page) своего института, фирмы или проекта, должны изучить предмет более углубленно, обратившись, например по адресу:

    http://info.cern.ch/hypertext/www/provider/overview.html.

    После этого недолгого экскурса в гипертекст, который является основой многих поисковых систем, вернемся к проблематике www. Следует заметить, что публично доступные клиент-серверы существуют для сред MS-DOS, VMS, MVS, UNIX, X-windows, Macintosh, NEXT. Это математическое обеспечение доступно через анонимный FTP из депозитария info.cern.ch секции /pub/www (или www.earn.net gnrt/www.html). Графические клиент-серверы доступны для UNIX, Windows, Macintosh, X-windows, Next.

    Режим удаленного терминала можно реализовать через telnet по адресу info.cern.ch (при этом не требуется иметь авторизацию на какой-либо ЭВМ ЦЕРН). Многие серверы при старте выходят на приглашение login. Обычно для входа в WWW при этом достаточно напечатать WWW. Никакого слова-пропуска не требуется. Программный пакет PCTCP (и некоторые другие) допускает настройку на эмуляцию того или иного терминала, например:

    tn -x vt100 info.cern.ch, где info.cern.ch - адрес WWW-сервера, который предполагает работу с терминалом VT-100 (или его эмулятором). При работе в строчном режиме (режим меню) вам предлагается возможность выбора одного из пунктов меню. Для этого вы печатаете номер этого пункта и нажимаете клавишу <enter>. Если все меню на экране не помещается, вы можете перемещаться по нему в любом направлении. Пояснения, содержащиеся на экране, позволяют работать c системой даже новичку.

    WWW-сервер в простом варианте выполняет лишь команды get имя_файла, приходящие от клиент-сервера пользователя. Остальная работа выполняется www-клиентом.

    Существует достаточно много "удаленных" тематических серверов, например:

    Адрес

    Тематика

    Страна

    vms.huji.ac.il (128.139.4.3)

    Окружающая среда

    Израиль

    info.cern.ch (128.141.201.74)

    Физика высоких энергий

    Швейцария

    fatty.law.cornell.edu (132.236.108.5)

    Законодательство

    США

    ukanaix.cc.ukans.edu (129.237.1.30)

    История

    США

    www.njit.edu (128.235.163.2)

     

    США

    www.erg.abdn.ac.uk

    Нейронные сети

    Англия

    www.mech.gla.ac.uk

     

    Англия

    www.ai.univie.ac.at

     

    Австрия

    kal-el.ugr.es

     

    Испания

    opal.vcu.edu

    Нанотехнология

    США

    galaxy.ph.tn.tudelft.nl

    Распознавание образов

    Нидерланды

    info.funet.fi (128.214.6.102)

     

    Финляндия

    fserv.kfki.hu (148.6.0.3)

     

    Венгрия

    Список этот не является исчерпывающим, существуют клиент-серверы и в России. Появились и первые зеркальные www-депозитарии в России (например, xxx.itep.ru ("зеркало" сервера LANL - Лос-Аламос, США), store.in.ru (зеркальный сервер по Linux - Red Hat и RFC) и т.д.. Хотя в вышеприведенной таблице указана тематика серверов, не следует думать, что этим ограничивается содержимое депозитариев. ЦЕРН является базовой организацией для справочных запросов (здесь работают многие авторы этой системы, www-bug@info.cern.ch). Для получения нужного файла по электронной почте следует послать mail по адресу listserv@info.cern.ch с командой send. Команда send присылает документ с данным www-адресом. Но следует иметь в виду ряд ограничений. Гипертекстные документы имеют стандартную ширину в 72 символа. В конце документа обычно имеется список других адресов документов по данной или близкой тематике. Гипертекстный документ имеет связи, которые помещаются в квадратные скобки. Обратите внимание на то, что, несмотря на наличие имени listserv в начале, - это не listserv-сервер. Максимальное число строк, получаемое пользователем, при этом не превышает 1000 (хотя сегодня найдется немного желающих пользоваться такой услугой, если имеется прямой доступ в Интернет). Все запросы мониторируются. При работе с графикой выбор того или иного объекта производится мышкой. Работая со строчным сервером, следует набрать номер строки меню и нажать клавишу <enter>. В WWW доступны некоторые команды (параметры команд помещаются в угловые скобки <>, в квадратных скобках приведены сокращенные названия команд для построчного просмотра; используется полное или сокращенное имя команды.):

    Команда

    Сокращение

    Назначение

    help

    [h]

    Выдает гипертекстный адрес текущего документа и список доступных команд, который является контекстно зависимым.

    manual

    [m]

    Отображает пояснительные тексты, если таковые имеются.

    quit

     

    Уход из www.

    up

    [u]

    Перемещает текущую страницу документа вверх [предшествующий экран].

    down

     

    Перемещает текущую страницу документа вниз [следующий экран].

    top

    [t]

    Устанавливает указатель в начало документа.

    bottom

    [bo]

    Устанавливает указатель в конец документа.

    back

    [b]

    Возвращает просмотр к предшествующему документу.

    home

    [ho]

    Возврат к первому документу.

    next

    [n]

    Осуществляет переход к просмотру следующего документа.

    previous

    [p]

    Осуществляет переход к просмотру предшествующего документа.

    list

    [l]

    Выдает пронумерованный список связей текущего документа, для отслеживания связей следует отпечатать соответствующий номер.

    recall

    [r] <number>

    Если число опущено, выдает пронумерованный список документов, которые вы просмотрели. Для просмотра определенного документа выполните команду с соответствующим номером.

    find

    [f] <ключевое слово>

    Поиск ключевых слов в индексе. Список находок отображается вместе со ссылками возможных дополнений. Ключевые слова отделяются пробелами. find можно и не печатать, если ключевое слово не совпадает ни с одной из команд www. Команда find выполнима не всегда.

    go

    [g] docaddress

    Просмотр документа с данным гипертекстным адресом.

    print

     

    Команда доступна только из unix. Печатает текущий документ. По умолчанию команда печати имеет имя lpr, но ее имя может быть определено переменной www_print_command.

    Стандартная форма обращения к www имеет вид:

    www <option> <docaddress <ключевое слово>>,

    где docaddress - гипертекстный адрес документа, который вы хотите просмотреть; а ключевое слово - объект поиска в индексе, предоставляемом docaddress. По умолчанию на экран вызывается первый документ. В нижней части экрана отображается строка выполнимых команд. Команды могут набираться как строчными, так и заглавными буквами. Имеются следующие возможности (опции):

    -n

    Неинтерактивный режим. Документ форматируется и отображается на экране. Страницы разделяются символами form feed (FF)

    -listrefs

    Добавляется список адресов всех ссылок вплоть до конца. Только не интерактивный режим

    -pn

    Устанавливает длину страницы равной n строк. По умолчанию длина страницы равна 24 строкам. Команда без числа делает страницу бесконечной

    -wn

    Устанавливает ширину страницы равной n колонкам. По умолчанию ширина равна 78, 79 или 80

    -na

    Прячет ссылки в тексте, удобно при распечатке

    -version

    Отображает версию используемой программы

    Для перехода к следующей странице достаточно нажать клавишу <enter>. Ниже приведен пример меню World Wide Web (в настоящее время данный вид доступа представляет скорее исторический интерес):

    the world-wide web virtual library: subject catalogue
    the www virtual library

    this is a distributed subject catalogue. see also arrangement by service type [1], and other subject catalogues of network information [2].
    mail to maintainers of the specified subject or www-request@info.cern.ch to add pointers to this list, or if you would like to contribute to administration of a subject area.
    see also how to put your data on the web [3]
    aeronautics mailing list archive index [4]. see also nasa larc [5]
    agriculture see agricultural info [6], almanac mail servers [7]
    the agricultural genome [8] (national agricultural library, part of the u.s. department of agriculture)
    archaeology [9] separate list
    astronomy and astrophysics [10] separate list.
    1-64, back, <return> for more, quit, or help:

    Цифры в квадратных скобках представляют собой пункты меню. Для выбора одного из них достаточно напечатать его номер (после двоеточия) и нажать клавишу <enter>. Поиск возможен только в случае, когда в меню в нижней части экрана присутствует слово find. Рассмотренная выше версия является устаревшей, но она дает представление о том как работает WEB-сервер.

    URL (uniform resource locator) идентифицирует ресурс Internet. В общем виде URL имеет вид:

    access://host/path

    где access = {FTP, Gopher, Telnet, ...}; host = имя ЭВМ-сервера; path = имя файла, имя каталога, или другая информация о ресурсе.

    Например, url для анонимного FTP:

    ftp.rpi.edu/pub/communications/internet-cmc.txt

    означает:


    Если вы не имеете WWW-клиент-сервера типа NetScape (где можно задать HTTP ресурс, который вы хотите получить), HTTP-ресурс может стать доступным для вас через электронную почту. Пошлите через e-mail запрос по адресу listserv@info.cern.ch с текстом в теле сообщения (вариант сегодня достаточно архаичный):

    www URL
    Например, URL для:
    CNIDR Web Page: cnidr.org welcome.html
    имеет форму:
    http://cnidr.org/welcome.html
    Пошлите сообщение:
    $ mail listserv@info.cern.ch
    www http://cnidr.org/welcome.html

    и вы получите welcome.html страницу по электронной почте. Вы можете получить доступ к HTTP-документам с помощью telnet. Команда:

    telnet info.cern.ch

    вызовет базовую страницу WWW в ЦЕРН. Для того чтобы достичь нужного URL, введите команду:

    go http://cnidr.org/welcome.html

    В ЦЕРН WWW-команду возглавляет Tim Berners-Lee. Обнаруженные ошибки или предложения шлите по адресу www-bug@info.cern.ch. Почтовый подписной лист: www-talk@info.cern.ch. Для подписки пошлите запрос по адресу:

    www-talk-request@info.cern.ch. В ЦЕРН работа WWW успешно дополняется другими информационными системами, например, библиотечной системой ALICE. Группа новостей в USENET: comp.infosystem.www.

    Особенности гипертекста с его межуровневыми связями приводят к циклам при просмотре меню (возврат осуществляется по тому же маршруту, по какому вы пришли в данную точку). Это снижает эффективность поиска. Отчасти эти недостатки устранены в графическом интерфейсе NetScape. Графические интерфейсы требуют большой пропускной способности от информационных каналов (желательно > 64 Кб/с). Именно NetScape и MS Explorer стали наиболее популярными интерфейсами поисковых информационных систем и источником наибольших загрузок в телекоммуникационных каналах. Этот интерфейс наиболее естественно позволяет работать и с графическими объектами. Публично доступны версии NetScape для Windows, Unix и т.д. Если у вас уже работает WWW-сервер, нет необходимости заводить серверы GOPHER, Archie или WAIS - их услуги обычно доступны через WWW. Сейчас существует несколько разновидностей программ-надстроек типа NetScape, например MS Explorer, LYNX и некоторые другие.

    Сегодня трудно найти какую-либо фирму, организацию или общественную группу, не представленную в Интернет своей Web-страницей. Эта технология широко используется в сфере рекламы и даже продажи товаров. Следствием этого стала актуальность проблем безопасности для Web-серверов. Большинство этих проблем происходят от несовершенства программ. Несмотря на общеизвестный совет не использовать программы версии 1.0, ошибки и "дыры" встречаются и в более поздних версиях (например, в Apache V.1.1.1 или Netscape Navigator 2.0, MS Internet Explorer 3.0 и т.д.). Хотя функция Web-сервера принципиально проста: найти запрошенный URL и послать его заказчику, реально практически все существующие сервера "обросли" конфигурационными опциями, интерфейсами для различных баз данных, снабжены адаптерами для разных версий HTTP и HTML, скриптами и модулями API. В результате исполняемый модуль WWW-сервера в несколько раз больше, чем для FTP-сервера, что оставляет достаточно пространства для ошибок и возможностей для реализации хакерских замыслов.

    4.5.6.1 Программное обеспечение WEB

    Существует достаточно широкий список программного обеспечения для формирования WEB-сервера. Структура и конфигурация этих серверов варьируется в широких пределах, но есть у них и немало общего. Рассмотрим основные каталоги, которые возникают при установке WEB-сервера.

    Каталог конфигурации. Здесь содержатся файлы, которые определяют рабочие характеристики сервера. Этот каталог жизненно важен, и необходимо максимально возможно ограничить круг лиц, которым разрешено изменять здесь что-либо.

    Инструментальный каталог администратора. Этот каталог содержит утилиты, которыми пользуется администратор сервера. Здесь могут располагаться программы управления доступом, генерации криптографических ключей и формирования поисковых индексов.

    Каталог файла регистрации операций (LOG-файла). Здесь фиксируются все процедуры доступа к серверу, а также все происходящие сбои и ошибки.

    Каталог CGI. В этом каталоге располагаются CGI-скрипты, которые используются для формирования документов с динамически изменяющимся содержимым, для организации доступа к базам данных и выполнения интерактивных задач. Здесь же могут находиться средства, которые позволяют администратору-программисту добавлять свои собственные функции сервера, расширяя его возможности.

    Каталог документов (корневой каталог документов). Этот каталог составляет основу иерархического дерева каталогов документов сервера. Каталог может включать субкаталоги типа html, java, icons и т.д.

    Помимо перечисленных может присутствовать каталог security, где лежат параметры доступа (имена и пароли) авторизованных клиентов сервера.

    Современные WEB-серверы трудно себе представить без CGI-скриптов (Common Gateway Interface). Эти скрипты позволяют существенно расширить возможности сервера, обеспечить доступ к базам данных, работать с документами, содержимое которых изменяется динамически, организовать игры в реальном масштабе времени, обрабатывать запросы клиентов, посылать сообщения по электронной почте и многое другое. CGI-скрипты обеспечивают интерфейс между WEB-сервером и серверами GOPHER или FTP. Привлекательность CGI-скриптов и легкость их написания, к сожалению, дополняется тем, что совсем не просто написать их безошибочно.

    CGI-скрипты (ISO 9636) представляют собой небольшие программы, которые являются независимыми от основной программы сервера. Когда удаленный пользователь запрашивает URL, который указывает на CGI-скрипт, сервер исполняет скрипт, передавая информацию о состоянии сессии. CGI-скрипт обрабатывает эти данные и выдает документ, который, вообще говоря, может быть и не только HTML-страницей. Среди информации, которую передает сервер CGI-скрипту, обычно присутствует строка запроса, содержащая данные, которые поступили от удаленного пользователя. Форма строки запроса произвольна. Она может содержать ключевые слова для поиска или SQL-предложение для обращения к серверу базы данных. Строка запроса может быть передана CGI-скрипту двумя способами. В первом случае она прикрепляется к URL. Например:

    http://www.altavista.com/cgi-bin/query?pg=q&what=web&fmt=.&q=question

    Все, что следует после знака вопроса, представляет собой строку запроса. В этой версии строка запроса должна следовать требованиям записи URL, т.е. пробелы должны заменяться символом + (ключевым словом в приведенном запросе является question). CGI-скрипт извлекает строку запроса с учетом переменной конфигурации (environment). Альтернативой этому является посылка строки запроса CGI методом HTTP POST. Этот метод обычно используется при заполнении пользователем форм и отправке их удаленному серверу. В этом случае WEB-сервер направляет строку запроса непосредственно на стандартный вход скрипта. Желательно пользоваться хорошо проверенными скриптами, а при написании новых следить за тем, чтобы они ни при каких обстоятельствах не допускали исполнения команд на машине сервера и не производили несанкционированной модификации файлов.

    Пользователи WEB сервера, которые имеют доступ к документам и файлам поддержки обычно делятся на четыре категории: хозяин, автор, разработчик и администратор. Каждая их этих категорий имеет разные права доступа, показанные в таблице 4.5.6.1.

    Таблица 4.5.6.1. Возможности различных категорий пользователей WEB-сервера

    Пользователь

    Тип файла

    Конфигурационный

    Инструментальный

    LOG-файл

    CGI

    Документы

    Хозяин

    RW

    R

    R

    RW

    RW

    Разработчик

    -

    -

    -

    RW

    RW

    Автор

    -

    -

    -

    R

    RW

    Клиент

    -

    -

    -

    R

    R

    R - разрешено чтение. W - разрешена запись и уничтожение.

    Хозяином в данном случае считается администратор узла, где размещен WEB-сервер. Автор занимается подготовкой документов и рисунков. Разработчик имеет сходные функции с автором, но в его обязанности входит также разработка и модификация CGI-скриптов и модулей сервера. Клиент (посетитель) может запускать скрипты и читать любые документы. Приведенная иерархия возможностей для пользователей гарантирует устойчивую работу и безопасность WEB-сервера.

    Previous: 4.5.5 Протокол X-Windows    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.6.1 Гипертекстный протокол HTTP


    previous up down next index index
    Previous: 4.5.6 WWW    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.6.2 Язык HTML

    4.5.6.1 Гипертекстный протокол HTTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    4.5.6.1.1 Соглашения по нотации и общая грамматика

    1.1. Расширенные BNF

    1.2. Основные правила

    4.5.6.1.2. Параметры протокола

    2.1. Версия http

    2.2. Универсальные идентификаторы ресурсов (uri)

    2.2.1. Общий синтаксис

    2.2.2. http url

    2.2.3. Сравнение uri

    2.3. Форматы даты/времени

    2.3.1. Полная дата

    2.3.2. Интервалы времени в секундах

    2.4. Наборы символов

    2.5. Кодировки содержимого

    2.6. Транспортное кодирование

    2.7. Типы среды

    2.7.1. Канонизация и текст по умолчанию

    2.7.2. Составные типы

    2.8. Лексемы (token) продукта

    2.9. Значения качества (quality values)

    2.10. Языковые метки

    2.11. Метки объектов

    2.12. Структурные единицы

    4.5.6.1.3. http сообщение

    3.1. Типы сообщений

    3.2. Заголовки сообщений

    3.3. Тело сообщения

    3.4. Длина сообщения

    3.5. Общие поля заголовка

    4.5.6.1.4. Запрос

    4.1. Строка запроса

    4.1.1. Метод

    4.1.2. uri запроса

    4.2. Ресурс, идентифицируемый запросом

    4.3. Поля заголовка запроса

    4.5.6.1.5. Отклик

    5.1. Статусная строка

    5.1.1. Статусный код и словесный комментарий

    5.2. Поля заголовка отклика

    4.5.6.1.6 Объект (entity)

    6.1. Поля заголовка объекта

    6.2. Тело объекта

    6.2.1. Тип

    6.2.2. Длина

    4.5.6.1.7. Соединения

    7.1. Устойчивые соединения

    7.1.1. Цель

    7.1.2. Общие процедуры

    7.1.2.1. Согласование

    7.1.2.2. Буферизация

    7.1.3. Прокси-серверы

    7.1.4. Практические соображения

    7.2. Требования к передаче сообщений

    4.5.6.1.8. Метод определений

    8.1. Безопасные и idempotent методы

    8.1.1. Безопасные методы

    8.1.2. idempotent методы

    8.2. Опции

    8.3. Метод get

    8.4. Метод head

    8.5. Метод post

    8.6. Метод put

    8.7. Метод delete

    8.8. Метод trace

    4.5.6.1.9. Определения статусных кодов

    9.1. Информационный 1xx

    9.2. successful 2xx (Успешная доставка)

    9.3. redirection 3xx (Переадресация)

    9.4. client error 4xx (Ошибка клиента)

    9.5. Сервер ошибок 5xx

    4.5.6.1.10. Идентификация доступа

    10.1. Базовая схема идентификации (authentication)

    10.2 Краткое изложение схемы авторизации

    4.5.6.1.11. Согласование содержимого

    11.1. Согласование, управляемое сервером

    11.2. Согласование, управляемое агентом (agent-driven negotiation)

    11.3. Открытое согласование (transparent negotiation)

    4.5.6.1.12. Кэширование в http

    12.1. Корректность кэша

    12.2. Предупреждения

    12.3. Механизмы управления кэшем

    12.4. Прямые предупреждения агента пользователя

    12.5. Исключения для правил и предупреждений

    12.6. Работа под управлением клиента

    12.7. Модель истечения срока годности

    12.7.1. Определение срока годности под управлением сервера

    12.7.2. Эвристический контроль годности

    12.7.3. Вычисление возраста

    12.7.4. Вычисление времени жизни (expiration)

    12.7.5. Устранение неопределенности значений времени жизни

    12.7.6 disambiguating multiple responses

    12.8. Модель проверки пригодности

    12.8.1. Даты последней модификации

    12.8.2. Валидаторы кэша для меток объектов (entity tag cache validators)

    12.8.3. Слабые и сильные валидаторы

    12.8.4. Правила того, когда использовать метки объекта и даты последней модификации

    12.8.5. Условия пригодности

    12.9. Кэшируемость отклика

    12.10. Формирование откликов кэшей

    12.10.1. Заголовки end-to-end (точка-точка) и hop-by-hop (шаг-за-шагом)

    12.10.2. Не модифицируемые заголовки

    12.10.3. Комбинирование заголовков

    12.10.4. Комбинирование байтовых фрагментов

    12.11. Кэширование согласованных откликов

    12.12. Кэши коллективного и индивидуального использования

    12.13. Ошибки и или поведение кэша при неполном отклике

    12.14. Побочные эффекты get и head

    12.15. Несоответствие после актуализации или стирания

    12.16. Обязательное прописывание (write-through mandatory)

    12.17. Замещения в кэше

    12.18. Списки предыстории

    4.5.6.1.13. Определения полей заголовка

    13.1. Поле accept

    13.2. Поле accept-charset

    13.3. Поле accept-encoding

    13.4. Поле accept-language

    13.5. Поле accept-ranges

    13.6. Поле age

    13.7. Поле allow

    13.8. Авторизация

    13.9. Поле cache-control

    13.9.1. Что допускает кэширование

    13.9.2. Что может быть запомнено в кэше

    13.9.3. Модификации базового механизма контроля времени жизни

    13.9.4. Управление перепроверкой пригодности и перезагрузкой

    13.9.5. Директива no-transform

    13.9.6. Расширения управления кэшем

    13.10. Соединение

    13.11. content-base

    13.12. Кодирование содержимого

    13.13. Язык содержимого

    13.14. Длина содержимого

    13.15. Поле content-location

    13.16. content-md5

    13.17. Отрывок содержимого

    13.18. Тип содержимого

    13.19. Дата

    13.20. Поле etag

    13.21. Поле expires

    13.22. Поле from

    13.23. Поле ЭВМ

    13.24. Поле if-modified-since

    13.25. Поле if-match

    13.26. Поле if-none-match

    13.27 Заголовок if-range

    13.28. Поле if-unmodified-since

    13.29. Поле last-modified

    13.30. Поле location

    13.31. Поле max-forwards

    13.32. Поле pragma

    13.33. Поле proxy-authenticate

    13.34. Поле proxy-authorization

    13.35. Поле public

    13.36. Фрагмент

    13.36.1. Фрагменты байт

    13.36.2. Запросы для получения фрагментов

    13.37. Поле referer

    13.38. Поле retry-after

    13.39. Поле server

    13.40. Поле transfer-encoding (Транспортное кодирование)

    13.41. Заголовок upgrade (Актуализация)

    13.42. Поле user-agent (Агент пользователя)

    13.43. Поле vary

    13.44. Поле via

    13.45. Поле warning (Предупреждение)

    13.46. Поле www-authenticate

    14.Соображения безопасности

    14.1. Идентификация клиентов

    14.2. Предложение выбора схемы идентификации

    14.3. Злоупотребление служебными (log) записями сервера

    14.4. Передача конфиденциальной информации

    14.5. Атаки, основанные на именах файлов и проходов

    14.6. Персональная информация

    14.7. Аспекты конфиденциальности, связанные с заголовками accept

    14.8. Фальсификация DNS

    14.9. Заголовки location и мистификация

    15. Ссылки

    16. Приложения

    16.1. Интернетовский тип среды "message/http"

    16.2. Тип среды Интернет "multipart/byteranges"

    16.3. Толерантные приложения

    16.4. Различие между объектами HTTP и mime

    16.4.1. Преобразование к канонической форме

    16.4.2. Преобразование форматов даты

    16.4.3. Введение кодирования содержимого

    16.4.4. no content-transfer-encoding

    16.4.5. Поля заголовка в многофрагментных телах

    16.4.6. Введение транспортного кодирования

    16.4.7. MIME-версия

    16.5. Изменения по отношению HTTP/1.0

    16.5.1. Изменения с целью упрощения распределенных WWW-сервером и экономии IP адресов

    16.6. Дополнительные функции

    16.6.1. Дополнительные методы запросов

    16.6.1.1. Метод patch

    16.6.1.2. Метод link

    16.6.1.3. Метод unlink

    16.6.2. Определения дополнительных полей заголовка

    16.6.2.1. Поле alternates

    16.6.2.2. Поле content-version

    16.6.2.3. Поле derived-from

    16.6.2.4. Поле link

    16.6.2.5. Поле uri

    16.7. Совместимость с предыдущими версиями

    16.7.1 Совместимость с постоянными соединениями HTTP/1.0

    16.7.1.1 Заголовок keep-alive

    Протокол передачи гипертекста HTTP является протоколом прикладного уровня для распределенных мультимедийных информационных систем. Это объектно-ориентированный протокол, пригодный для решения многих задач, таких как создание серверов имен, распределенных объектно-ориентированных управляющих систем и др.. Структура HTTP позволяет создавать системы, независящие от передаваемой информации.

    Протокол HTTP использован при построении глобальной информационной системы World-Wide Web (начиная с 1990).

    Первые версии, такие как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли являются последними.

    Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений сходен с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions).

    HTTP используется также в качестве базового протокола для коммуникации пользовательских агентов с прокси-серверами и другими системами Интернет, в том числе и использующие протоколы SMTP, NNTP, FTP, Gopher и Wais. Последнее обстоятельство способствует интегрированию различных служб Интернет. Ниже описаны базовые понятия и термины протокола HTTP.

    Прокси

    Промежуточная программа, которая выполняет функции, как сервера, так и клиента. Такая программа предназначена для обслуживания запросов так, как если бы это делал первичный сервер. Запросы обслуживаются внутри или переадресуются другим серверам.

    Туннель

    Промежуточная программа, которая работает как ретранслятор между двумя объектами. Туннель закрывается, когда обе стороны, соединенные им прерывают сессию. Туннель может быть активирован с помощью HTTP-запроса.

    Время пригодности объекта (expiration time)

    Время, при котором исходный сервер требует, чтобы объект не посылался более кэшем без перепроверки пригодности.

    Эвристическое значение времени жизни (heuristic expiration time)

    Время пригодности, присваиваемое объекту в кэше, если это время не задано явно.

    Возраст

    Возраст отклика - время с момента его посылки или проверки его пригодности исходным сервером.

    Время жизни (freshness lifetime)

    Продолжительность времени с момента генерации отклика до истечения его пригодности.

    Свежий

    Отклик считается свежим, если его возраст не превысил времени его пригодности.

    Устаревший

    Отклик считается устаревшим, когда его возраст превысил время жизни.

    Семантическая прозрачность

    Кэш по отношению к конкретному отклику функционирует в "семантически прозрачном" режиме, когда его использование не имеет последствий ни для исходного сервера, ни для запрашивающего клиента. Когда кэш семантически прозрачен, клиент получает в точности тот же отклик (за исключением транспортных заголовков), какой он бы получил при непосредственном обращении к исходному серверу.

    Валидатор

    Протокольный элемент (например, метка объекта или время last-modified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта.

    Метод

    Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.).

    Рис. 4.5.6.1.1. Взаимодействие клиента, кэша и исходного сервера в протоколе HTTP

    Кэш может находиться в ЭВМ клиента или агента пользователя, но может размещаться на соседнем континенте. Число прокси между клиентом и исходным сервером может варьироваться и ограничивается сверху только здравым смыслом.

    Рис. 4.5.6.1.2. Структура ресурса и объекта

    Протокол HTTP представляет собой протокол запросов-откликов. Клиент посылает запрос серверу в форме, определяющей метод, URI и версию протокола. В конце запроса следует MIME-подобное сообщение, содержащее модификаторы, информацию о клиенте и, возможно, другие данные. Сервер откликается, посылая статусную строку, которая включает в себя версию протокола, код результата (успех/неудача) и MIME-подобное сообщение, в котором содержатся данные о сервере и метаинформация.

    Большинство HTTP-обменов инициируются пользователем и состоят из запросов ресурсов, имеющихся на определенном сервере. В простейшем случае такой запрос может быть реализован путем соединения пользовательского агента (UA) и базового сервера.

    Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартные формы посредников: прокси, туннель и внешний порт (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) представляет собой приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка-точка и не производит каких-либо видоизменений сообщений. Туннель используется тогда, когда нужно пройти через какую-то систему (например, Firewall) в условиях, когда эта система не понимает (не анализирует) содержимое сообщений.

    Запрос -------------------------------------->
    
    UA -----v----- A -----v----- B -----v----- C -----v----- O
    <------------------------------------- отклик

    Рис. 4.5.6.1.3. UA - агент пользователя

    На рисунке показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A, и переадресовывать запросы к другим серверам кроме C.

    Любой участник обмена, который не используется в качестве туннеля, может воспользоваться кэшем для запоминания запросов. Буфер может сократить длину цепочки в том случае, если у одного из участников процесса имеется в буфере отклик для конкретного запроса, что может, кроме прочего, заметно снизить требования к пропускной способности канала. Не все запросы могут записываться в кэш, некоторые из них могут содержать модификаторы работы с кэшем.

    В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии прокси-серверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, распространяющие фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-системы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости.

    Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает использования HTTP поверх любого другого протокола в Интернет, или других сетей. HTTP предполагает надежное соединение; применим любой протокол, который может гарантировать корректную доставку сообщений.

    В HTTP/1.0, большинство приложений используют новое соединение для каждого обмена запрос/отклик. В HTTP/1.1, соединение может быть использовано для одного или более обменов запрос/отклик, хотя соединение может быть разорвано по самым разным причинам.

    4.5.6.1.1. Соглашения по нотации и общая грамматика
    1.1. Расширенные BNF

    Все механизмы, специфицированные в данном документе, описаны с использованием обычного текста и расширенных форм Бахуса-Наура BNF (Backus-Naur Form; см. RFC 822). Пользователи должны быть знакомы с этой нотацией для понимания данной спецификации. Расширение BNF включает в себя следующие конструкции:

    name = definition

    Имя правила не требует помещения в угловые скобки. Некоторые базовые правила записываются прописными буквами, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и пр.

    "literal"

    Двойные кавычки используются для выделения символьного текста.

    rule1 | rule2

    Элементы, разделенные вертикальной чертой, ("|") являются альтернативными, например, "yes | no" допускает yes или no (да или нет).

    (rule1 rule2)

    Элементы, помещенные в круглые скобки, рассматриваются как один элемент. Так, "(elem (foo | bar) elem)" допускают последовательности "elem foo elem" и "elem bar elem".

    *rule

    Символ "*", предшествующий элементу, указывает на повторение. Полная форма "*element" указывает как минимум на и как максимум повторений элемента. Значения по умолчанию равны 0 и бесконечности, так что "*( элемент)" позволяет любое число, включая ноль; "1*element" требует по меньшей мере один; а "1*2element" допускает один или два.

    [rule]

    В квадратные скобки заключаются опционные элементы; "[foo bar]" эквивалентно "*1(foo bar)".

    N rule

    Специальный повтор: "(элемент)" эквивалентно "*(элемент)"; то есть, точно (element). Таким образом, 2DIGIT является 2-значным числом, а 3ALPHA представляет собой строку из трех буквенных символов.

    #rule

    Конструкция "#" определена подобно "*", для описания списка элементов. Полная форма имеет вид "#element ", отмечая, по меньшей мере и по большей элементов, отделенных друг от друга одной или более запятыми (",") и опционно строчным пробелом (LWS - Linear White Space). Это делает обычную форму списков очень простой. Запись "( *LWS элемент *( *LWS "," *LWS элемент)) " может быть представлена как "1#element". Всюду, где используется эта конструкция, допускаются нулевые элементы, но они не учитываются при подсчете элементов. То есть, допускается запись "(элемент), (элемент) ", но число элементов при этом считается равным двум. Следовательно, там, где необходим хотя бы один элемент, должен присутствовать, по крайней мере, один ненулевой элемент. Значениями по умолчанию являются 0 и бесконечность, таким образом "#элемент" позволяет любое число, включая нуль; "1#элемент" требует, по меньшей мере один, а "1#2элемент" допускает один или два.

    ; комментарий

    Точка с запятой, смещенная вправо от линейки текста, открывает комментарий, который продолжается до конца строки. Это простой способ включения замечаний в текст спецификаций.

    implied *LWS

    Грамматика, описанная в данной спецификации, ориентирована на слова. Если не оговорено обратное, строчный пробел (LWS) может быть заключен между любыми двумя соседними словами (лексема или заключенная в кавычки строка), и между смежными лексемами (token) и разделителями (TSpecials) без изменения интерпретации поля. По крайней мере один разграничитель (TSpecials) должен присутствовать между любыми двумя лексемами, так как они иначе будут интерпретироваться как одна.

    1.2. Основные правила

    Следующие правила используются практически во всей спецификации для описания основных конструкций разбора (парсинга).

    OCTET

    = <любая 8-битовая последовательность данных>

    CHAR

    = <любой символ US-ASCII (октеты 0 - 127)>

    UPALPHA

    = <любая прописная буква US-ASCII "A".."Z">

    LOALPHA

    = < любая строчная буква US-ASCII "a".."z">

    ALPHA

    = UPALPHA | LOALPHA (строчная или прописная буква)

    DIGIT

    = <любая цифра US-ASCII "0".."9">

    CTL

    = <любой управляющий символ US-ASCII (октеты 0 - 31) и DEL (127)>

    CR

    =

    LF

    =

    SP

    =

    HT

    =

    <">

    =

    HTTP/1.1 определяет последовательность CR LF, как маркер конца для всех протокольных элементов, за исключением тела элемента. Маркер конца строки в пределах тела объекта определен соответствующим типом среды.

    CRLF

    = CR LF

    HTTP/1.1 заголовки могут занимать несколько строк, если продолжение строки начинается с пробела или символа горизонтальной табуляции. Все строчные пробелы имеют ту же семантику, что и обычный пробел (SP).

    LWS

    = [CRLF] 1*( SP | HT )

    Правило TEXT используется только для содержимого описательных полей и значений, которые не предполагается передавать интерпретатору сообщений. Слова *TEXT могут содержать символы из символьного набора, не совпадающего с ISO 8859-1 [22], только когда они закодированы согласно правилам RFC-1522 [14].

    TEXT

    = <любой OCTET за исключением CTL, но включая LWS>

    В некоторых протокольных элементах используются шестнадцатеричные цифровые символы.

    HEX

    = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

    Многие значения полей заголовков HTTP/1.1 состоят из слов, разделенных LWS или специальными символами. Эти специальные символы должны представлять собой строки, заключенные в кавычки, чтобы использоваться в качестве значения параметра.

    Token

    = 1*<любой CHAR за исключением CTLs или tspecials>

    Tspecials

    = "(" | ")" | "<" | ">" | "@"

    | "," | ";" | ":" | "\" | <">

    | "/" | "[" | "]" | "?" | "="

    | "{" | "}" | SP | HT

    Комментарии могут быть включены в некоторые поля HTTP заголовков, при этом текст комментария заключается в скобки. Комментарии допустимы только для полей, содержащих "comment", как часть описания поля. В других полях скобки рассматриваются как элемент содержимого поля.

    Комментарий

    = "(" *( ctext | комментарий) ")"

    ctext

    = <любой TEXT, исключая "(" и ")">

    Строка текста воспринимается как одно слово, если она помещена в двойные кавычки.

    quoted-string

    = ( <"> *(qdtext) <"> )

    qdtext

    = <любой TEXT, исключая <">>

    Символ обратная косая черта ("\") может использоваться вместо кавычки внутри закавыченного текста или в структурах комментариев.

    quoted-pair

    = "\" CHAR

    4.5.6.1.2. Параметры протокола
    2.1. Версия HTTP

    HTTP использует схему нумерации "." для отображения версии протокола. Политика присвоения версии протоколу ориентирована на то, чтобы позволить отправителю указать формат сообщения и его емкость. Номер версии не меняется при добавлении компонент сообщения, которые не влияют на характер обмена.

    Число увеличивается, когда в протокол внесены изменения, которые не изменили общий алгоритм разбора сообщений, но которые изменили семантику сообщений и добавили новые возможности отправителю. Число увеличивается в случае, когда изменен формат протокольного сообщения.

    Версия HTTP-сообщения указывается в поле HTTP-Version в первой строке сообщения.

    HTTP

    Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

    Заметьте, что числа major и minor должны рассматриваться как независимые целые, так что каждое из них может быть увеличено за пределы одной цифры. Таким образом, HTTP/2.4 является более низкой версией, чем HTTP/2.13, которая в свою очередь ниже, чем HTTP/12.3. Начальные нули должны игнорироваться и не пересылаться

    Приложения, посылающие запросы или отклики, так как это определено в спецификации, должны включать HTTP-Version "HTTP/1.1". Использование этого номера версии указывает, что посылающее приложение совместимо с этой спецификацией.

    Версия HTTP приложения является верхней, совместимость с которой гарантируется. Приложения прокси-серверов и сетевых портов должны проявлять осторожность при переадресации сообщений с протокольной версией, отличной от поддерживаемой ими. Так как версия протокола указывает на возможности отправителя, прокси никогда не должны пересылать сообщения с версией больше, чем их собственная; если получено сообщение более высокой версии, прокси/порт должен либо понизить версию запроса, либо послать отклик об ошибке или переключиться в режим туннеля. Запросы с версией ниже, чем у прокси/порта могут быть повышены при переадресации, при этом major часть версии сервера и запроса должны совпадать.

    Замечание: Преобразование между версиями может включать модификацию полей заголовка.

    2.2. Универсальные идентификаторы ресурсов (URI)

    URI известен под многими именами: WWW адрес, универсальный идентификатор документа (Universal Document Identifiers), универсальный идентификатор ресурса (Universal Resource Identifiers), и, наконец, универсальный локатор ресурса URL (Uniform Resource Locators; тождество URI и URL сомнительно, так как URL является частным случаем URI (примечание переводчика)) и универсальное имя ресурса (URN). Что касается HTTP, универсальный идентификатор ресурса представляет собой форматированную строку символов, которая идентифицирует имя, положение или какие-то еще характеристики ресурса.

    2.2.1. Общий синтаксис

    URI в HTTP может быть представлен в абсолютной или относительной форме по отношению к некоторому известному базовому URI, в зависимости от контекста его использования. Эти две формы отличаются тем, что абсолютный URI всегда начинается с имени схемы, за которым следует двоеточие (например HTTP: или FTP:).

    URI

    = ( absoluteURI | relativeURI ) [ "#" фрагмент ]

    AbsoluteURI

    = схема ":" *( uchar | reserved )

    RelativeURI

    = net_path | abs_path | rel_path

    net_path

    = "//" net_loc [ abs_path ]

    abs_path

    = "/" rel_path

    rel_path

    = [ проход ] [ ";" params ] [ "?" query ]

    path

    = fsegment *( "/" сегмент )

    fsegment

    = 1*pchar

    segment

    = *pchar

    params

    = param *( ";" param )

    param

    = *( pchar | "/" )

    scheme

    = 1*( ALPHA | DIGIT | "+" | "-" | "." )

    net_loc

    = *( pchar | ";" | "?" )

    query

    = *( uchar | reserved )

    fragment

    = *( uchar | reserved )

    pchar

    = uchar | ":" | "@" | "&" | "=" | "+"

    uchar

    = unreserved | escape

    unreserved

    = ALPHA | DIGIT | safe | extra | national

    escape

    = "%" HEX HEX

    reserved

    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"

    extra

    = "!" | "*" | "'" | "(" | ")" | ","

    safe

    = "$" | "-" | "_" | "."

    unsafe

    = CTL | SP | <"> | "#" | "%" | "<" | ">"

    national

    = <любой OCTET, исключая ALPHA, DIGIT, зарезервированный, extra, safe, и unsafe>

    Более детальную информацию о синтаксисе и семантике URL можно найти в RFC-1738 [4] и RFC-1808 [11]. Приведенные выше BNF включают в себя национальные символы, недопустимые в URL, так как это специфицировано в RFC 1738, так как серверам HTTP не запрещено использование любых наборов символов, допустимых в rel_path частях адресов, HTTP-прокси могут получить запросы URI, не определенные в рамках RFC-1738.

    Протокол HTTP не устанавливает каких-либо ограничений на длину URI. Серверы должны быть способны обрабатывать URI любых ресурсов, имеющих любую длину. Сервер должен выдать отклик 414 (Request-URI Too Long - URI запроса слишком длинен), если URI длиннее, чем может обработать сервер (см. раздел 9.4.15).

    Замечание: Серверы должны избегать использования URI длиннее 255 байт, так как некоторые старые клиенты или прокси-приложения не могут корректно работать с такими длинами.

    2.2.2. HTTP URL

    Схема "HTTP" используется для локализации сетевых ресурсов с помощью протокола HTTP. Далее определены синтаксис и семантика HTTP URL, зависящие от схемы.

    http_URL

    = "http:" "//" host [ ":" port ] [ abs_path ]

    host

    = <Легальное имя ЭВМ в Интернет или IP-адрес (в точечно-цифровой форме), как это определено в разделе 2.1 RFC 1123>

    port

    = *DIGIT

    Если номер порта не указан, предполагается порт 80. Семантика устроена так, что идентифицированный ресурс размещается на сервере, который ожидает TCP-соединения через порт данной ЭВМ, а Request-URI для ресурса находится в abs_path. Использование IP адресов в URL следует избегать всюду, где это возможно (см. RFC-1900 [24]). Если abs_path в URL отсутствует, он должен считаться равным "/", в случае, если он используется в качестве Request-URI для ресурса (раздел 4.1.2).

    2.2.3. Сравнение URI

    При сравнении двух URI с целью проверки их идентичности, клиент должен использовать по октетное сравнение с учетом регистра, в котором напечатаны символы. Допускаются следующие исключения:

    • Номер порта не указан, тогда для данного URI берется значение по умолчанию;
    • Сравнение имен ЭВМ и схем не должно быть чувствительным к строчным/прописным буквам;
    • Пустой abs_path эквивалентен abs_path "/".

    Символы, отличные от типов "reserved" и "unsafe" устанавливаются равными их эквивалентам в кодировке ""%" HEX HEX".

    Например, следующие три URI являются эквивалентными:

    http://abc.com:80/~smith/home.html
    http://ABC.com/%7Esmith/home.html
    http://ABC.com:/%7Esmith/home.html

    3.3. Форматы даты/времени
    3.3.1. Полная дата

    HTTP приложения допускают три различных формата для представления метки времени и даты:

    Sun, 06 Nov 1994 08:49:37 GMT ; RFC-822, актуализировано в RFC-1123
    Sunday, 06-Nov-94 08:49:37 GMT ; RFC-850, объявлено устаревшим в RFC-1036
    Sun Nov 6 08:49:37 1994 ; ANSI C's ASCtime() format

    Первый формат предпочтительнее, как стандарт Интернет и представляет собой форму фиксированной длины, определенную RFC-1123. Второй формат используется достаточно широко, но базируется на устаревшем документе RFC-850 [12], формат даты не имеет 4 цифр года. Клиенты и серверы HTTP/1.1, которые анализируют дату, должны уметь работать со всеми тремя форматами (для совместимости с HTTP/1.0), хотя они должны сами генерировать время/дату согласно формату RFC-1123.

    Замечание: Получатели значений даты должны быть готовы принять коды, которые посланы не приложениями HTTP, что случается, когда данные поступают через прокси/порты или по почте в SMTP- или NNTP-форматах.

    Все марки времени/даты HTTP должны соответствовать времени по Гринвичу (GMT). Это указано в первых двух форматах путем включения строки "GMT" и должно предполагаться во всех прочих случаях.

    HTTP-date

    = RFC-1123-date | rRFC-850-date | asctime-date

    RFC-1123-date

    = wkday "," SP date1 SP time SP "GMT"

    RFC-850-date

    = weekday "," SP date2 SP time SP "GMT"

    asctime-date

    = wkday SP date3 SP time SP 4DIGIT

    date1

    = 2DIGIT SP month SP 4DIGIT

    ; day month year (e.g., 02 Jun 1982)

    date2

    = 2DIGIT "-" month "-" 2DIGIT

    ; day-month-year (e.g., 02-Jun-82)

    date3

    = month SP ( 2DIGIT | ( SP 1DIGIT ))

    ; month day (e.g., Jun 2)

    time

    = 2DIGIT ":" 2DIGIT ":" 2DIGIT

    ; 00:00:00 - 23:59:59

    wkday

    = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"

    weekday

    = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday"

    month

    = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

    Замечание: HTTP требования для формата метки даты/времени применимы только для использования в рамках реализации самого протокола. Клиенты и сервера не требуют применения этих форматов для пользовательских презентаций, протоколирования запросов и т.д..

    2.3.2. Интервалы времени в секундах

    Некоторые поля заголовка HTTP допускают спецификацию значения времени в виде целого числа секунд, представленного в десятичной форме и равного времени с момента получения сообщения.

    delta-seconds = 1*DIGIT

    2.4. Наборы символов

    HTTP использует то же определение термина "набор символов", что дано для MIME:

    Термин "набор символов", используемый в данном документе, относится к методу, который с помощью одной или более таблиц преобразует последовательность октетов в последовательность символов. Заметьте, что не требуется безусловное обратное преобразование, при этом не все символы могут быть доступны и одному и тому же символу может соответствовать более чем одна последовательность октетов. Это определение имеет целью допустить различные виды кодировок символов, от простых однотабличных, таких как US-ASCII, до сложных - таблично переключаемых методов, используемых, например, в ISO 2022. Однако, определение, связанное с набором символов MIME, должно полностью специфицировать схему соответствия октетов и символов. Использование внешних профайлов для определения схемы шифрования не допустимо.

    Замечание. Здесь "набор символов" ближе к понятию "кодирование символов". Однако так как HTTP и MIME используют один и тот же регистр, важно, чтобы терминология также была идентичной.

    Наборы символов HTTP идентифицируются лексемами, которые не чувствительны к использованию строчных или прописных букв. Полный набор лексем определен регистром наборов символов IANA [19].

    charset = token

    Несмотря на то, что HTTP позволяет использовать произвольную лексему в качестве значения charset, любая лексема, значение которой определено в рамках регистра набора символов IANA, должна представлять символьный набор, определенный этим регистром. Приложение должно ограничить использование символьных наборов только теми, которые определены регистром IANA.

    2.5. Кодировки содержимого

    Значения кодировки содержимого указывают на кодовое преобразование, которое было или может быть выполнено над объектом. Кодировки содержимого первоначально применены для того, чтобы иметь возможность архивировать документ или преобразовать его каким-то другим способом без потери идентичности или информации. Часто объект запоминается закодированным, передается и только получателем декодируется.

    content-coding = token

    Все значения кодировок содержимого не зависят от того, используются строчные или прописные символы. HTTP/1.1 использует значения кодировок содержимого в полях заголовка Accept-Encoding (раздел 13.3) и Content-Encoding (раздел 13.12). Хотя значение описывает кодирование содержимого, более важным является то, что оно определяет механизм декодирования.

    Комитет по стандартным числам Интернет IANA (Internet Assigned Numbers Authority) выполняет функции регистра для значений лексем кодирования содержимого, этот регистр хранит следующие лексемы:

    gzip

    Формат кодирования, реализуемый программой архивации файлов "gzip" (GNU zip), как описано в RFC 1952 [25]. Этот формат соответствует кодированию Lempel-Ziv (LZ77) с 32 битным CRC.

    compress

    Формат кодирования, реализуемый стандартной программой UNIX для архивации файлов "compress". Этот формат соответствует адаптивному методу кодирования Lempel-Ziv-Welch (LZW).

    Замечание: Использование имен программ для идентификации форматов кодирования не является желательным и будет в будущем заменено. Их использование здесь является следствием исторической практики. Для совместимости с предшествующими реализациями HTTP, приложения должны считать "x-gzip" и "x-compress" эквивалентными "gzip" и "compress" соответственно.

    deflate

    Формат "zlib" определен документом RFC 1950 [31] в комбинации с механизмом сжатия "deflate", описанным в RFC 1951 [29].

    Новые значения лексем кодирования содержимого должны регистрироваться. Для обеспечения взаимодействия между клиентами и серверами спецификации алгоритмов кодирования содержимого должны быть общедоступны.

    2.6. Транспортное кодирование

    Значения транспортного кодирования используются для определения кодового преобразования, которому был подвергнут или желательно подвергнуть объект для того, чтобы гарантировать безопасную его транспортировку через сеть. Этот вид преобразования отличен от кодирования содержимого, так как относится к сообщению, а не исходному объекту.

    Transfer-coding

    = "chunked" | transfer-extension

    Transfer-extension

    = token

    Все значения транспортного кодирования не зависят от того, строчные или прописные буквы здесь использованы. HTTP/1.1 несет значения транспортного кодирования в поле заголовка Transfer-Encoding (раздел 13.40).

    Транспортные кодировки аналогичны используемым значениям Content-Transfer-Encoding MIME, которые были введены для обеспечения безопасной передачи двоичных данных через 7-битную транспортную среду. Однако безопасная транспортировка имеет другие аспекты в рамках 8-битного протокола передачи сообщений. В HTTP, единственной небезопасной характеристикой тела сообщения является неопределенность его длины (раздел 6.2.2), или желание зашифровать данные при передаче по общему каналу.

    Блочное кодирование фрагментов модифицирует тело сообщения для того, чтобы передать его в виде последовательности пакетов, каждый со своим индикатором размера, за которым следует опционная завершающая запись (footer), содержащая поля заголовка объекта. Это позволяет передать динамически сформированное содержимое, снабдив его необходимой информацией для получателя, который, в конце концов, сможет восстановить все сообщение.

    Chunked

    Body = *chunk "0" CRLF footer CRLF

    Chunk

    = chunk-size [ chunk-ext ] CRLF chunk-data CRLF

    Hex-no-zero

    =

    Chunk-size

    = hex-no-zero *HEX

    Chunk-ext

    = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )

    Chunk-ext-name

    = token

    Chunk-ext-val

    = token | quoted-string

    Chunk-data

    = chunk-size(OCTET)

    footer

    = *entity-header

    Блочное кодирование фрагментов завершается пакетом нулевой длины, за которыми следует завершающая запись и пустая строка. Назначение завершающей записи заключается в том, чтобы дать информацию о динамически сформированном объекте; приложения не должны пересылать поля заголовка в завершающей записи, кроме тех, которые специально оговорены, например, такие как Content-MD5 или будущие расширения HTTP для цифровой подписи. Пример процесса такого кодирования представлен в приложении 16.4.6.

    Все приложения HTTP/1.1 должны быть способны получать и декодировать получаемые фрагменты ("chunked"-кодирование), и должны игнорировать расширения транспортного кодирования, которые они не понимают. Сервер, получающий тело объекта с транспортной кодировкой, которую он не понимает, должен отослать отклик c кодом 501 (Unimplemented - не применимо), и закрыть соединение. Сервер не должен использовать транспортное кодирование при посылке данных клиенту HTTP/1.0.

    2.7. Типы среды

    HTTP использует типы среды Интернет (Internet Media Types) в полях заголовка Content-Type (раздел 13.18) и Accept (раздел 13.1) для того, чтобы обеспечить широкий и открытый обмен с самыми разными типа среды.

    Media-type

    = type "/" subtype *( ";" parameter )

    type

    = token

    subtype

    = token

    Параметры могут следовать за type/subtype в форме пар атрибут/значение.

    Parameter

    = attribute "=" value

    attribute

    = token

    value

    = token | quoted-string

    Имена типа, субтипа и атрибутов параметра могут набираться, как строчными, так и прописными буквами. Значения параметров могут быть и чувствительны к используемому регистру, в зависимости от семантики и имени параметра. Строчный пробел (LWS) не должен использоваться ни между типом и субтипом, ни между атрибутом и значением. Агенты пользователя, которые распознают тип среды, должны обрабатывать (или обеспечить обработку с использованием внешнего приложения для работы агента пользователя с типом/субтипом) параметры для типа MIME так, как это описано для данного типа/субтипа, и информировать пользователя о любых возникающих проблемах.

    Замечание. Некоторые старые приложения HTTP не узнают параметры типа среды. При посылке данных старому HTTP-приложению, программы должны использовать параметры типа среды, только когда они необходимы по описанию типа/субтипа. Значения типа среды регистрируются IANA (Internet Assigned Number Authority). Процесс регистрации типа среды описан в RFC 2048 [17]. Использование незарегистрированных типов среды настоятельно не рекомендуется.

    2.7.1. Канонизация и текст по умолчанию

    Типы среды Интернет регистрируются каноническим образом. Вообще, тело объекта, передаваемого с помощью HTTP сообщений, должно быть представлено соответствующим каноническим способом, прежде чем будет послано, исключение составляет тип "text", как это описано в следующем параграфе.

    В случае канонической формы субтип среды "text" использует CRLF для завершения строки текста. HTTP ослабляет это требование и позволяет передавать текст, используя просто CR или LF, представляющие разрыв строки. HTTP приложения должны воспринимать CRLF, "голое" CR и LF как завершение строки для текстовой среды полученной через HTTP. Кроме того, если текст представлен в символьном наборе, где нет октетов 13 и 10 для CR и LF соответственно, как это имеет место в случае мультибайтных символьных наборов, HTTP позволяет использовать соответствующие символьные представления для CR и LF. Эта гибкость в отношении разрыва строк относится только к текстовой среде в теле объекта; CR или LF не должны подставляться вместо CRLF в любые управляющие структуры HTTP (такие как поля заголовка).

    Если тело объекта закодировано с помощью Content-Encoding, исходные данные, прежде чем подвергнуться кодированию должны были иметь форму, указанную выше.

    Параметр "charset" используется с некоторыми типами среды, чтобы определить символьный набор (раздел 2.4). Когда параметр charset не задан отправителем явно, субтип среды "text" определяется так, что используется символьный набор по умолчанию "ISO-8859-1". Данные с набором символов, отличным от "ISO-8859-1" или его субнабора, должны помечаться соответствующим значением charset.

    Некоторые программы HTTP/1.0 интерпретируют заголовок Content-Type без параметра charset, неправильно предполагая, что "получатель должен решить сам, какой это набор". Отправители, желающие заблокировать такое поведение, могут включать параметр charset, даже когда charset равен ISO-8859-1 и должны делать так, когда известно, что это не запутает получателя.

    К сожалению, некоторые старые HTTP/1.0 клиенты не обрабатывают корректно параметр charset. HTTP/1.1 получатели должны учитывать метку charset, присланную отправителем, и те агенты пользователя, которые умеют делать предположение относительно символьного набора, должны использовать символьный набор из поля content-type, если они поддерживают этот набор, а не набор, предпочитаемый получателем.

    2.7.2. Составные типы

    MIME обеспечивает нескольких составных типов - инкапсуляция одного или более объектов в общее тело сообщения. Все составные типы имеют общий синтаксис, как это определено в MIME [7], и должны включать граничный параметр, являющийся частью значения типа среды. Тело сообщения является само протокольным элементом и, следовательно, должно использовать только CRLF для обозначения разрывов строки. В отличии от MIME, завершающая часть любого составного cообщения должна быть пустой. HTTP приложения не должны передавать завершающую часть (даже если исходное составное сообщение содержит такую завершающую часть (эпилог-подпись).

    В HTTP, составляющие части тела могут содержать поля заголовка, которые существенны для значения этих частей. Рекомендуется, чтобы поле заголовка Content-Location (раздел 13.15) было включено в часть тела каждого вложенного объекта, который может быть идентифицирован URL.

    Вообще, рекомендуется, чтобы агент пользователя HTTP имел идентичное или схожее поведение с агентом пользователя MIME при получении составного типа. Если приложение получает неузнаваемый составной субтип, оно должно обрабатывать его также как "multipart/mixed".

    Замечание: Тип "multipart/form-data" специально определен для переноса данных совместимого с методом обработки почтовых запросов, как это описано в RFC 1867 [15].

    2.8. Лексемы (token) продукта

    Лексемы продукта служат для того, чтобы позволить взаимодействующим приложениям идентифицировать себя с помощью имени и версии программного продукта. Большинство полей, использующих лексемы продукта допускают также включение в список субпродуктов, которые образуют существенную часть приложения, их лексемы отделяются пробелом. По договоренности, продукты перечисляются в порядке их важности для идентификации приложения.

    Product

    = token ["/" product-version]

    Product-version

    = token

    Примеры:

    User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    Server: Apache/0.8.4

    Лексемы продукта должны быть короткими и, кроме того, использование их для оповещения или передачи маловажной информации абсолютно запрещено. Хотя любой символ лексемы может присутствовать в версии продукта, рекомендуется, чтобы эта лексема использовалась только для идентификации версии (то есть, последовательные версии одного и того же продукта должны отличаться только в части версии продукта).

    2.9. Значения качества (Quality values)

    HTTP согласование параметров содержимого (раздел 12) использует короткие числа с плавающей запятой для указания относительной важности (веса) различных согласуемых параметров. Вес нормализуется на истинное число в диапазоне 0 - 1, где 0 равен минимальному, а 1 максимальному значению. Приложения HTTP/1.1 не должны генерировать более трех чисел после запятой. Рекомендуется, чтобы конфигурация пользователя для этих значений удовлетворяла тем же ограничениям.

    qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )

    "Quality values" (значения качества) является неверным названием, так как эти значения в большей степени отражают относительную деградацию желательного качества.

    2.10. Языковые метки

    Языковая метка идентифицирует естественный язык. Компьютерные языки в этот перечень не входят. HTTP использует языковые метки в полях Accept-Language и Content-Language.

    Синтаксис и регистр языковых меток HTTP тот же, что и определенный в RFC 1766 [1]. Языковая метка содержит одну или более частей: первичная языковая метка и последовательность субметок, которая может и отсутствовать:

    language-tag

    = primary-tag *( "-" sub-tag )

    primary-tag

    = 1*8ALPHA

    sub-tag

    = 1*8ALPHA

    Пробел не допустим в метке, применение строчных и прописных букв не играет никакой роли. Перечень языковых меток контролируется IANA. Ниже приведены примеры языковых меток:

    en, en-US, en-cockney, i-cherokee, x-pig-latin

    где любые две буквы первичной метки представляют собой языковую аббревиатуру ISO 639 и две буквы исходной субметки соответствуют коду страны ISO 3166 (последние три метки не являются зарегистрированными; все кроме последней могут быть зарегистрированы в будущем).

    2.11. Метки объектов

    Метки объектов служат для сравнения двух или более объектов из одного и того же запрошенного ресурса. HTTP/1.1 использует метки объектов в полях заголовков ETag (раздел 13.20), If-Match (раздел 13.25), If-None-Match (раздел 13.26) и If-Range (раздел 13.27). Метки объекта состоят из строк, заключенных в кавычки, перед ней может размещаться индикатор слабости.

    entity-tag

    = [ weak ] opaque-tag

    Weak

    = "W/"

    opaque-tag

    = quoted-string

    "Сильная метка объекта" (strong entity tag) может принадлежать двум объектам ресурса, если они эквивалентны на октетном уровне.

    "Слабая метка объекта " (weak entity tag) отмечается префиксом "W/", может относиться к двум объектам ресурса, только если объекты эквивалентны и могут быть взаимозаменяемы. Слабая метка объекта может использоваться для "слабого" сравнения.

    Метка объекта должна быть уникальной для всех версий всех объектов, сопряженных с конкретным ресурсом. Значение данной метки объекта может использоваться для объектов, полученных в результате запросов для различных URI без использования данных об эквивалентности этих объектов.

    2.12. Структурные единицы

    HTTP/1.1 позволяет клиенту запросить только часть объекта (диапазон). HTTP/1.1 использует структурные единицы, определяющие выделение части объекта, в полях заголовка Range (раздел 13.36) и Content-Range (раздел 13.17). Объект может быть разбит на фрагменты с использованием различных структурных единиц.

    range-unit

    = bytesunit | other-range-unit

    bytes-unit

    = "bytes"

    other-range-unit

    = token

    Единственной структурной единицей, определенной в HTTP/1.1, является "bytes". HTTP/1.1 реализации могут игнорировать диапазоны, специфицированные с использованием других структурных единиц. HTTP/1.1 сконструирован так, чтобы позволить реализацию приложений, которые не зависят от знания диапазонов.

    4.5.6.1.3. HTTP сообщение
    3.1. Типы сообщений

    Сообщения HTTP включают в себя запросы клиента к серверу и отклики сервера клиенту.

    HTTP-message = Request | Response ; HTTP/1.1 messages

    Сообщения запрос (раздел 5) и отклик (раздел 6) используют общий формат сообщений RFC-822 [9] для передачи объектов (поле данных сообщения). Оба типа сообщений состоят из стартовой строки, одного или более полей заголовка (также известные как "заголовки"), пустой строки (то есть, строка, содержащая CRLF), отмечающей конец полей заголовка, а также опционного тела сообщения.

    generic-message = start-line
    *message-header
    CRLF
    [ message-body ]
    start-line = Request-Line | Status-Line

    В интересах надежности, рекомендуется серверам игнорировать любые пустые строки, полученные, когда ожидается Request-Line (строка запроса). Другими словами, если сервер читает протокольный поток в начале сообщения и получает сначала CRLF, он должен игнорировать CRLF.

    Замечание: Определенные не корректные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Клиент HTTP/1.1 не должен посылать CRLF до или после запроса.

    3.2. Заголовки сообщений

    Поля заголовка HTTP, которые включают в себя поля общего заголовка (раздел 3.5), заголовка запроса (раздел 4.3), заголовка отклика (раздел 6.2), и заголовка объекта (раздел 6.1), следуют тому же общему формату, что дан в разделе 3.1 RFC 822 [9]. Каждое поле заголовка состоит из имени, за которым следует двоеточие (":"), и поля значения. Поля имен безразличны в отношении использования строчных и прописных букв. Поле значения может начинаться с любого числа LWS, хотя один SP предпочтительнее. Поля заголовка могут занимать несколько строк, каждая новая строка должна открываться, по крайней мере, одним SP или HT. Рекомендуется, чтобы приложения следовали общему формату, если они создаются конструкциями HTTP, так как могут существовать некоторые реализации, которые не могут воспринимать ничего кроме общих форматов.

    Message-header

    = field-name ":" [ field-value ] CRLF

    field-name

    = token

    field-value

    = *( field-content | LWS )

    field-content = < OCTET'ы образуют значения поля и состоят из *TEXT или комбинаций лексем, tspecials и закавыченных строк >

    Порядок, в котором приходят поля заголовка с отличающимися именами, не играет значения. Однако, хорошей практикой считается посылка сначала поля общего заголовка, за которым следует заголовок запроса или отклика, а в заключение поля заголовка объекта.

    Множественные поля заголовка сообщения с идентичными именами могут присутствовать тогда и только тогда, когда значение поля определяется как список из элементов, разделенных запятыми [то есть, #(значения)]. Должна быть предусмотрена возможность объединять множественные поля заголовка в одну пару "имя_поля: значение_поля", без изменения семантики сообщения, путем добавления каждой последующей пары поле-значение, отделенных друг от друга запятыми. Порядок, в котором следуют поля заголовка с идентичными именами, влияет на последующую интерпретацию значения комбинированного поля, по этой причине прокси-сервер не должен менять порядок значений этих полей при переадресации сообщения.

    3.3. Тело сообщения

    Тело сообщения HTTP (если имеется) используется для переноса тела объекта, сопряженного с запросом или откликом. Тело сообщения отличается от тела объекта, только когда используется транспортное кодирование, как это указано в поле заголовка Transfer-Encoding (раздел 13.40).

    message-body = entity-body
    |

    Transfer-Encoding должно использоваться для указания любого транспортного кодирования, реализованного приложением с целью гарантированной неискаженной доставки сообщения. Транспортное кодирование лежит в зоне ответственности сообщения, а не объекта и по этой причине может быть реализовано любым приложением в цепочке запрос/отклик.

    Присутствие тела сообщения в запросе отмечается с помощью включения полей заголовка Content-Length или Transfer-Encoding в заголовки сообщений-запросов. Тело сообщения может быть включено в запрос, только когда метод запроса допускает наличие тела объекта (раздел 4.1.1).

    Для сообщений-откликов включение в них тела сообщения зависит от метода запроса и статусного кода отклика (раздел 5.1.1). Все отклики в случае метода запроса HEAD не должны включать тела сообщения, даже если присутствуют поля заголовка объекта, позволяющие предположить его присутствие. Все отклики 1xx (информационные), 204 (никакого содержимого) и 304 (не модифицировано) не должны включать тела сообщения. Все другие отклики включают в себя тело сообщения, хотя оно может иметь и нулевую длину.

    3.4. Длина сообщения

    Когда тело включено в сообщение, его длина определяется следующим образом (в порядке приоритета):

    1. Любое сообщение-отклик, которое не должно включать в себя тело сообщения (такое как отклик 1xx, 204 и 304, а также любые отклики на запрос HEAD) всегда завершаются первой пустой строкой после полей заголовка, вне зависимости от присутствующих в сообщении полей заголовка объекта.

    2. Если присутствует поле заголовка Transfer-Encoding (раздел 13.40) и указано, что использовано по фрагментное ("chunked") транспортное кодирование, тогда длина тела определяется выбранной схемой кодирования (раздел 2.6).

    3. Если присутствует поле заголовка Content-Length (раздел 13.14), его значение в байтах и определяет длину тела сообщения.

    4. Если сообщение использует тип cреды "multipart/byteranges", который является самоограничивающим, тогда он и определяет длину. Этот тип среды не должен использоваться, если отправитель не знает, может ли получатель разобрать его. Присутствие в запросе заголовка Range с множественными спецификаторами диапазона подразумевает, что клиент может разобрать отклики типа multipart/byteranges.

    5. Определяется сервером при закрытии связи. (Закрытие соединения не может использоваться для обозначения конца тела запроса, так как это не оставит возможности для сервера послать отклик.)

    Для совместимости с приложениями HTTP/1.0, запросы HTTP/1.1, содержащие тело запроса, должны включать корректное поле заголовка Content-Length. Если запрос содержит тело сообщения, а поле Content-Length отсутствует, рекомендуется, чтобы сервер реагировал откликом 400 (плохой запрос), если он не может определить длину сообщения, или 411 (необходима длина), если он настаивает на получении корректного поля Content-Length.

    Все приложения HTTP/1.1, которые получают объект (entity) должны понимать блочное ("chunked") транспортное кодирование (раздел 2.6), таким образом, разрешая использование этого механизма для сообщений, когда длина сообщения не может быть определена заранее.

    Сообщения не должны включать поле заголовка Content-Length и блочное транспортное кодирование одновременно. Если такое сообщение получено, поле Content-Length должно игнорироваться.

    Когда в сообщении присутствует поле Content-Length и разрешено наличие тела сообщения, его значение поля должно строго соответствовать числу октетов в теле сообщения. Агенты пользователя HTTP/1.1 должны оповещать пользователя, если получено сообщение некорректной длины.

    3.5. Общие поля заголовка

    Существует несколько полей заголовка, которые имеют применимость, как для запросов, так и откликов, но которые не используются для передачи объектов. Эти поля заголовков служат только для пересылаемых сообщений.

    general-header

    = Cache-Control

    ; Раздел 13.9

    | Connection

    ; Раздел 13.10

    | Date

    ; Раздел 13.19

    | Pragma

    ; Раздел 13.32

    | Transfer-Encoding

    ; Раздел 13.40

    | Upgrade

    ; Раздел 13.41

    | Via

    ; Раздел 13.44

    Имена полей общего заголовка могут быть расширены только при изменении версии протокола. Однако, новые или экспериментальные поля заголовка могут использоваться при условии, если партнеры обмена способны их распознавать, как поля общего заголовка. Не узнанные поля заголовка считаются полями заголовка объекта (entity).

    4.5.6.1.4. Запрос

    Сообщение-запрос от клиента к серверу включает в себя, в пределах первой строки сообщения, метод, который должен быть использован для ресурса, идентификатор ресурса и код версии используемого протокола.

    Request

    = Request-Line

    *( generalheader

    | requestheader

    | entityheader )

    CRLF

    [ messagebody ]

    4.1. Строка запроса

    Строка запроса начинается с лексемы метода, за которой следует Request-URI, версия протокола, завершается строка последовательностью CRLF. Элементы разделяются символами SP. Символы CR или LF запрещены кроме завершающей последовательности CRLF.

    Request

    Line = Method SP Request-URI SP HTTP-Version CRLF

    4.1.1. Метод

    Лексема Method указывает на метод, который должен быть применен к ресурсу, обозначенному Request-URI. При записи метода использование строчных или прописных букв не безразлично.

    Method

    = "OPTIONS"

    ; Раздел 9.2

    | "GET"

    ; Раздел 9.3

    | "HEAD"

    ; Раздел 9.4

    | "POST"

    ; Раздел 9.5

    | "PUT"

    ; Раздел 9.6

    | "DELETE"

    ; Раздел 9.7

    | "TRACE"

    ; Раздел 9.8

    | extension-method
    extension-method = token

    Список методов допустимых для ресурса может быть специфицирован полем заголовка Allow (раздел 13.7). Возвращаемый код отклика всегда оповещает клиента, допустим ли метод для ресурса, так как набор допустимых методов может меняться динамически. Серверам рекомендуется возвращать статусный код 405 (Метод не допустим), если метод известен серверу, но не приемлем для запрашиваемого ресурса и 501 (Не применим), если метод не узнан или не приемлем для сервера. Список методов, известных серверу может быть представлен в поле заголовка отклика Public (раздел 13.35).

    Методы GET и HEAD должны поддерживаться всеми серверами общего назначения. Все другие методы являются опционными; однако, если применены вышеназванные методы, они должны быть применены с той же семантикой, что специфицирована в разделе 8.

    5.1.2 URI запроса

    URI запроса является универсальным идентификатором ресурса (раздел 2.2) и идентифицирует ресурс, который запрашивается.

    Request-URI = "*" | absoluteURI | abs_path

    Три опции для Request-URI зависят от природы запроса. Звездочка "*" означает, что запрос приложим не к заданному ресурсу, но к самому серверу, и допустим только, когда используемый метод не обязательно приложим к ресурсу. Примером может служить

    OPTIONS * HTTP/1.1

    Форма абсолютного URI необходима, когда запрос адресован к прокси-серверу. Прокси-серверу посылается запрос переадресации с целью получения отклика. Заметьте, что прокси может переадресовать запрос другому прокси или серверу, указанному абсолютным URI. Для того, чтобы избежать петель запросов прокси-сервер должен быть способен распознавать все имена серверов, включая любые псевдонимы, локальные вариации и численные IP-адреса. Пример строки запроса представлен ниже:

    GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

    Для того чтобы разрешить передачу абсолютных URI в запросах будущих версий HTTP, все серверы HTTP/1.1 должны уметь работать с запросами абсолютных форм URI.

    Наиболее общей формой Request-URI является та, которая используется для идентификации ресурса на исходном сервере или внешнем порту сети. В этом случае абсолютный проход к URI должен быть занесен в abs_path (см. раздел 2.2.1) как Request-URI, а сетевой адрес URI (net_loc) должен быть занесен в поле заголовка Host. Например, клиент, желающий извлечь ресурс из выше приведенного примера непосредственно с базового сервера, установит TCP-соединение через порт 80 с ЭВМ "www.w3.org" и пошлет строки:

    GET /pub/WWW/TheProject.html HTTP/1.1
    Host: www.w3.org

    за которыми следует остальная часть запроса. Заметьте, что абсолютный проход не может быть пустым; если его нет в исходном URI, он должен быть задан в виде "/" (корневой каталог сервера).

    Если прокси получает запрос без какого-либо прохода в Request-URI, а метод, специфицирован так, чтобы быть способным поддерживать форму "*" запросов, тогда последний прокси в цепочке запроса должен переадресовать запрос с "*" в качестве финального Request-URI. Например, запрос

    OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

    будет переадресован прокси как

    OPTIONS * HTTP/1.1
    Host: www.ics.uci.edu:8001

    после подключения к порту 8001 ЭВМ "www.ics.uci.edu".

    Request-URI передается в формате, описанном в разделе 3.2.1. Исходный сервер должен декодировать Request-URI, для того чтобы правильно интерпретировать запрос. Серверам рекомендуется откликаться на некорректный запрос Request-URI соответствующим статусным кодом.

    В запросах, которые они переадресуют, прокси-серверы не должны переписывать "abs_path" часть Request-URI каким-либо способом, за исключением случая, описанного выше, когда нулевой abs_path заменяется на "*".

    Замечание: Правило "no rewrite" препятствует прокси изменить смысл запроса, когда исходный сервер некорректно использует незарезервированный URL символ для зарезервированных целей. Следует остерегаться того, что некоторые предшествующие варианты прокси-серверов HTTP/1.1 допускали перезапись Request-URI.

    4.2. Ресурс, идентифицируемый запросом

    Исходному серверу HTTP/1.1 рекомендуется заботиться о точном определении ресурса, идентифицированного Интернет-запросом путем анализа Request-URI и поля заголовка Host.

    Исходный сервер, который не разделяет ресурсы по запрашиваемого ЭВМ, может игнорировать значение поля заголовка Host. (См. раздел 16.5.1 по поводу других требований по поддержке Host в HTTP/1.1.)

    Исходный сервер, который различает ресурсы с использованием имени ЭВМ, должен использовать следующие правила для определения ресурса в запросе HTTP/1.1:

    1. Если Request-URI является absoluteURI, ЭВМ определена частью Request-URI. Любое значение поля заголовка Host в запросе должно игнорироваться.
    2. Если Request-URI не является absoluteURI, а запрос содержит поле заголовка Host, ЭВМ определяется значением поля заголовка Host.
    3. Если ЭВМ, так как это определено правилами 1 или 2, не является ЭВМ сервера, откликом должно быть сообщение об ошибке с кодом 400 (Плохой запрос - Bad Request).

    Получатели HTTP/1.0-запроса, где отсутствует поле заголовка Host, могут попытаться использовать эвристику (напр., рассмотрение прохода URI на предмет уникальной конкретной ЭВМ) для того, чтобы определить, какой конкретный ресурс запрошен.

    4.3. Поля заголовка запроса

    Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса, с семантикой, эквивалентной параметрам, характеризующими метод языка программирования.

    Request-header

    = Accept

    ; Раздел 13.1

    | Accept-Charset

    ; Раздел 13.2

    | Accept-Encoding

    ; Раздел 13.3

    | Accept-Language

    ; Раздел 13.4

    | Authorization

    ; Раздел 13.8

    | From

    ; Раздел 13.22

    | Host

    ; Раздел 13.23

    | If-Modified-Since

    ; Раздел 13.24

    | If-Match

    ; Раздел 13.25

    | If-None-Match

    ; Раздел 13.26

    | If-Range

    ; Раздел 13.27

    | If-Unmodified-Since

    ; Раздел 13.28

    | Max-Forwards

    ; Раздел 13.31

    | Proxy-Authorization

    ; Раздел 13.34

    | Range

    ; Раздел 13.36

    | Referer

    ; Раздел 13.37

    | User-Agent

    ; Раздел 13.42

    Поля имен заголовка запроса могут быть безопасно расширены в сочетании с изменением версии протокола. Однако новым или экспериментальным полям может быть придана семантика полей заголовка запроса, если все участники обмена способны их распознать. Не узнанные поля заголовка рассматриваются как поля заголовка объекта.

    4.5.6.1.5. Отклик

    После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.

    Response

    = Status-Line

    ; Раздел 5.1

    *( general-header

    ; Раздел 3.5

    | response-header

    ; Раздел 5.2

    | entity-header )

    ; Раздел 6.1

    CRLF

    [ message-body ]

    ; Раздел 6.2

    5.1. Статусная строка

    Первая строка сообщения-отклика является статусной строкой, состоящей из кода версии протокола, за которым следует числовой статусный код и его текстовое представление, все элементы разделяются символами SP (пробел). Никакие CR или LF не допустимы, за исключением завершающей последовательности CRLF.

    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

    5.1.1. Статусный код и словесный комментарий

    Элемент Status-Code представляет собой 3-значный цифровой результирующий код попытки понять и исполнить запрос. Эти коды полностью определены в разделе 9. Словесный комментарий (Reason-Phrase) предназначен для того, чтобы дать краткое описание статусного кода. Статусный код служит для использования автоматами, а словесный комментарий для пользователей. Клиент не обязан рассматривать или отображать словесный комментарий.

    Первая цифра статусного кода определяет класс отклика. Последние две цифры не имеют четко определенной функции. Существует 5 значений первой цифры:

    • 1xx: Информационный - Запрос получен, процесс продолжается
    • 2xx: Успех (Success) - Запрос успешно получен, понят и воспринят
    • 3xx: Переадресация (Redirection) - Нужны дополнительные действия для завершения выполнения запроса
    • 4xx: Ошибка клиента (Client Error) - Запрос содержит синтаксическую ошибку или не может быть выполнен
    • 5xx: Ошибка сервера (Server Error) - Сервер не смог выполнить корректный запрос

    Индивидуальные значения числовых статусных кодов определены в HTTP/1.1, а набор примеров, соответствующих причинам, представлен ниже. Комментарии причин, предлагаемые здесь, являются лишь рекомендательными - они могут быть заменены местными аналогами без последствий для протокола.

    Status-Code

    = "100"

    ; Continue

    | "101"

    ; Switching Protocols

    | "200"

    ; OK

    | "201"

    ; Created

    | "202"

    ; Accepted

    | "203"

    ; Non-Authoritative Information

    | "204"

    ; No Content

    | "205"

    ; Reset Content

    | "206"

    ; Partial Content

    | "300"

    ; Multiple Choices

    | "301"

    ; Moved Permanently

    | "302"

    ; Moved Temporarily

    | "303"

    ; See Other

    | "304"

    ; Not Modified

    | "305"

    ; Use Proxy

    | "400"

    ; Bad Request

    | "401"

    ; Unauthorized

    | "402"

    ; Payment Required

    | "403"

    ; Forbidden

    | "404"

    ; Not Found

    | "405"

    ; Method Not Allowed

    | "406"

    ; Not Acceptable

    | "407"

    ; Proxy Authentication Required

    | "408"

    ; Request Time-out

    | "409"

    ; Conflict

    | "410"

    ; Gone

    | "411"

    ; Length Required

    | "412"

    ; Precondition Failed

    | "413"

    ; Request Entity Too Large

    | "414"

    ; Request-URI Too Large

    | "415"

    ; Unsupported Media Type

    | "500"

    ; Internal Server Error

    | "501"

    ; Not Implemented

    | "502"

    ; Bad Gateway

    | "503"

    ; Service Unavailable

    | "504"

    ; Gateway Time-out

    | "505"

    ; HTTP Version not supported

    | extension-code

    Extension-code

    = 3DIGIT

    Reason-Phrase

    = *

    Статусные коды HTTP допускают расширение. HTTP приложения могут не понимать значение всех зарегистрированных статусных кодов, хотя их понимание, очевидно, является желательным. Однако, приложения должны понимать класс любого статусного кода, который задается его первой цифрой, и воспринимать не узнанный отклик как x00. Не узнанный статусный отклик не должен заноситься в буфер. Например, если клиентом получен не распознаваемый статусный код 431, он может предположить, что произошло что-то с запросом и рассматривать отклик так, как если бы он равнялся 400. В таких случаях агентам пользователя рекомендуется предоставлять пользователю объект с откликом, который содержит текст, поясняющий причину создавшейся ситуации.

    5.2 Поля заголовка отклика

    Поля заголовка отклика позволяют серверу передавать дополнительную информацию об отклике, который не может быть помещен в статусную строку. Эти поля заголовка дают информацию о сервере и доступе к ресурсу, идентифицированному Request-URI.

    Response-header

    = Age

    ; Раздел 13.6

    | Location

    ; Раздел 13.30

    | Proxy-Authenticate

    ; Раздел 13.33

    | Public

    ; Раздел 13.35

    | Retry-After

    ; Раздел 13.38

    | Server

    ; Раздел 13.39

    | Vary

    ; Раздел 13.43

    | Warning

    ; Раздел 13.45

    | WWW-Authenticate

    ; Раздел 13.46

    Имена полей заголовка отклика могут быть расширены только в случае изменения версии протокола. Однако новые или экспериментальные поля могут быть введены с учетом семантики полей заголовка отклика, если все участники обмена способны распознавать эти поля. Не узнанные поля заголовка рассматриваются, как поля заголовка объекта (entity-header fields).

    4.5.6.1.6. Объект (Entity)

    Сообщения запрос и отклик могут нести в себе объект, если это не запрещено методом запроса или статусным кодом отклика. Объект состоит из полей заголовка объекта и тела объекта, хотя некоторые отклики включают в себя только заголовки объектов.

    В данном разделе, как отправитель, так и получатель соотносятся к клиенту или серверу, в зависимости от того, кто отправляет и кто получает объект.

    6.1. Поля заголовка объекта

    Поля заголовка объекта определяют опционную метаинформацию о теле объекта или, если тело отсутствует, о ресурсе, идентифицированном в запросе.

    Entity-header

    = Allow

    ; Раздел 13.7

    | Content-Base

    ; Раздел 13.11

    Entity-header

    | Content-

    ; Раздел 13.12

    Entity-header

    | Content-Language

    ; Раздел 13.13

    Entity-header

    | Content-Length

    ; Раздел 13.14

    Entity-header

    | Content-Location

    ; Раздел 13.15

    Entity-header

    | Content-MD5

    ; Раздел 13.16

    Entity-header

    | Content-Range

    ; Раздел 13.17

    Entity-header

    | Content-Type

    ; Раздел 13.18

    Entity-header

    | Etag

    ; Раздел 13.20

    Entity-header

    | Expires

    ; Раздел 13.21

    Entity-header

    | Last-Modified

    ; Раздел 13.29

    Entity-header

    | extension-header

    extension-header = message-header

    Механизм расширения заголовка позволяет определить дополнительные полязаголовка объекта без изменения версии протокола, но эти поля не могут считаться заведомо распознаваемыми получателем. Неузнанные поля заголовка рекомендуется получателю игнорировать и переадресовывать прокси-серверам.

    6.2. Тело объекта

    Тела объекта (если они имеются), пересылаемые HTTP-запросом или откликом, имеют формат и кодировку, определенную полями заголовка объекта.

    entity-body

    = *OCTET

    Тело объекта присутствует в сообщении только когда имеется тело сообщения, как это описано в разделе 3.3. Тело объекта получается из тела сообщения путем декодирования любого транспортного кода (Transfer-Encoding), который может быть применен для обеспечения безопасной и корректной доставки.

    6.2.1. Тип

    Когда тело объекта включено в сообщение, тип данных этого тела определяется полями заголовка Content-Type и Content-Encoding. Они определяют два слоя, заданных моделью кодирования:

    entity-body := Content-Encoding( Content-Type( данные ) )
    Content-Type специфицирует тип среды данных.

    Content-Encoding может использоваться для индикации любого дополнительного кодирования содержимого поля данных, обычно для целей архивации, которая является особенностью запрашиваемого ресурса. По умолчанию никакого кодирования не используется.

    Любое HTTP/1.1 сообщение, содержащее тело объекта, должно включать поле заголовка Content-Type, определяющее тип среды для данного тела. Только в случае, когда тип среды не задан полем Content-Type, получатель может попытаться предположить, каким является тип среды, просмотрев содержимое и/или расширения имен URL, использованного для идентификации ресурса. Если тип среды остается неизвестным, получателю следует рассматривать его как "application/octet-stream" (поток октетов).

    6.2.2. Длина

    Длина тела объекта равна длине тела сообщения, после того как произведено транспортное декодирование. Раздел 4.4 определяет то, как определяется длина тела сообщения.

    4.5.6.1.7. Соединения
    7.1. Постоянные соединения
    7.1.1. Цель

    Прежде чем установить постоянную связь должно быть реализовано отдельное TCP соединение с тем, чтобы получить URL. Это увеличивает нагрузку HTTP серверов и вызывает перегрузку каналов Интернет. Использование изображений и другой связанной с этим информации часто требует от клиента множественных запросов, направленных определенным серверам за достаточно короткое время. Анализ этих проблем содержится в [30][27], а результаты макетирования представлены в [26].

    Постоянное HTTP соединение имеет много преимуществ:

    • При открытии и закрытии TCP соединений можно сэкономить время CPU и память, занимаемую управляющими блоками протокола TCP.
    • HTTP запросы и отклики могут при установлении связи буферизоваться (pipelining), образуя очередь. Буферизация позволяет клиенту выполнять множественные запросы, не ожидая каждый раз отклика на запрос, используя одно соединение TCP более эффективно и с меньшими потерями времени.
    • Перегрузка сети уменьшается за счет сокращения числа пакетов, сопряженных с открытием и закрытием TCP соединений, предоставляя достаточно времени для детектирования состояния перегрузки.
    • HTTP может функционировать более эффективно, так как сообщения об ошибках могут доставляться без потери TCP связи. Клиенты, использующие будущие версии HTTP, могут испытывать новые возможности, взаимодействуя со старым сервером, они могут после неудачи попробовать старую семантику. HTTP реализациям следует пользоваться постоянными соединениями.

    7.1.2. Общие процедуры

    Заметным различием между HTTP/1.1 и более ранними версиями HTTP является постоянное соединение, которое в HTTP/1.1 является вариантом, реализуемым по умолчанию. Поэтому, если не указано обратное, клиент может предполагать, что сервер будет поддерживать постоянное соединение.

    Постоянное соединение обеспечивает механизм, с помощью которого клиент и сервер могут сигнализировать о закрытии TCP-соединения. Эта система сигнализации использует поле заголовка Connection. Как только поступил сигнал о закрытии канала, клиент не должен посылать какие-либо запросы по этому каналу.

    7.1.2.1. Согласование

    HTTP/1.1 сервер может предполагать, что HTTP/1.1 клиент намерен поддерживать постоянное соединение, если только в поле заголовка Connection не записана лексема "close". Если сервер принял решение закрыть связь немедленно после посылки отклика, ему рекомендуется послать заголовок Connection, включающий лексему связи close.

    Клиент HTTP/1.1 может ожидать, что соединение останется открытым, но примет решение оставлять ли его открытым на основе того, содержит ли отклик сервера заголовок Connection с лексемой close.

    Если клиент или сервер посылает лексему close в заголовке Connection, этот запрос становится последним для данного соединения.

    Клиентам и серверам не следует предполагать, что соединение будет оставаться постоянным для версий HTTP, меньше 1.1, если только не получено соответствующее уведомление.

    7.1.2.2. Буферизация

    Клиенты, которые поддерживают постоянное соединение, могут буферизовать свои запросы (то есть, посылать несколько запросов не дожидаясь отклика для каждого из них). Серверы должны посылать свои отклики на эти запросы в том же порядке, в каком они их получили.

    Клиенты, которые предполагают постоянство соединения и буферизацию немедленно после установления соединения должны быть готовы совершить повторную попытку установить связь, если первая буферизованная попытка не удалась. Если клиент совершает повторную попытку установления связи, он не должен выполнять буферизацию запросов, пока не получит подтверждения об установления постоянного соединения. Клиенты должны также быть готовы послать повторно свои запросы, если сервер закрывает соединение прежде, чем пришлет соответствующие отклики.

    7.1.3. Прокси-серверы

    Особенно важно то, чтобы прокси-серверы корректно использовали свойства поля заголовка Connection, как это специфицировано в 13.2.1.

    Прокси-сервер должен сигнализировать о постоянном соединении отдельно своему клиенту и исходному серверу (origin server) или другому прокси, с которым связан. Каждое постоянное соединение устанавливается только для одной транспортной связи.

    Прокси-сервер не должен устанавливать постоянное соединение с HTTP/1.0 клиентом.

    7.1.4. Практические соображения

    Серверы обычно имеют некоторое значение таймаута, за пределами которого они уже не поддерживают более неактивное соединение. Прокси-серверы могут сделать эту величины больше, так как весьма вероятно, что клиент создаст больше соединений через один и тот же сервер. Использование постоянных соединений не устанавливает никаких требований на величину этого таймаута для клиента или сервера.

    Когда клиент или сервер хочет прервать связь по таймауту, ему следует послать корректное оповещение о закрытии соединения. Клиенты и серверы должны постоянно следить, не выдала ли противоположная сторона сигнал на закрытие канала и соответственно реагировать на него. Если клиент или сервер не зафиксирует сигнал противоположной стороны, то будут бессмысленно тратиться ресурсы сети.

    Клиент, сервер или прокси могут закрыть транспортный канал в любое время. Например, клиент может послать новый запрос во время, когда сервер решит закрыть "пассивное" соединение. С точки зрения сервера, состояние которое предлагается закрыть, является пассивным, но с точки зрения клиента идет обработка запроса.

    Это означает, что клиенты, серверы и прокси должны быть способны восстанавливаться после случаев асинхронного закрытия. Программа клиента должна заново открыть транспортное соединение и повторно передать неисполненный запрос без вмешательства пользователя (см. раздел 1.2), хотя агент пользователя может предложить оператору выбор, сопряженный с повторением запроса. Однако эта повторная попытка не должна повторяться при повторной неудаче.

    Серверам следует всегда реагировать, по крайней мере, на один запрос при соединении, если это возможно. Серверам не следует закрывать соединение в процессе передачи отклика, если только не имеет место отказ в сети или выключение клиента.

    Клиенты, которые используют постоянные соединения, должны ограничивать число одновременных связей, которые они поддерживают с конкретным сервером. Однопользовательскому клиенту рекомендуется поддерживать не более двух соединений с любым сервером или прокси. Прокси следует использовать до 2*N соединений с другим сервером или прокси, где N равно числу активных пользователей. Эти рекомендации призваны улучшить время отклика HTTP и исключить перегрузки Интернет и других сетей.

    7.2. Требования к передаче сообщений

    Общие требования:

    • HTTP/1.1 серверам следует поддерживать постоянные соединения и использовать TCP механизмы контроля информационного потока для преодоления временных перегрузок, а не разрывать соединение в расчете на то, что клиент совершит повторную попытку. Последнее может усугубить сетевую перегрузку.
    • Клиент HTTP/1.1 (или позднее), посылая тело сообщения, должен мониторировать сетевое соединение на наличие сигнала ошибки. Если клиент обнаружил состояние ошибки, он должен немедленно прервать передачу. Если тело передается с использованием блочной кодировки ("chunked" encoding, раздел 2.6), возможно применение фрагмента нулевой длины и пустой завершающей секции для обозначения преждевременного конца сообщения. Если телу предшествовал заголовок Content-Length, клиент должен разорвать соединение.
    • Клиент HTTP/1.1 (или позднее) должен быть готов принять код статуса 100 (Continue - продолжить), за которым следует обычный отклик.
    • Сервер HTTP/1.1 (или позднее), который получает запрос от клиента HTTP/1.0 (или ранее), не должен передавать отклик 100 (continue - продолжение), ему следует или ждать нормального завершения запроса (таким образом, избегая его прерывания) или преждевременно разрывать соединение.

    Клиентам следует запомнить номер версии, по крайней мере, сервера, с которым проводилась работа последним, если клиент HTTP/1.1 получил отклик от сервера HTTP/1.1 (или позднее) и обнаружил разрыв соединения до получения какого-либо статусного кода, клиенту следует повторно попытаться направить запрос без участия пользователя (см. раздел 9.1.2). Если клиент действительно повторяет запрос, то клиент:

    • Должен сначала послать поля заголовка запроса, а затем
    • Должен ждать, того, что сервер пришлет отклик 100 (Continue), тогда клиент продолжит работу, или код статуса, сигнализирующего об ошибке.

    Если клиент HTTP/1.1 не получил отклика от сервера HTTP/1.1 (или более поздней версии), ему следует считать, что сервер поддерживает версию HTTP/1.0 или более раннюю и не использует отклик 100 (Continue). Если в этом случае клиент обнаруживает закрытие соединения до получения какого-либо статусного кода от сервера, клиенту следует повторить запрос. Если клиент повторил запрос серверу HTTP/1.0, ему следует использовать следующий алгоритм получения надежного отклика:

    1. Инициировать новое соединение с сервером
    2. Передать заголовок запроса
    3. Инициализировать переменную R для оценки задержки отклика сервера (round-trip time) (напр., на основе времени установления соединения), если RTT не доступно, ему присваивается значение 5 секунд.
    4. Вычислить T = R * (2**N), где N равно числу предыдущих попыток запроса.
    5. Ждать в течение Т секунд или до прихода статуса ошибки (что наступит раньше)
    6. Если не получен сигнал ошибки, после T секунд передается тело запроса.
    7. Если клиент обнаруживает преждевременное прерывание связи, повторяется шаг 1 до тех пор, пока запрос не будет принят или будет получен сигнал ошибки, или пока нетерпеливый пользователь не завершит процесс посылки повторных запросов.

    Вне зависимости от версии сервера, если получен статус ошибки, то клиент

    • Не должен продолжать операции и
    • Должен прервать соединение, если процедура не завершена посылкой сообщения.

    Клиент HTTP/1.1 (или позднее), который обнаруживает разрыв соединения после получения флага 100 (Continue), но до получения какого-либо статусного кода, должен повторить запрос и не должен ждать отклика 100 (Continue), но может и делать это, если это упрощает реализацию программы.

    4.5.6.1.8. Метод определений

    Набор общих методов для HTTP/1.1 определен ниже. Хотя этот набор может быть расширен, нельзя предполагать, что дополнительные методы следуют той же семантике для разных клиентов и серверов. Поле заголовка запроса Host (раздел 13.23) должно присутствовать во всех запросах HTTP/1.1.

    8.1. Безопасные и Idempotent методы
    8.1.1. Безопасные методы

    Программисты должны заботиться о том, чтобы избегать операций, которые могут иметь неожиданное значение для них самих или их соседей по сети Интернет.

    В частности, установлено соглашение, что методы GET и HEAD никогда не должны выполнять какие либо функции помимо доставки информации. Эти методы должны рассматриваться как вполне безопасные. Это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и DELETE, особым способом, так что пользователь сам будет заботиться о возможности опасных операций, которые могут быть выполнены в результате реализации запроса.

    Естественно, невозможно гарантировать, что сервер не будет вызывать побочные эффекты, как следствие выполнения запроса GET; в действительности, некоторые динамические ресурсы предусматривают такую возможность. Важным отличием здесь является то, что пользователь не запрашивал побочные эффекты и, следовательно, не может нести ответственность за них.

    8.1.2. Подобные методы

    Методы могут также иметь свойство "idempotence", при котором (помимо ошибок и таймаутов) побочный эффект от N > 0 идентичных запросов является таким же, как и от одного запроса. Методы GET, HEAD, PUT и DELETE имеют это свойство.

    8.2. Опции

    Метод OPTIONS представляет собой запрос информации о коммуникационных опциях, доступных в цепочке запрос/отклик, идентифицированной Request-URI. Этот метод позволяет клиенту определить опции и/или требования, связанные с ресурсами, или возможности сервера, не прибегая к операциям по извлечению и пересылке каких-либо файлов.

    Если отклик сервера не сигнализирует об ошибке, отклик не должен включать никакой информации об объекте, отличной оттого, что считается коммуникационными опциями (напр., Allow подходит под эту категорию, а Content-Type нет). Отклики на этот метод не должны кэшироваться.

    Если Request-URI тождественен символу звездочка ("*"), то запрос OPTIONS будет относиться ко всему серверу. Отклик 200 должен включать в себя любые поля заголовка, которые указывают на опционные характеристики используемого сервера (например, Public), включая любые расширения неопределенные в данной спецификации, в дополнение к любым общим используемым полям заголовка. Как описано в разделе 4.1.2, запрос "OPTIONS *" может быть реализован через прокси путем спецификации сервера места назначения в Request-URI без указания прохода. Если Request-URI не равен звездочке, запрос OPTIONS относится только к опциям, которые доступны при обмене с данным ресурсом. Отклик 200 должен включать любые поля заголовка, которые указывают опционные характеристики используемого сервера и применимы к данному ресурсу (напр., Allow), включая любые расширения, не описанные в данной спецификации. Если запрос OPTIONS проходит через прокси, то он должен редактировать отклик и удалять те опции, которые не доступны для реализации через данный прокси-сервер.

    8.3 Метод GET

    Метод GET предполагает извлечение любой информации (в форме объекта), заданной Request-URI. Если Request-URI относится к процессу, генерирующему данные, то в результате в виде объекта будут присланы эти данные, а не исходный текст самого процесса, если только этот текст не является результатом самого процесса.

    Семантика метода меняется на "условный GET", если сообщение-запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Метод условного GET запрашивает, пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на "частичный GET", если сообщение запроса включает в себя поле заголовка Range. Запросы частичного GET, которые предназначены для пересылки лишь части объекта, описаны в разделе 13.36. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей.

    Отклик на запрос GET буферизуется, тогда и только тогда, когда это согласуется с требованиями буферизации, рассмотренными в разделе 12.

    8.4. Метод HEAD

    Метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта. Этот метод часто используется для тестирования гипертекстных связей на корректность, доступность и актуальность.

    Отклик на запрос HEAD может кэшироваться в том смысле, что информация, содержащаяся в отклике, может использоваться для актуализации кэшированных ранее объектов данного ресурса. Если новые значения поля указывают на то, что кэшированный объект отличается от текущего объекта (как это индицируется изменением Content-Length, Content-MD5, ETag или Last-Modified), тогда запись в кэше должна рассматриваться как устаревшая.

    8.5. Метод POST

    Метод POST используется при заявке серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного Request-URI в Request-Line. POST создан для обеспечения однородной схемы реализации следующих функций:

    • Аннотация существующего ресурса;
    • Помещение сообщения на электронную доску объявлений, в группу новостей, почтовый список или какую-то другую группу статей;
    • Выдача блока данных, такого как при передаче формы процессу ее обработки;
    • Расширение базы данных с помощью операции добавления (append).

    Реальная операция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Присланный объект является вторичным по отношению к URI в том же смысле, в каком файл является вторичным по отношению к каталогу, в котором он находится, а статья новостей - вторичной по отношению к группе новостей, куда она помещена, или запись - по отношению к базе данных.

    Операция, выполняемая методом POST, может не иметь последствий для ресурса, который может быть идентифицирован URI. В этом случае приемлемым откликом является 200 (OK) или 204 (No Content - никакого содержимого), в зависимости от того, включает ли в себя отклик объект, описывающий ресурс.

    Если ресурс был создан на исходном сервере, отклик должен быть равен 201 (Created - создан) и содержать объект, который описывает статус запроса и относится к новому ресурсу и заголовку Location (см. раздел 13.30).

    Отклики на этот метод не могут кэшироваться, если только не содержат поля заголовка Cache-Control или Expires. Однако отклик 303 (см. Other) может быть использован для того, чтобы направить агента пользователя для извлечения кэшируемого ресурса.

    Запросы POST должны подчиняться требованиям, предъявляемым к передаче сообщений, рассмотренным в разделе 7.2.

    8.6. Метод PUT

    Метод PUT требует, чтобы вложенный объект был запомнен с использованием Request-URI. Если Request-URI относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если Request-URI не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URI как новый ресурс, исходный сервер может создать ресурс с этим URI. Если новый ресурс создан, исходный сервер должен информировать об этом агента пользователя, послав код отклик 200 (OK) или 204 (No Content - никакого содержимого) и тем самым, объявляя об успешно выполненном запросе. Если ресурс не может быть создан или модифицирован с помощью Request-URI, должен быть послан соответствующий код отклика, который отражает характер проблемы. Получатель объекта не должен игнорировать любой заголовок Content-* (например, Content-Range), который он не понял или не использовал, а должен в таком случае вернуть код отклика 501 (Not Implemented - не использовано).

    Если запрос проходит через кэш и Request-URI идентифицирует один или более кэшированных объектов, эти объекты должны рассматриваться как устаревшие. Отклики этого метода не должны кэшироваться.

    Фундаментальное отличие между запросами POST и PUT отражается в различных значениях Request-URI. URI в запросе POST идентифицирует ресурс, который будет работать со вложенным объектом. Этот ресурс может быть процессом приемки данных, шлюзом к другому протоколу или отдельным объектом, который воспринимает аннотации. Напротив, URI в запросах PUT идентифицируют объекты, заключенные в запросе, - агент пользователя знает, какой URI применить и сервер не должен пытаться посылать запрос другому ресурсу. Если сервер хочет, чтобы запрос был направлен другому URI, он должен послать отклик 301 (Moved Permanently). Агент пользователя может принять свое собственное решение относительно того, следует ли переадресовывать запрос.

    Один и тот же ресурс может быть идентифицирован многими URI. Например, статья может иметь URI для идентификации "текущей версии", которая отличается от URI, идентифицирующей каждую конкретную версию. В этом случае запрос PUT на общий URI может дать в результате несколько других URI, определенных исходным сервером. HTTP/1.1 не определяет то, как метод PUT воздействует на состояние исходного сервера. Запросы PUT должны подчиняться требованиям передачи сообщения, заданным в разделе 7.2.

    8.7. Метод DELETE

    Метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый Request-URI. Этот метод на исходном сервере может быть отвергнут вмешательством человека (или каким-то иным путем). Клиент не может гарантировать, что операция была выполнена, даже если возвращенный статусный код указывает, что операция завершилась успешно. Однако, сервер не должен сообщать об успехе, если за время отклика он не намерен стереть ресурс или переместить его в недоступное место.

    Сообщение об успехе должно иметь код 200 (OK), если отклик включает объект, описывающий статус; 202 (Accepted - принято), если операция еще не произведена или 204 (No Content - Никакого содержимого), если отклик OK, но объекта в нем нет.

    Если запрос проходит через кэш, а Request-URI идентифицирует один или более кэшированных объектов, эти объекты следует считать устаревшими (stale). Отклики на этот метод не кэшируемы.

    8.8. Метод TRACE

    Метод TRACE используется для того, чтобы запустить удаленный цикл сообщения-запроса на прикладном уровне. Конечный получатель запроса должен отослать полученное сообщение назад клиенту в виде тела объекта (код = 200 (OK)). Конечным получателем является либо исходный сервер, либо первый прокси или шлюз для получения значения Max-Forwards (0) в запросе (см. раздел 13.31). Запрос TRACE не должен включать в себя объект.

    TRACE позволяет клиенту видеть, что получено на другом конце цепи запроса и использовать эти данные для тестирования или диагностики. Значение поля заголовка Via (раздел 13.44) представляет особый интерес, так как оно позволяет отследить всю цепочку запроса. Использование поля заголовка Max-Forwards позволяет клиенту ограничить длину цепи запроса, которая полезна для тестирования цепи прокси, переадресующих сообщения по замкнутому кругу.

    В случае успеха отклик должен содержать все сообщение-запрос с Content-Type = "message/http". Отклики этого метода не должны кэшироваться.

    4.5.6.1.9. Определения статусных кодов

    Ниже описаны статусные коды, включая то, каким методам они соответствуют, и какая метаинформация должна присутствовать в откликах.

    9.1. Информационный 1xx

    Этот класс статусного кода индицирует информационный отклик, состоящий только из статусной строки и опционных заголовков с пустой строкой в конце. Так как HTTP/1.0 не определяет каких-либо статусных кодов 1xx, серверы не должны посылать отклики 1xx клиентам HTTP/1.0 за исключением случаев отладки экспериментальных протокольных версий.

    9.1.1. 100 Continue (продолжение)

    Клиент может продолжать работу, получив этот отклик. Этот промежуточный отклик используется для информирования клиента о том, что начальная часть запроса получена и пока не отклонена сервером. Клиенту следует продолжить отправлять оставшуюся часть запроса, если же запрос уже отправлен, то игнорировать этот отклик. Сервер должен послать окончательный отклик по завершении реализации запроса.

    9.1.2. 101 Switching Protocols (Переключающие протоколы)

    Сервер оповещает клиента о том, что он понял и принял к исполнению запрос. С помощью поля заголовка сообщения Upgrade (раздел 13.41) клиент уведомляется об изменении прикладного протокола для данного соединения. Сервер переходит на протокол, определенный в поле заголовка отклика Upgrade, немедленно после получения пустой строки, завершающей отклик 101.

    Протокол следует изменять лишь в случае, если он предоставляет существенные преимущества. Например, переключение на новую версию HTTP предоставляет преимущества по отношению к старой версии, а переключение на синхронный протокол реального времени может иметь преимущество, когда ресурс использует это свойство.

    9.2. Successful 2xx (Успешная доставка)

    Этот класс статусного кода индицирует, что запрос клиента благополучно получен, понят и принят к исполнению.

    9.2.1. 200 OK

    Запрос успешно исполнен. Информация, возвращаемая вместе с откликом, зависит от метода, использованного запросом, например:

    GET - в качестве отклика посылается объект, соответствующий запрошенному ресурсу;
    HEAD - в качестве отклика посылаются поля заголовка объекта (без какого-либо тела), соответствующего запрошенному ресурсу;
    POST - объект, описывающий или содержащий результат операции;
    TRACE - объект, содержащий сообщение-запроса, в виде, полученном оконечным сервером.

    9.2.2. 201 Created (Создано)

    Запрос исполнен и в результате создан новый ресурс. Вновь созданный ресурс может быть доступен через URI, присланный в объекте отклика, со значащей частью URL ресурса в поле заголовка Location. Исходный сервер должен создать ресурс до отправки статусного кода 201. Если операция не может быть выполнена немедленно, сервер вместо этого должен откликнуться статусным кодом 202 (Accepted).

    9.2.3. 202 Accepted (Принято)

    Запрос был принят для исполнения, но обработка запроса не завершена. Запрос может обрабатываться или нет, так как он был блокирован в процессе исполнения. Не существует механизма повторной посылки статусного кода для асинхронных операций вроде этой.

    Целью отклика 202 является разрешить серверу принять запрос для некоторого другого процесса (возможно процесса, запускаемого раз в день), не требуя того, чтобы соединение агента пользователя с сервером сохранялось до завершения процесса. Объект, возвращаемый этим откликом должен включать в себя текущий статус запроса и указатель на статус-монитор или некоторую оценку того, когда пользователь может ожидать завершения реализации запроса.

    9.2.4. 203 Non-Authoritative Information (Не надежная информация)

    Присылаемая в ответ метаинформация в заголовке объекта не идентифицируется, как полученная от исходного сервера, ее следует скорее считать косвенной, полученной опосредовано. Например, включение местной аннотационной информации о ресурсе может иметь последствия для мета информации, известной исходному серверу. Использование данного кода отклика не является обязательным и целесообразно лишь в случае, когда отклик мог бы быть равен 200 (OK).

    9.2.5. 204 No Content (Никакого содержимого)

    Сервер исполнил запрос, но нет никакой новой информации для отсылки. Этот отклик первоначально предназначался для разрешения ввода, не вызывая изменения активного документа агента пользователя. Отклик может включать новую метаинформацию в форме заголовков объектов, которая должна быть передана для документа, отображаемого агентом пользователя.

    Отклик 204 не должен включать тела сообщения и всегда завершается пустой строкой после полей заголовка.

    9.2.6. 205 Reset Content (Сброс содержимого)

    Сервер исполнил запрос и агент пользователя должен вернуть документ к виду, который он имел в момент посылки запроса. Этот отклик первоначально предназначался для обеспечения ввода при выполнении пользователем операции, за которой следует очистка формы, в которую произведен ввод, так что пользователь может начать другую операцию ввода. Отклик не должен включать в себя объект.

    9.2.7. 206 Partial Content (Частичное содержимое)

    Сервер исполнил частично запрос GET для заданного ресурса. Запрос должен включать поле заголовка Range (раздел 13.36), указывающее на желательный интервал (range). Отклик должен включать поле заголовка Content-Range (раздел 13.17), указывающее диапазон данных, включенных в отклик, или множественные байтные интервалы (multipart/byteranges) Content-Type, включающие поля Content-Range для каждой из частей. Если множественные байтные интервалы не используются, поле заголовка Content-Length в отклике должно соответствовать действительному числу октетов в теле сообщения. Кэш, который не поддерживает заголовки Range и Content-Range, не должен кэшировать отклики 206 (Partial).

    9.3. Redirection 3xx (Переадресация)

    Этот класс статусных кодов указывает, что для выполнения запроса, нужны дальнейшие действия агента пользователя. Необходимые действия могут быть выполнены агентом пользователя без взаимодействия с пользователем, тогда и только тогда, когда используемый метод соответствует GET или HEAD. Агент пользователя не должен автоматически переадресовывать запрос более чем 5 раз, так как такая переадресация обычно свидетельствует о зацикливании запроса.

    9.3.1. 300 Multiple Choices (Множественный выбор)

    Запрошенный ресурс соответствует какому-то представлению из имеющегося набора представлений, каждое со своим адресом. Имеется информация (раздел 11), полученная в результате согласования под управлением агента пользователя, так что пользователь (или агент пользователя) может выбрать предпочтительное представление и переадресовать свой запрос по соответствующему адресу.

    Если это только не был запрос HEAD, отклик должен включать объект, содержащий список характеристик ресурсов и их адресов, из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта специфицируется типом среды, заданным полем заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может быть выполнен автоматически. Однако, эта спецификация не определяет какого-либо стандарта для такого автоматического выбора.

    Если сервер имеет предпочтительный вариант представления, ему следует включить соответствующий URL этого представления в поле Location. Агент пользователя может использовать значение поля Location для реализации автоматического выбора. Этот отклик может кэшироваться, если не указано обратного.

    9.3.2. 301 Moved Permanently (Постоянно перемещен)

    Запрошенному ресурсу был приписан новый постоянный URI и любая будущая ссылка на этот ресурс должна делаться с использованием одного из присланных URI. Клиенты с возможностью редактирования связей должны, где возможно, автоматически менять связи для ссылок Request-URI на одну или более новых ссылок, присланных сервером. Этот отклик можно кэшировать, если не указано обратного.

    Если новый URI является адресом (location), его URL должен быть задан в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.

    Если получен статусный код 301 в ответ на запрос, отличный от GET или HEAD, агент пользователя не должен автоматически переадресовывать запрос, если только это не может быть подтверждено пользователем, так как такая переадресация может изменить условия, при которых направлен запрос.

    Замечание: При автоматической переадресации запроса POST, получив статусный код 301, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET.

    9.3.3. 302 Moved Temporarily (Временно перемещен)

    Запрошенный ресурс размещается временно под различными URI. Так как переадресация может быть случайно изменена, клиент должен продолжать использовать Request-URI для будущих запросов. Этот отклик допускает кэширование, если имеются соответствующие указания в полях заголовка Cache-Control или Expires.

    Если новый URI является адресом (location), его URL должен задаваться полем Location отклика. Если запрошенный метод не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.

    Если в ответ на запрос, отличный от GET или HEAD, получен статусный код 302, агент пользователя не должен автоматически переадресовывать запрос, если это не может быть подтверждено пользователем, так как это может изменить условия, при которых был выдан запрос.

    Замечание: Когда после получения статусного кода 302 автоматически переадресуется запрос POST, некоторые существующие агенты пользователя HTTP/1.0 ошибочно меняют его на запрос GET.

    9.3.4. 303 See Other (смотри другие)

    Отклик на запрос может быть найден под разными URI. Его следует извлекать с помощью метода GET. Этот метод первоначально создан для того, чтобы позволить переадресацию агента пользователя на выбранный ресурс при запуске скрипта с помощью POST. Новый URI не является заменой ссылки для первоначально запрошенного ресурса. Отклик 303 не кэшируется, но отклик на второй (переадресованный) запрос может кэшироваться.

    Если новый URI является адресом (location), его URL должно быть задано в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать гипертекстовую ссылку на новый URI.

    9.3.5. 304 Not Modified (Не модифицировано)

    Если клиент выполнил условный запрос GET и получил доступ, а документ не был модифицирован, сервер должен реагировать этим статусным кодом. Отклик не должен содержать тела сообщения.

    Отклик должен включать поля заголовка:

    • Дата
    • ETag и/или Content-Location, если заголовок был послан в рамках отклика 200 на тот же самый запрос
    • Expires, Cache-Control и/или Vary, если значение поля может отличаться от посланного в каком-либо предыдущем отклике того же типа

    Если условный GET использовал строгий валидатор кэша (см. раздел 12.8.3), отклик не должен содержать других заголовков объекта. В противном случае (напр., условный GET использовал слабый валидатор), отклик не должен включать в себя другие заголовки. Это предотвращает несогласованности между кэшированными телами объектов и актуализованными заголовками (updated headers).

    Если отклик 304 указывает на то, что объект не кэширован, тогда кэш должен игнорировать отклик и повторить запрос уже в безусловном режиме.

    Если кэш использует полученный отклик 304 для актуализации записи в кэше, то кэш должен выполнить актуализацию с учетом новых значений полей, присланных в отклике.

    Отклик 304 не должен включать в себя тело сообщения и, по этой причине всегда завершается пустой строкой после полей заголовка.

    9.3.6. 305 Use Proxy (Используйте прокси)

    Запрошенный ресурс должен иметь доступ через прокси-сервер, указанный в поле Location. Поле Location задает URL прокси-сервера. Предполагается, что получатель повторит запрос через прокси.

    9.4. Client Error 4xx (Ошибка клиента)

    Класс статус кодов 4xx предназначен для случаев, когда клиент допустил ошибку. За исключением случая отклика на запрос HEAD, серверу следует включить объект, содержащий объяснение ошибочной ситуации, а также указать, является ли ситуация временной или постоянной. Эти статусные коды применимы к любому методу запросов. Агенту пользователя следует отобразить все объекты.

    Замечание. Если клиент посылает данные, реализация сервера, использующая протокол TCP, должна позаботиться о том, чтобы клиент получил пакет, содержащий отклик, до того как сервер закроет данное соединение. Если клиент продолжает посылку данных серверу после закрытия связи, TCP-уровень сервера должен послать клиенту пакет reset (сброс), который может стереть содержимое входного буфера клиента до того, как оно будет прочитано и интерпретировано приложением HTTP.

    9.4.1. 400 Bad Request (Плохой запрос)

    Запрос может быть не понят сервером из-за ошибочного синтаксиса. Клиенту не следует повторять запрос без модификации.

    9.4.2. 401 Unauthorized (Не авторизован)

    Запрос требует авторизации пользователя. Отклик должен включать в себя поле заголовка WWW-Authenticate (раздел 13.46), содержащее требование (challenge), применимое к запрошенному ресурсу. Клиент может повторить запрос с соответствующим содержимым поля заголовка Authorization (раздел 13.8). Если запрос уже включал допуск в поле Authorization, тогда отклик 401 указывает на то, что данный допуск не работает. Если отклик 401 содержит то же требование, что и предшествующий отклик, а агент пользователя уже пробовал пройти идентификацию по крайней мере хотя бы раз, тогда пользователю следует предоставить объект, содержащийся в отклике, так как он может содержать полезную диагностическую информацию. Идентификация доступа HTTP описана в разделе 10.

    9.4.3. 402 Необходима оплата

    Этот код зарезервирован для использования в будущем.

    9.4.4. 403 Forbidden (Запрещено)

    Сервер понял запрос, но отказался его исполнить. Авторизация не поможет и повторять запрос не следует. Если метод запроса не HEAD, а сервер желает открыто объявить причину неисполнения запроса, то ему следует описать соображения, по которым запрос отклонен Этот статусный код обычно используется, когда сервер не хочет показывать, почему запрос отклонен, или когда другой отклик не подходит.

    9.4.5. 404 Not Found (Не найдено)

    Сервер не нашел ничего, отвечающего Request-URI. Не приводится никаких данных о том, являются ли эта ситуация временной или постоянной.

    Если сервер не хочет сделать эту информацию открытой для клиента, вместо этого может использоваться статусный код 403. Статусный код 410 (Gone - Утрачен) следует использовать, если сервер знает за счет некоторого внутреннего механизма конфигурации, что старый ресурс постоянно недоступен и не имеет нового адреса его размещения.

    9.4.6. 405 Method Not Allowed (Метод не разрешен)

    Метод, специфицированный в Request-Line, не разрешен для ресурса, указанного Request-URI. Отклик должен включать заголовок Allow, содержащий список разрешенных методов для запрошенного ресурса.

    9.4.7. 406 Not Acceptable (Не приемлемо)

    Ресурс, идентифицированный запросом, способен только генерировать объекты откликов, которые имеют характеристики, неприемлемые согласно заголовкам accept, присланным в запросе.

    Если это не запрос HEAD, отклик должен включать объект, содержащий список доступных характеристик объекта и адреса, где пользователь или агент пользователя может выбрать нечто наиболее подходящее. Формат объекта специфицируется типом среды, приведенным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, оптимальный выбор может быть сделан автоматически. Однако данная спецификация не определяет какого-либо стандарта для такого автоматического выбора.

    Замечание. HTTP/1.1 серверам разрешено присылать отклики, которые неприемлемы согласно заголовкам accept, присланным в запросе. В некоторых случаях, может оказаться предпочтительнее послать отклик 406. Агенты пользователя могут просматривать заголовки приходящих откликов с тем, чтобы определить, являются ли они приемлемыми. Если отклик не может быть воспринят, агенту пользователя следует временно прервать прием данных и запросить пользователя принять решение о дальнейших действиях.

    9.4.8. 407 Proxy Authentication Required (Необходима идентификация прокси)

    Этот статусный код подобен 401 (Unauthorized), но указывает, что клиент должен сначала авторизоваться на прокси-сервере. Прокси должен прислать в ответ поле заголовка Proxy-Authenticate (раздел 13.33), содержащего требования, реализуемые на прокси для запрошенного ресурса. Клиент может повторить запрос с подходящим полем заголовка Proxy-Authorization (раздел 13.34). Авторизация доступа HTTP описана в разделе 10.

    9.4.9. 408 Request Timeout (Таймаут запроса)

    Клиент не выдал запрос в пределах временного интервала, в течение которого сервер его ожидал. Клиент может повторить запрос без модификаций в любое время.

    9.4.10. 409 Conflict (Конфликт)

    Выполнение запроса не может быть завершено из-за конфликта с текущим состоянием ресурса. Этот статусный код разрешен в ситуациях, где предполагается, что пользователь может разрешить конфликт и повторно послать запрос. Тело отклика должно включать достаточно информации, чтобы пользователь мог понять причину конфликта. В идеале, объект отклика должен был бы включать достаточно информации для пользователя или агента пользователя для того, чтобы уладить конфликт, однако это невозможно и необязательно.

    Конфликты наиболее вероятно происходят в результате запроса PUT. Если задействована версия и объект операции PUT вызывает изменение ресурса, которые конфликтуют с изменениями внесенными запросом, выполненным ранее, сервер может использовать отклик 409 для того, чтобы указать на невозможность завершить выполнение запроса. В этом случае объект отклика должен содержать список отличий между двумя версиями формата, определенном откликом Content-Type.

    9.4.11. 410 Gone (Исчез)

    Запрошенный ресурс не является более доступным на сервере и не известен указатель переадресации. Это условие следует считать постоянным. Клиенты с возможностями редактирования связей должны ликвидировать ссылки на Request-URI после подтверждения пользователем. Если сервер не знает или не имеет возможности определить, является ли данное условие постоянным или временным, следует использовать отклик со статусным кодом 404 (Not Found). Этот отклик можно кэшировать, если не указано обратного.

    Отклик 410 первоначально предназначался для того, чтобы помочь работе задач в WWW-среде путем сообщения получателю о том, что ресурс заведомо недостижим и владелец сервера хотел бы, чтобы связи с этим ресурсом были удалены. Такое событие является типичным для ограниченного периода времени и для ресурсов, принадлежащих частным лицам, которые не работают более с данным сервером. Не обязательно отмечать все постоянно недоступные ресурсы, как исчезнувшие (Gone) или сохранять такую пометку произвольное время - это оставлено на усмотрение собственника сервера.

    9.4.12. 411 Length Required (Необходима длина)

    Сервер отказывается принять запрос без определенного значения Content-Length. Клиент может повторить запрос, если он добавит корректное значение поля заголовка Content-Length, содержащего длину тела сообщения.

    9.4.13. 412 Precondition Failed (Предварительные условия не выполнены)

    Предварительные условия, заданные в одном или более полях заголовка запроса, воспринимаются как не выполненные, когда это проверено сервером. Этот код отклика позволяет клиенту установить предварительные условия для метаинформации (данные поля заголовка) текущего ресурса и, таким образом, предотвратить возможность использования запрошенного метода для ресурса, отличного от указанного.

    9.4.14. 413 Request Entity Too Large (Объект запроса слишком велик)

    Сервер отказывается обрабатывать запрос, потому что объект запроса больше, чем сервер способен обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать посылать запросы.

    Если условие является временным, серверу следует включить поле заголовка Retry-After, чтобы указать на временность этого условия, что означает возможность повторения запроса некоторое время спустя.

    9.4.15. 414 Request-URI Too Long (URI запроса слишком велик)

    Сервер отказывается обслужить запрос, потому что Request-URI длиннее, чем сервер способен интерпретировать. Это редкое обстоятельство может возникнуть только, когда клиент не корректно преобразует запрос POST в GET с длинной информацией запроса. При этом клиент ныряет в "черную дыру" переадресаций. Примером может служить преадресованный URL префикс, который указывает на свой суффикс, или случай атаки сервера клиентом, который пытается использовать дыры в системе безопасности, имеющиеся у клиентов с фиксированной емкостью буферов для работы с Request-URI.

    9.4.16. 415 Unsupported Media Type (Неподдерживаемый тип среды)

    Сервер отказывается обслужить запрос, потому что объект запроса имеет формат, неподдерживаемый запрашиваемым ресурсом для указанного метода.

    9.5. Сервер ошибок 5xx

    Статусный код отклика, начинающийся с цифры "5", указывает на случаи, когда сервер опасается, что он ошибся или не может реализовать запрос. За исключением случаев, когда обрабатывается запрос HEAD, серверу следует включить объект, содержащий объяснение создавшейся ошибочной ситуации и указывающей на то, является ли ситуация временной или постоянной. Агенту пользователя следует отобразить пользователю любой объект, включенный в отклик. Эти коды откликов применимы для любых методов запроса.

    9.5.1. 500 Internal Server Error (Внутренняя ошибка сервера)

    Сервер столкнулся с непредвиденными условиями, которые мешают ему исполнить запрос.

    9.5.2. 501 Not Implemented (Не применимо)

    Сервер не поддерживает функцию, которая должна быть реализована в ходе исполнения запроса. Это адекватный отклик, когда сервер не распознает метод запроса и не способен поддерживать его для данного ресурса.

    9.5.3. 502 Bad Gateway (Плохой шлюз)

    Сервер при работе в качестве шлюза или прокси получил неверный отклик от вышестоящего сервера, к которому он обратился, выполняя запрос.

    9.5.4. 503 Service Unavailable (Услуга не доступна)

    Сервер в данный момент не может обработать запрос в связи с временной перегрузкой или другими сложившимися обстоятельствами.

    Замечание. Существование статусного кода 503 не предполагает, что сервер должен использовать его, когда оказывается перегруженным. Некоторые серверы могут захотеть просто отказаться устанавливать соединение.

    9.5.5. 504 Gateway Timeout (Таймаут шлюза)

    Сервер при работе в качестве внешнего шлюза или прокси-сервера не получил своевременно отклик от вышестоящего сервера, к которому он обратился, пытаясь исполнить запрос.

    9.5.6. 505 HTTP Version Not Supported (Версия не поддерживается)

    Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая была использована в сообщении-запросе. Сервер индицирует, что он не способен или не хочет завершать обработку запроса в рамках главной версии клиента, как это описано в разделе 2.1, в отличие от сообщения об ошибке. Отклику следует содержать объект, описывающий, почему эта версия не поддерживается и какие другие протоколы поддерживаются сервером.

    4.5.6.1.10. Идентификация доступа

    HTTP предлагает простой механизм аутентификации с помощью отклика, который может использоваться сервером, чтобы потребовать от клиента прислать запрос, содержащий аутентификационную информацию. Для определения схемы идентификации он использует лексему произвольной длины, не зависящую от применения строчных или прописных символов, за ней следует список пар атрибут-значение. Элементы списка отделяются друг от друга запятыми. Атрибуты представляют собой параметры, которые определяют аутентификацию в рамках выбранной схемы.

    Auth-scheme

    = token

    auth-param

    = token "=" quoted-string

    Сообщение-отклик 401 (Unauthorized) используется исходным сервером для посылки требования авторизации агенту пользователя. Этот отклик должен включать в себя поле заголовка WWW-Authenticate, содержащее, по крайней мере, одно требование доступа к запрашиваемому ресурсу.

    Challenge

    = auth-scheme 1*SP realm *( "," auth-param )

    Realm

    = "realm" "=" realm-value

    realm-value

    = quoted-string

    Атрибут области realm (не зависит от применения строчных или прописных букв) необходим для всех схем идентификации (authentication), которые посылают требования. Значение атрибута realm (чувствительно к применению строчных и прописных букв), в комбинации с каноническим корневым URL (см. раздел 4.1.2) сервера доступа, определяет пространство защиты. Эти области позволяют разделить защищенные ресурсы на сервере на ряд защищенных зон, каждая со своей собственной схемой идентификации и/или идентификационной базой данных. Значением атрибута области является строка, обычно присваиваемая исходным сервером, которая может иметь специфическую емантику для каждой схемы идентификации.

    Агент пользователя, который хочет идентифицировать себя на сервере, после получения отклика 401 или 411 может сделать это, включив в запрос поле заголовка Authorization. Значение поля Authorization состоит из записей, содержащих идентификационную информацию агента пользователя для области (realm) запрошенного ресурса.

    credentials = basic-credentials

    | auth-scheme #auth-param

    Домен, в пределах которого может автоматически использоваться идентификационная информация, определяется зоной защиты. Если предыдущий запрос был авторизован, та же идентификационная информация может быть использована для всех других запросов в пределах зоны защиты и во временных рамках, заданных схемой идентификации, параметрами и/или предпочтениями пользователя. Если не определено обратного схемой авторизации, одна зона защиты не может быть распространена за пределы ее сервера.

    Если сервер не хочет принимать идентификационную информацию, присланную в запросе, он должен прислать отклик 401 (Unauthorized). Отклик должен включать поле заголовка WWW-Authenticate, содержащее требование (возможно новое), применимое для запрошенного ресурса, и объект, объясняющий причину отказа.

    Протокол HTTP не ограничивает приложения только этим простым механизмом авторизации (требование-отклик). Может быть применен дополнительный механизм, такой как шифрование на транспортном уровне или использование инкапсуляции сообщений. Однако в данной спецификации эти дополнительные механизмы не определены.

    Прокси-серверы должны быть полностью прозрачны по отношению авторизации агентов пользователя. То есть, они должны переадресовывать в неприкосновенном виде заголовки WWW-Authenticate и Authorization, согласно правилам описанным в разделе 13.8.

    HTTP/1.1 позволяет клиенту передать идентификационную информацию в прокси и обратно с использованием заголовков Proxy-Authenticate и Proxy-Authorization.

    10.1 Базовая схема идентификации (Authentication)

    Базовая схема авторизации базируется на модели, в которой агент пользователя должен идентифицировать себя с помощью имени пользователя и пароля, необходимого для каждой области (realm). Значение атрибута realm должно рассматриваться в виде неотображаемой строки символов, которая может сравниваться с другим значение realm на этом сервере.

    Сервер обслужит запрос только в случае, если убедится в корректности имени и пароля пользователя для данной зоны защиты Request-URI. Не существует каких-либо опционных параметров авторизации.

    При получении неавторизованного запроса для URI в пределах зоны защиты (protection space), сервер может реагировать посылкой требования в виде:

    WWW-Authenticate: Basic realm="WallyWorld"

    где "WallyWorld" - строка присвоенная сервером для идентификации зоны защиты Request-URI.

    Чтобы получить авторизацию клиент посылает свое имя и пароль, разделенные символом двоеточие (":"), и закодированные согласно base64.

    basic-credentials = "Basic" SP basic-cookie
    basic-cookie =
    user-pass = userid ":" password
    userid = *
    password = *TEXT

    Идентификационная информация может быть чувствительной к применению строчных или прописных букв.

    Если агент пользователя хочет послать имя пользователя "Aladdin" и пароль "Сезам открой", он использует следующее поле заголовка:

    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

    Смотри раздел 14 по поводу соображений безопасности, связанных с базовой авторизацией.

    10.2 Краткое изложение схемы авторизации

    Краткое изложение идей авторизации для HTTP представлено в документе RFC-2069 [32].

    4.5.6.1.11. Согласование содержимого

    Большинство HTTP откликов включают в себя объекты, которые содержат информацию для интерпретации человеком-пользователем. Естественно, желательно обеспечить пользователя наилучшим объектом, соответствующим запросу. К сожалению для серверов и кэшей не все пользователи имеют одни и те же предпочтения и не все агенты пользователя в равной степени способны обрабатывать все типы объектов. По этой причине, HTTP имеет несколько механизмов обеспечения согласования содержимого - процесс выбора наилучшего представления для данного отклика, когда доступны несколько возможностей.

    Замечание. Это не называется "согласование формата " потому, что альтернативные представления могут принадлежать к одному и тому же типу среды, но использовать различные возможности этого типа, например, различные иностранные языки.

    Любой отклик, содержащий тело объекта может быть предметом согласования, включая отклики об ошибках. Существует два вида согласования содержимого, которые возможны в HTTP: согласование под управлением сервера и под управлением агента пользователя. Эти два сорта согласования могут использоваться по отдельности или в сочетании. Один из методов, называемый прозрачным согласованием, реализуется, когда кэш использует информацию, полученную от исходного сервера в результате согласования под управлением агента пользователя. Эта информация используется для последующих запросов, где осуществляется согласование под управлением сервера.

    11.1 Согласование, управляемое сервером

    Если выбор наилучшего представления для отклика выполнен с использованием некоторого алгоритма на сервере, такая процедура называется согласованием под управлением сервера. Выбор базируется на доступных представлениях отклика (размеры, в пределах которых он может варьироваться, язык, кодировка и т.д.) и на содержимом конкретных полей заголовка в сообщении-запросе или другой информации, имеющей отношение к запросу (например, сетевой адрес клиента).

    Согласование, управляемое сервером предпочтительнее, когда алгоритм выбора из числа доступных представлений трудно описать агенту пользователя. Согласование под управлением сервера привлекательно тогда, когда сервер хочет послать свои "наилучшие предложения" клиенту вместе с первым откликом (надеясь избежать задержек RTT последующих запросов, если предложение удовлетворит пользователя). Для того чтобы улучшить предложения сервера, агент пользователя может включить в запрос поля заголовка (Accept, Accept-Language, Accept-Encoding, и т.д.), которые описывают его предпочтения для данного запроса. Согласование под управлением сервера имеет следующие недостатки:

    1. Для сервера трудно определить, что является "лучшим" для любого заданного пользователя, так как это потребовало бы полного знания как возможностей агента пользователя, так конкретного назначения отклика (напр., хочет ли пользователь видеть отклик на экране или отпечатать на принтере?).
    2. Заставлять агента пользователя описывать свои возможности при каждом запросе крайне неэффективно (ведь лишь небольшой процент запросов имеют несколько вариантов представления) и потенциально нарушает конфиденциальность пользователя.
    3. Это усложняет реализацию исходного сервера и алгоритм генерации откликов на запросы.
    4. Это может ограничить возможность общедоступного кэша использовать один и тот же отклик для запросов многих пользователей.

    HTTP/1.1 включает в себя следующие поля заголовка запроса для активации согласования, управляемого сервером, через описание возможностей агента пользователя и предпочтений самого пользователя: Accept (раздел 13.1), Accept- Charset (раздел 13.2), Accept-Encoding (раздел 13.3), Accept-Language (раздел 13.4) и User-Agent (раздел 13.42). Однако, исходный сервер не ограничен этими рамками и может варьировать отклик, основываясь на свойствах запроса, включая информацию помимо полей заголовка запроса или используя расширения полей заголовка нерассмотренные в данной спецификации.

    Исходные серверы HTTP/1.1 должны включать соответствующие, управляемом сервером. Поле Vary описывает пределы, в которых может варьироваться отклик (то есть, пределы, в которых исходный сервер выбирает свои "наилучшие предложения" отклика из многообразия редставлений).

    HTTP/1.1 общедоступный кэш должен распознавать поле заголовка Vary, когда оно включено в отклик и подчиняется требованиям, описанным в разделе 12.6, где рассматриваются взаимодействия между кэшированием и согласованием содержимого.

    11.2. Согласование, управляемое агентом (Agent-driven Negotiation)

    При согласовании, управляемом агентом, выбор наилучшего представления для отклика выполняется агентом пользователя после получения стартового отклика от исходного сервера. Выбор базируется на списке имеющихся представлений отклика, включенном в поля заголовка (эта спецификация резервирует имя поля Alternates, как это описано в приложении 16.6.2.1,) или в тело объекта исходного отклика, при этом каждое представление идентифицируется своим собственным URI. Выбор из числа представлений может быть выполнен автоматически (если агент пользователя способен на это) или вручную пользователем, выбирая вариант из гипертекстного меню.

    Согласование, управляемое агентом, имеет преимущество тогда, когда отклик варьируется в определенных пределах (таких как тип, язык или кодирование), когда исходный сервер не способен определить возможности агента пользователя, проанализировав запрос, и вообще, когда общедоступные кэши используются для распределения нагрузки серверов и для снижения сетевого трафика.

    Согласование под управлением агента имеет тот недостаток, что требуется второй запрос для получения наилучшего альтернативного представления. Этот второй запрос эффективен только тогда, когда используется кэширование. Кроме того, эта спецификация не определяет какого-либо механизма поддержки автоматического выбора, хотя она и не препятствует применению любого такого механизма в рамках расширения HTTP/1.1.

    HTTP/1.1 определяет статусные коды 300 (Multiple Choices - множественный выбор) и 406 (Not Acceptable - Не приемлем) для активации согласования под управлением агента, когда сервер не хочет или не может обеспечить свой механизм согласования.

    11.3 Прозрачное согласование (Transparent Negotiation)

    Прозрачное согласование представляет собой комбинацию управления сервера и агента. Когда кэш получает форму списка возможных представлений откликов (как в согласовании под управлением агента) и кэшу полностью поняты пределы вариации, тогда кэш становится способным выполнить согласование под управлением сервера для исходного сервера при последующих запросах этого ресурса.

    Прозрачное согласование имеет преимущество распределения работы согласования, которое в противном случае было бы выполнено исходным сервером. При этом удаляется также задержка, сопряженная со вторым запросом при схеме согласования под управлением агента, когда кэш способен правильно прогнозировать отклик.

    Эта спецификация не определяет какого-либо механизма для прозрачного согласования, хотя она и не препятствует использованию таких механизмов в будущих версиях HTTP/1.1. Выполнение прозрачного согласования кэшем HTTP/1.1 должно включать в отклик поле заголовка Vary (определяя пределы его вариаций), обеспечивая корректную работу со всеми клиентами HTTP/1.1.

    4.5.6.1.12 Кэширование в HTTP

    HTTP обычно используется для распределенных информационных систем, где эксплуатационные характеристики могут быть улучшены за счет применения кэширования откликов. Протокол HTTP/1.1 включает в себя много элементов, предназначенных для оптимизации такого кэширования. Благодаря тому, что эти элементы завязаны с другими аспектами протокола и из-за их взаимодействия друг с другом, полезно описать базовую схему кэширования в HTTP отдельно от детального рассмотрения методов, заголовков, кодов откликов и т.д.

    Кэширование представляется бесполезным, если оно значительно не улучшит работу. Целью кэширования в HTTP/1.1 является исключение во многих случаях необходимости посылать запросы, а в некоторых других случаях - полные отклики. При этом уменьшается число необходимых RTT для многих операций. Для этих целей используется механизм "истечения срока" (expiration) (см. раздел 12.2). Одновременно снижаются требования к полосе пропускания сети, для чего применяется механизм проверки пригодности (см. раздел 12.3).

    Требования к рабочим характеристикам, доступности и работе без соединения заставляют нас несколько снизить семантическую прозрачность. Протокол HTTP/1.1 позволяет исходным серверам, кэшам и клиентам снизить прозрачность, когда необходимо. Так как непрозрачность операций может поставить в тупик недостаточно опытных пользователей, а также привести к определенной несовместимости для некоторых серверных приложений (таких как торговля по заказу), протокол рекомендует не убирать прозрачность полностью, а лишь несколько ослабить.

    Следовательно, протокол HTTP/1.1 обеспечивает следующие важные моменты:

    1. Протокольные особенности, которые гарантируют полную семантическую прозрачность, когда это требуется всеми участниками процесса.
    2. Протокольные особенности, которые позволяют исходному серверу или агенту пользователя запросить и управлять непрозрачными операциями.
    3. Протокольные особенности, которые позволяют кэшу присоединить предупреждения к откликам, которые не сохраняют запрошенный уровень семантической прозрачности.

    Базовым принципом является возможность для клиентов детектировать любое ослабление семантической прозрачности.

    Замечание. Разработчики серверов, кэшей или клиентов могут столкнуться с решениями, которые не обсуждались в данной спецификации. Если решение может повлиять на семантическую прозрачность, разработчик может ошибаться относительно прозрачной работы, не проведя детального анализа и не убедившись, что нарушение такой прозрачности дает существенные преимущества.

    12.1 Корректность кэша

    Корректный кэш должен реагировать на запрос откликом новейшей версии, которой он владеет. Разумеется, отклик должен соответствовать запросу (см. разделы 12.5, 12.6, и 12.12) и отвечать одному из следующих условий:

    1. Он был проверен на эквивалентность с тем, который бы прислал исходный сервер при соответствующем запросе (раздел 12.3);
    2. Он достаточно нов (см. раздел 12.2). В варианте по умолчанию это означает, что он отвечает минимальным требованиям клиента, сервера и кэша по новизне (см. раздел 13.9). Если исходный сервер задает такие требования, то это только его требования на новизну.
    3. Он включает в себя предупреждение, о нарушении требований новизны клиента или исходного сервера (см. разделы 12.5 и 13.45).
    4. Это сообщение-отклик 304 (Not Modified), 305 (Proxy Redirect), или ошибка (4xx или 5xx).

    Если кэш не может осуществлять обмен с исходным сервером, он должен реагировать в соответствии с вышеприведенными правилами, если отклик может быть корректно обслужен, в противном случае он должен отослать сигнал ошибки или предупреждения, указывающий, что имел место отказ в системе коммуникаций.

    Если кэш получает отклик (полный отклик или код 304 (Not Modified)), который уже не является свежим, кэш должен переадресовать его запросившему клиенту без добавления нового предупреждения, и не удаляя существующего заголовка Warning. Кэшу не следует пытаться перепроверить отклик, так как это может привести к бесконечному зацикливанию. Агент пользователя, который получает устаревший отклик без Warning, может отобразить предупреждение для пользователя.

    12.2 Предупреждения

    Когда кэш присылает опосредованный отклик, который "недостаточно свеж" (с точки зрения условия 2 раздела 12.1), к нему должно быть присоединено предупреждение об этом с использованием заголовка Warning. Это предупреждение позволяет клиентам предпринять соответствующие действия.

    Предупреждения могут использоваться для других целей, как кэшами так и другими системами. Использование предупреждения, а не статусного кода ошибки, отличает эти отклики от действительных отказов в системе.

    Предупреждения всегда допускают кэширование, так как они никогда не ослабляют прозрачности отклика. Это означает, что предупреждения могут передаваться HTTP/1.0 кэшам без опасения, что такие кэши просто передадут их как заголовки объектов отклика.

    Предупреждениям приписаны номера в интервале от 0 до 99. Данная спецификация определяет номера кодов и их значения для каждого из предупреждений, позволяя клиенту или кэшу обеспечить во многих случаях (но не во всех) автоматическую обработку ситуаций.

    Предупреждения несут в себе помимо кода и текст. Текст может быть написан на любом из естественных языков (предположительно базирующемся на заголовках Accept клиента) и включать в себя опционное указание того, какой набор символов используется.

    К отклику может быть присоединено несколько предупреждений (исходным сервером или кэшем), включая несколько предупреждений с идентичным кодом. Например, сервер может выдать одно и то же предупреждение на английском и мордовском.

    Когда к отклику присоединено несколько предупреждений, не будет практичным и разумным отображать их все на экране для пользователя. Эта версия HTTP не специфицирует строгих правил приоритета для принятия решения, какие предупреждения отображать и в каком порядке, но предлагает некоторые эвристические соображения.

    Заголовок Warning и определенные в настоящий момент предупреждения описаны в разделе 13.45.

    12.3 Механизмы управления кэшем

    Базовым механизмом кэша в HTTP/1.1 (времена таймаутов и валидаторы) являются неявные директивы кэша. В некоторых случаях серверу или клиенту может потребоваться выдать прямую директиву кэшу. Для этих целей используется заголовок Cache-Control.

    Заголовок Cache-Control позволяет клиенту или серверу передать большое число директив через запросы или отклики. Эти директивы переписывают указания, которые действуют по умолчанию при реализации алгоритма работы кэша. Если возникает явный конфликт между значениями заголовков, то используется наиболее регламентирующее требование (то есть, то, которое наиболее вероятно сохраняет прозрачность семантики).

    Однако в некоторых случаях директивы Cache-Control сформулированы так, что явно ослабляют семантическую прозрачность (например, "max-stale" или "public"). Директивы Cache-Control подробно описаны в разделе 13.9.

    12.4 Прямые предупреждения агента пользователя

    Многие агенты пользователя позволяют переписывать базовый механизм кэширования. Например, агент пользователя может специфицировать то, какие кэшированные объекты (даже явно старые) не проверять на новизну. Или агент пользователя может всегда добавлять "Cache-Control: max-stale=3600" к каждому запросу.

    Если пользователь переписал базовый механизм кэширования, агент пользователя должен явно указать всякий раз, когда это важно, что отображаемая информация не отвечает требованиям прозрачности (в частности, если отображаемый объект известен как устаревший). Так как протокол обычно разрешает агенту пользователя определять, является ли отклик устаревшим, такая индикация нужна только тогда, когда это действительно случится. Для такой индикации не нужно диалоговое окно; это может быть иконка (например, изображение гнилой рыбы) или какой-то иной визуальный индикатор.

    Если пользователь переписал механизм кэширования таким образом, что он непомерно понизил эффективность кэша, агент пользователя должен непрерывно отображать индикацию (например, изображение горящих денег), так чтобы пользователь, беспечно расходующий ресурсы, страдал от заметной задержки откликов на его действия.

    12.5 Исключения для правил и предупреждений

    В некоторых случаях оператор кэша может выбрать такую конфигурацию, которая возвращает устаревшие отклики, даже если клиенты этого не запрашивали. Это решение не должно приниматься легко, но может быть необходимо по причинам доступности или эффективности, особенно когда кэш имеет плохую связь с исходным сервером. Всякий раз, когда кэш возвращает устаревший отклик, он должен пометить его соответствующим образом (используя заголовок Warning). Это позволяет клиентскому программному обеспечению предупредить пользователя о возможных проблемах.

    Такой подход позволяет также агенту пользователя предпринять шаги для получения "свежего" отклика или информации из первых рук. По этой причине кэшу не следует присылать устаревшие отклики, если клиент запрашивает информацию из первых рук, если только невозможно это сделать по техническим или политическим причинам.

    12.6 Работа под управлением клиента

    Когда основным источником устаревшей информации является исходный сервер (и в меньшей мере промежуточные кэши), клиенту может быть нужно контролировать решение кэша о том, следует ли присылать кэшированный отклик без его проверки. Клиенты выполняют это, используя несколько директив заголовка Cache-Control.

    Запрос клиента может специфицировать максимальный возраст, который он считает приемлемым для не верифицированного отклика. Клиент может также специфицировать минимальное время, в течение которого отклик еще считается пригодным для использования. Обе эти опции увеличивают ограничения, накладываемые на работу кэша.

    Клиент может также специфицировать то, что он будет воспринимать устаревшие отклики с возрастом не более заданного. Это ослабляет ограничения, налагаемые на работу кэшей и, таким образом, может привести к нарушению семантической прозрачности, заданной исходным сервером, хотя это может быть необходимо для поддержания автономной работы кэша в условиях плохой коннективности.

    12.7. Модель истечения срока годности
    12.7.1 Определение срока годности под управлением сервера

    Кэширование в HTTP работает наилучшим образом, когда кэши могут полностью исключить запросы к исходному серверу. Другими словами, кэш должен возвращать "свежий" отклик без обращения к серверу.

    Предполагается, что серверы припишут в явном виде значения времени пригодности (expiration time) откликам в предположении, что объекты вряд ли изменятся семантически значимым образом до истечения этого времени. Это сохраняет семантическую прозрачность при условии, что время жизни выбрано корректно.

    Механизм времени пригодности (expiration) применим только к откликам, взятым из кэша, а не к откликам, полученным из первых рук и переадресованных запрашивающему клиенту.

    Если исходный сервер хочет усилить семантическую прозрачность кэша, тогда он может установить время истечения действия в прошлое, чтобы проверялся каждый запрос. Это означает, что всякий запрос изначально будет считаться устаревшим, и кэш будет вынужден проверить его прежде чем использовать для последующих запросов. О более жестких методах вынуждения проверки действенности отклика смотри раздел 13.9.4.

    Если исходный сервер хочет заставить любой HTTP/1.1 кэш, вне зависимости от его конфигурации проверять каждый запрос, он может использовать директиву Cache-Control "must-revalidate" (см. раздел 13.9).

    Серверы определяют реальные времена сроков пригодности, используя заголовок Expires, или директиву максимального возраста заголовка Cache-Control.

    Время пригодности (expiration time) не может использоваться для того, чтобы заставить агента пользователя обновить картинку на дисплее или перезагрузить ресурс; его семантика применима только для механизма кэширования, а такой механизм нуждается только в контроле истечения времени жизни ресурса, когда инициируется новый запрос доступа к этому ресурсу.

    12.7.2 Эвристический контроль пригодности

    Так как исходные сервера не всегда предоставляют значение времени пригодности в явном виде, HTTP кэши присваивают им значения эвристически, используя алгоритмы, которые привлекают для оценки вероятного значения времени пригодности другие заголовки (такие как Last-Modified time). Спецификация HTTP/1.1 не предлагает каких-либо специальных алгоритмов, но налагает предельные ограничения на полученный результат. Так как эвристические значения времени жизни могут подвергнуть риску семантическую прозрачность, они должны использоваться с осторожностью. Предпочтительнее, чтобы исходные серверы задавали время пригодности явно.

    12.7.3. Вычисление возраста

    Для того чтобы узнать является ли запись в кэш свежей, кэшу нужно знать превышает ли его возраст предельное время жизни. То, как вычислить время пригодности, обсуждается в разделе 12.7.4. Этот раздел описывает метод вычисления возраста отклика или записи в кэше.

    В этом обсуждении используется термин "сейчас" для обозначения "текущего показания часов на ЭВМ, выполняющей вычисление". ЭВМ, которая использует HTTP, и в особенности ЭВМ, работающие в качестве исходных серверов и кэшей, должны использовать NTP [28] или некоторый схожий протокол для синхронизации их часов с использованием общего точного временного стандарта.

    Следует обратить внимание на то, что HTTP/1.1 требует от исходного сервера посылки в каждом отклике заголовка Date, сообщая время, когда был сгенерирован отклик. Мы используем термин "date_value" для обозначения значения заголовка Date, в форме, приемлемой для арифметических операций.

    HTTP/1.1 использует заголовок отклика Age для того, чтобы облегчить передачу информации о возрасте объектов между кэшами. Значение заголовка Age равно оценке отправителя времени, прошедшего с момента генерации отклика исходным сервером. В случае кэшированного отклика, который был перепроверен исходным сервером, значение Age базируется на времени перепроверки, а не на времени жизни оригинального отклика.

    По существу значение Age равно сумме времени, в течение которого отклик был резидентен в каждом из кэшей вдоль пути от исходного сервера, плюс время распространения данных по сети.

    Мы используем термин "age_value" для значения поля заголовка Age, в удобном для выполнения арифметических операций формате. Возраст отклика может быть вычислен двумя совершенно независимыми способами.

    1. Текущее время минус date_value, если местные часы синхронизованы с часами исходного сервера. Если результат отрицателен, он заменяется на нуль.
    2. age_value, если все кэши вдоль пути отклика поддерживают HTTP/1.1.

    Таким образом, мы имеем два независимых способа вычисления возраста отклика при его получении, допускается их комбинирование, например:

    corrected_received_age = max(now - date_value, age_value)

    и, поскольку мы имеем синхронизованные часы, или все узлы вдоль пути поддерживают HTTP/1.1, получается надежный (консервативный) результат.

    Заметьте, что поправка применяется в каждом кэше HTTP/1.1 вдоль пути так, что, если встретится на пути кэш HTTP/1.0, правильное значение возраста будет получено потому, что его часы почти синхронизованы. Нам не нужна сквозная синхронизация (хотя ее не плохо бы иметь).

    Из-за задержек, вносимых сетью, значительное время может пройти с момента генерации отклика сервером и получением его следующим кэшем или клиентом. Если не внести поправки на эту задержку, можно получить неправдоподобные значения возраста отклика.

    Так как запрос, который определяет возвращаемое значение Age, должен быть инициирован до генерации этого значения Age, мы можем сделать поправку на задержки, вносимые сетью путем записи времени, когда послан запрос. Затем, когда получено значение Age, оно должно интерпретироваться относительно времени посылки запроса, а не времени когда был получен отклик. Этот алгоритм выдает результат, который не зависит от величины сетевой задержки. Таким образом, вычисляется:

    corrected_initial_age = corrected_received_age + (now - request_time)

    где "request_time" равно времени (согласно местным часам), когда был послан запрос, вызвавший данный отклик.

    Резюме алгоритма вычисления возраста при получении отклика кэшем:

    /*
    * age_value

    *

    равно значению Age: заголовок, полученный кэшем с этим откликом.

    * date_value

    *

    равно значению Date исходного сервера: заголовок

    * request_time

    *

    равно местному времени, когда кэш сделал запрос, который явился причиной этого кэшированного отклика

    * response_time

    *

    равно местному времени, когда кэш получил отклик

    * now

    *

    равно текущему (местному) времени

    */

    apparent_age = max(0, response_time - date_value);
    corrected_received_age = max(apparent_age, age_value);
    response_delay = response_time - request_time;
    corrected_initial_age = corrected_received_age + response_delay;
    resident_time = now - response_time;
    current_age = corrected_initial_age + resident_time;

    Когда кэш посылает отклик, он должен добавить к corrected_initial_age время, в течение которого отклик оставался резидентно локальным. Он должен ретранслировать этот полный возраст, используя заголовок Age, следующему кэшу-получателю.

    Заметьте, что клиент не может надежно сказать, что отклик получен из первых рук, но присутствие заголовка Age определенно указывает на то, что это не так. Кроме того, если значение в отклике соответствует более раннему времени, чем местное время запроса клиента, отклик, вероятно, получен не из первых рук (в отсутствие серьезного сбоя часов).

    12.4 Вычисление времени жизни (Expiration)

    Для того, чтобы решить, является ли отклик свежим или устаревшим, нам нужно сравнить его время жизни с возрастом. Возраст вычисляется так, как это описано в разделе 12.3. Этот раздел описывает то, как вычисляется время жизни, и как определяется, истекло ли время жизни отклика. В обсуждении, приведенном ниже, величины могут быть представлены в любой форме, удобной для выполнения арифметических операций.

    Мы используем термин "expires_value" для обозначения содержимого заголовка Expires. Для обозначения числа секунд, определенного директивой максимального возраста заголовка Cache-Control отклика (см. раздел 13.9), используется термин "max_age_value".

    Директива максимального возраста имеет приоритет перед Expires, так если max-age присутствует в отклике, вычисление производится просто:

    freshness_lifetime = max_age_value

    В противном случае, если в отклике присутствует Expires, то вычисления осуществляются следующим образом:

    freshness_lifetime = expires_value - date_value

    Заметьте, ни одно из этих вычислений не зависит от синхронизации и корректной работы местных часов, так как вся исходная информация получается от исходного сервера.

    Если ни Expires, ни Cache-Control: max-age не определяют максимальный возраст отклика, а отклик не содержит других ограничений на кэширование, кэш может вычислить время жизни, используя эвристику. Если эта величина больше 24 часов, кэш должен присоединить к отклику Warning 13, если такое предупреждение еще не добавлено.

    Кроме того, если отклик имеет время Last-Modified, эвристическое значение времени жизни должно быть не больше некоторой доли времени, прошедшего со времени модификации. Типичное значение этой доли может составлять 10%.

    Расчет того, истекло ли время жизни отклика, достаточно прост:

    response_is_fresh = (freshness_lifetime > current_age)

    12.5 Устранение неопределенности значений времени жизни

    Из-за того, что значения времени жизни часто назначаются оптимистически, может так случиться, что два кэша содержат две "свежих" записи одного и того же ресурса, которые различаются.

    Если клиент, выполняя извлечение ресурса, получает отклик не из первых рук на запрос, который был свежим в своем собственном кэше, а заголовок Date в его кэше новей, чем Date нового отклика, тогда клиент может игнорировать этот отклик. Если это так, он может повторить запрос с директивой "Cache-Control: max-age=0" (см. раздел 13.9), чтобы усилить контроль со стороны исходного сервера.

    Если кэш имеет два свежих отклика для одного и того же представления с различными указателями корректности (validator), он должен использовать тот, который имеет современный заголовок Date. Эта ситуация может возникнуть, когда кэш извлекает отклик из других кэшей, или потому, что клиент запросил перезагрузку или повторную проверку корректности заведомо свежего объекта.

    12.6 Неопределенность из-за множественных откликов

    Из-за того, что клиент может получать отклики по большому числу различных маршрутов, так что некоторые отклики проходят через одну последовательность кэшей, а другие, через другую, клиент может получить их не в той последовательности в какой они были посланы исходным сервером. Хотелось бы, чтобы клиент использовал наиболее свежие оклики, даже если срок годности старых еще не истек.

    Ни метка объекта, ни значение времени жизни не могут определять порядок откликов, так как возможно, что более поздний отклик имеет срок годности, который истекает раньше. Однако, спецификация HTTP/1.1 требует передачи заголовка Date в каждом отклике, а значения Date должны быть кратны одной секунде.

    Когда клиент пытается перепроверить запись в кэше, а отклик, который он получает, содержит заголовок Date, который оказывается старше, чем у другой уже существующей записи, тогда клиенту следует безусловно повторить запрос и включить

    Cache-Control: max-age=0

    Чтобы заставить некоторые промежуточные кэши сверить свои копии непосредственно с исходным сервером, или

    Cache-Control: no-cache

    Чтобы заставить любые промежуточные кэши получит новые копии от исходного сервера.

    Если значения Date равны, тогда клиент может использовать любой отклик (или может, если он особенно осторожен, затребовать новый отклик). Серверы не должны зависеть от возможности клиентов четкого выбора между откликами, сгенерированными в пределах одной и той же секунды, если их сроки пригодности перекрываются.

    12.8 Модель проверки пригодности

    Когда кэш имеет устаревшую запись, которую бы он хотел использовать в качестве отклика на запрос клиента, он сначала должен произвести сверку с базовым сервером (или возможно промежуточным кэшем, содержащим свежий отклик), чтобы убедиться, что кэшированная запись все еще применима. Мы это называем проверкой пригодности записи кэша ("validating"). Так как мы не хотим пересылки всей записи, если с ней все в порядке, и мы не хотим тратить лишнее время из-за RTT в случае, если запись более не пригодна, протокол HTTP/1.1 поддерживает использование условных методов.

    Ключевой особенностью протокола для поддержки условных методов являются так называемые "валидаторы" кэша. Когда исходный сервер генерирует полный отклик, он подключает к нему некоторые виды валидаторов, которые хранятся вместе с самой записью в кэше. Когда клиент (агент пользователя или прокси-кэш) выполняет условный запрос ресурса, для которого он имеет запись в кэше, он добавляет соответствующий валидатор к запросу.

    Сервер сверяет полученный валидатор с текущим валидатором объекта и, если они совпадают, посылается отклик с соответствующим статусным кодом (обычно, 304 (Not Modified)) и без тела объекта. В противном случае он возвращает полный отклик (включая тело объекта). Таким образом, мы избегаем передачи полного отклика, если валидаторы взаимно согласованы.

    Замечание. Функции сравнения, используемые при решении, согласуются ли между собой валидаторы, определены в разделе 12.8.3.

    В HTTP/1.1 условный запрос выглядит точно также как и обычный запрос того же самого ресурса, за исключением того, что он несет в себе специальный заголовок (который содержит валидатор), и неявно меняет метод (обычный GET) на условный.

    Протокол предусматривает как положительное, так и отрицательное значения условий проверки пригодности записей кэша. То есть, можно запросить, чтобы был реализован этот метод тогда и только тогда, когда валидатор подходит, или тогда и только тогда, когда ни один валидатор не подходит.

    Замечание. Отклик, который не имеет валидатора, может кэшироваться и использоваться до истечения его срока годности, если только это явно не запрещено директивой Cache-Control. Однако, кэш не может выполнить условную доставку ресурса, если он не имеет валидатора для запрашиваемого объекта, что означает отсутствие возможности его актуализации после истечения срока годности.

    12.8.1 Даты последней модификации

    Значение поля заголовка объекта Last-Modified часто используется кэшем в качестве валидатора. Иными словами, запись в кэше рассматривается как пригодная, если объект не был модифицирован с момента, указанного в Last-Modified.

    12.8.2 Валидаторы кэша для меток объектов (Entity Tag Cache Validators)

    Значение поля заголовка объекта ETag (Entity Tag - метка объекта), представляет собой "непрозрачный" валидатор кэша. Это может гарантировать большую надежность при контроле пригодности в ситуациях, когда неудобно запоминать модификации дат, где недостаточно односекундного разрешения для значения даты HTTP или где исходный сервер хочет избежать определенных парадоксов, которые могут возникнуть от использования дат модификации.

    Метки объекта обсуждаются в разделе 3.10. Заголовки, используемые с метками объектов, рассмотрены в разделах 13.20, 13.25, 13.26 и 13.43.

    12.8.3 Слабые и сильные валидаторы

    Так как исходные серверы и кэши будут сравнивать два валидатора, чтобы решить, представляют ли они один и тот же объект, обычно подразумевается, что, если объект (тело объекта или любой заголовок) изменяется каким-либо образом, то и сопряженный валидатор изменится. Если это так, такой валидатор называется "сильным ".

    Однако могут встретиться случаи, когда сервер предпочитает изменять валидатор только при семантически существенных изменениях. Валидатор, который не изменяется всякий раз при изменении ресурса, называется "слабым".

    Метки объекта обычно являются "сильными валидаторами", но протокол предлагает механизм установки "слабой" метки объекта. Можно считать, что сильный валидатор это такой, который изменяется, если меняется хотя бы один бит в объекте, в то время как значение слабого изменяется при вариации значения объекта. Альтернативой можно считать точку зрения, при которой сильный валидатор является частью идентификатора конкретного объекта, в то время как слабый валидатор является частью идентификатора набора семантически эквивалентных объектов.

    Замечание. Примером сильного валидатора является целое число, которое увеличивается на единицу всякий раз, когда в объект вносится какое-либо изменение.

    Время модификации объекта при односекундном разрешении может быть лишь слабым валидатором, так как имеется возможность того, что ресурс может быть модифицирован дважды в течение одной и той же секунды.

    Поддержка слабых валидаторов является опционной. Однако слабый валидатор позволяет более эффективно кэшировать эквивалентные объекты.

    Валидатор используется либо, когда клиент генерирует запрос и включает валидатор в поле заголовка проверки годности, или когда сервер сравнивает два валидатора.

    Сильные валидаторы могут использоваться в любом контексте. Слабые валидаторы применимы только в контексте, который не зависит от точной эквивалентности объектов. Например, как один, так и другой вид валидаторов применим для условного GET. Однако, только сильный валидатор применим для фрагментированного извлечения ресурсов, так как в противном случае клиент может прервать работу с внутренне противоречивым объектом.

    Единственной функцией протокола HTTP/1.1, определенной для валидаторов, является сравнение. Существует две функции сравнения валидаторов, в зависимости от того, допускает ли контекст использование слабых валидаторов или нет:

    • Функция сильного сравнения. Для того, чтобы считаться равными оба валидатора должны быть идентичными, и не один из них не должен быть слабым.
    • Функция слабого сравнения. Для того, чтобы считаться равными оба валидатора должны быть идентичными, но либо оба, либо один из них могут иметь метку "слабый" без какого-либо воздействия на результат.

    Функция слабого сравнения может быть использована для простых (non-subrange - не фрагментных) GET-запросов. Функция сильного сравнения должна быть использована во всех прочих случаях.

    Метка объекта является сильной, если она не помечена явно как слабая. В разделе 2.11 рассматривается синтаксис меток объектов.

    Параметр Last-Modified time, при использовании в качестве валидатора запроса, является неявно (подразумевается) слабым, если не возможно установить, что он сильный, используя следующие правила:

    • Валидатор сравнивается исходным сервером с текущим рабочим валидатором для данного объекта и,
    • Исходный сервер твердо знает, что соответствующий объект не изменялся дважды за секунду, к которой привязан настоящий валидатор. Или
    • Валидатор предполагается использовать клиентом в заголовке If-Modified-Since или If-Unmodified-Since, так как клиент имеет запись в кэше для соответствующего объекта, и
    • Эта запись в кэш включает в себя значение Date, которое определяет время, когда исходный сервер послал оригинал запроса, и
    • Предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.

    или

    • Валидатор сравнивается промежуточным кэшем с валидатором, запомненным в записи для данного объекта, и
    • Эта запись в кэше включает в себя значение Date, которое определяет время, когда исходный сервер послал оригинал запроса, и
    • Предлагаемый параметр Last-Modified time соответствует моменту времени, по крайней мере, на 60 секунд раньше значения Date.

    Этот метод базируется на том факте, что, если два различных отклика были посланы исходным сервером в пределах одной и той же секунды, но оба имеют одно и то же время Last-Modified, тогда, по крайней мере, один из этих откликов имеет значение Date равное его времени Last-Modified. Произвольный 60-секундный лимит предохраняет против возможности того, что значения Date и Last-Modified сгенерированы с использованием различных часов или в несколько разные моменты времени при подготовке отклика. Конкретная реализация может использовать величину больше 60 секунд, если считается, что 60 секунд слишком мало.

    Кэш или исходный сервер, получающий условный запрос кэша, отличный от GET-запроса, должен использовать функцию сильного сравнения, чтобы оценить условие.

    Эти правила позволяют кэшам HTTP/1.1 и клиентам безопасно произвести фрагментный доступ к ресурсам на глубину, которая получена от серверов HTTP/1.0.

    12.8.4 Правила того, когда использовать метки объекта и даты последней модификации

    Мы принимаем набор правил и рекомендаций для исходных серверов, клиентов и кэшей относительно того, когда должны использоваться различные типы валидаторов и для каких целей.

    Исходный сервер HTTP/1.1:

    • Должен послать валидатор метки объекта, если только возможно его сгенерировать.
    • Может послать слабую метку объекта вместо сильной, если рабочие соображения поддерживают использования слабых меток объекта или если невозможно послать сильную метку объекта.
    • Должен послать значение Last-Modified, когда это возможно сделать, если только риск нарушения семантической прозрачности, которое может явиться следствием использования этой даты в заголовке, не приведет к серьезным проблемам.

    Другими словами предпочтительным поведением для исходного сервера HTTP/1.1 является посылка сильной метки объекта и значения Last-Modified.

    Для сохранения легальности сильная метка объекта должна изменяться всякий раз, когда каким-либо образом меняется ассоциированное значение объекта. Слабую метку объекта следует менять всякий раз, когда соответствующий объект изменяется семантически значимым образом.

    Замечание. Для того, чтобы обеспечить семантически прозрачное кэширование, исходный сервер должен избегать повторного использования специфических, сильных меток для двух разных объектов, или повторного использования специфических, слабых меток для двух семантически разных объектов. Записи в кэш могут существовать сколь угодно долгое время вне зависимости от времени годности. Таким образом, может оказаться неразумным ожидать, что кэш никогда вновь не попытается перепроверить запись, используя валидатор, который он получил в какой-то момент в прошлом.

    Клиенты HTTP/1.1:

    • Если метка объекта была прислана исходным сервером, эта метка должна быть использована в любом условном запросе кэша (с If-Match или If-None-Match).
    • Если только значение Last-Modified было прислано исходным сервером, оно должно использоваться в нефрагментных, условных запросах кэша (с использованием If-Modified-Since).
    • Если только значение Last-Modified было прислано исходным сервером HTTP/1.0, оно может использоваться в фрагментных, условных запросах кэша (с использованием If-Unmodified-Since:). Агенту пользователя следует обеспечить способ блокировки этого в случае возникновения трудностей.
    • Если и метка объекта и значение Last-Modified были присланы исходным сервером, в условных запросах кэша следует использовать оба валидатора. Это позволяет корректно реагировать кэшам, поддерживающим как HTTP/1.0, так и HTTP/1.1.

    Кэш HTTP/1.1 при получении запроса должен использовать наиболее регламентирующий валидатор, когда проверяется, соответствуют ли друг другу запись в буфере клиента и собственная запись в кэше. Это единственный выход, когда запрос содержит как метку объекта, так и валидатор last-modified-date (If-Modified-Since или If-Unmodified-Since).

    Базовым принципом всех этих правил является то, что HTTP/1.1 серверы и клиенты должны пересылать как можно больше надежной информации в своих запросах и откликах. HTTP/1.1 системы, принимая эту информацию, используют наиболее консервативное предположение относительно валидаторов, которые они получают.

    Клиенты HTTP/1.0 и кэши будут игнорировать метки объектов. Вообще, значения времени последней модификации, полученные или используемые этими системами, будут поддерживать прозрачное и эффективное кэширование и, по этой причине, исходные серверы HTTP/1.1 должны присылать значения параметров Last-Modified. В тех редких случаях, когда в качестве валидатора системой HTTP/1.0 используется значение Last-Modified, могут возникнуть серьезные проблемы, и тогда исходные серверы HTTP/1.1 присылать их не должны.

    12.8.5 Условия пригодности

    Принцип использования меток объектов базируется на том, что только автор услуг знает семантику ресурсов достаточно хорошо, чтобы выбрать подходящий механизм контроля кэширования. Спецификация любой функции сравнения валидаторов более сложна, чем сравнение байтов. Таким образом, для целей проверки пригодности записи в кэше никогда не используется сравнение любых других заголовков кроме Last-Modified, для совместимости с HTTP/1.0.

    12.9. Кэшируемость отклика

    Если только нет специального ограничения директивой Cache-Control (раздел 13.9), система кэширования может всегда запоминать отклик (см. раздел 12.8) в качестве записи в кэш, может прислать его без проверки пригодности, если он является свежим, и может послать его после успешной проверки пригодности. Если нет ни валидатора кэша ни времени пригодности, ассоциированного с этим откликом, мы не ожидаем, что такой отклик будет кэширован, но некоторые кэши могут нарушить это правило (например, когда имеется плохая коннективность или она вообще отсутствует). Клиент обычно может детектировать, что такой отклик был взят из кэша после сравнения заголовка Date с текущим временем.

    Заметьте, что некоторые кэши HTTP/1.0 нарушают эти правила, даже не присылая предупреждения.

    Однако, в некоторых случаях может быть неприемлемо для кэша сохранять объект или присылать его в ответ на последующие запросы. Это может быть потому, что автор сервиса полагает необходимой абсолютную семантическую прозрачность по соображениям безопасности или конфиденциальности. Определенные директивы Cache-Control предназначены для того, чтобы сервер мог указать, что некоторые объекты ресурсов или их части не могут кэшироваться ни при каких обстоятельствах.

    Заметьте, что раздел 13.8 в норме препятствует кэшу запоминать и отсылать отклик на предыдущий запрос, если этот запрос включает в себя заголовок авторизации.

    Отклик, полученный со статусным кодом 200, 203, 206, 300, 301 или 410, может быть запомнен кэшем и использован в ответе на последующие запросы, если директива не препятствует кэшированию. Однако, кэш, который не поддерживает заголовки Range и Content-Range не должен кэшировать отклики 206 (Partial Content).

    Отклик, полученный с любым другим статусным кодом, не должен отсылаться в ответ на последующие запросы, если только нет директив Cache-Control или других заголовков, которые напрямую разрешают это. К таким, например, относятся: заголовок Expires (раздел 13.21); "max-age", "must-revalidate", "proxy-revalidate", "public" или "private" директива Cache-Control (раздел 13.9).

    12.10 Формирование откликов кэшей

    Целью кэша HTTP является запоминание информации, полученной в откликах на запросы, для использования в ответ на будущие запросы. Во многих случаях, кэш просто отсылает соответствующие части отклика отправителю запроса. Однако, если кэш содержит объект, базирующийся на предшествующем отклике, он может быть вынужден комбинировать части нового отклика с тем, что хранится в объекте кэша.

    12.10.1 Заголовки End-to-end (точка-точка) и Hop-by-hop (шаг-за-шагом)

    Для целей определения поведения кэшей и некэшурующих прокси-серверов заголовки HTTP делятся на две категории:

    • Заголовки End-to-end, которые должны быть пересланы конечному получателю запроса или отклика. Заголовки End-to-end в откликах должны запоминаться как часть объекта кэша и пересылаться в любом отклике, полученном из записи кэша.
    • Заголовки Hop-by-hop, которые имеют смысл только для одноуровневого транспортного соединения, они не запоминаются кэшем и не переадресуются прокси-серверами.

    Следующие заголовки HTTP/1.1 относятся к категории hop-by-hop:

    • Connection
    • Keep-Alive
    • Public
    • Proxy-Authenticate
    • Transfer-Encoding
    • Upgrade

    Все другие заголовки, определенные HTTP/1.1 относятся к категории end-to-end.

    Заголовки Hop-by-hop, вводимые в будущих версиях HTTP, должны быть перечислены в заголовке Connection, как это описано в разделе 13.10.

    12.10.2 Немодифицируемые заголовки

    Некоторые черты протокола HTTP/1.1, такие как Digest Authentication, зависят от значения определенных заголовков end-to-end. Кэш или некэширующий прокси не должны модифицировать заголовок end-to-end, если только определение этого заголовка не требует или не разрешает этого.

    Кэш или некэширующий прокси не должны модифицировать любое из следующих полей запроса или отклика или добавлять какие-либо поля, если они еще не существуют:

    • Content-Location
    • Etag
    • Expires
    • Last-Modified

    Кэш или некэширующий прокси не должны модифицировать или добавлять следующие поля в любых запросах и в откликах, которые содержат директиву no-transform Cache-Control:

    • Content-Encoding
    • Content-Length
    • Content-Range
    • Content-Type

    Кэш или некэширующий прокси могут модифицировать или добавлять эти поля в отклик, который не включает директиву no-transform. Если же он содержит эту директиву, следует добавить предупреждение 14 (Transformation applied), если оно еще не занесено в отклик.

    Предупреждение. Ненужная модификация заголовков end-to-end может вызвать отказы в авторизации, если в поздних версиях HTTP использован более строгий механизм. Такие механизмы авторизации могут использовать значения полей заголовков не перечисленных здесь.

    12.10.3 Комбинирование заголовков

    Когда кэш делает запрос серверу о пригодности ресурса и сервер выдает отклик 304 (Not Modified), кэш должен подготовить и отправить отклик, чтобы послать клиенту. Кэш использует тело объекта из записи в кэше при формировании отклика. Заголовки end-to-end записанные в кэше, используются для конструирования отклика. Исключение составляют любые end-to-end заголовки, поступившие в рамках отклика 304, они должны заместить соответствующие заголовки из записи в кэше. Если только кэш не решил удалить запись, он должен также заменить end-to-end заголовки своей записи соответствующими заголовками из полученного отклика.

    Другими словами, набор end-to-end заголовков, полученный вместе откликом переписывает все соответствующие end-to-end заголовки, из записи в кэше. Кэш может добавить к этому набору заголовки предупреждений (см. раздел 13.45).

    Если имя поля заголовка приходящего отклика соответствует более чем одной записи в кэше, все старые заголовки заменяются.

    Замечание. Это правило позволяет исходному серверу использовать отклик 304 (Not Modified) для актуализации любого заголовка, связанного с предыдущим откликом для того же объекта, хотя это может не всегда иметь смысл. Это правило не позволяет исходному серверу использовать отклик 304 (not Modified) для того, чтобы полностью стереть заголовок, который был прислан предыдущим откликом.

    12.10.4 Комбинирование байтовых фрагментов

    Отклик может передать только субдиапазон байтов тела объекта, либо потому, что запрос включает в себя один или более спецификаций Range, либо из-за преждевременного обрыва соединения. После нескольких таких передач кэш может получить несколько фрагментов тела объекта.

    Если кэш запомнил не пустой набор субфрагментов объекта, а входящий отклик передает еще один фрагмент, кэш может комбинировать новый субфрагмент с уже имеющимся набором, если для обоих выполняются следующие условия:

    • Оба приходящие отклика и запись в кэше должны иметь валидатор кэша.
    • Оба валидатора кэша должны соответствовать функции сильного сравнения (см. раздел 12.8.3).

    Если любое из условий не выполнено, кэш должен использовать только наиболее поздний частичный отклик и отбросить другую частичную информацию.

    12.11. Кэширование согласованных откликов

    Использование согласования содержимого под управлением сервера (раздел 11), что индицируется присутствием поля заголовка Vary в отклике, изменяет условия и процедуру, при которой кэш может использовать отклик для последующих запросов.

    Сервер должен использовать поле заголовка Vary (раздел 13.43), чтобы информировать кэш о том, какие пределы для поля заголовка используются при выборе представления кэшируемого отклика. Кэш может использовать выбранное представление для ответов на последующие запросы, только когда они имеют те же или эквивалентные величины полей заголовка, специфицированных в заголовке отклика Vary. Запросы с различными значениями одного или нескольких полей заголовка следует переадресовывать исходному серверу.

    Если представлению присвоена метка объекта, переадресуемый запрос должен быть условным и содержать метки в поле заголовка If-None-Match всех его кэшированных записей для Request-URI. Это сообщает серверу набор объектов, которые в настоящее время хранятся в кэше, так что, если любая из этих записей соответствует запрашиваемому объекту, сервер может использовать заголовок ETag в своем отклике 304 (Not Modified), чтобы сообщить кэшу, какой объект подходит. Если метка объекта нового отклика соответствует существующей записи, новый отклик должен быть использован для актуализации полей заголовка существующей записи, а результат должен быть прислан клиенту.

    Поле заголовка Vary может также информировать кэш, что представление было выбрано с использованием критериев помимо взятых из заголовков запросов. В этом случае, кэш не должен использовать отклик в ответ на последующий запрос, если только кэш не передает исходному серверу условный запрос. Сервер при этом возвращает отклик 304 (Not Modified), включая метку объекта или поле Content-Location, которые указывают, какой объект должен быть использован.

    Если какая-то запись кэша содержит только часть информации для соответствующего объекта, его метка не должна содержаться в заголовке If-None-Match, если только запрос не лежит в диапазоне, который полностью покрывается этим объектом.

    Если кэш получает позитивный отклик с полем Content-Location, соответствующим записи в кэше для того же Request-URI, с меткой объекта, отличающейся от метки существующего объекта, и датой современнее даты существующего объекта, данная запись не должна использоваться в качестве отклика для будущих запросов и должна быть удалена из кэша.

    12.12. Кэши коллективного и индивидуального использования

    По причинам безопасности и конфиденциальности необходимо делать различие между кэшами совместного и индивидуального использования. Индивидуальные кэши доступны только для одного пользователя. Доступность в этом случае должна определяться соответствующим механизмом, обеспечивающим безопасность. Все другие кэши рассматриваются как коллективные. Другие разделы этой спецификации накладывают определенные ограничения на работу совместно используемых кэшей, для того, чтобы предотвратить потерю конфиденциальности или управления доступом.

    12.13. Ошибки и поведение кэша при неполном отклике

    Кэш, который получает неполный отклик (например, с меньшим числом байтов, чем специфицировано в заголовке Content-Length) может его запомнить. Однако, кэш должен воспринимать эти данные как частичный отклик. Частичные отклики могут компоноваться, как это описано в разделе 12.5.4. Результатом может быть полный или частичный отклик. Кэш не должен возвращать частичный отклик клиенту без явного указания на то, что он частичный, используя статусный код 206 (Partial Content). Кэш не должен возвращать частичный отклик, используя статусный код 200 (OK).

    Если кэш получает отклик 5xx при попытке перепроверить запись, он может переадресовать этот отклик запрашивающему клиенту или действовать так, как если бы сервер не смог ответить на запрос. В последнем случае он может вернуть отклик, полученный ранее, если только запись в кэше не содержит директиву Cache-Control "must-revalidate" (см. раздел 13.9).

    12.14. Побочные эффекты методов GET и HEAD

    Если исходный сервер напрямую не запрещает кэширование своих откликов, методы приложения GET и HEAD не должны давать каких-либо побочных эффектов, которые вызывали бы некорректное поведение, если эти отклики берутся из кэша. Они все же могут давать побочные эффекты, но кэш не обязан рассматривать такие побочные эффекты, принимая решение о кэшировании. Кэши контролируют лишь прямые указания исходного сервера о запрете кэширования.

    Обратим внимание только на одно исключение из этого правила: некоторые приложения имеют традиционно используемые GET и HEAD с запросами URL (содержащими "?" в части rel_path) для выполнения операций с ощутимыми побочными эффектами. Кэши не должны обрабатывать отклики от таких URL, как свежие, если только сервер не присылает непосредственно значение времени жизни. Это в частности означает, что отклики от серверов HTTP/1.0 для этих URI не следует брать из кэша. Дополнительную информацию по смежным темам можно найти в разделе 8.1.1.

    12.15 Несоответствие после актуализации или стирания

    Воздействие определенных методов на исходный сервер может вызвать то, что одна или более записей, имеющихся в кэше, становятся неявно непригодными. То есть, хотя они могут оставаться "свежими", они не вполне точно отражают то, что исходный сервер пришлет в ответ на новый запрос.

    В протоколе HTTP не существует способа гарантировать, что все такие записи в кэше будут помечены как непригодные. Например, запрос, который вызывает изменение в исходном сервере не обязательно проходит через прокси, где в кэше хранится такая запись. Однако несколько правил помогает уменьшить вероятность некорректного поведения системы.

    В этом разделе, выражение "пометить объект как непригодный" означает, что кэш должен либо удалить все записи, относящиеся к этому объекту из памяти или должен пометить их, как непригодные ("invalid"), что будет вызывать обязательную перепроверку пригодности перед отправкой в виде отклика на последующий запрос.

    Некоторые методы HTTP могут сделать объект непригодным. Это либо объекты, на которые осуществляется ссылка через Request-URI, или через заголовки отклика Location или Content-Location (если они имеются). Это методы:

    • PUT
    • DELETE
    • POST

    12.16. Обязательная пропись (Write-Through Mandatory)

    Все методы, которые предположительно могут вызвать модификацию ресурсов исходного сервера должны быть прописаны в исходный сервер. В настоящее время сюда входят все методы кроме GET и HEAD. Кэш не должен отвечать на такой запрос от клиента, прежде чем передаст запрос встроенному (inbound) серверу, и получит соответствующего отклик от него. Это не препятствует кэшу послать отклик 100 (Continue), прежде чем встроенный сервер ответит.

    Альтернатива, известная как "write-back" или "copy-back" кэширование, в HTTP/1.1 не допускается, из-за трудности обеспечения согласованных актуализаций и проблем, связанных с отказами сервера, кэша или сети до осуществления обратной записи (write-back).

    12.17. Замещения в кэше

    Если от ресурса получен новый кэшируемый отклик (см. разделы 13.9.2, 12.5, 12.6 и 12.8), в то время как какой-либо отклик для того же ресурса уже записан в кэш, кэшу следует использовать новый отклик для ответа на текущий запрос. Он может ввести его в память кэша и может, если он отвечает всем требованиям, использовать в качестве отклика для будущих запросов. Если он вводит новый отклик в память кэша, он должен следовать правилам из раздела 12.5.3.

    Замечание. Новый отклик, который имеет значение заголовка Date старше, чем кэшированные уже отклики, не должен заноситься в кэш.

    12.18. Списки предыстории

    Агенты пользователя часто имеют механизмы "исторического" управления, такие как кнопки "Back" и списки предыстории, которые могут использоваться для повторного отображения объекта, извлеченного ранее в процессе сессии. Механизмы предыстории и кэширования различны. В частности механизмы предыстории не должны пытаться показать семантически прозрачный вид текущего состояния ресурса. Скорее, механизм предыстории предназначен для того, чтобы в точности показать, что видел пользователь, когда ресурс был извлечен. По умолчанию время годности не приложимо к механизмам предыстории. Если объект все еще в памяти, механизм предыстории должен его отобразить, даже если время жизни объекта истекло и он объявлен непригодным, если только пользователь не сконфигурировал агента так, чтобы обновлять объекты, срок годности которых истек. Это не запрещает механизму предыстории сообщать пользователю, что рассматриваемый им объект устарел.

    Замечание. Если механизмы предыстории излишне мешают пользователю просматривать устаревшие ресурсы, то это заставит разработчиков избегать пользоваться контролем времени жизни объектов. Разработчикам следует считать важным, чтобы пользователи не получали сообщений об ошибке или предупреждения, когда они пользуются навигационным управлением (например, таким как клавиша BACK).

    4.5.6.1.13. Определения полей заголовка

    Этот раздел определяет синтаксис и семантику всех стандартных полей заголовков HTTP/1.1. Для полей заголовков объекта, как отправитель, так и получатель могут рассматриваться клиентом или сервером в зависимости от того, кто получает объект.

    13.1. Поле Accept

    Поле заголовка запроса Accept может использоваться для спецификации определенных типов среды, которые приемлемы для данного ресурса. Заголовки Accept могут использоваться для индикации того, что запрос ограничен в рамках определенного набора типов, как в случае запросов отображения в текущей строке.

    Accept

    = "Accept" ":"

    #( media-range [ accept-params ] )

    media-range

    = ( "*/*"

    | ( type "/" "*")

    | ( type "/" subtype )

    ) *( ";" parameter )

    accept-params = ";" "q" "=" qvalue *( accept-extension )
    accept-extension = ";" token [ "=" ( token | quoted-string ) ]

    Символ звездочка "*" используется для того, чтобы группировать типы среды в группы с "*/*", указывающим на все типы, и "type/*", указывающим на все субтипы данного типа. Группа сред может включать в себя параметры типа среды, которые применимы. За каждой группой сред может следовать один или более параметров приема (accept-params), начинающихся с "q" параметра для указания фактора относительного качества. Первый "q" параметр (если таковой имеется) отделяет параметры группы сред от параметров приема. Факторы качества позволяют пользователю или агенту пользователя указать относительную степень предпочтения для данной группы сред, используя шкалу значений q от 0 до 1 (раздел 2.9). Значение по умолчанию соответствует q=1.

    Замечание. Использование имени параметра "q" для разделения параметров типа среды от параметров расширения Accept связано с исторической практикой. Это мешает присвоения параметру типа среды имени "q". Пример Accept: audio/*; q=0.2, audio/basic.

    Должно интерпретироваться, как "Я предпочитаю audio/basic, но шлите мне любые типы аудио, если это лучшее, что имеется после 80% понижения качества". Если поле заголовка Accept отсутствует, тогда предполагается, что клиент воспринимает все типы среды. Если поле заголовка Accept присутствует и, если сервер не может послать отклик, который является приемлемым, согласно комбинированному значению поля Accept, тогда сервер должен послать отклик 406 (not acceptable). Более сложный пример.

    Accept: text/plain; q=0.5, text/html,
    text/x-dvi; q=0.8, text/x-c

    Это будет интерпретироваться следующим образом: "text/html и text/x-c являются предпочтительными типами сред, но, если их нет, тогда следует слать объект text/x-dvi, если он отсутствует, следует присылать объект типа text/plain".

    Группы сред могут быть заменены другими группами или некоторыми специальными типами среды. Если используется более одного типа среды для данного типа, предпочтение отдается наиболее специфичному типу. Например,

    Accept: text/*, text/html, text/html;level=1, */*
    имеет следующие предпочтения:
    1) text/html;level=1
    2) text/html
    3) text/*
    4) */*

    Фактор качества типа среды, ассоциированный с данным типом определен путем нахождения группы сред с наивысшим предпочтением, который подходит для данного типа. Например,

    Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    text/html;level=2;q=0.4, */*;q=0.5

    в результате будут установлены следующие величины:

    text/html;level=1

    = 1

    text/html

    = 0.7

    text/plain

    = 0.3

    image/jpeg

    = 0.5

    text/html;level=2

    = 0.4

    text/html;level=3 ;

    = 0.7

    Замечание. Агент пользователя может быть создан с набором значений качества по умолчанию для определенных групп среды. Однако, если только агент пользователя не является закрытой системой, которая не может взаимодействовать с другими агентами, этот набор по умолчанию должен быть конфигурируем пользователем.

    13.2. Поле Accept-Charset

    Поле заголовка запроса Accept-Charset может быть использовано для указания того, какой символьный набор приемлем для отклика. Это поле позволяет клиентам, способным распознавать более обширные или специальные наборы символов, сигнализировать об этой возможности серверу, который способен представлять документы в рамках этих символьных наборов. Набор символов ISO-8859-1 может считаться приемлемым для всех агентов пользователя.

    Accept-Charset = "Accept-Charset" ":"
    1#( charset [ ";" "q" "=" qvalue ] )

    Значения символьных наборов описаны в разделе 2.4. Каждому символьному набору может быть поставлено в соответствие значение качества, которое характеризует степень предпочтения пользователя для данного набора. Значение по умолчанию q=1. Например Accept-Charset: ISO-8859-5, unicode-1-1;q=0.8. Если заголовок Accept-Charset отсутствует, по умолчанию это означает, что приемлем любой символьный набор. Если заголовок Accept-Charset присутствует, и, если сервер не может послать отклик, который приемлем с точки зрения заголовка Accept-Charset, тогда он должен послать сообщение об ошибке со статусным кодом 406 (not acceptable), хотя допускается посылка и отклика "unacceptable".

    13.3. Поле Accept-Encoding

    Поле заголовка запроса Accept-Encoding сходно с полем Accept, но регламентирует кодировку содержимого (раздел 13.12), которая приемлема в отклике.

    Accept-Encoding = "Accept-Encoding" ":"
    #( content-coding )

    Ниже приведен пример его использования Accept-Encoding: compress, gzip

    Если заголовок Accept-Encoding в запросе отсутствует, сервер может предполагать, что клиент воспримет любую кодировку информации. Если заголовок Accept-Encoding присутствует и, если сервер не может послать отклик, приемлемый согласно этому заголовку, тогда серверу следует послать сообщение об ошибке со статусным кодом 406 (Not Acceptable). Пустое поле Accept-Encoding указывает на то, что не приемлемо никакое кодирование.

    13.4. Поле Accept-Language

    Поле заголовка запроса Accept-Language сходно с полем Accept, но регламентирует набор естественных языков, которые предпочтительны в отклике на запрос.

    Accept-Language

    = "Accept-Language" ":"

    1#( language-range [ ";" "q" "=" qvalue ] )

    language-range

    = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

    Каждому набору языков может быть поставлено в соответствие значение качества, которое представляет собой оценку предпочтений пользователя для языков, специфицированных в диапазоне. По умолчанию значение качества "q=1". Например,

    Accept-Language: da, en-gb;q=0.8, en;q=0.7

    будет означать: "Я предпочитаю датский, но восприму британский английский и другие типы английского". Список языков согласуется с языковой меткой, если он в точности равен метке или, если он в точности равен префиксу метки, такому как первый символ метки, за которым следует символ "-". Специальный список "*", если он присутствует в поле Accept-Language, согласуется с любой меткой.

    Замечание. Это использование префикса не предполагает, что языковые метки присвоены языкам таким образом, что, если пользователь понимает язык с определенной меткой, то он поймет все языки, имеющие метки с одним и тем же префиксом. Правило префикса просто позволяет использовать префиксные метки для случаев, когда это справедливо.

    Фактор качества, присваиваемый языковой метке с помощью поля Accept-Language, равен значению качества самого длинного списка языков в поле. Если в поле отсутствует список языков, фактору качества присваивается значение нуль. Если в запросе отсутствует заголовок Accept-Language, серверу следует предполагать, что все языки приемлемы в равной мере. Если заголовок Accept-Language имеется, тогда все языки, которым присвоен фактор качества больше нуля, приемлемы.

    Посылка заголовка Accept-Language с полным списком языковых предпочтений пользователя в каждом запросе может восприниматься как нарушение принципов конфиденциальности. Обсуждение этой проблемы смотри в разделе 14.7.

    Замечание. Так как степень интеллигентности в высшей степени индивидуальна, рекомендуется, чтобы приложения клиента делали выбор языковых предпочтений доступным для пользователя. Если выбор не сделан доступным, тогда поле заголовка Accept-Language не должно присутствовать в запросе.

    13.5. Поле Accept-Ranges

    Поле заголовка отклика Accept-Ranges позволяет серверу указать доступность широкодиапазонных запросов к ресурсу:

    Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
    acceptable-ranges = 1#range-unit | "none"

    Исходные серверы, которые воспринимают байт-диапазонные запросы, могут послать

    Accept-Ranges: bytes

    но делать это необязательно. Клиенты могут выдавать байт-диапазонные запросы, не получив этот заголовок отклика для запрашиваемого ресурса. Серверы, которые не могут работать с какими-либо диапазонными запросами, могут послать

    Accept-Ranges: none,

    чтобы посоветовать клиенту, не пытаться посылать такие запросы.

    13.6. Поле Age

    Поле заголовка отклика Age передает оценку отправителем времени с момента формирования отклика исходным сервером (или перепроверки его пригодности). Кэшированный отклик является свежим, если его возраст не превышает его времени жизни. Значения Age вычисляются согласно рекомендациям представленным разделе 12.2.3.

    Age

    = "Age" ":" age-value

    age-value

    = delta-seconds

    Значения Age являются неотрицательным десятичным целым числом, характеризующим возраст записи в секундах.

    Если кэш получает величину больше, чем наибольшее положительное число, которое он может себе представить или, если вычисление возраста вызвало переполнение, он должен передать заголовок Age со значением 2147483648 (231). Кэши HTTP/1.1 должны посылать заголовки Age в каждом отклике. Кэшам следует использовать арифметический тип чисел не менее 31 бита.

    13.7. Поле Allow

    Поле заголовка объекта Allow перечисляет набор методов, поддерживаемых ресурсом, идентифицированным Request-URI. Целью этого поля является точное информирование получателя о рабочих методах данного ресурса. Поле заголовка Allow должно быть представлено в отклике 405 (Method Not Allowed).

    Allow = "Allow" ":" 1#method

    Пример использования:

    Allow: GET, HEAD, PUT

    Это поле не препятствует клиенту испытать другие методы. Однако указания, данные в значение поля заголовка Allow, следует выполнять. Действительный набор методов определяется исходным сервером во время каждого запроса.

    Поле заголовка Allow может быть прислано запросом PUT, чтобы рекомендовать методы, которые будут поддерживаться новым или модифицированным ресурсом. Серверу не обязательно поддерживает эти методы, но ему следует включить заголовок Allow в отклик, чтобы сообщить действительно поддерживаемые методы.

    Прокси не должен модифицировать поле заголовка Allow, даже если он не понимает все специфицированные методы, так как агент пользователя может иметь другие средства связи с исходным сервером.

    Поле заголовка Allow не указывают на то, что методы реализованы на уровне сервера. Серверы могут использовать поле заголовка отклика Public (раздел 13.35), чтобы описать, какие методы реализованы на сервере.

    13.8. Авторизация

    Агент пользователя, который хочет авторизовать себя на сервере может сделать это после получения отклика 401, включив в запрос поле заголовка Authorization. Значение поля Authorization состоит из идентификационной информации агента пользователя для области (realm) запрошенных ресурсов.

    Authorization = "Authorization" ":" credentials

    Авторизация доступа HTTP описана в разделе 10. Если запрос идентифицирован и область специфицирована, та же самая идентификационная информация может быть использована для других запросов в пределах данной области.

    Когда кэш коллективного пользования (см. раздел 12.7) получает запрос, содержащий поле Authorization, он не должен присылать соответствующий отклик в качестве ответа на какой-либо другой запрос, если только не выполняется одно из следующих условий:

    1. Если отклик включает в себя директиву Cache-Control "proxy-revalidate", кэш может использовать этот отклик при последующих запросах, но прокси-кэш должен сначала перепроверить его пригодность с помощью исходного сервера, используя заголовки нового запроса для того, чтобы исходный сервер мог идентифицировать новый запрос.
    2. Если отклик содержит в себе директиву Cache-Control "must-revalidate", кэш может использовать этот отклик при ответах на последующие запросы, но все кэши должны сначала перепроверить пригодность откликов с помощью исходного сервера, используя заголовки нового запроса для того, чтобы сервер мог идентифицировать новый запрос.
    3. Если отклик содержит директиву Cache-Control "public", то этот отклик может быть отослан в ответ на любой последующий запрос.

    13.9. Поле Cache-Control

    Поле общего заголовка Cache-Control используется для спецификации директив, которые должны исполняться всеми механизмами кэширования вдоль цепочки запрос/отклик. Директивы определяют поведение, которое, как предполагается, должно предотвратить нежелательную интерференцию откликов или запросов в кэше. Эти директивы обычно переписывают алгоритм кэширования, используемый по умолчанию. Директивы кэша являются однонаправленными, присутствие директивы в запросе не предполагает, что та же директива будет присутствовать и в отклике.

    Заметьте, что кэши HTTP/1.0 могут не реализовывать управление (Cache-Control), а могут использовать только директиву Pragma: no-cache (см. раздел 13.32).

    Директивы кэша должны пропускаться через приложения прокси или внешнего шлюза (gateway), вне зависимости от их значения для этого приложения, так как директивы могут быть применимы для всех получателей в цепочке запрос/отклик. Невозможно специфицировать директивы для отдельных кэшей.

    Cache-Control

    = "Cache-Control" ":" 1#cache-directive

    cache-directive

    = cache-request-directive

    | cache-response-directive

    cache-request-directive

    = "no-cash" ["=" <">1#field-name<">]

    | "no-store"

    | "max-age" "=" delta-seconds

    | "max-stale" [ "=" delta-seconds ]

    | "min-fresh" "=" delta-seconds

    | "only-if-cached"

    | cache-extension

    cache-response-directive

    = "public"

    | "private" [ "=" <"> 1#field-name <"> ]

    | "no-cache" [ "=" <"> 1#field-name <"> ]

    | "no-store"

    | "no-transform"

    | "must-revalidate"

    | "max-age" "=" delta-seconds

    | cache-extension;

    cache-extension

    = token [ "=" ( token | quoted-string ) ]

    Если директива появляется без какого-либо параметра 1#field-name, она воздействует на весь запрос или отклик. Когда такая директива приходит с параметром 1#field-name, она воздействует только на именованное поле или поля и не имеет никакого действия на остальную часть запроса или отклика. Этот механизм поддерживает расширяемость. Реализации будущих версий протокола HTTP могут использовать эти директивы для полей заголовка, неопределенных в HTTP/1.1.

    Директивы управления кэшем могут быть разделены на следующие категории:

    • Ограничения на то, что можно кэшировать. Они налагаются только исходным сервером.
    • Ограничения на то, что можно записывать в память кэша. Они определяются исходным сервером или агентом пользователя.
    • Модификации базового механизма контроля годности записей. Они вносятся либо исходным сервером, либо агентом пользователя.
    • Управление процессом перепроверки годности записей и перезагрузкой осуществляется только агентом пользователя.
    • Управление преобразованием объектов.
    • Расширения системы кэширования.

    13.9.1. Что допускает кэширование?

    По умолчанию отклик допускает кэширование, если требования метода запроса, поля заголовка запроса и код статуса отклика указывают на то, что кэширование не запрещено. Раздел 12.4 обобщает эти рекомендации для кэширования. Следующие Cache-Control директивы отклика позволяют исходному серверу переписать стандартные требования по кэшируемости:

    public

    Указывает, что отклик может кэшироваться любым кэшем, даже если он в норме не кэшируем или кэшируем только в кэшах индивидуального пользования. (См. также об авторизации в разделе 13.8.)

    private

    Указывает, что весь или часть сообщения отклика предназначена для одного пользователя и не должна быть записана кэшем коллективного пользования. Это позволяет исходному серверу заявить о том, что специфицированные части отклика предназначены только для одного пользователя, и он не может отсылаться в ответ на запросы других пользователей. Частный кэш может кэшировать такие отклики.

    Замечание. Это использование слова частный (private) определяет только возможность кэширования и не гарантирует конфиденциальности для содержимого сообщения.

    no-cache

    Указывает, весь или фрагмент сообщения-отклика не должны кэшироваться, где бы то ни было. Это позволяет исходному серверу предотвратить кэширование даже для кэшей, сконфигурированных для рассылки устаревших откликов.

    Замечание. Большинство кэшей HTTP/1.0 не распознают и не исполняют эту директиву.

    13.9.2. Что может быть записано в память кэша?

    Целью директивы no-store (не запоминать) является предотвращение ненамеренного распространения или записи конфиденциальной информации (например, на backup ленты). Директива no-store применяется для всего сообщения и может быть послана как в отклике, так и в запросе. При посылке в запросе кэш не должен запоминать какую-либо часть этого запроса или присланного в ответ отклика. При посылке в отклике, кэш не должен запоминать какую-либо часть отклика или запроса, его вызвавшего. Эта директива действует как для индивидуальных кэшей, так и кэшей коллективного пользования. "Не должно запоминаться" в данном контексте означает, что кэш не должен заносить отклик в долговременную память и должен сделать все от него зависящее для того, чтобы удалить эту информацию из временной памяти после переадресации этих данных.

    Даже когда эта директива ассоциирована с откликом, пользователи могут непосредственно запомнить такой отклик вне системы кэширования (например, с помощью диалога "Save As"). Буферы предыстории могут запоминать такие отклики как часть своей нормальной работы.

    Цель этой директивы обеспечение выполнения определенных требований пользователей и разработчиков, кто связан с проблемами случайного раскрытия информации за счет непредвиденного доступа к структуре данных кэша. При использовании этой директивы можно в некоторых случаях улучшить конфиденциальность, но следует учитывать, что не существует какого-либо надежного механизма для обеспечения конфиденциальности. В частности, некоторые кэши могут не распознавать или не выполнять эту директиву, а коммуникационные сети могут прослушиваться.

    13.9.3. Модификации базового механизма контроля времени жизни

    Время пригодности объекта (entity expiration time) может быть специфицировано исходным сервером с помощью заголовка Expires (см. раздел 13.21). Другой возможностью является применение директивы max-age в отклике.

    Если отклик включает в себя как заголовок Expires, так и директиву max-age, более высокий приоритет имеет директива max-age, даже если заголовок Expires накладывает более жесткие ограничения. Это правило позволяет исходному серверу обеспечить для заданного отклика большее время жизни в случае объектов кэша HTTP/1.1 (или более поздней версии), чем в HTTP/1.0. Это может быть полезным, если кэш HTTP/1.0 некорректно вычисляет возраст объекта или его время пригодности, например, из-за не синхронности часов.

    Замечание. Большинство старых кэшей, несовместимых с данной спецификацией, не поддерживают применение директив управления кэшем. Исходный сервер, желающий применить директиву управления кэшем, которая ограничивает, но не запрещает кэширование в системах, следующих регламентациям HTTP/1.1, может использовать то, что директива max-age переписывает значение, определенное Expires.

    Другие директивы позволяют агенту пользователя модифицировать механизм контроля времени жизни объектов. Эти директивы могут быть специфицированы в запросе max-age.

    Этот запрос указывает, что клиент желает воспринять отклик, чей возраст не больше времени, заданного в секундах. Если только не включена также директива max-stale, клиент не воспримет устаревший отклик.

    Запрос min-fresh указывает, что клиент желает воспринять отклик, чье время жизни не меньше, чем его текущий возраст плюс заданное время в секундах. То есть, клиент хочет получит отклик, который будет еще свежим, по крайней мере, заданное число секунд.

    Запрос max-stale указывает, что клиент желает воспринять отклик, время жизни которого истекло. Если max-stale присвоено конкретное значение, тогда клиент хочет получить отклик, время жизни которого не ранее, чем заданное число секунд тому назад. Если значения max-stale в директиве не указано, тогда клиент готов воспринять отклики любого возраста.

    Если кэш присылает устаревший отклик, из-за наличия в запросе директивы max-stale, либо потому, что кэш сконфигурирован таким образом, что переписывает время жизни откликов, кэш должен присоединить заголовок предупреждения к отклику, используя Warning 10 (Response is stale - отклик устарел).

    13.9.4. Управление перепроверкой пригодности и перезагрузкой

    Иногда агент пользователя может потребовать, чтобы кэш перепроверил пригодность своих записей с помощью исходного сервера (а не соседнего кэша по пути к исходному серверу), или перезагрузил свой кэш из исходного сервера. Может потребоваться перепроверка End-to-end, если и кэш и исходный сервер имеют завышенные оценки времени жизни кэшированных откликов. Перезагрузка End-to-end может потребоваться, если запись в кэше оказалась по какой-то причине поврежденной.

    Перепроверка типа End-to-end может быть запрошена в случае, когда клиент не имеет своей локальной копии, этот вариант мы называем "не специфицированная перепроверка end-to-end", или когда клиент имеет локальную копию, такой вариант называется "специфической перепроверкой end-to-end."

    Клиент может потребовать три вида действий, используя в запросе директивы управления кэшем:

    End-to-end reload

    Запрос включает в себя директиву управления кэшем "no-cache" или, для совместимости с клиентами HTTP/1.0, "Pragma: no-cache". В запросе с директивой no-cache может не быть никаких имен полей. Сервер не должен использовать кэшированную копию при ответе на этот запрос.

    Specific end-to-end revalidation

    Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, если она имеются, с записью следующего кэша или сервера. Исходный запрос включает в себя требования перепроверки для текущего значениея валидатора клиента.

    Unspecified end-to-end revalidation

    Запрос включает в себя директиву управления кэшем "max-age=0", которая вынуждает каждый кэш вдоль пути к исходному серверу сверить свою собственную запись, с записью следующего кэша или сервера. Исходный запрос не включает в себя требований перепроверки. Первый кэш по пути (если таковой имеется), который содержит запись данного ресурса, подключает условия перепроверки со своим текущим валидатором.

    Когда промежуточный кэш вынуждается с помощью директивы max-age=0 перепроверить свои записи, присланный клиентом валидатор может отличаться от того, что записан в данный момент в кэше. В этом случае кэш может воспользоваться в своем запросе любой из валидаторов, не нарушая семантической прозрачности.

    Однако выбор валидатора может влиять на результат. Наилучшим подходом для промежуточного кэша является использование в запросе своего собственного валидатора. Если сервер присылает отклик 304 (Not Modified), тогда кэш должен отправить свою уже проверенную копию клиенту со статусным кодом 200 (OK). Если сервер присылает отклик с новым объектом и валидатором кэша, промежуточный кэш должен сверить, тем не менее, полученный валидатор с тем, что прислал клиент, используя функцию сильного сравнения. Если валидатор клиента равен присланному сервером, тогда промежуточный кэш просто возвращает код 304 (Not Modified). В противном случае он присылает новый объект со статусным кодом 200 (OK).

    Если запрос включает в себя директиву no-cache, в нем не должно быть min-fresh, max-stale или max-age.

    В некоторых случаях, таких как периоды исключительно плохой работы сети, клиент может захотеть возвращать только те отклики, которые в данный момент находятся в памяти, и не перезагружать или перепроверять записи из исходного сервера. Для того чтобы сделать это, клиент может включить в запрос директиву only-if-cached. При получении такой директивы кэшу следует либо реагировать, используя кэшированную запись, которая соответствует остальным требованиям запроса, либо откликаться статусным кодом 504 (Gateway Timeout). Однако если группа кэшей работает как унифицированная система с хорошей внутренней коннективностью, тогда такой запрос может быть переадресован в пределах группы кэшей

    Так как кэш может быть сконфигурирован так, чтобы игнорировать времена жизни, заданные сервером, а запрос клиента может содержать директиву max-stale, протокол включает в себя механизм, который позволяет серверу требовать перепроверки записей в кэше для любого последующего применения. Когда в отклике, полученном кэшем, содержится директива must-revalidate, этот кэш не должен использовать эту запись для откликов на последующие запросы без сверки ее на исходном сервере. Таким образом, кэш должен выполнить перепроверку end-to-end каждый раз, если согласно значениям Expires или max-age, кэшированный отклик является устаревшим.

    Директива must-revalidate необходима для поддержания надежной работы для определенных функций протокола. При любых обстоятельствах HTTP/1.1 кэш должен выполнять директиву must-revalidate. В частности, если кэш по какой-либо причине не имеет доступа к исходному серверу, он должен генерировать отклик 504 (Gateway Timeout).

    Серверы должны посылать директиву must-revalidate, тогда и только тогда, когда неудача запроса перепроверки объекта может вызвать нарушение работы системы, например, не выполнение финансовой операции без оповещения об этом. Получатели не должны осуществлять любые автоматические действия, которые нарушают эту директиву, и не должны посылать непригодную копию объекта, если перепроверка не удалась.

    Хотя это и не рекомендуется, агенты пользователя, работающие в условиях очень плохой коннективности, могут нарушать эту директиву, но, если это происходит, пользователь должен быть предупрежден в обязательном порядке, что присланный отклик возможно является устаревшим. Предупреждение должно посылаться в случае каждого непроверенного доступа, при этом следует требовать подтверждения от пользователя.

    Директива proxy-revalidate имеет то же значение, что и must-revalidate, за исключением того, что она не применима для индивидуальных кэшей агентов пользователя. Она может использоваться в отклике на подтвержденный запрос, чтобы разрешить кэшу пользователя запомнить и позднее прислать отклик без перепроверки (так как он был уже подтвержден однажды этим пользователем), в то же время прокси должен требовать перепроверки всякий раз при обслуживании разных пользователей (для того чтобы быть уверенным, что каждый пользователь был авторизован). Заметьте, что такие авторизованные отклики нуждаются также в директиве управления кэшем public для того, чтобы разрешить их кэширование.

    13.9.5. Директива No-Transform

    Разработчики промежуточных кэшей (прокси) выяснили, что полезно преобразовать тип среды для тел определенных объектов. Прокси может, например, преобразовать форматы изображения для того, чтобы сэкономить место в памяти кэша или чтобы уменьшить информационный поток в тихоходном канале. HTTP должен датировать такие преобразования, выполняемые без оповещения.

    Серьезные операционные проблемы происходят, однако, когда такие преобразования производятся над телами объектов, предназначенных для определенного сорта приложений. Например, использующих медицинские изображения, предназначенные для анализа научных данных, а также тех, которые применяют авторизацию end-to-end, или требуют побитной совместимости с оригиналом.

    Следовательно, если отклик содержит директиву no-transform, промежуточный кэш или прокси не должны изменять те заголовки, которые перечислены в разделе 12.5.2, так как они могут содержать директиву no-transform. Это предполагает, что кэш или прокси не должны изменять любую часть тела объекта, который имеет такие заголовки.

    13.9.6. Расширения управления кэшем

    Поле заголовка Cache-Control может быть расширено за счет использования одной или более лексем расширения, каждой из которых может быть присвоено определенное значение. Информационные расширения (те которые не требуют изменений в работе кэша) могут быть добавлены без изменения семантики других директив. Поведенческие расширения спроектированы для того, чтобы выполнять функции модификаторов существующих директив управления кэшем. Новые директивы и стандартные директивы устроены так, что приложения, которые не воспринимают новую директиву, по умолчанию исполнят стандартную процедуру. Те же приложения, которые распознают новую директиву, воспринимают ее как модификацию стандартной процедуры. Таким путем расширения директив управления кэшем могут быть сделаны без изменения базового протокола.

    Этот механизм расширений зависит от того, выполняет ли кэш все директивы управления, определенные для базовой версии HTTP. Предполагается, что кэш реализует определенные расширения и игнорирует все директивы, которые не может распознать.

    Например, рассмотрим гипотетическую, новую директиву, названную "community", которая действует как модификатор директивы "private". Мы определяем эту новую директиву так, что в дополнение к стандартным возможностям индивидуальных кэшей, кэши, которые обслуживают группу (community), могут кэшировать их отклики. Исходный сервер, желающий позволить группе "UCI" использовать частные отклики на их общем кэше, может решить эту проблему, включив директиву управления кэшем: private, community="UCI".

    Кэш, получив это поле заголовка, будет действовать корректно, если даже не понимает расширение "community", так как он видит и понимает директиву "private" и, таким образом, по умолчанию обеспечит безопасное функционирование.

    Не распознанная директива управления должна игнорироваться. Предполагается, что любая директива, в том числе и не узнанная кэшем HTTP/1.1, имеет по умолчанию стандартную директиву-подмену, которая обеспечивает определенный уровень функциональности, когда директива-расширение не распознается.

    13.10. Соединение

    Поле общего заголовка Connection позволяет отправителю специфицировать опции, которые желательны для конкретного соединения. Заголовок Connection имеет следующую грамматику:

    Connection-header = "Connection" ":" 1#(connection-token)
    connection-token = token

    Прокси-серверы HTTP/1.1 должны выполнить разбор поля заголовка Connection, прежде чем выполнить переадресацию, и для каждой лексемы соединения в этом поле убрать любые поля заголовка в сообщении с именами, совпадающими с этими лексемами. Опции Connection отмечаются присутствием лексем соединения в поле заголовка Connection, а не какими-либо дополнительными полями заголовка, так как дополнительное поле заголовка может быть не послано, если нет параметров, ассоциированных с данной опцией соединения. HTTP/1.1 определяет опцию "close" (закрыть) для отправителя, чтобы сигнализировать о том, что соединение будет закрыто после завершения передачи отклика. Например, наличие

    Connection: close

    как в полях запроса, так и в полях отклика указывает на то, что соединение не следует рассматривать как "постоянное" (раздел 7.1) после завершения передачи данного запроса/отклика.

    Приложения HTTP/1.1, которые не поддерживают постоянные соединения, должны содержать опцию соединения "close" в каждом сообщении.

    13.11. Content-Base

    Поле заголовка объекта Content-Base может быть использовано для спецификации базового URI, которое позволяет работать с относительными URL в пределах объекта. Это поле заголовка описано как Base в документе RFC 1808, который, как ожидается, будет пересмотрен.

    Content-Base = "Content-Base" ":" absoluteURI

    Если поле Content-Base отсутствует, базовый URI объекта определяется его Content-Location (если это Content-Location URI является абсолютным) или URI используется для инициации запроса. Заметьте, однако, что базовый URI содержимого в пределах тела объекта может быть переопределен.

    13.12. Кодирование содержимого

    Поле заголовка объекта Content-Encoding используется в качестве модификатора типа среды. Если это поле присутствует, его значение указывает, что тело объекта закодировано, и какой механизм декодирования следует применить, чтобы получить массив данных, ориентированный на тип среды, указанный в поле Content-Type. Поле Content-Encoding первоначально предназначалось для того чтобы архивировать документ без потери его идентичности с учетом типа среды, на которую он ориентирован.

    Content-Encoding = "Content-Encoding" ":" 1#content-coding

    Кодировки содержимого определены в разделе 2.5. Пример его использования приведен ниже

    Content-Encoding: gzip

    Content-Encoding (кодирование содержимого) является характеристикой объекта, задаваемой Request-URI. Обычно тело объекта заносится в память в закодированном виде и декодируется перед отображением или другим аналогичным использованием.

    Если было применено множественное кодирование объекта, кодирование содержимого должно быть перечислено в том порядке, в котором оно было выполнено.

    13.13. Язык содержимого

    Поле заголовка объекта Content-Language описывает естественный язык(и) потенциальных читателей вложенного объекта. Заметьте, что это может быть совсем не эквивалентно всем языкам, использованным в теле объекта.

    Content-Language = "Content-Language" ":" 1#language-tag

    Языковые метки определены в разделе 2.10. Первоначальной целью поля Content-Language является предоставление пользователю возможности дифференцировать объекты согласно языковым предпочтениям. Таким образом, если содержимое тела предназначено только для аудитории, говорящей на датском языке, подходящим содержимым поля Content-Language может быть

    Content-Language: da

    Если поле Content-Language не задано, по умолчанию считается, что содержимое ориентировано на любую аудиторию. Это может значить, что отправитель не выделяет какой-либо естественный язык конкретно, или что отправитель не знает, какой язык предпочесть.

    Список языков может быть предложен для текста, который предназначен для многоязыковой аудитории. Например, перевод "Treaty of Waitangi," представленный одновременно в оригинальной версии на маори и на английском, может быть вызван с помощью

    Content-Language: mi, en

    Однако только то, что в поле объекта перечислено несколько языков не означает, что объект предназначен для многоязыковой аудитории. Примером может быть языковый курс для начинающих, такой как "A First Lesson in Latin," который предназначен для англо-говорящей аудитории. В этом случае поле Content-Language должно включать только "en".

    Поле Content-Language может быть применено к любому типу среды - оно не ограничено только текстовыми документами.

    13.14. Длина содержимого

    Содержимое поля заголовка объекта Content-Length указывает длину тела сообщения в октетах (десятичное число), посылаемое получателю, или в случае метода HEAD, размер тела объекта, который мог бы быть послан при запросе GET.

    Content-Length = "Content-Length" ":" 1*DIGIT

    Например

    Content-Length: 3495

    Приложениям следует использовать это поле для указания размера сообщения, которое должно быть послано вне зависимости от типа среды. Получатель должен иметь возможность надежно определить положение конца запроса HTTP/1.1, содержащего тело объекта, например, запрос использует Transfer-Encoding chunked или multipart body.

    Любое значение Content-Length больше или равное нулю допустимо. Раздел 3.4 описывает то, как определить длину тела сообщения, если параметр Content-Length не задан.

    Замечание. Значение этого поля заметно отличается от соответствующего определения в MIME, где оно является опционным, используемым в типе содержимого "message/external-body". В HTTP его следует посылать всякий раз, когда длина сообщения должна быть известна до начала пересылки.

    13.15. Поле Content-Location

    Поле заголовка объекта Content-Location может быть использовано для определения положения ресурса для объекта, вложенного в сообщение. В случае, когда ресурс содержит много объектов, и эти объекты в действительности имеют разные положения, по которым может быть осуществлен доступ, сервер должен предоставить поле Content-Location для конкретного варианта, который должен быть прислан. Кроме того сервер должен предоставить Content-Location для ресурса, соответствующего объекту отклика.

    Content-Location = "Content-Location" ":"
    ( absoluteURI | relativeURI )

    Если поле заголовка Content-Base отсутствует, значение Content-Location определяет также базовый URL для объекта (см. раздел 13.11).

    Значение Content-Location не является заменой для исходного запрашиваемого URI, это лишь объявление положения ресурса, соответствующего данному конкретному объекту в момент запроса. Будущие запросы могут использовать Content-Location URI, если нужно идентифицировать источник конкретного объекта.

    Кэш не может предполагать, что объект с полем Content-Location, отличающимся от URI, который использовался для его получения, может использоваться для откликов на последующие запросы к этому Content-Location URI. Однако Content-Location может использоваться для того, чтобы отличить объекты, полученные из одного общего, как это описано в разделе 12.6.

    Если Content-Location является относительным URI, URI интерпретируется с учетом значения Content-Base URI, присланного в отклике. Если значения Content-Base не предоставлено, относительный URI интерпретируется по отношению к Request-URI.

    13.16. Content-MD5

    Поле заголовка объекта Content-MD5, как это определено в RFC 1864 [23], является MD5-дайджестом тела объекта для целей обеспечения проверки end-to-end целостности сообщения MIC (message integrity check). Замечание. MIC привлекательна для регистрации случайных модификаций тела объекта при транспортировке, но не является гарантией против преднамеренных действий.)

    Content

    MD5 = "Content-MD5" ":" md5-digest

    md5digest

    =

    Поле заголовка Content-MD5 может генерироваться исходным сервером с целью проверки целостности тел объектов. Только исходные серверы могут генерировать поле заголовка Content-MD5. Прокси и внешние шлюзы его генерировать не должны, так как это сделает невозможными проверку целостности end-to-end. Любой получатель тела объекта, включая внешние шлюзы и прокси, могут проверять то, что значение дайджеста в этом поле заголовка согласуется с полученным телом объекта.

    Дайджест MD5 вычисляется на основе содержимого тела сообщения, с учетом любых кодировок содержимого, но исключая любые транспортные кодировки (Transfer-Encoding), которые могли быть использованы. Если сообщение получено в закодированном виде с использованием Transfer-Encoding, это кодирование должно быть удалено перед проверкой значения Content-MD5 для полученного объекта.

    Это означает, что дайджест вычисляется для октетов тела объекта в том порядке, в каком они будут пересланы, если не используется транспортное кодирование.

    HTTP расширяет RFC 1864 с тем, чтобы разрешить вычисление дайджеста для MIME-комбинации типов среды (например, multipart/* и message/rfc822), но это никак не влияет на способ вычисления дайджеста, описанного выше.

    Замечание. Существует несколько следствий этого. Тело объекта для комбинированных типов может содержать много составных частей, каждая со своими собственными MIME и HTTP заголовками (включая заголовки Content-MD5, Content-Transfer-Encoding и Content-Encoding). Если часть тела имеет заголовок Content-Transfer-Encoding или Content-Encoding, предполагается, что содержимое этой части закодировано и она включается в дайджест Content-MD5 как есть. Поле заголовка Transfer-Encoding не применимо для частей тела объекта.

    Замечание. Так как определение Content-MD5 является в точности тем же для HTTP и MIME (RFC 1864), существует несколько вариантов, в которых применение Content-MD5 к телам объектов HTTP отличается от случая MIME. Один вариант связан с тем, что HTTP, в отличие от MIME, не использует Content-Transfer-Encoding, а использует Transfer-Encoding и Content-Encoding. Другой - вызван тем, что HTTP чаще, чем MIME, использует двоичный тип содержимого. И, наконец, HTTP позволяет передачу текстовой информации с любым типом разрыва строк, а не только с каноническим CRLF. Преобразование всех разрывов строк к виду CRLF не должно делаться до вычисления или проверки дайджеста: тип оформления разрыва строк при расчете дайджеста должен быть сохранен.

    13.17. Отрывок содержимого

    Заголовок объекта Content-Range посылается с частью тела объекта и служит для определения того, где в теле объекта должен размещаться данный фрагмент. Он также указывает полный размер тела объекта. Когда сервер присылает клиенту частичный отклик, он должен описать как длину фрагмента, так и полный размер тела объекта.

    Content-Range

    = "Content-Range" ":" content-range-spec

    Content-range-spec

    = byte-content-range-spec

    byte-content-range-spec

    = bytes-unit SP first-byte-pos "-"

    last-byte-pos "/" entity-length

    entity-length

    = 1*DIGIT

    В отличие от значений спецификаторов байтовых диапазонов (byte-ranges-specifier), byte-content-range-spec может специфицировать только один интервал и должен содержать абсолютные положения, как первого, так и последнего байтов.

    Некорректной считается спецификация byte-content-range-spec, чье значение last-byte-pos меньше, чем его значение first-byte-pos, или значение длины объекта меньше или равно last-byte-pos. Получатель некорректной спецификации byte-content-range-spec должен игнорировать ее и любой текст, переданный вместе с ней. Примеры спецификации byte-content-range-spec, предполагающей, что объект содержит 1234 байт, приведены ниже:

    • The first 500 bytes: bytes 0-499/1234
    • The second 500 bytes: bytes 500-999/1234
    • All except for the first 500 bytes: bytes 500-1233/1234
    • The last 500 bytes: bytes 734-1233/1234

    Когда сообщение HTTP включает в себя содержимое одного фрагмента (например, отклик на запрос одного фрагмента, или на запрос набора фрагментов, которые перекрываются без зазоров), это содержимое передается с заголовком Content-Range, а заголовок Content-Length несет в себе число действительно переданных байт. Например,

    HTTP/1.1 206 Partial content
    Date: Wed, 15 Nov 1995 06:25:24 GMT
    Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
    Content-Range: bytes 21010-47021/47022
    Content-Length: 26012
    Content-Type: image/gif

    Когда сообщение HTTP несет в себе содержимое нескольких фрагментов (например, отклик на запрос получения нескольких, не перекрывающихся фрагментов), они передаются как многофрагментное MIME-сообщение. Многофрагментный тип данных MIME используемый для этой цели, определен в этой спецификации как "multipart/byteranges". (Смотри приложение 16.2).

    Клиент, который не может декодировать сообщение MIME multipart/byteranges, не должен запрашивать несколько байт-фрагментов в одном запросе.

    Когда клиент запрашивает несколько фрагментов байт в одном запросе, серверу следует присылать их в порядке перечисления.

    Если сервер игнорирует спецификацию byte-range-spec, из-за того, что она некорректна, сервер должен воспринимать запрос так, как если бы некорректного заголовка Range не существовало вовсе. (В норме это означает посылку отклика с кодом 200, содержащего весь объект). Причиной этого является то, что клиент может прислать такой некорректный запрос, только когда объект меньше чем объект, полученный по предыдущему запросу.

    13.18. Тип содержимого

    Поле заголовка объекта Content-Type указывает тип среды тела объекта, посланного получателю, или, в случае метода HEAD, тип среды, который был бы применен при методе GET.

    Content-Type = "Content-Type" ":" media-type

    Типы среды определены в разделе 2.7. Примером поля может служить

    Content-Type: text/html; charset=ISO-8859-4

    Дальнейшее обсуждение методов идентификации типа среды объекта приведено в разделе 6.2.1.

    13.19. Дата

    Поле общего заголовка Date представляет дату и время формирования сообщения, имеет ту же семантику, что и orig-date в RFC 822. Значение поля равно HTTP-date, как это описано в разделе 2.3.1.

    Date = "Date" ":" HTTP-date

    Пример

    Date: Tue, 15 Nov 1994 08:12:31 GMT

    Если сообщение получено через непосредственное соединение с агентом пользователя (в случае запросов) или исходным сервером (в случае откликов), дата может считаться текущей датой конца приема. Однако так как дата по определению является важной при оценке характеристик кэшированных откликов, исходный сервер должен включать поле заголовка Date в каждый отклик. Клиентам следует включать поле заголовка Date в сообщения, которые несут тело объекта запросов PUT и POST, но даже здесь это является опционным. Полученному сообщению, которое не имеет поля заголовка Date, следует присвоить дату. Это может сделать один из получателей, если сообщение будет кэшировано им, или внешним шлюзом.

    Теоретически дата должна представлять момент времени сразу после генерации объекта. На практике поле даты может быть сформировано в любое время в процессе генерации сообщения.

    Формат поля Date представляет собой абсолютную дату и время так, как это определено для даты HTTP в разделе 2.3. Оно должно быть послано в формате, описанном в документе RFC-1123 [8].

    13.20. Поле ETag

    Поле заголовка объекта ETag определяет метку объекта. Заголовки с метками объектов описаны в разделах 13.20, 13.25, 13.26 и 13.43. Метка объекта может использоваться для сравнения с другими объектами того же самого ресурса (см. раздел 12.8.2).

    ETag = "ETag" ":" entity-tag
    Примеры:
    ETag: "xyzzy"
    ETag: W/"xyzzy"
    ETag: ""

    13.21. Поле Expires

    Поле заголовка объекта Expires содержит дату/время с момента, когда отклик может считаться устаревшим. Устаревшая запись в кэше в норме не должна посылаться кэшем (а также прокси кэшем и кэшем агента пользователя), если только она не будет сначала перепроверена с помощью исходного сервера (или с помощью промежуточного кэша, который содержит свежую копию объекта). Дальнейшее обсуждение модели контроля пригодности записей содержится в разделе 12.2. Присутствие поля Expires не предполагает, что исходный ресурс изменит или удалит объект по истечении указанного времени.

    Формат абсолютной даты и времени описан в разделе 2.3. Он должен следовать рекомендациям документа RFC1123:

    Expires = "Expires" ":" HTTP-date

    Примером реализации формата даты может служить

    Expires: Thu, 01 Dec 1994 16:00:00 GMT

    Замечание. Если отклик содержит поле Cache-Control с директивой max-age, то эта директива переписывает значение поля Expires.

    Клиенты HTTP/1.1 и кэши должны рассматривать некорректные форматы даты, в особенности те, что содержат нули, как относящиеся к прошлому (то есть, как "уже истекшие").

    Для того, чтобы пометить отклик, как "уже с истекшим сроком", исходный сервер должен использовать дату Expires, которая равна значению заголовка Date. (Правила вычисления времени истечения пригодности записи смотри в разделе 12.2.4.)

    Для того, чтобы пометить отклик как "всегда пригодный", исходный сервер должен использовать дату Expires приблизительно на один год позже момента посылки отклика. Серверы HTTP/1.1 не должны посылать отклики с датами в поле Expires, которые устанавливают время жизни более одного года.

    Присутствие поля заголовка Expires со значением даты, относящейся к будущему, означает, что они могут быть занесены в кэш, если только не указано обратного в поле заголовка Cache-Control (раздел 13.9).

    13.22. Поле From

    Поле заголовка запроса From (если присутствует) должно содержать интернетовский e-mail адрес пользователя. Адрес должен иметь формат, описанный в документе RFC-822 (и дополненный в RFC-1123):

    From = "From" ":" mailbox

    Пример:

    From: webmaster@w3.org

    Это поле заголовка может быть использовано для целей регистрации процедур и как средство идентификации источников некорректных и нежелательных запросов. Не следует использовать его как ненадежную систему защиты доступа. Это поле предоставляет информацию о том, кто является ответственным за метод, использованный в данном запросе. В частности, агенты-роботы должны содержать этот заголовок, так чтобы с лицом, ответственным за работу робота, можно было связаться, в случае возникновения проблем на принимающем конце.

    Интернетовский e-mail адрес в этом поле может не совпадать с Интернет-адресом ЭВМ, пославшей запрос. Например, когда запрос прошел через прокси, следует использовать адрес первичного отправителя.

    Замечание. Клиенту не следует посылать поле заголовка From без одобрения пользователя, так как это может вызвать конфликт с интересами конфиденциальности пользователя или нарушить политику безопасности сети отправителя. Настоятельно рекомендуется, чтобы пользователь мог дезактивировать, активировать и модифицировать значение этого поля в любое время до запроса.

    13.23. Поле Host

    Поле заголовка запроса Host специфицирует ЭВМ в Интернет и номер порта запрашиваемого ресурса в виде, полученном из исходного URL, который выдал пользователь или который получен из указанного ресурса (в общем случае из HTTP URL, как это описано в разделе 2.2.2). Значение поля Host должно определять положение в сети исходного сервера или шлюза, заданное исходным URL. Это позволяет исходному серверу или шлюзу различать внутренние URL, такие как корневые "/" URL сервера для ЭВМ, которым поставлен в соответствие один IP адрес.

    Host = "Host" ":" host [ ":" port ] ; Раздел 2.2.2

    Имя "ЭВМ" без последующего номера порта предполагает значение порта по умолчанию для заданного вида сервиса (напр., "80" для HTTP URL). Например, запрос исходного сервера должен включать в себя:

    GET /pub/WWW/ HTTP/1.1
    Host: www.w3.org

    Клиент должен включать поле заголовка Host во все сообщения-запросы HTTP/1.1 в Интернет (т.е., в любое сообщение, соответствующее запросу URL, который включает в себя Интернет-адрес ЭВМ, услуги которой запрашиваются). Если поле Host отсутствует, прокси HTTP/1.1 должен добавить его в сообщение-запрос до того, как переадресует запрос дальше в Интернет. Все серверы HTTP/1.1, которые базируются в Интернет, должны откликаться статусным кодом 400 на любое сообщение-запрос HTTP/1.1, в котором отсутствует поле Host.

    О других требованиях относительно поля Host смотри раздел 4.2 и 16.5.1.

    13.24. Поле If-Modified-Sinc

    Поле заголовка запроса If-Modified-Since используется с методом GET, для того чтобы сделать его условным. Если запрошенный объект не был модифицирован со времени, указанного в этом поле, объект не будет прислан сервером, вместо этого будет послан отклик 304 (not modified) без какого-либо тела сообщения.

    If-Modified-Since = "If-Modified-Since" ":" HTTP-date

    Пример поля:

    If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

    Метод GET с заголовком If-Modified-Since и без заголовка Range требует, чтобы идентифицированный объект был передан, только в случае его модификации после даты, указанной в заголовке If-Modified-Since. Алгоритм определения этого включает в себя следующие шаги.

    1. Если запрос приводит к чему-то отличному от статусного отклика 200 (OK), или если переданная дата If-Modified-Since некорректна, отклик будет в точности тот же, что и для обычного GET. Дата раньше текущего времени сервера является некорректной.
    2. Если объект был модифицирован после даты If-Modified-Since, отклик будет в точности тем же, что и для обычного GET.
    3. Если объект не был модифицирован после корректно указанной даты If-Modified-Since, сервер должен прислать отклик 304 (Not Modified).

    Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками.

    Заметьте, что поле заголовка запроса Range модифицирует значение If-Modified-Since. Более детально эта проблема рассмотрена в разделе 13.36.

    Заметьте, что время If-Modified-Since интерпретируются сервером, чьи часы могут быть не синхронизованы с часами клиента.

    Если клиент использует произвольную дату в заголовке If-Modified-Since вместо даты взятой из заголовка Last-Modified для текущего запроса, тогда клиенту следует остерегаться того, что эта дата интерпретируется согласно представлениям сервера о временной шкале. Клиенту следует учитывать не синхронность часов и проблемы округления, связанные с различным кодированием времени клиентом и сервером. Это предполагает возможность быстрого изменения условий, когда документ изменяется между моментом первого запроса и датой If-Modified-Since последующего запроса, а также возможность трудностей, связанных с относительным сбоем часов, если дата If-Modified-Since получена по часам клиента (без поправки на показания часов сервера). Поправки для различных временных базисов клиента и сервера желательно делать с учетом времени задержки в сети.

    13.25. Поле If-Match

    Поле заголовка запроса If-Match используется с методом, для того чтобы сделать его условным. Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, является ли один из этих объектов текущим, включив список связанных с ним меток в поле заголовка If-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальными издержками. Она используется также в запросах актуализации с целью предотвращения непреднамеренной модификации не той версии ресурса что нужно. Значение "*" соответствует любому текущему объекту ресурса.

    If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

    Если какая-то метка объекта совпадает с меткой объекта, который прислан в отклике на аналогичный запрос GET (без заголовка If-Match), или если задана "*" и какой-то текущий объект существует для данного ресурса, тогда сервер может реализовать запрошенный метод, как если бы поля заголовка If-Match не существовало.

    Сервер должен использовать функцию сильного сравнения (см. раздел 2.11) для сопоставления меток объекта в If-Match.

    Если ни одна из меток не подходит, или если задана "*" и не существует никакого текущего объекта, сервер не должен реализовывать запрошенный метод, а должен прислать отклик 412 (Precondition Failed). Это поведение наиболее полезно, когда клиент хочет помешать актуализующему методу, такому как PUT, модифицировать ресурс, который изменился после последнего доступа к нему клиента.

    Если запрос без поля заголовка If-Match выдает в результате нечто отличное от статуса 2xx, тогда заголовок If-Match должен игнорироваться.

    "If-Match: *" означает, что метод должен быть реализован, если представление, выбранное исходным сервером (или кэшем, возможно с привлечением механизма Vary, см. раздел 13.43), существует, и не должен быть реализован, если выбранного представления не существует.

    Запрос, предназначенный для актуализации ресурса (напр., PUT) может включать в себя поле заголовка If-Match, чтобы сигнализировать о том, что метод запроса не должен быть применен, если объект, соответствующий значению If-Match (одиночная метка объекта), не является более представлением этого ресурса. Это позволяет пользователям указывать, что они не хотят, чтобы запрос прошел успешно, если ресурс был изменен без их уведомления. Примеры:

    If-Match: "xyzzy"
    If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    If-Match: *

    13.26. Поле If-None-Match

    Поле заголовка запроса If-None-Match используется для формирования условных методов. Клиент, который имеет один или более объектов, полученных ранее из ресурса, может проверить, что ни один из этих объектов не является текущим, путем включения списка их ассоциированных меток в поле заголовка If-None-Match. Целью этой функции является эффективная актуализация кэшированной информации с минимальной избыточностью. Она также используется при актуализации запросов с тем, чтобы предотвратить непреднамеренную модификацию ресурса, о существовании которого не было известно.

    Значение "*" соответствует любому текущему объекту ресурса.

    If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

    Если какая-либо метка объекта соответствует метке объекта, который был прислан в отклике на аналогичный запрос GET (без заголовка If-None-Match) или если задана "*" и существует какой-то текущий объект данного ресурса, тогда сервер не должен реализовывать запрошенный метод. Вместо этого, если методом запроса был GET или HEAD, серверу следует реагировать откликом 304 (Not Modified), включая поля заголовков объекта, ориентированные на кэш (в частности ETag). Для всех других методах запроса сервер должен откликаться статусным кодом 412 (Precondition Failed).

    По поводу правил того, как определять соответствие двух меток объектов смотри раздел 12.8.3. С запросами GET и HEAD должна использоваться только функция слабого сравнения.

    Если не подходит ни одна из меток объекта или если задана "*" и не существует ни одного текущего объекта, сервер может выполнить запрошенный метод так, как если бы поля заголовка If-None-Match не существовало.

    Если запрос без поля заголовка If-None-Match, даст результат отличный от статусного кода 2xx, тогда заголовок If-None-Match должен игнорироваться.

    "If-None-Match: *" означает, что метод не должен реализовываться, если представление, выбранное исходным сервером (или кэшем, возможно использующим механизм Vary, см. раздел 13.43), существует, и должен быть реализован, если представления не существует. Эта функция может быть полезной для предотвращения конкуренции между операциями PUT.

    Примеры:

    If-None-Match: "xyzzy"
    If-None-Match: W/"xyzzy"
    If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    If-None-Match: *

    13.27. Заголовок If-Range

    Если клиент имеет частичную копию объекта в своем кэше и хочет иметь полную свежую копию объекта, он может использовать заголовок запроса Range с условным GET (используя If-Unmodified-Since и/или If-Match.) Однако если условие не выполняется, из-за того, что объект был модифицирован, клиенту следует послать второй запрос, чтобы получить все текущее содержимое тела объекта.

    Заголовок If-Range позволяет клиенту заблокировать второй запрос. По существу это означает, что "если объект не изменился, следует посылать мне часть, которой у меня нет, в противном случае пришлите мене всю новую версию объекта".

    If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

    Если клиент не имеет метки объекта, но имеет дату Last-Modified, он может использовать эту дату в заголовке If-Range. Сервер может отличить корректную дату HTTP от любой формы метки объекта, рассмотрев не более двух символов. Заголовок If-Range следует использовать только совместно с заголовком Range, и его следует игнорировать, если запрос не содержит в себе этот заголовок, или если сервер не поддерживает операции с фрагментами.

    Если метка объекта, представленная в заголовке If-Range, соответствует текущей метке, тогда сервер должен обеспечить специфицированный фрагмент объекта, используя отклик 206 (Partial content). Если метка объекта не подходит, сервер должен прислать полный объект со статусным кодом 200 (OK).

    13.28. Поле If-Unmodified-Since

    Поле заголовка запроса If-Unmodified-Since используется для того, чтобы формировать условные методы. Если запрошенный ресурс не был модифицирован с момента, указанного в поле, сервер должен произвести запрошенную операцию, так как если бы заголовок If-Unmodified-Since отсутствовал.

    Если запрошенный объект был модифицирован после указанного времени, сервер не должен выполнять запрошенную операцию и должен прислать отклик 412 (Precondition Failed).

    If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

    Примером поля может служить:

    If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

    Если запрос завершается чем-то отличным от статусного кода 2xx (т.е., без заголовка If-Unmodified-Since), заголовок If-Unmodified-Since следует игнорировать. Если специфицированная дата некорректна, заголовок также игнорируется.

    13.29. Поле Last-Modified

    Поле заголовка объекта Last-Modified указывает на дату и время, при которых, по мнению исходного сервера, данный объект был модифицирован.

    Last-Modified = "Last-Modified" ":" HTTP-date

    Пример его использования

    Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

    Точное значение этого заголовка зависит от реализации исходного сервера и природы ресурса. Для файлов, это может быть дата последней модификации файловой системы. Для объектов с динамическими встроенными частями это может время последней модификации одной из встроенных компонент. Для шлюзов баз данных это может быть метка последней модификации рекорда. Для виртуальных объектов это может быть время последнего изменения внутреннего состояния.

    Исходный сервер не должен посылать дату Last-Modified, которая позже, чем время формирования сообщения сервера. В таких случаях, когда последняя модификация объекта указывает некоторое на время в будущем, сервер должен заменить дату на время формирования сообщения.

    Исходный сервер должен получить значение Last-Modified объекта как можно ближе по времени к моменту генерации значения Date отклика. Это позволяет получателю выполнить точную оценку времени модификации объекта, в особенности, если объект был изменен буквально накануне формирования отклика.

    Серверы HTTP/1.1 должны посылать поле Last-Modified всякий раз, когда это возможно.

    13.30. Поле Location

    Поле заголовка отклика Location используется для переадресации запроса на сервер, отличный от указанного в Request-URI, или для идентификации нового ресурса. В случае отклика 201 (Created), поле Location указывает на новый ресурс, созданный в результате запроса. Для откликов 3xx поле Location должно указывать предпочтительные URL сервера для автоматической переадресации на ресурс. Значение поля включает одинарный абсолютный URL.

    Location = "Location" ":" absoluteURI

    Например

    Location: http://www.w3.org/pub/WWW/People.html

    Замечание. Поле заголовка Content-Location (раздел 13.15) отличается от поля Location в том, что Content-Location идентифицирует исходное положение объекта, заключенное в запросе. Следовательно, отклик может содержать поля заголовка как Location, так и Content-Location. Требования некоторых методов изложены также в разделе 12.10.

    13.31. Поле Max-Forwards

    Поле заголовка запроса Max-Forwards может использоваться с методом TRACE (раздел 13.31) ,чтобы ограничить число прокси или шлюзов, которые могут переадресовывать запрос. Это может быть полезным, когда клиент пытается отследить путь запроса в случае возникновения различных проблем.

    Max-Forwards = "Max-Forwards" ":" 1*DIGIT

    Значение Max-Forwards представляет собой целое десятичное число, которое указывает сколько еще раз запрос можно переадресовать.

    Каждый прокси или шлюз получатель запроса TRACE, содержащего поле заголовка Max-Forwards, должен проверить и актуализовать его величину прежде, чем переадресовывать запрос. Если полученная величина равна нулю, получателю не следует переадресовывать запрос. Вместо этого, ему следует откликнуться как конечному получателю статусным кодом 200 (OK), содержащим полученное сообщение-запрос в качестве тела отклика (как это описано в разделе 8.8). Если полученное значение больше нуля, тогда переадресованное сообщение должно содержать актуализованное значение поля Max-Forwards (уменьшенное на единицу).

    Поле заголовка Max-Forwards следует игнорировать для всех других методов определенных в данной спецификации и для всех расширений методов, для которых это не является частью определения метода.

    13.32. Поле Pragma

    Поле общего заголовка Pragma используется для включения специальных директив (зависящих от конкретной реализации), которые могут быть применены ко всем получателям вдоль цепочки запрос/отклик. Все директивы pragma специфицируют с точки зрения протокола опционное поведение. Однако некоторые системы могут требовать, чтобы поведение соответствовало директивам:

    Pragma

    = "Pragma" ":" 1#pragma-directive

    pragma-directive

    = "no-cache" | extension-pragma

    extension-pragma

    = token [ "=" ( token | quoted-string ) ]

    Когда в запросе присутствует директива no-cashe, приложение должно переадресовать запрос исходному серверу, даже если имеется кэшированная копия того, что запрошено. Директива pragma имеет ту же семантику, что и директива кэша no-cache (см. раздел 13.9) и определена здесь для обратной совместимости с HTTP/1.0. Клиентам следует включать в запрос оба заголовка, когда посылается запрос no-cache серверу, о котором неизвестно, совместим ли он с HTTP/1.1.

    Нельзя специфицировать директиву pragma для какого-то отдельного получателя. Однако любая директива pragma неприемлемая для получателя должна им игнорироваться.

    Клиенты HTTP/1.1 не должны посылать заголовок запроса Pragma. Кэши HTTP/1.1 должны воспринимать "Pragma: no-cache", как если бы клиент послал "Cache-Control: no-cache". Никаких новых директив Pragma в HTTP определено не будет.

    13.33. Поле Proxy-Authenticate

    Поле заголовка отклика Proxy-Authenticate должно быть включено в качестве части отклика 407 (Proxy Authentication Required). Значение поля состоит из вызова, который указывает схему идентификации, и параметров, применимых в прокси для данного Request-URI.

    Proxy-Authenticate = "Proxy-Authenticate" ":" challenge

    Процесс авторизованного доступа HTTP описан в разделе 10. В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применимо только к текущему соединению и не может быть передано другим клиентам. Однако, промежуточному прокси может быть нужно получить свои собственные авторизационные параметры с помощью запроса у ниже расположенного клиента, который при определенных обстоятельствах может проявить себя как прокси, переадресующий поле заголовка Proxy-Authenticate.

    13.34. Поле Proxy-Authorization

    Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать себя (или его пользователя) прокси, который требует авторизации. Значение поля Proxy-Authorization состоит из автризационных параметров, содержащих идентификационную информацию агента пользователя для прокси и/или области (realm) запрошенного ресурса.

    Proxy-Authorization = "Proxy-Authorization" ":" credentials

    Процесс авторизации доступа HTTP описан в разделе 10. В отличие от Authorization, поле заголовка Proxy-Authorization применимо только к следующему внешнему прокси, который требует авторизации с помощью поля Proxy-Authenticate. Когда работает несколько прокси, объединенных в цепочку, поле заголовка Proxy-Authorization используется первым внешним прокси, который предполагает получение авторизационных параметров. Прокси может передать эти параметры из запроса клиента следующему прокси, если существует механизм совместной авторизации при обслуживании данного запроса.

    13.35. Поле Public

    Поле заголовка отклика Public содержит список методов, поддерживаемых сервером. Задачей этого поля является информирование получателя о возможностях сервера в отношении необычных методов. Перечисленные методы могут быть, а могут и не быть применимыми к Request-URI. Поле заголовка Allow (раздел 13.7) служит для указания методов, разрешенных для данного URI.

    Public

    = "Public" ":" 1#method

    Пример использования:

    Public: OPTIONS, MGET, MHEAD, GET, HEAD

    Это поле заголовка применяется для серверов, непосредственно соединенных с клиентом, (т.е., ближайших соседей в цепи соединения). Если отклик проходит через прокси, последний должен либо удалить поле заголовка Public или заменить его полем, характеризующим его собственные возможности.

    13.36. Фрагмент
    13.36.1. Фрагменты байт

    Так как все объекты HTTP в процессе передачи представляют собой последовательности байт, концепция фрагментов является существенной для любого объекта HTTP. Однако не все клиенты и серверы нуждаются в поддержке операций с фрагментами.

    Спецификации байтовых фрагментов в HTTP относятся к последовательностям байт в теле объекта не обязательно то же самое что и тело сообщения.

    Операция с байтовыми фрагментами может относиться к одному набору байт или к нескольким таким наборам в пределах одного объекта.

    ranges-specifier

    = byte-ranges-specifier

    byte-ranges-specifier

    = byte-sunit "=" byte-range-set

    byte-range-set

    = 1#( byte-range-spec | suffix-byte-range-spec )

    byte-range-spec

    = first-byte-pos "-" [last-byte-pos]

    first-byte-pos

    = 1*DIGIT

    last-byte-pos

    = 1*DIGIT

    Значение first-byte-pos в спецификации byte-range-spec указывает на относительное положение первого байта фрагмента. Значение last-byte-pos определяет относительное положение последнего байта фрагмента. Относительное положение начального байта равно нулю.

    Если присутствует значение last-byte-pos, оно должно быть больше или равно значению first-byte-pos в спецификации byte-range-spec, в противном случае спецификация byte-range-spec не корректна. Получатель некорректной спецификации byte-range-spec должен ее игнорировать.

    Если значение last-byte-pos отсутствует, или если значение больше или равно текущей длине тела объекта, значение last-byte-pos берется на единицу меньше текущего значения длины тела объекта в байтах.

    При выборе last-byte-pos, клиент может ограничить число копируемых байт, если не известна длина объекта.

    suffix-byte-range-spec = "-" suffix-length
    suffix-length = 1*DIGIT

    Спецификация suffix-byte-range-spec используется для задания суффикса тела объекта с длиной, заданной значением suffix-length. (То есть, эта форма специфицирует последние N байтов тела объекта.) Если объект короче заданной длины суффикса, то в качестве суффикса используется все тело объекта.

    Примеры значений byte-ranges-specifier (предполагается, что длина тела объекта равна 10000):

    • Первые 500 байтов (относительные позиции 0-499, включительно): bytes=0-499
    • Вторые 500 байтов (относительные позиции 500-999, включительно): bytes=500-999
    • Последние 500 байтов (относительные позиции 9500-9999, включительно): bytes=-500
    или

    bytes=9500-

    • Первые и последние байты (байты 0 и 9999): bytes=0-0,-1
    • Несколько легальных, но неканонических спецификаций вторых 500 байт (относительные позиции 500-999, включительно): bytes=500-600,601-999; bytes=500-700,601-999

    13.36.2. Запросы получения фрагментов

    Информационные запросы HTTP, использующие условные или безусловные методы GET могут заказывать один или более субфрагментов объекта, а не целый объект, используя заголовок запроса Range:

    Range

    = "Range" ":" ranges-specifier

    Сервер может игнорировать заголовок Range. Однако исходные серверы HTTP/1.1 и промежуточные кэши должны поддерживать по возможности работу с фрагментами, так как Range поддерживает эффективное восстановление в случае частично неудачных пересылок больших объектов.

    Если сервер поддерживает заголовки Range и специфицированный фрагмент или фрагменты подходят для данного объекта, то:

    • Присутствие заголовка Range в безусловном GET допускает модификацию того, что прислано. Другими словами отклик может содержать статусный код 206 (Partial Content) вместо 200 (OK).
    • Присутствие заголовка Range в условном GET (запрос использует If-Modified-Since, If-None-Match, If-Unmodified-Since и/или If-Match) модифицирует то, что прислано GET в случае успешного завершения при выполнении условия (TRUE). Это не влияет на отклик 304 (Not Modified), если условие не выполнено (FALSE).

    В некоторых случаях более удобно использовать заголовок If-Range (см. раздел 13.27).

    Если прокси, который поддерживает фрагменты, получает запрос Range, переадресует запрос внешнему серверу и получает в ответ весь объект, ему следует прислать запрашиваемый фрагмент клиенту. Он должен запомнить весь полученный отклик в своем кэше, если отклик совместим с политикой записи в его кэш.

    13.37. Поле Referer

    Поле заголовка запроса Referer позволяет клиенту специфицировать (для пользы сервера) адрес (URI) ресурса, из которого был получен Request-URI. Заголовок запроса Referer позволяет серверу генерировать список обратных связей с ресурсами для интереса, ведения дневника, оптимизации кэширования и т.д.. Он позволяет также заставить работать устаревшие или дефектные связи. Поле Referer не должно посылаться, если Request-URI был получен от источника, который не имеет своего собственного URI, такого, например, как ввод с пользовательского терминала.

    Referer

    = "Referer" ":" ( absoluteURI | relativeURI )

    Пример:

    Referer: http://www.w3.org/hypertext/DataSources/Overview.html

    Если значением поля является частичный URI, его следует интерпретировать относительно Request-URI. URI не должен включать фрагментов.

    Замечание. Так как первоисточник связи может быть конфиденциальной информацией или может раскрывать другой источник частной информации, настоятельно рекомендуется, чтобы пользователь имел возможность решать, посылать поле Referer или нет. Например, клиент-броузер может иметь кнопку-переключатель для открытого или анонимного просмотра, которая управляет активацией/дезактивацией посылки информации Referer и From.

    13.38. Поле Retry-After

    Поле заголовка отклика Retry-After может использоваться с кодом статуса 503 (Service Unavailable) с тем, чтобы указать, как еще долго данная услуга предполагается быть недоступной для запрашивающего клиента. Значением этого поля может быть либо дата HTTP либо целое число секунд (в десятичном исчислении) после отправки отклика.

    Retry-After

    = "Retry-After" ":" ( HTTP-date | delta-seconds )

    Два примера использования поля

    Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    Retry-After: 120

    В последнем примере задержка равна двум минутам.

    13.39. Поле Server

    Поле заголовка отклика Server содержит информацию о программном обеспечении, используемым исходным сервером для обработки запросов. Поле может содержать коды многих продуктов (раздел 2.8), комментарии, идентифицирующие сервер, и некоторые важные субпродукты. Коды программных продуктов перечисляются в порядке важности приложений.

    Server

    = "Server" ":" 1*( product | comment )

    Например:

    Server: CERN/3.0 libwww/2.17

    Если отклик переадресуется через прокси, приложение прокси не должно модифицировать заголовок отклика сервера. Вместо этого ему следует включить в отклик поле Via (как это описано в разделе 13.44).

    Замечание. Раскрытие конкретной версии программного обеспечения сервера может облегчить атаки против программных продуктов, для которых известны уязвимые места. Разработчикам серверов рекомендуется сделать это поле конфигурируемой опцией.

    13.40. Поле Transfer-Encoding (Транспортное кодирование)

    Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования (если таковое использовано) применен к телу сообщения, для того чтобы безопасно осуществить передачу между отправителем и получателем. Это поле отличается от Content-Encoding тем, что транспортное кодирование является параметром сообщения, а не объекта.

    Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding

    Транспортное кодирование определено в разделе 2.6. Например:

    Transfer-Encoding: chunked

    Многие старые приложения HTTP/1.0 не воспринимают заголовок Transfer-Encoding.

    13.41. Заголовок Upgrade (Актуализация)

    Общий заголовок Upgrade позволяет клиенту специфицировать то, какие дополнительные коммуникационные протоколы он поддерживает и хотел бы использовать, если сервер найдет их подходящими. Сервер должен использовать поле заголовка Upgrade в отклике 101 (Switching Protocols) для указания того, какие протоколы активны.

    Upgrade

    = "Upgrade" ":" 1#product

    Например:,

    Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

    Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода от протокола HTTP/1.1 к некоторым другим. Это достигается путем разрешения клиенту объявлять о намерении использовать другой протокол, например, более позднюю версию HTTP с большим старшим кодом версии, даже если текущий запрос выполнен с использованием HTTP/1.1. Это облегчает переходы между несовместимыми протоколами за счет разрешения клиенту инициировать запрос в более широко поддерживаемом протоколе, в то же время, указывая серверу, что он предпочел бы использовать протокол "получше", если таковой доступен (где слово "получше" определяется сервером, возможно согласно природы метода и/или запрашиваемого ресурса).

    Поле заголовка Upgrade воздействует только на переключающий протокол прикладного уровня транспортного слоя существующег соединения. Upgrade не может быть использовано для требования изменения протокола, его восприятие и использование сервером является опционным. Совместимость и природа прикладного уровня коммуникаций после смены протокола зависит исключительно от нового выбранного протокола, хотя первым действием после такой замены должен быть отклик на исходный запрос HTTP, содержащий поле заголовка Upgrade.

    Поле Upgrade применимо только к текущему соединению. Следовательно, ключевое слово upgrade должно содержаться в поле заголовка Connection (раздел 13.10) всякий раз, когда поле Upgrade присутствует в сообщении HTTP/1.1.

    Поле заголовка Upgrade не может использоваться для указания смены протокола в другом соединении. Для этой цели более приемлемы отклики переадресации с кодами 301, 302, 303 или 305.

    Эта спецификация определяет протокол с именем "HTTP" при работе с семейством протоколов для передачи гипертекста (Hypertext Transfer Protocols), как это определено в правилах работы с версиями HTTP раздела 2.1 и для будущих усовершенствований этой спецификации. В качестве имени протокола может использоваться любая лексема, однако она будет работать, только если клиент и сервер ассоциируют это имя с одним и тем же протоколом.

    13.42. Поле User-Agent (Агент пользователя)

    Поле заголовка отклика User-Agent содержит информацию об агенте пользователя, инициировавшем запрос. Это нужно для целей сбора статистических данных, отслеживания нарушений протокола и автоматического распознавания агентов пользователя. Агентам пользователя рекомендуется включать это поле в запросы. Поле может содержать несколько кодов продуктов (раздел 2.8), комментарии, идентифицирующие агента и любые субпродукты, которые образуют существенную часть агента пользователя. Согласно договоренности коды программных продуктов перечисляются в порядке их важности для идентифицируемого приложения.

    User-Agent

    = "User-Agent" ":" 1*( product | comment )

    Например:

    User-Agent: CERN-LineMode/2.15 libwww/2.17b3

    13.43. Поле Vary

    Поле заголовка отклика Vary используется сервером для того, чтобы сигнализировать о том, что отклик выбран из числа имеющихся представлений с помощью механизма согласования под управлением сервера (раздел 11). Имена полей, перечисленные в заголовках Vary, являются такими заголовками запроса. Значение поля Vary указывает на то, что данный набор полей заголовка ограничивает пределы, в которых могут варьироваться представления, или что пределы вариации не специфицированы ("*") и, таким образом, могут модифицироваться в широких пределах для будущих запросов.

    Vary

    = "Vary" ":" ( "*" | 1#field-name )

    Сервер HTTP/1.1 должен включать соответствующее поле заголовка Vary в любой кэшируемый отклик, который является субъектом, управляющим процессом согласования. Такая схема позволяет кэшу правильно интерпретировать будущие запросы к заданному ресурсу и информирует пользователя о согласовании доступа к ресурсу. Серверу следует включить соответствующее поле заголовка Vary в некэшируемый отклик, который является субъектом, управляющим согласованием, так как это может предоставить агенту пользователя полезную информацию о пределах вариации отклика.

    Набор полей заголовка, перечисленных в поле Vary известен как "выбирающие" заголовки запроса.

    Когда кэш получает последующий запрос, чей Request-URI специфицирует одну или более записей кэша, включая заголовок Vary, кэш не должен использовать такую запись для формирования отклика на новый запрос. Он это должен делать, если только все заголовки, перечисленные в кэшированном заголовке Vary, присутствуют в новом запросе и все заголовки отбора предшествующих запросов совпадают с соответствующими заголовками нового запроса.

    Сортирующие заголовки от двух запросов считаются соответствующими, тогда и только тогда, когда сортирующие заголовки первого запроса могут быть преобразованы в сортирующие заголовки второго запроса с помощью добавления или удаления строчных пробелов LWS (Linear White Space) в местах, где это допускается соответствующими правилами BNF (Backus-Naur Form) и/или, комбинируя несколько полей заголовка согласно требованиям на построение сообщения из раздела 3.2.

    Vary "*" означает, что не специфицированные параметры, возможно отличающиеся от содержащихся в полях заголовка (напр., сетевой адрес клиента), играют роль при выборе представления отклика. Последующие запросы данного ресурса могут быть правильно интерпретированы только исходным сервером, а кэш должен переадресовать запрос (возможно условно), даже когда он имеет свежий кэшированный отклик для данного ресурса. Об использовании заголовка кэшами см. раздел 12.6.

    Значение поля Vary, состоящее из списка имен полей сигнализирует о том, что представление, выбранное для отклика, базируется на алгоритме выбора, который рассматривает только значения перечисленные в поле заголовка запроса. Кэш может предполагать, что тот же выбор будет сделан для будущих запросов с теми же значениями имен полей, для периода времени, в течение которого отклик остается свежим.

    Имена полей не ограничены набором стандартных полей заголовков запросов, определенных в данной спецификации. Имена полей могут быть записаны строчными или прописными буквами.

    13.44. Поле Via

    Поле общего заголовка Via должно быть использовано шлюзами или прокси для указания промежуточных протоколов и получателей на пути от агента пользователя к серверу, которому адресован запрос, и между исходным сервером и клиентом в случае отклика. Это аналогично полю "Received" документа RFC 822 и предназначено для использования при трассировке переадресаций сообщений, исключения петель запроса и идентификации протокольных возможностей всех отправителей вдоль цепочки запрос/отклик.

    Via

    = "Via" ":" 1#( received-protocol received-by [ comment ] )

    received-protocol

    = [ protocol-name "/" ] protocol-version

    protocol-name

    = token

    protocol-version

    = token

    received-by

    = ( host [ ":" port ] ) | pseudonym

    pseudonym

    = token

    Запись "received-protocol" указывает версию протокола в сообщении, полученном сервером или клиентом вдоль цепочки запрос/отклик. Версия received-protocol добавляется к значению поля Via, когда сообщение переадресуется, так что информация о возможностях протоколов предыдущих приложений остается прозрачной для всех получателей.

    Запись "protocol-name" является опционной, тогда и только тогда, когда это "HTTP". Поле "received-by" обычно соответствует ЭВМ и номеру порта сервера получателя или клиента, который переадресует сообщение. Однако, если настоящее имя ЭВМ считается конфиденциальной информацией, оно может быть заменено псевдонимом. Если номер порта не задан, можно предполагать, что используется значение по умолчанию для данного протокола (received-protocol).

    Значения поля Via представляет каждый прокси или шлюз, который переадресовывал сообщение. Каждый получатель должен присоединить свою информацию так, что конечный результат оказывается упорядоченным согласно последовательности переадресующих приложений.

    Комментарии могут быть использованы в поле заголовка Via для идентификации программ получателя прокси или шлюза аналогично полям User-Agent и Server header. Однако, все комментарии в поле Via являются опционными и могут быть удалены любым получателем перед тем, как переадресовать сообщение.

    Например, сообщение-запрос может быть послано от агента пользователя HTTP/1.0 программе внутреннего прокси с именем "fred", которая использует HTTP/1.1 для того, чтобы переадресовать запрос общедоступному прокси с именем nowhere.com, который завершает процесс переадресации запроса исходному серверу www.ics.uci.edu. Запрос, полученный www.ics.uci.edu будет тогда иметь следующее поле заголовка Via:

    Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

    Прокси и шлюзы, используемые как средства сетевой защиты (firewall) не должны по умолчанию переадресовывать имена ЭВМ и портов в пределах области firewall. Эта информация может передаваться, если это непосредственно позволено. Если это не разрешено, запись "received-by" для ЭВМ в зоне действия firewall должна быть заменена соответствующим псевдонимом.

    Для организаций, которые имеют жесткие требования к защите конфиденциальности и сокрытию внутренней структуры, прокси может комбинировать субпоследовательность поля заголовка Via с идентичными значениями "received-protocol" в единую запись. Например,

    Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya

    Приложениям не следует комбинировать несколько записей, если они только не находятся под единым административным контролем и имена ЭВМ уже заменены на псевдонимы. Приложения не должны комбинировать записи, которые имеют различные значения "received-protocol".

    13.45. Поле Warning (Предупреждение)

    Поле заголовка отклика Warning используется для переноса дополнительной информации о состоянии отклика, которая может отражать статусный код. Эта информация обычно служит для предупреждения о возможной потере семантической прозрачности из-за операций кэширования. Заголовки Warning посылаются с откликами, используя:

    Warning

    = "Warning" ":" 1#warning-value

    warning-value

    = warn-code SP warn-agent SP warn-text

    warn-code

    = 2DIGIT

    warn-agent

    = ( host [ ":" port ] ) | pseudonym

    ; имя или псевдоним сервера, добавившего заголовок Warning, предназначенный для целей отладки

    warn-text

    = quoted-string

    Отклик может нести в себе более одного заголовка Warning.

    Запись warn-text производится на естественном языке и с применением символьного набора, приемлемого для принимающего отклик лица. Это решение может базироваться на какой-то имеющейся информации, такой как положение кэша или пользователя, поле запроса Accept-Language, поле отклика Content-Language и т.д. Языком по умолчанию является английский, а символьным набором - ISO-8859-1.

    Если используется символьный набор отличный от ISO-8859-1, он должен быть закодирован в warn-text с использованием метода, описанного в RFC-1522 [14].

    Любой сервер или кэш может добавить заголовки Warning к отклику. Новые заголовки Warning должны добавляться после любых существующих заголовков Warning. Кэш не должен уничтожать какие-либо заголовки, которые он получил в отклике. Однако, если кэш успешно перепроверил запись, ему следует удалить все заголовки Warning, присоединенные ранее, за исключением специальных кодов Warning. Он должен добавить к записи новые заголовки Warning, полученные с откликом перепроверки. Другими словами заголовками Warning являются те, которые были бы получены в отклике на запрос в данный момент.

    Когда к отклику подключено несколько заголовков Warning, агенту пользователя следует отображать их столько, сколько возможно, для того чтобы они появились в отклике. Если невозможно отобразить все предупреждения, агент пользователя должен следовать следующим эвристическим правилам:

    • Предупреждения, которые появляются в отклике раньше, имеют приоритет перед теми, что появляются позже.
    • Предупреждения, с предпочитаемым пользователем символьным набором имеют приоритет перед предупреждениями с другими наборами, но с идентичными warn-codes и warn-agents.

    Системы, которые генерируют несколько заголовков Warning, должны упорядочить их с учетом ожидаемого поведения агента пользователя.

    Далее представлен список определенных в настоящее время кодов предупреждений, каждый из которых сопровождается рекомендуемым текстом на английском языке и описанием его значения.

    10 Response is stale (отклик устарел)

    Должно включаться всякий раз, когда присылаемый отклик является устаревшим. Кэш может добавить это предупреждение к любому отклику, но не может удалить его до тех пор, пока не будет установлено, что отклик является свежим.

    11 Revalidation failed (перепроверка пригодности неудачна)

    Должно включаться, если кэш присылает устаревший отклик, потому что попытка перепроверить его пригодность не удалась, из-за невозможности достичь сервера. Кэш может добавить это предупреждение к любому отклику, но никогда не может удалить его до тех пор, пока не будет успешно проведена перепроверка пригодности отклика.

    12 Disconnected operation (работа в отключенном от сети состоянии)

    Следует включать, если кэш намерено отключен от остальной сети на определенный период времени.

    13 Heuristic expiration (эвристическое завершение периода пригодности)

    Должно включаться, если кэш эвристически выбрал время жизни больше 24 часов, а возраст отклика превышает эту величину.

    14 Transformation applied (применено преобразование)

    Должно добавляться промежуточным кэшем или прокси, если он использует какое-либо преобразование, изменяющее кодировку содержимого (как это специфицировано в заголовке Content-Encoding) или тип среды (как это описано в заголовке Content-Type) отклика, если только этот код предупреждения не присутствует уже в отклике.

    99 Разные предупреждения

    Текст предупреждения включает в себя любую информацию, которая может быть представлена человеку-оператору или может быть занесена в дневник операций. Система, получающая это предупреждение, не должна предпринимать каких-либо действий автоматически.

    13.46. Поле WWW-Authenticate

    Поле заголовка отклика WWW-Authenticate должно включаться в сообщения откликов со статусным кодом 401 (Unauthorized). Значение поля содержит, по крайней мере, одно требование, которое указывает на схему идентификации и параметры, применимые для Request-URI.

    WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

    Процесс авторизации доступа HTTP описан в разделе 10. Агенты пользователя должны проявлять особую тщательность при разборе значения поля WWW-Authenticate, если оно содержит более одного требования, или если прислан более чем одно поле заголовка WWW-Authenticate, так как содержимое требования может само содержать список параметров идентификации, элементы которого разделены запятыми.

    14. Соображения безопасности

    Этот раздел предназначен для того, чтобы проинформировать разработчиков приложений, поставщиков информации и пользователей об ограничениях безопасности в HTTP/1.1, как это описано в данном документе. Обсуждение не включает определенные решения данных проблем, но рассматриваются некоторые предложения, которые могут уменьшить риск.

    14.1. Аутентификация клиентов

    Базовая схема идентификации не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и какох-либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей).

    Наиболее серьезным дефектом базового механизма идентификации является то, что пароль пользователя передается по сети в незашифрованном виде.

    Так как базовая идентификация предусматривает пересылку паролей открытым текстом, она никогда не должна использоваться (без улучшения) для работы с конфиденциальной информацией.

    Обычным назначением базовой идентификации является создание информационной (справочной) среды, которая требует от пользователя его имени и пароля, например, для сбора точной статистики использования ресурсов сервера. При таком использовании предполагается, что не существует никакой опасности даже в случае неавторизованного доступа к защищенному документу. Это правильно, если сервер генерирует сам имя и пароль пользователя и не позволяет ему выбрать себе пароль самостоятельно. Опасность возникает, когда наивные пользователи часто используют один и тот же пароль, чтобы избежать необходимости внедрения многопарольной системы защиты.

    Если сервер позволяет пользователям выбрать их собственный пароль, тогда возникает опасность несанкционированного доступа к документам на сервере и доступа ко всем аккаунтам пользователей, которые выбрали собственные пароли. Если пользователям разрешен выбор собственных паролей, то это означает, что сервер должен держать файлы, содержащие пароли (предположительно в зашифрованном виде). Многие из этих паролей могут принадлежать удаленным пользователям. Собственник или администратор такой системы может помимо своей воли оказаться ответственным за нарушения безопасности сохранения информации.

    Базовая идентификация уязвима также для атак поддельных серверов. Когда пользователь связывается с ЭВМ, содержащей информацию, защищенную с использованием базовой системой идентификации, может так получиться, что в действительности он соединяется с сервером-злоумышленником, целью которого является получение идентификационных параметров пользователя (например, имени и пароля). Этот тип атак не возможен при использовании идентификации с помощью дайджестов [32]. Разработчики серверов должны учитывать возможности такого рода атак со стороны ложных серверов или CGI-скриптов. В частности, очень опасно для сервера просто прерывать связь со шлюзом, так как этот шлюз может тогда использовать механизм постоянного соединения для выполнения нескольких процедур с клиентом, исполняя роль исходного сервера, так что это незаметно клиенту.

    14.2. Предложение выбора схемы идентификации

    Сервер HTTP/1.1 может прислать несколько требований с откликом 401 (Authenticate) и каждое требование может использовать разную схему. Порядок присылки требований соответствует шкале предпочтений сервера. Сервер должен упорядочит требования так, чтобы наиболее безопасная схема предлагалась первой. Агент пользователя должен выбрать первую понятную ему схему.

    Когда сервер предлагает выбор схемы идентификации, используя заголовок WWW-Authenticate, безопасность может быть нарушена только за счет того, что злонамеренный пользователь может перехватить набор требований и попытаться идентифицировать себя, используя саму слабую схему идентификации. Таким образом, упорядочение служит более для защиты идентификационных параметров пользователя, чем для защиты информации на сервере.

    Возможна атака MITM (man-in-the-middle - "человек в середине"), которая заключается в добавлении слабой схемы идентификации к списку выбора в надежде на то, что клиент выберет именно ее и раскроет свой пароль. По этой причине клиент должен всегда использовать наиболее строгую схему идентификации из предлагаемого списка.

    Еще эффективнее может быть MITM-атака, при которой удаляется весь список предлагаемых схем идентификации, и вставляется вызов, требующий базовой схемы идентификации. По этой причине агенты пользователя, обеспокоенные таким видом атак, могут запомнить самую строгую схему идентификации, которая когда-либо запрашивалась данным сервером, и выдавать предупреждение, которое потребует подтверждения пользователя при использовании более слабой схемы идентификации. Особенно хитроумный способ реализации MITM-атаки является предложение услуг "свободного" кэширования для доверчивых пользователей.

    14.3. Злоупотребление служебными (Log) записями сервера

    Сервер должен оберегать информацию о запросах пользователя, о характере его интересов (такая информация доступна в дневнике операций сервера). Эта информация является, очевидно, конфиденциальной по своей природе и работа с ней во многих странах ограничена законом. Люди, использующие протокол HTTP для получения данных, являются ответственными за то, чтобы эта информация не распространялась без разрешения лиц, кого эта информация касается.

    14.4. Передача конфиденциальной информации

    Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации. Четыре поля заголовка представляют интерес с этой точки зрения: Server, Via, Referer и From. Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией. Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall. В частности они должны удалять или замещать любые поля Via, созданные в пределах firewall. Хотя поле Referer может быть очень полезным, его мощь может быть использована во вред, если данные о пользователе не отделены от другой информации, содержащейся в этом поле. Даже когда персональная информация удалена, поле Referer может указывать на URI частных документов, чья публикация нежелательна. Информация, посланная в поле From, может вступать в конфликт с интересами конфиденциальности пользователя или с политикой безопасности его домена, и, следовательно, она не должна пересылаться и модифицироваться без прямого разрешения пользователя. Пользователь должен быть способен установить содержимое этого поля, в противном случае оно будет установлено равным значению по умолчанию. Мы предлагаем, хотя и не требуем, чтобы предоставлялся удобный интерфейс для пользователя, который позволяет активировать и дезактивировать посылку информации полей From и Referer.

    14.5. Атаки, основанные на именах файлов и проходов

    Реализации исходных серверов HTTP должна быть тщательной, чтобы ограничить список присылаемых HTTP документов теми, которые определены для этого администратором сервера. Если сервер HTTP транслирует HTTP URI непосредственно в запросы к файловой системе, сервер должен следить за тем, чтобы не пересылать файлы клиентам HTTP, для этого не предназначенные. Например, UNIX, Microsoft Windows и другие операционные системы используют ".." как компоненту прохода, чтобы указать уровень каталога выше текущего. В такой системе сервер HTTP должен запретить любую подобную в Request-URI, если она позволяет доступ к ресурсу за пределами того, что предполагалось. Аналогично, файлы, предназначенные только для внутреннего использования сервером (такие как файлы управления доступом, конфигурационные файлы и коды скриптов) должны быть защищены от несанкционированного доступа, так как они могут содержать конфиденциальную информацию. Практика показала, что даже незначительные ошибки в реализации сервера HTTP могут привести к рискам безопасности.

    14.6. Персональная информация

    Клиентам HTTP небезразличнен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Мы настоятельно рекомендуем, чтобы был создан удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации.

    14.7. Аспекты конфиденциальности, связанные с заголовками Accept

    Заголовок запроса Accept может раскрыть информацию о пользователе всем серверам, к которым имеется доступ. В частности, заголовок Accept-Language может раскрыть информацию, которую пользователь, возможно, рассматривает как конфиденциальную. Так, например, понимание определенного языка часто строго коррелируется с принадлежностью к определенной этнической группе. Агентам пользователя, которые предлагают возможность конфигурирования содержимого заголовка Accept-Language, настоятельно рекомендуется посылать сообщение пользователю о том, что в результате может быть потеряна конфиденциальность определенных данных. Подходом, который ограничивает потерю конфиденциальности для агента пользователя, может быть отказ от посылки заголовков Accept-Language по умолчанию. Предполагается при этом каждый раз консультироваться с пользователем относительно возможности посылки этих данных серверу. Пользователь будет принимать решение о посылке Accept-Language, лишь убедившись на основании содержимого заголовка отклика Vary в том, что такая посылка существенно улучшит качество обслуживания.

    Для многих пользователей, которые размещены не за прокси, сетевой адрес работающего агента пользователя может также использоваться как его идентификатор. В среде, где прокси используются для повышения уровня конфиденциальности, агенты пользователя должны быть достаточно консервативны в предоставлении опционного конфигурирования заголовков доступа конечным пользователям. В качестве крайней меры обеспечения защиты прокси могут фильтровать заголовки доступа для передаваемых запросов. Главной целью агентов пользователя, которые предоставляют высокий уровень конфигурационных возможностей, должно быть предупреждение пользователя о возможной потере конфиденциальности.

    14.8. Фальсификация DNS

    Клиенты, интенсивно использующие HTTP обмен со службой имен домена (Domain Name Service), обычно предрасположены к атакам, базирующимся на преднамеренном некорректном соответствии IP адресов и DNS имен. Клиенты должны быть осторожны относительно предположений, связанных с ассоциаций IP адресов и DNS имен.

    В частности, клиенту HTTP следует полагаться на его сервер имен для подтверждения соответствия IP адресов и DNS имен, а не слепо кэшировать результаты предшествующих запросов. Многие платформы могут кэшировать такие запросы локально и это надо использовать, конфигурируя их соответствующим образом. Такие запросы должны кэшироваться, однако только на период, пока не истекло время жизни этой информации.

    Если клиенты HTTP кэшируют результат DNS-запроса для улучшения рабочих характеристик, они должны отслеживать пригодность этих данных с учетом времени жизни, объявляемого DNS-сервером.

    Если клиенты HTTP не следуют этому правилу, они могут быть мистифицированы, когда изменится IP-адрес доступного ранее сервера. Так как смена адресов в сетях будет в ближайшее время активно развиваться (Ipv6 !), такого рода атаки становятся все более вероятными.

    Данное требование улучшает работу клиентов, в том числе с серверами, имеющими идентичные имена.

    14.9. Заголовки Location и мистификация

    Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, тогда он должен проверять значения заголовков Location и Content-Location в откликах, которые формируются под управлением этих организаций. Это следует делать, чтобы быть уверенным, что они не пытаются провести какие-либо операции над ресурсами, доступ к которым для них ограничен.

    16. Библиография

    [1]

    Alvestrand, H., "Tags for the identification of languages", RFC 1766, UNINETT, March 1995.

    [2]

    Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti. "The Internet Gopher Protocol: (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993

    [3]

    Berners-Lee, T., "Universal Resource Identifiers in WWW", A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994

    [4]

    Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994

    [5]

    Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995

    [6]

    Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May 1996

    [7]

    Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996.

    [8]

    Braden, R., "Requirements for Internet hosts - application and support", STD3, RFC 1123, IETF, October 1989

    [9]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982

    [10]

    Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification", (v1.5), Thinking Machines Corporation, April 1990

    [11]

    Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995

    [12]

    Horton, M., and R. Adams. "Standard for interchange of USENET messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987

    [13]

    Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego, UC Berkeley, February 1986

    [14]

    Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996

    [15]

    Nebel, E., and L. Masinter. "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995.

    [16]

    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/ISI, August 1982

    [17]

    Postel, J., "Media Type Registration Procedure", RFC 2048, USC/ISI, November 1996

    [18]

    Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/ISI, October 1985

    [19]

    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700, USC/ISI, October 1994

    [20]

    Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994

    [21]

    US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986

    [22]

    ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets

    Part 1: Latin alphabet No. 1, ISO 8859-1:1987

    Part 2: Latin alphabet No. 2, ISO 8859-2, 1987

    Part 3: Latin alphabet No. 3, ISO 8859-3, 1988

    Part 4: Latin alphabet No. 4, ISO 8859-4, 1988

    Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988

    Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987

    Part 7: Latin/Greek alphabet, ISO 8859-7, 1987

    Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988

    Part 9: Latin alphabet No. 5, ISO 8859-9, 1990

    [23]

    Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC1864, Carnegie Mellon, Dover Beach Consulting, October, 1995

    [24]

    Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, IAB, February 1996.

    [25]

    Deutsch, P., "GZIP file format specification version 4.3." RFC1952, Aladdin Enterprises, May 1996

    [26]

    Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/ mogul/HTTPLatency.html.

    [27]

    Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance", , USC/Information Sciences Institute, June 1996

    [28]

    Mills, D., "Network Time Protocol, Version 3, Specification, Implementation and Analysis", RFC 1305, University of Delaware, March 1992

    [29]

    Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, Aladdin Enterprises, May 1996

    [30]

    Spero, S., "Analysis of HTTP Performance Problems" .

    [31]

    Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996

    [32]

    Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997

    16. Приложения
    16.1. Интерентовский тип среды "message/http"

    В дополнение к определению протокола HTTP/1.1, данный документ является спецификацией для типов среды Интернет "message/http". Ниже приведенный список является официальным для IANA.

    Media Type name:

    message

    Media subtype name:

    http

    Required parameters:

    none

    Optional parameters:

    version, msgtype

    version: Номер версии HTTP вложенного сообщения (напр., "1.1"). Если отсутствует, номер версии может быть определен по первой строке тела сообщения.

    msgtype: Тип сообщения -- "запроса" или "отклика". Если отсутствует, тип может быть определен по первой строке тела сообщения.

    Соображения кодирования: разрешено только "7bit", "8bit" или "binary" (двоичное).

    16.2. Тип среды Интернет "multipart/byteranges"

    Когда сообщение HTTP содержит несколько фрагментов (ranges) (например, отклик на запрос нескольких не перекрывающихся фрагментов), они пересылаются как многофрагментное сообщение MIME. Тип среды multipart для этих целей носит название "multipart/byteranges".

    Тип среды multipart/byteranges содержит в себе две или более части, каждая из которых со своими полями Content-Type и Content-Range. Отдельные части разделяются с использованием пограничного параметра MIME.

    Media Type name:

    multipart

    Media subtype name:

    byteranges

    Required parameters: boundary
    Optional parameters: none

    Соображения кодирования: разрешено только "7bit", "8bit" или "binary".

    • Например:
      HTTP/1.1 206 Partial content
      Date: Wed, 15 Nov 1995 06:25:24 GMT
      Last-modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES--THIS_STRING_SEPARATES
      Content-type: application/pdf
      Content-range: bytes 500-999/8000
      ...первый фрагмент ...
      --THIS_STRING_SEPARATES
      Content-type: application/pdf
      Content-range: bytes 7000-7999/8000
      ...второй фрагмент...
      --THIS_STRING_SEPARATES--

    16.3. Толерантные приложения

    Хотя этот документ специфицирует требования к генерации HTTP/1.1 сообщений, не все приложения будут корректны. Мы, следовательно, рекомендуем, чтобы рабочие приложения были толерантны (терпимы) к некоторым отклонениям от требований, при условии, что эти отклонения можно однозначно интерпретировать. Клиенту следует быть толерантным при разборе Status-Line, а серверу - при разборе Request-Line. В частности, им следует воспринимать любое число символов SP или HT между полями, хотя требуется только один пробел (SP). Терминатором строки полей заголовков сообщения является CRLF. Однако рекомендуется, чтобы приложение при разборе таких заголовков распознавало в качестве терминатора строки одиночный символ LF и игнорировала предыдущий символ CR. Символьный набор тела объекта должен быть снабжен меткой. Метка не нужна только для набора US-ASCII или ISO-8859-1. Правила разбора и кодирования дат и пр. включают в себя предположение, что HTTP/1.1 клиенты и кэши должны предполагать, что даты, следующие документу RFC-850 и относящиеся ко времени 50 лет в будущем, на самом деле относятся к прошлому (это помогает решить проблему "2000-го года").

    • Приложение HTTP/1.1 может внутри представлять время истечения годности раньше, чем истинное значение, но не должно представлять его позднее истинного значения.
    • Все вычисления, относящиеся ко времени пригодности должны выполняться в шкале GMT (по Гринвичу). Местные временные зоны не должны оказывать влияния на вычисления и сравнение возраста и времени пригодности.

    Если заголовок HTTP несет в себе некорректное значение даты с временной зоной отличной от GMT, значение должно быть преобразовано в GMT.

    16.4. Различие между объектами HTTP и MIME

    HTTP/1.1 использует много конструкций, определенных для электронной почты Интернет (RFC 822) и MIME (Multipurpose Internet Mail Extensions), для обеспечения пересылки объектов в различных представлениях. MIME [7] обслуживает электронную почту, а HTTP имеет лишь ряд черт, которые отличают его от MIME. Эти отличия тщательно подобраны, чтобы оптимизировать работу в условиях двоичных соединений, с тем чтобы достичь большей свободы в использовании новых типов сред. Прокси и шлюзы должны по возможности исключать такие отличия и обеспечивать соответствующие преобразования там, где это нужно.

    16.4.1. Преобразование к канонической форме

    MIME требует, чтобы почтовый объект Интернет перед посылкой был преобразован в каноническую форму. Раздел 2.7.1 описывает формы, допустимые для подтипов типа среды "text" при пересылке с использованием HTTP. MIME требует, чтобы содержимое типа "text" представляло разрывы строк в виде последовательности символов CRLF и запрещает использование CR или LF отдельно. Для обозначения разрыва строки HTTP позволяет использовать CRLF, одиночный CR и одиночный LF. Всюду где возможно, прокси и шлюзы между средами HTTP и MIME должны преобразовать все разрывы строк для текстовых типов среды, как это описано в разделе 2.7.1. Заметьте однако, что это может вызвать сложности в присутствии кодирования содержимого, а также вследствие того, что HTTP допускает применение символьных наборов, которые не используют октеты 13 и 10 для представления CR и LF, так как для этих целей здесь служат многобайтовые последовательности.

    16.4.2. Преобразование форматов даты

    Для того чтобы упростить сравнение, HTTP/1.1 использует ограниченный набор форматов даты (раздел 2.3.1). Прокси и шлюзы должны позаботиться о преобразовании полей заголовков даты в один из допустимых форматов всякий раз, когда это необходимо (при получении данных от других протоколов).

    16.4.3. Введение кодирования содержимого

    MIME не содержит какого-либо эквивалента полю заголовка Content-Encoding HTTP/1.1. Так как это поле работает как модификатор типа среды, прокси и шлюзы между HTTP и MIME протоколами должны или изменить значение поля заголовка Content-Type или декодировать тело объекта, прежде чем переадресовывать сообщение. Некоторые экспериментальные приложения Content-Type для почты Интернет используют параметр типа среды ";conversions=" для выполнения операции, аналогичной Content-Encoding. Однако, этот параметр не является частью MIME.

    16.4.4. No Content-Transfer-Encoding

    HTTP не использует поле MIME CTE (Content-Transfer-Encoding). Прокси и шлюзы от MIME к HTTP должны удалять любую не идентичность CTE ("quoted-printable" или "base64") кодирования, прежде чем доставлять сообщение-отклик клиенту HTTP.

    Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы сообщения имели корректные форматы и кодировки для безопасной транспортировки, (где безопасная транспортировка определяется ограничениями используемого протокола). Такие прокси и шлюзы должны помечать информацию согласно Content-Transfer-Encoding, поступая так, мы улучшаем вероятность безопасной транспортировки с использованием протокола места назначения.

    16.4.5. Поля заголовка в многофрагментных телах

    В MIME, большинство полей заголовка в многофрагментных частях игнорируются, если только имя поля не начинается с "Content-". В HTTP/1.1, многофрагментные части тела могут содержать любые поля заголовков HTTP, которые имеют смысл для этой части.

    16.4.6. Введение транспортного кодирования

    HTTP/1.1 вводит поле заголовка Transfer-Encoding (раздел 13.40). Прокси/шлюзы должны удалять любое транспортное кодирование перед переадресацией сообщения через протокол MIME.

    Процесс декодирования транспортного кода (раздел 2.6) может быть представлен в виде псевдо-программы:

    length := 0
    read chunk-size, chunk-ext (if any) and CRLF
    while (chunk-size > 0) {

    read chunk-data and CRLF
    append chunk-data to entity-body
    length := length + chunk-size
    read chunk-size and CRLF
    }
    read entity-header
    while (entity-header not empty) {
    append entity-header to existing header fields
    read entity-header
    }
    Content-Length := length
    Remove "chunked" from Transfer-Encoding

    16.4.7. MIME-Version

    HTTP не является протоколом, совместимым с MIME (смотри приложение 16.4). Однако HTTP/1.1 сообщения могут включать поле общего заголовка MIME-Version, для того чтобы указать, какая версия протокола MIME была использована для конструирования сообщения. Использование заголовка поля MIME-Version отмечает, сообщение полностью соответствует протоколу MIME. Прокси/шлюзы несут ответственность за полную совместимость (где возможно), когда осуществляется передача HTTP сообщений в среду MIME.

    MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

    HTTP/1.1 использует по умолчанию версию MIME "1.0". Однако разбор сообщений HTTP/1.1 и семантика определяются данным документом, а не спецификацией MIME.

    16.5. Изменения по отношению HTTP/1.0

    Этот раздел обобщает основные отличия между версиями HTTP/1.0 и HTTP/1.1.

    16.5.1. Изменения с целью упрощения распределенных WWW-сервером и экономии IP адресов

    Требование того, чтобы клиенты и серверы воспринимали абсолютные URI (раздел 4.1.2) и поддерживали заголовки Host, откликались кодами ошибки при отсутствии заголовка Host (раздел 13.23) в запросе HTTP/1.1, являются наиболее важными изменениями, внесенными данной спецификацией.

    Более старые HTTP/1.0 клиенты предполагают однозначное соответствие IP адресов и серверов. Изменения, описанные выше, позволяют Интернет поддерживать несколько WWW узлов с помощью одного IP-адреса. Высокая скорость роста WWW-сети, большое число уже существующих серверов делают крайне важным, чтобы реализации HTTP (включая усовершенствования существующих HTTP/1.0 приложений) корректно следовали перечисленным ниже требованиям:

    • Как клиент, так и сервер должны поддерживать заголовки запроса Host.
    • Заголовки Host необходимы в запросах HTTP/1.1.
    • Серверы должны откликаться кодом ошибки 400 (Bad Request), если запрос HTTP/1.1 не содержит заголовка Host.
    • Серверы должны воспринимать абсолютные URI.

    16.6. Дополнительные функции

    Это приложение документирует протокольные элементы, используемые некоторыми существующими реализациями HTTP, но не вполне корректно совместимыми с большинством HTTP/1.1 приложений.

    16.6.1. Дополнительные методы запросов
    16.6.1.1. Метод PATCH

    Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH. Список отличий записывается в формате, определенном типом среды объекта (например, "application/diff"), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную.

    Если запрос проходит через кэш и Request-URI идентифицирует объект в кэше, этот объект должен быть удален из кэша. Отклики для этого метода не кэшируются.

    Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений, установленным в разделе 7.2. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными, как это описано в разделе 12.10 для PUT.

    16.6.1.2. Метод LINK

    Метод LINK устанавливает один или более связей между ресурсами, идентифицированными Request-URI, и другими существующими ресурсами. Отличие между LINK и другими методами, допускающими установление связей между ресурсами, заключается в том, что метод LINK не позволяет послать в запросе любое тело сообщения и не вызывает непосредственно создания новых ресурсов. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют LINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT.

    16.6.1.3. Метод UNLINK

    Метод UNLINK удаляет одну или более связей между ресурсами, идентифицированными Request-URI. Эти связи могут быть установлены с использованием метода LINK или каким-либо другим методом, поддерживающим заголовок Link. Удаление связи с ресурсом не подразумевает, что ресурс перестает существовать или становится недоступным. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют UNLINK, должны объявить кэшированные отклики непригодными, как это определено в разделе 12.10 для PUT.

    16.6.2. Определения дополнительных полей заголовка
    16.6.2.1. Поле Alternates

    Поле заголовка отклика Alternates было предложено в качестве средства исходного сервера для информирования клиента о других доступных представлениях запрошенного ресурса. При этом выдается информация об их специфических атрибутах, все это образует более надежное основание агенту пользователя для выбора представления, которое лучше соответствует желаниям пользователя (описано как согласование под управлением агента пользователя в разделе 11). Поле заголовка Alternates является ортогональным по отношению к полю заголовка Vary, вместе с тем они могут сосуществовать в сообщении без последствий для интерпретации отклика или доступных представлений. Ожидается, что поле Alternates предоставит заметное улучшение по сравнению с согласованием под управлением сервера, предоставляемым полем Vary для ресурсов, которые варьируются в общих пределах подобно типу и языку. Поле заголовка Alternates будет определено в будущей спецификации.

    16.6.2.2. Поле Content-Version

    Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, 16.6.2.3, это позволяет группе людей вести разработку в интерактивном режиме.

    Content-Version = "Content-Version" ":" quoted-string.

    Примеры использования поля Content-Version:

    Content-Version: "2.1.2"
    Content-Version: "Fred 19950116-12:26:48"
    Content-Version: "2.5a4-omega7"

    16.6.2.3. Поле Derived-From

    Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем. Это поле используется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются в параллель многими субъектами.

    Derived-From = "Derived-From" ":" quoted-string.

    Пример использования поля:

    Derived-From: "2.1.1".

    Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался.

    16.6.2.4. Поле Link

    Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML[5].

    Link

    = "Link" ":"#("<" URI ">" *(";" link-param)

    link-param

    = (("rel" "=" relationship )

    | ("rev" "=" relationship)
    | ( "title" "=" quoted-string )
    | ( "anchor" "=" <"> URI <"> )
    | (link-extension ))

    link-extension

    = token ["=" (token | quoted-string )]

    relationship

    = sgml-name

    | ( <"> sgml-name *( SP sgml-name) <"> )

    sgml-name

    = ALPHA *( ALPHA | DIGIT | "." | "-")

    Запись значений отношения не зависит от использования строчных или прописных букв и может быть расширена в рамках синтаксиса имен sgml. Параметр заголовка может быть использован для пометки места назначения связи, такой как используется при идентификации в рамках меню для пользователя. Параметр типа якорь может использоваться для индикации источника якоря, отличного от всего текущего ресурса, такого как фрагмент данного ресурса. Примеры использования:

    Link: ; rel="Previous"
    Link: ; rev="Made"; title="Tim Berners-Lee"

    Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй указывает, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты.

    16.6.2.5. Поле URI

    Поле заголовка URI использовалось в прошлых версиях данной спецификации как комбинация существующих полей заголовка Location, Content-Location и Vary. Его первоначальной целью являлось включение списка дополнительных URI для ресурса, включая имена и положение зеркал. Однако, стало ясно, что комбинация многих различных функций в пределах одного поля мешает эффективной их реализации. Более того, мы полагаем, что идентификация имени положения зеркал лучше осуществлять через поле заголовка Link. Поле заголовка URI было признано менее удобным, чем эти поля.

    URI-header = "URI" ":" 1#( "<" URI ">" )

    16.7. Совместимость с предыдущими версиями

    HTTP/1.1 был специально спроектирован так, чтобы обеспечить совместимость с предыдущими версиями. Следует заметить, что на фазе разработки этой спецификации мы предполагали, что коммерческие HTTP/1.1 серверы будут следовать следующим правилам:

    • распознают формат Request-Line для запросов HTTP/0.9, 1.0 и 1.1;
    • воспринимают любой корректный запрос в формате HTTP/0.9, 1.0 или 1.1;
    • корректно откликаются сообщениями с той же версией, что использовал клиент.

    Мы также ожидаем, что клиенты HTTP/1.1:

    • распознают формат откликов Status-Line для HTTP/1.0 и 1.1;
    • воспринимают любой корректный отклик в формате HTTP/0.9, 1.0 или 1.1.

    Для большинства реализаций HTTP/1.0, каждое соединение устанавливается клиентом до посылки запроса и закрывается сервером после посылки отклика. Некоторые реализации используют версию Keep-Alive постоянного соединения, описанную в разделе 16.7.1.1.

    16.7.1. Совместимость с постоянными соединениями HTTP/1.0

    Некоторые клиенты и серверы могут пожелать быть совместимыми с некоторыми предшествующими реализациями HTTP/1.0 постоянных соединений клиента и сервера. Постоянные соединения в HTTP/1.0 должны согласовываться в явном виде, так как это не является вариантом по умолчанию. Экспериментальные реализации постоянных соединений в HTTP/1.0 не лишены ошибок. Проблема была в том, что некоторые существующие клиенты 1.0 могут посылать Keep-Alive прокси-серверу, которые не понимает Connection, и ошибочно переадресует его ближайшему серверу. Последний установит соединение Keep-Alive, что приведет к повисанию системы, так как прокси будет ждать close для отклика. В результате клиентам HTTP/1.0 должно быть запрещено использование Keep-Alive, когда они работают с прокси. Однако, взаимодействие с прокси является наиболее важным использованием постоянных соединений, по этой причине подобный запрет является не приемлемым. Следовательно, нам нужен какой-то другой механизм для индикации намерения установить постоянное соединение. Этот механизм должен быть безопасным даже при взаимодействии со старыми прокси, которые игнорируют Connection. Постоянные соединения для сообщений HTTP/1.1 работают по умолчанию; мы вводим новое ключевое слово (Connection: close) для декларации непостоянства соединения. Ниже описана оригинальная форма постоянных соединений для HTTP/1.0. Когда HTTP клиент соединяется с исходным сервером, он может послать лексему соединения Keep-Alive в дополнение к лексеме соединения Persist:

    Connection: Keep-Alive.

    Сервер HTTP/1.0 откликнется лексемой соединения Keep-Alive и клиент сможет установить постоянное (или Keep-Alive) соединение с HTTP/1.0. Сервер HTTP/1.1 может также установить постоянное соединение с клиентом HTTP/1.0 по получении лексемы соединения Keep-Alive. Однако, постоянное соединение с клиентом HTTP/1.0 не может быть использовано для по-фрагментного кодирования и, следовательно, должно использовать Content-Length для пометки конца каждого сообщения. Клиент не должен посылать лексему соединения Keep-Alive прокси-серверу, так как прокси-сервера HTTP/1.0 не следуют правилам HTTP/1.1 при разборе поля заголовка Connection.

    16.7.1.1. Заголовок Keep-Alive

    Когда лексема соединения Keep-Alive передана в рамках запроса или отклика, поле заголовка Keep-Alive может также присутствовать. Поле заголовка Keep-Alive имеет следующую форму:

    Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
    keepalive-param = param-name "=" value.

    Заголовок Keep-Alive является опционным и используется, если передается параметр. HTTP/1.1 не определяет каких-либо параметров. Если посылается заголовок Keep-Alive, должна быть передана соответствующая лексема соединения. Заголовок Keep-Alive без лексемы соединения должен игнорироваться.

    Previous: 4.5.6 WWW    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.6.2 Язык HTML


    previous up down next index index
    Previous: 4.5.6.1 Гипертекстный протокол HTTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.7 Протокол новостей NNTP

    4.5.6.2 Язык HTML
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1.

    Синтаксис HTML

    2.

    Описания атрибутов

    2.1.

    Булевы атрибуты

    3.

    HTML и URL

    4.

    Элементы, используемые в тексте документа

    5.

    Идентификаторы элементов. id и атрибуты классов.

    5.1.

    Элемент HTML

    5.2.

    Группирующие элементы div и span

    5.3.

    Элементы заголовков h1, h2, h3, h4, h5, h6

    5.4.

    Элементы address

    6.

    Спецификация языка содержимого документа. Атрибут lang

    7.

    Наследование языковых кодов

    8.

    Спецификация направления текста. Атрибут dir

    9.

    Текст

    9.1.

    Структурированный текст

    9.2.

    Цитирование. Элементы q и blockquote

    9.3.

    Верхние и нижние индексы. Элементы sub и sup

    9.4.

    Строки и параграфы

    9.4.1.

    Параграфы и элемент p

    9.5.

    Элемент br

    9.6.

    Предварительно сформатированный текст. Элемент pre

    10.

    Пометка изменений документа. Элементы ins и del

    11.

    Формат даты и времени

    12.

    Неупорядоченные (ul) и упорядоченные (ol) списки

    12.1.

    Списки, форматируемые визуальным агентом пользователя

    12.2.

    Списки определений. Элементы dl, dt и dd

    13.

    dir и элементы menu

    14.

    Таблицы

    14.1.

    Структура таблиц

    14.1.1.

    Элемент table

    14.2.

    Вычисление числа рядов и колонок в таблице

    14.3.

    Ориентация таблиц

    14.4.

    Надписи и таблицы. Элемент caption

    14.5.

    Группы рядов. Элементы thead, tfoot и tbody

    14.6.

    Опционные метки групп рядов

    14.7.

    Группы колонок. Элементы colgroup и col

    14.8.

    Элемент col

    14.9.

    Ряды таблицы. Элемент tr

    14.10.

    Ячейки таблицы. Элементы th и td

    14.11.

    Ячейки, которые занимают несколько рядов или колонок

    14.12.

    Горизонтальное и вертикальное выравнивание

    14.13.

    Границы и линии

    15.

    Информация о пути. Элемент base

    15.1.

    Связи и якоря

    15.2.

    Элементы, определяющие якоря

    15.3.

    Элемент А

    15.4.

    Связи mailto

    15.5.

    Вложенные связи

    15.6.

    Якоря с атрибутом id

    15.7.

    Элемент link

    15.8.

    Типы связей

    15.9.

    Связи с поисковыми системами

    16.

    Элемент object

    16.1.

    Инициализация объекта. Элемент param

    17.

    Изображения. Элемент img

    18.

    Введение аплетов. Элемент applet

    19.

    Введение HTML-документа в другой HTML-документ

    20.

    Введение карты изображения в HTML-документ

    20.1.

    Карты изображения клиента

    20.2.

    Карты изображения клиента с map и area

    21.

    Визуальное представление изображений, объектов и аплетов

    22.

    Как специфицировать альтернативный текст?

    23.

    Стилевые листы

    23.1.

    Стилевая информация заголовка. Элемент style

    23.2.

    Типы среды

    23.3.

    Внешние стилевые листы

    23.4.

    Установка именованного стиля по умолчанию

    23.5.

    Форматирование

    23.6.

    Плавающие объекты

    23.7.

    Элементы управления шрифтами: tt, i, b, big, small, strike, s и u

    23.8.

    Элементы модификаторов шрифтов: font и basefont

    23.9.

    Элемент hr

    24.

    Рамки (frames)

    24.1.

    Элемент frameset

    24.2.

    Элемент frame

    24.3.

    Установка для связей адресов по умолчания

    24.4.

    Элемент noframes

    24.5.

    Элемент iframe

    25.

    Формы

    25.1.

    Элемент form

    25.2.

    Элемент input

    25.3.

    Элемент isindex

    25.4.

    Элемент button

    25.5.

    Элемент select

    25.6.

    Элемент optgroup

    25.7.

    Элемент textarea

    25.8.

    Элемент label

    25.9.

    Элементы fieldset и legend

    26.

    Выделение элементов

    27.

    Скрипты

    27.1.

    Элемент script

    27.2.

    Локальная декларация языка скрипта

    27.3.

    Ссылки на HTML-документы из скрипта

    28.

    Динамическая модификация документов

    28.1.

    Элемент noscript

    28.2.

    Комментирование скриптов в javascript

    28.3.

    Комментирование скриптов в vbscript

    28.4.

    Комментирование скриптов в tcl

    29.

    Верификация документов

    29.1.

    Каталог образцов sgml

    29.2.

    sgml декларация HTML 4.0

    29.3.

    sgml декларация

    29.4.

    Определение типа документа dtd (document type definition)

    30.

    Определение типа документа frameset

    31.

    Эталонные символьные объекты в HTML 4.0

    31.1.

    Введение

    31.2.

    Эталонные символьные объекты для символов ISO 8859-1

    32.

    Приложение А. (Отличия HTML 3.2 и HTML 4.0)

    33.

    Приложение b: Рабочие характеристики, приложения и заметки для разработчиков

    33.1.

    Замечания по поводу некорректных документов

    34.

    Специальные символы в значениях атрибута uri

    34.1.

    Не-ascii символы в значениях атрибута uri

    34.2.

    Символ & в значениях атрибута uri

    35.

    Замечания об использовании sgml

    36.

    Спецификация не HTML данных

    37.

    Особенности sgml с ограниченной поддержкой

    38.

    Булевы атрибуты

    39.

    Помеченные секции

    40.

    Заметки по индексному поиску

    40.1.

    Определение языка документа

    41.

    Поисковые роботы

    41.1.

    Роботы и элементы meta

    42.

    Замечания о таблицах

    43.

    Динамическое реформатирование

    44.

    Инкрементное отображение

    45.

    Структура и презентация

    46.

    Группы строк и колонок

    47.

    Доступность

    48.

    Рекомендуемые алгоритмы верстки

    49.

    Фиксированные алгоритмы верстки

    50.

    Алгоритм авто выкладки

    51.

    Замечания о формах

    52.

    Будущие проекты

    53.

    Заметки о скриптах

    53.1.

    Зарезервированный синтаксис для будущих скриптов

    54.

    Замечания о доступности

    55.

    Замечания о безопасности

    55.1.

    Соображения безопасности для форм

    56.

    Ссылки на литературу и серверы

    Язык программирования HTML (Hypertext Markup Language) предназначен для создания гипертекстных документов, формат которых не зависит от ЭВМ или используемой ОС. HTML-документы являются SGML-документами (Standard Generalized Markup Language, [ISO 8879]) с семантикой, пригодной для представления информации от широкого круга доменов. Файлы HTML-документов должны иметь расширение .html или .html. Данный формат пригоден для представления почтовых сообщений, новостей, меню, опций, гипермедийных документов, результатов запросов к базам данных, графических документов и т.д.

    HTML используется во всемирной информационной системе World Wide Web (WWW) с 1990 года (разработчик Tim Berners-Lee).

    В настоящее время существует также простой диалект языка SGML - XML (Extensible Markup Language). Смотри http://win.www.citycat.ru/doc/html/xml/wd-xml-lang или www.w3.org/put/www/tr (первоисточник). Предполагается, что этот язык совместим с SGML и HTML (последнее справедливо лишь частично).

    Любое приложение SGML состоит из нескольких частей:

    • SGML-декларация определяет, какие символы и разделители могут быть использованы в приложении.
    • dtd (document type definition) определяет стандарт на типы документов и задает синтаксис базовых конструкций.
    • Спецификация семантики, которая может также включать определенные ограничения на синтаксис, не включенные в DTD и т.д. .

    SGML - это система описания языков разметки (markup). HTML - пример такого языка. Каждый язык разметки, определенный в SGML, называется приложением SGML. HTML 4.0 является приложением SGML, соответствующим международному стандарту international standard ISO 8879:1986 -- Standard Generalized Markup Language SGML (определено в [ISO8879]).

    Приложение SGML характеризуется:

    1. Декларацией SGML. SGML-декларация специфицирует, какие символы и разграничители могут использоваться в приложении.
    2. Описанием типа документа DTD (Document Type Definition). DTD определяет синтаксис конструкций разметки. DTD может включать в себя дополнительные определения, такие как эталонные символьные объекты (entity).
    3. Спецификацией, которая описывает семантику разметки. Эта спецификация также определяет синтаксические ограничения, которые не могут быть выражены в рамках DTD.
    4. Примерами документов, содержащих данные и разметку. Каждый пример содержит ссылку на DTD, которая используется для его интерпретации.

    HTML предоставляет разработчику следующие возможности:

    • Публиковать в реальном масштабе времени документы с заголовками, текстом, таблицами, рисунками, фотографиями и т.д.
    • Одним нажатием клавиши мышки извлекать документы через гипертекстные связи.
    • Конструировать формы (бланки) для осуществления удаленных операций, для заказа продуктов, резервирования билетов или поиска информации.
    • Включать электронные таблицы (напр. Excel), видеоклипы, звуковые клипы и другие приложения непосредственно в документ.

    1. Синтаксис HTML

    Символьные объекты (entity) представляют собой цифровые или символьные имена символов, которые могут быть включены в документ HTML. Эти объекты нужны в тех случаях, когда прямой их ввод по каким-либо причинам невозможен. Эти объекты начинаются с символа & и завершаются точкой с запятой (;).

    Элементы в SGML представляют собой структуры или описывают требуемое поведение. Элементы начинаются со стартовой метки (TAG), за которой следует содержание, и завершаются конечной меткой. Стартовая метка обычно записывается как <имя_элемента>, а конечная метка, как </имя_элемента>. Некоторые элементы могут не иметь содержания или конечной метки. "Пустые" элементы не имеют конечной метки. Имена элементов обычно записываются прописными буквами, но HTML использование прописных или строчных букв в именах элементов не регламентировано.

    Атрибуты. Элементы могут иметь определенные свойства, эти свойства характеризуются атрибутами, которым пользователь может присваивать некоторые значения. Пары атрибут/значение должны быть записаны до появления закрывающей угловой скобки (>) стартовой метки. Если используется несколько атрибутов/значений, они разделяются пробелами. Порядок их записи не играет роли. По умолчанию SGML требует, чтобы значения были помещены в двойные или одинарные кавычки. Для этих же целей могут использоваться символьные объекты &#34; или &quot; для двойной кавычки и &#39; для одинарной кавычки. Значения могут содержать помимо латинских букв и цифр символы (-) и (.). Имена атрибутов не чувствительны к тому, прописными или строчными буквами они напечатаны (как правило, их имена записываются в HTML строчными буквами).

    Агент пользователя HTML - любой прибор, который интерпретирует HTML документы. К агентам пользователей относятся визуальные броузеры (текстовые и графические), не визуальные броузеры (звуковые и Брейля), поисковые роботы и т.д.. Агент пользователя должен игнорировать любые не узнанные атрибуты.

    Пользователь - лицо, взаимодействующее с агентом пользователя, для того чтобы тем или иным способом ознакомиться с документом HTML.

    URI. Любой ресурс в WWW - HTML документ, изображение, видео-клип, программа и пр. имеют адрес, который может быть представлен в виде универсального идентификатора ресурса (URI).

    Комментарии в HTML имеют следующий синтаксис:

    <!-- Комментарий -->
    <!-- Если комментарий занимает более одной строки,
    то он записывается так -->

    dtd-комментарии выделяются двумя черточками (--) в начале и в конце текста.

    HTML DTD начинается с серии описаний каких-то объектов (entities). Описание объекта представляет собой макрос, который может быть развернут где-либо в DTD(в HTML не применим). Когда макрос вызывается (по имени), он разворачивается в строку.

    Описание объекта (entity) начинается с ключевого слова <!entity %, за которым следует имя объекта и помещенная в кавычки строка, которая разворачивается. Описание завершается символом >. Развертываемая строка может содержать другие имена объектов. Конкретные значения объекта начинаются с символа "%" и завершается опционно символом ";". Эти объекты будут также развернуты (если требуется рекурсивно). Например:

    <!entity %fontstyle "tt | i | b | big | small">
    <!entity %inline "#pcdata | %fontstyle; | %phrase; | %formctrl;">

    Большая часть HTML DTD состоит из описаний элементов и их атрибутов. Ключевое слово <!element> открывает описание элемента, а символ > - завершает. Между ними размещается имя элемента, две черточки после имени указывают на то, что стартовая и конечная метки являются обязательными. Одна черточка после имени элемента и последующая буква О указывают на то, что конечная метка может отсутствовать. Две буквы О означают допустимость отсутствия как стартовой, так и конечной метки. После имени может следовать содержимое элемента, которое называется моделью содержимого. Элементы без содержимого называются пустыми (empty). Пустые элементы описываются ключевым словом "empty". Например, <!element ccc - o empty>. ccc - имя элемента; - О говорит о допустимости отсутствия конечной метки. В сочетании с моделью empty это означает, что конечная метка должна отсутствовать.

    Модель содержимого описывает то, что может содержать элемент. Определения содержимого могут включать:

    • Имена допустимых и запрещенных элементов.
    • dtd-объекты.
    • Текст документа, отмеченный SGML-конструкцией "#pcdata". Текст может содержать цифровые и именные символьные объекты.

    Модель содержимого имеет следующий синтаксис.

    (.)

    специфицирует группу.

    А|b

    Допускается присутствие А и В в любом порядке.

    А,В

    А должно появиться раньше, чем В.

    a&b

    a и b должны появиться только один раз, но в любом порядке.

    А?

    А может появиться не более одного раза.

    А*

    А может появиться любое число раз, включая 0.

    А+

    А может появиться один или более раз.

    Ниже приведены примеры HTML DTD:

    <!element select - - (option+)>

    Элемент select должен содержать один или более элементов option.

    <!element dl - - (dt|dd)+>

    Элемент dl должен содержать один или более dt или dd элементов в любом порядке.

    <!element option - o (#pcdata) *>

    Элемент option может содержать только текст и символьные объекты.

    2. Описания атрибутов

    Описание атрибутов начинается с ключевого слова <!attlist>. Описание атрибута включает в себя:

    1. Имя атрибута.
    2. Тип значения атрибута или набор возможных значений.
    3. Значение атрибута может быть определено тремя способами. Когда значение атрибута по умолчанию задано неявно (ключевое слово "#implied"), оно должно быть задано агентом пользователя или наследуется из определения порождающего элемента. Возможны также ключевые слова "#required" (всегда необходимо) и "#fixed" - присвоено фиксированное значение.

    Рассмотрим описание элемента map с опционным атрибутом.

    <!attlist map name cdata #implied >, здесь тип допустимого значения задан DATA (тип данных SGML). CDATA - представляет собой текст, который может содержать символьный объекты.

    Описания атрибутов могут содержать объекты DTD. Например:

    <!attlist link %attrs;

    -- id, class, style, lang, dir, title -

    bref %url @implied

    -- url для подключенного ресурса -- >

    Объект %attrs разворачивается в:

    <!attrlist p

    id id #implied -- уникальный идентификатор для данного документа --

    class cdata #implied

    -- список значений классов --

    style cdata #implied

    -- информация о стиле --

    title cdata #implied

    -- рекомендуемые заголовки/расширения --

    lang name #implied

    -- [rfc1766] код идентификатор языка --

    dir (ltr|rtl) #implied

    -- direction for weak/neutral text --

    align (left|center|right|justified) #implied >

    Аналогично DTD определяет объект %URL как расширение в строку cdata.

    <!entity % URL "CDATA" -- термин URL означает атрибут, значение которого равно универсальному указателю ресурса URL (uniform resource locator), см. RFC-1808 и RFC-1738 -->

    2.1. Булевы атрибуты

    Некоторые атрибуты выполняют роль булевых переменных. Их появление в стартовой метке элемента предполагает, что значение атрибута равно "true" (истинно). Их отсутствие означает, что их значение равно "false" (ложно). В HTML допускается сжатая форма записи булевых атрибутов:

    <option selected> вместо
    <option selected="selected">.

    3. HTML и URL

    World Wide Web (WWW) представляет собой всемирную сеть информационных ресурсов. WWW базируется на трех механизмах, которые обеспечивают доступ к этим ресурсам:

    1. Однородная схема имен для описания положения ресурсов в сети WWW(например, URI).
    2. Протоколы доступа к именованным ресурсам через WWW-сеть (напр., HTTP).
    3. Гипертекст, который обеспечивает простую технику поиска и перемещения (навигации) в сетях WWW (например, HTML).
    Каждый ресурс, доступный в WWW (HTML-документ, видео-клип, программа или статическое изображение) имеет адрес, который кодируется с помощью универсального идентификатора ресурса universal resource identifier, или uri. URI состоит из трех частей:

    1. Схема имен механизмов доступа к ресурсам [см. RFC-2068; далее в тексте данного документа ссылки на публикации и сервера, представленные в конце выделены квадратными скобками [].].
    2. Имя машины, где размещается ресурс.
    3. Имя самого ресурса в виде прохода к нему (path).

    Примером URI может служить адрес, где размещено описание языка HTML v4.0:

    http://www.w3.org/tr/rec-html4/

    Этот URI можно воспринимать следующим образом: имеется документ, доступный через протокол HTTP (см. [RFC-2068]), этот документ находится на ЭВМ www.w3.org, проход к нему имеет вид /tr/rec-html4/.

    Замечание. Большинство читателей знакомо с термином URL (Universal Resource Locator; [RFC-1738]) URL представляет собой подмножество более общей системы имен URI.

    Следует помнить, что запись URL чувствительна к тому, строчные или прописные буквы используются при его написании (это не относится только к имени ЭВМ).

    Спецификация URL определяет положение документа в сети, но не позицию внутри документа. По этой причине введено понятие URL-фрагмента, который может указывать на определенную часть документа. URL-фрагмент завершается символом #, за которым следует идентификатор указателя (anchor). Примером такого URL-фрагмента может служить http://store.in.ru/semenov/intro.htm#intr_1, где int_1 - имя метки в тексте документа intro.htm.

    Для локальной адресации HTML-документов используется относительные URL, которые не имеют секций протокола и ЭВМ. Относительный URL может содержать компоненты относительного прохода к ресурсу (".." означает положение порождающего URL). Документ RFC-1808 определяет алгоритм работы с относительными URL. Относительный URL может быть частью полного URL. Полный URL можно определить следующим образом:

    • Если базовый URL завершается символом (/), то он получен путем добавления относительного URL. Например, если базовый URL http://nosite.com/dir1/dir2/, а относительный - gee.html, то полный URL будет выглядеть как http://nosite.com/dir1/dir2/gee.html.
    • Если базовый URL не завершается /, последнюю секцию базового URL следует рассматривать как ресурс.

    Для связи через электронную почту иногда используется специальная разновидность URL - mailto, которая имеет формат:

    mailto:e-mail_адрес.

    В HTML, URI используются для:

    Поскольку люди на Земле пока используют различные языки, в которых применяются совершенно не схожие наборы символов, необходимо как-то управлять процессом описания набора символов, используемого в данном документе. Для документов HTML используется универсальный набор символов UCS (Universal Character Set) [ISO10646; cм. также RFC-2070]. Этот набор эквивалентен Unicode 2.0 [unicode]. Агент пользователя может получить, послать или воспроизвести документ в любой кодировке. Это может быть набор ISO-8859-1 ("latin-1"), ISO-8859-5 (кирилица), shift_jis (японская кодировка) и так далее. Пользователь должен позаботиться, чтобы его документ в конечном итоге был приведен в соответствие с Unicode, тогда у него не будет более проблем с национальным шрифтовым набором.

    Для того чтобы облегчить представление полученного документа, можно проанализировать первые несколько байт документа и в процессе пересылки соответствующим образом задать параметр charset поля "content-type". Например:

    content-type: text/html; charset= euc-jp

    В качестве значения параметра charset может быть выбрано стандартное имя из документа [RFC-2045]. Но, к сожалению, отнюдь не все сервера присылают информацию об используемом символьном наборе даже в случае несовпадения с ISO-8859-1. Другим способом решить проблему является включение в заголовок документа соответствующего meta-элемента. Например:

    <meta http-equiv="content-type" content="text/html; charset=euc-jp">

    Здесь крайне важно, чтобы агент пользователя был способен правильно интерпретировать элемент meta-декларации. Если других указаний не распознано, считается, что использован набор ISO-8859-1.

    Значение типа атрибута "color" служит для описания цвета. Значение этого атрибута может быть шестнадцатеричным числом, перед которым записывается символ #, или одним из 16 имен цветов:

    black="#000000"

    white="#ffffff"

    silver="#c0c0c0

    gray="#808080"

    green="#008000"

    lime="#00ff00"

    olive="#808000"

    maroon="#800000"

    yellow="#ffff00"

    aqua="#00ffff"

    red="#ff0000"

    blue="#0000ff"

    purple="#800080"

    teal="#008080"

    fuchsia="#ff00ff"

    navy="#000080"

    Цвета могут заметно улучшить выразительность и читаемость документов, но следует иметь в виду, что использование стилевых листов более эффективно. Нужно также учитывать, что цвета отображаются на разных рабочих станциях по-разному.

    HTML-документ состоит из трех частей, строки с информацией о версии, секции заголовка и собственно содержания документа. В первой строке документа должна быть внесена конструкция doctype, описывающая использованную версию HTML. Например:

    <!doctype html public "-//w3c//dtd html 4.0 draft//en">

    Последние две буквы этой декларации характеризуют язык HTML dtd, в данном случае английский ("en"). Агент пользователя может игнорировать эту информацию. Слово draft говорит о том, что использована предварительная версия HTML 4.0. В случае работы с окончательной версией html 4.0 это слово должно быть заменено на strict. Часть документа, следующая после описания версии, должна быть оформлена в виде HTML-элемента. Таким образом, HTML-документ имеет следующую структуру:

    <!doctype html public -//w3c//dtd html 4.0 draft//en>
    <html>
    Заголовок, текст документа .
    </html>

    Рассмотрим возможные варианты HTML-элементов.

    <!entity % version "version cdata #fixed '%html.version;'">
    <!entity % html.content "head, (fragment|body) ">
    <!entity html o o (%html.content)>
    <!attlist html %version; %i18n; >

    Стартовая и конечная метки являются опционными.

    Ниже приведены примеры элементов-заголовков.

    <!entity % head.content "title & isindex? & base?">
    <!element head o o (%head.content) +(%head.misc)>
    <!attlist head %i18n; profile %url #implied - named directory of meta info -- >

    Для элемента title стартовая и конечная метки являются обязательными. Элемент head содержит информацию о документе, он не является частью текста и служит в качестве источника ключевых слов для поисковых систем. HTML-документ должен иметь только один элемент title в секции head.

    Не следует путать элемент title с атрибутом title, который предоставляет справочную информацию об элементе, для которого установлен. Атрибут title имеет формат: title=cdata. В отличие от элемента title, который характеризует весь документ в целом и может появиться в пределах документа только раз, атрибуту title позволено аннотировать любое число элементов. Агент пользователя может интерпретировать этот атрибут самым различным способом. Визуальные броузеры могут отобразить его текст в качестве совета, аудио агент может воспроизвести текст, говорящий о ресурсах подключенного сервера. Специфическую роль играет атрибут title при использовании для элемента link.

    В html 4.0 программист может использовать метаданные в своем документе следующим способом:

    1. Можно описать свойства метаданных во внешнем профайле. Профайл может определить свойства вспомогательной системы поиска (help), такой как "автор", "ключевые слова" и т.д..
    2. Программист может установить значения определенных параметров. Это можно сделать внутри документа с помощью meta-элемента. В этом случае профайл определяет имена свойств, которые могут быть заданы с помощью META-элемента. Установить конкретные значения можно и извне, связав метаданные с элементом link. В этом варианте профайл определяет имена соотношений типов, которые может использовать элемент LINK.

    Если профайл определен для элемента Head, тот же профайл будет присутствовать во всех элементах META и LINK в заголовке документа. Ниже приведены примеры записи элементов meta.

    <!element meta - o empty

    -- Базовая метаинформация -->

    <!attlist meta %i18n;

    -- lang, dir, для использования со строкой содержимого --

    http-equiv name #implied

    -- имя заголовка http-отклика --

    name name #implied

    -- Имя метаинформации --

    content cdata #required

    -- соответствующая информация --

    scheme sdata #implied

    -- select form of content -->

    Для META-элемента стартовая метка необходима, а конечная не нужна. Атрибуты, их значения и интерпретация зависят от профайла.

    name=Cdata Этот атрибут определяет имя свойства.
    content=Cdata определяет значение свойства.
    scheme=Cdata определяет схему интерпретации значения свойства.

    HTTP-equiv=cdata

    может использоваться вместо атрибута name. http-серверы используют этот атрибут при сборе информации для заголовков откликов.

    Например, <meta name="interpreter" content="yuri semenov">. Атрибут lang может использоваться с элементом meta для определения языка для значения атрибута content. Этот атрибут позволяет синтезаторам речи корректно выбрать правила произношения. Например:

    <meta name="interpreter" lang="ru" content="semenov">.

    Некоторые агенты пользователья используют meta для обновления текущей страницы каждые несколько секунд. При этом страница может обновляться полностью. Например:

    <meta name="refresh" content="3,http://www.acme.com/intro.html">

    Слово content определяет задержку в секундах, за этим числом следует URL, который должен быть загружен по истечении указанного времени. К сожалению не все агенты пользователя поддерживают такую возможность.

    Атрибут HTTP-equiv может использоваться вместо атрибута name. HTTP-серверы могут работать с именами свойств, заданными атрибутом HTTP-equiv, что позволяет им формировать заголовок HTTP-отклика согласно требованиям RFC-822. Декларация <meta http-equiv="expires" content="Mon, 17 Aug 1998 16:35:08 GMT"> приведет к формированию следующей строки в HTTP-заголовке: expires: Mon, 17 Aug 1998 16:35:08 GMT. Это позволяет определить время доступности свежей копии документа.

    Одним из важных функция элемента meta является описание ключевых слов для поисковых систем. Например:

    <meta name="keywords" content="information, retrieval, indexing">

    4. Элементы, используемые в тексте документа

    <!entity % block "(%blocklevel | %inline)*">
    <!entity % color "cdata" - a color using srgb: #rrggbb as hex values -->
    <!entity % bodycolors "bgcolor %color #implied
    text %color #implied
    link %color #implied
    vlink %color #implied
    alink %color #implied">

    <!element body o o (%block) -(body) +(ins|del)>
    <!attlist body
      %attrs; -- %coreattrs, %i18n, %events -
      background %url #implied -- раскладка текстуры для фона документа --
      %bodycolors; -- bgcolor, text, link, vlink, alink -
      onload %script #implied -- документ загружен --
      onunload $script #implied -- документ удален -->

    Для этого элемента стартовая и конечная метки являются опционными. Здесь применимы следующие атрибуты.

    Background=URL

    указывает на место, где лежит изображение мозаичного образа для фона документа.

    text=color

    устанавливает фоновый цвет для текста.

    Link=color

    определяет цвет не посещенных гипертекстных объектов.

    vlink=color

    определяет цвет посещенных гипертекстных объектов.

    alink=color

    определяет цвет выбранного пользователем объекта.

    Помимо перечисленных ряд атрибутов могут задаваться извне:

    id, class, (идентификаторы действуют для всего документа) lang (языковая информация), dir (направление текста/отступ), title, style (текущая стилевая информация), bgcolor (цвет фона), onload, onunload, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (действительные события).

    Презентация документа определяется стилем (использование атрибутов презентации не желательно). Атрибуты презентации могут применяться только для агентов пользователя, не поддерживающих стили. Ниже представлена иллюстрация представления документа, где фон имеет белый цвет, текст черный, гиперсвязи в исходный момент красные, темные при активации и темно бордовые после первого визита.

    <html>
    <head>
    <title> a study of population dynamics </title>
    </head>
    <body bgcolor="white" text="black" link="red" alink="fuschia" vlink="maroon">
    . текст документа .
    </body>
    </html>

    То же самое с использованием стилевого листа.

    <html>
    <head>
    <title> a study of population dynamics </title>
    <style type="text/css">
    body { background: white color: black}
    a:link { color: red }
    a:visited { color: fuschia }
    </style>
    </head>
    <body>
    .текст документа .
    </body>
    </html>

    Использование связанного стилевого листа добавляет гибкости при реализации презентации.

    <html>
    <head>
    <title> a study of population dynamics </title>
    <link rel="stylesheet" type="text/css" href="smartstyle.css">
    </head>
    <body>
    .текст документа.
    </body>
    </html>

    5. Идентификаторы элементов. ID и атрибуты классов.

    Определения атрибутов

    ID = name

    Этот атрибут присваивает имя элементу, которое действительно в пределах данного документа. Значение ID должно быть уникальным для данного документа.

    class = cdata-list

    Этот атрибут присваивает некоторому элементу значение класса или набора классов. Одно и тоже имя класса может быть присвоено любому числу элементов. Значение класса позволяет определить или уточнить функцию данного элемента или группы элементов.

    Эти атрибуты могут использоваться в следующих случаях:

    1. Атрибут id может использоваться в качестве адреса места назначения гипертекстной связи.
    2. Атрибут id может использоваться скриптами для ссылки на какой-то конкретный элемент.
    3. Стилевые листы могут использовать атрибут ID для того, чтобы определить элемент, на который распространяется действие данного стиля.
    4. Атрибут ID может использоваться для идентификации деклараций object.
    5. Стилевые листы могут использовать атрибут class для идентификации списка элементов, на которые распространяется действие данного стиля.
    6. Атрибуты id и class могут использоваться для целей обработки, например, для идентификации полей при извлечении информации с HTML-страниц в базу данных, при трансляции HTML-документов в другие форматы.

    Предположим, что пишется документ о языке программирования. Документ включает в себя некоторое число отформатированных примеров. В этом случае для форматирования используется элемент pre. Пусть также задан цвет фона = green для всех случаев, когда элемент pre принадлежит классу "example".

    <head>
    <style pre.example { background : green } </style>
    </head>
    <body>
    <pre class = "example" id = "example-1">
    . текст программы примера .
    </pre>
    </body>

    5.1. Элемент html

    <!entity % html.content "head, body">
    <!element html o o (%html.content;) -- корневой элемент документа -->
    <!attlist html %i18n; -- lang, dir -- >

    Определение атрибута

    version = cdata [cn]

    Применять не рекомендуется. Значение атрибута специфицирует то, какая версия HTML DTD используется в данном документе. Этот атрибут не рекомендован из-за того, что в качестве стандарта принято определение версии в декларации типа документа.

    После декларации типа документа оставшаяся часть документа содержит элемент HTML. Таким образом, HTML-документ имеет структуру:

    <!doctype html public "-//w3c//dtd html 4.0//en"
    "http://www.w3.org/tr/rec-html40/strict.dtd">
    <html>
    ...Заголовок, тело, и т.д. следует здесь...
    </html>

    5.2. Группирующие элементы div и span

    <!element div - - %block>

    <!attlist div %attrs;

    -- %coreattrs, %i18n, %events --

    %align;

    -- align, выравнивание текста -- >

    <!element span - - (%inline) *

    -- базовый языковый/стилевой контейнер -- >

    <!element span %attrs;

    -- %coreattrs, %i18n, %events -- >

    Атрибуты определенные где-то еще

    • id, class (идентификаторы, действующие в пределах документа)
    • lang (языковая информация), dir (направление текста/отступ)
    • title (заголовок элемента)
    • style (текущая стилевая информация)
    • align (выравнивание)
    • onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (события)

    Элементы div и span в сочетании с атрибутами id и class предлагают обобщенный механизм структурирования документа. Таким образом, сформировав примеры и классы и используя для них стилевые листы, программист может придать HTML-документу необходимую структуру и форму.

    Предположим нужно сформировать документ на основе базы данных клиента. Так как HTML не имеет элементов, идентифицирующих такие объекты как "клиент", "телефонный номер" и т.д., для решения стоящей задачи воспользуемся элементами div и span.

    В приведенном примере каждое имя клиента принадлежит классу client-last-name. Присвоим также уникальные идентификаторы каждому клиенту (client-stepanov, client-ivanov).

    <div id="client-stepanov" class="client">
    <span class="client-last-name">last name:</span> stepanov,
    <span class="client-first-name">first name:</span> stepa
    <span class="client-tel">telephone:</span> (095) 123-9442
    <span class="client-email">email:</span> s.s@itep.ru">s.s@itep.ru
    </div>

    <div id="client-ivanov" class="client">
    <span class="client-last-name">last name:</span> ivanov,
    <span class="client-first-name">first name:</span> vanja
    <span class="client-tel">telephone:</span> (095) 123-5442
    <span class="client-email">email:</span> s.s@itep.ru">v.i@itep.ru
    </div>

    Позднее может быть легко добавлена стилевая информация для тонкой настройки представления записей этой базы данных.

    span является строчным элементом и его зона ответственности - параграф. span не может быть использован для группирования элементов блочного уровня. div, напротив, предназначен для работы с блочными элементами. div элемент, за которым следует незакрытый p-элемент, завершает параграф. Агент пользователя помещает разрыв строки до и после div-элемента, например строка:

    <p>aaaaaa<div>bbbbbb</div><div>ccccc<p>ccccc</div>
    обычно развертывается в:
    aaaaaa
    bbbbbb
    ccccc

    ccccc

    Агент пользователя развернет ее как:
    aaaaaabbbbbbccccc
    ccccc

    5.3. Элементы заголовков h1, h2, h3, h4, h5, h6

    <!entity % heading "h1, h2, h3, h4, h5, h6">
    <!-- Существует шесть уровней заголовков, начиная с Н1 (наиважнейший), кончая Н6 -- >
    <!element (%heading) - - (%inline;)*>

    <!attlist (%heading) %attrs;

    -- %coreattrs, %i18n, %events --

    %align;

    -- align, выравнивание текста -- >

    Элементы заголовка кратко описывают тему раздела, который они открывают. Содержимое заголовка может использоваться агентом пользователя, например, для автоматического формирования оглавления документа.

    Визуальные броузеры отображают заголовки более высокого уровня буквами более крупного кегля. Ниже приведен пример использования div-элемента для установления связи заголовка со следующей за ним секцией документа. Это позволяет определить стиль раздела с помощью стилевых листов.

    <div class="section" id="forest-elephants" >
    <h1>forest elephants </h1>

    В этом разделе обсуждаются менее известные лесные слоны.

    . далее следует продолжение текста .
    <div class="subsection" id="forest-habitant" >
    <h2> habitant </h2>
    Лесные слоны живут не на деревьях (:-))
    . далее следует рассказ о том, где и как живут лесные слоны .
    </div>
    </div>

    Структура может быть улучшена с помощью стилевой информации, например:

    <head>
    <style>
    div.section { text-align: justify; font-size: 12pt }
    div.subsection { text-ident: 2em }
    h1 {font-style: italic; color: green }
    h2 { color: green }
    </style>
    </head>

    5.4. Элементы address

    <!element address - - ((%inline;) | p) *>

    <!attlist address %attrs;

    -- %coreattrs, %i18n, %events -- >

    Элемент address служит для введения контактного адреса с автором документа, например:

    <address>
    newsletter editor<br>
    j. r. brown<br>
    8723 buena vista, smallville, ct 01234<br>
    tel: +1 (123) 456 7890
    </address>

    6. Спецификация языка содержимого документа. Атрибут lang

    lang = language-code

    Специфицирует базовый язык, на котором написан документ. Значением этого атрибута является код языка (см. RFC-1766). В пределах кода языка пробелы использоваться не должны. Значение этого кода по умолчанию "unknown". Код языка состоит из базового кода и субкода.

    language-code = primary-code *( "-" subcode )

    Атрибуты, определенные где-либо еще.

    • id, class (идентификаторы, действующие в пределах документа)
    • lang (языковая информация), dir (направление текста/отступ)
    • onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (события)

    Ниже приведено несколько примеров кодов языка.

    "en":english
    "en-us":the u.s version of english

    "en-cockney":the cockney version of english

    (версия английского - кокни)

    "i-cherokee":the cherokee language spoken by some native americans

    (Чероки - язык, на котором говорят некоторые коренные американцы)

    Две первые буквы базового кода зарезервированы ISO-639.

    fr

    французский

    de

    немецкий

    it

    итальянский

    nl

    голландский

    el

    греческий

    es

    испанский

    pt

    португальский

    ar

    арабский

    he

    еврейский

    ru

    русский

    zh

    китайский

    ja

    японский

    hi

    хинди

    ur

    урду

    Любые две буквы субкода воспринимаются как код страны ISO3166.

    7. Наследование языковых кодов

    Элемент наследует информацию языкового кода согласно следующим приоритетам (сверху вниз):

    • Атрибут lang устанавливает значение элемента.
    • Глобальный элемент, имеющий атрибут lang.
    • http заголовок "content-language", устанавливающий значения языка, например,
      content-language: en-us.
    • Задание языкового атрибута извне.

    В ниже приведенном примере базовый язык документа является французским. Один параграф декларирован как испанский, после чего базовый язык восстанавливается. Следующий параграф включает встроенную фразу на японском, после чего следует снова текст на французском.

    <html lang="fr">
    <body>
    . текст интерпретируется как французский .
    <p lang="es">. текст интерпретируется как испанский .
    <p>. текст интерпретируется снова как французский .
    <p> . французский текст интерпретируется с помощью <em lang="ja"> немного японского </em> далее следует снова текст на французском .
    </body>
    </html>

    8. Спецификация направления текста. Атрибут dir

    Описание атрибута

    dir = ltr | rtl

    Специфицирует направление размещения текста, возможные значения:

    ltr: слева направо
    rtl: справа налево.

    Последнее значение атрибута может быть нужно для случая арабского или еврейского текстов. Агент пользователя не может использовать атрибут lang для определения направления текста.

    9. Текст

    Пробел

    Спецификация SGML делает различие между начальным символом (перевод строки) и концом записи (возврат каретки). Но существует большое разнообразие использования этих символов в различных системах и агент пользователя должен быть способен корректно обрабатывать все варианты. Аналогично меняется от скрипта к скрипту представление о том, что такое разделитель слов. В латинских текстах это пробел (десятичный код 32), в японском и китайском пробел игнорируется, а в тайском используется нуль-сепаратор. Что же касается самого HTML, здесь функции сепаратора выполняет код пробела. Набор символов документа включает в себя широкое разнообразие символов пробела. Многие из них являются типографскими элементами, которые служат для формирования зазоров между словами или буквами. В HTML, определены только следующие символы пробела:

    • ascii пробел (&#x0020;)
    • ascii tab (&#x0009;)
    • ascii form feed (&#x000c;)
    • пробел нулевой ширины (&#x200b;)

    Разрыв строки также является пробелом. Заметьте, что &#x2028; и &#x2029; определенные в [ISO10646] для разделения строк и параграфов, соответственно, не являются разрывами строк в HTML.

    Пример текста:

    <p>
    this example shows a paragraph and a list
    </p>
    <ul>

    <li>

    the <em>первый</em> item
    </li>

    <li>

    this is the <em>второй</em> item
    </li>
    </ul>

    текст может быть переписан с пропуском конечных меток и размещен иначе с использованием меньшего числа пробелов.

    <p>this example shows a paragraph and a list
    <ul>

    <li> this is <em>первый</em> item

    <li> this is <em>второй</em> item

    </ul>

    Элемент pre используется для уже сформатированных фрагментов текста, где важны пробелы.

    9.1. Структурированный текст

    Элементы фраз: em, strong, dfn, code, samp, kbd, var, cite, acronym
    <!entity % phrase "em | strong | dfn | code | samp | kbd | var | citr | acronym">
    <!element (%font|%phrase) - - (%inline) *>

    <!attlist (%font|%phrase)

    -- %coreattrs, %i18n, %events -- >

    Элементы фраз добавляют структурную информацию к текстовым фрагментам. Элементы фраз имеют следующие значения:

    em:

    Подчеркивают значение.

    strong:

    Указывает на еще большую важность (придает выразительность)

    dfn:

    Указывает, что это место определения вложенного термина.

    code:

    Отмечает фрагмент текста программы.

    samp:

    Выделяет пример из текста программы или скрипта.

    kbd:

    Отмечает текст, который должен быть введен пользователем.

    var:

    Отмечает переменную или аргумент программы

    cite:

    Ссылается на фрагмент текста или другой источник.

    acronym:

    Отмечает акроним (напр. HTML, URI, WWW и т.д.).

    EM и strong весьма привлекательны для подчеркивания важности фрагмента текста. Приведенный ниже пример позволяет проиллюстрировать использование некоторых элементов фраз.

    "More information can be found in <cite>[ISO-0000]</cite>
    "Please refer to the following reference number in future correspondence:
    <strong>1-234-55</strong>"

    Элемент acronym позволяет упростить работу программ проверки правописания и звуковых синтезаторов речи. Текст элемента acronym позволяет описать сам акроним:

    <acronym title="world wide web">www</acronym>
    <acronym lang="fr" title ="soci&eacute;t&eacute; nationale de chemins de fer"> sncf
    </acronym>

    Представление элементов фраз зависит от агента пользователя. Визуальные броузеры отмечают фрагменты текста EM курсивом, а фрагменты strong - полужирным шрифтом. HTML не выделяет аббревиатур и акронимов, по этой причине в текстах, ориентированных на звуковое воспроизведение, следует позаботиться о создании специальных словарей, подключенных к тексту с помощью элементов link в заголовке документа.

    9.2. Цитирование. Элементы q и blockquote

    <!element blockquote - - %block>

    <!attlist blockquote %attrs;

    -- %coreattrs, %i18n, %events --

    cite %url #implied

    -- url исходного документа или сообщения -- >

    <!element q - - (%inline) *>

    <!attlist q %attrs;

    -- %coreattrs, %i18n, %events --

    cite %url #implied

    -- url исходного документа или сообщения -- >

    Определения атрибутов

    cite=url

    Значение этого атрибута равно url, который указывает на первоисточник или сообщение. Аргумент указывает на источник цитаты, заключенной в кавычки. Элемент q служит для использования с короткими цитатами в пределах абзаца, а blockquote предназначен для более длинных. Например:

    <blockquote cite=http://www.mycom.com/tolkien/twotpwers.html>
    they went in single file, running like hounds on a strong scent, and an eager light was in their eyes.
    </blockquote>

    9.3. Верхние и нижние индексы. Элементы sub и sup

    <!element (sub|sup) - - (%inline) *>

    <!attlist (sub|sup) %attrs;

    -- %coreattrs, %i18n, %events -->

    Например, французское "mlle dupont" можно представить в HTML как:

    m<sup>lle</sup> dupont

    9.4. Строки и параграфы

    Любой текст обычно представляется в виде последовательности параграфов. Для определения границ параграфа в HTML используется элемент p. Текст параграфа будет использоваться как единое целое при ряде процедур.

    9.4.1. Параграфы и элемент p

    <! element p - o (%inline) *>

    <!attlist p %attrs;

    -- %coreattrs, %i18n, %events

    %align;

    -- выравнивание текста -- >

    P-элемент отмечает границы параграфа и не может содержать элементов блочного уровня, включая другие Р-элементы. Конечная метка может быть опущена, при этом любой элемент блочного уровня будет являться начальной меткой и конечной меткой Р-элемента. Например:

    <p>Это первый параграф.</p>
    <p>Это второй </p>
    . блочный элемент .

    Этот же текст можно переписать эквивалентным образом:

    <p>Это первый параграф.
    <p>Это второй.
    .блочный элемент .

    Аналогично параграф может быть сформирован с помощью блочных элементов:

    <div>
    <p> Это параграф
    </div>

    Пустой параграф является дурным стилем и должен игнорироваться агентом пользователя. Агент пользователя определяет способ отображения параграфа. Параграфы могут иметь абзацы, а могут отделяться друг от друга пустой строкой. Обычно в процессе отображения строки разрываются по пробелам между словами, но можно ввести принудительные разрывы строк с помощью элемента BR.

    9.5. Элемент br

    <!element br - o empty

    -- вызывает разрыв строки -- >

    <!attlist br %coreattrs;

    -- id, class, style, title --

    clear (left|all|right|none) none

    -- управление отображением текста -- >

    Для визуального агента пользователя атрибут clear может использоваться для позиционирования плавающих объектов (напр. обтекание текстом изображений). Этот атрибут используется в случае отсутствия стилей.

    Помимо принудительного разрыва строки существует элемент, запрещающий разрыв строки между двумя словами. Например &nbsp; entity (&#160;, &#xa0;) действует как пробел, где агент пользователя не должен разрывать строку.

    В HTML существует два вида дефисов: мягкий и твердый. Твердый рассматривается как обычный символ, а мягкий воспринимается агентом пользователя как место, где можно разорвать строку. Твердый дефис обозначается символом "-" (&#45;,&#x2d;), а мягкий - именованным символом &shy; (&#173;,&#xad;).

    9.6. Предварительно сформатированный текст. Элемент pre.

    <!entity % pre.exclusion "img|big|small|sub|sup|font">
    <!element pre - - (%inline) * - (%pre.exclusion)>

    <!attlist pre %attrs;

    -- %coreattrs, %i18n, %events --

    width number #implied >

    Определения атрибутов

    width = integer

    Этот атрибут дает информацию агенту пользователя о желательной ширине форматируемого блока. Агент пользователя может использовать эту информацию для выбора шрифта или отступа. Желательная ширина выражается в числе символов.

    Элемент pre сообщает визуальному агенту пользователя, что данный фрагмент текста уже сформатирован. Агент пользователя при этом должен сохранить все пробелы, использовать шрифт с фиксированной шириной букв, блокировать автоматический перенос и разрыв строк. Перед и после такого фрагмента обычно вводятся пустые строки (требование SGML). В DTD-фрагменте, приведенном выше, в первой строке содержится список элементов, которые не должны присутствовать в PRE-декларации. Рассмотрим фрагмент из поэмы Шелли "to a skylark".

    <pre>

    higher still and higher

    from the earth thou springest

    like a cloud of fire;

    the blue deep thou wingest,

    and singing still dost soar, and soaring ever singest.
    </pre>

    Этот стих будет представлен агентом пользователя без изменений формата.

    Не рекомендуется использовать горизонтальную табуляцию в предварительно отформатированных текстах, агент пользователя не сможет воспроизвести формат фрагмента без искажений.

    10. Пометка изменений документа. Элементы ins и del.

    <!element (ins|del) - - (%inline) *

    -- (введенный/удаленный текст) -- >

    <!attlist (ins|del) %attrs;

    -- %coreattrs, %i18n, %events --

    cite %url #implied

    -- информация о причине изменения --

    datetime cdata #implied

    -- дата изменения в формате ISO -- >

    Определение атрибутов

    cite = URL

    Значение этого атрибута равно URL, которое указывает на документ-первоисточник. Атрибут служит для пояснения причины изменения документа.

    datetime = cdata

    Значение этого атрибута определяет дату и время внесения изменения в документ. Формат этого значения должен соответствовать требованиям документа ISO-8601.

    Элементы ins и del используются для выделения фрагментов документа, которые были добавлены или удалены из предшествующей версии документа.

    11. Формат даты и времени

    ISO-8601 допускает много опций и вариаций в представлении дат и времени. Но основным форматом HTML следует считать следующий:

    yyyy-mm-ddthh:mm:sstzd

    Где

    yyyy

    = четыре цифры года

     

    mm

    = две цифры месяца (01 - январь)

     

    dd

    = две цифры дня месяца (01-31)

     

    hh

    = две цифры часа (00-23; am/pm запрещены)

     

    mm

    = две цифры минут (00-59)

     

    ss

    = две цифры секунд (00-59)

     

    tzd

    = идентификатор временной зоны

    В качестве tzd (код временной зоны) можно использовать следующие:

    z

    обозначает utc (coordinated universal time)

    +hh:mm

    указывает местное время в часах и минутах опережающее utc.

    -hh:mm

    указывает местное время в часах и минутах отстающее от utc.

    Символ t указывает на начало строки символов времени.

    12. Неупорядоченные (ul) и упорядоченные (ol) списки

    <!entity % ulstyle "disc|square|circle">
    <!element ul - - (li) +>

    <!attlist ul

    -- неупорядоченный список --

    %attrs;

    -- %coreattrs, %i18n, %events --

    type (%ulstyle) #implied

    -- список, где элементы отмечены жирной точкой в начале строки --

    compact (compact) #implied

    -- уменьшенное расстояние между элементами списка -- >

    <!entity % olstyle "cdata"

    -- определяет стиль нумерации: [1|a|a|i|i] -- >

    <!element ol - - (li) +>

    <!attlist ol

    -- упорядоченный список --

    %attrs;

    -- %coreattrs, %i18n, %events --

    type (%olstyle) #implied

    -- нумерованный список --

    compact (compact) #implied

    -- уменьшенное расстояние между элементами списка --

    start number #implied

    -- начальный номер элемента списка -- >

    <!entity % listyle "cdata"

    -- ограничение: "(%ulstyle|%olstyle)" -- >

    <!element li - o %block

    -- элемент списка -- >

    <!attlist li %attrs;

    -- %coreattrs, %i18n, %events --

    type %listyle) #implied

    -- стиль элемента списка --

    value number #implied

    -- сброс счетчика элементов списка -- >

    Определение атрибутов

    type = style-information

    Этот атрибут определяет стиль элемента списка.

    start = integer

    Работает только для ol. Устанавливает начальное значение счетчика элементов упорядоченного списка, значение по умолчанию равно единице.

    value = integer

    Работает только для LI. Устанавливает текущее значение номера элемента списка.

    compact

    Не рекомендуется использовать. При использовании требует от агента пользователя отображать список в возможно более компактном виде.

    Упорядоченные и не упорядоченные списки во многом схожи. Оба типа представляют собой последовательность элементов, описанных элементом LI (конечная метка этого элемента обычно опускается). Ниже приведены примеры списков.

    <ul>

    <li> . первый элемент списка .

    <li> . второй элемент списка .

    .....

    </ul>

    Списки могут быть вложенными.

    <ul>

    <li> .Уровень 1, номер 1 .

    <ol>

    <li> . Уровень 2, номер 1 .

    <li> . Уровень 2, номер 2 .

    <ol start="10">

    <li> . Уровень 3, номер 1 .

    </ol>

    <li> . Уровень 2, номер 3 .

    </ol>

    <li> .Уровень 1, номер 2 .

    </ul>

    В упорядоченных списках невозможно продолжать нумерацию с предыдущего списка или убрать нумерацию, но можно установить счетчик принудительно с помощью атрибута value. Например:

    <ol>
    <li value="30"> присваивает этому элементу списка номер 30.
    <li value="40"> присваивает этому элементу списка номер 40.
    <li> этот элемент списка будет иметь номер 41.
    </ol>

    12.1. Списки, форматируемые визуальным агентом пользователя

    Для OL и UL атрибут type определяет опцию отображения визуальным агентом пользователя. Для элемента UL возможны значения атрибута type: disc, square и circle. Значение по умолчанию зависит от уровня вложения текущего списка. Агент пользователя попытается представить "disc" в виде небольшого заполненного кружочка, "circle" - в виде незаполненного кружочка, а "square" - в виде квадратика.

    Для элемента ol возможные значения атрибута type представлены в таблице.

    Тип

    Стиль нумерации

    1

    Арабские цифры

    1,2,3,.

    a

    Строчные буквы латинского алфавита

    a,b,c,.

    a

    Прописные буквы латинского алфавита

    a,b,c, .

    i

    Малые римские цифры

    i, ii, iii, .

    i

    Большие римские цифры

    i, ii, iii, .

    12.2. Списки определений. Элементы dl, dt и dd

    <!element dl - - (dt|dd)+>

    <!attlist dl %attrs

    -- %coreattrs, %i18n, %events --

    compact (compact) #implied

    -- уменьшенное расстояние между элементами -- >

    <!element dt - o (%inline) *>
    <!element dd - o %block>

    <!attlist (dt|dd) %attrs

    -- %coreattrs, %i18n, %events -- >

    Список определений отличается слабо от других списков, он состоит из двух частей: начальная этикетка (label) и описание. Этикетка инициируется элементом DT и может содержать только помеченный текст. Описание начинается с элемента DD и может содержать данные блочного уровня. Например:

    <dl>

    <dt> <em> daniel</em>

    <dd> born in france, daniel's favorite food is foie gras.

    <p> in this paragraph we'll discuss daniel's girlfriends: audrey, laurie and alice.

    <dt> <em> tim</em>

    <dd> born in new york, tim's favorite food is ice cream.

    </dl>

    Представление списка определений зависит от агента пользователя. Агент пользователя может отобразить представленный список в виде:

    daniel
    born in france, daniel's favorite food is foie gras.
    in this paragraph we'll discuss daniel's girlfriends: audrey, laurie and alice.
    tim
    born in new york, tim's favorite food is ice cream.

    13. dir и элементы menu

    <!element (dir|menu) - - (li)+ - (%blocklevel)>

    <!attlist dir %attrs;

    -- %coreattrs, %i18n, %events --

    compact (compact) #implied >

    <!attlist menu %attrs;

    -- %coreattrs, %i18n, %events --

    compact (compact) #implied >

    Элемент DIR предназначен для формирования многоколоночного текста каталога. Элемент Menu предназначен для работы с одноколонными текстами каталогов. Оба элемента имеют структуру, аналогичную UL. Рекомендуется использовать UL вместо DIR и Menu.

    14. Таблицы

    Модель таблиц в HTML позволяет пользователям создавать достаточно сложные структуры таблиц. В этой модели ряды и колонки можно объединять в группы. При печати больших таблиц заголовки и нижние комментарии могут дублироваться для каждой части.

    14.1. Структура таблиц

    В HTML таблицы имеют следующую структуру

    • Допускается одна или более групп строк. Каждая группа состоит из опционной секции заголовка таблицы и опционной нижней секции.
    • Допускается одна или более групп колонок.
    • Каждая строка состоит из одной или более ячеек.
    • Каждая ячейка может содержать заголовок или информацию и занимать более одной строки и более одной колонки.

    14.1.1. Элемент table

    <!element table - - (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
    <!attlist table -- элемент таблицы -

    %attrs;

    -- %coreattrs, %i18n, %events --

    align %talign; #implied

    -- положение таблицы относительно окна --

    bgcolor %color #implied

    -- фоновый цвет ячейки --

    width cdata #implied

    -- ширина таблицы относительно окна --

    cols number #implied

    -- используется для режима немедленного отображения --

    borrder cdata #implied

    -- управляет шириной рамки вокруг таблицы --

    frame %tframe; #implied

    -- какую часть таблицы заключить в рамку --

    rules %trules #implied

    -- линии между рядами и колонками --

    cellspacing cdata #implied

    -- зазоры между ячейками --

    cellpadding cdata #iplied

    -- отступы внутри ячеек -- >

    Определение атрибутов

    align = left | center | right

    Этот атрибут определяет положение таблицы в документе. Возможные значения:

    • left: Таблица сдвинута к левому краю документа.
    • center: Таблица размещена по центральной оси документа.
    • right: Таблица сдвинута к правому краю документа.

    width = length

    Этот атрибут определяет желательную ширину всей таблицы для агента пользователя. В отсутствии этого атрибута размер таблицы определяется агентом пользователя.

    cols = integer

    Этот атрибут задает число колонок в таблице. Если он задан, агент пользователя разворачивает таблицу по мере получения данных.

    14.2. Вычисление числа рядов и колонок в таблице

    Число рядов в таблице равно числу tr-элементов в ее содержимом. Агенты пользователя должны игнорировать ряды с номерами за пределами этого числа. Существует несколько путей определения числа колонок.

    • Сканирование рядов таблицы и определение максимального числа колонок. Если число колонок в таблице превосходит число ячеек, ряд дополняется пустыми ячейками.
    • Подсчитывается число колонок, как это специфицировано элементами COL и colgroup.
    • Используется атрибут COLS элемента table

    Агент пользователя может предположить, что число колонок в примере, приведенном ниже равно трем.

    <table cols= "3">
    . текст таблицы .
    </table>

    Если число колонок в таблице не задано атрибутом COLS, то визуальный агент пользователя будет ждать прихода всей информации о таблице, прежде чем приступит к ее отображению. Таким образом, атрибут cols позволяет отображать таблицу ряд за рядом по мере поступления данных.

    14.3. Ориентация таблиц

    Ориентация таблиц определяется атрибутом dir элемента table. Для таблиц, ориентированных слева направо (ориентация по умолчанию), первая колонка расположена слева, а первый ряд сверху. Возможна ориентация таблицы справа налево. Для того чтобы специфицировать таблицу с нумерацией колонок справа налево нужно установить значение атрибута dir.

    <table dir="rtl">
    . содержимое таблицы .
    </table>

    14.4. Надписи и таблица. Элемент caption

    <!element caption - - (%inline;) +>
    <!entity % calign "(top|bottom|left|right)">

    <!attlist caption

    -- Надпись для таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    align %CAlign; #implied

    -- относительно таблицы -- >

    Определение атрибута

    align = top|bottom|left|right

    Этот атрибут определяет положение подписи по отношению к таблице. Возможные значения:

    • top: подпись над таблицей. Это значение по умолчанию.
    • bottom: подпись под таблицей.
    • left: подпись слева от таблицы.
    • right: подпись справа от таблицы.

    Надпись, если она присутствует, должна описывать природу таблицы. Элемент caption должен располагаться непосредственно после начальной метки table. Например:

    <table cols="3">
    <caption>cups of coffee consumed by each senator</caption>
    . остальная часть таблицы .
    </table>

    14.5. Группы рядов. Элементы thead, tfoot и tbody

    <!element thead - o (tr+)>
    <!element tfoot - o (tr+)>
    <!element tbody o o (tr+) >

    <!attlist (thead|tfoot|tbody)-- секция таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейке --

    %CEllvalign;

    -- вертикальное выравнивание в ячейке -- >

    Таблица должна содержать хотя бы одну группу рядов. Каждая группа рядов делится на три секции: заголовок, собственно таблица и подпись под таблицей. Заголовок и подпись являются опционными. Элемент thead определяет заголовок, tfoot - подпись под таблицей, а элемент tbody - тело таблицы. thead, tfoot и tbody, если они присутствуют, должны содержать один или более рядов. Ниже приведен пример использования элементов thead, tfoot и tbody.

    <table>
    <thead>

    <tr> . информация заголовка .

    align="justify"></thead>
    <tfoot>

    <tr> . информационная подпись под таблицей .

    </tfoot>
    <tbody>

    <tr> . первый ряд блока первых данных .

    <tr> . второй ряд блока первых данных .

    </tbody>
    <tbody>

    <tr> . первый ряд блока вторых данных .

    <tr> . второй ряд блока вторых данных .

    <tr> . третий ряд блока вторых данных .

    </tbody>
    </table>

    tfoot в рамках определения table должен появляться до tbody, так чтобы агент пользователя мог осуществлять разбор подписи до получения всех данных таблицы.

    14.6. Опционные метки групп рядов

    Когда таблица содержит только одно тело и не имеет заголовка и нижней подписи, начальная и конечная метки tbody могут быть опущены. Когда блок таблицы содержит заголовок, начальная и конечная метки элемента thead являются необходимыми. Конечная метка может быть опущена, когда далее следует стартовая метка tfoot или tbody. когда блок таблицы содержит нижняя подпись, необходима начальная метка элемента tfoot. Конечная метка может быть опущена, когда далее следуют начальная метка thead или tbody.

    14.7. Группы колонок. Элементы colgroup и col

    <!element colgroup - o (col*) >

    <!attlist colgroup %attrs;

    -- %coreattrs, %i18n, %events --

    span number 1

    -- число колонок в группе по умолчанию --

    width cdata #implied

    -- ширина колонки по умолчанию --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    Определения атрибутов

    span = integer

    Атрибут в случае своего присутствия определяет число колонок в группе по умолчанию. Агент пользователя должен игнорировать этот атрибут, если текущая группа содержит один или более элементов col. Значение атрибута по умолчанию равно единице.

    width = length

    Атрибут определяет значение ширины колонки по умолчанию для текущей группы колонок. Кроме того, для стандартных значений пикселя и процента этот атрибут может иметь специальную форму "0*", которая означает, что ширина каждой колонки в группе должна иметь минимальную ширину для размещения имеющегося текста.

    Таблица должна иметь как минимум одну группу колонок. В отсутствии определения группы считается, что таблица имеет одну группу колонок, включающую в себя все колонки таблицы. Атрибут width элемента colgroup определяет ширину по умолчанию каждой из колонок в группе. Формат "0*", требующий минимальной ширины, может быть отменен элементом col.

    Таблица в приведенном ниже примере имеет две группы колонок. Первая группа содержит 10 колонок, а вторая - 5 колонок. Значение ширины колонки по умолчанию для каждой из колонок в первой группе равно 50 пикселей. Для второй группы ширина колонки определяется минимально возможным значением.

    <table>
    <colgroup span="10" width="50">
    <colgroup span="5" width="0*">
    <thead>
    <tr> ..
    </thead>

    14.8. Элемент col

    <!element col - o empty>

    <!attlist col

    -- группы колонок и свойства --

    %attrs;

    -- %coreattrs, %i18n, %events --

    span number 1

    -- число колонок в группе --

    width cdata #implied

    -- спецификация ширин колонок --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    Определение атрибута

    width = length

    Этот атрибут задает значение по умолчанию для ширины колонок в группе. Атрибут может также принимать значение "0*" (смотри выше) и "i*", где i - целое. Это называется относительной шириной. Когда агент пользователя выделяет место для таблицы, он сначала определяет габариты, а уже затем делит выделенное пространство, определяя относительные ширины рядов и колонок. Число i при этом определяет относительную долю, выделяемую данной колонке. Значение "*" эквивалентно "1*".

    Каждая группа колонок может содержать нуль или более элементов col. Элемент col не определяет группу колонок в том смысле, как это делает colgroup, он предоставляет способ задать значения атрибутов для всех колонок группы. Атрибут span элемента col имеет следующее значение.

    В отсутствии декларации span каждый элемент col представляет одну колонку. Если атрибут span имеет значение n>0, текущий элемент col действует на n колонок таблицы. Если атрибут span равен нулю, текущий элемент col имеет воздействие на все оставшиеся колонки таблицы, начиная с текущей. Что же касается colgroup, атрибут width для col воздействует на ширины колонок, к которым относится этот элемент. Если элемент cal действует на несколько колонок, тогда его атрибут width специфицирует ширину каждой колонки в его зоне ответственности.

    Ниже приведен пример таблицы, имеющей две группы колонок. Первая группа содержит три колонки, вторая - две колонки. Доступное место по горизонтали определяется следующим образом. Сначала агент пользователя выделяет 30 пикселей для первой колонки. Затем будет выделено минимально возможное место для второй колонки. Оставшееся место по горизонтали будет поделено на 6 равных частей. Колонка 3 получит 2 такие порции, колонка 4 - одну, а колонка 5 получит 3.

    <table>
    <colgroup>

    <col width="30">

    <col width="0*">

    <col width="2*">

    <colgroup align="center">

    <col width="1*">

    <col width="3*" align="char" char=":">

    <thead>
    <tr> ...
    </table>

    Мы установили значение атрибута align во второй группе колонок равным "center". Все ячейки в каждой колонке этой группы наследуют это значение. Но оно может быть изменено. В действительности последний элемент col делает это, специфицируя то, что все колонки, которыми он управляет, будут выровнены по символу ":".

    14.9. Ряды таблицы. Элемент tr

    <!element tr - o (th|td)+>

    <!attlist tr

    -- ряд таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках --

    bgcolor %color #implied

    -- цвет фона в ряду -- >

    Элементы TR действуют как контейнеры рядов ячеек таблицы. Ниже приведен пример таблицы, которая имеет три ряда, каждый из которых открывается элементом TR.

    <table>
    <caption>cups of coffee consumed by each senator</caption>
    <tr> . Ряд заголовка .
    <tr> . Первый ряд данных .
    <tr> . Второй ряд данных .
    . остальная часть таблицы .
    </table>

    14.10. Ячейки таблицы. Элементы th и td

    <!element (th|td) - o %block>

    <!attlist (th|td)

    -- Заголовок или данные ячейки --

    %attrs;

    -- %coreattrs, %i18n, %events --

    axis cdata #iplied

    -- содержимое ячейки по умолчанию --

    axes cdata #iplied

    -- список имен axis --

    nowrap (nowrap) #implied

    -- блокирует разрыв слов --

    bgcolor %color #implied

    -- цвет фона ячейки --

    rowspan number

    -- число рядов, охватываемых ячейкой --

    colspan number

    -- число колонок, охватываемых ячейкой --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    Определения атрибутов

    axis = cdata

    Атрибут определяет сокращенное имя заголовка ячейки. Имя ячейки по умолчанию - ее содержимое.

    axes = cdata-list

    Значение этого атрибута представляет собой список имен axis, разделенных запятыми. Эти имена представляют собой заголовки рядов и колонок, принадлежащих данной ячейке. В отсутствии этого атрибута агент пользователя идентифицирует эти имена сам.

    rowspan = integer

    Этот атрибут специфицирует число рядов в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все ряды, начиная с текущего, до конца таблицы.

    colspan = integer

    Этот атрибут специфицирует число колонок в текущей ячейке. Значение этого атрибута по умолчанию равно 1. Значение нуль означает, что ячейка включает в себя все колонки, начиная с текущей, до конца таблицы.

    nowrap

    Использование не рекомендуется. В случае присутствия этот булев атрибут указывает агенту пользователя заблокировать автоматический разрыв слов при выкладке их в ячейку. Вместо этого атрибута рекомендуется использовать стилевой лист.

    Элемент TH запоминает заголовок, в то время как TD - данные. Это позволяет агенту пользователя обрабатывать заголовки и данные по-разному даже в отсутствии стилевого листа. Ячейки могут быть пустыми (не содержать данных). Ниже приведен пример таблицы с четырьмя колонками, имеющими заголовки.

    <table>
    <caption>Cups of coffee consumed by each senator</caption>
    <tr> <th>name <th>Cups <th> Type of coffee <th> Suger?
    <tr> <td>T. Sexton <td>10 <td>espresso <td>no
    <tr> <td>J. Dinnen <td>5 <td>decaf <td>yes
    . остальная часть таблицы .
    </table>

    Агент пользователя представит верхнюю часть данной таблицы в виде:

    Cups of coffee consumed by each senator

    Name

    Cups

    Type of coffee

    Sugar

    T. Sexton

    10

    espresso

    no

    J. Dinnen

    5

    decaf

    yes

    Для того чтобы сделать таблицу более выразительной, можно ввести атрибут border в элемент table.

    <table border="border">
    . остальная часть таблицы .
    </table>

    Тогда агент пользователя отобразит начало данной таблицы следующим образом:

    Cups of coffee consumed by each senator

    Name

    Cups

    Type of coffee

    Sugar

    T. Sexton

    10

    espresso

    no

    J. Dinnen

    5

    decaf

    yes

    Ячейки с этикетками

    Атрибуты axis и exes предоставляют возможность снабжать ячейки таблицы этикетками (labels). Синтезаторы речи могут использовать эти этикетки для идентификации содержимого и положения каждой ячейки. Программное обеспечение может рассматривать эти этикетки как имена полей базы данных при занесении содержимого таблицы в банк данных. Ниже представлен пример таблицы, где значение атрибута axis представляет собой фамилию сенатора.

    <table border="border">
    <caption>Caps of coffee consumed by each senator</caption>
    <tr> <th>Name <th>Cups <th> Type of coffee <th> suger?
    <tr> <td axis="sexton" exes="name">T. Sexton <td>10
    <td>espresso <td>no
    <tr> <td axis="dinnen" exes="name">J. Dinnen <td>5 <td>decaf <td>yes
    </table>

    14.11. Ячейки, которые занимают несколько рядов или колонок

    Ячейки могут охватывать несколько рядов или колонок. Число рядов или колонок в ячейке определяется атрибутами rowspan и colspan для соответственно TH или TD-элементов. В таблице, которая была описана, ячейка в ряду 4 вторая колонка должна занимать три колонки, включая текущий ряд.

    <table border="border">
    <caption>Caps of coffee consumed by each senator</caption>
    <tr> <th>Name <th>Cups <th> Type of coffee <th> suger?
    <tr> <td>T. Sexton <td>10 <td>espresso <td>no
    <tr> <td>J. dinnen <td>5 <td>decaf <td>yes
    <tr> <td>A. Soria <td colspan="3"<em>not available</em>
    </table>

    Эта таблица будет развернута визуальным агентом пользователя как:

    Caps of coffee consumed by each senator

    Name

    Cups

    Type of coffee

    Suger?

    T. Sexton

    10

    espresso

    no

    J. Dinnen

    5

    decaf

    yes

    A. Soria

    not available

    Этот пример иллюстрирует как описания ячеек, которые распространяются более чем на один ряд или колонку, влияет на определение последующих ячеек. Рассмотрим следующее описание таблицы.

    <table border="border">
    <tr> <td>1 <td rowspan="2">2 <td>3
    <tr> <td>4 <td>6
    <tr> <td>7 <td>8 <td>9
    </table>

    Таблица может быть представлена в виде:

    1

    2

    3

    4

    6

    7

    8

    9

    Версия HTML 4.0 включает в себя механизмы контроля горизонтального и вертикального выравнивания, стилями границ таблицы и полями ячеек.

    14.12. Горизонтальное и вертикальное выравнивание

    <!entity % cellhalign "align (left|center|right|justify|char) #implied
    char cdata #implied -- выравнивание по символу, напр. char=":" --
    charoff cdata #implied -- смещение выравнивания по символу -- >
    <!entity % cellvalign "valign (top|middle|bottom|baseline) #implied" >

    Определения атрибутов

    align = left|center|right|justify|char

    Этот атрибут определяет способ выравнивания текста в ячейке. Возможны следующие значения:

    left:

    выравнивание по левому краю (значение атрибута по умолчанию)

    center:

    Выравнивание текста в ячейке по центру (значение по умолчанию для заголовков)

    right:

    выравнивание текста по правому краю ячейки.

    justify:

    выравнивание текста по правой и левой границам.

    char:

    выравнивание текста по некоторому символу.

    valign = top|middle|bottom|baseline

    Этот атрибут определяет вертикальное позиционирование текста в ячейке таблицы. Возможны следующие значения:

    top:

    текст прижимается к верхней границе ячейки.

    middle:

    текст размещается по центру ячейки (значение по молчанию для заголовков)

    bottom:

    текст прижимается к нижней границе ячейки.

    baseline:

    все ячейки в ряду должны быть выровнены по высоте так, чтобы их первые строки были на одной высоте. Это не касается последующих строк.

    char = cdata

    Этот атрибут определяет символ в тексте, который будет выполнять роль оси для выравнивания. Значением по умолчанию является точка для английского языка и запятая - для французского (бывает полезно для колонок цифр с долями целого).

    charoff = length

    Если этот атрибут присутствует, он определяет смещение текста относительно символа выравнивания (рассматривается первый такой символ). Если в строке такого символа нет, то она должна быть сдвинута горизонтально в конец относительно позиции выравнивания.

    Рассмотрим пример таблицы с выравниванием по символу точка.

    <table border="border">
    <colgroup>
    <col><col align="char" char=".">
    <thead>
    <tr><th>Vegetable <th>Cost per kilo
    <tbody>
    <tr> <td> lettuce <td>$1
    <tr> <td> silver carrots <td>$10.50
    <tr> <td>golden turnips <tr>$100.30
    </table>

    Отформатированная таблица будет выглядеть как:

    vegetable

    cost per kilo

    lettuce

    $1

    silver carrots

    $10.50

    golden turnips

    $100.30

    14.13. Границы и линии

    Следующие атрибуты влияют на рамки таблицы и внутренние линии.

    frame = void|above|below|hsides|lhs|rhs|vsides|box|border

    Эти атрибуты определяют, какая из сторон рамки, окружающей таблицу, будет видимой.

    void:

    Ни одна из сторон. Значение по умолчанию.

    above:

    Только верхняя сторона.

    below:

    Только нижняя сторона.

    hsides:

    Только нижняя и верхняя стороны.

    vsides:

    Только правая и левая стороны.

    lhs:

    Только левая сторона.

    rhs:

    Только правая сторона.

    box:

    Все четыре стороны.

    border:

    Все четыре стороны.

    rules = none|groups|rows|cols|all

    Этот атрибут определяет, какие линии появится между ячейками в пределах таблицы. Возможные значения:

    none:

    Никаких линий, значение по умолчанию.

    groups:

    Линии имеются только между группами рядов и столбцов.

    rows:

    Линии имеются только между рядами.

    cols:

    Линии имеются только между столбцами.

    all:

    Линии имеются между рядами и столбцами.

    border = cdata

    Эти атрибуты определяют ширину рамки вокруг таблицы в пикселях. В приведенном ниже примере таблица имеет рамку в 5 пикселей и присутствует с правой и левой сторон таблицы. Разделительные линии имеются между всеми колонками.

    <table border="5" frame=vsides" rules="cols">
    <tr> <td>1 <td>2 <td>3
    <tr> <td>4 <td>5 <td>6
    <tr> <td>7 <td>8 <td>9
    </table>

    Следующие установки должны выполняться агентом пользователя для совместимости. Установка border="0" подразумевает frame="void" и, если не специфицировано иного, rules="none". Другие установки border подразумевают frame="border" и, если не оговорено иное, rules="all". Значение "border" в стартовой метке элемента table должно интерпретироваться как значение атрибута frame. Это предполагает, что rules="all" и ненулевое значение атрибута border. Так, например:

    <frame border="2"> у <frame border="2" frame="border" rules="all">
    и
    <frame border> <=< frame frame="border" rules="all">

    14.14 Поля ячейки

    Два атрибута регулируют зазор между и внутри ячеек.

    cellspacing = length

    Этот атрибут определяет то, какое расстояние должно быть оставлено между рамкой таблицы и начальным или конечным краем ячейки для каждого ряда или колонки, а также между ячейками в таблице.

    cellpadding = length

    Этот атрибут определяет расстояние между границей ячейки и его содержимым.

    Во всех последующих таблицах атрибут cellspacing определяет, что ячейки разделяются друг от друга и от рамки таблицы расстоянием в 20 пикселей. Атрибут cellpadding определяет, что верхняя и нижняя граница ячейки отстоит от его содержимого на 10% доступного пространства по вертикали (всего 20%). Аналогично поля ячейки в горизонтальном направлении составляют 10% от горизонтального размера ячейки.

    <table>
    <tr cellpadding="20"> <tr>data1 <td cellpadding="20%">data2 <td>data3
    </table>

    Ниже приведены примеры, где проиллюстрировано взаимодействие различных элементов. Пример 1.

    <table border="border">
    <caption>A test table with merged cells </caption>

    <tr>

    <th> rowspan=2><th colspan="2">average

    <th rowspan="2">other<br>category<th>misc

    <tr>

    <th>height<th>weight

    <tr>

    <th>align="left">males<td>1.9<td>0.003

    <tr>

    <th> align="left" rowspan="2">females<td>1.7<td>0.002

    /table>

    Таблица может быть отображена следующим образом.

    A test table with merged cells

     

    Average

    Other
    category

    misc

    height

    weight

     

    males

    1.9

    0.003

       

    females

    1.7

    0.002

       

    Пример 2 иллюстрирует группировку рядов и колонок. Пример взят из "developing international software", by nadine kano.

    Code-page support in Microsoft Window

    Code-page
    ID

    Name

    ACP

    OEMCP

    Windows
    NT 3.1

    Windows
    NT 3.51

    Windows
    95

    1200
    1250
    1251
    1252
    1253
    1254
    1255
    1256
    1257
    1361

    unicode (BMP of ISO/IEC-10646)
    windows 3.1 eastern european
    windows 3.1 cyrillic
    windows 3.1 us (ansi)
    windows 3.1 greek
    windows 3.1 turkish
    hebrew
    arabic
    baltic
    korean

     
    x
    x
    x
    x
    x
    x
    x
    x
    x

     
     
     
     
     
     
     
     
     
     

    x
    x
    x
    x
    x
    x
     
     
     
     

    x
    x
    x
    x
    x
    x
     
     
     
    **

    *
    x
    x
    x
    x
    x
    x
    x
    x
    x

    437
    708
    709
    710
    720

    MS-DOS united states
    arabic (asmo 708)
    arabic (asmo 449+, bcon v4)
    arabic (transparent arabic)
    arabic (transparent asmo)

     

    x
    x
    x
    x
    x

    x
     
     
     
     

    x

    x
    x
    x
    x
    x

    15. Информация о пути. Элемент base

    <!element base - o empty>
    <!attlist base href %url #required
    target cdata #implied -- где развернуть подключенный ресурс -- >

    Описание атрибута

    href = url

    Этот атрибут задает абсолютный url, который используется как базовый при определении относительных url.

    В HTML проходы всегда задаются с помощью URL. Относительные URL получаются на основе базового URL, который может быть получен различными путями. Элемент base позволяет описать базовый URL явно. Например:

    <html>
    <head>
    <base href=http://www.barre.fr/fou/intro.html>
    </head>
    ..
    </html>

    Относительный URL "../gee/foo/html" будет в этом случае получен в виде:

    http://www.barre.fr/gee/foo.html

    15.1. Связи и якоря

    HTML-связь представляет собой соединение одного WWW-ресурса с другим.

    Определение связей и якорей

    В HTML любая связь имеет два конца и направление. Связь начинается в источнике и завершается в месте назначения. Любое описание связи определяет оба эти конца. Один конец задается местом описания связи, другой - атрибутом этой связи. Связь соответствует какому-то WWW-ресурсу (HTML-документу, изображению, видео-клипу, текущему документу, звуковому файлу и т.д.). Конец связи может быть также задан якорем. Якорь - это именованный указатель на определенную часть документа. Связь устанавливает соответствие между источником и местом назначения. Но помимо этого связь может определять тип информации. Связи могут носить самый разный характер, например, указания "next" или "previous" также задают определенные связи. Связи могут использоваться пользователем и для определения порядка печати документов. Атрибут rel определяет, что связь имеет начало в текущем документе. Атрибут rev указывает, что описанная связь имеет в качестве места назначения текущий документ. В HTML имеется два элемента, определяющие связь, это link и a.

    Link может появиться в секции head HTML-документа. Этот элемент определяет взаимоотношение между зоной текущего документа и другим ресурсом.

    Элемент A может появиться в теле документа, он устанавливает связь между зоной текущего документа и другим ресурсом. Элемент a в отличие от link может иметь содержимое (текст, изображения и т.д.). Другим важным отличием этих двух элементов является то, что А интерпретируется агентом пользователя как указание "извлечь ресурс, находящийся на другом конце связи". Извлеченный ресурс может обрабатываться агентом пользователя разными способами:

    Открыть новый документ в том же окне, открыть документ в другом окне, запустить новую программу и т.д.

    Атрибут title может быть установлен в элементах для выдачи дополнительной информации о природе связи.

    15.2. Элементы, определяющие якоря

    Существует два способа специфицировать якоря в HTML-документах.

    • Использовать элемент А (служит для формирования связей и якорей).
    • Применить атрибут id любого элемента.

    Так как документы могут быть написаны на разных языках, link и a поддерживают атрибуты lang, dir и charset.

    15.3. Элемент А

    <!element a - - (%inline)* -(a)>
    <!attlist a

    %attrs;

    -- %coreattrs, %i18n, %events --

    charset cdata #implied

    -- перекодировка символов в подключенном ресурсе --

    name cdata #implied

    -- именованный конец связи --

    href %url #implied

    -- url для подключенного ресурса --

    target cdata #implied

    -- где развернуть ресурс --

    rel cdata #implied

    -- типы прямых связей --

    rev cdata #implied

    -- типы обратных связей --

    accesskey cdata #implied

    -- символ ключа доступа --

    shape %shape rect

    -- для использования с object shapes --

    coords %coords #implied

    -- для использования с object shapes --

    tabindex number #implied

    -- положения табуляции -- >

    Описания атрибутов

    name = cdata

    Этот атрибут указывает на то, что элемент использован для описания якоря. Значение этого атрибута является уникальным именем якоря. Это имя действительно в пределах данного документа. Атрибут name работает в том же пространстве имен, что и атрибут ID.

    href = url

    Этот атрибут указывает на то, что элемент использован для описания связи. Значение атрибута равно положению одного из концов связи (другой конец задан положением этого элемента).

    rel = cdata

    Этот атрибут указывает на то, что источником связи является текущая позиция в документе. Значение Href в этом случае определяет место назначения связи. Значение rel специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами.

    rev = cdata

    Этот атрибут указывает на то, что место назначения связи соответствует текущей позиции в документе. Значение Href в этом случае определяет положение источника. Значение rev специфицирует тип связи. Этот атрибут может включать в себя список типов связей, разделенных пробелами.

    charset = cdata

    Этот атрибут специфицирует перекодировку символов для данной связи. Значение этого атрибута должно быть именем "charset" описанным в RFC-2045. Значение по умолчанию этого атрибута равно "ISO-8859-1".

    Ниже приведен пример использования А-элемента.

    <a href=http://www.3w.org/>w3c web site</a>

    Эта ссылка указывает на базовую страницу консорциума WWW. Когда пользователь активирует эту связь, агент пользователя обратится к указанному ресурсу и откроет HTML-документ. Агент пользователя представляет ссылки в документе так, чтобы выделить их из текста (например, подчеркивает их). Чтобы сообщить агенту пользователя в явном виде, какой набор символов следует использовать при отображении, следует установить соответствующее значение атрибута charset.

    <a href =http://www.w3.org/ charset="ISO-8859-1">w3c web site</a>

    Ниже приведен пример, иллюстрирующий описание якоря с именем "anchor-one" в файле "one.html".

    . текст до якоря .

    <a name="anchor-oner">this is the location of anchor one.</a>
    . текст после якоря .

    Это определение присваивает якорь зоне документа, содержащей текст "This is the location of anchor one". Определив якорь, мы можем установить с ним связь из того же или постороннего документа. URL, который указывает на якорь, завершаются символом #, за которым следует имя якоря. Ниже приведены примеры такого URL.

    • Абсолютный URL: http://www.mycompany.com/one.html">http://www.mycompany.com/one.html#anchor-one
    • Относительный URL: ../one.html#anchor-one
    • Когда связь задана в пределах документа: #anchor-one

    Таким образом, связь, определенная в файле "two.html", который находится в том же каталоге, что и "one.html" имеет ссылку на якорь в виде:

    <a href="./one.html#anchor-one" anchor one</a>

    Элемент А в следующем примере определяет якорь и связь в одно и то же время.

    <a name="anchor-two" href="html://wwwsomecompany.com/people/ian/vocation/family.png">
    </a>

    Этот пример содержит связь с www-ресурсом другого типа (png-изображение). Активация связи должна извлечь это изображение из сети и отобразить его.

    15.4. Связи mailto

    Автор может сформировать связи, которые не ведут к какому-либо документу, а реализуют отправку e-mail сообщения по некоторому адресу. Когда такая связь активизируется, агент пользователя вызывает почтовую программу. Для реализации таких связей введено значение mailto атрибута Href.

    <a href="mailto:semenov@ns.itep.ru"> yury semenov</a>

    Когда пользователь активизирует эту связь, агент пользователя открывает почтовую программу и заносит в поле "to:" значение "semenov@ns.itep.ru".

    15.5. Вложенные связи

    Связи и якоря, описанные элементом А не допускают вложения. Например, ниже приведенная запись недопустима.

    <a name="outer-anchor" href="next-outer.html"> an outer anchor and link <a name="inner-anchor" href="next-inner.html">an inner anchor and link.</a></a>

    15.6. Якоря с атрибутом id

    Атрибут id может использоваться для размещения якоря в области начальной метки любого элемента. Ниже приведен пример использования id для размещения якоря в элементе Н2. Якорь подвязан здесь посредством А-элемента.

    <h2 id="section2">section two</h2>
    . позднее в документе .
    please refer to <a href="#section2">section two</a> above for more details.

    Атрибуты ID и name работают в общем пространстве имен (см. ISO10646). Это означает, что они не могут описать якоря с идентичными именами в пределах одного документа.

    15.7. Элемент link

    <!element link - o empty>
    <!attlist link

    %attrs;

    -- %coreattrs, %i18n, %events --

    href %url #implied

    -- url для подключаемого ресурса --

    rel cdata #implied

    -- forward link types --

    rev cdata #implied

    -- reverse link types --

    type %contenttype #implied

    -- advisory internet content type --

    media cdata #implied

    -- для представления в этой среде --

    target cdata #implied

    -- место, где производится отображение -- >

    Этот элемент, который должен использоваться в Head-секции документа (любое число раз), определяет связь, независящую от среды. Хотя Link не имеет содержимого, он предоставляет информацию, обрабатываемую агентами пользователя. Ниже в предлагаемом примере показано как в секции head документа могут появиться несколько определений Link. Атрибуты rel и rev определяют, откуда связь начинается и где кончается.

    <html>
    <head>
    <link rel ="index" href="../index.html">
    <link rel ="next" href="chapter_3.html">
    <link rev ="previous" href="chapter_1.html">
    </head>
    ..

    15.8. Типы связей

    Атрибуты rel и rev определяют начало и конец связи, но их значение или значения задают также природу связи. Если для элемента А атрибуты rel и rev не являются обязательными для link, хотя бы один из них присутствовать должен. Агент пользователя может интерпретировать эти атрибуты множеством путей, например, через меню или "клавишу next". Ниже перечислены некоторые типы связей.

    Содержимое

    соединение выполняет функцию оглавления документа.

    Индекс

    соединение предлагает индекс документа.

    Глоссарий

    соединение предлагает глоссарий терминов для данного документа.

    copyright

    соединение воспроизводит заявление о защите авторских прав.

    Следующий

    связь осуществляет переход к следующему документу из списка (next)

    Предыдущий

    связь осуществляет переход к предыдущему документу из списка (previous)

    Начало

    связь вызывает переход к первому из ряда документов.

    Справка

    связь производит вызов документов, дающих дополнительную информацию по некоторым вопросам (help)

    Закладка

    связь реализует переход в определенную точку документа, часто такой точкой является заголовок главы или раздела (bookmark).

    Стилевой лист

    связь указывает на внешний стилевой лист.

    Альтернатива

    связь указывает на различные версии того же самого документа, например, на переводы данного документа на иностранные языки (alternate).

    15.9. Связи с поисковыми системами

    Элемент Link может использоваться для решения задач поиска документов по ключевым словам и другим признакам, например, язык или представления документа в виде, допускающем печать. Ниже приведен пример, где сообщается поисковой системе о месте нахождения печатной копии руководства.

    <head>
    <link media="print" title="the manual in postscript"

    rel="alternate"

    href="http://someplace.com/manual/postscript.ps">

    </head>

    А в этом примере мы заставляем поисковую систему найти первую страницу собрания документов.

    <head>
    <link rel="start" title="the first page of the manual"

    href="html://someplace.com/manual/postscript.ps">

    </head>

    16. Элемент object

    <!entity % oalign "(texttop|middltextmiddle|baseline|textbottom|left|center|right)">
    <!element object - - (param | %block)*>
    <!attlist object

    %attrs;

    -- %coreattrs, %i18n, %events --

    declare (declare) #implied

    -- декларирует но не присваивает конкретных значений флагу --

    classid %url #implied

    -- идентифицирует приложение --

    codebase %url #implied

    -- некоторые системы требуют дополнительного url --

    data %url #implied

    -- ссылка на объектные данные --

    type %contenttype #implied

    -- Интернетовский тип данных --

    codetype %contenttype #implied

    -- Интернетовский тип для кодов --

    standby cdata #implied

    -- сообщение, отображаемое при загрузке --

    align %oalign #implied

    -- позиционирование в пределах документа --

    height %length #implied

    -- предлагаемая высота --

    width %length #implied

    -- предлагаемая ширина --

    border %length #implied

    -- предлагаемая ширина рамки --

    hspace %length #implied

    -- предлагаемый горизонтальный пробел --

    vspace %length #implied

    -- предлагаемый вертикальный пробел --

    usemap %url #implied

    -- reference to image map --

    shapes (shapes) #implied

    -- объект имеет сформированные гипертекстные связи --

    name %url #implied

    -- представить, как часть формы --

    tabindex number #implied

    -- position in tabbing order -- >

    Определения атрибутов

    codebase = url

    Этот атрибут специфицирует базовый проход для определения относительного URL, описанного classid. Если атрибут не задан, значением по умолчанию является базовый URL данного документа.

    classid = URL

    Этот атрибут специфицирует положение механизма отображения через url.

    codetype = cdata

    Этот атрибут специфицирует internet media type данных, ожидаемых механизмом отображения, определенным classid. Атрибут является опционным, но рекомендуемым, когда имеется classid, так как это позволяет агенту пользователя избежать загрузки информации для неподдерживаемого типа среды. Если явно величина не задана, его значение по умолчанию соответствует значению атрибута type.

    data = URL

    Этот атрибут специфицирует положение данных, которые должны быть отображены.

    type = cdata

    Этот атрибут специфицирует Internet media type для данных, заданных атрибутом data. Атрибут является опционным, но рекомендуемым, когда задан атрибут data, так как это позволяет агенту пользователя избежать загрузки информации с типом, неподдерживаемым средой.

    declare

    Если присутствует, этот булев атрибут делает текущее определение object лишь декларацией.

    standby = cdata

    Этот атрибут специфицирует сообщение, которое агент пользователя может отобразить при загрузке объектных приложений и данных.

    align = texttop|middle|textmiddle|baseline|textbottom|left|center|right

    Не рекомендуется к использованию. Этот атрибут специфицирует положение объекта по отношению к окружающему контексту.

    Большинство агентов пользователей снабжены механизмом для отображения базовых типов информации, таких как текст, картинки в GIF-формате, цвета, шрифты и т.д. В HTML элемент object определяет положение механизма отображения и положение данных, необходимых для механизма отображения. Агент пользователя интерпретирует элемент object согласно следующим правилам.

    Агент пользователя должен сначала попробовать механизм отображения, заданный атрибутом элемента. Если агент пользователя не может поддержать этот механизм по какой-либо причине, он должен попытаться работать с содержимым элемента.

    Важным следствием конструкции элемента object является то, что он предлагает механизм для описания альтернативного механизма отображения различных объектов. Каждая декларация object может предлагать альтернативный механизм отображения. Если агент пользователя не может воспользоваться имеющимся механизмом, он может обратиться к тексту, который может представлять собой другой элемент object. В ниже приведенном примере использовано несколько деклараций object для иллюстрации альтернативных способов отображения. Агент пользователя сначала попробует отобразить первый элемент object, а далее будет пытаться воспользоваться: аплетом eath, написанным на языке python, mpeg анимацией, изображением земли в формате GIF и, наконец, альтернативным текстом.

    <object title="the earth as seen from space"
    classid="http://www.observer.mars/theearth.py">
    <object data="theearth.mpeg" type="application/mpeg">

    <object src="theearth.gif">

    the <strong> "earth"</strong> as seen from space.

    </object>

    </object>

    </object>

    Самая внешняя декларация специфицирует аплет, который не требует данных или начальных параметров. Вторая декларация специфицирует MPEG-анимацию и не определяет механизм отображения, предполагая, что с этой работой справится агент пользователя. Здесь установлен атрибут type, таким образом, что в случае если агент пользователя не может отобразить MPEG, он может не копировать "theearth.mpeg" из сети. Третья декларация специфицирует позицию GIF-файла и предлагает альтернативный текст на случай, когда другие механизмы не приведут к успеху.

    Отображаемая информация может извлекаться двумя путями: из текущей строки илиb из внешнего источника. Первый способ дает большее быстродействие, но требует много места.

    16.1. Инициализация объекта. Элемент param.

    <!element param - empty

    -- именованное значение параметра -- >

    <!attlist param name cdata #required

    -- имя параметра --

    value cdata #implied

    -- значение параметра --

    valuetype (data|ref|object) data

    -- способ интерпретации значения --

    type cdata #implied

    -- internet media type -- >

    Определения атрибутов

    name = cdata

    Этот атрибут определяет имя параметра исполнения.

    value = cdata

    Этот атрибут специфицирует значение параметра исполнения, заданного атрибутом name. Значение этого параметра не имеет какого-либо смысла для HTML, он определяется рассматриваемым объектом.

    valuetype=data|ref|object

    Этот атрибут специфицирует тип значения, определенного атрибутом value. Возможны значения:

    data:

    значение, заданное value, после преобразования любых вложенных символов и цифровых объектов будет непосредственно передано механизму отображения в виде строки. Этот тип используется по умолчанию и может появляться в стартовой метке элемента.

    ref:

    значение, заданное value, является url, который определяет ресурс, где записано значение параметра исполнения. URL должно передаваться механизму отображения в не преобразованном виде.

    object:

    значение, заданное value, является фрагментом URL, который определяет декларацию object в том же самом документе. В этом случае определение object должно идентифицироваться его атрибутом ID.

    type = cdata

    Этот атрибут специфицирует internet media type ресурса, определенного атрибутом value, только в случае, когда атрибут valuetype = "ref". Этот атрибут, таким образом, специфицирует для агента пользователя тип значений, которые будут обнаружены в URL, определенном атрибутом value.

    Элемент param специфицирует набор значений, которые могут требоваться механизму отображения. В начале декларации object может появиться любое число элементов param. Синтаксис имен и значений предполагается понятным механизму отображения. Имена и значения передаются механизму отображения, как стандартный ввод. Рассмотрим пример. Здесь предполагается, что механизм отображения может воспринять два параметра, которые определяют начальную высоту и ширину (часов). Задаем эти начальные параметры равными 40х40 пикселей.

    <object classid="http://www.miamachina.it/ahalogclock.py">
    <param name="height" value="40" valuetype="data">
    <param name="width" value="40" valuetype="data">

    Этот агент пользователя не может исполнять приложения, написанные на языке python.

    </object>

    Так как значение по умолчанию valurtype для элемента param равно "data", мы можем заменить вышеприведенную декларацию следующей:

    <param name="height" value="40">
    <param name="width" value="40">

    или

    <param name="height" value="40" data>
    <param name="width" value="40" data>

    В следующем исходные данные исполнения для параметра механизма отображения "init_values" заданы как внешний ресурс (GIF-файл). Значение атрибута valuetype установлено равным "ref", а атрибут value равен URL.

    <object classid="html://www.gifstuff.com/gifappli" standby="loading elvis.">
    <param name="init_values" value="./images/elvis.gif">
    </object>

    Здесь установлен также атрибут standby так, что агент пользователя может отобразить сообщение в процессе загрузки механизма отображения. Механизмы отображения локализуются с помощью URL. Первая секция абсолютного URL характеризует протокол, используемый для передачи данных, которые указаны в URL. Для HTML-документов протокол обозначается как HTTP. Но возможны и другие варианты, например, в случае использования механизма отображения java вы можете использовать URL, начинающиеся со слова Java, а для аплетов activex - "clsid". В предлагаемом примере в HTML-документ введен Java-аплет.

    <object classid="java:program.start">
    </object>

    Некоторые схемы отображения требуют дополнительной информации для идентификации их применения и должны сообщить, где можно найти эту информацию. Проход к этой информации для механизма отображения может быть указан с помощью атрибута codebase.

    <object codetype="application/octet-strim" classid="java:program.start">
    codebase=http://fooo.bar.com/java/myimplement/
    </object>

    В следующем примере с помощью атрибута classid через URL, который начинается с протокольной информации "clsid", специфицирован механизм activex.

    <object classid="clsid:663c8fef-1ef9-11cf-a3db-080036f12502"
    data=http://www.acme.com/ole/clock.stm>
    Это приложение не поддерживается.
    </object>

    Для декларирования механизма отображения так, чтобы он не запускался в процессе прочтения агентом пользователя, нужно в элементе object установить булеву переменную declare. В то же время вы должны идентифицировать декларацию с помощью атрибута id в элементе object.

    В предлагаемом ниже примере декларируется object, который активируется через внешнюю связь. Таким образом, объект можно активировать с помощью мышки, выбрав соответствующий фрагмент текста.

    <object declare

    id="earth_declaration"

    data="theearth.mpeg"

    type="application/mpeg">

    <object src="theearth.gif">

    the <strong>earth</strong> as seen from space.

    </object>

    </object>
    .далее в документе .
    click to see a neat <a href="#earth_declaration">
    animation of the earth! </a>

    Последующий пример иллюстрирует то, как можно специфицировать значения исполнительных параметров, которые являются объектами. В этом примере мы посылаем текст гипотетическому механизму его отображения. Механизм отображения распознает параметр, названный "font". Значение этого параметра само является объектом, который управляет использованием определенного шрифта. Взаимоотношение этого объекта и механизма отображения устанавливается путем присвоения id "tribune" декларации объекта шрифта и обращением к нему из элемента param.

    <object declare

    id="tribune"

    type="application/x-webfont"

    data="tribune.gif">

    </object>
    . здесь отображается текст из файла kublakhan.txt .
    <object classid=http://foo.bar.com/poem_viewer

    data="kublakhan.txt">

    <param name="font" valuetype="object" value="#tribune">
    <p>you're missing a really cool poem viewer .
    </object>

    Агент пользователя, который не поддерживает атрибут declare, должен пытаться отображать содержимое декларации object.

    Выравнивание объектов

    Атрибут align для данного элемента применять не рекомендуется, предпочтительнее использование стилевых листов.

    17. Изображения. Элемент img

    <!element img - o empty

    -- введение изображения в текст документа -- >

    <!attlist img %attrs;

    -- %coreattrs, %i18n, %events --

    src %url #required

    -- url вводимого рисунка --

    alt cdata #implied

    -- описание для чисто текстовых броузеров --

    align %ialign #implied

    -- вертикальное или горизонтальное выравнивание --

    height %pixels #implied

    -- предлагаемая высота в пикселях --

    width %pixels #implied

    -- предлагаемая ширина в пикселях --

    border %pixels #implied

    -- предлагаемая толщина рамки в пикселях --

    hspace %pixels #implied

    -- предлагаемая ширина горизонтального поля --

    vspace %pixels #implied

    -- предлагаемая ширина вертикального поля --

    usemap %url #implied

    -- use client-side image map --

    ismap (ismap) #implied

    -- use server-side image map --

    Определение атрибутов

    src = URL

    Этот атрибут специфицирует положение (указатель на) ресурса, содержащего изображение. Общепринятые форматы: GIF, JPG, PNG.

    align = bottomiddle|top|left|right

    Применение не рекомендуется. Атрибуты определяют положение изображения по отношению к окружающему тексту.

    Элемент IMG вводит изображение в текущий документ в точке его описания. Но тем не менее, рекомендуется вводить рисунок в текст с помощью элемента object. Рассмотрим, как семейное фото может быть включено в документ.

    <img src="html://www.somecompany.com/people/ian/vocation/family.png"

    alt="a photo of my family at the lake.">

    Это же может быть сделано с помощью object следующим образом.

    <object data=http://www.somecompany.com/people/ian/vocation/family.png

    type="image/png">

    Фото моей семьи на озере.
    </object>

    Атрибут alt специфицирует текст, который будет выведен в случае, когда изображение не может быть отображено по какой-либо причине.

    18. Введение аплетов. Элемент applet

    <!element applet - - (param | %inline) *>
    <!attlist applet

    codebase %url #implied

    -- опционный базовый url для аплета --

    archive cdata #implied

    -- архивный список с элементами, разделенными с помощью запятых --

    code cdata #implied

    -- файл класса аплета --

    object cdata #implied

    -- специализированный файл аплета --

    alt cdata #implied

    -- описание для чисто текстовых броузеров --

    name cdata #implied

    -- позволяет аплетам найти друг друга --

    width %pixels #required

    -- предлагаемая ширина в пикселях --

    height %pixels #required

    -- предлагаемая высота в пикселях --

    align %ialign #implied

    -- вертикальное или горизонтальное выравнивание --

    hspace %pixels #implied

    -- предлагаемые горизонтальные поля --

    vspace %pixels #implied

    -- предлагаемые вертикальные поля -- >

    Описания атрибутов

    codebase = URL

    Этот атрибут специфицирует базовый URL для аплета. Если этот атрибут отсутствует, в качестве базового URL рассматривается текущий документ.

    code = cdata

    Этот атрибут специфицирует имя ресурса, который содержит откомпилированный субкласс аплета. Значение атрибута должно представлять собой относительный URL по отношению к базовому URL.

    name = cdata

    Этот атрибут специфицирует имя аплета, которое позволяет аплетам найти друг друга в пределах страницы.

    width = length

    Этот атрибут специфицирует исходную ширину для области отображения аплета (без учета размера окна или области диалоговых обменов, которые вызывают аплет).

    height = length

    Этот атрибут специфицирует исходную высоту для области отображения аплета.

    align = top|middle|bottom|left|right

    Этот атрибут специфицирует положение объекта по отношению к окружающему тексту.

    archive = cdata

    Этот атрибут специфицирует имена одного или нескольких архивов, разделенные запятыми, содержащие классы и другие ресурсы, которые будут предварительно загружены. Классы загружаются с помощью вызова appletclassloader с данным codebase. Предзагрузка ресурсов может значительно улучшить работу аплета.

    object = cdata

    Этот атрибут присваивает имя ресурсу, который содержит последовательное представление аплета. Аплет приводится к стандартному виду. Используется метод start().

    Этот элемент, поддерживаемый всеми java-броузерами, позволяет разработчикам встраивать Java-аплеты в HTML-документы. Содержимое аплетов используется агентом пользователя как альтернатива, если он не поддерживает данный элемент. При прочих условиях его содержимое должно игнорироваться. Ниже приведен пример Java-аплета.

    <applet code="bubbles.class" width="500" height="500">
    java-аплет, который рисует движущиеся пузыри.
    </applet>

    Эту запись можно переписать в другой форме.

    <object codetype="application/octet-stream"
    classid="java:bubbles.class"

    width="500" height="500">

    java-аплет, который рисует движущиеся пузыри.
    </object

    Исходные данные можно передать аплету через элемент param

    <applet code="audioitem" width="15" height="15">
    <param name="snd" value="hello.au|welcome.au">
    java-аплет, который исполняет приветственную мелодию.
    </applet>

    Вариант, базирующийся на object, представлен ниже.

    <object codetype="application/octet-stream"
    classid="audioitem"
    width="15" height="15">
    <param name="snd" value="hello.au|welcome.au">
    java-аплет, который исполняет приветственную мелодию.
    </object>

    19. Введение HTML-документа в другой HTML-документ

    Иногда возникает необходимость не связи с другим HTML-документом, а полного его включения в текст. Для решения такой задачи рекомендуется использовать элемент object с атрибутом data. Ниже следующая строка включит содержимое file_to_include.html в позицию документа, где размещен элемент object.

    <object data="file_to_include.html">
    warning: file_to_include.html could not be included.
    </object>

    Содержание object отображается только в случае, когда атрибут data не может быть загружен. При использовании операций включения следует проявлять осторожность, так как файл может содержать элементы, которые вызовут непредсказуемые действия. Для введения определенного текста в документ можно также использовать элемент Iframe.

    20. Введение карты изображения в html-документ

    Использование карты изображения позволяет разработчику специфицировать активные зоны изображения и поставить им в соответствие определенные операции. Карта изображения создается путем установления связи между объектом и определенными областями изображения. Существует два типа карт изображения:

    1. Сторона сервера. Когда пользователь активирует область карты изображения со стороны сервера с помощью мышки, координаты нажатия клавиши посылаются серверу, где помещен документ. Сервер интерпретирует эти координаты и выполняет определенные действия (определено атрибутом href элемента А).
    2. Сторона клиента. Когда пользователь активирует область карты изображения со стороны клиента с помощью мышки, координаты нажатия клавиши интерпретируются агентом пользователя. Агент пользователя выбирает связь, которая была специфицирована для активированной области.

    Предпочтительной считается карта изображения клиента. Предусматривается возможность использования карты изображения несколькими элементами.

    20.1. Карты изображения клиента

    Ниже описаны атрибуты элементов A и AREA, которые позволяют разработчику специфицировать ряд геометрических областей и ассоциировать их с определенными URL.

    Описания атрибутов

    shape = default|rect|circle|poly

    Этот атрибут специфицирует форму области. Возможные значения:

    default

    специфицирует всю область.

    rect

    выделяет прямоугольную область.

    circle

    выделяет круговую область.

    poly

    выделяет область, ограниченную многогранником.

    coords = length-list

    Этот атрибут специфицирует положение и форму области на экране. Число и порядок значений зависит от определенной формы. Возможны комбинации:

    rect:

    левый-х, верхний-у, правый-х, нижний-у.

    circle:

    х центра, у центра, радиус.

    poly:

    х1, у1, х2, у2,.хn, yn.

    Начало координат размещено в верхнем левом углу объекта. Значения координат выражаются в пикселях или в процентах.

    Для элемента object описан также булев атрибут shapes, который определяет то, что объект является картой изображения. Ниже представлен пример с картой изображения клиента.

    <object data=:navbar.gif" shapes>
    <a href="guide.html" shape="rect" coords="0,0,118,28">access guide</a> |
    <a href="shotcut.html" shape="rect" coords="118,0,184,28">go</a> |
    <a href="search.html" shape="circ" coords="184,200,60">search</a> |
    <a href="top10.html" shape="poly" coords="276,0,373,28,50,50,276,0">top ten</a>
    </object>

    Если элемент object содержит атрибут shapes, агент пользователя должен анализировать содержимое элемента с целью поиска якорей. Если две или более областей перекрываются, область, определенная первой, имеет приоритет.

    20.2. Карты изображения клиента с map и area

    Элементы map и area предоставляют альтернативный механизм для карт изображения клиента.

    <!element map - - (area)*>

    <!attrlist map %coreattrs;

    -- id, class, style, title --

    name cdata #implied >

    <!element area - o empty>
    <!attrlist area

    shape %shape rect

    -- контролирует интерпретацию координат --

    coords %coords #implied

    -- список значений, разделенных запятыми --

    href %url #implied

    -- эта область используется как гипертекстная связь --

    target cdata #implied

    -- где отображать подключенный ресурс --

    nohref (nohref) #implied

    -- эта область не вызывает никаких действий --

    alt cdata #implied

    -- описание для исключительно текстовых броузеров --

    tabindex number #implied

    -- position in tabbing order -- >

    Определение атрибута

    nohref

    Этот булев атрибут (если =true) указывает на то, что данная область не имеет никаких связей.

    Несколько элементов (object, img и input) имеют атрибут usemap = URL для спецификации карты изображения клиента описанной элементами map и area.

    Рассмотрим пример, представленный выше, переписанный в терминах MAP и AREA.

    <object data=:navbar1.gif" usemap="#map></object>
    <map name="map1">

    <area href="guide.html"

    alt="search"

    shape="rect"

    coords="184,0,276,28">

    <area href="top10.html"

    alt="top ten"

    shape="poly"

    coords="276,0,373,28,50,50,276,0">

    </map>

    Атрибут alt специфицирует альтернативный текст на случай, когда карта изображения не может быть отображена. map не совместима с версией HTML 2.0.

    Карты изображения сервера

    Карты изображения сервера могут представлять интерес в случае, когда карта изображения слишком сложна для стороны клиента. Такая карта может быть создана с помощью элемента img. Для того чтобы сделать это, нужно установить булев атрибут ismap в описании элемента IMG. Соответствующие области должны быть описаны с помощью атрибута usemap. Когда пользователь активирует область карты изображения, соответствующие координаты посылаются непосредственно серверу, где помещен документ. Координаты на экране выражаются в пикселях. Агент пользователя берет новый URL из URL, описанного атрибутом HREF, присоединив к нему символ "?", за которым следуют координаты х и у, разделенные запятой. Например, в предыдущем примере, если пользователь кликнет в области x=10, y=27, то будет получен URL=/cgibin/navbar.map?10,27.

    В следующем примере первая активная область определяет связь со стороны клиента. Вторая - определяет связь со стороны сервера, но не определяет ее форму и размер (это осуществляется значением по умолчанию атрибута shape). Так как области этих связей перекрываются, первая имеет более высокий приоритет. Таким образом, кликнув мышкой где-либо в прямоугольной области, мы пошлем соответствующие координаты серверу.

    <object data="game.gif" shapes>

    <a href="guide.html" shape="rect" coords="0,0,118,28">

    rules of the game </a>

    <a href=http://www.acme.com/cgi-bin/competition

    ismap

    shape="default">

    guess the location </a>

    </object>

    21. Визуальное представление изображений, объектов и аплетов

    Применение атрибутов элементов img и object для целей управления отображением не рекомендуется, предпочтение, как и раньше здесь отдается стилевым листам. Атрибуты height и width дают агенту пользователя информацию о размере изображения или объекта, что позволяет зарезервировать для него место, а тем временем продолжить отображение документа. Оба атрибута могут иметь значение типа length. Агент пользователя может изменить масштаб, если это необходимо. Атрибуты vspace и hspace специфицируют размер полей вокруг изображения или объекта. Значения по умолчанию этих атрибутов не определено, оно должно быть мало, но не равно нулю.

    22. Как специфицировать альтернативный текст?

    Описание атрибута

    alt = cdata

    Для агента пользователя, который не может отображать изображения, формы или аплеты, этот атрибут позволяет ввести альтернативный текст. Язык этого текста задается атрибутом lang. Атрибут alt является обязательным для элемента area и опционным для img, applet и input.

    23. Стилевые листы

    Стилевые листы являются главным инструментом при разработке дизайна HTML-страниц. Они дают разработчику возможность преобразовать текст в изображение, отображать таблицы, писать программы и делать многое другое. HTML 4.0 поддерживает следующие возможности:

    • Гибкое размещение стилевой информации. Помещение стилевых листов в отдельные файлы упрощает их повторное использование.
    • Независимость от стилевых особенностей используемого языка. Данная спецификация HTML не привязывает его к какому-то определенному языку.
    • Каскадирование стилевых листов. Эта особенность позволяет совместно использовать стилевую информацию из нескольких источников.
    • Зависимость от среды. HTML позволяет описать документ независимым от среды способом, что обеспечивает доступ широкому кругу людей, работающих в различных средах (Windows, X11, Mac, мультимедиа системы и пр.). Стилевые листы позволяют адаптироваться к среде наилучшим образом, используя все предоставляемые ей возможности.
    • Альтернативные стили. Разработчик может предложить пользователю несколько альтернативных стилей представления данных. Например, отображение с мелкими или крупными шрифтами, с или без графических объектов и т.д.

    HTML-документ может содержать стилевые рекомендации внутри, но можно их импортировать и извне. Синтаксис стилевых правил определяется языком стилевых листов CSS (Cascading Style Sheets), который не является частью HTML. Так как агент пользователя должен осуществлять разбор стилевых инструкций, пользователь обязан декларировать, какой стилевой язык он использует. Можно использовать элемент META для установки стилевого языка по умолчанию. Так для установления в качестве стилевого языка по умолчанию CSS, в head документа нужно включить следующую декларацию.

    <meta http-equiv="content-style-type" content="text/css">

    Стилевой язык может быть задан также в http-заголовках. Например:

    content-style-type: text/css

    Если использовано несколько деклараций стилевого языка, работает самая последняя декларация. Если нет явной декларации стилевого языка, по умолчанию устанавливается CSS. HTML-элементы и атрибуты определяют начало стилевого листа. Конец стилевого листа определяется открытым разграничителем конечной метки, за которым следует начальный символ имени SGML [a-za-z]. Агент пользователя должен иметь соответствующий хандлер стилевого листа.

    Одним из строчных стилевых атрибутов является style = Cdata. Этот атрибут специфицирует стилевую информацию для текущего элемента. Ниже приведен пример задания цвета и размера шрифта в тексте параграфа.

    <p type="text/css" style="font-size: 12pt; color: fuschia">aren't style sheet wonderful?

    Декларация типа имя: значение является конструкцией языка CSS. Если стиль планируется использовать повторно в нескольких элементах, более корректным будет применение элемента style, а не атрибута style, который носит одноразовый характер.

    23.1. Стилевая информация заголовка. Элемент style

    <!element style - - cdata -- стилевая информация --
    <!attlist style

    %i18n;

    -- lang, dir, для использования с title --

    type cdata #implied

    -- тип содержимого internet для стилевого языка --

    media cdata #implied

    -- предназначено для использования в этих средах --

    title cdata #implied

    -- рекомендуемый title -- >

    Описание атрибутов

    type = cdata

    Этот атрибут специфицирует язык стилевого листа (заменяет значение по умолчанию). Стилевой язык специфицируется также как и тип среды Интернет (internet media type) (т.е. "text/css").

    media cdata-list

    Этот атрибут специфицирует среду для стилевой информации. Это может быть одна среда или перечень, где отдельные элементы списка разделены запятыми. Возможные типы сред:

    screen:

    Вывод на экран дисплей (без многостраничной поддержки). Значение по умолчанию.

    print:

    Постраничный вывод на непрозрачную бумагу. Предназначен также для вывода на экран в режиме preview.

    projection:

    Вывод на проектор.

    braille:

    Вывод кодов Брайля на тактильное устройство

    speach:

    Вывод на речевой синтезатор.

    all:

    Вывод на все устройства сразу.

    Элемент style позволяет разработчику установить стилевые правила в заголовке документа. HTML допускает любое число элементов style в секции head документа. Агент пользователя, который не поддерживает стилевые листы или специфический стилевой язык, используемый элементом style, должен прятать содержимое элемента style. Управление средой особенно интересно, когда применяются внешние стилевые листы, так как агент пользователя может сэкономить время, копируя через сеть только те стилевые листы, которые используются на данном устройстве вывода.

    Следующая декларация CSS style устанавливает рамку вокруг каждого Н1 элемента в документе и центрирует ее на странице.

    <head>
    <style type="text/css">

    h1 {border-width: 1; border: solid; text-align: center}

    </style>

    </head>

    Для спецификации того, что этот стиль информации должен применяться только для Н1-элементов определенного класса, модифицируем эту запись следующим образом.

    <head>
    <style type="text/css">

    h1.myclass {border-width: 1; border: solid; text-align: center}

    </style>

    </head>
    <body>

    <h1 class="myclass"> this H1 is affected by our style </h1>

    <h1 this one is not affected by our style </h1>

    </body>

    И наконец, для того чтобы ограничить зону действия стилевой информации одним случаем Н1, установим атрибут ID.

    <head>

    <style type="text/css">

    h1.myid {border-width: 1; border: solid; text-align: center}

    </style>

    </head>
    <body>

    <H1 class="myclass"> this H1 is not affected </h1>

    <H1 this one is affected by style </H1>

    <H1> this h1 is not affected </H1>

    </body>

    В следующем примере использован элемент span для определения шрифтового стиля первых нескольких слов.

    <head>

    <style type="text/css">

    span.sc-ex { font-variant: small-caps }

    </style>

    </head>
    <body>

    <p><span id="sc-ex"> the first</span> few words of

    this paragraph are in small-caps

    </body>

    В следующем примере используется div и атрибут class для выравнивания последовательности параграфов. Эта стилевая информация может быть использована повторно, например, для форматирования резюме научных статей путем установки атрибута class в соответствующем месте документа.

    <head>

    <style type="text/css">

    div.abstact {text-align: justify }

    </style>

    </head>
    <body>

    <div class="abstract">

    <p>the chieftain product range is our market winner for the coming year.

    this report sets out how to position chieftain against competing products.

    <p>chieftain replaces the commander range, which will remain on the

    price list until further notice.

    </div>
    </body>

    23.2. Типы среды

    HTML позволяет разработчику конструировать документы, структура которых не зависит от специфических свойств среды. В результате пользователь может просматривать этот документ с использованием самых разных агентов пользователя: на персональной ЭВМ, рабочей станции, Х-терминале, специально приспособленном телефонном аппарате и т.д..

    Атрибут media специфицирует среду вывода для формирования стилевых правил. Установив атрибут media, разработчик может позволить агенту пользователя избежать копирования через сеть стилевых листов, не используемых в данном документе. Ниже предлагается пример деклараций для элемента Н1. При отображении на экране текст будет голубым и выровненным по центру, при печати текст будет выровнен по центру. Предусмотрена возможность вывода и на речевой синтезатор.

    <head>

    <style type="text/css" media="screen">

    h1 { color: blue }

    </style>

    <style type="text/css" media="screen, print">
    h1 { text-align: center }
    </style>
    <style type="text/acss" media="speach">
    h1 { cue-before: url(bell.aiff); cue-after: url(dong.wav)}
    </style>
    </head>

    Предыдущий пример может быть переписан для случая применения внешних стилевых листов (вместо элемента style) в сочетании с атрибутом media. Агент пользователя на основе атрибута media принимает решение о копировании из сети тех или иных стилевых листов.

    <head>
    <link href="docl-screen.css" rel="stylesheet"

    type="text/css" media="screen">

    <link href="docl-print.css" rel="stylesheet"

    type="text/css" media="print">

    <link href="docl-speach.css" rel="stylesheet"

    type="text/css" media="speach">

    </head>

    23.3. Внешние стилевые листы

    Стилевые листы могут быть определены отдельно от документа. Это позволяет использовать такие стилевые листы во многих документах. Кроме того, стиль может быть изменен без модификации самого документа. Любой стиль обычно представляет собой иерархию стилевых листов. Некоторые из них используются вне зависимости от выбора пользователя. Для выбора внешних стилевых листов используется элемент Link. При этом необходимо установить следующие атрибуты:

    href

    для определения места размещения внешнего стилевого файла (href=url).

    rel

    определяет, является ли данный стилевой лист постоянным (rel="stylesheet"), стилевым листом по умолчанию (rel="stylesheet") или листом по выбору (rel="alternate stylesheet").

    title

    устанавливает заголовок в случае, когда стилевой лист является листом по умолчанию (активируется и деактивируется пользователем).

    Сначала специфицируются постоянные (persistent) внешние стилевые листы (например, из файла mystyle.css).

    <link href="mystyle/css" rel="stylesheet">

    Установка атрибута title превращает постоянный стилевой лист в лист по умолчанию. Агенты пользователя должны предоставлять возможность применения именованных стилей на базе атрибута title.

    <link href="mystyle/css" title="compact" rel="stylesheet">

    Добавление ключевого слова "alternate" к атрибуту rel делает стилевой лист альтернативным.

    <link href="mystyle/css" title="medium" rel="alternate stylesheet">

    Все альтернативные стили, имеющие один и тот же заголовок (title), будут использоваться, когда пользователь (через агента пользователя) активирует этот стиль. Стилевые листы с разными заголовками в этом случае не будут применены. Однако, стилевые листы, которые не имеют атрибута title, применяются всегда (за исключением случая, когда пользователь отключает все стилевые листы).

    Агент пользователя должен обеспечить средства выбора стилей для пользователей. Значение атрибута title предоставляет имя, которое может использоваться при выборе стиля. В предлагаемом примере определено два альтернативных стиля, названных "compact". Если пользователь выберет стиль "compact", будут применены оба внешних стилевых листа, а также стилевой лист "common.css" (применяется всегда, так как атрибут title не установлен). Если пользователь выберет стиль "big print", агент пользователя применит файлы "bigprint.css" и "common.css".

    <link rel="alternate stylesheet" title="compact" href="small-base.css">
    <link rel="alternate stylesheet" title="compact" href="small-extras.css">
    <link rel="alternate stylesheet" title="big- print" href="bigprint.css">
    <link rel=stylesheet href="common.css">

    Ниже предлагается вариант с элементами link и style.

    <link rel=stylesheet href="corporate.css">
    <link rel=stylesheet href="techreport.css">
    <style type="text/css">

    p.special { color: rgb(230, 100, 180) }

    </style>

    23.4. Установка именованного стиля по умолчанию

    Для установки в документе именованного стиля по умолчанию используется элемент meta. Например (установка стилевого листа "compact" в качестве стиля по умолчанию):

    <meta http-equiv="default-style" content="compact"

    Стилевой лист по умолчанию может быть установлен в HTML-заголовке.

    default-style: "compact"

    Если имеется две или более деклараций стилевого листа по умолчанию, то работает последняя декларация. Если явной декларации стиля по умолчанию нет, то берется первый элемент link, где есть title и где имеется атрибут rel="stylesheet".

    При отображении документа с использованием стилевых листов выполняются определенные правила наследования свойств (тип шрифта, цвет и т.д.). Если то или иное свойство не может быть наследовано, используется значение по умолчанию.

    Некоторые стилевые языки поддерживают синтаксис, который позволяет разработчику спрятать содержимое элементов style от агентов пользователя, которые их не поддерживают, с тем, чтобы они не пытались отобразить эти фрагменты, как текст. Например (случай с CSS):

    <style type="text/css">
    <!-- h1 { color: red }
    p { color: blue} -->
    </style

    Иногда бывает удобно, конфигурируя WEB-сервер, установить стилевые листы, которые воздействуют на группу WWW-страниц. HTTP Link-заголовок имеет то же воздействие, что и элемент Link с теми же атрибутами и значениями. Заголовки с несколькими Link работают также как и несколько элементов Link, в соответствии с их порядком записи.

    link: rel=stylesheet href="corporate.css"

    cоответствует

    <link rel="stylesheet" href="corporate.css">

    Можно описать несколько альтернативных стилей, используя несколько Link-заголовков, а затем с помощью атрибута Rel определить стиль по умолчанию.

    link: rel="stylesheet" title="compact" href="compact.css"
    link: rel="alrernate stylesheet" title="big print" href="bigprint.css"

    23.5. Форматирование

    Для задания цвета фона может использоваться атрибут bgcolor = color (хотя это и не рекомендуется). Применение стилевых листов для решения этой задачи предпочтительнее.

    Другой проблемой форматирования является выравнивание текста. Для этой цели служит атрибут Align = left|center|right|justify. Здесь справедливы те же замечания, что и в случае атрибута bgcolor. Ниже предлагается пример решения задачи выравнивания с использованием стилевого листа.

    <head>
    <style>
    h1 { test-align: center }
    </style>
    </head>
    <h1> how to carve wood </h1>

    Следует иметь в виду, что приведенный текст отцентрирует все заголовки Н1. Можно ограничить зону действия данного стиля, установив атрибут ID.

    <head>
    <style type="text/css">
    h1.wood {text-align: center}
    </style>
    </head>
    <h1 id="wood"> how to carve wood </h1>

    Аналогично для выравнивания по правому и левому полям с использование атрибута align:

    <p align="justify"> ..далее следует текст..

    То же с использованием стилевого листа:

    <head>
    <style type="text/css">
    p.mypar {text-align: justify}
    </style>
    </head>
    <p id="mypar"> ..далее следует текст..

    Для двойного выравнивания последовательности параграфов можно группировать их с помощью элемента div.

    <div align="justify">
    <p> . текст первого параграфа..
    <p> . текст второго параграфа..
    <p> . текст третьего параграфа..
    </div>

    Решение той же задачи с использованием каскадирования стилевых листов:

    <head>
    <style type="text/css">
    div.mypars {text-align: justify}
    </style>
    </head>
    <div id="mypars">
    <p> . текст первого параграфа..
    <p> . текст второго параграфа..
    <p> . текст третьего параграфа..
    </div>

    Для выравнивания всего документа с использованием каскадирования стилевых листов можно записать:

    <head>
    <style type="text/css">
    body {text-align: justify}
    </style>
    </head>
    <body>
    . текст документа, подлежащий выравниванию .
    </body>

    Элемент center работает также как и элемент div с атрибутом align="center". Использование center не рекомендуется.

    23.6. Плавающие объекты

    Изображения и объекты могут быть привязаны к тексту, а могут обтекаться текстом, прижимаясь к одной из сторон документа и деформируя его поля. Плавающие объекты начинаются с новой строки. Для управления положением плавающего объекта используется атрибут align. Например:

    <img align="left" src=http://foo.com/animage.gif>

    Существует атрибут для элемента br, который управляет обтеканием объекта текстом. Это clear= none|left|right|all, который определяет то, где должна появиться следующая строка в процессе отображения.

    none

    следующая строка будет отображена как обычно (значение по умолчанию).

    left

    следующая строка будет помещена ниже плавающего объекта на левом поле.

    right

    следующая строка будет помещена ниже плавающего объекта на правом поле.

    all

    следующая строка будет помещена ниже плавающего объекта на любом из доступных полей.

    Рассмотрим вариант, когда текст размещается справа от изображения, и посмотрим, что будет после прерывания строки с помощью BR.

    Если атрибут clear="none", следующая строка начнется сразу под уже имеющимся текстом.

    Если же clear = "left" или all, то мы получим:

    Используя стилевые листы, мы можем потребовать, чтобы все разрывы строк обрабатывались аналогичным образом. Для реализации этого можно записать:

    <style type="text/css">
    br { clear: left }
    </style>

    Для того чтобы такая схема размещения текста сработала только раз, следует воспользоваться атрибутом ID.

    <head>
    ...
    <style type="text/css">
    br.mybr }clear: left}
    </style>
    </head>
    <body>
    ...
    ....
    </body>

    23.7. Элементы управления шрифтами: tt, i, b, big, small, strike, s и u

    <!entity % font
    "tt | i | b | u | s | strike | big | small ">
    <!element (%font|%phrase) - - (%inline)*>
    <!attlist (%font|%phrase) %attrs; -- %coreattrs, %i18n, %events -- >

    tt:

    соответствует шрифту телетайпа (символы равной ширины).

    i:

    курсив

    b:

    полужирный шрифт.

    big:

    шрифт с крупными буквами.

    small:

    мелкий шрифт.

    strike:

    перечеркнутый шрифт (к использованию не рекомендуется)

    u:

    подчеркнутый шрифт (к использованию не рекомендуется)

    Ниже приведены примеры управления шрифтами.

    <b>bold</b>
    <i>italic</i>, <b><i>bold italic</i></b>, <tt>teletype text</tt>
    <big>big</big> <small> small </small> text.

    Броузер отобразит при этом на экране:

    bold, italic, bold italic , teletype text, big, small text.

    Использование стилевых листов позволяет получить значительно большее многообразие шрифтов. Например, нижеприведенный текст даст распечатку голубым курсивом:

    <head>
    <style>
    p.mypar {font-style: italic; color: blue}
    </style>
    </head>

    <p id="mypar"> . далее следует текст, печатаемый голубыми буквами курсивом.

    23.8. Элементы модификаторов шрифтов: font и basefont

    <!element font - - (%inline)* -- локальное изменение шрифта -->
    <!attlist font

    size cdata #implied

    -- [+]nn напр. size="+1", size=4 --

    color cdata #implied

    -- #rgbgbb in hex, напр. red: "#ff0000" --

    face cdata #implied

    -- список имен шрифтов, разделенных запятыми -- >

    <!element basefont - o empty>
    <!attlist basefont

    size cdata #required

    -- базовый размер шрифта для элементов font --

    color cdata #implied

    -- #rgbgbb in hex, напр. red: "#ff0000" --

    face cdata #implied

    -- список имен шрифтов, разделенных запятыми -- >

    С этими элементами могут использоваться атрибуты (все они не рекомендуются к использованию):

    size = cdata

    Атрибут определяет размер шрифта (1-7).

    color = color

    Атрибут определяет цвет шрифта.

    face = cdata-list

    Атрибут определяет список шрифтов, которые агент пользователя должен рассматривать в порядке приоритета.

    Элемент font изменяет размер и цвет шрифта для текста, в нем содержащегося. Элемент basefont устанавливает базовый размер шрифта (с помощью атрибута size). Размер шрифта, заданного font является относительным по отношению к размеру, определенному basefont. Если basefont не задан, значением по умолчанию считается 4. Ниже приведены примеры задания шрифтов с помощью font (данная форма определения размера шрифта не рекомендуется).

    <p> <font size=1> size=1</font>
    <font size=2> size=2</font>
    <font size=3> size=3</font>
    <font size=4> size=4</font>
    <font size=5> size=5</font>
    <font size=6> size=6</font>
    <font size=7> size=7</font>

    Агент пользователя при этом отобразит следующее

    size=1 size=2 size=3 size=4 size=5 size=6 size=7

    23.9. Элемент hr

    <!element hr - o empty>

    <!attlist hr %coreattrs;

    -- id, class, style, title --

    %events;

    align (left|right|center) #implied

    noshade (noshade) #implied

    size %pixels #implied

    width %length #implied >

    Определение атрибутов

    noshade

    Этот булев атрибут требует, чтобы агент пользователя пользовался одноцветным способом отображения линии.

    size = length

    (Не рекомендуется) Этот атрибут определяет высоту линии.

    width = length

    (Не рекомендуется) Этот атрибут определяет ширину линии (по умолчанию 100%), то есть линия пресекает весь экран.

    Пример использования элемента hr.

    <hr width="50%" align="center">
    <hr size="5" width="50%" align="center">
    <hr noshade size="5" width="50%" align="center">

    24. Рамки (frames)

    Обычный документ имеет одну секцию заголовка и одну секцию тела документа. Документ с рамками имеет заголовок (head), frameset (набор рамок) и, опционно, тело документа. Секция frameset специфицирует раскладку объектов в основном окне агента пользователя. Секция body предлагает альтернативу для случая агентов пользователя, которые не поддерживают frameset.

    24.1. Элемент frameset

    <!element frameset - - ((frameset|frame) + & noframes?)>
    <!attlist frameset

    -- абсолютные значения в пикселях, проценты или относительные значения --

    rows cdata #implied

    -- если не задано, по умолчанию rows=1 --

    cols cdata #implied

    -- если не задано, по умолчанию cols=1 --

    onload %script #implied

    -- все рамки загружены --

    onunload %script #implied

    -- все рамки удалены -- >

    Определения атрибутов

    rows = length-list

    Этот атрибут специфицирует выкладку горизонтальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%.

    cols = length-list

    Этот атрибут специфицирует выкладку вертикальных рамок. Значение представляет собой список длин, разделенных запятыми. Если атрибут не задан, значение по умолчанию равно 100%.

    Все рамки предполагаются прямоугольными. Установка атрибута rows определяет число рамок по горизонтали, а атрибут cols задает число рамок по вертикали. Таким образом, задается сетка рамок. Если атрибут rows не задан, каждая колонка занимает всю длину страницы. Если атрибут cols не задан, каждый ряд занимает всю ширину страницы. Если не заданы оба атрибута, на странице присутствует одна рамка, занимающая всю страницу.

    Размер может задаваться в пикселях (абсолютно), в процентах от размеров экрана или в относительных длинах в форме i*, где i - целое число. Когда заданы оба атрибута, агент пользователя сначала выделяет размеры, заданные абсолютно, затем оставшуюся часть делит в соответствии с определенными долями. Значение * эквивалентно 1*. Отображение страницы осуществляется слева направо и сверху вниз. Пример (экран делится на две равные части, верхнюю и нижнюю):

    <frameset rows="50%, 50%">
    . остальная часть определения .
    </frameset>

    В следующем примере создается три колонки: вторая имеет фиксированную ширину в 250 пикселей (что удобно для картинки известного размера). Первая получает 25% оставшегося пространства, а третья - 75%.

    <frameset cols="1*,250,3*">
    . остальная часть определения .
    </frameset>

    В следующем примере создается решетка 2х3

    <frameset rows="30%,70%" cols="33%,34%,33%">
    . остальная часть определения .
    </frameset>

    В следующем примере предполагается, что высота окна равна 1000 пикселей. Для первой рамки выделяется 30% общей высоты (300 пикселей). Для второй рамки выделено точно 400 пикселей. Это оставляет 300 пикселей на две оставшиеся рамки. Высота четвертой рамки определена как "2*", а третей - *, следовательно, третья получит 100, а четвертая - 200 пикселей.

    <frameset rows="30%,400,*,2*" >
    . остальная часть определения .
    </frameset>

    Если при задании абсолютных размеров остается свободное место, или возникает перерасход пространства, агент пользователя пропорционально увеличит или уменьшит размеры рамок. frameset могут вкладываться друг в друга на любом уровне. В приведенном примере внешний frameset делит имеющееся пространство на три равные колонки. Внутренний frameset делит вторую область на два ряда не равной высоты.

    <frameset rows="33%,33%,34%" >
    .содержимое первой рамки.

    <frameset rows="40%,50%" >

    .содержимое второй рамки первого ряда.

    .содержимое второй рамки второго ряда.

    </frameset>

    .содержимое третей рамки.

    </frameset>

    24.2. Элемент frame

    <!element frame - o empty>
    <!attlist frame

    name cdata #implied

    -- имя рамки --

    src %url #implied

    -- источник содержимого рамки --

    frameborder (1|0) 1

    -- request frame border? --

    marginwidth %pixels #implied

    -- ширина полей в пикселях --

    marginheight %pixels #implied

    -- высота полей в пикселях --

    noresize (noresize) #implied

    -- позволить пользователям изменять размеры рамок? --

    scrolling (yes/no/auto) auto

    -- делать полосу прокрутки или нет? -- >

    Определения атрибутов

    name = cdata

    Атрибут присваивает имя текущей рамке. К этому имени можно адресоваться.

    src = url

    Этот атрибут специфицирует положение исходного документа, содержимое которого заключено в рамку.

    noresize

    Этот булев атрибут говорит агенту пользователя, что размер окна рамки не может быть изменен.

    scrolling = auto|yes|no

    Этот атрибут специфицирует информацию о возможности прокрутки информации в данной рамке. Возможные значения:

    auto:

    говорит агенту пользователя, что он может организовывать скроллинг по своему усмотрению (значение по умолчанию)

    yes:

    говорит агенту пользователя, что он должен обеспечить скроллинг информации в окне.

    no:

    говорит агенту пользователя, что скроллинг делать не нужно.

    frameborder=1|0

    Этот атрибут предоставляет агенту пользователя информацию о рамке вокруг текущего окошка. 1 означает, что агент пользователя должен прочертить границу вокруг текущей рамки (значение по умолчанию). 0 означает, что агент пользователя не должен прочерчивать границу вокруг текущей рамки.

    marginwidth = length

    Этот атрибут специфицирует правое и левое поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя.

    marginheight = length

    Этот атрибут специфицирует размер верхнего и нижнего поля между текстом и границей рамки. Значение должно быть больше одного пикселя. Значение по умолчанию определяет агент пользователя.

    Атрибут SRC определяет источник текста, помещаемого в рамку. Содержимое рамки не может быть записано в том же документе, в котором описана сама рамка. Пример:

    <html>
    <frameset cols="33%, 33%, 33%">

    <frameset rows="*,200">

    <frame src="contents_of_frame1.html">

    <frame src="contents_of_frame2.gif">

    </frameset>

    <frame> src="contents_of_frame3.html">

    <frame> src="contents_of_frame4.html">

    </frameset>
    </html>

    В результате будет получена раскладка рамок, показанная ниже не рисунке.

    Ниже приведенный пример содержит в себе ошибку, так как текст второй рамки включен в описание самой рамки.

    <html>
    <frameset cols="50%,50%">

    <frame src="contents_of_frame1.html">

    <frame src="#anchor_in_same_document">

    </frameset>
    <body>

    . некоторый текст.
    <h2><a name="anchor_in_same_document">important section</a></h2>
    . некоторый текст.
    </body>
    </html>

    Существует атрибут target = cdata, который специфицирует имя рамки, где должна быть размещена информация. Путем присвоения с помощью атрибута name имени рамке разработчик может ссылаться на нее, как на адрес связей. Атрибут target может быть установлен для элементов, создающих связи (А, link), карты изображения (area) и формы (form). Ниже предлагается пример, где target позволяет динамически изменять содержимое рамки:

    <html>
    <frameset rows="50%,50%">

    <frame name="fixed" src="init_fixed.html">

    <frame name="dynamic" src="init_dynamic.html">

    </frameset>
    </html>

    Затем в init_dynamic.html мы организуем связь с рамкой под именем "dynamic"

    <html>
    <body >
    . начало документа .
    now you may advance to

    <a href="slide2.html" target="dynamic">slide 2.</a>

    . продолжение документа .
    you're doing great. now on to

    <a href="slide3.html" target="dynamic">slide 3.</a>

    </body>
    </html>

    Активирование любой связи приводит к открытию документа в рамке с именем "dynamic", в то время как другие рамки ("fixed") остаются со своим исходным содержимым.

    24.3. Установка для связей адресов по умолчания

    Когда многие связи в документе указывают на один и тот же адрес, имеется возможность специфицировать адрес только один раз, а ссылки обеспечить путем введения атрибута target в нужные элементы. Это делается путем установки атрибута target элемента base. Рассмотрим предыдущий пример с этой точки зрения.

    <html>
    <head>
    <base target="dynamic">
    </head>
    <body>
    . начало документа .

    now you may advance to <a href="slide2.html">slide 2.</a>
    . продолжение документа .
    you're doing great. now on to
    <a href="slide3.html">slide 3.</a>
    </head>
    </html>

    Существует несколько методов сделать рамку адресом связи.

    1. Если элемент имеет атрибут target, указывающий на известную рамку, тогда при активации элемента, документ связанный с этим элементом, будет загружен в данную рамку.
    2. Если элемент не имеет атрибута target и имеет элемент base, тогда именно base определяет рамку, куда будет произведена загрузка.
    3. Если элемент и base не имеют атрибута target, документ, соответствующий элементу, будет загружен в рамку, содержащую этот элемент.
    4. Если любой адрес (target) указывает на рамку f, агент пользователя создаст новое окно и рамку, припишет имя f этой рамке и загрузит документ, соответствующий элементу, в эту новую рамку.

    Имя рамки должно начинаться с буквы (a-za-z). Агент пользователя должен игнорировать любые другие имена. Существует несколько имен, зарезервированных для специальных целей.

    _blank

    агент пользователя должен загрузить документ в новую безымянную рамку.

    _self

    агент пользователя должен загрузить документ в ту же рамку, что и элемент, который ссылается на этот адрес (target).

    _parent

    агент пользователя должен загрузить документ в frameset, породивший текущую рамку. Это значение эквивалентно _self, если текущая рамка не имеет прародителя.

    _top

    агент пользователя должен загрузить документ в полное исходное окно. Значение эквивалентно _self, если текущее окно не имеет прародителя.

    Агенты пользователя, которые не поддерживают рамки, должны отображать секцию body, которая следует за самым внешним frameset документа. Агенты пользователя, которые поддерживают рамки, должны игнорировать эту секцию body.

    24.4. Элемент noframes

    <!element noframes - - (#pcdata, ((body,#pcdata)|

    (((%blocklevel)|%font|%phrase|%special|%formctrl),%block)))>

    Элемент noframes специфицирует содержимое, которое должно быть отображено, только когда не отображаются рамки. Агенты пользователя могут отображать содержимое только в случае, когда они сконфигурированы с блокировкой поддержки рамок.

    Предположим, что имеется frameset, определенный в "top.html", который отображает документ "main.html", и оглавление этого документа ("table_of_contents.html"). Тогда содержимое "top.html":

    <html>
    <frameset cols="50%,50%">

    <frame src="main.html">

    <frame src="table_of_contents.html">

    </frameset>
    </html>

    Когда пользователь читает "top.html", а агент пользователя не поддерживает работу с рамками, на экране ничего не появится, если в секции body ("top.html") нет альтернативного текста. Если мы введем "table_of_contents.html" и "main.html" непосредственно в body, задача ассоциации документов будет решена. Но при этом мы можем заставить агента пользователя, который поддерживает рамки, скопировать один и тот же документ дважды. Более экономно включить оглавление в начало "main.html", в элемент noframes:

    <html>
    <body>
    <noframes>
    . оглавление .
    </noframes>
    . остальная часть документа .
    </body>
    </html>

    Элемент noframes может использоваться в frameset-секции документа. Например:

    <!doctype html public "-//w3c//dtd HTML 4.0 frameset//en"
    "http://www.w3.org/tr/rec-html40">
    <html>
    <head>
    <title>a frameset document with noframes</title>
    </head>
    <frameset cols="50%, 50%">
    <frame src="main.html">
    <frame src="table_of_contents.html">
    <noframes>
    <p>here is the <a href="main-noframes.html">
    версия документа non-frame.</a>
    </noframes>
    </frameset>
    </html>

    24.5. Элемент iframe

    <!element iframe - - (%flow;)* -- субокно в блоке текста -->
    <!attlist iframe
    %coreattrs; -- id, class, style, title --
    longdesc %uri; #implied -- указатель на более длинное описание (дополнение к title) --
    name cdata #implied -- имя файла для адресации --
    src %uri; #implied -- источник содержимого рамки --
    frameborder (1|0) 1 -- request frame borders? --
    marginwidth %pixels; #implied -- ширина поля в пикселях --
    marginheight %pixels; #implied -- высота поля в пикселях --
    scrolling (yes|no|auto) auto -- наличие поля прокрутки --
    align %ialign; #implied -- вертикальное и горизонтальное выравнивание --
    height %length; #implied -- высота рамки --
    width %length; #implied -- ширина рамки -- >

    Описание атрибутов

    longdesc = uri

    Этот атрибут специфицирует связь с длинным описанием рамки. Это описание должно быть дополнением короткого описания, данного в атрибуте title.

    name = cdata

    Этот атрибут присваивает имя текущей рамке. Это имя может использоваться в последующих ссылках.

    width = length

    Ширина рамки.

    height = length

    Высота рамки.

    Элемент Iframe позволяет разработчику ввести рамку в блок текста. Эта процедура схожа с введением одного HTML-документа в другой с помощью элемента object. Информация, которая должна быть введена, определяется атрибутом src этого элемента. Содержимое элемента Iframe отображается только агентами пользователя, которые не поддерживают рамки. Пример, когда рамка вводится внутрь текста, приведен ниже.

    <iframe src="foo.html" width="400" height="500"
    scrolling="auto" frameborder="1">
    [Ваш агент пользователя не поддерживает рамки или сконфигурирован без поддержки рамок]. Кликните для извлечения <a href="foo.html"> сопряженного документа. </a>]
    </iframe>

    Размеры этих рамок не могут быть изменены.

    25. Формы

    HTML-форма представляет собой часть документа, содержащая обычный текст, разметку (markup) и специальные элементы управления, называемые controls. controls служат для приема и обработки текста, вводимого пользователем. Форма - это аналог стандартного бланка, заполняемого пользователем. Заполненная форма может быть послана по почте другому пользователю, или передана программе для последующей обработки. Каждый control (графа бланка) должен иметь имя, а его значение определяется его типом. Ниже приведен пример формы, где используются метки и различного типа кнопки:

    <form action="http://somesite.com/prog/adduser" method="post">
    <p>
    <label for="firstname">first name: </label>
    <input type="text" id="firstname"><br>
    <label for="lastname">last name: </label>
    <input type="text" id="lastname"><br>
    <label for="email">email: </label>
    <input type="text" id="email"><br>
    <input type="radio" name="sex" value="male"> male<br>
    <input type="radio" name="sex" value="female"> female<br>
    <input type="submit" value="send"> <input type="reset">
    </p>
    </form>

    Каждый control имеет исходное и текущее значение, каждое из которых представляет собой символьную строку. Исходное значение может быть определено с помощью соответствующего атрибута.

    Кнопки

    Разработчики могут создавать три типа кнопок:

    • submit-кнопки. При активации эти кнопки преадресуют форму адресату. Форма может содержать более одной submit-кнопки.
    • Кнопки сброса: При активации эти кнопки возвращают все controls в исходное состояние.
    • Кнопки нажатия. Эти кнопки не имеют какого-либо фиксированного назначения. Каждой такой кнопке может быть поставлен в соответствие, например, скрипт клиента.

    Разработчик создает кнопку с помощью элемента button или input. Следует иметь в виду, что элемент button предоставляет более широкие возможности, чем input.

    Переключатели

    Переключатели (chekbox; и радио-кнопки) представляют собой двухпозиционные приборы, которые могут находиться в состоянии on/off (вкл/выкл). Пользователь может переводить этот переключатель из одного состояния в другое. Переключатель находится в состоянии "on", когда установлен соответствующий атрибут управляющего элемента.

    Несколько переключателей могут относиться к одному и тому же control, позволяя, например, выбрать одно из нескольких значений определенного параметра. Для формирования переключателя используется элемент input.

    Радио-кнопки

    Радио-кнопки схожи с переключателями. Но здесь при наличии нескольких кнопок, относящихся к одному имени control, перевод одной кнопки в состояние "on" переводит все другие кнопки с тем же именем в состояние "off". Для создания радио-кнопок используется элемент input.

    Меню

    Меню предоставляет пользователю выбор из нескольких возможностей. Для формирования меню используется элемент select, в сочетании с элементами optgroup и option.

    Ввод текста

    Разработчик может создать два типа controls, которые позволяют вводить текст. Элемент input создает однострочный control для ввода, а textarea предназначен для многострочного ввода. В обоих случаях введенный текст становится текущим значением control.

    Выбор файла

    Этот тип control позволяет пользователю выбрать файлы, так что их содержимое будет введено в форму. Для обеспечения выбора файла используется элемент input.

    Скрытые элементы управления control

    Разработчик может создать control, которые не отображаются на экране, но величины которых заносятся в форму. Для формирования скрытого control используется элемент input.

    Объектные control

    Разработчик может ввести в форму общие объекты, так что соответствующие величины будут заноситься в форму. Для работы с объектными control используется элемент object.

    Элементы, используемые для создания controls, обычно вводятся в элемент FORM, но могут появляться и вне декларации FORM, когда они используются для построения интерфейса пользователя.

    25.1. Элемент FORM

    <!element form - - (%block;|script)+ -(form) -- интерактивная форма -->
    <!attlist form %attrs; -- %coreattrs, %i18n, %events --
    action %uri; #required -- хандлер форм со стороны сервера --
    method (get|post) get -- http метод для ввода форм --
    enctype %contenttype; "application/x-www-form-urlencoded"
    onsubmit %script; #implied -- форма введена --
    onreset %script; #implied -- форма возвращена в исходное состояние --
    accept-charset %charsets; #implied -- список поддерживаемых символьных наборов -->

    Определение атрибутов

    action = url

    Этот атрибут специфицирует агента, который осуществляет обработку формы. Например, возможным значением атрибута может быть HTTP URI (для передачи формы программе) или mailto URI (для пересылки формы по электронной почте).

    method = get|post

    Этот атрибут специфицирует http-метод, который будет использоваться для представления данных. Возможные значения: "get" (по умолчанию) и "post". Метод post вводит пары имя/значение в тело формы.

    enctype = content-type

    Этот атрибут специфицирует тип содержимого (internet media type), используемого при передаче формы серверу (когда метод = "post"). Значение по умолчанию атрибута равно "application/x-www-form-urlencoded". Значение "multipart/form-data" должно использоваться в сочетании с type="file" элемента input.

    accept-charset = charset list

    Этот атрибут специфицирует список кодировок символов для входных данных, которые должны быть приняты сервером, обрабатывающим эти формы. Значения атрибута представляют собой список значений символьных комбинаций, разделенных пробелами или запятыми. Сервер должен интерпретировать этот список и воспринимать любой односимвольный код. Значение этого атрибута по умолчанию равно "unknown". Агент пользователя может интерпретировать это значение как символьную комбинацию, которая была использована для передачи документа, содержащего этот элемент form.

    accept = content-type-list

    Этот атрибут специфицирует список типов содержимого (в качестве разделителей используются занятые), которые сможет корректно воспринять и обработать сервер форм.

    Элемент form работает как контейнер для controls. Он специфицирует:

    • Выкладку формы (заданную содержимым элемента).
    • Программу, которая будет обрабатывать заполненную форму (атрибут action). Принимающая программа должна быть способна разобрать пары имя/значение, для того чтобы использовать их.
    • Метод, посредством которого данные пользователя будут посланы серверу (атрибут method).
    • Кодировку символов, которая должна быть воспринята сервером, для того чтобы успешно произвести последующую обработку полученной формы (атрибут accept-charset). Агенты пользователя могут подсказать пользователю значения атрибута accept-charset и/или ограничить возможность ввода неузнаваемых символов.

    Ниже приведен пример, который показывает форму, которая должна быть обработана программой "adduser". Форма посылается программе с помощью метода http "post".

    <form action="http://somesite.com/prog/adduser" method="post">
    ...form contents...
    </form>

    Следующий пример показывает, как послать форму по заданному электронному адресу:

    <form action="mailto:kligor.t@gee.whiz.com" method="post">
    ...содержимое формы...
    </form>

    25.2. Элемент input

    <!entity % inputtype
    "(text | password | checkbox | radio | submit | reset |
    file | hidden | image | button)" >
    <!-- имя атрибута необходимо для всех кроме submit & reset -->

    <!element input - o empty -- управление формой -->
    <!attlist input %attrs; -- %coreattrs, %i18n, %events --
    type %inputtype; text -- what kind of widget is needed --
    name cdata #implied -- представить как часть формы --
    value cdata #implied -- необходимо для радио-кнопок и переключателей --
    checked (checked) #implied -- для радио-кнопок и переключателей --
    disabled (disabled) #implied -- не доступно в данном контексте --
    readonly (readonly) #implied -- для текста и пароля --
    size cdata #implied -- разный для каждого типа полей --
    maxlength number #implied -- макс. число символов для текст. полей --
    src %uri; #implied -- для полей с изображением --
    alt cdata #implied -- краткое описание --
    usemap %uri; #implied -- использование карты изображения клиента --
    tabindex number #implied -- position in tabbing order --
    accesskey %character; #implied -- клавиша доступа --
    onfocus %script; #implied -- элемент выделен --
    onblur %script; #implied -- элемент не выделен --
    onselect %script; #implied -- некоторый текст был выбран --
    onchange %script; #implied -- значение элемента изменилось --
    accept %contenttypes; #implied -- list of mime types for file upload -->

    Определение атрибутов
    type = text|password|checkbox|radio|submit|reset|file|hidden|image|button

    Этот атрибут специфицирует тип создаваемого control. Значение по умолчанию "text".
    name = cdata

    Этот атрибут присваивает имя control.
    value = cdata

    Этот атрибут специфицирует начальное значение control.
    size = cdata

    Этот атрибут сообщает агенту пользователя исходную ширину control. Ширина задается в пикселях, за исключением случая, когда тип атрибута "text" или "password". В этом варианте ширина измеряется числом символов.

    maxlength = number

    Когда тип атрибута "text" или "password", этот атрибут специфицирует максимальное число символов, которое предлагается ввести пользователю. Это число может превзойти указанный размер, тогда агент пользователя должен предложить механизм скроллинга.

    checked.

    Когда тип атрибута "radio" или "checkbox", этот булев атрибут указывает, что кнопка нажата. Агент пользователя должен игнорировать этот атрибут для всех других видов control.

    src = url

    Когда тип атрибута "image", этот атрибут специфицирует положение изображения, которое будет использовано для украшения кнопки.

    Атрибут type элемента input определяет то, какой управляющий элемент создан.

    text

    Этот тип создает текстовый бокс на одну строчку. Значение текстового control равно введенному тексту.

    password

    Подобен типу "text", но отображение ввода делается так, что вводимые символы не видны (напр. каждому введенному символу ставится в соответствие *). Значение данного типа control равно введенному тексту. Служит для ввода паролей.

    checkbox

    Представляет собой двух позиционный переключатель (вкл/выкл=on/off). Когда переключатель в положении on, значение checkbox = "active". Состояние переключателя передается только в случае, когда переключатель в состоянии on.

    Нижеследующий фрагмент HTML представляет собой пример простой формы, которая позволяет пользователю ввести свою фамилию имя, электронный адрес и т.д.

    <form action="http://somesite.com/prog/adduser" method="post">
    <p>
    first name: <input type="text" name="firstname"><br>
    last name: <input type="text" name="lastname"><br>
    email: <input type="text" name="email"><br>
    <input type="radio" name="sex" value="male"> male<br>
    <input type="radio" name="sex" value="female"> female<br>
    <input type="submit" value="send"> <input type="reset">
    </p>
    </form>

    radio

    также является двухпозиционным переключателем. Единственным отличием от checkbox является то, что при наличии нескольких радио-кнопок с идентичным именем в состоянии on может быть всегда только одна.

    submit

    формирует кнопку submit. При активации этой кнопки пользователем, форма передается по адресу, указанному атрибутом action элемента form. Форма может содержать несколько таких кнопок.

    image

    Создает графический образ кнопки submit. Значение атрибута src специфицирует URL изображения кнопки. Рекомендуется воспользоваться атрибутом alt, чтобы создать альтернативный текст для агентов пользователя, не поддерживающих графику. Если кнопка активизирована, форма передается серверу-адресату. Передаваемые данные содержат значения name.x=x и name.y=y, где "name" - значение атрибута name, х - число пикселей от левого края изображения, а у - число пикселей от верхней кромки изображения. Это позволяет варьировать реакцию сервера от координат места, где была нажата кнопка мышки.

    reset

    Создает кнопку сброса. При нажатии этой кнопки пользователем всем controls формы присваиваются исходные значения, заданные атрибутом value. Пара имя/значение кнопки reset вместе с формой не пересылается.

    button

    Создает кнопку, которая не имеет заранее определенной функции. Эта функция определяется скриптом клиента, который запускается при нажатии этой кнопки. Например, создадим кнопку, которая вызывает функцию verify:

    <input type="button" value="click me" onclick="verify()">

    hidden

    Создает элемент, не видимый при работе агента пользователя. Однако, имя и значение элемента передаются серверу вместе с формой. Эта форма controls используется для запоминания информации в паузах между обменами клиент/сервер. Следующий control типа hidden, тем не менее, должен передавать свое значение вместе с формой.

    <input type="password" style="display:none"

    name="invisible-password"

    value="mypassword">

    file

    Позволяет пользователю присоединить содержимое файла к форме.

    Следующий пример представляет собой анкету, предложенную выше, дополненную кнопками submit и reset. Кнопки содержат изображения, для чего использован элемент img.

    <form action="http://somesite.com/prog/adduser" method="post">
    <p>
    first name: <input type="text" name="firstname"><br>
    last name: <input type="text" name="lastname"><br>
    email: <input type="text" name="email"><br>
    <input type="radio" name="sex" value="male"> male<br>
    <input type="radio" name="sex" value="female"> female<br>
    <button name="submit" value="submit" type="submit">
    send<img src="/icons/wow.gif" alt="wow"></button>
    <button name="reset" type="reset">
    reset<img src="/icons/oops.gif" alt="oops"></button>
    </p>
    </form>

    Внешне данная форма будет выглядеть для пользователя следующим образом:

    25.3. Элемент isindex

    <!element isindex - o empty>
    <!attlist isindex

    %coreattrs;

    -- id, class, style, title --

    %i18n;

    -- lang, dir --

    prompt cdata @implied

    -- сообщение-приглашение (prompt) -->

    Элемент использовать не рекомендуется, вместо него лучше применять элемент input.

    Описание атрибута
    prompt = cdata

    Атрибут специфицирует строку приглашения для ввода. Служит для ввода одной строки пользователем. Например:

    <isindex prompt="enter your name: ">

    Та же задача решается с использованием элемента input следующим образом (рекомендуемый вариант):

    <form action="." method="post">
    enter your name: <input type="text">
    </form>

    25.4. Элемент button

    <!element button - - (%flow;)* -(a|%formctrl;|form|fieldset) -- клавиша -->
    <!attlist button
    %attrs -- %coreattrs, %i18n, %events --
    name cdata #implied
    value cdata #implied -- при представлении посылать серверу --
    type (button|submit|reset) submit -- для использования в качестве кнопки --
    disabled (disabled) #implied -- в данном контексте недоступно --
    tabindex number #implied -- position in tabbing order --
    accesskey %character; #implied -- клавиша доступа --
    onfocus %script; #implied -- элемент выделен --
    onblur %script; #implied -- элемент не выделен -- >

    Описание атрибутов

    name = cdata

    Этот атрибут присваивает имя кнопке.
    value = cdata

    Этот атрибут присваивает значение кнопке.
    type = button | submit | reset

    Этот атрибут декларирует тип кнопки. Когда атрибут не задан, поведение кнопки не определено. Возможные значения:

    button:

    Создает простую кнопку, которая может запускать скрипт.

    submit:

    Создает кнопку, которая служит для отправки формы серверу (значение по умолчанию).

    reset:

    Создает кнопку сброса для формы.

    Элемент button с типом "submit", содержащий изображение (т.е. элемент img), очень похож на элемент input с типом "image". Но их поведение на фазе отображения различно. В этом контексте элемент input предполагает плоское изображение, а button - объемное (кнопка нажимается и отбрасывает тень). Ниже приведен пример использования элементов input и button:

    <form action="http://somesite.com/prog/adduser" method="post"><p>
    first name: <input type="text" name="firstname"><br>
    last name: <input type="text" name="lastname"><br>
    email: <input type="text" name="email"><br>
    <input type="radio" name="sex" value="male"> male<br>
    <input type="radio" name="sex" value="female"> female<br>
    <button name="submit" value="submit" type="submit">
    send<img src="/icons/wow.gif" alt="wow"></button>
    <button name="reset" type="reset">
    reset<img src="/icons/oops.gif" alt="oops"></button>
    </p>
    </form>

    Если используется button с элементом img, рекомендуется применение img-элемента с атрибутом alt, чтобы обеспечить совместимость с агентами пользователя, не поддерживающими графику. Недопустимо использование карты изображения с img в элементе button:

    <button>
    <img src="foo.gif" usemap=".">
    </button>

    Элемент button с типом "reset" очень похож на элемент input с типом "reset".

    25.5. Элемент select

    <!element select - - (optgroup|option)+ -- селектор опции -->
    <!attlist select
    %attrs; -- %coreattrs, %i18n, %events --
    name cdata #implied -- имя поля --
    size number #implied -- rows visible --
    multiple (multiple) #implied -- по умолчанию один выбор --
    disabled (disabled) #implied -- недоступно в данном контексте --
    tabindex number #implied -- position in tabbing order --
    onfocus %script; #implied -- элемент выделен --
    onblur %script; #implied -- элемент не выделен --
    onchange %script; #implied -- значение элемента изменено -->

    Определение атрибутов

    name = cdataЭтот атрибут присваивает имя control.
    size = number

    Если элемент select представлен в виде окна с полосой прокрутки, этот атрибут специфицирует число рядов в списке, которые должны быть видны одновременно. Визуальный агент пользователя не должен представлять элемент select в качестве окна; он может использовать и другой механизм, например, выпадающее меню.

    multiple

    Этот булев атрибут позволяет обеспечить множественный выбор. При отсутствии этого атрибута допускается только один выбор.

    Элемент select создает список вариантов, из которых может выбирать пользователь. Каждый элемент select должен предложить как минимум один вариант. Каждый вариант специфицируется с помощью элемента option.

    <!element option - o (#pcdata) -- доступный выбор -->
    <!attlist option -- %coreattrs, %i18n, %events --
    %attrs;
    selected (selected) #implied
    disabled (disabled) #implied -- недоступно в данном контексте --
    label %text; #implied -- для использования иерархического меню --
    value cdata #implied -- содержимое элемента по умолчанию -->

    Описание атрибутов элемента option selected

    Этот булев атрибут определяет то, что данная опция является уже выбранной (pre-selected).

    value = cdata

    Этот атрибут специфицирует исходное значение control. Если атрибут не установлен, исходное значение определяется содержимым элемента option.

    label = text

    Этот атрибут позволяет разработчику специфицировать более короткую метку, чем содержимое элемента option. Если атрибут задан, агент пользователя должен использовать в качестве метки опции значение атрибута, а не содержимое элемента option.

    Элемент select помогает создать меню, с помощью которого осуществляется выбор опции. Ниже приведен пример создания такого меню.

    <form action="http://somesite.com/prog/component-select" method="post">
    <p>
    <select multiple size="4" name="component-select">
    <option selected value="component_1_a">component_1</option>
    <option selected value="component_1_b">component_2</option>
    <option>component_3</option>
    <option>component_4</option>
    <option>component_5</option>
    <option>component_6</option>
    <option>component_7</option>
    </select>
    <input type="submit" value="send"><input type="reset">
    </p>
    </form>

    Атрибут size определяет, что в окне должно быть видно 4 опции. Реальное число опций равно 7, по этой причине выбор остальных опций возможен с помощью механизма скролинга.

    Элемент optgroup позволяет разработчику логически сгруппировать опции. Это особенно удобно, когда пользователь должен сделать выбор из длинного списка опций. В HTML 4.0 все элементы optgroup должны быть специфицированы в пределах элемента select (т.е., группы не могут вкладываться друг в друга). В ниже приведенном примере показано использование элемента optgroup:

    <form action="http://somesite.com/prog/someprog" method="post">
    <p>
    <select name="comos">
    <optgroup label="portmaster 3">
    <option label="3.7.1" value="pm3_3.7.1">portmaster 3 with comos 3.7.1
    <option label="3.7" value="pm3_3.7">portmaster 3 with comos 3.7
    <option label="3.5" value="pm3_3.5">portmaster 3 with comos 3.5
    </optgroup>
    <option label="3.7" value="pm2_3.7">portmaster 2 with comos 3.7
    <option label="3.5" value="pm2_3.5">portmaster 2 with comos 3.5
    </optgroup>
    <optgroup label="irx">
    <option label="3.7r" value="irx_3.7r">irx with comos 3.7r
    <option label="3.5r" value="irx_3.5r">irx with comos 3.5r
    </optgroup>
    </select>
    </form>

    25.6. Элемент optgroup

    <!element optgroup - - (option)+ -- группа опции -->
    <!attlist optgroup
    %attrs; -- %coreattrs, %i18n, %events --
    disabled (disabled) #implied -- недоступно в данном контексте --

    Определение атрибута

    label = text [cs]

    Этот атрибут специфицирует метку опции для группы опций.

    Когда форма передается на обработку, каждый из выборов группируется с именем "component-select".

    25.7. Элемент textarea

    <!element textarea - - (#pcdata) -- поле многострочного текста -->
    <!attlist textarea
    %attrs; -- %coreattrs, %i18n, %events --
    name cdata #implied
    rows number #required
    cols number #required
    disabled (disabled) #implied -- недоступно в данном контексте --
    readonly (readonly) #implied
    tabindex number #implied -- position in tabbing order --
    accesskey %character; #implied -- клавиша доступа --
    onfocus %script; #implied -- элемент выделен --
    onblur %script; #implied -- элемент не выделен --
    onselect %script; #implied -- некоторый текст выбран --
    onchange %script; #implied -- значение элемента изменено -- >

    Определение атрибутов

    name = cdata [ci]

    Этот атрибут присваивает имя control.

    rows = number [cn]

    Этот атрибут специфицирует номер видимой строки текста. Пользователь может ввести больше строк, чем это число, по этой причине агент пользователя должен предоставить средства для скролирования текста, чтобы обеспечить доступ к строкам за пределами видимости окна.

    cols = number [cn]

    Этот атрибут специфицирует видимую ширину строки (в символах). Пользователь может иметь возможность ввести более длинные строки, так что агент пользователя должен обеспечить средства для скролирования текста по горизонтали. Агент пользователя может разрывать строки, чтобы их сделать видимыми по всей длине без горизонтального скролинга.

    Пример использования элемента textarea для создания текстовой области размером 20 строк по 80 колонок. В исходный момент зона содержит только две строки.

    <form action="http://somesite.com/prog/text-read" method="post">
    <p>
    <textarea name="thetext" rows="20" cols="80">
    first line of initial text.
    second line of initial text.
    </textarea>
    <input type="submit" value="send"><input type="reset">
    </p>
    </form>

    25.8. Элемент label

    <!element label - - (%inline;)* -(label) -- form field label text -->
    <!attlist label
    %attrs; -- %coreattrs, %i18n, %events --
    for idref #implied -- matches field id value --
    accesskey %character; #implied -- клавиша доступа --
    onfocus %script; #implied -- элемент выделен --
    onblur %script; #implied -- элемент не выделен -->

    Определение атрибута

    for = idref [cs]

    Этот атрибут устанавливает соответствие между меткой и control. При наличии этого атрибута его значение должно совпадать с атрибутом id другого control того же документа. При отсутствии этого атрибута метка ставится в соответствие содержимому элемента.

    Элемент label может использоваться для привязки информации к другим элементам control (за исключением других элементов label). Ниже приведены два примера использования элемента label.

    <form action="..." method="post">
    <table>
    <tr>
    <td><label for="fname">first name</label>
    <td><input type="text" name="firstname" id="fname">
    <tr>
    <td><label for="lname">last name</label>
    <td><input type="text" name="lastname" id="lname">
    </table>
    </form>
    <form action="http://somesite.com/prog/adduser" method="post">
    <p>
    <label for="firstname">first name: </label>
    <input type="text" id="firstname"><br>
    <label for="lastname">last name: </label>
    <input type="text" id="lastname"><br>
    <label for="email">email: </label>
    <input type="text" id="email"><br>
    <input type="radio" name="sex" value="male"> male<br>
    <input type="radio" name="sex" value="female"> female<br>
    <input type="submit" value="send"> <input type="reset">
    </p>
    </form>

    Для установления неявной связи между меткой и другим control контрольный элемент должен находиться внутри содержимого элемента label. В этом случае label может содержать только один контрольный элемент. В примере две метки неявно поставлены в соответствие двум вводимым текстам:

    <form action="..." method="post">
    <p>
    <label>
    first name
    <input type="text" name="firstname">
    </label>
    <label>
    <input type="text" name="lastname">
    last name
    </label>
    </p>
    </form>

    25.9. Элементы fieldset и legend

    <!-- #pcdata служит для решения проблемы смешанных данных, согласно спецификации здесь допустимы только whitespace! -->
    <!element fieldset - - (#pcdata,legend,(%flow;)*) >
    <!attlist fieldset
    %attrs; -- %coreattrs, %i18n, %events -- >
    <!element legend - - (%inline;)* -- легенда поля -->
    <!entity % lalign "(top|bottom|left|right)">
    <!attlist legend
    %attrs; -- %coreattrs, %i18n, %events -- >
    accesskey %character; #implied -- клавиша доступа -- >

    Определение атрибута элемента legend
    align = top|bottom|left|right

    Не рекомендуется к применению. Этот атрибут специфицирует положение легенды по отношению к набору полей. Возможные значения:

    top: Легенда размещается сверху (значение по умолчанию).
    bottom: Легенда размещается внизу.
    left: Легенда размещается слева.
    right: Легенда размещается справа.

    Элемент fieldset позволяет разработчику тематически группировать управляющие элементы. Группирование облегчает пользователю понимание их функций и в то же время упрощает графическому агенту пользователя их размещение.

    Элемент legend позволяет разработчику поставить в соответствие надпись, поясняющую назначение полей, и fieldset. Ниже представлен пример использования этих элементов.

    <form action="..." method="post">
    <p>
    <fieldset>
    <legend>personal information</legend>
    last name: <input name="personal_lastname" type="text" tabindex="1">
    first name: <input name="personal_firstname" type="text" tabindex="2">
    address: <input name="personal_address" type="text" tabindex="3">
    ...more personal information...
    </fieldset>
    <fieldset>
    <legend>medical history</legend>
    <input name="history_illness"
    type="checkbox"
    value="smallpox" tabindex="20"> smallpox
    <input name="history_illness"
    type="checkbox"
    value="mumps" tabindex="21"> mumps
    <input name="history_illness"
    type="checkbox"
    value="dizziness" tabindex="22"> dizziness
    <input name="history_illness"
    type="checkbox"
    value="sneezing" tabindex="23"> sneezing
    ...more medical history...
    </fieldset>
    <fieldset>
    <legend>current medication</legend>
    are you currently taking any medication?
    <input name="medication_now"
    type="radio"
    value="yes" tabindex="35">yes
    <input name="medication_now"
    type="radio"
    value="no" tabindex="35">no
    if you are currently taking medication, please indicate
    it in the space below:
    <textarea name="current_medication"
    rows="20" cols="50"
    tabindex="40">
    </textarea>
    </fieldset>
    </form>

    Обратите внимание на то, что в этом примере можно улучшить представление формы путем выравнивания элементов в пределах каждого fieldset (с помощью стилевых листов), добавив цвета, подобрав шрифты и используя скрипты.

    26. Выделение элементов

    Активный элемент HTML-документа должен быть выделен. Существует несколько способов выделения элемента:

    1. Пометить элемент с помощью мышки.
    2. Выделить нужный элемент, перемещаясь от элемента к элементу с помощью стрелок или других клавиш.
    3. Выбрать нужный элемент, нажав определенную комбинацию клавиш.

    Описание атрибута

    tabindex = integer

    Этот атрибут специфицирует положение текущего элемента по порядку, значение может быть положительным или отрицательным.

    Элементы, которые могут быть выделены, должны обрабатываться агентом пользователя согласно следующим правилам:

    1. Тем элементам, которые поддерживают атрибут tabindex, присваиваются положительные значения и они просматриваются первыми. Процесс просмотра начинается с меньших значений tabindex и продолжается в направлении больших. Элементы, которые имеют равные значения tabindex должны обрабатываться в порядке их появления в документе.
    2. Элементы, для которых атрибут tabindex не определен или не поддерживается, просматриваются в порядке их появления в документе.
    3. Те элементы, которым приписано отрицательное значение tabindex, не участвуют в процессе просмотра.

    Атрибут tabindex поддерживается элементами a, area, object, input, select, textarea и button. Ниже предлагается пример.

    <!doctype html public "-//w3c//dtd html 4.0//en"
    "http://www.w3.org/tr/rec-html40/strict.dtd">
    <html>
    <head>
    <title>a document with form</title>
    </head>
    <body>
    ...some text...
    <p>go to the
    <a tabindex="10" href="http://www.w3.org/">w3c web site.</a>
    ...some more...
    <button type="button" name="get-database"
    tabindex="1" onclick="get-database">
    get the current database.
    </button>
    ...some more...
    <form action="..." method="post">
    <p>
    <input tabindex="1" type="text" name="field1">
    <input tabindex="2" type="text" name="field2">
    <input tabindex="3" type="submit" name="submit">
    </p>
    </form>
    </body>
    </html>

    Ключи доступа

    accesskey = cdata

    Этот атрибут присваивает ключ доступа элементу. Ключ доступа представляет собой одиночный символ в текущей кодировке агента пользователя.

    Нажатие клавиши, соответствующей ключу доступа, приводит к выбору элемента.Действия, которые будут выполнены при выборе, зависят от элемента. Атрибут accesskey поддерживается элементами: label и legend. В приведенном примере клавиша "u" ставится в соответствие элементу управления input.

    <form action="..." method="post">
    <p>
    <label for="fuser" accesskey="u">
    user name
    </label>
    <input type="text" name="user" id="fuser">
    </p>
    </form>

    В ниже приведенном примере ключ доступа поставлен в соответствие связи, описанной элементом А. Нажатие клавиши доступа (c) приводит к вызову другого элемента.

    <p><a accesskey="c"
    rel="contents"
    href="http://someplace.com/specification/contents.html">
    table of contents</a>

    В системе MS Windows для активации ключа доступа одновременно с ним следует нажать клавишу alt.

    Атрибут disabled

    Когда этот булев атрибут установлен для control формы, он блокирует данный вид контроля для ввода пользователя. Атрибут disabled поддерживается элементами input, textarea, select, option, object, label и button.

    Блокированный элемент не может быть выделен, он игнорируется при обходе элементов и значения блокированного элемента не передается вместе с формой. В ниже предлагаемом примере блокированный элемент input не может воспринять ввод пользователя и передать его с формой.

    <input disabled name="fred" value="stone">

    Изменить значение атрибута динамически можно только с помощью скрипта.

    Атрибут readonly

    Этот булев атрибут при установке запрещает изменение control. Элементы, предназначенные только для чтения, могут быть выбраны, но не могут быть изменены пользователем. Значения control в этом случае передается вместе с формой. Атрибут readonly поддерживается элементами input, text, password и textarea.

    27. Скрипты

    На стороне клиента скрипт представляет собой программу, которая может сопровождать документ HTML или быть непосредственно встроена в него. Программа исполняется на ЭВМ клиента при загрузке документа или при активации определенной связи. Скрипт предлагает разработчику заметно расширить возможности HTML-документа. В частности:

    • Скрипт может динамически изменять содержимое документа.
    • Скрипт может использоваться для обработки вводимой пользователем информации.
    • Скрипт может быть запущен каким-либо событием (выделение фрагмента, операции с мышкой, выгрузка документа и т.д.).
    • Скрипт может быть поставлен в соответствие одному из control формы и управляться им.

    Существует два типа скриптов, которые могут быть подключены к документу:

    • Исполняемые только раз при загрузке документа агентом пользователя (это прежде всего скрипты элемента script).
    • Исполняемые каждый раз, когда происходит какое-то определенное событие. Такие скрипты могут быть подключены ко многим документам.

    27.1. Элемент script

    <!element script - - %script; -- текст скрипта -->
    <!attlist script
    charset %charset; #implied -- кодировка символов, подключенного ресурса --
    type %contenttype; #required -- тип содержимого языка скрипта --
    src %uri; #implied -- uri для внешнего скрипта --
    defer (defer) #implied -- ua может отложить исполнение скрипта -->

    Определение атрибутов

    src = URI [ct]

    Этот атрибут специфицирует местонахождения внешнего скрипта.

    type = content-type

    Этот атрибут специфицирует язык скрипта, включенного в элемент. Язык специфицируется в содержимом content-type (напр., "text/javascript"). Разработчик должен выдать значения этого атрибута, так как не существует никакого значения по умолчанию.

    language = cdata

    Не рекомендуется к применению. Этот атрибут специфицирует язык скрипта, включенного в элемент. Его содержимое представляет собой идентификатор языка. Но из-за отсутствия стандарта атрибут type предпочтительнее.

    defer

    Установка этого булева атрибута сообщает агенту пользователя о том, что скрипт не будет генерировать какого-либо текста документа, что позволяет агенту пользователя продолжить разборку и представление документа.

    Элемент script размещает скрипт внутри документа. Этот элемент может встретиться в head или body HTML-документа любое число раз. Сам скрипт может находиться в содержательной части элемента script или во внешнем файле. Если атрибут src не установлен, агент пользователя должен интерпретировать содержимое элемента, как скрипт. Если же src содержит URL, то агент пользователя должен игнорировать содержимое элемента и получить скрипт через URL. Разработчик должен идентифицировать язык скрипта. Для того чтобы определить язык всех скриптов в документе, необходимо включить следующую meta-декларацию в head документа:

    <meta http-equiv="content-script-type" content="type">

    где "type" соответствует internet media type, именующему язык скрипта. В отсутствии META-декларации, значение по умолчанию может быть установлено с помощью HTTP-заголовка "content-script-type"

    content-script-type: type

    где "type" соответствует internet media type.

    27.2. Локальная декларация языка скрипта

    Можно описать язык скрипта в каждом элементе script независимо с помощью атрибута type. В отсутствии значения языка по умолчанию этот атрибут должен быть обязательно установлен. При наличии значения по умолчанию атрибут type переписывает это значение. Ниже приведен пример, где значение языка скриптов по умолчанию равно "text/tcl". Один скрипт включен в заголовок, он размещен во внешнем файле и написан на языке "text/vbscript". Включен скрипт и в тело script (написан на "text/javascript").

    <!doctype html public "-//w3c//dtd html 4.0//en"
    "http://www.w3.org/tr/rec-html40/strict.dtd">z
    <html>
    <head>
    <title>a document with script</title>
    <meta http-equiv="content-script-type" content="text/tcl">
    <script type="text/vbscript" src="http://someplace.com/progs/vbcalc">
    </script>
    </head>
    <body>
    <script type="text/javascript">
    ...some javascript...
    </script>
    </body>
    </html>

    27.3. Ссылки на html-документы из скрипта

    В каждом языке имеется соглашение относительно взаимодействия с HTML-объектами. Содержимым элемента script является скрипт и по этой причине агент пользователя не должен рассматривать его как часть HTML-текста. Текст скрипта начинается сразу после начальной метки и завершается любой меткой, которая начинается с символов "</". Ниже следующий пример не является корректным из-за наличия "</em>" символов внутри элемента script (эта комбинация указывает на окончание скрипта):

    <scipt type="text/javascript">

    document.write ("<em> this won't work</em>"

    </script>

    Корректная версия записи выглядит как:

    <scipt type="text/javascript">

    document.write ("<em> this will work<\/em>"

    </script>

    В tcl можно это записать как:

    <scipt type="text/tcl">

    document.write ("<em> this will work<\/em>"

    </script>

    Определения атрибутов

    onload = script [ct]
    Событие onload происходит, когда пользователь заканчивает загрузку окна в рамках frameset. Этот атрибут может использоваться с элементами body и frameset.

    onunload = script [ct]
    Событие onunload происходит, когда агент пользователя удаляет документ из окна или рамки. Этот атрибут может использоваться с элементами BODY и frameset.

    onclick = script [ct]
    Событие onclick происходит, когда на устройстве (например, мышке), указывающем на клавишу, нажата кнопка. Этот атрибут может использоваться с большинством элементов.

    ondblclick = script
    Событие ondblclick происходит, когда на устройстве, указывающем на клавишу, кнопка нажата дважды. Этот атрибут может использоваться с большинством элементов.

    onmousedown = script
    Событие onmousedown происходит, когда на устройстве, указывающем на клавишу, кнопка находится в нажатом состоянии. Этот атрибут может использоваться с большинством элементов.

    onmouseup = script
    Событие onmouseup происходит, когда на устройстве, указывающем на клавишу, кнопка отпущена. Этот атрибут может использоваться с большинством элементов.

    onmouseover = script
    Событие onmouseover происходит, когда указатель устройства, наезжает на клавишу (элемент). Этот атрибут может использоваться с большинством элементов.

    onmousemove = script
    Событие onmousemove происходит, когда устройство указывающее на элемент, перемещено. Этот атрибут может использоваться с большинством элементов.

    onmouseout = script
    Событие onmouseout происходит, когда позиционер указателя сдвигается с поля элемента. Этот атрибут может использоваться с большинством элементов.

    onfocus = script
    Событие onfocus происходит, когда элемент оказывается выделен с помощью прибора-указателя или каким-либо другим способом (например, с помощью клавиш). Этот атрибут может использоваться с: label, input, select, textarea, и button.

    onblur = script
    Событие onblur происходит, когда элемент перестает быть выделенным с помощью прибора-указателя или каким-либо другим способом. navigation. Этот атрибут может использоваться с теми же элементами, что и onfocus.

    onkeypress = script
    Событие onkeypress происходит, когда клавиша нажата и отпущена на элементе. Этот атрибут может использоваться с большинством элементов.

    onkeydown = script
    Событие onkeydown происходит, когда клавиша нажата на элементе. Этот атрибут может использоваться с большинством элементов.

    onkeyup = script
    Событие onkeyup происходит, когда клавиша отпущена на элементе. Этот атрибут может использоваться с большинством элементов.

    onsubmit = script

    Событие onsubmit происходит, когда форма передана. Этот атрибут используется с элементом form.

    onreset = script
    Событие onreset происходит, когда форма сброшена. Этот атрибут используется с элементом form.

    onselect = script
    Событие onselect происходит, когда пользователь выбирает некоторый текст втекстовом поле. Этот атрибут может использоваться с элементами input и textarea.

    onchange = script
    Событие onchange происходит, когда control перестает быть выбранным и его значение модифицировано с момента выбора. Этот атрибут может использоваться с элементами input, select и textarea.

    Имеется возможность установить соответствие между определенными действиями и несколькими событиями, когда пользователь взаимодействует с агентом пользователя. Управляющие элементы, такие как input, select, button, textarea и label реагируют на те или иные события. В следующем примере необходимо ввести имя пользователя в текстовое поле. Когда пользователь пытается покинуть это поле, событие onblur вызывает функцию javascript, которая проверяет корректность введенного имени.

    <input name="num"
    onchange="if (!checknum(this.value, 1, 10))
    {this.focus();this.select();} else {thanks()}"
    value="0">

    Вот пример скрипта vbscript для обработки событий в текстовом поле:

    <input name="edit1" size="50">
    <script type="text/vbscript">
    sub edit1_changed()
    if edit1.value = "abc" then
    button1.enabled = true
    else
    button1.enabled = false
    end if
    end sub
    </script>

    Ниже прведен пример с использованием tcl:

    <input name="edit1" size="50">
    <script type="text/tcl">
    proc edit1_changed {} {
    if {[edit value] == abc} {
    button1 enable 1
    } else {
    button1 enable 0
    }
    }
    edit1 onchange edit1_changed
    </script>

    Здесь приведен пример Javascript для демонстрации установки связи между скриптом и событием (в случае нажатия клавиши на мышке):

    <button type="button" name="mybutton" value="10">
    <script type="text/javascript">
    function my_onclick() {
    . . .
    }
    document.form.mybutton.onclick = my_onclick
    </script>
    </button>

    Ниже представлен более интересный хандлер окна:

    <script type="text/javascript">
    function my_onload() {
    . . .
    }
    var win = window.open("some/other/uri")
    if (win) win.onload = my_onload
    </script>

    На tcl это выглядит как:

    <script type="text/tcl">
    proc my_onload {} {
    . . .
    }
    set win [window open "some/other/uri"]
    if {$win != ""} {
    $win onload my_onload
    }
    </script>

    Атрибуты скриптов для событий определяются как cdata. Значение атрибута должно быть заключено в одинарные или двойные кавычки. С учетом ограничений, налагаемых программой лексической разборки, случаи появления (") и "&" в атрибуте хандлера событий должны быть записаны следующим образом:

    '"' должно быть записано как "&quot;" или "&#34;"
    '&' должно быть записано как "&amp;" или "&#38;"

    Поэтому ниже представленный пример должен быть записан как:

    <input name="num" value="0"
    onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">
    sgml разрешает введение (') в строку атрибута следующим образом:
    "this is 'fine' " and "so is "this" '

    28. Динамическая модификация документов

    Скрипты, которые исполняются в процессе загрузки документа, могут динамически модифицировать его содержимое. Эта возможность зависит от языка, используемого для написания скрипта. Динамическая модификация документов осуществляется следующим образом:

    1. Сначала определяются все элементы script для того, чтобы загрузить документ.
    2. Определяются все конструкции скрипта в пределах данного элемента script, которые генерируют SGML cdata. Полученный в результате текст загружается в документ в месте размещения элемента script.
    3. Сгененированная cdata подвергается обратному преобразованию.

    Следующий пример иллюстрирует то, как скрипты могут динамически модифицировать текст.

    <title>test document</title>
    <script type="text/javascript">
    document.write("<p><b>hello world!<\/b>")
    </script>

    Приведенный выше текст дает тот же результат, что и html-текст:

    <title>test document</title>
    <p><b>hello world!</b>

    28.1. Элемент noscript

    <!element noscript - - (%block;)+
    -- альтернативный текст для случая безскриптового отображения -->
    <!attlist noscript
    %attrs; -- %coreattrs, %i18n, %events -- >

    Элемент noscript позволяет разработчику варьировать содержимое, даже когда скрипт не исполняется. Содержимое элемента noscript должно отображаться соответствующим агентом пользователя в следующих случаях:

    1. Агент пользователя сконфигурирован так, что он не поддерживает скрипты.
    2. Агент пользователя не поддерживает язык скрипта, использованный в элементе script.

    Агент пользователя, не поддерживающий скрипты для стороны клиента, должен осуществлять разборку и представление содержимого элемента. В следующем примере агент пользователя, который исполняет script, включит некоторую динамически созданную информацию, в текст документа. Если агент пользователя не поддерживает скрипты, пользователь может, тем не менее, получить эту информацию через сеть.

    <script type="text/tcl">
    ...некоторый tcl-скрипт для введения данных...
    </script>
    <noscript>
    <p>access the <a href="http://someplace.com/data">data.</a>
    </noscript>

    Агент пользователя, который не распознает элемент script, вероятно будет разбирать и отображать содержимое элемента, как текст. Некоторые интерпретаторы скриптов, включая те, которые ориентированы на Javascript, VBscript и TCL, позволяют помещать фрагменты текстов скриптов в SGML-комментарии. Тогда агент пользователя, не узнавший элемент script, игнорирует его текст, считая его комментарием, а продвинутый интерпретатор скриптов распознает скрипт, помещенный в комментарий, и исполнит его. Другим решением проблемы является помещение скрипта во внешний документ.

    28.2. Комментирование скриптов в javascript

    Интерпретатор javascript позволяет вводить строку "<!--" в начало элемента script и игнорировать все символы, следующие за ней вплоть до конца строки. javascript интерпретирует "//" как начало комментария, который следует до конца текущей строки. Это необходимо, для того чтобы скрыть строку "-->" от интерпретатора javascript.

    <script type="text/javascript">
    <!-- to hide script contents from old browsers
    function square(i) {
    document.write("the call passed ", i ," to the function.","<br>")
    return i * i
    }
    document.write("the function returned ",square(5),".")
    // end hiding contents from old browsers -->
    </script>

    28.3. Комментирование скриптов в vbscript

    В vbscript символ одиночной кавычки воспринимается, как начало комментария, который продолжается до конца строки. Это может быть использовано для того, чтобы спрятать "-->" от vbscript. Например:

    <script type="text/vbscript">
    <!--
    sub foo()
    ...
    end sub
    ' -->
    </script>

    28.4. Комментирование скриптов в tcl

    В TCL для начала строки комментария используется символ "#" (действует до конца строки).

    <script type="text/tcl">
    <!-- чтобы скрыть содержимое скрипта от старых броузеров

    proc square {i} {
    document write "the call passed $i to the function.<br>"
    return [expr $i * $i]
    }
    document write "the function returned [square 5]."
    # end hiding contents from old browsers -->
    </script>

    Некоторые броузеры считают комментарий завершившимся на первом символе ">".

    29. Верификация документов

    Многие разработчики при проверке своих документов полагаются на ограниченное число броузеров, предполагая, что если эти броузеры могут работать с их документами корректно, то они лишены ошибок. К сожалению, это очень неэффективный способ верификации документов, прежде всего из-за того, что многие броузеры приспособлены работать с не вполне корректными документами.

    Для более тщательной проверки рекомендуется воспользоваться интерпретатором SGML, например, в случае проверки соответствия документа требованиям HTML 4.0 DTD это может быть NSGMLS. Если декларации типа в вашем документе включают URI, и ваш интерпретатор SGML поддерживает этот тип системных идентификаторов, то он получит DTD (Document Type Definition) непосредственно. В противном случае можно воспользоваться каталогом образцов SGML.

    Предполагается, что DTD спасено в виде файла "strict.dtd", а объекты (entities) записаны в файлы "htmllat1.ent", "htmlsymbol.ent" и "htmlspecial.ent". В любом случае следует проверить то, что ваш интерпретатор SGML может работать с уникодами.

    Следует иметь в виду, что такая проверка, хотя и полезна и настойчиво рекомендуется, не может гарантировать полного соответствия документа требованиям спецификации HTML 4.0. Это происходит потому, что интерпретатор SGML базируется на определенных SGML DTD, не выражают всех аспектов истинного документа HTML 4.0. Интерпретатор SGML гарантирует, что синтаксис, структура, список элементов и их атрибутов соответствуют рекомендациям стандарта. Но он не может, например, обнаружить ошибки при установке атрибута ширины элемента IMG. Хотя спецификация ограничивает значение атрибута "целым числом пикселей"," DTD определяет только то, что это cdata, что практически допускает любые значения. Только специализированная программа способна выловить все несоответствия с HTML 4.0.

    Несмотря ни на что, этот тип верификации является рекомендуемым, так как позволяет обнаружить большинство ошибок.

    29.1. Каталог образцов SGML

    Этот каталог включает в себя отвергнутые директивы с тем, чтобы гарантировать, что обрабатывающее программное обеспечение, такое как NSGMLS, использует предпочтительно общедоступные идентификаторы по отношению к системным идентификаторам. Это означает, что пользователи не должны быть подключены к сети при обработке системных идентификаторов, базирующихся на URI.

    override yes
    public "-//w3c//dtd html 4.0//en" strict.dtd
    public "-//w3c//dtd html 4.0 transitional//en" loose.dtd
    public "-//w3c//dtd html 4.0 frameset//en" frameset.dtd
    public "-//w3c//entities latin1//en//html" htmllat1.ent
    public "-//w3c//entities special//en//html" htmlspecial.ent
    public "-//w3c//entities symbols//en//html" htmlsymbol.ent

    29.2. sgml декларация html 4.0

    Замечание. Набор символов SGML-деклараций документа включает в себя первые 17 плоскостей [ISO10646] (17 раз по 65536). Это ограничение связано с тем, что это число в текущей версии стандарта SGML имеет только 8 цифр.

    Замечание. Строго говоря, регистрационный номер ISO 177 относится к исходному состоянию ISO 10646 в 1993 году, в то время как в этой спецификации мы базируемся на последней версии ISO 10646.

    29.3. SGML декларация

    <!sgml "ISO 8879:1986"
    -- SGML - предложениеHhypertext Markup Language версия 4.0. С поддержкой первых 17 плоскостей ISO10646 и увеличенными пределами для меток и литералов. --
    charset
    baseset "ISO registration number 177//charset
    ISO/IEC 10646-1:1993 UCS-4 with
    implementation level 3//esc 2/5 2/15 4/6"

    descset

    0

    9

    unused

    9

    2

    9

    11

    2

    unused

    13

    1

    13

    14

    18

    unused

    32

    95

    32

    127

    1

    unused

    128

    32

    unused

    160

    55136

    160

    55296

    2048

    unused -- суррогаты --

    57344

    1056768

    57344

    capacity

    sgmlref

    totalcap

    150000

    grpcap

    150000

    entcap

    150000

    scope

    document

    syntax

    shunchar

    controls

    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

    17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127

    baseset

    "ISO 646irv:1991//charset

    international reference version (irv)//esc 2/8 4/2"

    descset 0 128 0
    function

    re

    13

    rs

    10

    space

    32

    tab sepchar

    9

    naming

    lcnmstrt ""

    ucnmstrt ""

    lcnmchar ".-_:"

    ucnmchar ".-_:"

    namecase

    general

    yes

    entity

    no

    delim

    general

    sgmlref

    shortref

    sgmlref

    names

    sgmlref

    quantity

    sgmlref

    attcnt

    60

    attsplen

    65536

    -- Это наибольшие величины --

    litlen

    65536

    -- разрешенные в декларации --

    namelen

    65536

    -- Избегайте фиксированных пределов --

    pilen

    65536

    -- приложения агентов пользователя HTML --

    taglvl

    100

    taglen

    65536

    grpgtcnt

    150

    grpcnt

    64

    features

    minimize

    datatag

    no

    omittag

    yes

    rank

    no

    shorttag

    yes

    link

    simple

    no

    implicit

    no

    explicit

    no

    other

    concur

    no

    subdoc

    no

    formal

    yes

    appinfo

    none

    >

    29.4. Определение типа документа DTD (Document Type Definition)

    <!-- Это строгие DTD HTML 4.0, которые исключают новейшие презентационные атрибуты и элементы. Разработчикам следует пользоваться строгими требованиями DTD всюду, где возможно, но могут быть применены и переходные DTD там, где это требуется для презентационных атрибутов и элементов. HTML 4.0 включает в себя механизм стилевых листов, скриптов, встроенных объектов, улучшенную поддержку размещения текста слева на право и наоборот, усовершенствования в работе с формами, обеспечение доступа для людей с ограниченными возможностями.

    Проект: $date: 1998/04/02 00:17:00 $
    Авторы:
    dave raggett <dsr@w3.org>
    arnaud le hors <lehors@w3.org>
    ian jacobs <ij@w3.org>

    Дальнейшая информация об HTML 4.0 доступна по адресу:

    http://www.w3.org/tr/rec-html40-->
    <!-- Типовое применение:

    <!doctype html public "-//w3c//dtd html 4.0//en"

    "http://www.w3.org/tr/rec-html40/strict.dtd">

    <html>

    <head>

    ...

    </head>

    <body>

    ...

    </body>

    </html>

    FPI для переходного HTML 4.0 dtd соответствует:

    "-//w3c//DTD HTML 4.0 transitional//en"

    а его uri:

    http://www.w3.org/tr/rec-html40/loose.dtd

    Если вы пишете документ, который включает в себя рамки, используйте fpi:

    "-//w3c//dtd html 4.0 frameset//en"

    с uri:

    http://www.w3.org/tr/rec-html40/frameset.dtd

    Следующие uri поддерживаются в рамках html 4.0

    "http://www.w3.org/tr/rec-html40/strict.dtd" (strict dtd)
    "http://www.w3.org/tr/rec-html40/loose.dtd" (loose dtd)
    "http://www.w3.org/tr/rec-html40/frameset.dtd" (frameset dtd)
    "http://www.w3.org/tr/rec-html40/htmllat1.ent" (latin-1 entities)
    "http://www.w3.org/tr/rec-html40/htmlsymbol.ent" (symbol entities)
    "http://www.w3.org/tr/rec-html40/htmlspecial.ent" (special entities)

    Эти uri указывают на последние версии каждого из файлов. Для ссылок используйте URI:

    "http://www.w3.org/tr/1998/rec-html40-19980424/strict.dtd"
    "http://www.w3.org/tr/1998/rec-html40-19980424/loose.dtd"
    "http://www.w3.org/tr/1998/rec-html40-19980424/frameset.dtd"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmllat1.ent"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmlsymbol.ent"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmlspecial.ent"
    -->
    <!--================== Импортированные имена ===================== -- >

    <!entity % contenttype "cdata"

    -- тип среды, как в rfc2045 -->

    <!entity % contenttypes "cdata"
    -- список кодов типов среды, разделенных запятыми, в соответствие с [rfc-2045] -->

    <!entity % charset "cdata"

    -- символьное кодирования как в [rfc-2045] -->

    <!entity % charsets "cdata"

    -- список символьных кодов, разделенных пробелами, как в rfc-2045 -->

    <!entity % languagecode "name"

    -- код языка, как в [RFC-1766] -->

    <!entity % character "cdata"

    -- одиночный символ из [ISO10646] -->

    <!entity % linktypes "cdata"

    -- список типов связей (через пробел) -->

    <!entity % mediadesc "cdata"

    -- список дескрипторов среды (через запятую)-->

    <!entity % uri "cdata"

    -- uri -->

    <!entity % datetime "cdata"

    -- информация о дате и времени. Формат ISO -->

    <!entity % script "cdata"

    -- скрипты -->

    <!entity % stylesheet "cdata"

    -- информация стилевого листа -->

    <!entity % text "cdata">

    <!-- parameter entities -->
    <!entity % head.misc "script|style|meta|link|object" -- повторяющиеся элементы заголовков -->
    <!entity % heading "h1|h2|h3|h4|h5|h6">
    <!entity % list "ul | ol">
    <!entity % preformatted "pre">
    <!entity % color "cdata" -- цвет в представлении rgb: #rrggbb (hex формат) -->

    <! -- Здесь представлены имена 16 широко известных цветов с их rgb значениями:

    black =

    #000000

    green =

    #008000

    silver =

    #C0C0C0

    lime =

    #00FF00

    gray =

    #808080

    olive =

    #808000

    white =

    #FFFFFF

    yellow =

    #FFFF00

    maroon =

    #800000

    navy =

    #000080

    red =

    #FF0000

    blue =

    #0000FF

    purple =

    #800080

    teal =

    #008080

    fuchsia =

    #FF00FF

    aqua =

    #00FFFF

    --> <!entity % bodycolors "

    bgcolor %color; #implied

    -- фоновый цвет документа --

    text %color; #implied

    -- цвет текста документа --

    link %color; #implied

    -- цвета связей --

    vlink %color; #implied

    -- цвета посещенных URL --

    alink %color; #implied

    -- цвет выбранного URL -- ">

    <!--============== Символьные мнемонические объекты ==============-->
    <!entity % htmllat1 public
    "-//w3c//entities latin1//en//html"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmllat1.ent">
    %htmllat1;

    <!entity % htmlsymbol public
    "-//w3c//entities symbols//en//html"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmlsymbol.ent">
    %htmlsymbol;
    <!entity % htmlspecial public
    "-//w3c//entities special//en//html"
    "http://www.w3.org/tr/1998/rec-html40-19980424/htmlspecial.ent">
    %htmlspecial;
    <!--===================== Общие атрибуты =======================-->
    <!entity % coreattrs
    "id id #implied
    -- уникальный идентификатор, действительный для всего документа --

    class cdata #implied

    -- список классов, разделенных пробелами --

    style %stylesheet; #implied

    -- ассоциированная стилевая информация --

    title %text; #implied

    -- рекомендуемые заголовки /приложения --" >

    <!entity % i18n

    "lang %languagecode; #implied

    -- код языка --

    dir (ltr|rtl) #implied

    -- направление для слабого/нейтрального текста --" >

    <!entity % events

    "onclick %script; #implied

    -- клавиша мышки была нажата --

    ondblclick %script; #implied

    -- клавиша мышки была нажата дважды --

    onmousedown %script; #implied

    -- клавиша мышки была нажата и удержана --

    onmouseup %script; #implied

    -- клавиша мышки была отпущена --

    onmouseover %script; #implied

    -- маркер был помещен на объект --

    onmousemove %script; #implied

    -- маркер перемещался в пределах объекта --

    onmouseout %script; #implied

    -- маркер удален с объекта --

    onkeypress %script; #implied

    -- клавиша была нажата и отпущена --

    onkeydown %script; #implied

    -- клавиша была зажата --

    onkeyup %script; #implied

    -- клавиша была отпущена --" >

    <!-- Зарезервированный переключатель функций -->
    <!entity % html.reserved "ignore">
    <!-- Следующие атрибуты зарезервированы для будущего использования -->
    <![ %html.reserved; [
    <!entity % reserved

    "datasrc %uri; #implied

    -- a single or tabular data source --

    datafld cdata #implied

    -- свойство или имя колонки --

    dataformatas (plaintext|html) plaintext

    -- текст или html --" >

    ]]>
    <!entity % reserved "">
    <!entity % attrs "%coreattrs; %i18n; %events;">
    <!--================== Разметка текста (markup) ===================-->
    <!entity % fontstyle "tt | i | b | big | small">
    <!entity % phrase "em | strong | dfn | code |
    samp | kbd | var | cite | abbr | acronym" >
    <!entity % special
    "a | img | object | br | script | map | q | sub | sup | span | bdo">
    <!entity % formctrl "input | select | textarea | label | button">
    <!-- %inline; охватывает строчные и "text-level" элементы -->
    <!entity % inline "#pcdata | %fontstyle; | %phrase; | %special; | %formctrl;">
    <!element (%fontstyle;|%phrase;) - - (%inline;)*>
    <!attlist (%fontstyle;|%phrase;)

    %attrs;

    -- %coreattrs, %i18n, %events -- >

    <!element (sub|sup) - - (%inline;)*

    -- нижний или верхний индексы -->

    <!attlist (sub|sup) %attrs;

    -- %coreattrs, %i18n, %events -->

    <!element span - - (%inline;)*

    -- общий языковый/стилевой контейнер -->

    <!attlist span %attrs

    -- %coreattrs, %i18n, %events --

    %reserved

    -- зарезервировано на будущее -->

    <!element bdo - - (%inline;)*

    -- i18n bidi over-ride -->

    <!attlist bdo %coreattrs;

    -- id, class, style, title --

    lang %languagecode; #implied

    -- код языка --

    dir (ltr|rtl) #required

    -- направление -->

    <!element br - o empty

    -- принудительный разрыв строки -->

    <!attlist br %coreattrs;

    -- id, class, style, title -- >

    <!element basefont - o empty

    -- базовый размер шрифта -->

    <!attlist basefont

    ID id #implied

    -- идентификатор документа --

    size cdata #required

    -- базовый размер шрифта для элементов font --

    color %color; #implied

    -- цвет текста --

    face cdata #implied

    -- список имен шрифтов, разделенных запятыми -- >

    <!element font - - (%inline;)*

    -- локальная смена шрифта -->

    <!attlist font %coreattrs;

    -- id, class, style, title --

    %i18n;

    -- lang, dir --

    size cdata #implied

    -- [+|-]nn e.g. size="+1", size="4" --

    color %color; #implied

    -- цвет текста --

    face cdata #implied

    -- список имен шрифтов, разделенных запятыми -- >

    <!--================ Модели содержимого html ==================-->

    <!-- HTML имеет две базовые модели содержимого:
    %inline; элементы символьного уровня и текстовые строки
    %block; блочные элементы, напр., параграфы и списки -->
    <!entity % block
    "p | %heading; | %list; | %preformatted; | dl | div | noscript |
    blockquote | form | hr | table | fieldset | address">
    <!entity % flow "%block; | %inline;">

    <!--=================== Тело документа ========================-->

    <!element body o o (%block;|script)+ +(ins|del) -- тело документа -->

    <!attlist body %attrs;

    -- %coreattrs, %i18n, %events --

    onload %script; #implied

    -- документ был загружен --

    onunload %script; #implied

    -- документ был удален -->

    <!element address - - (%inline;)*

    -- информация об авторе -->

    <!attlist address %attrs;

    -- %coreattrs, %i18n, %events -- >

    <!element div - - (%flow;)*

    -- общий языковый/стилевой контейнер -->

    <!attlist div %attrs;

    -- %coreattrs, %i18n, %events --

    %reserved;

    -- зарезервировано на будущее -->

    <!--================== Элемент anchor ========================-->

    <!entity % shape "(rect|circle|poly|default)">

    <!entity % coords "cdata"

    -- список длин с запятыми между элементами -->

    <!element a - - (%inline;)* -(a)

    -- якорь -->

    <!attlist a %attrs;

    -- %coreattrs, %i18n, %events --

    charset %charset; #implied

    -- кодировка подключенного ресурса --

    type %contenttype; #implied

    -- рекомендуемый тип содержимого --

    name cdata #implied

    -- именованный конец связи --

    href %uri; #implied

    -- uri для связанного ресурса --

    hreflang %languagecode; #implied

    -- код языка --

    rel %linktypes; #implied

    -- прямые типы связи --

    rev %linktypes; #implied

    -- обратные типы связи --

    target %frametarget; #implied

    -- отображать в этой рамке --

    accesskey %character; #implied

    -- клавиша доступа --

    shape %shape; rect

    -- для использования с картой изображения клиента --

    coords %coords; #implied

    -- для использования с картой изображения клиента --

    tabindex number #implied

    -- индекс позиции в меню --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен -- >

    <!--================ Карты изображения стороны клиента ==============-->
    <!-- Они могут помещаться в один и тот же документ или группироваться в отдельном документе, хотя это и не поддерживается широко -->

    <!element map - - ((%block;)+ | area+)

    -- карта изображения со стороны клиента -->

    <!attlist map

    %attrs;

    -- %coreattrs, %i18n, %events --

    name cdata #required

    -- для ссылок через карту использования -- >

    <!element area - o empty

    -- карта изображения стороны клиента -->

    <!attlist area

    %attrs;

    -- %coreattrs, %i18n, %events --

    shape %shape; rect

    -- управление интерпретацией координат --

    coords %coords; #implied

    -- список длин, разделенных запятыми --

    href %uri; #implied

    -- uri для подключенного ресурса --

    target %frametarget; #implied

    -- отображать в этой рамке --

    nohref (nohref) #implied

    -- эта область не производит действия --

    alt %text; #required

    -- краткое описание --

    tabindex number #implied

    -- положение при обходе меню --

    accesskey %character; #implied

    -- клавиша доступа --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен -- >

    <!--===================== Элемент link ======================-->

    <!-- Значения отношений могут использоваться:

    1. для специальных меню (toolbars), когда значения отношений используются с элементом link в заголовке документа, напр., start, contents, previous, next, index, end, help
    2. для связи с отдельным стилевым листом (rel=stylesheet)
    3. для организации связи со скриптом (rel=script)
    4. с стилевыми листами для управления процессом представления документов из нескольких узлов при их печати
    5. для создания связи с печатаемой версией документа, напр., postscript или pdf (rel=alternate media=print) -->

    <!element link - o empty

    -- связь, независящая от среды-->

    <!attlist link

    %attrs;

    -- %coreattrs, %i18n, %events --

    charset %charset; #implied

    -- кодировка символов подключенного ресурса --

    href %uri; #implied

    -- uri для подключенного ресурса --

    hreflang %languagecode; #implied

    -- код языка --

    type %contenttype; #implied

    -- рекомендуемый тип содержимого --

    rel %linktypes; #implied

    -- прямые типы связей --

    rev %linktypes; #implied

    -- обратные типы связей --

    media %mediadesc; #implied

    -- для отображения в этих средах -- >

    target %frametarget; #implied

    -- отображать в этой рамке -- >

    <!--===================== Изображения =====================-->

    <!-- Длина, определенная в DTD, для cellpadding/cellspacing -->

    <!entity % length "cdata"

    -- nn для пикселей или nn% для %-длины -->

    <!entity % multilength "cdata"

    -- пиксель, процент или относительно -->

    <!entity % multilengths "cdata"

    -- список multilength, разделенных запятыми -->

    <!entity % pixels "cdata"

    -- целочисленная длина в пикселях -->

    <!entity % ialign "(top|middle|bottom|left|right)"

    -- центрировать? -->

    <!-- Чтобы избежать проблем с агентами пользователя, ориентированными исключительно на работу с текстом, сделать изображение понятным и удобным для сетевого поиска для неграфических агентов пользователя, следует предусмотреть альтернативу описания с помощью alt, и избежать применения карт изображения на стороне сервера -->

    <!element img - o empty

    -- Встроенное изображение -->

    <!attlist img

    %attrs;

    -- %coreattrs, %i18n, %events --

    src %uri; #required

    -- uri встроенного изображения --

    alt %text; #required

    -- краткое описание --

    longdesc %uri; #implied

    -- связь с длинным описанием (complements alt) --

    height %length; #implied

    -- присвоение нового значения высоты --

    width %length; #implied

    -- присвоение нового значения ширины--

    usemap %uri; #implied

    -- для использования с картой изображения клиента --

    ismap (ismap) #implied

    -- для использования с картой изображения сервера -->

    align %ialign; #implied

    -- вертикальное или горизонтальное выравнивание--

    border %length; #implied

    -- ширина границы для связи --

    hspace %pixels; #implied

    -- горизонтальный пробельный массив--

    vspace %pixels; #implied

    -- вертикальный пробельный массив-- >

    <!-- usemap указывает на элемент map, который может быть в этом документе или во внешнем документе, хотя последнее и не поддерживается широко -->

    <!--==================== object ===================-->

    <!-- object используется для вставления объектов в качестве части html страниц. Элементы param должны предшествовать остальному содержимому. -->

    <!element object - - (param | %flow;)*

    -- общий встроенный объект -->

    <!attlist object

    %attrs

    -- %coreattrs, %i18n, %events --

    declare (declare) #implied

    -- декларирует, но не инициирует флаг --

    classid %uri; #implied

    -- идентифицирует реализацию --

    codebase %uri; #implied

    -- базовый uri для classid, data, archive --

    data %uri; #implied

    -- ссылка на данные объекта --

    type %contenttype; #implied

    -- тип содержимого для данных --

    codetype %contenttype; #implied

    -- тип содержимого для кода --

    archive %uri; #implied

    -- архивный список с sp в качестве разделителей --

    standby %text; #implied

    -- сообщение, отображаемое при загрузке --

    height %length; #implied

    -- присваивает новое значение высоты --

    width %length; #implied

    -- присваивает новое значение ширины --

    usemap %uri; #implied

    -- для использования с картой изображения клиента --

    name cdata #implied

    -- представляет как часть формы --

    tabindex number #implied

    -- положение при обходе меню --

    align %ialign; #implied -- вертикальное или горизонтальное выравнивание--

    border %length; #implied

    -- ширина границы связи --

    hspace %pixels; #implied

    -- горизонтальный пробельный массив--

    vspace %pixels; #implied

    -- вертикальный пробельный массив--

    %reserved;

    -- зарезервировано на будущее -->

    <!element param - o empty

    -- именованное значение свойства -->

    align="justify"><!attlist param

    id id #implied

    -- идентификатор документа --

    name cdata #required

    -- имя свойства --

    value cdata #implied

    -- значение свойства --

    valuetype (data|ref|object) data

    -- Как интерпретировать значение --

    type %contenttype; #implied

    -- тип содержимого для значения, когда valuetype=ref -->

    <!--======================= java applet ========================-->
    <!-- Один из кодов или атрибутов объекта должен присутствовать. Помещайте элементы param до остального содержимого. -->
    <!element applet - - (param | %flow;)* -- аплет java -->

    <!attlist applet %coreattrs;

    -- id, class, style, title --

    codebase %uri; #implied

    -- опционный базовый uri для аплета --

    archive cdata #implied

    -- список архива с запятой в качестве разделителя--

    code cdata #implied

    -- файл класса аплета --

    object cdata #implied

    -- файл специального аплета --

    alt %text; #implied

    -- краткое описание--

    name cdata #implied

    -- позволяет аплетам найти друг друга --

    width %length; #required

    -- начальная ширина --

    height %length; #required

    -- начальная высота --

    align %ialign; #implied

    -- вертикальное или горизонтальное выравнивание --

    hspace %pixels; #implied

    -- горизонтальный пробельный массив--

    vspace %pixels; #implied

    -- вертикальный пробельный массив-- >

    <!--================ Горизонтальная линейка ==================-->

    <!element hr - o empty

    -- горизонтальная линейка -->

    <!attlist hr %coreattrs;

    -- id, class, style, title --

    %events; >

    <!--====================== Параграфы =======================-->

    <!element p - o (%inline;)*

    -- параграф -->

    <!attlist p %attrs;

    -- %coreattrs, %i18n, %events -- >

    %align;

    -- выравнивание текста -- >

    <!--======================= Заголовки =======================-->

    <!--Существует 6 уровней заголовков от H1 (наиболее важный) до H6 (наименее важный). -->

    <!element (%heading;) - - (%inline;)*

    -- Заголовок -->

    <!attlist (%heading;) %attrs;

    -- %coreattrs, %i18n, %events -- >

    %align;

    -- выравнивание текста -- >

    <!--================ Преформатированный текст ================-->

    <!-- не включает разметку для изображений и изменений в размере шрифтов -->
    <!entity % pre.exclusion "img|object|big|small|sub|sup">
    <!element pre - - (%inline;)* -(%pre.exclusion;) -- преформатированный текст -->
    <!attlist pre %attrs; -- %coreattrs, %i18n, %events -- >

    <!--===================== inline quotes ====================-->

    <!element q - - (%inline;)*

    -- Кавычки для текста в пределах строки -->

    <!attlist q %attrs;

    -- %coreattrs, %i18n, %events --

    cite %uri; #implied

    -- uri для исходного документа или сообщения -- >

    <!--===================== block-like quotes ====================-->

    <!element blockquote - - (%block;|script)+ -- Кавычки для многострочных блоков текста -->
    <!attlist blockquote

    %attrs;

    -- %coreattrs, %i18n, %events --

    cite %uri; #implied

    -- uri для исходного документа или сообщения -->

    <!--================== Введенный/Стертый текст ====================-->

    <!-- ins/del are handled by inclusion on body -->

    <!element (ins|del) - - (%flow;)*

    -- введенный текст, стертый текст -->

    <!attlist (ins|del) %attrs;

    -- %coreattrs, %i18n, %events --

    cite %uri; #implied

    -- инфо о причине изменения --

    datetime %DAtetime; #implied

    -- дата и время изменения -- >

    <!--====================== Списки ========================-->

    <!-- список определений - dt - для термов, dd - для их определений -->

    <!element dl - - (dt|dd)+

    -- список определений -->

    <!attlist dl %attrs;

    -- %coreattrs, %i18n, %events -->

    <!element dt - o (%inline;)*

    -- term определения -->

    <!element dd - o (%flow;)*

    -- описание определения -->

    <!attlist (dt|dd) %attrs;

    -- %coreattrs, %i18n, %events -->

    <!element ol - - (li)+

    -- упорядоченный список -->

    <!attlist ol %attrs;

    -- %coreattrs, %i18n, %events -->

    <!-- Стиль нумерации упорядоченных списков (ol)
    1 арабские числа 1, 2, 3, ...
    a строчные буквы a, b, c, ...
    a прописные буквы a, b, c, ...
    i строчные римские i, ii, iii, ...
    i прописные римские i, ii, iii, ...

    Стиль применяется к номеру по порядку, который по умолчанию равен 1 для первого элемента упорядоченного списка. -->

    <!entity % olstyle "cdata" -- ограничено перечнем: "(1|a|a|i|i)" -->
    <!element ol - - (li)+ -- упорядоченный список -->
    <!attlist ol

    %attrs;

    -- %coreattrs, %i18n, %events --

    type %olstyle; #implied

    -- стиль нумерации --

    compact (compact) #implied

    -- уменьшенный зазор между позициями--

    start number #implied

    -- начальный номер последовательности -- >

    <!-- Неупорядоченные списки (ul) bullet styles -->

    <!element ul - - (li)+

    -- неупорядоченный список -->

    <!attlist ul %attrs;

    -- %coreattrs, %i18n, %events -- >

    <!element li - o (%flow;)*

    -- элемент списка -->

    <!attlist li %attrs;

    -- %coreattrs, %i18n, %events -- >

    type %ulstyle; #implied

    -- стиль bullet --

    compact (compact) #implied

    -- уменьшенный зазор между позициями-- >

    <!--==================== Формы =======================-->

    ><!element form - - (%block;|script)+ -(form)

    -- интерактивная форма -->

    <!attlist form %attrs;

    -- %coreattrs, %i18n, %events --

    action %uri; #required

    -- хандлер форм для стороны сервера --

    method (get|post) get

    -- http метод для представления форм --

    enctype %contenttype; "application/x-www-form-urlencoded"

    onsubmit %script; #implied

    -- форма была представлена --

    onreset %script; #implied

    -- форма возвращена в исходное состояние --

    target %frametarget; #implied

    -- отображать в этой рамке --

    accept-charset %charsets; #implied

    -- список поддерживаемых символьных наборов -- >

    <!-- Каждая метка не должна содержать более одного поля -->
    <!element label - - (%inline;)* -(label) -- текст метки поля формы -->

    <!attlist label %attrs;

    -- %coreattrs, %i18n, %events --

    or idref #implied

    -- проверяет корректность значения поля --

    accesskey %character; #implied

    -- клавиша доступа --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен -- >

    <!entity % inputtype
    "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)" >
    <!-- имя атрибута необходимо всем кроме submit & reset -->

    <!element input - o empty

    -- Управление формой -->

    <!attlist input %attrs;

    -- %coreattrs, %i18n, %events --

    type %inputtype; text

    -- what kind of widget is needed --

    name cdata #implied

    -- представить в качестве части формы --

    value cdata #implied

    -- необходимо для радио кнопок и переключателей --

    checked (checked) #implied

    -- для радио кнопок и переключателей --

    disabled (disabled) #implied

    -- недоступно в данном контексте --

    readonly (readonly) #implied

    -- для текста и пароля --

    size cdata #implied

    -- разный для каждого из полей --

    maxlength number #implied

    -- максимальное число символов для текстовых полей --

    src %uri; #implied

    -- для полей с изображением --

    alt cdata #implied

    -- краткое описание --

    usemap %uri; #implied

    -- использует карту изображения клиента --

    tabindex number #implied

    -- номер позиции в меню --

    accesskey %character; #implied

    -- клавиша доступа --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен --

    onselect %script; #implied

    -- некоторая часть текста выделена --

    onchange %script; #implied

    -- значение элемента изменилось --

    accept %contenttypes; #implied

    -- список типов mime для файловой загрузки --

    align %ialign; #implied

    -- вертикальное или горизонтальное выравнивание--

    %reserved;

    -- зарезервировано на будущее -- >

    <!element select - - (optgroup|option)+

    -- селектор опций -->

    <!attlist select %attrs;

    -- %coreattrs, %i18n, %events --

    name cdata #implied

    -- имя поля --

    size number #implied

    -- видимые строки --

    multiple (multiple) #implied

    -- по умолчанию один выбор --

    disabled (disabled) #implied

    -- недоступно в данном контексте --

    tabindex number #implied

    -- номер позиции в меню --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен --

    onchange %script; #implied

    -- значение элемента изменилось --

    %reserved;

    -- зарезервировано на будущее -- >

    <!element optgroup - - (option)+

    -- группа опций -->

    <!attlist optgroup %attrs;

    -- %coreattrs, %i18n, %events --

    disabled (disabled) #implied

    -- недоступно в данном контексте --

    label %text; #required

    -- для использования в иерархических меню -->

    <!element option - o (#pcdata)

    -- селективный выбор -->

    <!attlist option %attrs;

    -- %coreattrs, %i18n, %events --

    selected (selected) #implied

    disabled (disabled) #implied

    -- недоступно в данном контексте --

    label %text; #implied

    -- для использования в иерархических меню --

    value cdata #implied

    -- значения по умолчанию содержимого элемента -->

    <!element textarea - - (#pcdata)

    -- многострочное текстовое поле -->

    <!attlist textarea %attrs;

    -- %coreattrs, %i18n, %events --

    name cdata #implied

    rows number #required

    cols number #required

    disabled (disabled) #implied

    -- недоступно в данном контексте --

    readonly (readonly) #implied

    tabindex number #implied

    -- номер позиции в меню --

    accesskey %character; #implied

    -- клавиша доступа --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен --

    onselect %script; #implied

    -- некоторая часть текста выделена --

    onchange %script; #implied

    -- значение элемента изменилось --

    %reserved;

    -- зарезервировано на будущее -->

    <!-- #pcdata служит для решения проблем смешанного содержимого, в спецификации допустим только пробел! -->

    <!element fieldset - - (#pcdata,legend,(%flow;)*)

    -- группа управлений формой -->

    <!attlist fieldset %attrs;

    -- %coreattrs, %i18n, %events -- >

    <!element legend - - (%inline;)*

    -- легенда поля -->

    <!entity % lalign "(top|bottom|left|right)">

    -- выравнивание -->

    <!attlist legend %attrs;

    -- %coreattrs, %i18n, %events --

    accesskey %character; #implied

    -- клавиша доступа -- >

    <!element button - - (%flow;)* -(a|%formctrl;|form|fieldset)

    -- кнопка нажатия -->

    <!attlist button %attrs;

    -- %coreattrs, %i18n, %events --

    name cdata #implied

    value cdata #implied

    -- посылается серверу при представлении --

    type (button|submit|reset) submit

    -- для использования в качестве кнопки в форме --

    disabled (disabled) #implied

    -- не доступно в данном контексте --

    tabindex number #implied

    -- номер позиции в меню --

    accesskey %character; #implied

    -- клавиша доступа --

    onfocus %script; #implied

    -- элемент выделен --

    onblur %script; #implied

    -- элемент не выделен --

    %reserved;

    -- зарезервировано на будущее -- >

    <!--===================== Таблицы ======================-->

    <!-- Стандарт таблиц ietf HTML, см. [rfc-1942] -->

    <!-- Атрибут border устанавливает толщину рамки вокруг таблицы. Единицы измерения по умолчанию пиксели. Атрибут frame специфицирует то, какую часть рамки вокруг таблицы следует отображать. Значение "border" включено для обеспечения обратной совместимости с <table border>, который выдает frame=border и border=implied. Для <table border=1> вы получите border=1 и frame=implied. В этом случае, представляется разумным считать, что frame=border для обратной совместимости с уже существующими броузерами. -->

    <!entity % tframe "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
    <!-- Атрибут rules определяет, какие линии должны быть проведены между ячейками:

    Если rules отсутствуют, то предполагается:

    "none", если border отсутствует или =0, в противном случае "all" -->
    <!entity % trules "(none | groups | rows | cols | all)">
    <!-- горизонтальное размещение таблицы в документе -->
    <!entity % talign "(left|center|right)">
    <!-- Атрибуты горизонтального выравнивания для содержимого ячеек -->
    <!entity % cellhalign "align (left|center|right|justify|char) #implied

    char %character; #implied

    -- символ выравнивания, напр. символ=':' --

    charoff %length; #implied

    -- смещение символа выравнивания --" >

    <!-- атрибуты вертикального выравнивания для содержимого -->
    <!entity % cellvalign "valign (top|middle|bottom|baseline) #implied" >
    <!element table - -

    (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>

    <!element caption - - (%inline;)*

    -- Название таблицы -->

    <!element thead - o (tr)+

    -- Заголовок таблицы -->

    <!element tfoot - o (tr)+

    -- Подпись под таблицей -->

    <!element tbody o o (tr)+

    -- Тело таблицы -->

    <!element colgroup - o (col)*

    -- Группа колонок таблицы -->

    <!element col - o empty

    -- Колонка таблицы -->

    <!element tr - o (th|td)+

    -- Строка таблицы -->

    <!element (th|td) - o (%flow;)*

    -- Заголовок ячейки, данные ячейки таблицы -->

    <!attlist table

    -- Элемент таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    summary %text; #implied

    -- цель/структура для речевого вывода --

    width %length; #implied

    -- ширина таблицы --

    border %pixels; #implied

    -- управляет шириной рамки вокруг таблицы --

    frame %tframe; #implied

    -- какую часть таблицы отображать--

    rules %trules; #implied

    -- линии между строками и колонками --

    cellspacing %length; #implied

    -- зазор между ячейками --

    cellpadding %length; #implied

    -- зазор внутри ячеек --

    align %talign; #implied

    -- положение таблицы по отношению к окну --

    bgcolor %color; #implied

    -- фоновый цвет ячеек таблицы --

    %reserved;

    -- зарезервировано на будущее --

    datapagesize cdata #implied

    -- зарезервировано на будущее -- >

    <!entity % calign "(top|bottom|left|right)">

    <!attlist caption %attrs;

    -- %coreattrs, %i18n, %events -- >

    <!-- Элемент colgroup группирует набор элементов col. Он позволяет сгруппировать несколько семантически зависимых колонок вместе. -->

    <!attlist colgroup %attrs;

    -- %coreattrs, %i18n, %events --

    span number 1

    -- число колонок в группе по умолчанию --

    width %multilength; #implied

    -- значение ширины по умолчанию для вложенных col --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    <!-- Элементы col определяют свойства выравнивания для ячеек в одной или нескольких колонках.
    Атрибут width специфицирует ширину колонок, напр.

    width=64

    ширина в пикселях

    width=0.5*

    относительная ширина 0.5

    Атрибут span заставляет атрибуты одного элемента col работать для нескольких колонок. -->

    <!attlist col

    -- группы колонок и свойства --

    %attrs;

    -- %coreattrs, %i18n, %events --

    span number 1

    -- атрибуты col воздействуют на n колонок --

    width %multilength; #implied

    -- спецификация ширины колонки --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    <!-- Используйте thead для дублирования заголовков при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием.

    Используйте tfoot для дублирования подписи под таблицей при продолжении таблицы на нескольких страницах, или для статического заголовка для секций tbody со скролированием.

    Используйте секции tbody, когда необходимы разделительные линии между группами строк в таблице. -->

    <!attlist (thead|tbody|tfoot)

    -- секция таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках--

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    <!attlist tr

    -- строка таблицы --

    %attrs;

    -- %coreattrs, %i18n, %events --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    bgcolor %color; #implied

    -- цвет фона для строки -- >

    <!-- scope проще, чем осевые атрибуты для обычных таблиц -->
    <!entity % scope "(row|col|rowgroup|colgroup)">
    <!-- th для заголовков, td для данных a, но для ячеек используется td -->

    <!attlist (th|td)

    -- заголовок или данные ячейки --

    %attrs;

    -- %coreattrs, %i18n, %events --

    abbr %text; #implied

    -- сокращение для ячейки заголовка --

    axis cdata #implied

    -- имена групп связанных заголовков --

    headers idrefs #implied

    -- список id для ячеек заголовка

    scope %scope; #implied

    -- область, перекрываемая ячеками заголовка --

    rowspan number 1

    -- число строк в ячейке --

    colspan number 1

    -- число колонок в ячейке --

    %CEllhalign;

    -- горизонтальное выравнивание в ячейках --

    %CEllvalign;

    -- вертикальное выравнивание в ячейках -- >

    nowrap (nowrap) #implied

    -- подавление разрыва слов --

    bgcolor %color; #implied

    -- цвет фона ячейки --

    width %pixels; #implied

    -- ширина ячейки --

    height %pixels; #implied

    -- высота ячейки -- >

    <!--=================== Рамки документа ====================-->

    <!-- Модель содержимого для HTML-документа зависит от того, следует ли за head элемент frameset или body. Широко распространенное отсутствие начальной метки body делает непрактичным определение модели содержимого без использования помеченной секции. -->
    <!-- Переключатель функций для набора рамок документов -->
    <!entity % html.frameset "ignore">
    <![ %html.frameset; [
    <!element frameset - - ((frameset|frame)+ & noframes?) - разделение окна -->

    <!attlist frameset %coreattrs;

    -- id, class, style, title --

    rows %multilengths; #implied

    -- список длин, по умолчанию 100% (1 строка) --

    cols %multilengths; #implied

    -- список длин, по умолчанию 100% (1 колонка) --

    onload %script; #implied

    -- все рамки были загружены --

    onunload %script; #implied

    -- все рамки удалены -- >

    ]]>
    <![ %html.frameset; [
    <!-- резервные имена рамок начинаются с "_" в противном случае с буквы -->
    <!element frame - o empty -- субокно -->
    <!attlist frame

    %coreattrs;

    -- id, class, style, title --

    longdesc %uri; #implied -- указатель на длинное описание (complements title) --

    name cdata #implied

    -- имя рамки для обращений --

    src %uri; #implied

    -- источник содержимого рамки --

    frameborder (1|0) 1

    -- запрос границ рамки? --

    marginwidth %pixels; #implied

    -- ширины полей в пикселях --

    marginheight %pixels; #implied

    -- высота поля в пикселях --

    noresize (noresize) #implied -- разрешить пользователям изменить размер рамок? --

    scrolling (yes|no|auto) auto

    -- есть или нет полоса прокрутки -- >

    ]]>
    <!element iframe - - (%flow;)* -- inline subwindow -->
    <!attlist iframe %coreattrs; -- id, class, style, title --

    longdesc %uri; #implied

    -- указатель на длинное описание --

    name cdata #implied

    -- имя рамки для обращений --

    src %uri; #implied

    -- источник содержимого рамки --

    frameborder (1|0) 1

    -- запрос границ рамки? --

    marginwidth %pixels; #implied

    -- ширины полей в пикселях --

    marginheight %pixels; #implied

    -- высота поля в пикселях --

    scrolling (yes|no|auto) auto

    -- есть или нет полоса прокрутки --

    align %ialign; #implied -- вертикальное или горизонтальное выравнивание--
    height %length; #implied

    -- высота рамки --

    width %length; #implied

    -- ширина рамки -- >

    <![ %html.frameset; [
    <!entity % noframes.content "(body) -(noframes)">
    ]]>
    <!entity % noframes.content "(%flow;)*">
    <!element noframes - - %noframes.content;
    < -- контейнер альтернативного сообщения для отображения без поддержки рамок -->
    <!attlist noframes %attrs; -- %coreattrs, %i18n, %events -- >

    <!--================== Заголовок документа ==================-->
    <!-- %head.misc; определены ранее как "script|style|meta|link|object" -->
    <!entity % head.content "title & base?">
    <!element head o o (%head.content;) +(%head.misc;) -- Заголовок документа -->

    <!attlist head %i18n;

    lang, dir

    profile %uri; #implied

    -- именованный словарь мета инфо -- >

    <!-- Элемент title не рассматривается как часть текста. Он должен быть отображен, например, как заголовок страницы или окна. У документа должен быть только один заголовок. -->
    <!element title - - (#pcdata) -(%head.misc;) -- заголовок документа -->
    <!attlist title %i18n>
    <!element isindex - o empty -- однострочное сообщение - подсказка -->
    <!attlist isindex

    %coreattrs;

    -- id, class, style, title --

    %i18n;

    -- lang, dir --

    prompt %text; #implied

    -- сообщение-подсказка -->

    <!element base - o empty -- базовый uri документа -->
    <!attlist base href %uri; #required -- uri, выполняющий функцию базового идентификатора -- >

    target %frametarget; #implied

    -- отображать в этой рамке -- >

    <!element meta - o empty

    -- общая метаинформация -->

    <!attlist meta %i18n;

    -- lang, dir, для использования с содержимым --

    http-equiv name #implied

    -- имя заголовка http отклика --

    name name #implied

    -- имя метаинформации --

    content cdata #required

    -- ассоциированная информация --

    scheme cdata #implied

    -- выбранная форма содержимого -- >

    <!element style - - %stylesheet

    -- стилевое инфо -->

    <!attlist style %i18n;

    -- lang, dir, для использования в заголовке --

    type %contenttype; #required

    -- тип содержимого стилевого языка --

    media %mediadesc; #implied

    -- предназначено для работы с этими средами --

    title %text; #implied

    -- рекомендуемый title -- >

    <!element script - - %script; -- декларации скрипта -->
    <!attlist script charset %charset; #implied -- символьное кодирование подключенного ресурса --

    type %contenttype; #required

    -- тип содержимого языка скрипта --

    language cdata #implied -- предопределенное имя языка скрипта --

    src %uri; #implied

    -- uri внешнего скрипта --

    defer (defer) #implied

    -- ua может отложить исполнение скрипта --

    event cdata #implied

    -- зарезервировано на будущее --

    for %uri; #implied

    -- зарезервировано на будущее -- >

    <!element noscript - - (%block;)+ -- альтернативный текст для случая отображения без поддержки скриптов -->

    <!attlist noscript %attrs; -- %coreattrs, %i18n, %events -- >
    <!--================== Структура документа ===================-->
    <!entity % version "version cdata #fixed '%html.version;`">
    <!entity % html.content "head, body">
    <!element html o o (%html.content;) -- корневой элемент документа -->
    <!attlist html %i18n; -- lang, dir -- >

    30. Определение типа документа frameset

    <!-- Это HTML 4.0 frameset DTD, который должен использоваться для документов с рамками. Этот DTD идентичен переходному DTD HTML 4.0 за исключением модели содержимого "html" элемента: в документах с рамками, элемент "frameset" замещает элемент "body".

    Дополнительная информация о HTML 4.0 доступна по адресу:

    www.w3.org/tr/rec-html40. -->

    <!entity % html.version "-//w3c//dtd HTML 4.0 frameset//en" -- Типовое использование:

    <!doctype html public "-//w3c//dtd html 4.0 frameset//en"
    "http://www.w3.org/tr/rec-html40/frameset.dtd">
    <html>
    <head>
    ...
    </head>
    <frameset>
    ...
    </frameset>
    </html>
    -->
    <!entity % html.frameset "include">
    <!entity % html4.dtd public "-//w3c//dtd html 4.0 transitional//en">
    %html4.dtd;

    31. Эталонные символьные объекты в HTML 4.0
    31.1. Введение

    Эталонные символьные объекты представляют собой SGML конструкцию, которая соответствует набору символов документа. Эта версия HTML поддерживает несколько наборов эталонных последовательностей символов:

    • Символы ISO 8859-1 (Latin-1). В соответствии с секцией 14 RFC-1866, набор Latin-1 был расширен с тем, чтобы покрыть всю правую часть ISO-8859-1 (все позиции кодов с 1 в старшем бите), включая широко используемые &nbsp;, &copy; и &reg;. Имена символьных объектов взяты из приложений SGML (определено в ISO8879).

    • Символы, математические символы и греческие буквы. Эти символы могут быть представлены глифами в шрифте adobe "symbol".
    • Символы разметки (markup) и символы интернационализации (напр., для двунаправленного текста).

    Следующие разделы представляют собой полные списки эталонных символьных объектов. Хотя по соглашению ISO10646 комментарии пишутся большими буквами, мы для целей лучшей читаемости преобразовали их в строчные.

    31.2. Эталонные символьные объекты для символов ISO 8859-1

    Эталонные символьные объекты в этой секции формируют символы, чьи цифровые эквиваленты должны поддерживаться агентами пользователя HTML 2.0. Таким образом, эталонный символьный объект &divide; более удобная форма, чем &#247; для получения знака деления (/).

    Чтобы поддержать эти именованные объекты агенты пользователя должны только распознать имя объекта и преобразовать его в символ из таблицы ISO88591.

    Символ 65533 (FFFD в шестнадцатеричной нотации) является последним допустимым символом в UCS-2. 65534 (fffe в шестнадцатеричной нотации) не имеет какого-либо соответствия и зарезервирован для "неразрывного пробела нулевой ширины" для целей детектирования порядка байт. 65535 (FFFF в шестнадцатеричной нотации) вообще не имеет смысла.

    32. Приложение А
    Отличия html 3.2 и html 4.0
    Изменения в элементах
    Новые элементы

    Новыми элементами в HTML 4.0 являются: abbr, acronym, bdo, button, col, colgroup, del, fieldset, frame, frameset, iframe, ins, label, legend, noframes, noscript, object, optgroup, param, s (не рекомендуемый), span, tbody, tfoot, thead и q.

    Не рекомендуемые элементы

    Следующие элементы являются не рекомендуемыми: applet, basefont, center, dir, font, isindex, menu, strike и u.

    Устаревшие элементы

    Следующие элементы являются устаревшими: listing, plaintext, и xmp. Вместо них разработчикам следует использовать элемент pre.

    Изменения в атрибутах

    • Почти все атрибуты, которые специфицируют представление HTML-документа (напр., colors, alignment, fonts, graphics, и т.д.) объявлены не рекомендуемыми, предпочтение отдается стилевым листам.
    • Атрибуты id и class позволяют разработчику присвоить имя и класс информации элементам для стилевых листов, для скриптов, для деклараций объектов и т.д..

    Изменения в доступе

    В HTML 4.0 введено много изменений для обеспечения доступа, включая:

    • Атрибут title может быть теперь установлен почти для любого элемента.
    • Разработчик может выдавать длинные описания таблиц, изображений и рамок.

    Изменения для мета данных

    Разработчики могут теперь специфицировать профайлы, которые выдают объяснения по поводу мета данных, заданных элементами meta или link.

    Изменения для текста

    • Новые возможности интернационализации позволяют разработчикам специфицировать язык документа и направление текста.
    • Элементы ins и del позволяют разработчикам помечать изменения, внесенные в документ.
    • Элементы ABBR и acronym позволяют разработчикам помечать сокращения и акронимы в своих документах.

    Изменения для связей

    Атрибут ID делает любой элемент якорем назначения связи.

    Изменения для таблиц

    Модель таблиц HTML 4.0 выросла из более ранней концепции HTML+ и первоначального проекта HTML 3.0. Предыдущая модель была расширена в ответ на следующие запросы от информационных провайдеров:

    • Разработчики могут специфицировать таблицы, которые отображаются агентом пользователя по мере получения данных.
    • Разработчики могут специфицировать таблицы, которые доступны пользователям с не визуальными агентами пользователя.
    • Разработчики могут специфицировать таблицы, с фиксированными заголовками и подписями. Агенты пользователя могут использовать преимущества этого решения при скролировании больших таблиц или при отображении таблиц в многостраничном формате.

    Модель таблиц HTML 4.0 удовлетворяет требованиям опционного выравнивания по колонкам, предоставляется больше гибкости при спецификации рамок и разделительных линий в таблицах. Ожидается, однако, что стилевые листы в самом ближайшем будущем возьмут на себя функции формирования и таблиц.

    Кроме того главной целью является обеспечение обратной совместимости с широко распространенными приложениями таблиц Netscape. Другой целью было упрощение импорта таблиц совместимых с моделью SGML cals. Последний проект делает атрибут выравнивания совместимым с последней версией наиболее популярных броузеров.

    Для формирования групп колонок с различной шириной и свойствами выравнивания введен новый элемент colgroup, который может работать с одним или более элементов col.

    Стилевой атрибут включен как средство расширения свойств, связанных с краями внутренней области групп ячеек. Например, стиль линии: точечная, двойная, тонкая/толстая и т.д.; цвет заполнения внутренней области; поля ячейки и шрифты.

    Атрибуты рамки и разделительных линий модифицированы для исключения конфликтов имен с sgml, а также для блокировки влияния совпадения имен атрибутов align и valign. Эти изменения стимулировались желанием исключить в будущем проблемы, если спецификация будет расширена и разрешит применение атрибутов рамок и разделительных линий другими элементами таблицы.

    Изменения для изображений, объектов и карт изображений

    • Элемент object позволяет включать объекты.
    • Элементы iframe и object позволяют разработчикам создавать встраиваемые документы.
    • Атрибут alt необходим для элементов img и area.
    • Механизм создания карт изображения позволяет разработчикам создавать более доступные карты. Модель содержимого элемента map по этой причине была изменена.

    Изменения для форм

    Данная спецификация вводит несколько новых атрибутов и элементов, для работы с формами:

    • Атрибут ключа доступа позволяет разработчику специфицировать прямой доступ к управлению формой через клавиатуру.
    • Атрибут disabled позволяет разработчику сделать управление формой заблокированным.
    • Атрибут readonly позволяет разработчику запретить какие-либо изменения в управлении формой.
    • Элемент label устанавливает связь между меткой и конкретным видом управления формой.
    • Элемент fieldset группирует связанные по смыслу поля в соответствии элементом legend. Оба эти новые элемента позволяют лучше организовать процесс отображения и улучшить интерактивность. Броузеры, ориентированные на воспроизведение речи при описании формы могут учитывать, вводимые этими элементами метки (ярлыки).
    • Новый набор атрибутов в сочетании со скриптами позволяют разработчику форм верифицировать данные, вводимые пользователем.
    • Элементы button и input с типом "button" могут использоваться в комбинации со скриптами для существенного обогащения возможностей форм.
    • Элемент optgroup позволяет разработчику группировать опции в меню select, который весьма важен для обеспечения доступа к форме.
    • Дополнительные изменения для интернационализации.

    Изменения для стилевых листов

    HTML 4.0 поддерживает больший набор описателей среды, так что разработчики могут писать стилевые листы, ориентированные на определенные внешние устройства.

    Изменения для рамок

    HTML 4.0 поддерживает документы со встроенными рамками.

    Изменения для скриптов

    Многие элементы имеют атрибуты событий, которые сопряжены со скриптами, исполняемыми при наступлении такого события (напр., при загрузке документа, при нажатии клавиши мышки и т.д.).

    Изменения для интернационализации

    HTML 4.0 интегрирует рекомендации RFC-2070 для интернационализации HTML.

    Однако, эта спецификация и RFC-2070 отличаются в следующих пунктах:

    • Атрибут accept-charset был специфицирован скорее для элемента form, чем для textarea и input.
    • Спецификация HTML 4.0 дает дополнительные разъяснения для двунаправленных алгоритмов укладки текста.
    • Использование cdata для определения элементов script и style не сохраняет возможности перекодировки документа, как это описано в RFC-2070.

    33. Приложение b
    Рабочие характеристики, приложения и заметки для разработчиков.

    Следующие замечания являются информативными, а не нормативными.

    33.1. Замечания по поводу некорректных документов

    Эта спецификация не определяет, как агент пользователя должен обрабатывать случаи ошибок, включая то, как агент пользователя должен себя вести, встретив элемент, атрибут, значение атрибута или объект, не специфицированный в данном документе.

    Однако, для облегчения экспериментов и взаимосогласованности между различными приложениями разных версий HTML, рекомендуется следующее:

    • Если агент пользователя встретил незнакомый элемент, он должен попытаться отобразить (render) его содержимое.
    • Если агент пользователя встретил незнакомый атрибут, он должен его игнорировать всю спецификацию этого атрибута (напр., атрибут и его значение).
    • Если агент пользователя встретил незнакомое значение атрибута, он должен использовать значение атрибута по умолчанию.
    • Если он встретил не декларированный объект, объект должен восприниматься как символьная информация.

    Рекомендуется также, чтобы агенты пользователя обеспечивали информирование пользователя о перечисленных выше случаях.

    Так как агенты пользователя могут реагировать на ошибки по-разному разработчики и пользователи не должны предполагать какое-то определенное поведение системы при столкновении с ошибкой.

    Спецификация HTML 2.0 (RFC-1866) предполагает, что многие агенты пользователя HTML 2.0 считают, что документы, не начинающиеся с декларации типа, являются документами HTML 2.0. Как показывает практика, это плохое предположение, данная спецификация не рекомендует такое поведение агентов пользователя.

    Для целей совместимости разработчики не должны "расширять" HTML за пределы доступных механизмов SGML (напр., расширяя DTD, добавляя новые наборы объектов, и т.д.).

    34. Специальные символы в значениях атрибута uri
    34.1. Не-ASCII символы в значениях атрибута URL

    Хотя URI не содержат не-ASCII значений, разработчики иногда специфицируют их в атрибутах, где должен лежать URI (напр., определенные с помощью %uri в DTD). Например, следующее значение Href нелегально:

    <a href="http://foo.org/håkon">...</a>

    Рекомендуется, чтобы агент пользователя воспринял следующее соглашение для обработки не-ASCII символов в следующих случаях:

    1. Представлять каждый символ в UTF-8 (см. RFC-2044) как один или более байт.
    2. Обходить эти байты с помощью механизма URI (напр., путем конверсии каждого байта в %HH, где HH представляет собой шестнадцатеричное представление значения байта).

    Эта процедура выдает в результате синтаксически корректный uri (как это определено в RFC-1738, секция 2.2 или RFC-2141, секция 2), это не зависит от метода кодировки символов.

    Замечание. Некоторые старые агенты пользователя обрабатывают URI в HTML тривиально, используя байты символов в том виде, в котором они записаны в документе. Некоторые старые HTML-документы полагаются на эту практику и прерывают свою работы при перекодировке (transcode). Агенты пользователя, которые хотят работать с этими старыми документами должны при получении URI, содержащего нестандартные символы, сначала использовать преобразование, базирующееся на UTF-8. Только если полученное в результате URI не удается распознать, они должны попробовать сформировать URI, базируясь на байтах символов в кодировке полученного документа.

    Замечание. То же самое преобразование, базирующееся на UTF-8 должно быть применено к значениям атрибутов имен для элемента A.

    34.2. Символ & в значениях атрибута URI

    URI, который создан при выдаче формы, может быть использован в качестве связи типа якорь (напр., атрибут Href для элемента A). К сожалению использование символа "&" для разделения полей формы противоречит его применению в значениях атрибутов SGML для выделения символьных объектов. Например, для того чтобы использовать URI "http://host/?x=1&y=2" в качестве связующего URI, его следует записать в виде <a Href="http://host/?x=1&#38;y=2"> или <a Href="http://host/?x=1&amp;y=2">.

    Рекомендуется, чтобы пользователи сервера http, и в частности, пользователи CGI поддерживали применение ";" вместо "&" с целью избавления разработчиков от обхода символов "&".

    35. Замечания об использовании sgml

    Разрывы строк

    SGML специфицирует то, что разрыв строки сразу после начальной метки должен игнорироваться, также как и разрыв строки непосредственно перед конечной меткой. Это приложимо ко всем HTML-элементам без исключения. Следующие два HTML-примера должны отображаться идентично:

    <p> Томас смотрит телевизор.</p>
    <p>
    Томас смотрит телевизор.
    </p>

    Аналогично идентичными должны быть и следующие два примера:

    <a>my favorite website</a>
    <a>
    my favorite website
    </a>

    36. Спецификация не HTML-данных

    Текст скрипта и стилевые данные могут появиться в содержимом элемента или в качестве значения атрибута.

    Замечание. DTD определяет данные скриптов и стилей как Cdata для содержимого элементов и значения атрибутов. Правила SGML не позволяют использование символьных объектов в Cdata элементах, но допускают их в Cdata значений атрибутов. Разработчикам следует обращать особое внимание на случаи обмена данными скриптов и стилей методом вырезания и вставления между элементами и значениями атрибутов.

    Эта асимметрия означает также, что при кросскодировании (transcoding) из богатого кодового набора символов в более бедный, кодировщик не может просто заменить неконвертируемые символы в скрипте или стилевых данных соответствующим цифровыми кодами. Он должен произвести разборку (анализ) HTML-документа и узнать все о каждом скрипте и стилевом языке для того, чтобы правильно обработать соответствующие данные.

    Содержимое элемента

    Когда скрипт или стилевые данные являются содержимым элемента (script и style), данные начинаются немедленно после начальной метки элемента и кончаются на первом etago ("</") разграничителе, за которым следует имя символа ([a-za-z]), это может быть и не конечной меткой элемента. Разработчики должны избегать использования строк "</" в теле элемента.

    Нелегальный пример:

    Следующий текст скрипта содержит недопустимую последовательность "</" (в качестве части "</em>") перед конечной меткой script:

    <script type="text/javascript">
    document.write ("<em>this won't work</em>")
    </script>

    В javascript, этот код может быть представлен корректно, путем сокрытия разграничителя Etago перед начальным символом имени SGML:

    <script type="text/javascript">
    document.write ("<em>this will work<\/em>")
    </script>

    В tcl, можно выполнить это следующим образом:

    <script type="text/tcl">
    document write "<em>this will work<\/em>"
    </script>

    В vbscript эта проблема может быть обойдена с помощью функции chr():

    "<em>this will work<" & chr(47) & "em>"

    Значения атрибутов

    Когда скриптовые или стилевые данные представляют собой значение атрибута, разработчики должны избегать случаев использования одиночных или двойных кавычек в значениях атрибута в соответствии с рекомендациями языка скрипта или описания стиля. Разработчики должны также избегать включения "&", если "&" не означает начало символьного объекта.

    * '"' should be written as "&quot;" or "&#34;"
    * '&' should be written as "&amp;" or "&#38;"

    Таким образом, например, можно написать:

    <input name="num" value="0"
    onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">

    37. Особенности sgml с ограниченной поддержкой

    Системы SGML, соответствующие ISO-8879, должны поддерживать определенное число возможностей, которые не слишком широко поддерживаются агентами пользователя HTML. Разработчикам рекомендуется не использовать все эти возможности.

    38. Булевы атрибуты

    Разработчики должны учитывать, что многие агенты пользователя распознают не все булевы атрибуты. Например, разработчик может захотеть специфицировать:

    <option selected>
    вместо
    <option selected="selected">

    39. Помеченные секции

    Помеченные секции играют роль, схожую с конструкцией #ifdef препроцессоров языка c.

    <![include[
    <!-- это будет включено -->
    ]]>
    <![ignore[
    <!-- это будет проигнорировано -->
    ]]>

    SGML определяет также использование помеченных секций для содержимого Cdata, в пределах которого "<" не рассматривается как начало метки, напр.,

    <![cdata[

    <an> example of <sgml> markup that is
    not <painful> to write with < and such.
    ]]>

    Указание на то, что агент пользователя не распознал помеченную секцию, является появление символьной последовательности "]]>", которая будет отображена, когда агент пользователя ошибочно использует первый символ ">" в качестве конечной метки, начинающейся с "<![".

    Инструкции обработки

    Инструкции обработки представляют собой механизм выявления платформо зависимых идиом. Команды обработки начинаются с последовательности символов <? и завершаются >.

    <?instruction >

    Например:

    <?>
    <?style tt = font courier>
    <?page break>
    <?experiment> ... <?/experiment>

    Разработчики должны учитывать то, что многие агенты пользователя отображают (render) инструкции обработки как часть текста документа.

    Сжатая форма разметки документа (markup)

    Некоторые конструкции SGML shorttag сокращают объем данных, вводимых с клавиатуры. Хотя эти конструкции технически не вводят неопределенности, они уменьшают ясность документов, особенно когда язык усовершенствуется и добавляются новые элементы. Документы, которые используют их, являются SGML документами, но могут не работать со многими существующими средствами HTML.

    Конструкции shorttag, о которых идет речь, выглядят следующим образом:

    * net tags:
    <name/.../
    * closed start tag:
    <name1<name2>
    * empty start tag:
    <>
    * empty end tag:
    </>

    40. Заметки по индексному поиску
    40.1. Определение языка документа

    В глобальном контексте WWW важно знать, какой язык использован при написании документа. Если вы подготовили перевод документа на другие языки, вам следует воспользоваться для ссылки на них элементом Link. Это позволяет индексной поисковой системе предложить пользователям результат на языке, который они предпочитают, вне зависимости от того, как составлен запрос. Например, следующие связи предлагают французскую и немецкую альтернативу поисковой системы.

    <link rel="alternate"
    type="text/html"
    href="mydoc-fr.html" hreflang="fr"
    lang="fr" title="la vie souterraine">
    <link rel="alternate"
    type="text/html"
    href="mydoc-de.html" hreflang="de"
    lang="de" title="das leben im untergrund">

    Обеспечение ключевыми словами и описаниями

    Некоторые системы индексации ищут META-элементы, которые определяют список ключевых слов или фраз, разделенных запятыми, или которые дают краткие описания. Поисковая система может представить эти ключевые слова в качестве результата поиска. Значение атрибута имени, которое ищется атрибутом поиска, не определено спецификацией. Рассмотрим такие примеры,

    <meta name="keywords" content="vacation, greece, sunshine">
    <meta name="description" content="idyllic european vacations">

    Выделение начала коллекции

    Собрание документов, где ищутся слова, часто преобразуется в собрание HTML-документов. Для результатов поиска полезно указать начало такого собрания. Вы можете помочь системе поиска. Использовав элемент Link с rel="start" и атрибутом title attribute, как в:

    <link rel="begin"
    type="text/html"
    href="page1.html"
    title="general theory of relativity">

    Роботы с инструкцией индексирования

    Люди могут удивиться, узнав, что их сайт был индексирован роботом, хотя роботу не было разрешено посещать некоторые критические секции. Многие web-роботы предлагают возможности администраторам сайтов и провайдерам информации ограничить возможности роботов. Это достигается с помощью двух механизмов: файла "robots.txt" и элемента meta в HTML-документах, как это показано ниже.

    41. Поисковые роботы
    Файл robots.txt

    Когда робот посещает сайт, скажем http://www.foobar.com/, он сначала проверяет наличие http://www.foobar.com/robots.txt. Если он нашел этот документ, он анализирует его содержимое и выясняет, разрешен ли допуск к документу. Вы можете указать, что файл robots.txt доступен только для специальных роботов, и запретить доступ к определенным каталогам и файлам. Ниже приведен пример файла robots.txt, который препятствует всем роботам посещение всего сайта.

    user-agent: * # applies to all robots
    disallow: / # disallow indexing of all pages

    Робот просто будет искать "/robots.txt" uri на вашем сайте, где сайт определен как HTTP-сервер, работающий на определенной ЭВМ с заданным номером порта. Ниже приведены примеры места положения robots.txt:

    Сайт URI

    URI для robots.txt

    http://www.w3.org/

    http://www.w3.org/robots.txt

    http://www.w3.org:80/

    http://www.w3.org:80/robots.txt

    http://www.w3.org:1234/

    http://www.w3.org:1234/robots.txt

    http://w3.org/

    http://w3.org/robots.txt

    Должен быть только один файл "/robots.txt" на сайт. В частности, не следует помещать файл "robots.txt" в пользовательские каталоги, так как робот туда не заглядывает. Если вы хотите, чтобы пользователи создали свои собственные "robots.txt", вы должны их объединить в один общий файл "/robots.txt". Если вы не хотите это делать, пользователи могут вместо этого использовать robots meta tag.

    Некоторые советы: URI чувствительны к набору строчными или прописными буквами, а строка "/robots.txt" должна быть набрана строчными буквами. Пустые строки не допустимы.

    Должен быть только одно поле "user-agent" на рекорд. Робот должен либерально интерпретировать это поле. Если значение равно "*", рекорд описывает политику доступа любого робота по умолчанию (робот не соответствует ни одному другому рекорду). Не допускается более одного такого рекорда в файле "/robots.txt".

    Поле "disallow" специфицирует URI, который не должен посещаться. Это может быть полный проход, частичный проход, любой URI, который начинается с этой величины, не будет доступен. Например,

    disallow: /help запрещает как /help.html так и /help/index.html, в то время как
    disallow: /help/ запрещает посещение /help/index.html, но позволяет /help.html.

    Пустое значение для "disallow", указывает, что все uri доступны. Хотя бы одно поле "disallow" должно присутствовать в файле robots.txt.

    41.1. Роботы и элементы meta

    Элемент meta позволяет HTML разработчикам сообщить приходящим роботам, можно ли индексировать документы. В ниже приведенном примере робот не должен ни индексировать документ, ни анализировать его связи.

    <meta name="robots" content="noindex, nofollow">

    Список терминов в содержимом включает в себя all, index, nofollow, noindex. Имена и содержимое значений атрибутов не зависит от регистра, использованного при наборе текста.

    Замечание. В начале 1997 только несколько роботов следовало этим правилам, но ожидается, что ситуация изменится в ближайшее время.

    42. Замечания о таблицах

    Модель таблиц HTML взята из исследований существующих моделей таблиц SGML. Модель выбрана из соображений простоты и возможностей дальнейшего расширения функций, если это потребуется.

    Важно, что модель таблиц HTML согласуется с большинством существующих средств их создания (напр., с текстовыми редакторами).

    43. Динамическое реформатирование

    Главным соображением при выработке модели таблиц HTML является то, что разработчик не должен заботиться о вариации размера таблиц пользователем или о его выборе шрифтов. Это делает рискованным задание ширины колонки в абсолютных единицах (пикселях). Вместо этого таблицы должны быть способны динамически приспосабливать размер таблицы к размерам имеющегося окна и к выбранным шрифтам. Разработчик может сформулировать пожелания относительно ширин колонок, но агент пользователя может и не следовать этим пожеланиям. Он должен обеспечить размер ячейки, достаточный для размещения самого крупного элемента.

    44. Инкрементное отображение

    Для больших таблиц или для медленных сетевых соединений пользователю важна возможность реализации инкрементного отображения таблицы. Агенты пользователя должны быть способны начать отображение таблицы до того, как будут получены все данные. Ширина окна по умолчанию для большинства агентов пользователя равна 80 символам, а графика для многих HTML страниц сконструирована с учетом этого значения. При специфицировании числа колонок, включая различные механизмы управления шириной колонок, разработчики могут подсказать агенту пользователя как организовать инкрементное отображение таблицы.

    Для инкрементного отображения броузер должен знать число колонок и их ширину. Ширина таблицы по умолчанию определяется размером текущего окна (ширина="100%"). Это значение может быть изменено путем установки атрибута width в элементе table. По умолчанию, все колонки имеют равные ширины, но вы можете специфицировать ширины колонок с помощью одного или нескольких элементов col.

    Последний пункт - число колонок. Некоторые люди предлагают ждать, пока первый ряд таблицы будет получен, но это может занять много времени, если ячейки содержат много материала. Имеет смысл, особенно для целей инкрементного отображения таблиц, задать разработчикам число колонок в таблице явно (в элементе table).

    Разработчикам нужен способ, сообщить агенту пользователя, следует ли использовать инкрементное отображение или изменить размер таблицы с тем, чтобы можно было разместить содержимое ячеек. В режиме двухпроходного определения размеров число колонок определяется при первом проходе. При инкрементном режиме сначала должно быть объявлено число колонок (с помощью элементов col или colgroup).

    45. Структура и презентация

    HTML различает структурную разметку, такую как параграфы и цитаты из идиом отображения (rendering idioms) таких как поля, шрифты, цвета, и т.д. Как это различие влияет на таблицы? С чисто теоретической точки зрения выравнивание текста внутри ячеек таблицы и определение границы между ячейками, проблема отображения, а не структуры. На практике полезно использовать обе возможности. Модель таблиц HTML оставляет большую часть управления отображением стилевым листам.

    Современные издательские системы предоставляют очень богатые возможности управления отображением таблиц. Эти спецификации предлагают разработчику возможность выбора класса стиля границ. Атрибут frame управляет наличием разграничительных линий вокруг таблицы, в то время как атрибут rules определяет выбор разделительных линий внутри таблицы. Стилевой атрибут может быть использован для спецификации информации, управляющей процессом отображения для индивидуальных элементов. Дополнительная информация может быть получена через элемент style в заголовке документа или из подключенного стилевого листа.

    46. Группы строк и колонок

    Таблицы рассматриваются как соединение опционной надписи и последовательность рядов, которые в свою очередь состоят из последовательности ячеек. Модель еще более дифференцирует заголовок и информационные ячейки и позволяет ячейкам занимать несколько рядов и колонок.

    Эта спецификация (модель таблиц cals) позволяет группировать ряды в секции заголовка, тела и основания. Она упрощает представление информации и может использоваться для повторения верхней и нижней секций при разбиении таблиц на несколько страниц, или для обеспечения фиксированного заголовка над панелью со скролированием текста. Это позволяет отображать нижнюю секцию, не дожидаясь пока вся таблица будет обработана.

    47. Доступность

    Модель таблиц HTML включает атрибуты для пометки каждой ячейки с целью высококачественного преобразования текста в голос. Те же самые атрибуты могут использоваться для поддержки автоматического обмена с базами данных и электронными таблицами.

    48. Рекомендуемые алгоритмы верстки

    Если присутствуют элементы col или colgroup, они специфицируют число колонок и таблица может быть отображена с использованием фиксированной раскладки. В противном случае будет применен автоматический алгоритм раскладки, описанный ниже.

    Если атрибут width не специфицирован, визуальные агенты пользователя должны предполагать значение по умолчанию, равное 100%.

    Рекомендуется, чтобы агенты пользователя увеличивали ширину таблицы за пределы, специфицированные width в случаях, когда содержимое может не поместиться. Агенты пользователя, которые корректируют значение, заданное width должны делать это в пределах разумного. Агенты пользователя могут выбрать переносы строк, когда горизонтальный скролинг не желателен или не практичен.

    Для целей раскладки агенты пользователя должны учитывать, что табличные надписи (специфицированные элементом caption) ведут себя подобно ячейкам таблицы. Каждая надпись является ячейкой, которая простирается через все колонки таблицы, если она размещена вверху или внизу таблицы, или через все ряды, если она находится справа или слева от таблицы.

    49. Фиксированные алгоритмы верстки

    Для этого алгоритма предполагается, что число колонок известно. Ширины колонок по умолчанию делаются равными. Разработчики могут поменять эти установки, задав относительные или абсолютные значения колонок с помощью элементов colgroup или col. Значение ширины по умолчанию равно расстоянию от левого до правого поля, но оно может быть скорректировано с помощью атрибута width в элементе table, или определено из абсолютных ширин колонок. Для того чтобы работать со смесью абсолютных и относительных ширин, сначала нужно выделить место для колонок с заданной абсолютной шириной. После этого, оставшееся пространство делится между колонками с учетом их относительных ширин.

    Сам по себе синтаксис таблицы не гарантирует взаимосогласованности значений атрибутов. Например, число элементов col и colgroup может не совпадать с числом колонок, используемых в таблице. Дополнительные проблемы возникают, когда колонки слишком узки и может произойти переполнение ячейки. Ширина таблицы, как это специфицировано элементами table или col может вызвать переполнение ячейки таблицы. Рекомендуется, чтобы агенты пользователя умели выходить из этого положения, например, путем переноса слов.

    В случае, когда переполнение ячейки вызывается словом, которое не может быть поделено, агент пользователя может рассмотреть возможность изменения ширин колонок и повторного отображения таблицы. В худшем случае, можно допустить обрубание слов, если вариации ширин колонок и скроллинг оказались невозможными. В любом случае, если содержимое ячейки разделено или обрублено, об этом должно быть сообщено пользователю соответствующим способом.

    50. Алгоритм авто выкладки

    Если число колонок не специфицировано элементами col и colgroup, тогда агент пользователя должен использовать алгоритм автоматической выкладки. Он использует два прохода по данным таблицы и линейно масштабирует размеры таблицы.

    При первом проходе запрещается разрыв строк и агент пользователя отслеживает минимальные и максимальные ширины для всех ячеек. Максимальная ширина задается самой длинной строкой. Так как разрыв строк запрещен, параграфы рассматриваются, как длинные строки, если не введены переносы строк с помощью элементов BR. Минимальная ширина задается наиболее широким текстовым элементом (словом, изображением, и т.д.) с учетом абзацев маркеров и пр. Другими словами необходимо определить минимальную ширину ячейки, которая необходима в пределах окна для того, чтобы ячейка не переполнилась. Допуская перенос слов, мы минимизируем необходимость горизонтального скролинга или обрубания содержимого ячейки.

    Этот процесс применим к любым вложенным таблицам. Минимальные и максимальные ширины ячеек для вложенных таблиц используются для определения минимальной и максимальной ширины этих таблиц, и, следовательно, таблиц их прародителей. Алгоритм является линейным и не зависит от глубины вложения.

    Минимальная и максимальная ширины ячейки используются для определения минимальной и максимальной ширины колонки. Эти значения в свою очередь служат для нахождения минимальной и максимальной ширины таблицы. Следует учитывать, что ячейки могут содержать вложенные таблицы, но это не усложняет программу сколько-нибудь значительно. Следующим шагом является определение ширин колонок в соответствии с доступным пространством (напр., зазором между левым и правым полями).

    Внешние ограничители таблицы и внутренние разделительные линии должны учитываться при определении ширин колонок. Имеется три варианта:

    1. Минимальная ширина таблицы равна или шире наличного пространства. В этом случае следует приписать минимальную ширину и разрешить агенту пользователя горизонтальный скролинг.
    2. Максимальная ширина таблицы укладывается в имеющееся пространство. В этом случае следует установить ширины колонок по максимуму.
    3. Максимальная ширина таблицы больше наличного пространства, а минимальная - меньше.

    Если ширина таблицы задана атрибутом width, агент пользователя пытается установить соответствующим образом ширины колонок.

    Если с помощью элемента col указаны относительные длины колонок, алгоритм может быть модифицирован так, что ширина колонок может превысить минимально объявленное значение для того, чтобы удовлетворить требования относительных ограничений. Элементы col должны рассматриваться только как рекомендации и ширины колонок не должны делаться меньше их минимальной ширины. Аналогично, колонки не должны делаться настолько широкими, что таблица не поместится в отведенное ей окно. Если элемент col специфицирует относительную ширину нуль, ширина колонки должна быть выбрана равной минимальной ширине.

    Если несколько ячеек в различных рядах одной и той же колонки используют выравнивание, тогда по умолчанию все такие ячейки должны быть выстроены в линию, вне зависимости от того, какой символ был использован для выравнивания.

    Выбор имен атрибутов. Предпочтительно выбрать значения для атрибута frame, согласующееся с атрибутом rules и параметрами выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, sgml требует нумеровать значения атрибутов, чтобы обеспечить их уникальность для каждого элемента, вне зависимости от имени атрибута. Это сразу создает проблемы для "none", "left", "right" и "all". Значения для атрибута frame были выбраны для исключения конфликтов с атрибутами rules, align, и valign.

    51. Замечания о формах
    Инкрементное отображение

    Инкрементное отображение документов, полученных по сети, создают некоторые проблемы, связанные с формами. Агенты пользователя должны позаботиться о том, чтобы форма не была передана серверу до тех пор, пока не получены все элементы формы.

    Если формы связаны со скриптами стороны клиента, создаются предпосылки для будущих проблем. Например, хандлер скриптов для данного поля может относиться к полю, которого пока не существует.

    52. Будущие проекты

    Данная спецификация определяет набор элементов и атрибутов, достаточно мощных, чтобы выполнить основные требования по генерации форм. Однако остается пространство для дальнейшего совершенствования. Например, следующие проблемы могут найти решение в будущем:

    • Диапазон типов полей формы слишком ограничен по сравнению с современными пользовательскими интерфейсами. Например, не существует возможности использования табуляции при вводе данных.
    • Серверы не могут корректировать поля в уже записанных формах, и вынуждены вместо этого передавать весь HTML-документ.

    Другим возможным расширением может стать атрибут usemap элемента input для использования в качестве карты изображения на стороне клиента, когда "type=image". Элемент area, соответствующий позиции, где была нажата кнопка мыши, должен будет выдать информацию, передаваемую серверу. Чтобы избежать необходимости модифицировать скрипты сервера, может оказаться разумным расширить возможности area в отношении передачи значений координат x и y для использования их элементом input.

    53. Заметки о скриптах

    Эта спецификация резервирует синтаксис для будущей поддержки скриптовых макро в атрибутах cdata HTML. Целью этого является допущение установки атрибутов, зависящих от свойств объектов, которые были записаны выше на странице. Синтаксис выглядит следующим образом:

    attribute = "... &{ macro body }; ... "

    Существующая практика скриптов

    Тело макро состоит из одного или более записей на языке скриптов. Точка с запятой, следующая за правой фигурной скобкой, всегда необходима, иначе правая фигурная скобка будет рассматриваться как часть текста макро.

    Обработка Cdata атрибутов производится следующим образом:

    1. Анализатор текста sgml вычисляет любой символьный объект SGML (напр., "&gt;").
    2. Далее скриптовые макросы обрабатываются интерпретатором скриптов.
    3. И, наконец, результирующая последовательность символов передается приложению для последующей обработки.

    Обработка макро имеет место, когда документ загружается, но эта процедура не повторяется, когда документ изменяется в размере или перезакрашивается.

    Не рекомендуемый пример:

    Ниже приведены примеры с использованием Javascript. Первый делает фон документа рэндомизованным:

    <body bgcolor='&{randomrbg};'>

    Возможно, вы хотите приглушить фон для просмотра в вечернее время:

    <body bgcolor='&{if(date.gethours > 18)...};'>

    Следующий пример использует javascript при установке координат для карты изображения на стороне клиента:

    <map name=foo>
    <area shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
    </map>

    Этот пример устанавливает размер изображения, базируясь на свойствах документа:

    <img src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">

    Вы можете установить URI для связи или изображения с помощью скрипта:

    <SCRIPT type="text/javascript">
    function manufacturer(widget) {
    ...
    }
    function location(manufacturer) {
    ...
    }
    function logo(manufacturer) {
    ...
    }
    </SCRIPT>
    <A href='&{location(manufacturer("widget"))};'>widget</A>
    <IMG src='&{logo(manufacturer("widget"))};' alt="logo">

    Последний пример показывает, как SGML CDATA атрибуты могут помещаться в одинарные или двойные кавычки. Если вы помещаете строку атрибута в одиночные кавычки, вы можете использовать двойные кавычки в качестве части строки атрибута. Другой подход связан с использованием &quot; для двухкавычечных меток:

    <IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

    53.1. Зарезервированный синтаксис для будущих скриптов

    Так как не существует гарантии того, что имя адресата рамки уникально, представляется разумным описать существующую практику нахождения имени адресата, заданного в рамке:

    1. Если имя адресата является зарезервированным именем, как это записано в нормативном тексте, следует использовать его так, как описано.
    2. В противном случае, следует выполнить поиск согласно иерархии рамок в окне, где содержится эта связь. Следует использовать первую рамку, имя которой соответствует искомому.
    3. Если такой рамки не найдено на этапе (2), используется этап 2 для каждого окна в послойном порядке, начиная с переднего плана. Поиск прекращается, когда найдена рамка с соответствующим именем.
    4. Если такой рамки не найдено на этапе (3), следует создать новое окно и присвоить ему имя адресата.

    54. Замечания о доступности

    Замечание. Следующий алгоритм генерации альтернативного текста может быть заменен рекомендациями W3C Web Accessibility Initiative Group. Для получения дополнительной информации предлагается ссылка [WAIGUIDE].

    Когда разработчик не устанавливает атрибут alt для элементов IMG или APPLET, агент пользователя должен предоставить альтернативный текст, который получается следующим способом:

    1. Если title был специфицирован, его значение должно использоваться в качестве альтернативного текста.
    2. В противном случае, если HTTP-заголовки предоставляют информацию о title, эта информация и должна использоваться в качестве альтернативного текста.
    3. В противном случае, если включенные объекты содержат текстовые поля (напр., GIF изображения содержат некоторые текстовые поля), информация из текстовых полей извлекается и используется в качестве альтернативного текста. Так как агенты пользователя для извлечения текстовых данных могут быть вынуждены заполучить сначала весь объект, пользовательские агенты могут воспользоваться каким-либо более экономным подходом.
    4. В противном случае, в отсутствии другой информации агенты пользователя должны воспользоваться именем файла (за вычетом расширения) в качестве альтернативного текста.

    Если разработчик не установил атрибут alt для элемента INPUT, агент пользователя должен получить альтернативный текст следующим образом:

    1. Если был специфицирован атрибут title, его значение должно использоваться в качестве альтернативного текста.
    2. В противном случае, если специфицировано имя, его значение используется как альтернативный текст.
    3. В противном случае (кнопки submit и reset), значение атрибута type должно использоваться в качестве альтернативного текста.

    55. Замечания о безопасности

    Якоря, встроенные изображения и все другие элементы, которые содержат URI в качестве параметров, могут вызвать повторное обращение к URI в ответ на ввод пользователя. В этом случае, следует рассмотреть соображения безопасности RFC-1738. Широко распространенные методы посылки запросов форм - HTTP и SMTP - обеспечивают ограниченную конфиденциальность. Провайдеры информации, которые запрашивают необходимые данные с помощью форм - точнее с помощью элементов INPUT, type="password" - должны позаботиться о том, чтобы сами пользователи учитывали возможность утечки конфиденциальной информации.

    55.1. Соображения безопасности для форм

    Агент пользователя не должен посылать какой-либо файл, который пользователь не указал явно, как подлежащий пересылке. Таким образом, агенты пользователя HTML должны требовать подтверждения для любых имен файлов по умолчанию, которые могут быть указаны значениями атрибутов элемента INPUT.

    Эта спецификация не содержит механизма шифрования данных. Раз файл загружен, агент должен обработать и записать его соответствующим образом.

    56. Ссылки на литературу и сервера

    [CSS1]

    "Cascading Style Sheets, level 1", H. W. Lie and B. Bos, 17 December 1996. Доступно по адресу: http://www.w3.org/TR/REC-CSS1-961217

    [DATETIME]

    "Date and Time Formats", W3C Note, M. Wolf and C. Wicksteed, 15 September 1997. Доступно по адресу: http://www.w3.org/TR/NOTE-datetime

    [IANA]

    "Assigned Numbers", STD 2, RFC 1700, USC/ISI, J. Reynolds and J. Postel, October 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1700.txt

    [ISO639]

    "Codes for the representation of names of languages", ISO 639:1988. Дополнительная информация может быть получена по адресу: http://www.iso.ch/cate/d4766.html. См. также http://www.sil.org/sgml/iso639a.html

    [ISO3166]

    "Codes for the representation of names of countries", ISO 3166:1993.

    [ISO8601]

    "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988

    [ISO8879]

    "Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", ISO 8879:1986. Информация о стандарте может быть получена по адресу http://www.iso.ch/cate/d16387.html .

    [ISO10646]

    "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-1:1993. Данная спецификация учитывает также первые пять поправок к документу ISO/IEC 10646-1:1993

    [ISO88591]

    "Information Processing -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO 8859-1:1987

    [MIMETYPES]

    Список зарегистрированных типов содержимого (типы MIME). Список зарегистрированных типов можно найти по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/media-types /.

    [RFC1555]

    "Hebrew Character Encoding for Internet Messages", H. Nussbacher and Y. Bourvine, December 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1555.txt .

    [RFC1556]

    "Handling of Bi-directional Texts in MIME", H. Nussbacher, December 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1556.txt

    [RFC1738]

    "Uniform Resource Locators", T. Berners-Lee, L. Masinter, and M. McCahill, December 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1738.txt.

    [RFC1766]

    "Tags for the Identification of Languages", H. Alvestrand, March 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1766.txt

    [RFC1808]

    "Relative Uniform Resource Locators", R. Fielding, June 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1808.txt .

    [RFC2044]

    "UTF-8, a transformation format of Unicode and ISO 10646", F. Yergeau, October 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2044.txt

    [RFC2045]

    "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed and N. Borenstein, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2045.txt. Учтите, что это RFC замещает RFC1521, RFC1522 и RFC1590.

    [RFC2046]

    "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2046.txt. Учтите, что это RFC замещает RFC1521, RFC1522 и RFC1590.

    [RFC2068]

    "HTTP Version 1.1 ", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2068.txt

    [RFC2119]

    "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2119.txt

    [RFC2141]

    "URN Syntax", R. Moats, May 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2141.txt

    [SRGB]

    "A Standard Default color Space for the Internet", version 1.10, M. Stokes, M. Anderson, S. Chandrasekar, and R. Motta, 5 November 1996. Доступно по адресу: http://www.w3.org/Graphics/Color/sRGB

    [UNICODE]

    "The Unicode Standard: Version 2.0", The Unicode Consortium, Addison-Wesley Developers Press, 1996. Спецификация учитывает также обнаруженные ошибки http://www.unicode.org/unicode/uni2errata/bidi.htm. Для получения дополнительной информации, рекомендуется посмотреть базовую страницу Unicode Consortium's по адресу http://www.unicode.org

    [URI]

    "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", T. Berners-Lee, R. Fielding, L. Masinter, 18 November 1997. Доступно по адресу: http://www.ics.uci.edu/pub/ietf/uri/draft-fielding-uri-syntax-01.txt. Работа продолжается и ожидается, что тексты RFC-1738 и RFC-1808 будут пересмотрены.

    [WEBSGML]

    "Proposed TC for WebSGML Adaptations for SGML", C. F. Goldfarb, ed., 14 June 1997. Доступно по адресу: http://www.sgmlsource.com/8879rev/n1929.htm

    Информационные ссылки

    [BRYAN88]

    "SGML: An Author's Guide to the Standard Generalized Markup Language", M. Bryan, Addison-Wesley Publishing Co., 1988

    [CALS]

    Continuous Acquisition and Life-Cycle Support (CALS). CALS является стратегией Министерства обороны США для достижения эффективного создания, обмена и использования цифровых данных для оборудования и систем оружия. Дополнительная информация доступна на базовой странице CALS по адресу http://navysgml.dt.navy.mil/cals.html

    [CHARSETS]

    Registered charset values. Загрузка списка зарегистрированных наборов символов возможна по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets

    [CSS2]

    "Cascading Style Sheets, level 2", B. Bos, H. W. Lie, C. Lilley, and I. Jacobs, November 1997. Доступно по адресу: http://www.w3.org/TR/WD-CSS2

    [DCORE]

    The Dublin Core: дополнительная информация доступна по адресу http://purl.org/metadata/dublin_core

    [ETHNO]

    "Ethnologue, Languages of the World", 12th Edition, Barbara F. Grimes editor, Summer Institute of Linguistics, October 1992.

    [GOLD90]

    "The SGML Handbook", C. F. Goldfarb, Clarendon Press, 1991.

    [HTML30]

    "HyperText Markup Language Specification Version 3.0", Dave Raggett, September 1995. Доступно по адресу: http://www.w3.org/MarkUp/html3/CoverPage

    [HTML32]

    "HTML 3.2 Reference Specification", Dave Raggett, 14 January 1997. Доступно по адресу: http://www.w3.org/TR/REC-html32

    [HTML3STYLE]

    "HTML and Style Sheets", B. Bos, D. Raggett, and H. Lie, 24 March 1997. Доступно по адресу: http://www.w3.org/TR/WD-style

    [LEXHTML]

    "A Lexical Analyzer for HTML and Basic SGML", D. Connolly, 15 June 1996. Доступно по адресу: http://www.w3.org/TR/WD-html-lex

    [PICS]

    Platform for Internet Content (PICS). Дополнительная информация доступна по адресу http://www.w3.org/PICS

    [RDF]

    The Resource Description Language: дополнительная информация доступна по адресу http://www.w3.org/Metadata/RDF

    [RFC822]

    "Standard for the Format of ARPA Internet Text Messages", Revised by David H. Crocker, August 1982. Доступно по адресу: http://ds.internic.net/rfc/rfc822.txt .

    [RFC850]

    "Standard for Interchange of USENET Messages", M. Horton, June 1983. Доступно по адресу: http://ds.internic.net/rfc/rfc850.txt

    [RFC1468]

    "Japanese Character Encoding for Internet Messages", J. Murai, M. Crispin, and E. van der Poel, June 1993. Доступно по адресу: http://ds.internic.net/rfc/rfc1468.txt

    [RFC1630]

    "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", T. Berners-Lee, June 1994. Доступно по адресу: http://ds.internic.net/rfc/rfc1630.txt

    [RFC1866]

    "HyperText Markup Language 2.0", T. Berners-Lee and D. Connolly, November 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1866.txt

    [RFC1867]

    "Form-based File Upload in HTML", E. Nebel and L. Masinter, November 1995. Доступно по адресу: http://ds.internic.net/rfc/rfc1867.txt. Ожидается, что RFC1867 будет поправлено, см.: ftp://ftp.ietf.org/internet-drafts/draft-masinter-form-data-01.txt, в настоящее время ведутся работы

    [RFC1942]

    "HTML Tables", Dave Raggett, May 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc1942.txt

    [RFC2048]

    "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", N. Freed, J. Klensin, and J. Postel, November 1996. Доступно по адресу: http://ds.internic.net/rfc/rfc2048.txt. Учтите, что это RFC замещает RFC-1521, RFC-1522 и RFC-1590.

    [RFC2070]

    "Internationalization of the HyperText Markup Language", F. Yergeau, G. Nicol, G. Adams, and M. Dьrst, January 1997. Доступно по адресу: http://ds.internic.net/rfc/rfc2070.txt

    [SGMLOPEN]

    SGML Consortium. Базовая страница консорциума находится по адресу http://www.sgmlopen.org

    [SP]

    SP представляет собой общедоступный интерпретатор SGML. Доступно по адресу: ftp://ftp.jclark.com/pub/sp /. Дополнительная информация доступна по адресу: http://www.jclark.com

    [SQ91]

    "The SGML Primer", 3rd Edition, SoftQuad Inc., 1991

    [TAKADA]

    "Multilingual Information Exchange through the World-Wide Web", Toshihiro Takada, Computer Networks and ISDN Systems, Vol. 27, No. 2, pp. 235-241, November 1994.

    [WAIGUIDE]

    Базовая информация по формированию HTML документов доступна на сайте Web Accessibility Initiative (WAI): http://www.w3.org/WAI/.

    [VANH90]

    "Practical SGML", E. van Herwijnen, Kluwer Academic Publishers Group, Norwell and Dordrecht, 1990

    Previous: 4.5.6.1 Гипертекстный протокол HTTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.7 Протокол новостей NNTP


    previous up down next index index
    Previous: 4.5.6.2 Язык HTML    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.7.1 Работа с сервером новостей

    4.5.7 Протокол новостей NNTP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Современное общество предъявляет весьма жесткие требования ко времени получения событийной информации. Это могут быть технические новинки, политические новости, уведомления о событиях (произошедших или грядущих) и т.д. Одной из форм оперативной рассылки и получения информации является электронная почта (в частности система LISTSERV). В таких системах помимо воли клиента в его почтовом ящике, как правило, скапливается огромное количество сообщений. Причем в настоящее время здесь нет пока каких-либо механизмов фильтрации. Несколько иное решение предлагает протокол NNTP и сеть рассылки новостей USENET (cм. RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. and RFC-1036, Standard for interchange of USENET messages, M.R. Horton, R. Adams). В USENET системе сообщение запоминается в базе данных сервера, а не в почтовых ящиках подписчиков. Региональный депозитарий снабжается специальным программным обеспечением, которое позволяет подписчику отбирать статьи, представляющие для него интерес. Система имеет индексацию, облегчающую поиск, и удаление устаревших статей.

    Для кластеров ЭВМ, объединенных ETHERNET (или другой быстродействующей локальной сетью) представляется целесообразным сконцентрировать функции хранения и распределения новостей в одном узле. При этом клиент может запросить любую статью тогда, когда это ему нужно, и он не обязан предоставлять ресурсы для хранения копий статей. Учитывая то, что даже в небольшой локальной сети обычно достаточно много клиентов-подписчиков такая схема позволяет сэкономить достаточно большой объем дискового пространства. Следует учитывать, что интегральный поток новостей сегодня превышает 300 Мбайт в сутки.

    Сервер новостей должен размещаться в локальной сети, так как именно в этом случае время доступа минимально. Этот сервер должен заниматься сбором новостей и созданием необходимых индексных файлов. При большом числе ЭВМ такая схема дает значительную экономию дискового пространства.

    NNTP представляет собой протокол для рассылки, подписки, поиска и доставки новостей на основе надежного протокола поточного типа (например, TCP) с использованием схемы клиент-сервер. NNTP сконструирован так, что статья, записанная в одном из серверов, становится доступной для всех подписчиков-клиентов.

    Протокол NNTP предполагает применения стандартных сообщений, формат которых следует рекомендациям RFC 850. NNTP-сервер обычно работает в фоновом режиме. В больших сетях, где число клиентов велико, возможно использование нескольких серверов новостей, которые образуют иерархическую систему. При этом клиент сначала пытается подключиться к ближайшему серверу. При неуспехе соединение либо абортируется, либо переадресуется другому серверу.

    Единицей хранения на сервере является статья. Статьи составляют содержательную часть пересылаемых сообщений. В NNTP предусмотрены команды, которые обеспечивают непосредственный обмен статьями между взаимодействующими узлами (более эффективно, чем это позволяет, например, UUCP).

    Традиционный метод рассылки новостей предполагает распространение статей от узла к узлу, так что каждый сервер пересылает другому все новости, которые имеет. При этом неизбежно дублирование, связанное с этим увеличение трафика и повышенный расход ресурсов ЭВМ. Но такая схема предельно проста и вполне оправдана, когда обмен новостями происходит один раз в сутки (дубликаты статей могут быть отфильтрованы позднее).

    При использовании NNTP ЭВМ, обменивающиеся новостями, пользуются интерактивным механизмом в процессе принятия решения о том, какие статьи следует передать. При этом ЭВМ контактирует с одним или несколькими серверами новостей. Процедура начинается с запроса о формировании новых групп новостей, для чего выдается команда NEWGROUPS. Далее клиент делает запрос о наличии новых статей из групп, представляющих интерес (команда NEWNEWS). В ответ сервер высылает список статей, а клиент может запросить их присылку, если он их не имеет. В заключение клиент может сообщить серверу, какие новые статьи он получил в последнее время.

    Сервер новостей, специфицированный в NNTP, использует поточный обмен (подобный TCP), а также набор команд и откликов, схожий с SMTP. Этот сервер является единственным интерфейсом между программами и базами данных, хранящими новости. Он не выполняет взаимодействия с пользователем или каких-либо операций презентационного уровня. Эти функции передаются программам клиента, которые имеют исчерпывающую информацию о среде. При работе через Интернет в рамках протокола TCP используется порт 119. На команды, посылаемые клиентом, предусмотрены текстовые и статусные отклики. Всякая сессия начинается с процедуры установления соединения между клиентом и сервером по инициативе клиента (например, с использованием протокола TCP).

    Текст может посылаться только после цифрового статусного отклика. Текст имеет вид последовательности строк, каждая из которых завершается парой символов CR-LF. В конце текста всегда посылается строка, содержащая один символ (.), за которым следует CR-LF (как и в SMTP).

    Если исходный текст содержит точку в начале строки, то она перед посылкой должна быть задублирована. Таким образом, клиент должен просматривать первые символы каждой полученной строки и, если это одиночная точка, прерывать дальнейший прием текста. Предполагается, что текстовый отклик будет отображен на дисплее пользователя, в то время как командно-статусный отклик интерпретируется программой клиента.

    Статусный отклик представляет собой реакцию сервера на команду, полученную от клиента. Строки статусного отклика начинаются с 3-значного десятичного кода, достаточного для описания любого отклика. Некоторые коды являются предшественниками последующего текстового отклика. Первая цифра говорит об успехе, ошибке или процессе исполнения команды.

    1xx

    Информационное сообщение

    2xx

    Команда ok

    3xx

    Команда корректна, можно продолжать обмен.

    4xx

    Команда корректна, но не может быть выполнена по какой-то причине.

    5xx

    Команда неприменима, неверна или произошла серьезная ошибка в программе.

    Следующая цифра кода характеризует категорию отклика.

    x0x

    Соединение, установка режима, прочие сообщения

    x1x

    Выбор группы новостей

    x2x

    Выбор статьи

    x3x

    Функции распределения

    x4x

    Отправка адресату

    x8x

    Нестандартное (частное применение) расширение

    x9x

    Отладочный вывод

    Конкретное значение кодов отклика можно найти только в описании конкретной команды. Ниже приведен список кодов общего назначения, которые могут быть получены в любое время.

    Некоторые статусные отклики могут иметь параметры (числа или имена). Число и тип параметров фиксировано для каждого конкретного отклика. Параметры отделяются от кода отклика и друг от друга одиночным пробелом. Все цифровые параметры имеют десятичное представление и могут начинаться с нулей. Все строковые параметры начинаются после пробела и завершаются пробелом или символьной парой CR-LF, то есть не могут содержать в себе пробелов. Любой текст, который не является параметром отклика, должен отделяться от последнего параметра, если таковой имеется, пробелом и завершаться пробелом.

    Не специфицированные коды-отклики могут использоваться для специфических новых команд. Такой код должен относиться к категории x8x (см. таблицу, приведенную выше). Применение не специфицированных откликов для стандартных команд запрещено.

    Коды категории x9x зарезервированы для отладочных целей. Так как большинство отладочных откликов можно рассматривать как информационные сообщения, для отладочных выдач зарезервирован диапазон кодов 190-199.

    Ниже приведен список сообщений общего назначения, которые может послать NNTP сервер. Эти отклики не привязаны к каким-то конкретным командам и могут быть присланы в результате сбоя или каких-то других необычных обстоятельств.

    Вообще говоря, коды 1xx могут игнорироваться; коды 200 или 201 посылаются при начальном подключении к NNTP серверу в зависимости от наличия разрешения пересылки. Код 400 отправляется, когда NNTP сервер прерывает обслуживание, например по запросу оператора, а коды 5xx указывают на то, что процедура не будет выполнена, по какой-то необычной причине.

    100

    Поясняющий текст

    190 - 199

    Отладочный вывод

    200

    Сервер готов - отправка разрешена

    201

    Сервер готов - отправка запрещена

    400

    Обслуживание прерывается

    500

    Команда не распознана

    501

    Синтаксическая ошибка в команде

    502

    Доступ ограничен или нет разрешения

    503

    Ошибка в программе - команда не выполнена

    Команды записываются в этом документе прописными буквами, хотя NNTP сервер игнорирует регистр, в котором они напечатаны. Параметры команд, помещенные в квадратные скобки, являются опционными. Длина команды не должна превышать 512 байт.

    Команды ARTICLE, BODY, HEAD и STAT

    Существует две формы команды ARTICLE (и соответственно команд BODY, HEAD, и STAT), каждая из которых использует различные методы спецификации извлекаемой статьи. Когда за командой ARTICLE следует идентификатор сообщения в угольных скобках ("<" и ">"), используется первая форма команды; когда же имеется цифровой параметр или нет параметра совсем, реализуется вторая форма. Текст статьи присылается в виде текстового отклика.

    Команды HEAD и BODY идентичны команде ARTICLE за исключением того, что они возвращают соответственно только строки заголовка или основной текст статьи.

    Команда STAT похожа на команду ARTICLE за исключением того, что не присылается никакого текста. Выбирая номер сообщения в пределах группы, команда STAT служит для установки указателя статьи без пересылки какого-либо текста. Возвращаемый отклик содержит идентификатор сообщения. Использование команды STAT для выбора статей по их идентификатору вполне работоспособно, хотя и не слишком эффективно, так как такой отбор не изменяет текущий указатель статьи.

    ARTICLE <message-id>

    Команда отображает заголовок, пустую строку и текст заданной статьи. Идентификатор сообщения (message-ID) представляет собой идентификатор, представленный в заголовке статьи. Предполагается, что клиент получит идентификатор сообщения из списка, предоставляемого командой NEWNEWS. Команда не изменяет указателя текущей статьи.

    ARTICLE [nnn]

    Отображает заголовок, пустую строку и текст текущей или специфицированной статьи. Опционный параметр nnn представляет собой числовой идентификатор статьи (номер) в текущей группе новостей. Он должен быть выбран из диапазона, который был выдан при выборе группы. Если этого параметра нет, предполагается текущая статья. Эта команда устанавливает указатель текущей статьи, если номер статьи указан корректно.

    Откликом на команду будет номер текущей статьи, строка-идентификатор сообщения и собственно текст статьи. Присылаемая строка идентификатора сообщения представляет собой последовательность символов, заключенную в угловые скобки, которая извлечена из заголовка статьи (согласно RFC-850). Если идентификаторная строка заголовка в статье отсутствует, в угловых скобках будет записан нуль.

    Так как поле идентификатора сообщения для каждой статьи уникально, оно может использоваться для поиска и удаления статей-дубликатов.

    Отклики:

    220 n <a> article retrieved - далее следует заголовок и сама статья (n = номер статьи, <a> = message-id)
    221 n <a> article retrieved - далее следует заголовок
    222 n <a> article retrieved - далее следует текст статьи
    223 n <a> article retrieved - текст запрашивается отдельно
    412 no newsgroup has been selected
    420 no current article has been selected
    423 no such article number in this group
    430 no such article found

    Команда GROUP ggg

    Обязательный параметр ggg представляет собой имя группы новостей, которая должна быть выбрана. Список доступных групп новостей может быть получен с помощью команды LIST.

    Отклик на успешный выбор группы возвращает номера первой и последней статьи в группе и оценку общего числа статей в группе. Оценка может быть и не вполне корректной, она равна или превосходит реальное число статей.

    Когда с помощью данной команды группа выбрана, внутренний указатель статьи устанавливается на первую запись в группе. Если выбрана несуществующая группа, остается в силе выбор предыдущей группы. При наборе имени группы выбранный регистр (строчные или прописные буквы) не играет роли.

    Отклики:

    211 n f l s group selected
    (n = оценка числа статей в группе; f = номер первой статьи в группе,
    l = номер последней статьи в группе; s = имя группы.)
    411 no such news group

    Команда HELP

    Команда дает краткое описание команд, которые может воспринять сервер. Отклик на команду имеет текстовую форму и завершается строкой с одиночной точкой в начале.

    Отклик: 100 help далее следует текст

    Команда IHAVE <messageid>

    Команда IHAVE информирует сервер о том, что клиент владеет статьей с идентификационным кодом <messageid>. Если сервер хочет скопировать статью, он пришлет отклик, предлагающий клиенту прислать ее. Если же сервер по какой-либо причине не хочет, чтобы ему прислали копию этой статьи (например, он ее уже имеет), он оповещает клиента об этом в своем отклике.

    Если запрошена передача статьи, клиент должен выслать полный текст статьи, включая заголовок. Сервер в этом случае пришлет отклик, уведомляющий об успехе или неудаче этой операции.

    Эта процедура отличается от команды POST в том, что последняя предназначена для пересылки полученных извне статей. Сервер может и не пересылать полученную статью другим серверам, в этом случае будут переданы коды ошибок 436 или 437.

    Причиной отказа в рассылке может стать неверный код группы, ошибка в заголовке, неприемлемая длина статьи или ограничения дискового пространства. Обычно эти ограничения связаны с конфигурацией программного обеспечения на сервере.

    Отклики:

    235 article transferred ok
    335 send article to be transferred. Завершение последовательностью <CR-LF>.<CR-LF>
    435 article not wanted - статью посылать не следует
    436 transfer failed - попытайтесь еще раз позднее
    437 article rejected - и не пытайтесь

    Так как некоторые серверы новостей не могут немедленно принять решение относительно рассылки конкретной статьи, прием статьи подтверждается (код 235), а позднее она может быть молча выброшена. Такое решение не идеально, возможно оно будет пересмотрено позднее.

    Команда LAST

    Внутренний указатель на статью устанавливается на предшествующую запись в текущей группе. Если указатель уже установлен на первую статью, отправляется сообщение об ошибке, а указатель остается неизменным.

    Отклик содержит текущий номер статьи и ее идентификатор.

    Отклики:

    223 n a article retrieved - выборочно запрашивает текст
    (n = номер статьи, a = уникальный идентификатор статьи)
    412 no newsgroup selected
    420 no current article has been selected
    422 no previous article in this group

    Команда LIST

    Присылает список доступных групп новостей. Каждой группе новостей соответствует строка в следующем формате:

    group last first p

    где <group> название группы новостей, <last> номер последней известной статьи в данной группе, <first> номер первой статьи в группе, и <p> может быть либо 'y' либо 'n', указывая на наличие или отсутствие разрешения на рассылку соответственно.

    Поля <first> и <last> являются числовыми. Они могут начинаться с нулей. Если код поля <last> превосходит код поля <first>, в файле данной группы новостей нет ни одной статьи.

    Обратите внимание на то, что рассылка может быть запрещена клиенту, хотя команда LIST указывает на то, что она разрешена для данной группы новостей. Флаг рассылки существует для каждой группы новостей, так как некоторые группы подвергаются редактированию или обобщению и по этой причине не могут рассылаться. Присылаемая статья сначала по почте пересылается посреднику-редактору, который может осуществить ее рассылку. Это не зависит от права рассылки, предоставленного клиенту NNTP-сервером.

    Заметьте, что пустой список может быть вполне корректным откликом и означает, что в данный момент на сервере нет новостей.

    Отклик:

    215 далее следует список групп новостей

    Команда NEWGROUPS date time [GMT] [<distributions>]

    Список групп новостей создан с <date и time> будет представлен в том же формате, что и в случае команды LIST.

    Дата посылается в виде 6 цифр в формате ГГММДД, где ГГ последние две цифры года, MM - номер месяца (с нулем в начале, если требуется) и ДД номер дня в месяце. Дополнение для года берется из предположения о ближайшем тысячелетии, так 86 предполагает 1986, 30 - 2030, 99 - 1999, а 00 - 2000 годы.

    Время должно характеризоваться также 6 цифрами в формате ЧЧMMСС, где ЧЧ - часы с начала суток в 24-часовом исчислении, MM минуты 00-59, а СС секунды 00-59. Временная зона определяется сервером, в противном случае появляется символьная комбинация "GMT", в этом случае и время и дата привязаны к нулевому меридиану.

    Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в угловые скобки. Если параметр задан, рассылаемая часть новых групп новостей будет сравниваться с данным списком, и только при совпадении включается в список. Если необходимо использовать более одного такого фильтра, то они разделяются друг от друга запятыми в пределах угловых скобок.

    Отклик:

    231 далее следует список новых групп

    Команда NEWNEWS newsgroups date time [GMT] [<distribution>]

    Команда формирует список идентификаторов статей для заданной группы новостей, с датой после указанной. Для каждого идентификатора сообщения в списке выделяется одна строка. Список завершается строкой с одиночным символом точки, за которым следует CR-LF. Дата и время задаются в том же формате, что и для команды NEWGROUPS.

    Для расширения зоны поиска в имени группы новостей можно использовать символ "*". Программа может подставить вместо звездочки любую комбинацию символов. Если вместо имени группы подставлен символ звездочка, поиск будет проведен по всем группам новостей.

    Если звездочка в имени группы отсутствует, новые статьи будут искаться только в группе, имя которой приведено в качестве параметра запроса. Имя группы должно быть взято из списка доступных групп. Допускается спецификация нескольких групп (имена разделяются запятыми). После последнего имени группы не должно быть запятой.

    Для отрицания соответствия может использоваться восклицательный знак. Это можно использовать для селективного исключения определенных групп новостей с целью сокращения размера списка. Например, спецификация групп "net.*,mod.*,!mod.map.*" определяет, что следует просмотреть все статьи в группах net.<что-то> и mod.<что-то> за исключением mod.map.<что-то>. Восклицательный знак должен использоваться непосредственно перед первым символом выбранного имени группы новостей.

    Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в треугольные скобки. Если этот параметр задан, производится отбор статей, соответствующих категориям, приведенным в списке distribution.

    Заметьте, что пустой список является вполне допустимым откликом и означает отсутствие новых статей.

    Отклик:

    230 далее следует список идентификаторов новых статей

    Команда NEXT

    Команда перемещает указатель текущей статьи на следующую запись в текущей группе новостей. Если в группе нет больше статей, посылается сообщение об ошибке, а указатель текущей статьи остается не измененным.

    В качестве отклика на команду возвращается номер текущей статьи и идентификатор сообщения. Никаких текстовых сообщений не посылается.

    Отклики:

    223 n a article retrieved, где n = номер статьи, a = уникальный идентификатор статьи
    412 no newsgroup selected
    420 no current article has been selected
    421 no next article in this group

    Команда POST

    Если рассылка разрешена, в качестве отклика присылается код 340, который указывает, что статью, предназначенную для рассылки, можно присылать. Код отклика 440 указывает, что рассылка запрещена по причинам, зависящим от инсталляции.

    Если рассылка разрешена, статья должна быть представлена в формате, описанном в RFC-850, и должна включать в себя все необходимые строки заголовка. После передачи заголовка и текста статьи от клиента к серверу последующий отклик будет свидетельствовать об успехе или неудаче доставки.

    Сервер не осуществляет какой-либо фильтрации текста, и он в неизмененном виде будет рассылаться.

    Отклики:

    240 article posted ok
    340 send article to be posted. Конец отмечается последовательностью <CR-LF>.<CR-LF>
    440 posting not allowed
    441 posting failed

    Команда QUIT

    Сервер подтверждает получение команды QUIT и затем закрывает канал связи с клиентом. Эта команда предоставляет клиенту корректную возможность сообщить NNTP-серверу, что все операции завершены и сессия закончена.

    Если клиент просто разорвет связь, сервер должен также прекратить попытки взаимодействовать с клиентом.

    Отклик:

    205 closing connection - goodbye!

    Команда SLAVE

    Команда сообщает серверу, что он связывается не с пользователем, а с обслуживающим сервером (slave). Эта команда позволяет разделить случаи соединения сервера с отдельным пользователем и промежуточными обслуживающими серверами. Это может использоваться для предоставления приоритета запросам от таких клиентов, так как они обслуживают многих пользователей. Это может быть также использовано при возникновении проблем с внутренними ресурсами сервера, когда он может разорвать связи с некоторыми клиентами, сохраняя каналы с обслуживающими серверами. В NNTP-серверах, где приоритетное обслуживание не предусмотрено, команда должна все равно распознаваться и подтверждаться ее получение

    Отклик:

    202 slave status noted

    Ниже приведены примеры (Примеры заимствованы из RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. (Там их больше)) диалога между клиентом и сервером. Букве C: соответствует клиент, а букве S: - сервер.

    Пример 1 - относительный доступ с помощью команды NEXT

    S:

    прослушивает порт 119 TCP

    C:

    запрашивает соединения к порту 119 TCP

    S:

    200 wombatvax news server ready - posting ok

    (Клиент запрашивает список текущих новостей)

    C:

    LIST

    S:

    215 далее следует список групп новостей

    S:

    net.wombats 00543 00501 y

    S:

    net.unix-wizards 10125 10011 y

    (какая-то еще информация)

    S:

    net.idiots 00100 00001 n

    S:

    .

    (Клиент выбирает группу новостей)

    C:

    GROUP net.unix-wizards

    S:

    211 104 10011 10125 net.unix-wizards group selected

    (В файле 104 статьи с 10011 по 10125)

    (Клиент выбирает статью для чтения)

    C:

    STAT 10110

    S:

    223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics

    only (article 10110 selected, its message-id is

    <23445@sdcsvax.ARPA>)

    (Клиент просматривает заголовок)

    C:

    HEAD

    S:

    221 10110 <23445@sdcsvax.ARPA> article retrieved - далее следует заголовок

    S:

    .

    (Клиент хочет просмотреть текст статьи)

    C:

    BODY

    S:

    222 10110 <23445@sdcsvax.ARPA> article retrieved - далее следует текст статьи

    S:

    .

    (Клиент хочет просмотреть следующую статью данной группы)

    C:

    NEXT

    S:

    223 10113 <21495@nudebch.uucp> article retrieved - statistics only (статья 10113 является следующей в группе)

    (Клиент завершает сессию)

    C:

    QUIT

    S:

    205 goodbye.

    Пример 2 - абсолютный доступ к статье с помощью команды ARTICLE

    S:

    прослушивает порт 119 TCP

    C:

    запрашивает соединения к порту 119 TCP

    S:

    201 UCB-VAX netnews server ready - рассылка запрещена

    C:

    GROUP msgs

    S:

    211 103 402 504 msgs Your new group is msgs

    (Здесь 103 статьи с 402 по 504)

    C:

    ARTICLE 401

    S:

    423 No such article in this newsgroup

    C:

    ARTICLE 402

    S:

    220 402 <4105@ucbvax.ARPA> Article retrieved

    S:

    Следует заголовок текст и статьи

    S:

    .

    C:

    HEAD 403

    S:

    221 403 <3108@mcvax.UUCP> Article retrieved, header follows

    S:

    Следует заголовок статьи

    S:

    .

    C:

    QUIT

    S:

    205 UCB-VAX news server closing connection. Goodbye.

    Пример 3 - Команда NEWGROUPS

    S:

    прослушивает порт 119 TCP

    C:

    запрашивает соединения к порту 119 TCP

    S:

    200 Imaginary Institute News Server ready (posting ok)

    (Клиент запрашивает группы новостей после 3-го апреля 1985)

    C:

    NEWGROUPS 850403 020000

    S:

    231 Далее следуют группы новостей после 03/04/85 02:00:00 follow

    S:

    net.music.gdead

    S:

    net.games.sources

    S:

    .

    C:

    GROUP net.music.gdead

    S:

    211 0 1 1 net.music.gdead Newsgroup selected

    (Нет статей в этой группе новостей, номера первой и последней статей следует игнорировать)

    C:

    QUIT

    S:

    205 Imaginary Institute news server ceasing service. Bye!

    Пример 4 - рассылка новых статей

    S:

    прослушивает порт 119 TCP

    C:

    запрашивает соединения к порту 119 TCP

    S:

    200 BANZAIVAX news server ready, рассылка разрешена.

    C:

    POST

    S:

    340 Continue posting; Period on a line by itself to end

    C:

    Передает статью в формате RFC850

    C:

    .

    S:

    240 Article posted successfully.

    C:

    QUIT

    S:

    205 BANZAIVAX closing connection. Goodbye.

    Сессия завершается, канал закрывается.

    Previous: 4.5.6.2 Язык HTML    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.7.1 Работа с сервером новостей


    previous up down next index index
    Previous: 4.5.7 Протокол новостей NNTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.8 Поиск узлов и людей

    4.5.7.1 Работа с сервером новостей
    Семенов Ю.А. (ГНЦ ИТЭФ)

    NETNEWS (или Usenet, RFC-1036) - всемирная система обмена сообщениями, использующая для этого единый формат. Сообщения рассортированы по темам, которые носят названия newsgroups (группы новостей). Эти сообщения имеют огромный суммарный объем и передаются от ЭВМ к ЭВМ. Они могут содержать текстовую или кодированную двоичную информацию. Сообщение имеет несколько строк заголовка, которые определяют, откуда пришло сообщение, через какие узлы поступило и т.д.

    Основные группы новостей, рассылаемые по всему миру, это: alt, comp, misc, news, rec, sci, soc и talk. Существует много других базовых категорий новостей, например, bionet, biz, vmsnet, которые рассылаются также повсеместно или в рамках какого-то региона или организации (например, ieee), а также коммерческие (например, clari). Последние категории рассылаются только ограниченно. Сообщения многих Bitnet LISTSERV серверов также рассылаются в виде новостей и относятся к категории bit.

    Наиболее важные группы новостей:

    Имя группы новостей

    Тематика

    alt

    Много различных тем (альтернативные группы новостей)

    bionet

    Биология

    bit

    Многие темы: из подписного листа Bitnet

    biz

    Бизнес, маркетинг, реклама

    comp

    ЭВМ

    ddn

    Defense Data Network (сеть министерства обороны)

    gnu

    Фонд общедоступного программного обеспечения, проект GNU

    ieee

    Institute of Electrical and Electronics Engineers (Институт инженеров электриков и электронщиков)

    info

    Многие темы из листа рассылки Университета Иллинойса

    k12

    От детских садов до высшей школы

    misc

    Все, что не попадает в одну из категорий news о самой Usenet

    rec

    Хобби, искусство, развлечения, отдых

    sci

    Науки всех направлений

    soc

    Социальная тематика

    talk

    Обсуждение полемических тем

    u3b

    AT&T 3B ЭВМ

    vmsnet

    DEC VAX/VMS и DECNET системы

    Базовые категории разбиваются на более чем 1200 групп новостей по различным вопросам и темам (от образования для инвалидов до Star Trek и от науки об окружающей среде до политики в странах бывшего Советского Союза). Качество дискуссий в этой среде не гарантируется. Некоторые группы имеют посредников, которые просматривают сообщения перед рассылкой. Usenet была разработана в 1979 году для системы UNIX. В настоящее время в сети новостей работает несколько тысяч узлов, охватывающих практически весь земной шар.

    Новости доступны как через локальный сервер, так и через телефонные коммутируемые сети. Программы для поддержки локального сервера новостей доступны в Интернет, UUCP, EARN/Bitnet и Fidonet. Если вам доступна только электронная почта, тогда для вас Usenet не доступна. Однако, многие группы новостей подключены к спискам почтовой рассылки и вы можете подписаться на них. Для этого шлите запрос в LISTSERV@AMERICAN.EDU со строкой: GET NETGATE GATELIST. Более того, многие документы, которые появляются в новостях, доступны по электронной почте в mail-server@rtfm.mit.edu. Для получения руководства по применению в поле subject напишите HELP.

    Команды (базовые), используемые при выборе групп новостей

    Основные команды

    h

    Отобразить справочную информацию;

    q

    quit rn (чтение новостей) - прерывание чтения новостей;

    x

    quit rn, изменения, внесенные в ваш файл .newsrc, не будут сохранены;

    v

    Показать, c какой версией rn вы работаете. RN - прикладная программа, предназначенная для просмотра новостей.

    Начало чтения статей

    Space

    Выполнение команды по умолчанию;

    y

    Чтение текущей группы новостей;

    -

    Тоже самое, что и y, но отображает список тем (subjects);

    ^N

    Переход к следующей нечитанной статье по тому же вопросу;

    k

    Пометить как читанные все статьи по текущей теме (subject).

    =

    Выдать список всех нечитанных статей;

    число

    Переход к статье с данным номером;

    #

    Отобразить номер последней статьи.

    Управление группами новостей

    n

    Переход к следующей группе новостей с нечитанными статьями;

    p

    Переход к предшествующей группе с нечитанными статьями;

    P

    Назад к следующей статье читанной или не читанной;

    ^P

    Назад к предыдущей статье по той же теме;

    ^

    Переход к первой группе новостей с нечитанными статьями;

    ^R

    Заново вывести на экран текущую статью;

    $

    Переход в конец списка групп новостей;

    g группа новостей

    Переход к заданной группе новостей;

    /эталон

    Поиск в прямом направлении группы, содержащей эталон;

    ? эталон

    Поиск в обратном направлении группы, содержащей эталон;

    /

    Поиск в прямом направлении предшествующего эталона;

    G

    Повторить поиск с направлением вперед;

    ?

    Поиск в обратном направлении предшествующего эталона;

    u

    Ликвидация подписки на текущую группу новостей;

    v

    Заново вывести на экран текущую статью вместе с заголовком;

    l эталон

    Выдача списка неподписанных групп, содержащих эталон;

    L

    Выдача состояния групп новостей в файле .newsrc;

    ^L

    Заново вывести на экран текущую страницу;

    b

    Возврат назад на одну страницу;

    c

    Пометить все новости в группе как прочитанные;

    A

    Пренебречь всеми изменениями в данной группе новостей;

    j

    Пометить статью, как прочитанную и перейти в конец;

    ^X

    Декодировать текущую статью, используя ROT-13;

    X

    Декодировать текущую страницу, используя ROT-13;

    Отклик на статью

    r

    Послать отклик автору статьи по электронной почте;

    R

    То же, что и r, но в ответ включается исходный текст;

    f

    Запуск программы Pnews для написания статьи отклика;

    F

    То же, что и f, но с включением текста исходной статьи.

    Сохранение статей

    s файл

    Запись статьи в файл;

    w файл

    То же, что и s, но без записи заголовка.

    Ввод Unix-команд

    ! команда

    Выполнить данную Unix-команду;

    !

    Прервать исполнение rn и уйти в Shell.

    Если Usenet доступен с вашего терминала, используйте один из многих программных пакетов, пригодных для чтения новостей. Эти пакеты используют либо доступ к местному серверу, либо работают на основе протокола доступа к новостям (NNTP Network News Transfer Protocol), осуществляя связь с другими ЭВМ сети. Рекомендуется прочесть брошюру "How to become a USENET site", которая посылается периодически в news.answers newsgroup. Она также доступна через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/site-setup или по почте в mail-server@rtfm.mit.edu со строкой send usenet/news.answers/site-setup.

    Существует поддержка Usenet в самых разных операционных системах: Unix, VMS, MS-DOS, OS/2, Macintosh, MVS, а также в различных средах: MS-Windows, X-Windows, Windows-NT, Emacs. Имеются интерфейсы для системы USENET и для электронной почты. Многие, реально почти все, программные продукты обеспечивают следующие возможности:

    • Подписка на группы новостей. Это означает, что именно новости данной группы будут немедленно доступны и вы сможете их просмотреть, когда пожелаете.
    • Аннулирование подписки на группы новостей. Группа удаляется из вашего списка.
    • Чтение оглавления групп новостей. Ваш локальный сервер выдает вам оглавление новостей и отслеживает, какие из них вы уже читали.
    • Нить дискуссии. Вы можете отслеживать оглавления групп новостей, имеющих отношение к одной и той же теме или предмету.
    • Посылка сообщения в группу новостей. Вы можете участвовать в дискуссии, ваш сервер новостей знает, куда послать ваше сообщение.
    • Отклик на сообщение. Вы можете послать отклик на любое сообщение (это часто называется follow-up [отклик]) или обратиться к автору сообщения (это обычно называется replay [ответ]).

    Выбрав с помощью стрелки группу новостей и нажав клавишу <Enter>, вы получите оглавление статей в группе. Символ "+" указывает на то, что не все сообщения в цепочке были прочитаны. После выбора конкретной статьи вам будет предоставлено ее содержание.

    Когда вы введете TIN (программа просмотра новостей), вы получите список групп новостей, на которые вы подписались:

    tin 1.2 PL2 [UNIX] (c) Copyright 1991-93 Iain Lea.
    (загрузка просмотрщика новостей)
    Reading news active file...
    Reading attributes file...

    Reading newsgroups file... h=help

    Group

    Selection (3658)

    (выдается базовое меню групп новостей)

    1

    26

    alt.0d

    2

    72

    alt.1d ?

    3

    50426

    alt.2600

    4

    79

    alt.3d

    Dis

    5

    496

    alt.abortion.inequity

    Pat

    6

    83

    alt.abuse.recovery

    ?

    7

    41087

    alt.activism

    Act

    8

    231

    alt.activism.d

    A p

    9

    106

    alt.activism.death-penalty

    10

    208

    alt.adoption

    Ado

    11

    37

    alt.aeffle.und.pferdle

    Ger

    12

    40

    alt.agriculture.fruit

    ?

    13

    26

    alt.agriculture.misc

    Gen

    14

    8

    alt.aldus.freehand

    ?

    15

    5

    alt.aldus.misc

    ?

    16

    78

    alt.aldus.pagemaker

    ?

    Приведем краткий перечень возможных команд, для выполнения которых достаточно нажать клавишу-символ, отмеченную правой круглой скобкой.

    <n>=set current to n,

    TAB=next unread,

    /=search pattern,

    c)atchup,

    g)oto,

    j=line down,

    k=line up,

    h)elp,

    m)ove,

    q)uit,

    r=toggle all/unread,

    s)ubscribe,

    S)ub pattern,

    u)nsubscribe,

    U)nsub

    pattern,

    y)ank in/out

         

    Если выбрать команду g (goto), то предоставляется возможность ввести имя группы новостей, которая вас интересует. Например, выберем группу comp.inforsystems.gopher:

    Goto newsgroup [comp.mail.misc]> comp.inforsystems.gopher

    (получаем новое меню, выбранная тема помечена стрелкой на левом поле)

    Group Selection (3658)

     

    1825

    189 comp.graphics.animation Tec

     

    1826

    26 comp.graphics.visualization Inf

     

    1827

    19 comp.groupware Har

     

    1828

    180 comp.groupware.lotus-notes.misc

     

    1829

    151 comp.home.automation

     

    1830

    comp.home.misc

     

    1831

    53 comp.human-factors Iss

     

    1832

    27 comp.infosystems Any

     

    1833

    comp.infosystems.announce

     

    1834

    130 comp.infosystems.gis All

    -->

    1835

    8 comp.infosystems.gopher Dis

     

    1836

    1 comp.infosystems.interpedia

     

    1837

    comp.infosystems.kiosks

     

    1838

    27 comp.infosystems.wais The

    1839

    302 comp.infosystems.www.misc

     

    1840

    16 comp.internet.library Dis

    Нажимаем <Enter>> и входим в раздел comp.infosystems.gopher. Система выдает список имеющихся документов.

     

    1

    + 3 mime-type Wolfgang Zekoll

     

    2

    + Harmony Binary Release 1.1 Mansuet Gaisbauer

     

    3

    + IRD Internet Gopher sites file Fritz Bohnet

    -->

    4

    + telnet via gopher Monty FullerDC

     

    5

    + WWW shop of British fine tea from Williamson webmaster@sswi.com

     

    6

    + WWW shop of Billy Riggs' sermon tapes webmaster@sswi.com

    Выбираем сначала пункт 4. Там лежит сообщение:

    Does anyone have a list of sights through which one can access telnet by way of gopher? Thanks for any help. Sincerely, Monty Fuller

    Посмотрим следующее сообщение (пункт 5):

    Hi,

    I would like to invite everybody to visit our WWW shop of British fine tea from Williamson & Magor: Assam, Celebration Blend, Darjeeling, Earl Grey, English Breakfast, Lifeboat.

    Go to http://www.sswi.com/, and look under "Shopping Mall": Have a nice holiday. Web Master

    http://www.sswi.com/ (может быть интересно для любителей хорошего чая).

    В документе 3 найдем полезную информацию об адресе, где лежит список Gopher-серверов:

    I have found the IRD Gopher sites file to be a very useful tool for searching the Internet. For those of you who want to have a look, here is the download site:

    http://www.mbmarktcons.com/mbmarkt/irdhome.htm or via FTP from:

    ftp://ftp.mbmarktcons.com/pub/mbmarkt/ird/Fritz

    Вернувшись назад в предыдущее меню и выбрав позицию 1838 (comp.infosystems.wais), мы получим другой список документов:

    comp.infosystems.wais (19T 26A 0K 0H R)

    1

    + searching for an underscore ("_") Thomas Carter

    2

    + Multi-field search w/freeWAIS-sf Paul Bingman

    3

    + 2 Help, compiling FreeWAIS under Sun OS 4.1.4 Adrian Blakey

    4

    + Harmony Binary Release 1.1 Mansuet Gaisbauer

    5

    + 2 freewais-sf BIO patches? Tak

    6

    + Indiceing single letters with freeWAIS-sf-2.0 B. D.O.Adams

    7

    + Wais database and html page question? Hans Baartmans

    8

    + Help on Virtual Warehousing Daniel Chang

    9

    + Question on freeWAIS and SFgate Anna Lee

    10

    + 2 Combining numeric fields in boolean search Frances Blomeley

    11

    + 2 Indexing PDF files Robert M. Ioffe

    12

    + extending length of filenames in freewais-sf Brenda Levesque

    13

    + Question: Timestamp problem with wais? Hans Baartmans

    14

    + 3 sockets.c - make errors Jason Wilkes

    15

    + freewais, wais, and Solaris Philippe Cuif

    16

    + 2 freeWAIS-sf Can't compile on BSD Jack Ellis

    Процесс этот почти беспределен.....

    Серверы новостей взаимодействуют друг с другом согласно стандартным протоколам, некоторые из которых описаны в Internet RFC. В настоящее время в этом списке имеются:

    RFC-977 описывает NNTP (Network News Transfer Protocol)

    RFC-1036 определяет формат статей Usenet.

    Некоторые группы новостей содержат статьи и дискуссионные материалы по использованию Usenet. Например: news.announce.newusers, news.answers и news.newusers.questions. Многие статьи, которые появляются в этих группах новостей доступны также с помощью анонимного FTP по адресу rtfm.mit.edu или по электронной почте по адресу: mail-server@rtfm.mit.edu.

    Previous: 4.5.7 Протокол новостей NNTP    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.8 Поиск узлов и людей


    previous up down next index index
    Previous: 4.5.7.1 Работа с сервером новостей    UP: 4.5 Процедуры Интернет
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.8.1 Whois

    4.5.8 Поиск узлов и людей
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.5.8 Поиск узлов и людей

    1

    3

    4.5.8.1 Whois

    5

    31

    4.5.8.2 FRED

    4

    22

    4.5.8.3 X500

    5

    20

    4.5.8.4 Система поиска NETFIND

    5

    22

    Previous: 4.5.7.1 Работа с сервером новостей    UP: 4.5 Процедуры Интернет
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.8.1 Whois


    previous up down next index index
    Previous: 4.5.8 Поиск узлов и людей    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.8.2 FRED

    4.5.8.1 Whois
    Семенов Ю.А. (ГНЦ ИТЭФ)

    WHOIS обеспечивает каталожную службу для пользователей сети (RFC-0954). Эта служба заключается в поиске e-mail адресов, почтовых адресов и телефонных номеров. WHOIS может поставлять информацию о сетях, о структуре доменов и т.д. Главная база данных, относящихся к сетям, поддерживается Регистрационной службой Интернет (InterNic). В действительности имена при регистрации доменов и при выдаче IP-адресов автоматически вводятся в базу данных. Каждая запись в базе имеет уникальный идентификатор (handle), имя, тип записи и ряд других полей в зависимости от типа записи. База данных поддерживается в каждой сети независимо и взаимодействие между ними не всегда существует.

    В системах UNIX имеется аналог этой службы - rwho, которая предоставляет даже несколько большую информацию, сообщая дополнительно о том, кто работает в данный момент в каждой из подключенных к сети машин.

    Сейчас создан новый протокол WHOIS++, в котором учтены прежние недостатки. WHOIS доступно для пользователей Интернет с помощью команды telnet. Возможна посылка запросов и по электронной почте.

    Обращение к базе данных производится по команде WHOIS (значение параметра заключается в угловые скобки). Обращение к местному клиент-серверу производится по форме:

    WHOIS <-h имя_сети> идентификатор

    Где имя_сети - адрес домена, куда вы собираетесь послать запрос (например, whois.internic.net); идентификатор - фамилия человека, название сети или домена, IP-адрес. С идентификатором могут использоваться специальные символы, определяющие тип поиска.

    . (точка)

    перед идентификатором задает поиск по фамилии;

    !

    перед идентификатором задает поиск по handle;

    ... or

    после идентификатора определяет режим частичного поиска: все, что начинается с идентификатора подходит.

    @

    (в идентификаторе) осуществляет поиск по e-mail адресу.

    *

    перед идентификатором извлекает полный список рекордов, соответствующих идентификатору (например, сеть и все зарегистрированные пользователи).

    %

    перед идентификатором извлекает список всех зарегистрированных пользователей узла (или региона).

    ~

    перед идентификатором выдает распечатку объекта, который точно соответствует идентификатору.

    Эти символы могут использоваться и в комбинации. Результат поиска отображается либо в виде полного текста найденной записи, либо в виде списка строк, характеризующих найденные рекорды. В обоих случаях handle следует в скобках за именем.

    Для получения информации в интерактивном режиме используется telnet по адресу whois.internic.net (или whois.ripe.net). Далее прописные буквы обозначают приемлемые сокращения; опционные параметры помещаются в угловые скобки.

    WHOIS

    Вызов программы;

    ?

    Вызов справочного материала;

    HElp

    Вызов полномасштабной справочной поддержки;

    Q, QUIT, Клавиша <Enter>

    Выход из WHOIS

    <ключевое слово>идентификатор

    Поиск в базе записей, содержащих идентификатор, ключевое слово может использоваться, чтобы ограничить область поиска каким-то одним полем.

    Можно использовать следующие ключевые слова:

    PErson

    Ограничивает поиск людьми;

    DOmain

    Ограничивает поиск доменами (например, DO EARN.NET);

    HOst

    Oграничивает поиск ЭВМ (например, HO PRINCETON);

    NEtwork

    Ограничивает поиск сетями (например, NE EBONE);

    Organization

    Ограничивает поиск организациями (например, O CERN)

    NАme

    То же что и лидирующая '.' в идентификаторе;

    HАndle

    То же что и ! в идентификаторе;

    PАrtial

    То же что и завершающая '.' в идентификаторе;

    Mailbox

    То же что и @ в идентификаторе;

    EXPand

    То же что и '*' в идентификаторе;

    SUBdisplay

    То же что и '%' в идентификаторе;

    Full or '='

    Детально отображает каждый найденный объект;

    SUMmary or '$'

    Выдает лишь список найденного;

    Использование базы данных для получения списка лиц для коммерческих целей категорически запрещено (при выявлении расстрел на месте преступления :-)).

    Пример использования WHOIS.

    telnet wais.ripe.net
    Trying 39.13.5.97 ... (IP-адрес сервера)
    Connected to info.ripe.net.
    Escape character is '^]'.

    RIPE Network Coordination Centre (NCC)
    INTERACTIVE INFORMATION SERVICE
    Report bugs to <ncc@ripe.net>.
    Enter terminal type (? for help) [vt100]: ibmpc
    Number of lines your terminal can display ? [24]

    Information Services Menu

     

    1 - About RIPE and the RIPE NCC

     

    2 - Browse through the NCC Document Store (Gopher)

     

    3 - Keyword Search of the NCC Document Store (WAIS)

     

    4 - Search the RIPE Database (whois)

    (DISABLED)

    5 - Browse through the NCC Document Store (WWW)

     

    6 - HELP for mailing documents to the UK

     

    q - Quit

    Enter Selection: 4 (выбираем позицию 4 - WHOIS)

    Enter search key [q to quit]: msu.su. (Проводим поиск записей, относящихся к домену msu.su). Система выдает:

    domain: MSU.SU
    descr: Lomonosov Moscow State University
    admin-c: SB16
    admin-c: DA196
    tech-c: DA196
    tech-c: SN4-RIPE
    zone-c: DA196
    nserver: unisun.radio-msu.net sun01a.desy.de
    nserver: ns1.barrnet.net ns2.barrnet.net
    sub-dom: npi cs srcc phys chem cogsci bio bog mics math geogr med
    sub-dom: econ rector logos geol lib sai journ cshe hist genebee
    sub-dom: law soc pvt
    changed: ada@radio-msu.net 950316
    source: RIPE
    person: Sergey F. Berezhnev
    address: Nuclear Physics Institute
    address: Moscow State University
    address: 119899 Moscow
    address: Russia
    phone: +7 095 932 8974
    phone: +7 095 939 5877
    fax-no: +7 095 932 8974
    e-mail: sfb@radio-msu.net
    nic-hdl: SB16
    notify: noc@radio-msu.net
    changed: ada@radio-msu.net 950303
    source: RIPE
    person: Dmitry A. Avdeyev
    address: Nuclear Physics Institute
    address: Moscow State University
    address: 119899 Moscow
    address: Russia
    phone: +7 095 932 8880
    phone: +7 095 939 5877
    fax-no: +7 095 932 8974
    e-mail: ada@radio-msu.net
    nic-hdl: DA196
    notify: ada@radio-msu.net
    mnt-by: RADIO-MSU-MNT
    changed: ada@radio-msu.net 950302
    source: RIPE
    person: Serge Yu. Nikiphorov
    address: Nuclear Physics Institute
    address: Moscow State University
    address: 119899 Moscow
    address: Russia
    phone: +7 095 932 8880
    phone: +7 095 939 5877
    e-mail: serg@radio-msu.net
    nic-hdl: SN4-RIPE
    changed: ada@radio-msu.net 950130
    source: RIPE
    Enter search key [q to quit]: q

    Еще один пример поиска в базе данных WHOIS, здесь задача решается с помощью команды, обращенной к серверу RIPE. Ищется информация об узле itep.ru: whois -h whois.ripe.net itep.ru (ЭВМ SUN):

    domain: ITEP.RU
    descr: Institute for Theoretical and Experimental Physics
    descr: ITEP, B.Cheremushkinskaja 25,
    descr: Moscow 117259, Russia.
    admin-c: Yuri Al. Semenov
    tech-c: Andrey N. Bobyshev
    zone-c: Andrey N. Bobyshev
    nserver: ns.itep.ru suncom.itep.ru sun01a.desy.de
    dom-net: 192.148.166.0 193.124.224.0 193.124.225.0 193.124.226.0
    remarks: fully-managed
    changed: bobyshev@cl.itep.ru 950218
    source: RIPE
    person: Yuri Al. Semenov
    address: Institute for Theoretical
    address: and Experimental Physics
    address: B.Cheremushkinskaja 25,
    address: Moscow 117259, Russia.
    phone: +7 095 1230292
    fax-no: +7 095 1236584
    e-mail: semenov@cl.itep.ru
    changed: bobyshev@cl.itep.ru 941005
    source: RIPE
    person: Andrey N. Bobyshev
    address: ITEP
    address: B.Cheremushkinskaja 25,
    address: Moscow 117259, Russia.
    phone: +7 095 1230292
    fax-no: +7 095 1236584
    e-mail: bobyshev@cl.itep.ru
    nic-hdl: AB293
    changed: bobyshev@cl.itep.ru 941005
    source: RIPE

    Существуют и другие программы для поиска информации о клиентах сети Internet (например, knowbot). Обращение к такой программе может быть выполнено, в частности, командой telnet nri.reston.va.us 185 (185 - номер порта). После входа в систему вы можете выдать запрос информации о возможностях системы поиска, напечатав ?, или просто выдав команду query vanja ivanov. Пользователи могут послать запрос через e-mail по адресу mailserv@internic.net. Команды записываются в поле subject. Текст сообщения обычно пуст, если subject не содержит команд, то интерпретируется первая строка текста сообщения. Запросы должны начинаться со слова WHOIS. Например: WHOIS \!EARN (\ представляет собой символ esc). Служба WHOIS документирована в RFC-1400. С любыми вопросами следует обращаться по адресу action@internic.net. Исчерпывающую информацию о WHOIS можно получить через анонимное FTP по адресам: nic.merit.edu /documents или sipb.mit.edu /pub/whois/whois-servers.list. Для этих же целей можно воспользоваться WWW: www.earn.net gnrt/whois.html или gopher: phantom.bsu.edu :4320/7whois%20rs.internic.net (число после двоеточия - номер порта). К материалам о WHOIS имеется доступ и с помощью telnet: rs.internic.net.

    Previous: 4.5.8 Поиск узлов и людей    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.8.2 FRED


    previous up down next index index
    Previous: 4.5.8.1 Whois    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.8.3 X500

    4.5.8.2 FRED
    Семенов Ю.А. (ГНЦ ИТЭФ)

    FRED - система поиска информации о пользователях ЭВМ, сходная с WHOIS. Пользователи в архивах Интернет ("белые страницы", OSI X.500) идентифицируются уникальным образом, например:

    "@c=RU@o=Institute for Theoretical and Experimental Physics@cn=Director"

    Так как в системе WHOIS пользователи идентифицируются короткими ключами, содержащими, например, три символа, система FRED использует в процессе своей работы список цифровых псевдонимов.

    Доступ к системе осуществляется, напимер, командой: telnet wp.psi.net. В качестве имени-идентификатора нужно ввести слово FRED. После этого появляется приглашение FRED> и вы можете приступать к работе. Система имеет удобную систему команд, основная из которых whois имеет несколько модификаций:

    whois "semenov"

    Поиск записей с таким именем в области по умолчанию.

    whois surname "semenov"

    Поиск записей с данной фамилией.

    whois fullname "yuri semenov"

    Поиск записей с указанным полным именем.

    whois "semenov" -org itep

    Поиск записей с указанным именем во всех организациях, в названии которых присутствует "itep".

    whois "semenov" -area "@c=RU@o=Institute for Theoretical and Experimental Physics команда используется, когда название "area" (место) известно.

    whois semenov@itep

    Идентична предшествующей команде;

    whois semenov@cl.itep.ru

    Поиск записей с указанным почтовым адресом.

    whois -title operator

    Поиск записей, относящихся к операторам.

    whois -org *

    Выдача списка всех зарегистрированных организаций (для данной области поиска).

    whois -org * -geo @c=US

    Выдача списка зарегистрированных организаций для домена US.

    Сначала FRED считывает файл fredrc в системном каталоге ISODE (обычно /usr/etc/). Затем FRED читает файл .fredrc в каталоге пользователя. В этих файлах, если они присутствуют, содержатся описания предпочтений пользователя. После этого система выдает приглашение для ввода команд поиска. Команда INTR, выданная на базовом уровне, не вызывает никаких последствий, выдача ее дважды подряд вызовет завершение работы FRED (аналог QUIT). На других уровнях работы FRED команда INTR прерывает выполнение процедуры. Приведем перечень служебных команд.

    alias имя

    При отсутствии аргументов печатает все псевдонимы, описанные в ходе данной сессии, если же аргумент имеется, определяет числовой псевдоним для данного имени.

    Help команда ...

    Выдает справочную информацию о командах.

    Manual

    Распечатывает подробное руководство по применению FRED.

    Quit

    Уход из системы FRED.

    report subject

    Позволяет вам ввести текст сообщения, которое по почте будет передано вашему местному менеджеру справочной системы "белые страницы".

    set переменная значение

    Производит присвоение нужных значений системным переменным FRED.

    version -fred

    Сообщает версию программного обеспечения.

    Список системных переменных FRED представлен в таблице:

    Переменная FRED

    Описание

    debug

    Отладка FRED

    manager

    Почтовый адрес местного менеджера "белых страниц".

    namesearch

    Тип имени, используемый при поиске, "fullname", "surname" или "frandly".

    pager

    Программа, используемая для разбивки текста на терминале на страницы

    query

    Подтверждение двух-шаговых операций

    server

    IP-адрес вспомогательного сервера

    timelimit

    Максимальное число секунд, которое может быть потрачено на поиск

    verbose

    Интерактивный режим с полной выдачей диагностической информации

    ufn

    Тип фильтрации при поиске: "none", "approx" или "wild".

    Вообще говоря синтаксис команды whois (FRED) аналогичен тому, что используется в системе WHOIS:

    входное_поле тип_записи признак_области_поиска управление_выводом

    Эти четыре компоненты могут встречаться в любом порядке и только входное_поле должно присутствовать обязательно. Это поле характеризует то, что вы желаете найти. Поле тип_записи говорит о том, какой вид записи в банке данных вас интересует. Поле признак_области_поиска может содержать ключи: -org (сокращение от "организация"); -unit или -locality, за которыми следует имя. Поле управление_выводом может содержать следующие ключи:

    *

    выдача детальной информации со ссылками;

    ~

    выдача минимальной информации;

    %

    выдача результатов поиска в одну строку и ссылок;

    |

    выдача полной информации.

    FRED имеет некоторые преимущества перед WHOIS и, возможно, вы предпочтете именно эту систему. Введем команду вызова сервера:

    telnet nic.switch.ch
    Trying 130.59.1.40 ...
    Connected to nic.switch.ch.
    Escape character is '^]'.

    После установления связи сервер выдаст на экран:

    SWITCH (Swiss Academic and Research Network)

    SunOS UNIX (nic) (ttyp9)

    login: dua

    SWITCHdirectory main menu (choose desired service)

    [ 1 ]

    Query the Directory, select a User Interface

    [ 2 ]

    Information about the User Interfaces

    [ 3 ]

    Terminal/X Window Configuration

    [ 4 ]

    Send Message to Administrator

    [ 5 ]

    Information about the Directory Project

    [ 6 ]

    Acknowledgement

    [ 0 ]

    Leave this Menu (back to previous Menu)

    Выберем пункт 1 (с другими видами сервиса читателям предлагается познакомиться самостоятельно):

    SWITCHdirectory User Interfaces

    [ 1 ]

    de (simple interface to find persons)

    [ 2 ]

    fred (simple white pages interface ('whois')

    [ 3 ]

    sd (menu oriented, only read functionality)

    [ 4 ]

    Dish (command line, full X.500 functionality)

    [ 5 ]

    Xdi (X window interface)

    [ 6 ]

    Xlu (X window interface)

    [ 7 ]

    XT-DUA (Commercial X window interface)


    [ 0 ]


    Leave this Menu (back to previous Menu)

    Выбираем пункт 2 и получаем:

    invoking interface "fred", please wait....
    fred> whois -org cern
    CERN (1) +41 22
    767 6111
    aka: European Laboratory for Particle Physics

     

    CERN CH-1211 Geneve 23

    FAX: +41 22 767 6555

    Mailbox information:

    X.400: /S=postmaster/O=CERN/PRMD=CERN/ADMD=ARCOM/C=CH/

    High Energy Physics research
    Business: Research Laboratory Research Lab
    Locality: Geneve
    Name: CERN, CH (1)
    Modified: Wed Aug 31 09:03:59 1994
    by: DSAmanager, SWITCHdirectory, SWITCH, CH (2)

    20 imprecise matches for '*', select from them [y/n] ? y

    После ряда ответов на вопросы (Y/N) получаем:

    7 matches found.

    1.

    CERN +41 22 767 6111

    4.

    Hochschule St. Gallen +41 71 30 2111

    5.

    IDIAP +41 26 22 7664

    6.

    Ingenieurschule HTL Biel +41 32 273 111

    7.

    Paul Scherrer Institute +41 56 992111

    8.

    Schweizerische Hochschulkonferenz +41 31 302 55 33

    10.

    SWITCH +41 1 268 1515

    Теперь посмотрим, что имеется в Германии (код=DE), для этого введем команду: whois -org * -geo @c=DE.

    100 matches found. (найдено 100 записей)

    16. BASF-AG

    +49 621-600

    21. Berufsakademie Stuttgart

    +49 711 6673-6965

    29. Competence Center Informatik

    +49-5931-805-0

    30. Computer-Communication Networks

    +49 211 905828

    40. Deutsche Fernkabel Gesellschaft mbH

    +49 30 54686-256

    41. Deutsche Forschungsgemeinschaft

    +49 228/885-2485

    44. Deutsches Forschungsnetz

    +49 30 884299-20

    51. DKRZ Hamburg

    +49 40-41173-0

    53. ECRC

    +49 89 92 69 90

    54. ERNO Raumfahrttechnik GmbH

    +49 421 539 - 0

    55. EUnet Deutschland GmbH

    +49 231 972-00

    58. European Space Agency

    +49 6151-90-0

    63. Fachhochschule Darmstadt

    +49 6151-168876

    64. Fachhochschule Dortmund

    +49 231 9112-0

    71. Fachhochschule Fulda

    +49 661 9640-0

    83. Fachhochschule Nuernberg

    +49/911/58800

    85. Fachhochschule Rheinland-Pfalz

    +41 6131 23920

    87. Fachhochschule Schweinfurt

    (049) 9721 940 5

    96. Fraunhofer-Gesellschaft

    +49 89 1205 x01

    97. Freie Universitaet Berlin

    +49 30 838-1

    105. GMD

    +49 2241 14-0

    Список, разумеется, напечатан в сокращенном виде.

    fred> q (до свидания FRED!).

    Previous: 4.5.8.1 Whois    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.8.3 X500


    previous up down next index index
    Previous: 4.5.8.2 FRED    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.8.4 Система поиска NETFIND

    4.5.8.3 X500
    Семенов Ю.А. (ГНЦ ИТЭФ)

    X.500 представляет собой протокол OSI для распределенных каталогов (индексов-оглавлений), разработанный CCITT. X.500 - протокол для работы с каталогами. X.500 предлагает распределенный каталог пользователей сети Интернет. X.500 поддерживает систему просмотра, а также добавления, модификации и удаления объектов в базе данных о людях (почтовый адрес, номер телефона, электронный адрес и пр.). Основным полем при поиске является фамилия, название организации, отдела, страны. Треугольные скобки служат для выделения имени параметра, а вертикальная черта - для указания значения параметра.

    Каждая секция каталога содержит часть глобальной базы данных и является доступной через сервер (именуемый Directory System Agent - DSA). Каждая база данных поддерживается локально. Для пользователя же доступна вся база данных. Хотя информация, доступная через X.500, относится к людям и организациям, данная база пригодна для хранения и другой информации, например, о ресурсах сети, приложениях или оборудовании. Каждый вход в базу (объект хранения, запись) в X.500 описывает один объект (человека, конкретный ресурс сети, или организацию) и носит название Distinguished Name (неповторимый идентификатор). Это имя включает в себя следующие поля: фамилия, имя, организация, e-mail для людей. Информация в каталоге X.500 (Directory Information Base - DIB) организована иерархически и носит название информационное дерево каталога (Directory Information Tree - DIT). На верхнем уровне - корневая запись (the World), затем следует уровень страны, уровень организации и, наконец, человека (ресурса и т.д.).

    X.500 доступна через локальный сервер, интерактивно через telnet или через электронную почту (или X.25). Возможен доступ и с помощью WWW или GOPHER.

    Таблица 4.5.8.3.1

    Адрес сервера при доступе через Telnet (login)

    Адрес X.25 (login)

    Страна

    jethro.ucc.su.oz.au (fred)

     

    Австралия

    elem4.vub.ac.be (dua)

    222100611

    Бельгия

    x500.denet.dk (de)

     

    Дания

    login.dkuug.dk (ds)

     

    Дания

    nic.funet.fi (dua)

     

    Финляндия

     

    20800603053201
    (login: dua, password: ucom.x)
    26245050230303

    Франция
    Франция
    Германия

    x500.ieunet.ie (de)

    272432590024

    Ирландия

    dir.ulcc.ac.uk (dua)

     

    UK

    ashe.cs.tcd.ie (de)

     

    Ирландия

    jolly.nis.garr.it (de or fred)

    22225010083212

    Италия

    zoek.nic.surfnet.nl (zoek)

     

    Нидерланды

    elc1.mat.torun.edu.pl (de или dish)

     

    Польша

    chico.rediris.es (directorio)

    2142160234013

    Испания

    hypatia.umdc.umu.se (de)

    240374810306

    Швеция

    nic.switch.ch (dua)

    22847971014540

    Швейцария

    paradise.ulcc.ac.uk (dua)

    23421920014853

    Англия

    Локальный клиент-серверы (Directory User Agent - DUA) имеются в общедоступном и коммерческом вариантах. Для получения более полного списка DUA, их описаний и места расположения рекомендуется обратиться к RFC 1292 / FYI 11 - "A Catalog of Available X.500 Implementations".

    Существует три варианта интерфейсов для доступа к X.500 в интерактивном режиме:

    • строчные (de, dish, fred);
    • управляемые через меню (sd, ранее известные как widget)
    • базирующиеся на X-Windows (Xdi, Xlookup (или xlu), pod)

    Сервер de (directory enquiries) рекомендуется в силу своей простоты для начинающих пользователей. Выход из de по команде q. Приведем перечень команд X.500.

    ?<тема>

    Выдает справочную информацию по данной теме (help).

    ^C

    (Ctrl-C) команда прерывания (например, поиска).

    *

    Выдает все записи для выбранного поля. Этот же символ представляет собой подстановку для строк по умолчанию. В том качестве * может появиться где угодно, например, smit* и *smit*.

    -

    Заменяет значение по умолчанию на пустую строку.

    После выдачи команды de пользователь должен заполнить четыре поля запроса (поиск не зависит от строчных или заглавных букв):

    Фамилия

    Символ * может использоваться где угодно. При пробеле в этом поле поиск будет проводиться по полям подразделение (отрасль) или организация.

    Наименование подразделения

    Название или сокращенное имя подразделения в организации, где работает искомое лицо. Напечатав *, вы выберете все подразделения. Это поле может быть опущено для мелких организаций.

    Название организации

    Название или сокращение для организации, где работает искомое лицо. Напечатав *, вы выберете все организации.

    Название страны

    Напечатав *, вы выберете все страны. В качестве названия страны можно напечатать ее код из двух букв (см. приложение).

    Чтобы осуществить поиск с использованием электронной почты, следует послать запрос по адресу directory@uninett.no со словом find в поле Subject. В тексте сообщения размещается запрос (один на один e-mail) в форме:

    find <фамилия> <:название организации <;название страны>> | <;название страны>

    Если название организации и страны опущены, то берутся значения по умолчанию, которые извлекаются из вашего электронного адреса. Результат поиска будет прислан по электронной почте. Для получения файла help напечатайте help вместо find. Хотя использование e-mail кажется архаичным, в некоторых случаях не слишком экстренных оно оправдано. Вы посылаете запрос и не ждете отклика в интерактивном режиме.

    Примеры использования X.500.

    Введем команду: telnet nic.switch.ch и система свяжется с сервером:

    Trying 130.59.1.40 ... (IP-адрес сервера)
    Connected to nic.switch.ch.
    Escape character is '^]'.
    login: dua (здесь необходим ввод пароля)
    *** Welcome to the Swiss X.500 Directory Service ***
    *** Access to this service is exclusively allowed for ***
    *** - Swiss universities, schools & organizations with a ***
    *** SWITCH service contract ***
    *** - foreign education & research organizations ***
    Я опускаю процедуру выбора вида сервиса (позиция 1, как и в случае FRED).

    SWITCHdirectory User Interfaces

    [ 1 ]

    de (simple interface to find persons)

    [ 2 ]

    fred (simple white pages interface ('whois')

    [ 3 ]

    sd (menu oriented, only read functionality)

    [ 4 ]

    Dish (command line, full X.500 functionality)

    [ 5 ]

    Xdi (X window interface)

    [ 6 ]

    Xlu (X window interface)

    [ 7 ]

    XT-DUA (Commercial X window interface)

    [ 0 ]

    Leave this Menu (back to previous Menu)

    Снова вводим 1 (WHOIS-сервер) и получаем на экране:

    invoking interface "de", please wait....
    Welcome to the SWITCHdirectory Service
    Connecting to the Directory - wait just a moment please...
    You can use this directory service to look up telephone numbers and electronic mail addresses of people and organizations participating in the Pilot Directory Service.
    The interface offers several MODES of usage. Type ?modes for an explanation about the modes. You can change the mode by typing one of the following option letters at the prompt for a PERSON's name.

    s

    Simple queries - the original style of this interface

    p

    Powerful, multiple organization searches

    y

    Yellow pages queries (uses power searching)

    u

    Input queries in user-friendly name format

    m

    Menu to select modes or access help facilities

    At any prompt:

    ?

    for HELP with the current question you are being asked

    ??

    for HELP on HELP

    q

    to quit the Directory Service

    Control-C

    to abandon current query or entry of current query

    Simple query mode selected

    Поищем "любые организации, известные в России", введя * в ответ на вопрос организации. Получаем:

    Department name, <CR> to search, * to list, ? for help
    :- *
    Organisation name, <CR> to search, * to list orgs, ? for help
    :- *
    Country name, <CR> to search, * to list countries, ? for help
    :- Russia (далее следует результат поиска по данному запросу)
    Found the following entries. Please select one from the list by typing the number corresponding to the entry you want.

    Russian Federation
    1 J.S.C. Mineralnye Udobreniya
    2 Moscow State University
    3 Radom-Vostok
    Organization name, <CR> to search, * to list orgs, ? for help

    Не много, но все же..... (пример относится к 1994 году)

    Печатаем 2 и получаем:

    Russian Federation
    Moscow State University
    In the meantime, displaying organization details.
    For information on people or departments, try again a little later.
    Russian Federation
    Moscow State University
    postal address MSU
    Moscow State University
    University Park
    Leninsky Gori
    Simple query mode selected
    Person's name, q to quit, * to list people, ? for help

    :- q

    (прерываем сессию)

    Для получения дополнительной информации рекомендуется прочесть RFC-1292 (доступные реализации X.500), RFC-1308 (Введение в службу каталогов, использующую протокол X.500) и RFC-1309 (технический обзор по протоколу X.500). Рекомендации по использованию X.500 можно получить, послав команду GET ITU-5233 по адресу itudoc@itu.ch. (объем документа весьма велик!). Их других источников можно упомянуть:

    FTP nic.merit.edu documents/fyi/fyi_13.txt (fyi_11.txt, fyi_14.txt).
    telnet rs.internic.net.
    gopher judgmentday.rs.itd.umich.edu :7777/;
    WWW www.earn.net gnrt/x500.html;
    http1.brunel.ac.uk :8080/wlu.html.

    Previous: 4.5.8.2 FRED    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.8.4 Система поиска NETFIND


    previous up down next index index
    Previous: 4.5.8.3 X500    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.9 Серверы подписки (LISTSERV)

    4.5.8.4 Система поиска NETFIND
    Семенов Ю.А. (ГНЦ ИТЭФ)

    NETFIND представляет собой прикладную программу для работы со справочниками и каталогами. Получив имя человека и некоторые данные о том, где он работает, NETFIND пытается найти его номер телефона, электронный адрес, используя базу данных доменов seed. NETFIND ищет информацию о людях с помощью Интернет-протоколов SMTP и finger. Netfind работает на ЭВМ SUN OS 4.0 или более новых. Могут быть найдены только лица, имеющие доступ к Интернет. Существует возможность работы с NETFIND через электронную почту. Доступ через telnet возможна по адресам (login: netfind):

    Адрес сервера

    Страна

    Адрес сервера

    Страна

    archie.ua

    Австралия

    bruno.cs.colorado.edu

    США

    dino.conicit.ve

    Венесуэла

    ds.internic.net

    США

    lincoln.technet.sg

    Сингапур

    macs.ee.mcgill.ca

    Канада

    malloco.ing.puc.cl

    Чили

    monolith.cc.ic.ac.uk

    Англия

    mudhoney.micro.umn.edu

    США

    netfind.oc.com

    США

    netfind.sjsu.edu

    США

    netfind.icm.edu.pl

    Польша

    netfind.vslib.cz

    Чехия

    nic.nm.kr

    Корея

    nic.uakom.sk

    Словакия

    redmont.cis.uab.edu

    США

    netfind.fnet.fr

    Франция

    eis.calstate.edu

    США

    Место работы искомого человека может быть описано ключевыми словами. NETFIND просматривает свою базу данных seed, чтобы найти домен, отвечающий критериям отбора. Список таких доменов отображается и вам предлагается выбрать из них 1-3. Если обнаружено более 100 доменов, NETFIND выдаст имена некоторых из них и предложит повторить поиск с более жесткими условиями. Можно использовать часть названия организации или домена в качестве эталона в процессе поиска. При использовании более чем одного эталона можно применить знак логической операции AND. По завершении поиска или при прерывании его с помощью ^C NETFIND выдает полученный результат. Предлагаются не только данные о домене или организации, но и даты последних входов искомого человека в систему. Обращение к NETFIND имеет формат:

    netfind <опции> фамилия (имя) место работы (ключевые слова)

    где допустимы следующие опции:

    -h

    Указывает NETFIND обойти фазу поиска домена и немедленно начать поиск индивидуальной ЭВМ в базе seed. Эта функция редко используется обычными пользователями

    -s

    Исключает применение протокола SMTP при поиске. Поиск происходит немного быстрее, но дает не полную информацию, так как не все ЭВМ пользователей поддерживают протокол finger

    -t

    Сообщает сколько случилось таймаутов. -T опция устанавливает время таймаута равным заданному числу секунд, что позволяет увеличить это время в некоторых случаях

    -D

    Устанавливает максимальное число доменов, где будет проводиться поиск. По умолчанию эта величина равна 3 (большее значение устанавливать не рекомендуется). Правильный выбор этого числа заметно ускоряет процесс поиска и снижает нагрузку на сеть.

    -H

    Устанавливает максимальное число ЭВМ, где будет проводиться поиск. По умолчанию это число равно 50. Устанавливать большую величину не рекомендуется

    -m

    Отображает измерительную информацию. Если не указано имя файла, то вывод производится в файл stderr

    -d

    Позволяет устанавливать различные классы отладочного вывода (в stderr), используя соответствующую букву для каждого из них, напр. -dsf. Могут использоваться любые комбинации этих букв

    Существуют следующие классы/буквы:

    c:

    Отображает управляющие сообщения (позволяет контролировать, какой точки достигла программа).

    f:

    Отображает сообщения, связанные с finger.

    h:

    Выдает список ЭВМ, найденных в базе данных seed.

    m:

    Отображает сообщения протокола SMTP.

    n:

    Отображает сообщения о неисправности сети.

    r:

    Отображает имена ЭВМ из базы seed, которые были отброшены из-за выбора search scope.

    s:

    Отображает системные сообщения.

    t:

    Отображает сообщения, связанные с thrread.

    Обычным пользователям наиболее интересны буквы f, m, и n. По умолчанию работают именно эти функции. -d команда инвертирует текущее значение опции, поэтому использование этих трех команд под знаком -d, заблокирует их работу. В качестве имени можно применить фамилию, имя или ID. При выдаче имени домена или ЭВМ можно выдавать эту информацию без разделительных точек, например, cs colorado edu. NETFIND для входа не требует каких-либо слов-паролей, кроме NETFIND. Воспользуемся услугами сервера nic.uakom.sk:

    tn nic.uakom.sk

    (обращение к серверу в Словакии)

    SunOS UNIX (nic)

    (произошло соединение)

    login:

    netfind

    (подключаемся к NETFIND-серверу, далее следует текст, выдаваемый сервером)

    UAKOM UMB
    Slovakia, Banska Bystrica
    Welcome to the Netfind server
    questions/problems : Lubos.Elias@uakom.sk

    Alternate Netfind servers:

    I think that your terminal can display 24 lines. If this is wrong, please enter the "Options" menu and set the correct number of lines. (Если ваш терминал не работает с 24 строками, обратитесь в раздел "Options" и установите верное значение).

    Top level choices:

    (Выдано базовое меню)

     

    1. Help (Запрос справочной информации)

     

    2. Search (Поиск)

     

    3. Seed database lookup (просмотр базы данных SEED)

     

    4. Options (Дополнительные возможности)

     

    5. Quit (exit server) (Уход из сервера)

    -->

    1 (Запрошена справочная информация)

    Help choices: (Справочное меню)

     

    1. Netfind search help (Работа с NETFIND)

     

    2. Usage restrictions (Используемые команды)

     

    3. Frequently asked questions (Часто задаваемые вопросы)

     

    4. For more information (Дополнительная информация)

     

    5. Quit menu (back to top level) (Возврат в предыдущее меню)

    -->

    1 (Запрошена информация о работе с NETFIND)

    Система выдает запрошенную справочную информацию (ниже приведен сокращенный перевод):

    По имени и приблизительному описанию места работы Netfind пытается найти информацию о данном лице. В качестве имени может быть введена фамилия или имя. Одновременно могут быть выданы ключевые слова: место работы, имя домена, город или страна. Найдя домен, Netfind отображает список доменов и просит вас выбрать от одного до трех из них, где следует провести поиск.

    Поиск проходит в два этапа. На первом - Netfind выполняет поиск в каждом из выбранных доменов. На втором этапе проводится более детальное исследование с помощью finger. Имеется возможность прервать поиск с помощью ^C.

    По завершении знакомства со справочной информации система возвращается к базовому меню. На этот раз выбираем пункт 2 (Поиск). Система выдает предупреждение:

    NOTE:

    Received no responses, and some host or network failures occurred. Maybe try this search again later. (В случае неуспеха можно позднее попытать счастья снова).

    Предлагается ввести имя и ключевые слова.

    Enter person and keys (blank to exit) --> Burov DESY Germany
    (Введено задание на поиск: фамилия, место работы, страна)
    Найдено три домена, отвечающие критериям отбора.
    Please select at most 3 of the following domains to search:
    (предлагается провести поиск по этим трем доменам)

    0.

    desy.de (desy zeus central data acquisition, germany)

    1.

    dsyibm.desy.de (desy, hamburg, germany)

    2.

    info.desy.de (desy zeus central data acquisition, germany)

    Enter selection (e.g., 2 0 1)--> 2 0 1
    (введен список доменов, где будет проведен поиск)
    ( 3) SMTP_Finger_Search: checking domain dsyibm.desy.de
    ( 3) do_connect:
    Finger service not available on host dsyibm.desy.de -> cannot do user lookup.
    (Поиск с помощью Finger не доступен на dsyibm.desy.de)
    ( 1) SMTP_Finger_Search: checking domain info.desy.de
    ( 2) got nameserver operator.desy.de
    ( 2) got nameserver sun01a.desy.de
    ( 2) SMTP_Finger_Search: checking domain desy.de

    Mail for Sergei Bourov is forwarded to burov@x4u2.desy.de

    Поиск завершился успехом - найден адрес, куда пересылается почта для Бурова, далее на экран выводится следующий текст:

    NOTE:

    this is a domain mail forwarding arrangement to an outside domain, possibly indicating that "burov" has moved to another department or institution. Hence, mail should be addressed to "burov@x4u2.desy.de" (почта должна посылаться Бурову по адресу).

    ( 1) SMTP_Finger_Search: checking host x4u2.desy.de

    SYSTEM: x4u2.desy.de

     

    Login name: burov In real life:

    Sergei Bourov

     

     

    (Полное имя: Сергей Буров)

     

    Office: 1d/39, 2081/2747

    Home phone: none

    Directory: /home/dice/burov Shell: /bin/zsh
    Last login at Tue Sep 26 09:04 from UNKNOWN@AXDSYB.desy.de
    (последний раз входил в систему во вторник 26-го сентября)
    No Plan.

    FINGER SUMMARY (результат исследования с помощью Finger):

    - Remote user queries (finger) were not supported on host(s) searched in the domain 'dsyibm.desy.de'.
    - The most promising email address for "burov" based on the above finger search is burov@x4u2.desy.de.
    Continue the search ([n]/y) ? --> n (хотим ли мы продолжить поиск?)

    При удаленном доступе к NETFIND имеется служба HELP. В секции каталога DOC обычно имеется также файл "часто задаваемые вопросы" (frequently asked questions - FAQ). Большую пользу может оказать статья "Experience with a Semantically Cognizant Internet White Pages Directory Tool", написанная M.F.Schwartz и P.G.Tsirigotis, Journal of Internetworking Research and Experience, март 1991, стр. 23-50. Существует список адресов подписчиков NETFIND. Для включения вас в этот список необходимо послать запрос по адресу netfind-users-request@cs.colorado.edu, где в тексте сообщения (не в строке subject!) написать: subscribe netfind-users. Исчерпывающую информацию о NETFIND можно найти посредством:

    FTP ftp.cs.colorado.edu /pub/cs/distribs/netfind
    WWW www.earn.net gnrt/netfind.html alpha.acast.nova.edu netfind.html
    Telnet ds.internic.net (Login: netfind).

    Previous: 4.5.8.3 X500    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.9 Серверы подписки (LISTSERV)


    previous up down next index index
    Previous: 4.5.8.4 Система поиска NETFIND    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.10 Электронная почта

    4.5.9 Серверы подписки (LISTSERV)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    LISTSERV - система обслуживания и управления списками адресов электронной почты. Она работает в рамках SUN/UNIX, LINUX и др., в интернациональной сети NJE (EARN/Bitnet) и Интернет. Она позволяет группам пользователей, объединенных общим интересом общаться между собой, обеспечивая эффективное использование ресурсов сети. Система дает возможность пользователю найти интересующую его группу, присоединиться к ней и активно участвовать в ее функционировании. LISTSERV управляет почтовым трафиком, осуществляет поиск архивов и файлов. Спектр тем ничем не ограничен, число рубрик превышает 3000.

    Доступ к LISTSERV может получить всякий пользователь, кто может посылать электронные сообщения по адресам EARN/Bitnet (в соответствии со стандартом RFC-822) и имеет пригодный к использованию адрес. Отличие от обычной электронной почты заключается в том, здесь вы можете обратиться не только к тем партнерам, адреса которых вы знаете, но и к тем о существовании которых и не подозреваете. Однажды по работе мне потребовалась информация по ультрафиолетовой дозиметрии, я послал запрос в один из серверов и в течение суток получил 6 ответов из США, Канады и Новой Зеландии (среди них Stephan Straus stephen@unicaat.yorku.ca, Martin Brown brauwnma@ucs.oust.edu). Неизвестные мне доселе люди снабдили меня необходимыми данными, указали адреса, где можно найти дополнительную информацию, прислали списки библиографии. Обратите внимание, чтобы однозначно определить, кого я имею в виду, достаточно указать электронный адрес.

    Для того, чтобы наладить контакт с LISTSERV нужно послать запрос по адресу: LISTSERV@host-id, где host-id NJE-адрес ЭВМ (например, TAUNIVM.BITNET) или имя INTERNET-домена (в этом случае, VM.TAU.AC.IL). Серверу LISTSERV можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Возможно взаимодействие с LISTSERV и в интерактивном режиме.

    Для облегчения связи с сервером необходимо определить узловую ЭВМ в сети EARN/Bitnet. Пользователи вне сети EARN/Bitnet могут посылать свои запросы по адресу LISTSERV.NET. Заметьте, что если этот узел еще не определен для вашей сети, вы можете попробовать работать на LISTSERV%LISTSERV.BITNET@CUNYVM.CUNY.EDU. Вы можете также использовать специальный LISTSERV-адрес, чтобы послать e-mail в любой LISTSERV-список. Например, если вы хотите послать электронное сообщение в список BITFTP-L для того, чтобы получить копию программы BITFTP, вы можете сделать это, послав сообщение по адресу BITFTP-L@LISTSERV.NET. Ваше сообщение будет автоматически переадресовано по реальному адресу (в данном случае BITFTP-L@EARNCC.BITNET), когда оно попадет в узел LISTSERV. Существует (на конец 1994 года) более 250 узлов в более чем 30 странах мира, где работают серверы LISTSERV. Вот некоторые из них:

    Сервер

    Место расположения

    Страна

    BITNIC

    Информационный центр сети BITNET

    США

    DEARN

    GMD, Бонн

    Германия

    EARNCC

    Офис EARN, Париж

    Франция

    HEARN

    Католический университет Nijmegen

    Нидерланды

    PUCC

    Принстонский университет, Нью-Джерси

    США

    SEARN

    Kungliga Tekniska Hoegskolan, Стокгольм

    Швеция

    Ниже описаны наиболее часто используемые команды. Для получения полного списка команд извлеките LISTSERV User Guide из списка DOC FILELIST по адресу LISTSERV@EARNCC.BITNET.

    Команды имеют следующий формат: заглавные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров. Важными ключевыми словами являются:

    PW=пароль - это ключевое слово служит для описания слова-пароля. Если вы завели слово-пароль для данного LISTSERV-сервера, вы должны в дальнейшем записывать в командном тексте строку PW=, чтобы ваши команды были выполнены. Эта функция создана, чтобы блокировать возможность исполнения команд, используя ваш электронный адрес. Если вы зарегистрировали ваш пароль в сервере LISTSERV, вы обязаны включать PW= во все команды, где это требуется по описанию.

    F=формат - это ключевое слово управляет форматом файла (или внутренней структурой файла), в котором он будет вам послан. Если вы не являетесь членом EARN/Bitnet, то LISTSERV будет всегда использовать формат MAIL. В противном случае формат файла зависит от информации, которая содержится в BITEARN NODES файле вашей ЭВМ. BITEARN NODES файл - это специальный файл описания сетей, используемый в EARN/Bitnet сетях. Любой пользователь может затребовать формат, отличный от описанного по умолчанию, посредством F=командное_ключевое_слово в командах, где это требуется опционно. Допустимы следующие форматы файлов:

    XXE UUe MIME/text MIME/Appl MAIL
    Кроме того, пользователи EARN/Bitnet могут задать:
    Netdata Card Disk Punch LPunch VMSdump

    Первичной задачей LISTSERV является обслуживание списков электронных адресов (списки для рассылки). Эти списки используются, чтобы пересылать сообщения подписчикам. Таким образом, создаются форумы для обмена идеями и информацией по темам, интересующим подписчиков. Пользователю достаточно помнить только один адрес (адрес сервера), чтобы взаимодействовать с большим числом лиц, имеющим сходные интересы. Обсуждения или дебаты при этом могут иметь всемирный характер.

    В рамках LISTSERV почтового списка могут использоваться следующие команды, которые служат для поиска нужного списка и адреса соответствующего сервера, для подписки или ее отмены и т.д.

    SUBscribe имя_списка <полное_имя>

    Эта команда служит для включения подписчика в список для рассылки. Вы можете использовать эту команду для изменения имени (но не электронного адреса), под которым вы уже известны в списке. имя_списка - это наименование списка, на который вы хотите подписаться. Например, EARN User Group список, находящийся в узле IRLEARN, имеет имя EARN-UG. Не следует путать имя списка с адресом сервера (EARN-UG@IRLEARN). Опционный параметр полное_имя позволяет вам выдать имя, под которым вы хотите фигурировать в списке (это может быть псевдоним). При посылке этой команды в LISTSERV по e-mail полное имя будет взято из поля From:. При посылке этой команды в сервер, где вы уже подписаны, это будет воспринято, как требование об изменении полного имени. Запрос о присоединении к подписному листу может быть обработан тремя путями: подписка может быть OPEN, CLOSED или BY-OWNER. Если это OPEN, вы будете автоматически добавлены в список и получите подтверждение этого. Если это CLOSED, вы будете вычеркнуты из списка рассылки. Если вас там не было, вы получите уведомление о том, что запрос не выполнен. Если же это BY-OWNER, ваш запрос будет переадресован собственнику списка, кто и решит добавлять вас к списку или нет. Адрес, куда будет переправлен ваш запрос, вам будет прислан. Для того, чтобы быть исключенным из списка посылайте команду:

    UNSubscribe имя_списка | * <(NETWIDE>

    Наличие круглой скобки только слева не является опечаткой. Для того, чтобы ликвидировать подписку по всем спискам LISTSERV, можете использовать "*" вместо имени списка. Если вы хотите, чтобы ваш запрос был передан всем серверам сети, используйте команду (NETWIDE. Эта версия команды рекомендуется при смене вашего электронного адреса или при длительном отпуске. Для получения списка имеющихся списков в сервере LISTSERV используйте команду List.

    List <option> <F=формат>

    Параметр option может принимать следующие значения:

    Short

    Отображается резюме всех списков, контролируемых LISTSERV, по одной строке на список. Эта версия реализуется по умолчанию;

    Long

    (детально) пересылает вам файл (называемый node-name LISTS), содержащий исчерпывающие описания всех списков, поддерживаемых сервером.

    Global <эталон>

    Выдается полный список всех известных почтовых списков LISTSERV на текущий момент. Этот файл имеет имя LISTSERV LISTS и содержит имена, заголовки и e-mail адреса этих списков. Это очень большой файл, поэтому следует проверить, есть ли у вас достаточно места на диске, прежде чем использовать опцию Global. Опционный параметр эталон может использоваться для того, чтобы выбрать имя списка, заголовок или список адресов.

    Для получения листинга почтовых списков используется команда REView. Формат команды:

    REView имя_списка <(> <option>

    Листинг будет вам переслан в виде файла с именем list-name LIST (или list-name node-name). Почтовый список состоит из двух частей: управляющая секция и подписная секция. Управляющая секция содержит параметры списка, которые включают в себя информацию о том, кто решает вопросы включения в список или его пересмотра, а также архивации. Подписная секция содержит e-mail адреса и имена всех членов списка. REView-команда позволяет вам получить листинг любой или обеих этих секций (по умолчанию - обеих) для любого из списков. Следует иметь в виду, что по решению владельца списка командой REView может выдаваться только список членов этого списка. В этом случае вам не будет позволено просматривать список e-mail адресов, если вы не член списка. Члены списка могут ограничить доступ к своему e-mail адресу по команде REView, если они установили опцию CANCEL. имя_списка - имя LISTSERV-списка, который вы хотите просмотреть. К важным опциям команды REView относятся:

    Short

    Получаемая информация ограничивается управляющей секцией (только параметры списка).

    Countries

    Выдается перечень членов списка упорядоченный с учетом национальной принадлежности.

    LOCal

    Если список имеет пару (соединен с другим списком того же имени, обслуживаемым другим сервером), вы получите полный листинг в отклик на команду REView.

    Опция LOCal может использоваться для подавления распространения действия команды REView на другие серверы. В этом случае вы получите листинг только от сервера, куда вы послали запрос.

    При подключении к какому-либо списку, вам будет поставлен в соответствие перечень параметров по умолчанию. Эти параметры могут быть вами изменены для любого из списков, где вы являетесь подписчиком. Команда Query позволяет просмотреть текущие значения параметров (опций) для любого списка. Формат команды:

    Query имя_списка | *

    Параметр имя_списка представляет собой наименование списка, на который вы подписались. Если вы используете символ "*" вместо имени списка, вы получите информацию о ваших личных параметрах для всех списков, на которые вы подписаны.

    Для изменения параметров вашей подписки используется команда SET. Она имеет формат:

    SET имя_списка | * options

    После выполнения команды SET сервер пришлет вам подтверждение успешного изменения параметра по электронной почте. Важными опциями команды SET являются:

    Mail | DIGests | INDex | NOMail

    Эти опции варьируют способ, которым вы получаете сообщения. Mail означает, что вы хотите получать сообщения по электронной почте (значение по умолчанию).

    DIGests и INDex доступны только в случае, если они разрешены собственником списка. DIGests сохраняет все сообщения посланные в список в течении определенного времени. Вместо того, чтобы получать сообщения одно за другим вы получите их единым кластером в определенный день недели или месяца. Обратите внимание, DIGests не редактирует почту и вы получите все сообщения. INDex передаст вам только дату, время, предмет, число строк, имя отправителя и адреса всех сообщений, посланных в список. Текст сообщений передан не будет. Вы можете выбрать и извлечь заинтересовавшие вас сообщения. NoMail означает, что вам не будут пересылаться сообщения. Это полезно при длительной командировке или отпуске. Вернувшись, вы можете послать команду SET c опцией Mail и возобновить присылку сообщений. Предусмотрена возможность изменения формата заголовков почтовых сообщений.

    SHORThdr | FULLhdr | IETFhdr | DUALhdr

    Все почтовые сообщения состоят из секции заголовка и тела сообщения. Заголовок содержит информацию об отправителе, получателе, дате и времени отправки. Перечисленные выше опции команды SET указывают на тип заголовка почтового сообщения, который вы хотите иметь. SHORThdr означает, что заголовок сообщения будет содержать только самую существенную информацию (например, Date:, To:, From:, Subject:, и Replay-to: поля). Этот вариант работает по умолчанию. Вы можете изменить это, используя опцию FULLhdr, которая означает, что все (даже не существенные) поля заголовка будут присутствовать в почтовом сообщении. Опция IETFhdr означает, что LISTSERV не изменит заголовок, за исключением того, что добавит в заголовок Received: (а также Message-id: и Sender:, если их там не было). Эта опция введена для обеспечения совместимости с SMTP. Наконец DUALhdr очень похожа на SHORThdr за исключением того, что LISTSERV введет заголовок в начало тела сообщения. Следовательно, когда сообщение получено и читается получателем с этой опцией, оно начнется с этой информации (например, первые три строки сообщения могут содержать To:. From:, и Subject). Эта опция удобна для таких почтовых пакетов на PC, где эта информация не отображается.

    CONCEAL | NOCONCEAL

    указывает на то, хотите вы или нет, чтобы ваше имя и почтовый адрес появлялся в ответ на команду REView, выданную одним из подписчиков списка. По умолчанию работает NONCONCEAL. Обратите внимание, что полный список подписчиков доступен владельцу списка и администратору LISTSERV, вне зависимости от установки этой опции.

    Для возобновления вашей подписки необходимо выдать команду COMFIRM. Формат команды:

    CONFIRM имя_списка

    Некоторые подписные листы требуют регулярного подтверждения подписки (обычно раз в год). Система автоматически напоминает пользователям, что они должны подтвердить свою подписку, т.е. они должны послать команду CONFIRM в течение заданного числа дней. В противном случае клиент будет вычеркнут из списка. Эта команда должна быть послана с того же адреса, по которому было послано напоминание. LISTSERV присылает подтверждение получения команды CONFIRM.

    LISTSERV может работать также и как файл-сервер. Поэтому сервер может запоминать файлы и обеспечивать к ним доступ по запросам. Эти файлы запоминаются в рамках иерархической системы filelists. Как и предполагает его название filelist представляет собой специальный файл, который содержит список файлов. Каждая запись в filelist описывает файл, который можно затребовать, давая информацию о его имени, размере, а также коде доступа (File Access Code), который описывает, кто имеет доступ к нему. Эти файлы сами могут быть списками файлов. Таким образом, эта файловая система имеет древовидную структуру.

    На LISTSERV существует два вида файлов-списков. Первый тип содержит файлы, которые помещены туда специально хозяином списка или его администратором. Это могут быть документы, карты, диаграммы или даже программы. Файлы-списки второго вида ассоциированы со списком адресов LISTSERV. Это списки файлов-списков, они состоят из серии файлов, каждый из которых хранит (обычно до месяца) копию сообщения, которое было ранее разослано. При желании в течение определенного времени эти файлы могут быть скопированы любым подписчиком.

    LISTSERV может компоновать один или более файлов в пакет и в таком виде рассылать подписчикам. Это могут быть, например, файлы, необходимые для генерации определенной программы. Пакет декларируется в LISTSERV-filelist через файл, который именуется packet-name $PACKEGE. В нем хранятся описания всех файлов, которые представляют собой пакеты. Любой файл, представляющий собой пакет, может быть извлечен из хранилища с помощью запроса: packet-name PACKAGE. Обратите внимание, что в этом случае символ $ в имени опущен. Таким образом, одна команда позволяет извлечь из депозитария сразу несколько файлов, входящих в пакет.

    Некоторые команды позволяют пользователю манипулировать файлами, которые хранятся в депозитарии LISTSERV. Сюда входят команды подписки и извлечения файлов. При посылке команд файл-серверу вы должны адресовать их именно серверу, а не какому-либо почтовому списку.

    Используйте команду INDex для получения списка файлов из определенного filelist. Формат команды:

    INDex <список_файлов> <F=формат>

    Параметр список_файлов определяет имя списка, который вас интересует. Если не указано ни какого имени, вам будет прислан индекс корневого списка файлов (именуемого LISTSERV FILELIST).

    Команда GET используется для извлечения какого-то определенного файла или пакета файлов из списка файлов, если вам разрешено это делать. Формат команды:

    GET имя_файла тип_файла <список_файлов> <F=формат>

    Параметры имя_файла и тип_файла описывают файл или пакет файлов, который вы хотите получить. Параметр список_файлов определяет список файлов или пакетов, где лежит искомый файл. Если этот параметр не указан, LISTSERV будет определять его путем поиска в собственном индексе, что задержит выполнение запроса.

    Для подписки на файлы или пакеты из определенного списка следует использовать команду AFD (Automatic File Distribution). Формат команды:

    AFD options

    Каждый раз, когда данный список или конкретный файл актуализуется (изменяется), вам будет выслана сервером его копия. Число файлов или пакетов, на которые вы подписаны, не лимитировано. Вы можете в любой момент просмотреть перечень подписки и ликвидировать ее частично или полностью. Параметр options команды AFD может принимать одно из следующих значений:

    ADD имя_файла тип_файла <список_файлов> <текст>

    <F=формат> <PW=password>

    Опция ADD позволяет вам подписаться на файл или пакет, имя_файла и тип_файла характеризует при этом имя и тип файла, на который вы подписались. Если вы хотите, чтобы автоматически в начало каждого присылаемого файла или пакета добавлялся некоторый текст, используйте параметр текст. Если вы пропускаете параметр список_файлов, то параметр текст должен быть помещен в кавычки.

    DELete filename filetype <filelist> <PW=password>

    Эта опция служит для аннулирования подписки, имена могут содержать символы * (wildcard). Опция List показывает файлы или пакеты, на которые вы в данный момент подписаны. Формат опции:

    List <(FORMAT>

    Если вы включите опцию (FORMAT, то будет отображен и формат, в котором вам будет присылаться файлы или пакеты. Еще одна команда, которая позволяет осуществить подписку на файлы и пакеты, носит название FUI (File Update Information). Ее формат:

    FUI options

    Эта команда аналогична AFD за исключением того, что вы в данном случае получаете сообщение об изменении файла или пакета, а не его новую копию. Эта команда допускает следующие опции:

    ADD имя_файла тип_файла <список_файлов> <PW=пароль>

    Аналог ADD для команды AFD за исключением параметров формат и текст. Опция DELete является полным аналогом одноименной опции команды AFD:

    Для получения информации об актуализации файлов или пакетов удобна команда Query File. Параметр список_файлов может быть опущен. Формат команды:

    Query File имя_файла тип_файла <список_файлов> <(FLags>

    Вы можете задать параметр (Flags, который позволит администрации LISTSERV получить дополнительную техническую информацию о файле, полезную при описании проблем, с которыми вы столкнулись.

    Команда PW позволяет вам добавить, изменить или ликвидировать ваше персональное слово-пароль. Команда имеет следующий формат:

    PW options

    Слово-пароль блокирует возможность несанкционированного использования вашего электронного адреса. Настоятельно рекомендуется воспользоваться этой возможностью. Запрос на регистрацию слова-пароля может быть воспринят в любое время, аналогично оно может быть изменено и аннулировано также, когда вы захотите. Слово-пароль может включать в себя от одного до 8 алфавитно-цифровых символов. Среди опций этой команды могут быть:

    ADD new-password

    Добавляет новое слово-пароль. Если вы зарегистрировали свое слово-пароль, вы обязаны впредь его использовать всюду (вводить командное ключевое слово PW=), где это требуется опционно.

    CHange old-password new-password

    Изменяет ваше старое слово-пароль на новое.

    DELete old-password

    Удаляет ваше слово-пароль из сервера, если вы уже имели его. После этого вы уже не обязаны вводить впредь командное ключевое слово PW=.

    Функции LISTSERV DATABASE

    LISTSERV позволяет пользователям извлекать старые почтовые сообщения, которые рассылались по списку какое-то время назад. Каждый почтовый список имеет ассоциированную базу данных (обычно называемую notebook или база данных list archive), в которую производится запись рассылаемых сообщений. Такая возможность зависит от хозяина списка и присутствует не всегда. Практически каждый сервер имеет базу данных по узловым ЭВМ сети EARN/Bitnet, которая называется BITEARN. Эта база доступна для всех пользователей. Базовые серверы имеют также базы данных по всем узловым ЭВМ LISTSERV (база имеет название PEERS). Для того, чтобы определить, какие базы данных доступны на данном сервере выдайте команду DATABASE LIST. Для выполнения поиска в базе данных вы можете послать e-mail в LISTSERV c соответствующим запросом в базу данных. Кроме того, пользователи EARN/Bitnet на VM или VMS системах имеют интерактивный доступ к базам данных через программу LDBASE. Для получения более детальной информации пошлите команду Info DATABASE на ближайший сервер.

    LISTSERV может выдать пользователю много и другой информации: статистика запросов, справочные и конфигурационные файлы и пр. При запросе этой информации следует адресоваться к серверам, а не к какому-либо списку. К числу команд, помогающих извлечь вспомогательную информацию, относится HELP. В ответ на эту команду вы получите по электронной почте описание наиболее употребимых команд LISTSERV, а также имя сервер-почтмейстера и его электронный адрес.

    Для получения help-файла из LISTSERV можно выдать команду Info, которая имеет формат:

    INFO <тема> <F=формат>

    Опция тема должна характеризовать тематику файла, который вы получите в ответ. Если вы пошлете запрос в ближайший (или любой) LISTSERV без указания темы, то получите список возможных тем запросов.

    Допустим вы хотите подписаться на список EARNEWS, который находится в узле FRMOP11. Ваше полное имя Yuri A. Semenov. Пошлите следующую команду по адресу LISTSERV@FRMOP11.BITNET:

    SUBSCRIBE EARNEWS Yuri A. Semenov

    Если вы хотите покинуть INFO-MAC список, где вы были подписчиком ранее, в узле CEARN, выдайте команду:

    UNSUBSCRIBE INFO-MAC

    которая должна быть послана серверу LISTSERV в CEARN, который управляет списком INFO_MAC. Для того чтобы покинуть все списки LISTSERV, пошлите команду в ближайший сервер LISTSERV:

    UNSUBSCRIBE * (NETWIDE

    Если вы хотите получить полный список всех списков рассылки, которые в своем названии содержат слово Europe. Пошлите следующую команду ближайшему серверу LISTSERV:

    LIST GLOBAL EUROPE

    Вы хотите прекратить получение сообщений из всех списков SEARN, где вы состоите подписчиком. Пошлите серверу LISTSERV в SEARN команду:

    SET * NOMAIL

    Предположим, что вы получили сообщение от сервера LISTSERV в IRLEARN с просьбой подтвердить вашу подписку на список EARN-UG и вы согласны это сделать. Пошлите серверу команду:

    CONFIRM EARN-UG

    Если вы хотите получить листинг файлов в DOC FILELIST, то следует послать команду INDEX DOC в LISTSERV-сервер EARNCC, где расположен этот список. Эта команда эквивалентна команде GET DOC FILELIST.

    Допустим, вы хотите получить файл PCPROG ZIP из списка файлов в формате XXE. Пошлите команду серверу, где размещен этот файл:

    GET PCPROG ZIP F=XXE

    Предположим, что вы хотите извлечь все файлы, которые образуют пакет под названием PROGRAM (как видно из файла с названием PROGRAM $PACKAGE) из списка файлов SAMPLE. Пошлите команду:

    GET PROGRAM PACKAGE SAMPLE

    Если вы хотите подписаться на файл под названием BUDGET MEMO в списке файлов EXPENSES с помощью AFD, тогда воспользуйтесь командой:

    AFD ADD BUDGET MEMO EXPENSES

    Чтобы подписаться на файл с названием VM EMAIL в DOC FILELIST с помощью FUI, вам следует послать следующую команду в LISTSERV узла EARNCC:

    FUI ADD VM EMAIL DOC

    Ниже приведен пример реализации LIST-сервера, который использован для обмена информацией о московском опорном магистрали (LIST-сервер "FBONE-OP").

    LIST-сервер "FBONE-OP" - система обслуживания и управления списком адресов электронной почты. Она позволяет группам ученых, пользующихся услугами южной части московской оптоволоконной магистрали, общаться между собой. Доступ к серверу может получить всякий пользователь, который имеет доступ к электронной почте. Система реализована на версии Majordomo. Это разработка Brent Chapman'а, версия 1.93.

    В описании, приведенном ниже параметры, которые помещены в ] являются опционными. Если вы задаете эти параметры, не помещайте их в [ ].

    Для того, чтобы наладить контакт с сервером нужно послать запрос по адресу: FBONE-OP-REQUEST@ITEP.RU. Серверу можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Ниже описаны наиболее часто используемые команды. Команды имеют следующий формат: прописные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров.

    При работе с LIST-сервером помимо уже описанных (subscribe, unsubscribe, get и index) могут использоваться следующие команды:

    which [<address>]

    Определить, на какой из списков вы подписаны (или адресат <address>).

    who [<list>]

    Определить список подписчиков <list>.

    info [<list>]

    Выдать общую вводную информацию для указанного списка <list>.

    lists

    Отображает список списков, которые обслуживаются Majordomo-сервером.

    end

    Блокирует дальнейшую обработку команд (полезно, если вы используете "подпись" в вашей почтовой программе).

    Команды должны записываться в тело почтового сообщения (а не в поле Subject) FBONE-OP@ITEP.Ru или FBONE-OP-REQUEST@ITEP.Ru.

    В ответ на запрос subscribe вы получите отклик вида:

    Received: by ns.itep.ru id AA03442 (5.67a8/IDA-1.5 for semenov); Sun, 26 Feb 1995 12:29:44 +0300
    Date: Sun, 26 Feb 1995 12:29:44 +0300
    To: semenov
    From: MailList
    Subject: ITEP MailLists Server results
    Reply-To: MailList
    >>>> subscribe
    Succeeded.

    Параметр <list> является опционным, если запрос послан по адресу "<list>-request@ITEP.Ru". В ответ на запрос who сервер выдаст:

    From maillist Sun Feb 26 15:46:16 1995

    Received: by ns.itep.ru id AA07983
    Date: Sun, 26 Feb 1995 15:46:15 +0300
    To: semenov
    From: MailList
    Subject: ITEP MailLists Server results
    Reply-To: MailList
    >>>> who
    Members of list 'fbone-op':
    bobyshev
    BOBYSHEV@vxdesy.desy.de
    bobyshev@x4u2.desy.de
    kent@top.rector.msu.su
    ks@isf.ru
    em@free.net
    gonchar@ipsun.ras.ru
    noc@radio-msu.net
    sid@free.net
    nelubov@oea.ihep.su
    sakr@itp.ac.ru
    leonid@egoshin.ihep.su
    semenov

    При работе c подписными листами следует прежде всего думать о партнерах по списку. Это занятые люди, поэтому для всеобщего внимания следует выносить лаконичные сообщения, представляющие всеобщий интерес. Частные сообщения лучше посылать только тому, или тем, адресатам, которым это важно знать.

    Детальная документация по LISTSERV и связанных с ним услуг доступна в DOC FILELIST по адресу LISTSERV@EARNCC.BITNET. Сюда входит LISTSERV User Guide, который доступен в обычном и postscript форматах. Для получения списка доступной документации используйте команду INDex. Существует несколько списков для обсуждения технических вопросов LISTSERV. Они не предназначены для обычных пользователей, но и не закрыты для них. Это:

    LSTSRV-L технический форум LISTSERV.
    LSTOWN-L форум хозяев списков LISTSERV.
    LDBASE-L форум возможностей баз данных в LISTSERV.

    Previous: 4.5.8.4 Система поиска NETFIND    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.10 Электронная почта


    previous up down next index index
    Previous: 4.5.9 Серверы подписки (LISTSERV)    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.11 Gopher

    4.5.10 Электронная почта
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Электронная почта - наиболее популярный и быстро развивающийся вид общения. Широко используются протоколы электронной почты UUCP (unix-to-unix copy protocol, RFC-976) и SMTP (simple mail transfer protocol; RFC-821, -822, -1351, -1352). Один из протоколов (RFC-822) определяет формат почтовых сообщений, второй (RFC-821) управляет их пересылкой. Имея механизмы промежуточного хранения почты (spooling) и механизмы повышения надежности доставки, протокол smtp базируется на TCP-протоколе в качестве транспортного и допускает использование различных транспортных сред. Он может доставлять сообщения даже в сети, не поддерживающие протоколы TCP/IP. Протокол SMTP обеспечивает как транспортировку сообщений одному получателю, так и размножение нескольких копий сообщения для передачи по разным адресам. Обычно в любом узле Интернет имеется почтовый сервер (MX), который принимает все сообщения и устанавливает их в очередь. Далее производится раскладка сообщений по почтовым ящикам ЭВМ пользователей. Если какая-то ЭВМ не включена, сервер попытается доставить почту позднее (например, через 30 мин). После заданного числа неудачных попыток или по истечении определенного времени (> 4-5 дней) сообщение может быть утрачено. При этом отправитель должен получить уведомление об этом. Над SMTP располагается почтовая служба конкретных вычислительных систем (например, POP3(RFC-1460), IMAP (RFC-2060), sendmail (UNIX), pine, elm (надстройка над sendmail), mush, mh и т.д.). Схема пересылки электронных почтовых сообщений (RFC-821) показана на рис. 4.5.10.1.

    Существует множество реализаций электронной почты. Имеются версии практически для всех ЭВМ, операционных систем и сред.

    Адреса электронной почты уникальны и однозначно определяют адресата, обладая иногда даже некоторой избыточностью. Символьные адреса электронной почты вполне соответствуют IP-нотации. Электронный почтовый адрес содержит две части, местную и доменную, например, vanja.ivanov@itep.ru (vanya.ivanov - местная). Доменная часть обычно совпадает с символьным IP-именем домена.

    Если между отправителем и приемником имеется непосредственная связь, адрес имеет вид имя_пользователя@имя_ЭВМ. Когда приемник находится на ЭВМ, которая не поддерживает SMTP и передача происходит через промежуточный почтовый сервер, то адрес может иметь вид, например, ivanov%имя_удаленной_ЭВМ@имя_сервера (благодаря быстрому развитию Интернет в мире и даже в России такая схема используется сейчас крайне редко). Местная часть адреса определяется пользователем и часто совпадет с его именем или фамилией. Электронный адрес несравненно компактнее традиционных почтовых адресов, которые мы пишем на конвертах. Да и сами возможности электронной почты несравненно богаче почты традиционной. По этой причине можно утверждать, что традиционная почта постепенно будет в ближайшем будущем вытеснена ее электронным аналогом. Схема взаимодействия различных объектов электронной почты показана на рис. 4.5.10.1

    Рис. 4.5.10.1. Схема пересылки электронных почтовых сообщений

    Со временем можно ожидать, что электронные адреса станут универсальными, но это произойдет не скоро. Для этого нужно чтобы транспорт и другие службы научились работать с такими адресами. Электронные (IP) адреса удобнее для ЭВМ, чем традиционные, а принимая во внимание, что применение вычислительной техники повсеместно, вывод напрашивается сам собой. То что удобно для ЭВМ, удобно в конечном итоге для всех.

    Любое почтовое сообщение можно разделить на три части: "конверт" (RFC-821), заголовки (RFC-822) и собственно текст. Конверт используется почтовым сервером и содержит две команды (тексты после двоеточия приведены в качестве примера):

    MAIL From: <semenov@cl.itep.ru>
    RCPT To: <king_penguin@antarctic.edu>

    Существует девять полей заголовка, используемые почтовой программой пользователя: Received, From, To, Date, Subject, Message-Id, X-Phone, X-Mailer, Reply-To. Каждое из этих полей содержит имя, за которым после двоеточия следует его значение. Документ RFC-822 определяет формат и интерпретацию полей заголовка. Заголовки, начинающиеся с X- являются полями, определяемые пользователем.

    При вызове почты (командой mail или mailx) на экране будет распечатан служебный текст, который зависит от конкретной реализации mail, но практически непременным атрибутом любой версии будет являться полное число полученных вами почтовых сообщений (если таковые были). Это могут быть и сообщения, оставленные вами там после предшествующего чтения почты. Непрочитанные вами сообщения так или иначе помечаются (например, символом U на левом поле строки-описания сообщения или N для новых). Далее следует аннотация сообщения, по одной строке на сообщение. Аннотация обычно содержит номер сообщения (нумерация всегда начинается с 1), имя и адрес отправителя, дата и время отправки. После этого следуют (в некоторых реализациях) два числа, разделенных косой чертой ("/"). Они характеризуют размер сообщения в строках и полное число символов. В заключение следует, если еще есть место, предмет сообщения (Subject:). Ниже приведен пример текста такого аннотационного сообщения (SUN):

    Mail version SMI 4.1-OWV3 Mon Sep 23 07:17:24 PDT 1991 Type ? for help.
    "/usr/spool/mail/semenov": 4 messages 4 new
    >N 1 mw@isds.Duke.EDU Wed Aug 23 14:15 92/4350
    N 2 hochreit@informatik.tu-muenchen.de Wed Aug 23 23:54 71/2767 TR announcement: Long Sho
    N 3 Voz@dice.ucl.ac.be Thu Aug 24 07:08 501/21416 ELENA Classification data
    N 4 S.Renals@dcs.shef.ac.uk Thu Aug 24 07:08 58/2837 AbbotDemo: Continuous Spe
    &

    Не ленитесь заполнять поле Subject, иначе при большой почте ваш адресат может пропустить ваше сообщение. Среди наиболее значимых для пользователя полей заголовка можно выделить: адрес и имя отправителя (From:), дата отправки (Date:), адрес получателя (To:), адреса и время прохождения промежуточных узлов, списки лиц (Cc:), кому кроме вас послано это сообщение, предмет сообщения (Subject:), некоторая служебная информация и т.д. Число строк заголовка зависит от программы, реализующей функцию почты и от параметров, определенных пользователем, например, путем задания значений системных переменных.

    Практически все пакеты электронной почты имеют возможность переадресовать сообщение другому адресату (Forward); отправить ответ (Replay) пославшему вам сообщение человеку (в этом случае в заголовке появится поле Replay-To); стереть сообщение не читая; в случае смены места работы или длительной командировки установить постоянную переадресацию (на ЭВМ SUN для этого нужно указать адрес нового почтового ящика в файле .forward); записать сообщение в файл (Save имя_файла) или отпечатать его на принтере.

    Команда обращение к почтовому серверу обычно имеет вид:

    mail местный_адрес@имя_домена, (все что записано после команды mail, является электронным адресом адресата). Например, если вы посылаете сообщение автору, то команда приобретает вид: mail semenov@itep.ru.

    Использование промежуточного почтового сервера (mail gateway) несколько усложнит запись электронного адреса (это бывает нужно, например, когда кто-то вне Internet хочет послать сообщение клиенту Internet):

    semenov%cl.itep.ru@имя_промежуточного_почтового_сервера

    При этом предполагается, что промежуточный почтовый сервер возьмет местную часть адреса, заменит символ "%" на традиционный "@" и перешлет полученное сообщение по данному адресу. Встречаются нотации (хотя сегодня их уже смело можно назвать устаревшими), когда адрес имеет вид:

    идентификатор_пользователя%имя_домена
    или
    идентификатор_пользователя:имя_домена.

    При возникновении проблем рекомендуется обращаться к администратору вашей локальной сети.

    Если вы любопытны и хотите посмотреть, какие служебные команды выдаются при отправке электронного сообщения, воспользуйтесь командой (в качестве адресата (xxxxxxxx) выберите своего друга, коллегу или знакомого, которому вам нужно что-то сообщить):

    mail -v xxxxxxxx@cernvm.cern.ch (обращение к почтовой программе пользователя)

    Subject: Test it.

    (пользовательская программа предлагает ввести тему почтового сообщения)

    Privet...

    (текст почтового сообщения)

    .

    (команда отправки сообщения)

    xxxxxxxx@cernvm.cern.ch... Connecting to dxmint.cern.ch (TCP)...
    220 dxmint.cern.ch Sendmail ready at Thu, 6 Jul 1995 07:43:27 +200
    >>> HELO itep.ru
    250 dxmint.cern.ch Hello itep.ru, pleased to meet you
    >>> MAIL From:<xxxxxxx@itep.ru>
    250 <xxxxxxx@itep.ru>... Sender ok
    >>> RCPT To:<xxxxxxxx@crnvma.cern.ch>
    250 <xxxxxxxx@crnvma.cern.ch>... Recipient ok
    >>> DATA
    354 Enter mail, end with "." on line by itself
    >>> . (команда завершения сообщения и его отправки адресату)
    250 Ok
    >>> QUIT
    221 dxmint.cern.ch closing connection
    xxxxxxxx@crnvma.cern.ch... Sent (сессия завершена)

    Именно модификация команды mail -v обеспечивает вывод сообщений, отпечатанных ниже строки "Privet...". Для посылки почтового сообщения используется только пять команд: HELO, MAIL, RCPT, DATA и QUIT. Строчки, начинающиеся с >>>, являются командами, которые посланы SMTP-клиентом (xxxxxxx@ns.itep.ru). Строки же, которые начинаются с трехзначной цифры, представляют собой коды-отклики SMTP-сервера (в данном случае он имеет имя dxmint.cern.ch), тексты же, следующие после кода-отклика необязательны и могут отсутствовать. Процедура отправки сообщения начинается с того, что клиент выполняет операцию active open для TCP-порта 25. Далее клиент идентифицирует себя командой HELO, выдавая в качестве параметра адрес своего домена. Команда MAIL идентифицирует отправителя, команда RCPT - получателя. Число команд RCPT всегда равно числу получателей. Команда DATA служит для передачи сообщения, а QUIT - для завершения этой процедуры и ликвидации TCP-канала. Посмотрим как выглядит посланное выше сообщение после того, как я его переадресовал себе по адресу semenov@itep.ru:

    From xxxxxxxx@crnvma.cern.ch Sat Jul 29 12:15:13 1995
    Received: from cearn.cern.ch by ns.itep.ru with SMTP id AA25862
    (5.67a8/IDA-1.5 for <SEMENOV@NS.ITEP.RU>); Sat, 29 Jul 1995 12:15:08 +0300
    Received: from CERNVM.CERN.CH by CEARN.cern.ch (IBM VM SMTP V2R2)
    with BSMTP id 3114; Sat, 29 Jul 95 10:07:15 SET
    Received: from CERNVM.cern.ch (NJE origin@CERNVM) by CERNVM.CERN.CH (LMail
    1.2a/1.8a) with BSMTP id 4132; Sat, 29 Jul 1995 10:11:12 +0200
    Resent-Date: Sat, 29 Jul 95 10:10:30 SET
    Resent-From: xxxxxxxx@crnvma.cern.ch
    Resent-To: SEMENOV@NS.ITEP.RU
    Received: from CERNVM (NJE origin SMTPIBM@CERNVM) by CERNVM.CERN.CH
    Lmail V1.2a/1.8a) with BSMTP id 4125; Sat, 29 Jul 1995 10:08:44 +0200
    Received: from dxmint.cern.ch by CERNVM.CERN.CH (IBM VM SMTP V2R2) with TCP;
    Sat, 29 Jul 95 10:08:43 SET
    Received: by ns.itep.ru id AA25665
    (5.67a8/IDA-1.5 for xxxxxxxx@cernvm.cern.ch); Sat, 29 Jul 1995 12:12:26 +0300
    Date: Sat, 29 Jul 1995 12:12:26 +0300
    From: Yuri Semenov <semenov>
    Message-Id: <199507290912.AA25665@ns.itep.ru>
    To: xxxxxxxx@crnvma.cern.ch
    Subject: Test it.
    Status: R
    --------------------------Original message---------------
    Privet...

    Текст, выделенный курсивом, представляет собой то, что пришло в CERN. "Накладные расходы" даже здесь значительны, ведь собственно текст состоит из одного слова, следующего после надписи "Original message". Переадресация же увеличивает издержки еще больше.

    При описании DNS говорилось о существовании MX-записей, которые являются одной из разновидностей ресурсных рекордов. MX-записи могут использоваться для доставки почтовых сообщений адресатам, не имеющим прямого доступа к Интернет (RFC-974). Еще одним применением MX-записей является предоставление альтернативного получателя почтовых сообщений в случае, когда ЭВМ-получатель вышла из строя. Для выяснение конкретной конфигурации почтовых серверов можно воспользоваться командой host:

    host -a -v -t mx cernvm.cern.ch (команда выданная с терминала, ниже следует отклик на эту команду)

    Trying domain "itep.ru"
    rcode = 3 (Non-existent domain), ancount=0
    Trying null domain
    rcode = 0 (Success), ancount=3
    The following answer is not authoritative:

    cernvm.cern.ch

    30450

    IN

    CNAME

    crnvma.cern.ch

    crnvma.cern.ch

    86042

    IN

    MX

    20 dxmint.cern.ch

    crnvma.cern.ch

    86042

    IN

    MX

    40 relay.EU.net

    For authoritative answers, see:

    cern.ch

    198821

    IN

    NS

    dxmon.cern.ch

    cern.ch

    198821

    IN

    NS

    ns.eu.net

    cern.ch

    198821

    IN

    NS

    sunic.sunet.se

    cern.ch

    198821

    IN

    NS

    scsnms.switch.ch

    Additional information:

    dxmint.cern.ch

    31455

    IN

    A

    128.141.1.113

    relay.EU.net

    8411

    IN

    A

    192.16.202.2

    dxmon.cern.ch

    371619

    IN

    A

    192.65.185.10

    ns.eu.net

    38326

    IN

    A

    192.16.202.11

    sunic.sunet.se

    331044

    IN

    A

    192.36.148.18

    sunic.sunet.se

    331044

    IN

    A

    192.36.125.2

    scsnms.switch.ch

    28536

    IN

    A

    130.59.10.30

    scsnms.switch.ch

    28536

    IN

    A

    130.59.1.30

    ..................................

    MX-записи с наименьшим предпочтением (код предпочтения следует сразу за MX) указывают, что сначала следует попытаться переслать сообщение ЭВМ dxmint.cern.ch.

    Следующий уровень предпочтения соответствует адресу relay.EU.net. Здесь же вы найдете CNAME-запись (канонические имена DNS). Кроме списка альтернативных почтовых серверов эта команда выдает информацию о списке серверов имен (DNS-серверов). В приведенном примере их четыре, они помечены символами NS и обслуживают домен cern.ch (см. первую колонку). В нижней части полученной таблицы вы можете найти IP-адреса приведенных MX- и NS-серверов (помечены символом A). Пояснения расшифровки содержимого других колонок можно найти выше, в описании DNS-системы (раздел 1.13 ).

    При подготовке текста сообщения вы можете сначала воспользоваться традиционным редактором. Текст будет тогда размещен в файле и при отправке вы можете использовать, например, команду send имя_файла (в системе VMS) или командой GET ввести содержимое файла в текст сообщения (с помощью команды ~r имя_файла в UNIX). Чаще текст сообщения печатается в реальном масштабе времени, непосредственно перед отправкой. В этом случае сигналом конца ввода будет Ctrl-D или символ "." (точка) в начале очередной строки (или Ctrl-Z в VAX/VMS). Если по какой-либо причине вы передумали и не хотите отправлять уже набранное сообщение, процедуру можно прервать, нажав Ctrl-C.

    При необходимости посылки одного и того же текста нескольким пользователям можно воспользоваться командой:

    mail (или mailx) адрес_1 адрес_2 и т.д.

    В этом случае сообщение будет послано по всем перечисленным адресам. Формат этой операции заметно варьируется для разных ЭВМ и программных пакетов. Вместо адресов могут использоваться псевдонимы, что несколько облегчает задачу. Для хранения псевдонимов (alias) служит специальный служебный файл. За описанием работы с псевдонимами вынужден отослать вас к описанию почтового пакета, с которым вы работаете.

    На последней строке будет напечатан символ &, который указывает, что система ждет ввода команды (просмотр почты). Уход из mail производится по команде q (quit). В ответ на & вы можете ввести следующие команды (набор команд и их синтаксис может варьироваться от ЭВМ к ЭВМ и от реализации к реализации, см. табл. 4.5.10.1).

    При работе в Unix в процессе печатания текста сообщения вы можете выдать почтовой программе определенные команды. Такие команды начинаются с символа "~" (тильда). Ниже приведен список таких команд, текст набранный курсивом, означает, что вместо него должны быть впечатаны имена, адреса и т.д. Многоточие показывает, что может быть введено более одного имени, адреса и пр.

    Таблица 4.5.10.1. Внутренние команды почтовой программы UNIX

    Субкоманда MAIL

    Описание

    ~?

    Отображает весь набор описаний ~-команд

    ~b адрес...

    Добавляет адрес в строку "Blind copy" (слепая копия "Bcc:").

    ~c адрес...

    Добавляет адрес(а) в строку "Copy" или "Cc:".

    ~d

    Читает содержимое файла dead.letter

    ~e

    Вызывает редактор текста

    ~f сообщения

    Считывает сообщения

    ~h

    Редактирует все строки заголовка.

    ~m сообщения

    Считывает сообщения, сдвигает указатель вправо на одну табуляцию

    ~p

    Отображает (печатает) текущее сообщение

    ~q

    Уход из почты (Quit), эквивалентно двойному Ctrl-C

    ~r файл

    Считывает содержимое указанного файла в текст сообщения

    ~s subject

    Изменяет содержимое строки Subject

    ~t адрес...

    Добавляет адрес в строку "To:".

    ~v

    Вызывает альтернативный редактор (то же, что и ~e).

    ~w файл

    Записывает текущее сообщение в файл

    ~! команда

    Выполняет команду Shell и возвращается к сообщению

    ~| команда

    Пропускает текущее сообщение через фильтр

    Если вы напечатаете ~f (без указания номера сообщения), в текст текущего сообщения будет внесено содержимое сообщения, которое вы читали последним. Стандартной формой использования ~f является, например, ~f 5, где 5 - номер сообщения. ~m делает тоже самое, но каждая строка сдвигается на один tab вправо.

    В UNIX многие команды имеют разные функции, если они напечатаны строчными или прописными буквами, смотри, например, команды r и R в таблице 4.5.10.2. Не безразлично в UNIX и применение строчных и прописных символов в именах файлов, что бывает существенно, в частности, при работе с FTP-сервером.

    Важной командой является SET, которая позволяет изменять системные переменные. Формат использования:

    SET переменная=значение (Например, SET EDITOR=/bin/edMe=/bin/eda).

    Уже сегодня можно переслать поздравительную цветную открытку вашим знакомым. Возможна по такой схеме пересылка и звуковых писем, лишь бы у вашего адресата была звуковая карта в ЭВМ. Ведутся работы и над протоколами видео-писем (NETBLT).

    Тот факт, что электронная почта является наиболее популярным видом сервиса, делает ее объектом непрерывных доработок и усовершенствований. Так в документах RFC-1425, -1426, -1427 предлагается вариант расширения возможностей SMTP (ESMTP). Эта модификация сохраняет совместимость со старыми версиями. Клиент, желающий воспользоваться расширенными возможностями, посылает команду EHLO вместо HELO. Если сервер поддерживает ESMTP, он выдаст код-отклик 250. Этот вид отклика является многострочным, что позволяет серверу сообщить о видах сервиса, которые он поддерживает. Например:

    250-8BITMIME (RFC-1426)
    250-EXPN (RFC-821)
    250-SIZE (RFC-1427)
    250-HELP (RFC-821)
    250-XADR

    Таблица 4.5.10.2. Команды, выполняемые почтовой программой

    Команда

    Описание

    Сокращение

    Полное имя

    ?

    -

    Отображение списка исполняемых команд

    !

    -

    Выполнение одной команды Shell

    +

    -

    Отобразить следующее сообщение

    RETURN

    -

    Отобразить следующее сообщение

    -

    -

    Отобразить предшествующее сообщение

    число

    -

    Отобразить сообщение с номером "число".

    d

    delete

    Стереть текущее сообщение

    dp

    -

    Стереть текущее сообщение и отобразить следующее

    e

    edit

    Вызвать редактор для работы с сообщениями

    h

    headers

    Отобразить список заголовков сообщений

    l

    list

    Выдать список имен всех доступных команд

    m

    mail

    Послать сообщение по указанному адресу или адресам

    n

    -

    Отобразить следующее сообщение и распечатать его

    p

    print

    Отобразить (отпечатать) сообщения

    pre

    preserve

    Сохранить сообщения в системном почтовом ящике

    q

    quit

    Завершить работу с почтой

    r

    replay

    Ответить отправителю и всем прочим получателям

    R

    Replay

    Ответить только отправителю

    s

    save

    Сохранить сообщения в указанном файле или в mbox, если имя файла не указано

    sh

    shell

    Временно уйти из почты и вернуться в shell

    t

    type

    Тоже что и print

    to

    top

    Отобразить несколько верхних строчек сообщения

    u

    undelete

    Восстановить ранее стертые сообщения

    v

    -

    Редактирование сообщения с помощью экранного редактора

    w

    write

    Тоже что и s, но без записи заголовка

    x

    exit

    Выйти из почты без спасения внесенных изменений

    z

    -

    Отобразить следующий набор заголовков

    z-

    -

    Отобразить предшествовавший набор заголовков сообщений

    Ключевое слово 8BITMIME говорит о том, что клиент может добавить ключевое слово BODY к команде MAIL FROM и определить тип символов, используемых в сообщении (ASCII или 8-битные). Ключевое слово XADR указывает на то, что любые ключевые слова, начинающиеся с X, относятся к местным модификациям SMTP. Документ RFC-1522 определяет способ, как можно включить не ASCII-символы в заголовок почтового сообщения. Например:

    =?набор_символов ?кодировка ?закодированный_текст ?=

    набор_символов - спецификация набора символов: us-ascii или ISO-8859-X, где X - одиночная цифра, например ISO-8859-1. Поле кодировка содержит один символ, характеризующий метод кодировки. В настоящее время описаны два метода:

    1. Q - набор печатных символов; символы, коды которых имеют неравный нулю 8-ой бит, отображается тремя символами: знаком равенства (=), за которым следует два шестнадцатеричных числа (например =AD). Так пробел будет иметь кодировку =20.

    2. B - 64-символьный набор (Base64, латинские буквы, 10 цифр, а также символы + и /). Набор кодов Base64 приведен в таблице:

    Таблица 4.5.10.3. Коды Base64

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    Код
    символа
    (6 бит)

    ASCII
    символ

    0

    A

    10

    Q

    20

    g

    30

    w

    1

    B

    11

    R

    21

    h

    31

    x

    2

    C

    12

    S

    22

    i

    32

    y

    3

    D

    13

    T

    23

    j

    33

    z

    4

    E

    14

    U

    24

    k

    34

    0

    5

    F

    15

    V

    25

    l

    35

    1

    6

    G

    16

    W

    26

    m

    36

    2

    7

    H

    17

    X

    27

    n

    37

    3

    8

    I

    18

    Y

    28

    o

    38

    4

    9

    J

    19

    Z

    29

    p

    39

    5

    A

    K

    1A

    a

    2A

    q

    3A

    6

    B

    L

    1B

    b

    2B

    r

    3B

    7

    C

    M

    1C

    c

    2C

    s

    3C

    8

    D

    N

    1D

    d

    2D

    t

    3D

    9

    E

    O

    1E

    e

    2E

    u

    3E

    +

    F

    P

    1F

    f

    2F

    v

    3F

    /

    Интересным дополнением к традиционной электронной почте является ее расширение MIME (Multipurpose Internet Mail Extensions, RFC-1521). MIME не требует каких-либо переделок в почтовых серверах, это расширение определяет пять новых полей-заголовков (расширение RFC-822):

    MIME-Version:

    (версия MIME, сейчас 1.0)

    Content-Type:

    (тип содержимого, см. таблицу на рис. 4.5.10.4)

    Content-Transfer-Encoding:

    (кодирование содержимого)

    Content-ID:

    (идентификатор содержимого)

    Content-Description:

    (описание содержимого)

    Поле заголовка Content-Transfer-Encoding используется пять видов кодировки (третий вид полей в приведенном выше списке):

    1. 7-бит (NVT ASCII, по умолчанию);
    2. Набор печатных символов (полезен, когда только небольшая часть символов использует 8-ой бит);
    3. 64-символьный набор (Base64 см. выше в таблице 4.5.10.3);
    4. 8-битный набор символов, включающий псевдографику, с использованием построчного представления;
    5. Двоичная кодировка (8-битное представление без построчного представления).

    Только первые три типа согласуются с требованиями RFC-821. MIME позволяет снять с электронной почты привычные ограничения и предоставляет возможность пересылать любую информацию. Техника приложений (Attachment) позволяет пересылать через электронную почту любые файлы без какого-либо специального преобразования, выполняемого пользователем. При этом необходимо только, чтобы и приемник и передатчик поддерживали это расширение электронной почты. В MIME предусмотрены следующие типы и субтипы содержимого почтового сообщения:

    Таблица 4.5.10.4. Типы и субтипы почтовых сообщений.

    Тип почтового сообщения

    Субтип
    почтового сообщения

    Описание

    text

    plain

    Неформатированный текст

    richtext

    Текст с простым форматированием, таким как курсив, жирный, с подчеркиванием и т.д.

    enriched

    Упрощение, прояснение и усовершенствование richtext

    multipart

    mixed

    Сообщение содержит несколько частей, которые обрабатываются последовательно

    parallel

    Сообщение содержит несколько частей, обрабатываемых параллельно

    digest

    Краткое содержание почтового сообщения

    alternative

    Сообщение содержит несколько частей с идентичным семантическим содержимым

    message

    RFC822

    Содержимое является почтовым сообщением в стандарте RFC-822

    partial

    Содержимое является фрагментом почтового сообщения

    external-body

    Содержимое является указателем на действительный текст сообщения

    application

    octet-stream

    Произвольная двоичная информация

    postscript

    PostScript программа

    image

    jpeg

    Формат ISO 10918.

    gif

    Формат обмена CompuServe (Graphic Interchange Format).

    audio

    basic

    Формат ISO 11172

    Текст электронного сообщения не передает всех оттенков мыслей и эмоций отправителя, что может вызвать неверное восприятие. Для решения этой проблемы хотя бы частично используются символьные обозначения эмоций. Таблица таких обозначений приведена ниже. Чтобы легче воспринять и запомнить их, посмотрите на страницу, где напечатана таблица, справа.

    Символ

    Значение

    :-)

    Улыбка

    :-D

    Смех

    ;-)

    Подмигивание

    :-(

    Неудовольствие

    :-<

    Огорчение

    8-)

    Удивление

    :-o

    О, нет!

    :-I

    Безразличие

    :-#

    Вынужденная улыбка

    :-]

    Ухмылка

    :-{)

    Улыбка с усами

    {:-)

    Улыбка с париком

    :-X

    Мой рот на замке

    =:-)

    Панк-рокер

    =:-(

    Настоящий панк-рокер никогда не улыбается

    %^)

    Название для этой улыбки читателям предлагается придумать самостоятельно

    В последнее время большинство почтовых серверов реализуется в среде UNIX, где функцию почтового демона (фонового процесса) выполняет программа sendmail. Эта программа осуществляет переадресацию сообщений от пользователя пользователю и от сервера серверу. Программа эта имеет большие возможности, но ее конфигурирование и использование представляет немалые трудности.

    Previous: 4.5.9 Серверы подписки (LISTSERV)    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.11 Gopher


    previous up down next index index
    Previous: 4.5.10 Электронная почта    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.12 WAIS

    4.5.11 Gopher
    Семенов Ю.А. (ГНЦ ИТЭФ)

    GOPHER (RFC-1436) представляет собой систему для поиска и доставки документов, хранящихся в распределенных хранилищах-депозитариях. Система разработана в университете штата Миннесота (на гербе этого штата изображен хомяк, по-английски gopher). Программа Gopher предлагает пользователю последовательность меню, из которых он может выбрать интересующую его тему или статью. Объектом поиска может быть текст или двоичный файл (во многих депозитариях даже текстовые файлы хранятся в архивированном, а следовательно, двоичном виде), графический или звуковой образ. Gopher кроме того предлагает шлюзы в другие поисковые системы WWW, Wais, Archie, Whois, а также в сетевые утилиты типа telnet или FTP. Gopher может предложить больше удобств для работы с оглавлением файлов (directory), чем FTP. Для доступа в глобальную сеть Gopher использует модель клиент-сервер. Система Gopher в настоящее время устарела, многие ее серверы интегрированы в сеть WEB. Но gopher явился прототипом современных интерфейсов WWW и именно делает его интересным.

    Для реализации доступа пользователь должен работать в рамках протоколов TCP/IP и иметь на своей машине программу-клиент одной из версий gopher. Существуют версии Gopher на IBM/PC (MS-DOS), VMS, UNIX, X-Windows и т.д. Многие версии публично доступны с помощью анонимного FTP в различных депозитариях, например, boombox.micro.umn.edu секция /pub/gopher. При постановке программы-клиента необходимо среди прочего указать адрес сервера-gopher. Для России можно использовать серверы (при равных условиях предпочтительнее серверы, отстоящие на меньшее число шагов; многие серверы gopher в настоящее время уже закрыты):

    internet адрес

    login

    Страна

    gopher.chalmers.se (129.16.221.40)

    gopher

    Швеция

    gopher.sunet.se (192.36.125.2)

    gopher

    Швеция

    gopher.uv.es (147.156.1.12)

    gopher

    Испания

    gopher.brad.ac.uk (143.53.2.5)

    info

    Англия

    gopher://gopher.bubl.bath.ac.uk/

     

    Англия

    gopher://gopher.uni-bayreuth.de/

     

    Германия

    gopher://gopher.uni-paderborn.de/

     

    Германия

    gopher://gopher.uni-essen.de/

     

    Германия

    gopher://gopher.uni-passau.de/

     

    Германия

    gopher://gopher.ebone.net/

    gopher

    Европа

    gopher://gopher.e-technik.tu-muenchen.de/

     

    Германия

    gopher://gopher.dkrz-hamburg.de/

     

    Германия

    gopher.denet.dk (129.142.6.66)

    gopher

    Дания

    gopher.uiuc.edu (128.174.5.61)

    gopher

    США

    gopher.virginia.edu (128.143.22.36)

    gwis

    США

    consultant.micro.umn.edu (134.84.132.4)

    gopher

    США

    gopher://gopher.info.usaid.gov/

     

    США

    gopher.ohiolink.edu (130.108.120.25)

    gopher

    США

    info.anu.edu.au (150.203.84.20)

    info

    Австралия

    infopath.ucsd.edu (132.239.50.100)

    info path

    США

    jake.esu.edu

     

    США

    nic.merit.edu

     

    США

    scilibx.ucsc.edu (128.114.143.4)

    gopher

    США

    trainmat.ncl.ac.uk

     

    Англия

    grits.vadosta.peachnet.edu (131.144.8.206)

    gopher

    США

    panda.uiowa.edu (128.255.40.201)

     

    США

    wsuaix.csc.wsu.edu (134.121.1.40)

    wsuinfo

    США

    gopher.msu.edu (35.8.2.61)

    gopher

    США

    gopher.unc.edu (152.2.22.81)

    gopher

    США

    twosocks.ces.ncsu.edu (152.1.45.21)

    gopher

    США

    ecosys.drdr.virginia.edu (128.143.96.10)

    gopher

    США

    gopher.ncc.go.jp (160.190.10.1)

    gopher

    Япония

    При выдаче команды Gopher система свяжет вас с сервером, указанным вами при постановке программы. Можно связаться с любым другим сервером, выдав команду: Gopher <имя_сервера>, где <имя_сервера> имя Gopher-сервера, выбранного вами.

    Большинство программ-клиентов позволяют пользователю делать "закладки" (bookmarks), которые содержат информацию о месте хранения объекта и пути доступа к нему. Закладки сохраняются и при выходе из Gopher, что облегчает продолжение поиска или нахождение объекта, найденного ранее. Набор функций программы-клиента зависит от ее конкретной реализации и от программного обеспечения ЭВМ, на которой она работает. Gopher обеспечивает простой и удобный интерфейс (лучше чем в обычном www с использованием меню, но хуже чем в MS internet explorer или netscape), позволяя работать с мышкой и предельно упрощая копирование найденных файлов.

    Обычно gopher имеет также автоматическую систему поиска объектов по ключевым словам в более чем 500 меню. Это крайне важно, так как пользователь не может знать все адреса серверов. Система носит имя Veronica (Very Easy Rodent-Oriented Net-wide Indexed Computerized Archives). Ключевое слово может быть набрано строчными или заглавными буквами. Veronica-сервер возвращает результат поиска в виде gopher-меню, где содержатся записи, в текстах которых присутствуют искомые ключевые слова. Доступ к Veronica возможен либо из базового меню или из из рубрики Other gopher servers... Для того чтобы ваш сервер стал известен окружающему миру, он должен быть зарегистрирован в сервере университета Миннесоты (США) или в любом другом уже зарегистрированном сервере.

    Объекты в меню обычно снабжаются символами-признаками, которые позволяют судить о типе объекта. Так, например, "<?>" означает полнотекстный индексный поиск, "/" - subdirectory, "<picture>" - указывает, что здесь хранится изображение, отсутствие какого-либо символа означает, что это текстовый файл.

    Если вы располагаете рабочей версией gopher, вызов программы можно выполнить командой Gopher или, например, gopher gopher.micro.umn.edu 70. В последнем случае обращение будет произведено к конкретному серверу, имя которого указано в качестве параметра команды. Число 70 указывает на номер порта (стандартное значение для gopher). Ниже приводится пример меню gopher:

    Internet gopher information client v2.0.12 information about gopher

    1. about gopher.
    2. search gopher news <?>
    3. gopher news archive/
    4. comp.infosystems.gopher (usenet newsgroup)/
    5. gopher software distribution/
    6. gopher protocol information/
    7. university of minnesota gopher software licensing policy.
    8. frequently asked questions about gopher.
    9. gopher93/
    10. gopher example server/
    11. how to get your information into gopher.

    -->   12. new stuff in gopher.
    13. reporting problems or feedback.
    14. big ann arbor gopher conference picture.gif <Picture>
    Press ? for Help, q to Quit, u to go up a menu Page: 1/1

    Выбор пункта из меню может выть выполнен мышкой, путем печатания номера соответствующей строки и последующего нажатия клавиши <Enter>, или путем движения курсора с помощью клавишей стрелок с последующим нажатием клавиши <Enter>. В приведенном выше примере курсор указывает на пункт меню с номером 12. Если в такой ситуации нажать клавишу <Enter>, обращение произойдет именно сюда. Звуковые и графические файлы имеют формат uuencode.

    Существует возможность доступа к GopherMail-серверам, которые пересылают заказчику текст базового меню. GopherMail включат в себя следующие возможности (что-то вроде игры в шахматы по переписке):

    • Разбиение сообщений, если они слишком велики.
    • Деление меню на части, если его число строк слишком велико.
    • Повторное использование связей, записанных в файлах-закладок (bookmarks).
    • Запрос меню Gopher заданной ЭВМ.
    • Пометка выбранного пункта меню символом "X" (или Xn, где n - номер строки меню).
    • Запрос help-файла.
    • Запрос записей из архива Info-Mac.
    • Запрос записей Gopher с их аннотациями.

    Вы можете задать предельные размеры сообщения и меню, включив в текст сообщения команды, например:

    Split=25K
    Menu=75

    Для работы с Gopher через электронную почту вы можете выбрать ближайший GopherMail-сервер из предлагаемого списка:

    gopher@earn.net

    France

    gopher@ftp.technion.ac.il

    Israel

    gopher@join.ad.jp

    Japan

    gopher@nig.ac.jp

    Japan

    gopher@nips.ac.jp

    Japan

    gopher@solaris.ims.ac.jp

    Japan

    gophermail@ncc.go.jp

    Japan

    gopher@dsv.su.se

    USA

    Если вы хотите узнать больше о GOPHER можете подписаться на новости о GOPHER по адресу: gopher-news-request@boombox.micro.umn.edu. Если для вас доступен NEWS-server, то секция GOPHER имеет там имя omp.infosystem.gopher. В сложных случаях за справками можно обратиться к разработчикам GOPHER по адресу:

    gopher@boombox.micro.umn.edu. При проблемах с VERONICA можно написать письмо ее разработчикам Steve Foster и Fred Barrie в университет Невады по адресу:

    gophadm@futique.scs.unr.edu. Но не злоупотребляйте этим, у них есть и свои заботы.

    Previous: 4.5.10 Электронная почта    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.12 WAIS


    previous up down next index index
    Previous: 4.5.11 Gopher    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.13 Система поиска файлов Archie

    4.5.12 WAIS
    Семенов Ю.А. (ГНЦ ИТЭФ)

    WAIS (Wide Area Information Server) распределенная система поиска информации. Поиск производится по базам данных, содержащим текстовые документы (но допустимы также графические, звуковые или видео документы). Тематика баз данных и поиска произвольны. Базы данных могут иметь любую структуру, но пользователю не нужно знать языка управления этими базами. WAIS использует естественный управляющий язык. WAIS доступен в Интернет. Для пользователей, имеющих доступ только к электронной почте, предназначен интерфейс, размещенный по адресу waismail@quake.think.com. В сети Интернет существует много серверов WAIS. Список депозитариев серверов достаточно широк, начать можно с анонимного FTP по адресу Think.com секция /wais, файл wais-sources.tar.Z (файл архивирован и пересылка должна осуществляться в режиме BINARY). В настоящее время многие WAIS-сервера интегрированы в сети WEB.

    Доступ к WAIS-клиентам возможен и напрямую с помощью команды TELNET по адресам:

     

    Авторизация

    Место расположения

    quake.think.com (192.31.181.1)

    (login: wais)

    США

    sunsite.unc.edu (152.2.22.81)

    (login: swais)

    США

    info.funet.fi (128.214.6.102)

    (login: wais)

    Финляндия

    swais.cwis.uci.edu (128.200.15.2)

    (login: swais)

    США

    kunzu.cnidr.org (128.109.130.57)

    (login: wais)

    США

    nnsc.nsf.net (128.89.1.178)

    (alogin: wais)

    США

    Существуют клиент-серверы WAIS для систем MS-DOS, VMS, MVS, OS/2, UNIX и Macintosh, а также для GNU Emacs, NeXT, X-Windows, MS-Windows, Sunview и т.д. Эти продукты несколько отличаются друг от друга, но обычно процедура содержит следующие шаги:

    1. Пользователь выбирает набор баз данных, где будет проводиться поиск, из числа имеющихся.
    2. Формулируется задание на поиск, выбираются ключевые слова.
    3. В процессе поиска WAIS запрашивает информацию из всех указанных баз данных.
    4. Отображаются заголовки документов, отвечающих критериям отбора. Документы аранжируются согласно их степени соответствия условиям запроса.
    5. Для получения копии пользователь просто отбирает документы из предлагаемого списка.
    6. При необходимости пользователь может переформулировать критерии отбора и повторить поиск.
    7. Вновь найденные документы, если они не совпадают с уже известными будут добавлены в список.

    Ниже приводится таблица команд WAIS

    Таблица 4.5.13.1. Команды WAIS

    Основные команды

    h

    Выдать перечень команд [help]

    ?

    тоже что и h

    q

    Уйти из WAIS (quit)

    Смена текущей строки

    DOWN

    Сместиться на одну строку вниз

    j

    То же, что и DOWN

    Ctrl-N

    То же, что и DOWN

    UP

    Сместиться на одну строку вверх

    k

    То же, что и UP

    Ctrl-P

    То же, что и UP

    число

    Переход к строке с указанным номером

    /эталон

    Перейти к строке, начинающейся с эталона

    J

    Сместиться на один экран вниз

    Ctrl-D

    То же, что и J

    K

    Сместиться вверх на один экран

    Ctrl-U

    То же, что и K

    Выбор источника

    Пробел

    Выбор или отмена выбора источника

    =

    Отменить выбор каких-либо источников

    RETURN

    После выбора источников запрашивает новое ключевое слово

    r

    Заново отображает результат предшествующего поиска

    v

    Отображает техническую информацию об источнике

    Выполнение поиска

    RETURN

    Начало поиска после ввода ключевых слов

    RETURN

    Отображает результат при просмотре результата поиска

    w

    Запрос новых ключевых слов

    s

    Повторное отображение первоначального экрана

    Чтение статьи

    пробел

    Отобразить следующий экран

    q

    Прервать чтение статьи (quit).

    Имеется возможность доступа к ресурсам системы WAIS и через электронную почту. Запрос посылается по адресу waismail@quake.think.com, строка Subject игнорируется. Далее (в теле сообщения) могут следовать команды (вертикальная черта (|) указывает на выбор параметров):

    help

    отображение справочного файла

    maxres number

    установка максимального числа искомых документов

    search source-name | "source-name1 source-name2 ... " keywords

    где: source-name имя источника, как оно было найдено в оглавлении сервера (с или без расширения .SRC). Если нужно провести поиск по нескольким источникам, их имена заключаются в двойные кавычки. keywords ключевые слова, по которым проводится поиск.

    Можно сформулировать несколько запросов в одном e-mail. Если имя источника не будет узнано, вы получите список имен возможных источников.

    retrieve docid

    Извлечение копии документа из базы данных. docid является DocID (идентификатор найденного документа). Если вы посылаете несколько запросов, они должны быть разделены пустыми строками. docid должен строго соответствовать имени документа, полученного вами в результате запроса-поиска (включая пробелы, если они имелись). Могут копироваться не только текстовые документы. Такие документы будут пересланы в формате UUENCODE.

    DocID: docid

    То же, что и retrieve. Эта форма идентична по форме ответу на поисковый запрос. Процедура делает возможным использовать replay в e-mail для копирования найденных документов.

    Примеры использования WAIS

    telnet quake.think.com
    Trying 192.216.46.98 ... (IP-адрес сервера)
    Connected to quake.think.com.
    Escape character is '^]'.
    SunOS UNIX (wais)
    login: wais (ввод идентификатора)
    Last login: Sun Aug 27 01:57:07 from france.cityu.edu
    Welcome to swais, the text-terminal telnet client to WAIS.
    Please type user identifier (optional, i.e. user@host): semenov@ns.itep.ru

    (в качестве пароля предлагается напечатать ваш почтовый адрес).

    TERM = (vt100) ibmpc (нужно ввести тип терминала, с которым вы работаете)

    Starting up. This may take awhile...
    SWAIS Source Selection Sources: 549

    #

    Server

    Source

    Cost

    001:

    [ wais.access.gpo.gov]

    103_cong_bills

    Free

    002:

    [ wais.access.gpo.gov]

    104_cong_bills

    Free

    003:

    [ wais.access.gpo.gov]

    1992_cri

    Free

    004:

    [ wais.access.gpo.gov]

    1993_cri

    Free

    005:

    [ wais.access.gpo.gov]

    1994_cri

    Free

    006:

    [ wais.access.gpo.gov]

    1994_hob

    Free

    007:

    [ wais.access.gpo.gov]

    1994_record

    Free

    008:

    [ wais.access.gpo.gov]

    1994_register

    Free

    009:

    [ wais.access.gpo.gov]

    1994_unified_agenda

    Free

    010:

    [ wais.access.gpo.gov]

    1995_cri

    Free

    011:

    [ wais.access.gpo.gov]

    1995_hob

    Free

    012:

    [ wais.access.gpo.gov]

    1995_record

    Free

    013:

    [ wais.access.gpo.gov]

    1995_register

    Free

    014:

    [ wais.access.gpo.gov]

    1995_unified_agenda

    Free

    015:

    [ archie.au]

    aarnet-resource-guide

    Free

    016:

    [ndadsb.gsfc.nasa.gov]

    AAS_jobs

    Free

    017:

    [ndadsb.gsfc.nasa.gov]

    AAS_meeting

    Free

    018:

    [ munin.ub2.lu.se]

    academic_email_conf

    Free

    Keywords:

    <space> selects, w for keywords, arrows move, <return> searches, q quits, ? for Help

    Слово Free на правом поле означает бесплатный доступ. Сразу после вывода на экран оказывается подсвеченной позиция <001> (номера позиций проставлены на левом поле). В квадратных скобках приведены адреса серверов, доступ к которым может быть предоставлен, сразу за ним следует наименование базы данных или документа. Используя стрелки <вверх> и <вниз>, можно подсветить нужную вам позицию. После нажатия клавиши <Enter> (или на некоторых клавиатурах RETURN) позиция будет выбрана и вам будет предложена возможность ввести ключевые слова для последующего поиска. Выберем для примера aarnet-resource-guide.src.

    Enter keywords with spaces between them; <return> to search; ^C to cancel
    Keywords: isdn (в качестве ключевого слова введено ISDN).
    Searching aarnet-resource-guide.src...
    Initializing connection...
    Searching 1995_register
    Found 1 items.

    SWAIS Search Results

    Items: 1

    #

    Score

    Source

    Title

    Lines

    001:

    [1000]

    (aarnet-resource)

    Charles Sturt University

    66

    <space> selects, arrows move, w for keywords, s for sources, ? for help
    Retrieving: Charles Sturt University
    Getting "Charles Sturt University" from aarnet-resource-guide.src...
    WARNING: terminal cannot "scroll backwards" (press RETURN)

    (ниже следует текст документа)

    Charles Sturt University

    Address:

    Division of Information Technology PO Box 588 WAGGA WAGGA 2650

    E-mail: cc_director@csu.edu.au Phone: +61 69 222206 Fax: +61 69 222454

    Description:

    The Division of Information Technology offers computing services for teaching, research and university administration and is a centrally funded support service of the University.

    The University has a Facom 340S, VAX 6320 and 6310 systems (VMS), a HP935 (HP-UX), and a SUN 4/75S, as well as a range of workstation-level Unix hosts.

    Numerous PC and Mac Networks are spread through the faculties and divisions. ISDN links between the three campuses of CSU bring the ethernet/fibre "backbones" on each individual campus into a single university-wide TCPIP/LAT Network.

    Network Access: Systems are generally available via AARNet and Austpac.
    Who Can Use:
    Computing services are provided to Charles Sturt University community.
    Account for outside users are considered on a case by case basis.

    Press any key to continue

    (для того чтобы продолжить просмотр текста следует нажать любую клавишу).

    Возможна и несколько другая форма доступа к WAIS (например, из ЭВМ SUN):

    ns> telnet info.funet.fi
    Trying 128.214.6.21 ...
    Connected to info.funet.fi.
    Escape character is '^]'.
    SunOS UNIX (info)
    Finnish University and Research Network FUNET Information Service
    The following information services are available:

    gopher

    Menu-based global information tool

    www

    World Wide Web, Global hypertext web

    wais

    Wide Area Information Server, global databases on different topics

    x500

    X.500 clients are on nic.funet.fi, login: dua, no password

    archie

    Database of Internet Archive contents

    exit

    Exit FUNET information services

    Select service (gopher/www/wais/archie/exit) ? wais (выбран WAIS)
    Select WAIS interface:
    swais VT100-based WAIS client
    Select interface (return for back to main menu) ? swais
    Supported terminal types are: vt100, xterm
    Starting WAIS ..

     

    Source Selection

    Server Source

    Cost

    001:

    [ archie.au]

    aarnet-resource-guide

    Free

    002:

    [ munin.ub2.lu.se]

    academic_email_conf

    Free

    003:

    [wraith.cs.uow.edu.au]

    acronyms

    Free

    004:

    [ archive.orst.edu]

    aeronautics

    Free

    005:

    [ ftp.cs.colorado.edu]

    aftp-cs-colorado-edu

    Free

    006:

    [nostromo.oes.orst.ed]

    agricultural-market-news

    Free

    007:

    [ archive.orst.edu]

    alt.drugs

    Free

    008:

    [ wais.oit.unc.edu]

    alt.gopher

    Free

    009:

    [sun-wais.oit.unc.edu]

    alt.sys.sun

    Free

    010:

    [ wais.oit.unc.edu]

    alt.wais

    Free

    011:

    [alfred.ccs.carleton.]

    amiga-slip

    Free

    012:

    [ munin.ub2.lu.se]

    amiga_fish_contents

    Free

    013:

    [ 150.203.76.2]

    ANU-Aboriginal-EconPolicies

    $0.00/minute

    014:

    [ coombs.anu.edu.au]

    ANU-Aboriginal-Studies

    $0.00/minute

    015:

    [ coombs.anu.edu.au]

    ANU-Asian-Computing

    $0.00/minute

    016:

    [ coombs.anu.edu.au]

    ANU-Asian-Religions

    $0.00/minute

    017:

    [ 150.203.76.2]

    ANU-Australian-Economics

    $0.00/minute

    018:

    [ 150.203.76.2]

    ANU-CAUT-Academics

    $0.00/minute

    Российского пользователя не остановит и плата за ресурс, если она составляет $0.00. Выберем позицию agricultural-market-new, а в качестве ключевого слова введем price (кого не интересуют цены на продукты питания?):

    Keywords: price
    Searching agricultural-market-news.src...
    Initializing connection...
    Found 40 items. (найдено 40 записей)
    SWAIS Search Results Items: 40
    # Score Source Title Lines

    001:

    [1000]

    (agricultural-ma)

    Re:

    MG

    LS756

    002:

    [772]

    (agricultural-ma)

    Re:

    MG

    LS754

     

    211

    003:

    [557]

    (agricultural-ma)

    Re:

    AM

    LS753

    SUP%RIOR VIDEO

    277

    004:

    [514]

    (agricultural-ma)

    Re:

    MG

    LS750

     

    155

    005:

    [500]

    (agricultural-ma)

    Re:

    ML

    LS143

    QUINCY AUCTION,QUINCY

    158

    006:

    [486]

    (agricultural-ma)

    Re:

    WA

    PY100

    CHICKEN PURCHASES

    480

    007:

    [457]

    (agricultural-ma)

    Re:

    RH

    LS751

     

    127

    008:

    [443]

    (agricultural-ma)

    LS.

    MN

    LL Re:

    USDA 04/26/94 20:51

    172

    009:

    [443]

    (agricultural-ma)

    Re:

    ML

    LS144

    TOPPENISH (RESEND)

    161

    010:

    [400]

    (agricultural-ma)

    Re:

    KO

    LS757

    ADA WGTD AVG W/COWS

    115

    011:

    [371]

    (agricultural-ma)

    Re:

    RH

    LS764

     

    138

    012:

    [343]

    (agricultural-ma)

    Re:

    KO

    LS752

    MCALESTER WGTD AVGW/COW

    100

    013:

    [343]

    (agricultural-ma)

    Re:

    MG

    LS752

     

    91

    014:

    [343]

    (agricultural-ma)

    Re:

    MG

    LS797

     

    122

    015:

    [343]

    (agricultural-ma)

    Re:

    RH

    LS750

     

    107

    016:

    [343]

    (agricultural-ma)

    Re:

    RH

    LS757

    ROCKINGHAM FEEDER CATTLE

    140

    017:

    [343]

    (agricultural-ma)

    Re:

    RH

    LS758

    STAUNTON UNION FEEDERCA

    102

    018:

    [343]

    (agricultural-ma)

    Re:

    RH

    LS795

     

    114

    <space> selects, arrows move, w for keywords, s for sources, ? for help

    Выбираем позицию <3>. Ниже следует текст, выданный в результате на экран.

    Retrieving: Re: AM LS753 SUPRIOR VIDEO "Re: SUP%RIOR
    VIDEO" from agricultural-market-news.src...
    SWAIS Document Display Page: 1
    Subject: AM LS753 SUP%RIOR VIDEO
    Date: Mon, 21 Aug 95 01:58:17 PM
    AM LS753
    Amarillo, Texas Mon Aug 21, 1995 USDA-TX Dept of Ag Market News
    Superior Video Auction - Final Report - Two day auction Aug 18 & 19.
    Offerings < 91,000

    Trade and demand moderate to good. Cattle offered from 16 States, Mexico and Canada. Prices based on net weights after a 1-3 percent shrink or equivalent with a 4-10 cent slide on calves and 3-8 cent slide on yearlings. Offerings included 31 percent feeder steers and differs over 600 lbs and 69 percent feeders under 600 lbs.

    ************************************************************
    Press any key to continue, 'q' to quit.
    Southcentral States: Texas, Oklahoma, New Mexico,
    Kansas and Missouri.
    ************************************************************

    Feeder Steers Medium and Large 1

    Head

    Weight

    Avg Wt

    Price

    Avg Price

    Delivery

    220

    425-425

    425

    74.10-74.10

    74.10

    Current

    84

    625-625

    625

    67.35-67.35

    67.35

    Current

    60

    850-850

    850

    62.00-62.00

    62.00

    Current

    190

    525-525

    525

    66.25-66.25

    66.25

    Septmbr

    78

    585-585

    585

    69.35-69.35

    69.35

    Septmbr

    130

    740-740

    740

    64.85-64.85

    64.85

    Septmbr

    382

    800-835

    821

    64.00-66.00

    64.96

    Septmbr

    540

    860-860

    860

    64.35-64.35

    64.35

    Septmbr

    70

    360-360

    360

    77.50-77.50

    77.50

    Oct+Nov

    Press any key to continue, 'q' to quit. (таблица напечатана с сокращениями)

    Если вы выдали более одного ключевого слова, тогда все документы, содержащие любое из перечисленных слов будут включены в список найденных.

    Если нужно узнать о WAIS больше (библиография, утилиты, исходные тексты), обращайтесь к Barbara Lincoln Brooks из WAIS inc. Библиография доступна по адресу ftp.wais.com в секции /pub/wais-inc-doc. Общую информацию по WAIS можно найти через FTP по адресу: quake.think.com /wais/doc или sunsite.unc.edu /pub/docs/about-the-net/libsoft/wais.txt. Для любителей доступа через WWW: www.wais.com или www.earn.net. Те же, кто для целей поиска предпочитает gopher, могут воспользоваться сервером: gopher-gw.micro.umn.edu. Можно узнать кое-что о WAIS и через telnet: quake.think.com Login: wais.

    Программы доступны по адресам (FTP): ftp.cnidr.org ftp.wais.com quake.think.com sunsite.unc.edu

    По вопросам получения бесплатного программного обеспечения обращайтесь по адресу: freewais@cnidr.org. Подписной почтовый лист имеет адрес: wais-discussion@wais.com. Для подписки посылайте запрос по адресу (формат запросов описан в разделе LISTSERV): wais-discussion-request@wais.com. Группа новостей в USENET (FAQ): comp.infosystems.wais; полезную информацию можно получить и через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/wais-faq.

    Previous: 4.5.11 Gopher    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.13 Система поиска файлов Archie


    previous up down next index index
    Previous: 4.5.12 WAIS    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.14 Современные поисковые системы

    4.5.13 Система поиска файлов Archie
    Семенов Ю.А. (ГНЦ ИТЭФ)

    ARCHIE - информационная система с наиболее эффективной системой поиска. Система разработана Аланом Эмтейджем, Питером Дойчем и Билом Хееланом из университетского вычислительного центра McGill, Канада. ARCHIE осуществляет поиск по более чем 1000 депозитариям мира допускающим анонимный доступ и содержащим более 2100000 файлов. ARCHIE работает под Windows, MS-DOS, Macintosh, Unix в рамках сети INTERNET. Рекомендуется следовать следующим правилам (в последнее время система стала менее популярна, ее функции взяли на себя поисковые сервера):

    • избегайте проводить поиск в рабочие часы, так как большинство ARCHIE- серверов выполняют и другие локальные функции.
    • запросы должны быть как можно конкретнее, это ускорит их выполнение.
    • интерфейс на вашей ЭВМ снизит нагрузку удаленных серверов, поэтому рекомендуется использовать локальные интерфейсы.
    • используйте ближайший к вам ARCHIE-сервер, это сократит нагрузку телекоммуникационных каналов и повысит надежность поиска.

    Базы данных ARCHIE располагаются по адресам:

    Адрес ARCHIE

    Страна

    Число шагов из ITEPNet *)

    archie.au (139.130.4.6)

    Австралия

    23

    archie.edvz.uni-linz.ac.at (140.78.3.8)

    Австрия

     

    archie.univie.ac.at (131.130.1.23)

    Австрия

    17

    archie.uqam.ca (132.208.250.10)

    Канада

    21

    archie.funet.fi (128.214.6.102)

    Финляндия

    9

    archie.th-darmstadt.de (130.83.128.118)

    Германия

    13

    archie.doc.ic.ac.uk (146.169.11.3)

    Англия

    16

    archie.ac.il (132.65.16.8)

    Израиль

    19

    archie.cs.huji.ac.il (132.65.6.15)

    Израиль

     

    archie.unipi.it (131.114.21.10)

    Италия

    12

    Archie.uninett.no (128.39.2.20)

    Норвегия

     

    archie.kuis.kyoto-u.ac.jp

    Япония

    29

    archie.wide.ad.jp (133.4.3.6)

    Япония

     

    archie.kr

    Корея

     

    archie.sogang.ac.kr (163.239.1.11)

    Корея

     

    archie.rediris.es (130.206.1.2)

    Испания

    12

    archie.nz (130.195.9.4)

    Новая Зеландия

    25

    archie.luth.se (130.240.18.4)

    Швеция

    15

    archie.switch.ch (130.59.1.40)

    Швейцария

    15

    archie.ncu.edu.tw (140.115.19.24)

    Тайвань

     

    archie.ans.net (147.225.1.10)

    США

    23

    archie.internic.net (198.49.45.10)

    США

    16

    archie.rutgers.edu (128.6.18.15)

    США

     

    archie.sura.net (128.167.254.179)

    США

     

    archie.unl.edu (129.93.1.14)

    США

    20

    *) Число шагов величина непостоянная и может изменяться со временем, сильно зависит от используемого маршрута.

    Имеется возможность доступа к ARCHIE через локальный клиент-сервер, через команду telnet или с помощью электронной почты. В настоящее время доступна версия сервера 3.0. Команды, помеченные ниже (+) работают только с версией 3.0, помеченные же (*), работают только с предшествующими версиями. Для определения версии, с которой вы работаете, выдайте команду version. Локальные серверы работают быстрее и надежнее. В публичном доступе имеются версии для MS-DOS, OS/2, VMS, NeXT, Unix, X-windows и Macintosh. Клиент-серверы доступны через анонимный FTP в каталогах /pub/archie/clients ли /archie/clients, обычно это строчные варианты. Существует и графическая версия (xarchie) для X-windows. Стандартное обращение к ARCHIE имеет форму:

    ARCHIE <-options> последовательность символов | образ

    где options могут быть:

    o

    определяет имя выходного файла для запоминания результата.

    l

    список найденных объектов по одной строке на документ.

    t

    сортирует результат поиска по датам.

    m#

    определяет максимальное число найденных документов (# от 0 до 1000), по умолчанию это число равно 95.

    H archie-server

    специфицирует сервер, куда посылается запрос, в отсутствии этого параметра используется сервер по умолчанию, если такой описан.

    L

    список известных серверов, включая текущий.

    Например, команда (SUN): archie -L выдаст на экран:

    Known archie servers:

    archie.ans.net (USA [NY])
    archie.rutgers.edu (USA [NJ])
    archie.sura.net (USA [MD])
    archie.unl.edu (USA [NE])
    archie.mcgill.ca (Canada)
    archie.funet.fi (Finland/Mainland Europe)
    archie.au (Australia)
    archie.doc.ic.ac.uk (Great Britain/Ireland)
    archie.wide.ad.jp (Japan)
    archie.ncu.edu.tw (Taiwan)
    * archie.funet.fi is the default Archie server.
    * For the most up-to-date list, write to an Archie server and give it the command `servers'.

    Следующая группа options определяет разновидность поиска.

    s

    объект будет выбран, если имя файла/каталога содержит заданную последовательность символов. Поиск не зависит от того, строчные или заглавные буквы использованы в эталонной последовательности.

    c

    как и выше, но для поиска не безразличны строчные/заглавные буквы.

    e

    последовательность символов должна точно совпадать с образцом, с учетом использования заглавных и строчных символов. Это способ поиска по умолчанию.

    r

    поиск образов, которые включают в себя специальные символы, интерпретируемые до начала поиска.

    Результатом поиска может стать список FTP-адресов файлов или каталогов, соответствующих критериям отбора, указывается размер файлов, дата последней модификации и имя каталога, где этот файл лежит.

    Для интерактивного попадания в ARCHIE-сервер используется команда telnet, в ответ на login следует ввести archie. Для того чтобы покинуть ARCHIE-сервер используются команды: exit, quit, bye. Кроме того, существуют следующие команды:

    help ?

    Выдает полный список команд

    help <имя команды>

    Выдает описание команды, возврат с помощью клавиши <Enter>.

    help set variable

    Выдает описание присвоения значения системной переменной.

    list <образ>

    Выдает список IP-адресов баз данных и дат их последней коррекции. Параметр, если он присутствует, обеспечивает отбор адресов с учетом соответствия этому параметру. Если нет параметра, то список будет содержать около 1000 адресов. list \.de$ даст адреса в Германии.

    manpage

    Отображение страницы руководства по использованию Archie

    servers

    Выдает список серверов Archie

    site (*) site-name

    Получение списка каталогов и субкаталогов депозитария с именем site-name. Обычно это очень длинный список.

    whatis <строка>

    Осуществляет поиск описания программы для string.

    prog <строка>|<образ> find(+)<строка>|<образ>

    Осуществляет поиск строки <строка> или образа <образ>, представляющий название искомого ресурса. Поиск может выполняться несколькими способами, определяемыми переменной search (команда set), которая также определяет, следует ли интерпретировать параметр как string или pattern. Результат представляет собой список FTP- адресов, размеров найденных объектов и дат последней модификации. Число объектов в списке ограничивается переменной maxhits (команда set). Результат prog может быть отсортирован в соответствии с величиной переменной sortby (команда set). По умолчанию переменные search, maxhits и sortby устанавливаются соответственно на точное соответствие string, 1000 объектов без сортировки результата

    mail <email> <,email2...>

    Отсылает результат поиска по электронной почте по заданному адресу. При команде без параметров результат отсылается по адресу, заданному переменной mailo (команда set).

    show <переменная>

    Отображает значение переменной с данным именем. В отсутствии параметра отображаются все переменные.

    set <переменная> <значение>

    Устанавливает значение одной из переменных ARCHIE.

    Используются следующие переменные:

    compress(+) метод_архивации

    Задает метод архивации (none или compress), используется до отправки почты командой mail. По умолчанию none.

    encode(+) метод_кодирования

    Определяет метод кодирования (none или uuencode), используется при отправке по почте. Эта переменная игнорируется, если компрессии нет. По умолчанию none.

    mailo email <,email2...>

    Определяет e-mail адрес, куда будет послан результат, при выдаче команды без аргумента.

    maxhits number

    Определяет максимальное число отобранных объектов командой prog (0-1000). По умолчанию эта переменная равна 1000.

    search search-value

    Определяет вид проводимого поиска: prog string | prog string | pattern. search-values равны:

    sub

    Частичное совпадение и независимость от заглавная/сточная.

    subcase

    То же, но не безразлично заглавный/сточный символы.

    exact

    Точное соответствие образцу.

    regex pattern

    Интерпретируется перед началом поиска.

    sortby sort-value

    Описывает то, как сортировать результаты поиска по команде prog. Значения sort-values (параметр сортировки):

    hostname

    Сортировка по FTP-адресам в лексическом порядке

    time

    Сортировка по дате модификации, более поздние сначала.

    filename

    Сортировка по именам файлов или каталогов в лексическом порядке

    none

    Никакой сортировки

    size

    Сортировка документов по размеру

    term terminal-type <number-of-rows<number-of-columns>>

    Сообщает ARCHIE, какой терминал используется.

    Доступ через электронную почту

    Пользователи могут получить доступ к ARCHIE через электронную почту, послав запрос по адресу archie@archie.ac.il. Команды посылаются в теле сообщения. Командные строки начинаются всегда с первой колонки. Поле subject рассматривается как строка самого сообщения. При этом допустимы следующие команды:

    help

    Присылает файл HELP, при этом другие команды сообщения игнорируются.

    path return-address set mailto(+) return-address

    Определяет обратный адрес, отличный от того, что записан в заголовке

    list pattern <pattern2...>

    Выдает список адресов, где есть данные, соответствующие pattern, наиболее свежие по дате

    site(*) site-name

    Выдает список каталогов и субкаталогов по адресу site-name

    whatis string <string2...>

    Ищется в базе данных описание программных продуктов, где содержится string. Прописные или строчные буквы роли не играет

    prog pattern <pattern2...> find(+) pattern <pattern2>

    Поиск всех упоминаний ресурсов с именем pattern. Если несколько pattern помещено в одной строке, результат поиска будет прислан в одном сообщении. Если несколько prog помещено в строке, результат присылается в нескольких сообщениях, по одному на каждый prog. Результат представляет собой список адресов для FTP. Если pattern содержит пробелы, он должен быть заключен в кавычки. Поиск не зависит от того, заглавные или строчные буквы использованы в запросе.

    compress(*)

    Полученный результат будет архивирован и перекодирован с помощью uuencode. В результате будет получен файл с расширением .Z. Сначала по получении сообщения следует обработать с помощью uudecode, а после этого следует выполнить программу uncompress

    set compress(+) compress-method

    Специфицирует метод архивирования (none или compress) перед отправкой по почте. По умолчанию none

    set encode(+) encode-method

    Специфицирует метод кодирования (none или uuencode) перед отправкой по почте. По умолчанию none.

    quit

    Ничего не производит, полезна в случае автоматического добавления подписи в конце сообщения.

    Description of pattern pattern

    Описывает последовательность символов, включая специальные символы. Символ перестает быть специальным, если перед ним стоит "\".

    К числу специальных символов относится:

    . (точка)

    Заменяет любые другие символы (wildcard).

    ^

    Появляется в начале pattern. При этом будет искаться будет последовательность, следующая за "^". Например: "^efgh" узнает "efgh" или "efghij" но не "abcdefgh".

    $

    Появляется в конце pattern. Так, например: "efghi$" узнает "efghi" или "abcdefghi" но не узнает "efghijkl".

    Если вы послали команду list \.de$ по электронной почте или с помощью Telnet, вы получите следующий отклик:

    alice.fmi.uni-passau.de

    132.231.1.180

    12:31

    8 Aug 1993

    askhp.ask.uni-karlsruhe.de

    129.13.200.33

    12:25

    8 Aug 1993

    athene.uni-paderborn.de

    131.234.2.32

    15:21

    6 Aug 1993

    bseis.eis.cs.tu-bs.de

    134.169.33.1

    00:18

    31 Jul 1993

    clio.rz.uni-duesseldorf.de

    134.99.128.3

    12:10

    8 Aug 1993

    cns.wtza-berlin.de

    141.16.244.4

    16:08

    31 Jul 1993

    и т.д.

    Если вы пошлете команду whatis compression по почте или посредством Telnet, вы получите следующий результат:

    RFC 468

    Braden, R.T. FTP data compression 1973 March 8; 5p.

    arc

    PC compression program

    deltac

    Image compression using delta modulation

    spl

    Splay tree compression routines

    squeeze

    A file compression program

    uncrunch

    Uncompression program

    unsqueeze

    Uncompression programs (Пример взят из [1])

    В ответ на команду find AMPS, вы получите:

    Host goliat.eik.bme.hu

    (152.66.115.2)

    Last updated 00:02 3 Jan 1995
    Location: /pub/win3/util
    FILE -r--r--r-- 145312 bytes 11:18 22 Dec 1994 amps13.zip

    Host nic.switch.ch

    (130.59.1.40)

    Last updated 01:17 11 Dec 1994
    Location: /mirror/novell/netwire/novuser/01
    FILE -rw-rw-r-- 177681 bytes 02:14 1 Nov 1994 amps15.zip

    Host faui43.informatik.uni.erlangen.de

    (131.188.1.43)

    Last updated 01:31 11 Dec 1994
    Location:
    /mounts/epix/public/pub/pc/windows/cica_mirror/util
    FILE -r--r--r-- 145312 bytes 00:00 2 Jun 1994 amps13.zip

    Host ftp.luth.se

    (130.240.16.39)

    Last updated 17:53 13 Dec 1994

    Location: /pub/msdos/.1/.util
    FILE -r--r--r-- 145312 bytes 01:00 1 Jun 1994 amps13.zip

    Host ftp.cyf

    kr.edu.pl (149.156.1.8)

    Last updated 17:50 3 Jan 1995
    Location: /pub/mirror/ami/chipset_guides
    FILE -rw-r--r-- 111858 bytes 00:00 4 Apr 1994 scampsx.z06
    FILE -rw-r--r-- 46677 bytes 00:00 4 Apr 1994 scampsx.z07

    Это лишь фрагмент выдачи реально она много длиннее. Видно, что один и тот же документ найден в нескольких депозитариях. Если у вас есть вопросы об ARCHIE, пишите Archie Group, Bunyip Information Systems Inc. по адресу info@bunyip.com. В случае обнаружения ошибок, а также с комментариями следует обращаться по адресу archie-admin@bunyip.com. По вопросам, связанным с конкретными серверами можно обратиться по адресу archie-admin@address.of.archie.server, например, archie-admin@archie.ac.il. Список адресов для рассылки информации находится по адресу: archie-people@bunyip.com; для включения в подписной лист можно послать запрос по адресу: archie-people-request@bunyip.com.

    Previous: 4.5.12 WAIS    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.14 Современные поисковые системы


    previous up down next index index
    Previous: 4.5.13 Система поиска файлов Archie    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.15 Диалог в локальных сетях и в Интернет

    4.5.14 Современные поисковые системы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Развитие Интернет начиналось как средство общения и удаленного доступа (электронная почта, telnet, FTP). Но постепенно эта сеть превратилась в средство массовой информации, отличающееся тем, что операторы сети сами могут быть источниками информации и определяют, в свою очередь то, какую информацию они хотят получить.

    Среди первых поисковых систем были archie, gopher и wais. Эти относительно простые системы казались тогда чудом. Использование этих систем показало их недостаточность и определенные врожденные недостатки: ограниченность зоны поиска и отсутствие управления этим процессом. Поиск проводился по ограниченному списку серверов и никогда не было известно, насколько исчерпывающую информацию получил клиент.

    Первые WWW-системы работали в режиме меню (Mosaic появилась несколько позже) и обход дерева поиска производился вручную. Структура гиперсвязей могла иметь циклические пути, как, например, на рис. 4.5.14.1. Число входящих и исходящих гиперсвязей для любого узла дерева может быть произвольным.

    Рис. 4.5.14.1. Пример дерева гиперсвязей

    Связь, помеченная буквой А может явиться причиной образования цикла при обходе дерева. Исключить такие связи невозможно, так как они носят принципиально смысловой характер. По этой причине любая автоматизированная программа обхода дерева связей должна учитывать такую возможность и исключать циклы обхода.

    Задача непроста даже в случае поиска нужного текста в пределах одного достаточно большого по емкости диска, когда вы заранее не знаете или не помните в каком субкаталоге или в каком файле содержится искомый текст. Для облегчения ручного поиска на серверах FTP в начале каждого субкаталога размещается индексный файл.

    Для решения этой задачи в большинстве операционных систем имеются специальные утилиты (например, grep для UNIX). Но даже они требуют достаточно много времени, если, например, дисковое пространство лежит в пределах нескольких гигабайт, а каталог весьма разветвлен. В полнотекстных базах данных для ускорения поиска используется индексация по совокупности слов, составляющих текст. Хотя индексация также является весьма времяемкой процедурой, но производить ее, как правило, приходится только один раз. Проблема здесь заключается в том, что объем индексного файла оказывается сравным (а в некоторых случаях превосходит) с исходным индексируемым файлом. Первоначально каждому документу ставился в соответствие индексный файл, в настоящее время индекс готовится для тематической группы документов или для поисковой системы в целом. Такая схема индексации экономит место в памяти и ускоряет поиск. Для документов очень большого размера может использоваться отдельный индекс, а в поисковой системе иерархический набор индексов. Индексированием называется процесс перевода с естественного языка на информационно-поисковый язык. В частности, под индексированием понимается отнесение документа в зависимости от содержимого к определенной рубрике некоторой классификации. Индексирование можно свести к проблеме распознавания образов. Классификация определяет разбиение пространства предметных областей на непересекающиеся классы. Каждый класс характеризуется набором признаков и специфических для него терминов (ключевых слов), выражающих основные понятия и отношения между ними.

    Слова в любом тексте в информационном отношении весьма неравнозначны. И дело не только в том, что текст содержит много вспомогательных элементов предлогов или артиклей (напр., в англоязычных текстах). Часто для сокращения объема индексных регистров и ускорения самого процесса индексации вводятся так называемые стоп-листы. В эти стоп-листы вносятся слова, которые не несут смысловой нагрузки (например, предлоги или некоторые вводные слова). Но при использовании стоп-листов необходима определенная осторожность. Например, занеся в стоп-лист, неопределенный артикль английского языка "а", можно заблокировать нахождение ссылки на "витамин А".

    Немалое влияние оказывает изменяемость слов из-за склонения или спряжения. Последнее делает необходимым лингвистический разбор текста перед индексацией. Хорошо известно, что смысл слова может меняться в зависимости от контекста, что также усложняет проблему поиска. Практически все современные информационные системы для создания и обновления индексных файлов используют специальные программные средства.

    Существующие поисковые системы успешно работают с HTML-документами, с обычными ASCII-текстами и новостями usenet. Трудности возникают для текстов Winword и даже для текстов Postscript. Связано это с тем, что такие тексты содержат большое количество управляющих символов и текстов. Трудно (практически невозможно) осуществлять поиск для текстов, которые представлены в графической форме. К сожалению, к их числу относятся и математические формулы, которые в HTML имеют формат рисунков (это уже недостаток самого языка). Так что можно без преувеличения сказать, что в этой крайне важной области, имеющей немалые успехи, мы находимся лишь в начале пути. Ведь море информации, уже загруженной в Интернет, требует эффективных средств навигации. Ведь оттого, что информации в сети много, мало толку, если мы не можем быстро найти то, что нужно. И в этом, я полагаю, убедились многие читатели, получив на свой запрос список из нескольких тысяч документов. Во многих случаях это эквивалентно списку нулевой длины, так как заказчик в обоих случая не получает того, что хотел.

    Встроенная в язык HTML метка <meta> создана для предоставления информации о содержании документа для поисковых роботов, броузеров и других приложений. Структура метки: <meta http-equiv=response content=description name=description URL=url>. Параметр http-equiv=response ставит в соответствие элементу заголовок HTTP ответа. Значение параметра http-equiv интерпретируется приложением, обрабатывающим HTML документ. Значение параметра content определяется значением, содержащимся в http-equiv.

    Современная поисковая система содержит в себе несколько подсистем.

    1. web-агенты. Осуществляют поиск серверов, извлекают оттуда документы и передают их системе обработки.
    2. Система обработки. Индексирует полученные документы, используя синтаксический разбор и стоп-листы (где, помимо прочего, содержатся все стандартные операторы и атрибуты HTML).
    3. Система поиска. Воспринимает запрос от системы обслуживания, осуществляет поиск в индексных файлах, формирует список найденных ссылок на документы.
    4. Система обслуживания. Принимает запросы поиска от клиентов, преобразует их, направляет системе поиска, работающей с индексными файлами, возвращает результат поиска клиенту. Система в некоторых случаях может осуществлять поиск в пределах списка найденных ссылок на основе уточняющего запроса клиента (например, recall в системе altavista). Задание системе обслуживания передается WEB-клиентом в виде строки, присоединенной к URL, наример, http://altavista.com/cgi-bin/query?pg=q&what=web&fmt=/&q=plug+%26+play, где в поле поиска было записано plug & play)

    Следует иметь в виду, что работа web-агентов и системы поиска напрямую независимы. WEB-агенты (роботы) работают постоянно, вне зависимости от поступающих запросов. Их задача - выявление новых информационных серверов, новых документов или новых версий уже существующих документов. Под документом здесь подразумевается HTML-, текстовый или nntp-документ. WEB-агенты имеют некоторый базовый список зарегистрированных серверов, с которых начинается просмотр. Этот список постоянно расширяется. При просмотре документов очередного сервера выявляются URL и по ним производится дополнительный поиск. Таким образом, WEB-агенты осуществляют обход дерева ссылок. Каждый новый или обновленный документ передается системе обработки. Роботы могут в качестве побочного продукта выявлять разорванные гиперсвязи, способствовать построению зеркальных серверов.

    Обычно работа роботов приветствуется, ведь благодаря ним сервер может обрести новых клиентов, ради которых и создавался сервер. Но при определенных обстоятельствах может возникнуть желание ограничить неконтролируемый доступ роботов к серверам узла. Одной из причин может быть постоянное обновление информации каких-то серверов, другой причиной может стать то, что для доставки документов используются скрипты CGI. Динамические вариации документа могут привести к бесконечному разрастанию индекса. Для управления роботами имеются разные возможности. Можно закрыть определенные каталоги или сервера с помощью специальной фильтрации по IP-адресам, можно потребовать идентификации с помощью имени и пароля, можно, наконец, спрятать часть сети за Firewall. Но существует другой, достаточно гибкий способ управления поведением роботов. Этот метод предполагает, что робот следует некоторым неформальным правилам поведения. Большинство из этих правил важны для самого робота (например, обхождение так называемых "черных дыр", где он может застрять), часть имеет нейтральный характер (игнорирование каталогов, где лежит информация, имеющая исключительно локальный характер, или страниц, которые находятся в состоянии формирования), некоторые запреты призваны ограничить загрузку локального сервера.

    Когда воспитанный робот заходит в ЭВМ, он проверяет наличие в корневом каталоге файла robots.txt. Обнаружив его, робот копирует этот файл и следует изложенным в нем рекомендациям. Содержимое файла robots.txt в простейшем случае может выглядеть, например, следующим образом.

    # robots.txt for http://store.in.ru

    user-agent: *

    # * соответствует любому имени робота

    disallow: /cgi-bin/

    # не допускает робот в каталог cgi-bin

    disallow: /tmp/

    # не следует индексировать временные файлы

    disallow: /private/

    # не следует заходить в частные каталоги

    Файл содержит обычный текст, который легко редактировать, после символа # следуют комментарии. Допускается две директивы. user-agent: - определяет имя робота, к которому обращены следующие далее инструкции, если не имеется в виду какой-то конкретный робот и инструкции должны выполняться всеми роботами, в поле параметра записывается символ *. disallow - указывает имя каталога, посещение которого роботу запрещено. Нужно учитывать, что не все роботы, как и люди, следуют правилам, и не слишком на это полагаться (см. http://info.webcrawler.com/mak/projects/ robots.html).

    Автор исходного текста может заметно помочь поисковой системе, выбрав умело заголовок и подзаголовок, профессионально пользуясь терминологией и перечислив ключевые слова в подзаголовках. Исследования показали, что автор (а иногда и просто посторонний эксперт) справляется с этой задачей быстрее и лучше, чем вычислительная машина. Но такое пожелание вряд ли станет руководством к действию для всех без исключения авторов. Ведь многие из них, давая своему тексту образный заголовок, рассчитывают (и не без успеха) привлечь к данному тексту внимание читателей. Но машинные системы поиска не воспринимают (во всяком случае, пока) образного языка. Например, в одном лабораторном проекте, разработанном для лексического разбора выражений, состоящих из существительных с определяющим прилагательным, и по своей теме связанных с компьютерной тематикой, система была не способна определить во фразе "иерархическая компьютерная архитектура" то, что прилагательное "иерархическая" относится к слову "архитектура", а не к "компьютерная" (Vickery & Vickery 1992). То есть система была не способна отличать образное использование слова в выражении от его буквального значения.

    В свою очередь специалисты, занятые в области поисковых и информационных систем, способны заметно облегчить работу авторам, снабдив их необходимыми современными тезаурусами, где перечисляются нормативные значения базовых терминов в той или иной научно-технической области, а также устойчивых словосочетаний. Параллельно могут быть решены проблемы синонимов.

    В настоящее время, несмотря на впечатляющий прогресс в области вычислительной техники, степень соответствия документа определенным критериям запроса надежнее всего может определить человек. Но темп появления электронных документов в сети достигает ошеломляющего уровня (частично это связано с преобразованием в электронную форму старых документов и книг методом сканирования). Написание рефератов для последующего их использование поисковыми системами достаточно изнурительное занятие, требующее к тому же достаточно высокой профессиональной подготовки. Именно по этой причине уже достаточно давно предпринимаются попытки перепоручить этот процесс ЭВМ. Для этого нужно выработать критерии оценки важности отдельных слов и фраз, составляющих текст. Оценку значимости предложений выработал Г.Лун. Он предложил оценивать предложения текста в соответствии с параметром: Vпр = , где Vпр - значимость предложения; Nзс - число значимых слов в предложении; а Nc - полное число слов в предложении. Используя этот критерий, из любого документа можно отобрать некоторое число предложений. Понятно, что они не будут составлять членораздельного текста. Нужно учитывать также, что "значимые слова" должны браться из тематического тезауруса или отбираться экспертом. По той причине методика может лишь помочь человеку, а не заменить его (во всяком случае, на современном этапе развития вычислительной техники).

    Автоматическая система выявления ключевых слов обычно использует статистический частотный анализ (методика В. Пурто). Пусть f - частота, с которой встречаются различные слова в тексте, а u - относительное значение полезности (важности).

    Тогда зависимость f(u) апроксимируется формулой , то есть произведение частоты встречи слов и их полезности является константой. В теории автоматического анализа документов данная гипотеза используется для вывода следствия о существовании двух пороговых значений частот. Слова с частотой менее нижнего порога считаются слишком редкими, а с частотой, превосходящей верхний порог, - общими, не несущими смысловой нагрузки. Слова с частотой, находящейся посередине между данными порогами, в наибольшей степени характеризуют содержимое данного конкретного документа [Г. Лун; 2 (cм. также http://www.medialingvo.ru)]. К сожалению, выбор порогов процедура достаточно субъективная. Ключевые слова, выявляемые программно, аранжируются согласно частоте их использования. Замечено, что определенное значение имеет не только частота применения слова в конкретном документе, но и число документов, в которых это слово встречается. В работах Спарка Джонса экспериментально показано, что если N - число документов и n - число документов, в которых встречается данный индексный термин (ключевое слово), то вычисление его веса по формуле: приводит к более эффективным результатам поиска, чем вообще без использования оценки значимости индексного термина.

    Одним из известных путей облегчения процедуры поиска является группирование документов по определенной достаточно узкой тематике в кластеры. В этом случае запрос с ключевым словом, фигурирующем в заголовке кластера, приведет к тому, что все документы кластера будут включены в список найденных. Кластерный метод наряду с очевидными преимуществами (прежде всего заметное ускорение поиска) имеет столь же явные недостатки. Документы, сгруппированные по одному признаку, могут быть случайно включены в перечень документов, отвечающих запросу, по той причине, что одно из ключевых слов кластера соответствует запросу. В результате в перечне найденных документов вы можете с удивлением обнаружить тексты, не имеющие никакого отношения к интересующей вас теме.

    Некоторые поисковые системы предоставляют возможность нахождения документов, где определенные ключевые слова находятся на определенном расстоянии друг от друга (proximity search).

    Наиболее эффективным инструментом при поиске можно считать возможность использования в запросе булевых логических операторов AND, OR и NOT. Объединение ключевых слов с помощью логических операторов может сузить или расширить зону поиска.

    Проблема соответствия (релевантности) документа определенному запросу совсем не проста.

    Индексные файлы, содержащие информацию о WEB-сайтах, занимают около 200 Гигабайт дискового пространства, поиск по содержимому которых производится за время, меньшее одной секунды (на самом деле, реальный поиск производится в более чем в десять раз меньшем объеме). Такой объем содержащейся информации делает Altavista неоценимым помощником в поиске нужных документов и серьезным конкурентом для остальных компаний, содержащих поисковые серверы. Поисковая система Altavista работает на самых мощных компьютерах, произведенных компанией Digital Equipment Corporation - это 16 серверов Alphaserver 8400 5/440, объединенных в сетевой кластер. Каждый из серверов имеет 8 Гбайт оперативной памяти (может иметь до 28 Гбайт), содержит 12 (до 14) процессоров Digital Alfa с тактовой частотой 437 МГц, в качестве жестких дисков используются высокоскоростные и надежные дисковые системы RAID с общим объемом 300 Гбайт. Для обеспечения связи с Интернет используются каналы с суммарной пропускной способностью 100 Мбит/с через шлюз DEC Palo Alto - что является самым мощным корпоративным шлюзом в Интернет.

    Пример широко известной поисковой системы alta vista, где задействовано большое число суперЭВМ, показывает, что дальнейшее движение по такому пути вряд ли можно считать разумным, хотя прогресс в вычислительной технике может и опровергнуть это утверждение. Тем не менее, даже в случае фантастических достижений в области создания еще более мощных ЭВМ, можно утверждать, что распределенные поисковые системы могут оказаться эффективнее. Во-первых, местный администратор быстрее может найти общий язык с авторами текстов, которые могут точнее выбрать набор ключевых слов. Во-вторых, распределенная система способна распараллелить обработку одного и того же информационного запроса. Распределенная система памяти и процессоров может, в конце концов, стать более адекватной потокам запросов к информации, содержащейся на том или ином сервере. Способствовать этому может также создание тематических серверов поиска, где концентрируется информация по относительно узкой области знаний. Для таких серверов возможен отбор документов экспертами, они же могут определить списки ключевых слов для многих документов. Здесь возможна автоматическая предварительная процедура фильтрации документов по наличию определенного набора ключевых слов. Способствует этому и существование тематических журналов, где сконцентрированы статьи по определенной тематике.

    В случаях, когда поисковая система выдает заказчику большой список документов, отвечающих критериям его запроса, бывает важно, чтобы они были упорядочены согласно их степени соответствия (наличие ключевых слов в заголовке, большая частота использования ключевых слов в тексте документа и т.д.). Но простые критерии здесь не всегда срабатывают, так объемный документ имеет больше шансов попасть в список результата поиска, так как в нем много слов и с большой вероятностью там встречается ключевое слово. По этому критерию Британская энциклопедия должна попасть в результирующий список любого запроса. Для компенсации искажений, вносимых длиной документов, используется нормализация весов индексных терминов.

    Нормализация представляет собой способ уменьшения абсолютного значения веса индексных терминов, обнаруженных в документе. Одним из наиболее распространенных методов, решающих данную проблему, является косинусная нормализация. При использовании этого метода нормализации вес каждого индексного термина делится на Евклидову длину вектора оцениваемого документа. Евклидова длина вектора определяется формулой: - вес i-того термина в документе, tf - (term frequency), частота, с которой встречается данный индексный термин; IDF (Inverted Document Frequency) - величина, обратная частоте, с которой данный термин встречается во всей совокупности документов. Окончательная формула для вычисления веса термина (w) в документе с учетом косинусного фактора нормализации представляется формулой: . Термины, которые отсутствуют в тексте документа, имеют нулевой вес. В списке, возвращаемом на запрос, документы перечисляются в порядке уменьшения данного численного значения.

    В работах Букштейна, Свенсона и Хартера было показано, что распределение функциональных слов в отличие от специфических слов с хорошей точностью описывается распределением Пуассона. То есть, если ищется распределение функционального слова w в некотором множестве документов, тогда вероятность f(n) того, что слово w будет встречено в тексте n раз представляется функцией: - распределение Пуассона. Значение параметра x варьируется от слова к слову, и для конкретного слова должно быть пропорционально длине текста. Слова, распределенные в совокупности документов согласно Пуассону, полезной информации не несут.

    Для представления документов используется векторная модель, где любой документ характеризуется бинарным вектором x = x 1,x2,., xn, где значения xi = 0 или 1, в зависимости от того, присутствует в тексте i-ый индексный термин или нет. Рассматриваются два взаимно исключающих события:

    w1 - документ удовлетворяет запросу
    w2 - документ удовлетворяет запросу

    Для каждого документа необходимо вычислить условные вероятности P(w1|x) и P(w2|x) для определения, какие документы удовлетворяют запросу, а какие нет.

    Непосредственно получить значения этих вероятностей нельзя, поэтому необходимо найти другой альтернативный подход для их определения с помощью известных нам величин. По формуле Байеса для дискретного распределения условных вероятностей: .

    В приведенной формуле P(w1) - первоначальная вероятность соответствия (i = 1) или несоответствия (i = 2) запросу, величина P(x|wi) пропорциональна вероятности соответствия или несоответствия запросу для данного x; в недискретном случае она представляет собой функцию плотности распределения и обозначается как P(x|wi).

    Окончательно: , что представляет собой вероятность получения документа x в ответ на запрос при условии, что он будет ему соответствовать или нет. P(x) выступает в качестве нормализующего фактора (т.е. с его помощью достигается выполнение условия ).

    Для определения релевантности документа используется вполне очевидное правило:

    Если , то документ удовлетворяет запросу [1].

    В противном случае считается, что документ не удовлетворяет запросу. При равенстве значений вероятности решение о релевантности документа принимается произвольно.

    Правило [1] основано на том, что при его использовании просто минимизируется средняя вероятность ошибки принятия нерелевантного документа за релевантный и наоборот. То есть, для любого документа x вероятность ошибки равна:

    Таким образом, для минимизации средней вероятности ошибки необходимо минимизировать функцию .

    Не углубляясь в теорию вероятностного нахождения релевантных документов, укажем еще одно правило, которое можно использовать вместо [1]:

    . [2]

    В формуле [2] коэффициенты lij стоимостной функции определяют потери, вносимые при ожидании события wi , когда на самом деле произошло событие wj .

    Для практической реализации вероятностного поиска вводится упрощающее предположение относительно P(x|wi). Принимается, что значения xi вектора x являются статистически независимыми. Данное утверждение математически представляется в виде: .

    Определим переменные: и , представляющие собой вероятность того, что в документе присутствует i-ый индексный термин при условии, что документ является релевантным (нерелевантным). Соответствующая вероятность для отсутствия индексных терминов имеет вид .

    Вероятностные функции, используемые для подстановки в правило [1] имеют вид:

    и

    .

    Подставляя значения в [2] и логарифмируя, получаем:

    , где

    и .

    Функция G(x) представляет собой ничто иное, как весовую функцию, в которой коэффициенты Сi представляют собой веса присутствующих в документе индексных терминов. Константа С одинакова для всех документов x, но, конечно, различна для разных запросов и может рассматриваться в качестве порогового значения для поисковой функции. Единственными параметрами, которые могут меняться для данного запроса являются параметры стоимостной функции, вариации которых позволяют получать в ответе большее или меньшее число документов.

    Теперь рассмотрим коэффициенты Сi функции G(x) с использованием следующей терминологии:

    Таблица 4.5.14.1.

     

    Релевантные документы

    Нерелевантные документы

    Общее количество документов

    Всего

    N - полное число документов в системе.
    R - число релевантных документов
    r - число релевантных документов, выданных в ответ на запрос
    n - полное число документов, выданных в ответ на запрос

    Таблица представляет результаты запроса, направленного системе поиска. Представленная таблица должна существовать для каждого из индексных терминов.

    Если мы обладаем всей информацией о релевантных и нерелевантных документах в коллекции документов, то применимы следующие оценки: и . Тогда функция g(x) может быть переписана в виде .

    Коэффициент при xi показывает, до какой степени можно провести дискриминацию по i-тому термину в рассматриваемой коллекции документов. В действительности, N может рассматриваться не только как полное количество документов во всей коллекции, но и в некотором ее подмножестве.

    Все приведенные формулы были выведены при условии, что индексные термины являются статистически независимыми. В общем случае это, конечно, не так. В теории вероятностного поиска моделируется зависимость между различными индексными формулами, в связи с чем, вид функции G(x) несколько меняется.

    Многие системы поиска информации основаны на словарях и тезаурусах для корректировки запросов и представления индексируемых документов, чтобы увеличить шансы найти необходимый документ. На практике, большинство словарей составляется вручную. Словари создаются с помощью одного из двух основных способов:

    1. Связываются слова, описывающие одну и ту же тему.
    2. Связываются слова, описывающие похожие темы.

    В первом случае связываются слова, являющиеся взаимозаменяемыми, то есть, в словарях и тезаурусах они принадлежат одному и тому же классу. То есть, можно выбрать по одному слову из каждого класса и совокупность выбранных слов может быть использована для создания контролируемого словаря. Выбирая слова из созданного контролируемого словаря можно проводить индексацию документов или создавать поисковые запросы.

    Во втором случае для создания тезауруса используются семантические связи между словами для построения, например, иерархической структуры связей. Создание такого типа словарей является достаточно сложным и трудоемким процессом.

    Однако, были предложены способы и для автоматического создания словарей. В то время как созданные вручную словари опираются на семантику (т.е. распознают синонимы, являются более обширными, используют более тонкие взаимосвязи), автоматически созданные тезаурусы, в основном, основаны на синтаксическом и статистическом анализе. Но, так как, использование синтаксиса не приводит к серьезному увеличению эффективности работы систем, то значительно большее внимание уделяется статистическим методам.

    Основное допущение, используемое для автоматического создания классов ключевых слов, заключается в следующем. Если ключевые слова a и b могут быть взаимозаменяемы в том смысле, что мы готовы принять документ, содержащий ключевое слово b вместо ключевого слова a и наоборот, то данное обстоятельство имеет место из-за того, что слова a и b имеют одинаковое значение или ссылаются на одинаковые темы.

    Основываясь на описанном принципе нетрудно видеть, что создание классификации слов может быть автоматизировано. Можно определить два основных приближения для использования классификации ключевых слов:

    1. Производить замену каждого из ключевых слов, встречающегося в представлении документа или запроса, названием класса, которому оно принадлежит.
    2. Заменять каждое из встреченных ключевых слов всеми словами, входящими в класс, которому принадлежит рассматриваемое ключевое слово.

    Для простейшей поисковой стратегии, использующей только что описанные дескрипторы, независимо от того, являются ли они ключевыми словами или названиями классов, созданных на основе группы ключевых слов, "расширенное" представление документов и запросов с помощью любого из вышеописанных способов может существенно повысить число соответствий между документами и запросами и, следовательно, увеличить значение параметра recall. Правда, последнее обстоятельство не является определяющим, так как значение имеет только совокупность параметров (recall, precision), а одно лишь увеличение параметра recall может привести лишь к увеличению объема выдаваемых в ответ на запрос различных документов.

    В отчетах об экспериментальных работах по использованию автоматической классификации ключевых слов, проведенных уже упоминавшимся ранее Спарком Джонсом, сообщается, что использование автоматической классификации приводит к увеличению эффективности работы системы по сравнению с системой, использующей неклассифицированные ключевые слова.

    Работа Минкера и др. не подтвердила выводы Спарка Джонса и, фактически, показала, что в некоторых случаях использование классификации ключевых слов приводит к существенному ухудшению работы системы в целом. Д. Сальтон в своем отзыве о работе Минкера определил, что целесообразность использования классификации ключевых слов для улучшения эффективности работы поисковых систем еще полностью не определена и является объектом дальнейших экспериментальных исследований. Действительно, при работе в Интернет с поисковыми системами, использующими классификацию ключевых слов, (такими как lycos и excite) заметно существенное увеличение документов, не представляющих ничего общего с запросом, но, тем не менее, имеющих довольно высокий ранг и, следовательно, по мнению поисковой системы, наиболее точно соответствующих заданному запросу.

    Для дальнейшего увеличения эффективности системы используется так называемая кластеризация документов.

    Существуют две основные области применения методов классификации в системах поиска и локализации информации. Это - кластеризация (классификация) ключевых слов и кластеризация документов.

    Под кластеризацией документов понимается создание групп документов, таких, что документы, принадлежащие одной группе, оказываются, в некоторой степени, связанными друг с другом. Другими словами, документы принадлежат одной группе потому, что ожидается, что эти документы будут находиться вместе в результате обработки запроса. Логическая организация документов достигается, в основном, двумя следующими способами.

    Первый - путем непосредственной классификации документов и второй - посредством промежуточного вычисления некоторой величины соответствия между различными документами.

    Было теоретически доказано, что первый метод является очень сложным для практической реализации, так что любые экспериментальные результаты не могут считаться достаточно надежными. Второй способ классификации заслуживает подробного внимания, и, по сути, является единственным реальным подходом к решению проблемы.

    На практике почти невозможно сопоставить каждый из документов каждому из запросов из-за слишком больших затрат машинного времени на проведение таких операций. Было предложено много различных способов для уменьшения количества необходимых для выполнения запроса операций сравнения. Наиболее многообещающим было предложение использовать группы взаимосвязанных документов, используя процедуры автоматического определения соответствия документов. Проводя сравнения запроса всего лишь с одним документом, являющимся представителем группы (заранее определенным) и, таким образом, определяя группу документов, в которой и происходит дальнейший поиск, существенно уменьшается затрачиваемое на обработку запроса машинное время. Однако, Дж. Сальтон полагал, что, хотя использование кластеризации документов и уменьшает время поиска, но неизбежно снижает эффективность поисковой системы. Точка зрения других исследователей несколько отличается от мнения Дж. Сальтона, так, в работе Jardine, N. и Van Rijsbergen, c.j., "The Use of Hierarchic Clustering in Information Retrieval", Information Storage and Retrieval, 7, 217-240 (1971) делаются выводы о достаточно высоком потенциале методов кластеризации для увеличения эффективности работы поисковых систем.

    Для построения систем поиска информации с использованием кластеров необходимо использовать методы для определения степени взаимосвязи между объектами. На основе определенных взаимосвязей можно построить систему кластеров. Взаимосвязь между документами определяется понятиями "степень сходства", "степень различия" и "степень соответствия". Значение степени сходства и степени соответствия между документами увеличивается по мере увеличения количества совпадающих параметров. В рассмотрении могут участвовать совершенно разные параметры. Некоторыми исследователями отмечалось, что различие в производительности поисковых систем при использовании различных способов определения степени ассоциации является несущественным, при условии, что функции, используемые для ее определения, являются соответствующим образом нормализованными. Интуитивно, такой вывод можно понять, так как большинство методов определения взаимосвязи между документами используют одни и те же параметры (использующие, в большинстве, статистический анализ текстовых документов). Данное предположение подтверждается в работах И. Лермана, где показано, что многие из способов определения степени соответствия являются монотонными по отношению друг к другу.

    В теории поиска информации используется пять основных способов определения степени соответствия. Документы и запросы представляются, в основном, с помощью индексных терминов или ключевых слов, поэтому для облегчения описания моделей обозначим посредством размер множества ключевых слов, представляющих рассматриваемый документ или запрос.

    Самая простая из моделей для определения степени соответствия - это так называемый простой коэффициент соответствия: , показывающий количество общих индексных терминов. При вычислении коэффициента не берутся в рассмотрение размеры множеств X и Y.

    В следующей таблице показаны другие подходы к определению степени соответствия, использующие коэффициенты, учитывающие размеры множеств и .

    Таблица 4.5.14.2

    Коэффициент

    Название

    Коэффициент Дайса (dice)

    Коэффициент Джаккарда (jaccard)

    Косинусный коэффициент

    Коэффициент перекрытия

    Приведенные коэффициенты, по сути, представляют собой нормализованные варианты простого коэффициента соответствия.

    Скажем несколько слов о функциях, определяющих степень различия между документами. Причины использования в системах поиска информации функций, определяющих степень различия между документами, вместо степени соответствия являются чисто техническими. Добавим, что любая функция оценки степени различия между документами d может быть преобразована в функцию, определяющую степень соответствия s следующим образом: . Надо сказать, что обратное утверждение, вообще говоря, не верно.

    Если P - множество объектов, предназначенных для кластеризации, то функция D определения степени различия документов - это функция, ставящая в соответствие неотрицательное рациональное число. Функция определения степени различия d удовлетворяет следующим условиям:

    Четвертое свойство неявно отображает тот факт, что функция определения степени различия между документами является, в некоторой степени, функцией, определяющей "расстояние" между двумя объектами и, следовательно, логично предположить, что должна удовлетворять неравенству треугольника. Данное свойство выполняется практически для всех функций определения степени различия.

    Пример функции, удовлетворяющей свойствам 1 - 4: , где представляет собой разность множеств x и y. Она связана, например, с коэффициентами Дайса соотношением .

    Наконец, представим функцию определения степени различия в альтернативной форме: , где суммирование производится по всем различным индексным терминам, входящим в коллекцию документов.

    Используя векторное представление документов, для двух векторов для косинусного коэффициента соответствия

    получаем следующую формулу: .

    Скажем несколько слов о вероятностном подходе для функций, определяющих степень соответствия. Степень соответствия между объектами определяется по тому, насколько их распределения вероятности отличаются от статистически независимого. Для определения степени соответствия используется ожидаемая взаимная мера информации. Для двух дискретных распределений вероятности она может быть определена как:

    .

    Если xi и xj - независимы, тогда и ). Дополнительно выполняется условие, что , показывающее, что функция является симметричной.

    Функция интерпретируется как статистическая мера информации, содержащейся в документе о документе (и наоборот). Когда данная функция применяется для определения степени связи между двумя индексными терминами, например, i и j, тогда xi и xj являются бинарными переменными. Таким образом, является вероятностью присутствия индексного термина i и, соответственно P(xi=0) является вероятностью его отсутствия.

    Та степень взаимосвязи, которая существует между индексными терминами i и j вычисляется затем функцией , показывающей степень отклонения их распределений от статистически независимого.

    Были предложены и другие функции, похожие на описанную выше функцию для определения степени соответствия (см. Jardine, N. and Sibson, R., Mathematical Taxonomy, Wiley, London and New York (1971)) между парами документов.

    Как и в случае автоматической классификации документов, использование вероятностных методов при формировании кластеров содержит в себе достаточно высокий потенциал и представляет крайне интересную область для исследований.

    Итак, для формирования кластеров необходимо использовать некую функцию соответствия для определения степени связи между парами документов из коллекции.

    Постулируем теперь основную идею, на которой, собственно говоря, и построена вся теория кластерного представления коллекции документов. Гипотеза, приведшая к появлению кластерных методов, называется Гипотезой Кластеров и может быть сформулирована следующим образом: "Связанные между собой документы имеют тенденцию быть релевантными одним и тем же запросам".

    Базисом, на котором построены все системы автоматического поиска информации, является то, что документы, релевантные запросу, отличаются от нерелевантных документов. Гипотеза кластеров указывает на целесообразность разделения документов на группы до обработки поисковых запросов. Естественно, она ничего не говорит о том, каким образом должно проводиться это разделение.

    Проводился ряд исследований по поводу применения кластерных методов в поисковых системах. Некоторые отчеты приведены в работах Б. Литофски, Д. Крауча, Н. Привеса и Д. Смита, а также М. Фритше.

    Кластерные методы, выбираемые для использования в экспериментальных поисковых системах должны удовлетворять некоторым определенным требованиям. Это:

    • методы, создающие кластеры, не должны существенно их изменять при добавлении новых объектов. То есть, должны быть устойчивы по отношению к объему коллекции.
    • методы должны быть устойчивы и в том отношении, что небольшие ошибки в описании объектов приводят к небольшим изменениям результата процесса кластеризации.
    • результат, производимый методами кластеризации, должен быть независимым от начального порядка объектов.

    Основной вывод из вышесказанного состоит в том, что любой кластерный метод, не удовлетворяющий приведенным условиям, не может производить сколько-нибудь значащие экспериментальные результаты. Надо сказать что, к сожалению, далеко не все работающие кластерные методы удовлетворяют приведенным требованиям. В основном, это происходит из-за значительных различий между реализованными методами кластеризации от теоретически разработанных ад-хок алгоритмов.

    Другим критерием выбора является эффективность процесса создания кластеров с точки зрения производительности и требований к объему необходимого дискового пространства.

    Необходимость учета данного критерия находится, естественно, в сильной зависимости от конкретных условий и требований.

    Возможно, использование процедур фильтрации базы данных таким образом, что из базы данных будет удаляться информация об индексных терминах, встречающихся в более чем, скажем 80% проиндексированных документов. Таким образом, список стоп-слов будет динамически изменяющимся. Как уже говорилось, использование списка стоп-слов может приводить к 30% уменьшению размеров индексных файлов. Для построения кластеров обычно используется два основных подхода:

    • кластеризация основывается на вычислении степени соответствия между подвергающимися кластеризации объектами.
    • кластерные методы применяются не к объектам непосредственно, а к их описаниям.

    В первом случае кластеры можно представить с помощью графов, построенных с учетом значений функции соответствия для каждой пары документов.

    Рассмотрим некоторое множество объектов, которые должны быть кластеризованы. Для каждой пары объектов из данного множества вычисляется значение функции соответствия, показывающее насколько эти объекты сходны.

    Если полученное значение оказывается больше величины заранее определенного порогового значения, то объекты считаются связанными. Вычислив значения функции соответствия для каждой пары объектов, строится граф, по сути, представляющий собой кластер. То есть определение кластера строится в терминах графического представления.

    Список литературы

    1

    Salton, G., "Automatic Text Analysis", Science, 168, 335-343 (1970)

    2

    Luhn, H. P. "The automatic creation of literature abstracts", IBM Journal of Research and Development, 2, 159-165 (1958)

    3

    Gerard Salton, Chris Buckley and Edward A. Fox, "Automatic Query Formulations in Information Retrieval", Cornell University, http://cs-tr.cs.cornell.edu/

    4

    Tandem Computers Inc. "Three Query Parsers", http://oss2.tandem.com /search97/doc/srchscr/tpappc1.htm

    5

    Object Design Inc., "Persistent Storage Engine PSE-Pro documentation", http://www.odi.com/

    6

    Roger Whitney, "CS 660: Combinatorial Algorithms. Splay Tree", San Diego State University. http://saturn.sdsu.edu:8080/~whitney/

    Previous: 4.5.13 Система поиска файлов Archie    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.15 Диалог в локальных сетях и в Интернет


    previous up down next index index
    Previous: 4.5.14 Современные поисковые системы    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.16 Некоторые другие процедуры Интернет

    4.5.15 Диалог в локальных сетях и в Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Команды Talk (для SUN), Phone (для VAX/VMS) и другие служат для переговоров двух человек, работающих на одной и той же ЭВМ с удаленных терминалов в реальном масштабе времени. Хотя эти команды и не используют протоколы TCP/IP, они весьма удобны при работе, в частности при отладке новых телекоммуникационных каналов. Вызов осуществляется в соответствии с форматами: Talk bobyshev@ns.itep.ru или Phone <ID>, где <ID> - имя партнера (его ID, используемое при входе в ЭВМ), с которым вы хотите поговорить. При использовании этих процедур экран делится на две части по вертикали, верхняя часть предназначена для печати текста вызывающего, нижняя часть для его партнера.

    Существует версия и Internet-Phone, которая обеспечивает голосовую двухстороннюю связь между пользователями сети. Этот вид услуг примыкает скорее к разновидностям сервиса, описанным в следующей главе. Для обеспечения работы такого канала связи достаточно ЭВМ PC-486SX с частотой 25МГц, памятью 8Мбайт и стандартной аудио-картой. Программы, поддерживающие этот вид сервиса, работают в рамках Windows, Winsock 1.1. При этом вы займете полосу канала шириной 7.7Кбит/c. При установке звуковой VC-платы c сжатием аудио-информации можно ограничить требования на полосу до уровня 6.72Кбит/c. Следует ожидать появления программ и на других платформах и в других средах. Общедоступное программное обеспечение для работы с аудио-версией Phone можно получить через анонимное FTP по адресу ftp.volcaltec.com (используйте ID-пользователя=ftp). Разговаривать можно только с одним партнером одновременно. Возможно совмещение разговора с другими процедурами Internet, что особенно привлекательно при диагностике и отладке каналов и сетевых программ. Internet-Phone контактирует с IRC (Internet Relay Chat, смотри подробнее в следующей главе), что позволяет получить необходимую справочную информацию. Используя возможности IRC, можно выбрать мышкой нужного вам партнера и начать беседовать с ним, если он конечно сидит у ЭВМ, которая оснащена необходимым аппаратным и программным обеспечением. В рамках этого вида сервиса вы можете обсудить какой-то документ, отображенный на экране терминалов, отмечая нужные места с помощью манипуляторов мышь. Это дает возможность согласовать в реальном масштабе времени текст документа, обсудить элементы конструкции или схемы, не тратя деньги на командировку или на дорогостоящее оборудование для видеоконференций. Бесплатно поболтать с вашим приятелем в Рио-де-Жанейро - это ли не мечта многих россиян?

    Если же специального оборудования в вашем распоряжении нет, можно воспользоваться текстовой версией Talk или Phone. Обращение к Talk имеет форму:

    talk имя_пользователя [ ttyname ]

    Если вы хотите поговорить с кем-то на вашей ЭВМ, достаточно в качестве параметра ввести имя_пользователя (login ID). Если же ваш партнер работает на другой машине, имя адресата может иметь вид: host!пользователь или host.пользователь, или host:пользователь, или пользователь@host, где host - это имя ЭВМ, на которой работает ваш партнер. Последняя форма используется чаще. При необходимости переговорить с человеком, работающем на определенном терминале, следует ввести имя этого терминала (ttyname). При получении запроса Talk выдает на экран следующее сообщение:

    Message from TalkDaemon@his_machineattime...
    talk: connection requested by ваше_имя@ваша_ЭВМ.
    talk: respond with: talk ваше_имя@ваша_ЭВМ

    Пользователь, желающий участвовать в диалоге, должен ответить:

    talk ваше_имя@ваша_ЭВМ

    Когда связь установлена, оба участника диалога могут печатать текст одновременно с отображением обоих текстов в верхней и нижней частях экрана. Нажатие комбинации СTRL-L переписывает заново содержание экрана. Для завершения диалога следует нажать CTRL-Y. Имя ЭВМ адресата можно найти в файле /etc/hosts, а имя терминала в файле /etc/utmp. В процессе общения с использованием терминала возникает проблема - "пальцы не поспевают за мыслью". Традиция англоязычного общения выработала некоторые общепринятые сокращения часто используемых слов и выражений, которые могут облегчить диалог:

    Таблица 4.5.15.1. Общепринятые сокращения, используемые при диалоге

    Общепринятое сокращение выражения

    Выражение

    Перевод

    BCNU

    be seeing you

    пока

    BRB

    be right back

    возвращайся вовремя

    BTW

    by the way

    кстати

    BYE

    goodbye

    до свидания, я готов закончить диалог

    BYE?

    Goodbye?

    вы готовы завершить диалог?

    CU

    see you

    пока

    CUL

    see you later

    увидимся

    FYI

    for your information

    для вашего сведения

    FWIW

    for what it's worth

    за чем это нужно

    GA

    go ahead and type

    давай, продолжай

    IMHO

    in my humble opinion

    по моему скромному мнению

    IMO

    in my opinion

    по моему мнению

    JAM

    just a minute

    минутку

    O

    over

    ваша очередь говорить

    OO

    over and out

    до свидания

    OBTW

    oh, by the way

    а кстати

    ROTFL

    rolling on the floor laughing

    кататься по полу от смеха

    R U THERE?

    are you there?

    вы там?

    SEC..

    wait a second

    подождите секунду

    WRT

    with respect to

    с уважением

    IRC
    Семенов Ю.А. (ГНЦ ИТЭФ)

    IRC - (Internet Relay Chat, RFC-1459) представляет собой систему переговоров в реальном времени. Она аналогична команде talk, которая используется на многих ЭВМ в Интернет. IRC делает все, что может talk, но позволяет также переговариваться более чем двум лицам одновременно. IRC предоставляет и много других удобных услуг.

    Когда вы печатаете текст в IRC, все что вы напечатали будет немедленно передано другим пользователям, кто подключен к разговору. Причем они при желании могут вам ответить в реальном масштабе времени. Темы обсуждений в IRC варьируются в широких пределах. Обычно разговор идет по-английски, но существуют каналы для немецкого, японского, финского и других языков (русский язык здесь не является исключением, какой-же русский откажет себе в удовольствии поболтать, особенно в рабочее время). Клиенты и серверы для IRC доступны через анонимное FTP по адресу: cs.bu.edu. Некоторые узлы позволяют доступ к IRC через telnet, например, wbrt.wb.psu.edu и irc.demon.co.uk. В обоих узлах вход в систему осуществляется (login) как IRC.

    В таблице 4.5.15.2 приведены основные команды IRC.

    Таблица 4.5.15.2. Основные команды IRC

    Команда IRC

    Описание

    /a

    Отбрасывание оставшегося выхода для текущей команды

    /help

    Отобразить список IRC-команд

    /help команда

    Выдает описание команды

    /help intro

    Отображает введение в IRC

    /help newuser

    Отображает информацию о новых пользователях

    /join канал

    Подключиться к соответствующему каналу

    /leave канал

    Покинуть соответствующий канал

    /list

    Выдать информацию о всех каналах.

    /list канал

    Отобразить информацию о конкретном канале

    /list -min n

    Отобразить каналы, которые имеют как минимум n человек

    /list -max n

    Отобразить каналы, в которых не более n человек

    /me операция

    Отобразить определенную операцию

    /mode * +p

    Делает текущий канал личным

    /msg псевдоним текст

    Посылка частного сообщения указанному человеку

    /msg , текст

    Посылка сообщения последнему корреспонденту, кто вам что-то прислал

    /msg . текст

    Посылка сообщения последнему корреспонденту

    /nick

    Отобразить ваш псевдоним

    /nick псевдоним

    Изменить ваш псевдоним

    /query псевдонимы

    Послать все ваши сообщения указанным лицам

    /query

    Прекратить посылку частных сообщений

    /quit

    Прервать работу IRC (quit).

    /set novice off

    Позволить некоторые операции, например, подключение ко многим каналам

    /who канал

    Определяет, кто подключен к определенному каналу

    /who псевдоним

    Выдает информацию о конкретном человеке

    /who *

    Определяет, кто подключен к каналу

    /whois псевдоним

    Выдает всю информацию об определенном человеке

    /whois *

    Выдает всю информацию о всех

    Многие серверы системы IRC для соединения друг с другом используют древовидную схему. Некоторые серверы, взаимодействуя друг с другом, передают информацию о существовании других серверов, пользователей или других ресурсов. Фундаментальной для IRC является концепция канала. Все пользователи, когда они в системе IRC, находятся на одном канале. Сначала вы входите в нулевой канал. Вы не можете послать сообщение, пока вы не вошли в канал и не задали параметры этого канала. Число каналов не ограничено.

    Когда вы находитесь в системе IRC и нуждаетесь в помощи, выдайте команду /help. При возникновении проблем можно контактировать с Кристофером Девисом (Christopher Davis, ckd@eff.org) или с Еленой Роуз (Helen Rose, hrose@eff.org). Можно запросить помощь у оператора каналов IRC, например, #twilight_zone и #eu-opers. Различные документы по IRC и архивы списков рассылки IRC доступны через анонимное FTP по адресу ftp.kei.com, cs.bu.edu irc/support/alt-irc-faq или dorm.rutgers.edu pub/Internet.documents/irc.basic.guide. Группа новостей:

    alt.irc, alt.irc.recovery. Имеется возможность доступа к материалам по IRC и через WWW: www.kei.com irc.html; eru.dd.chalmers.se home/f88jl/Irc; mistral.enst.fr ~pioch/IRC; alpha.acast.nova.edu IRC; www.infosystems.com cgi-bin/www2irc.

    RELAY

    RELAY представляет собой систему серверов в глобальной сети Bitnet/EARN, которая ретранслирует интерактивные сообщения от одного пользователя к другим, кто подписан на данный "канал" системы RELAY. Пользователь, подписанный на ближайший RELAY, виртуально подписан на всю систему RELAY. Большинство узлов RELAY отключаются в часы пик. Только некоторые из них работают 24 часа в сутки. Каждый RELAY-сервер обслуживает ограниченное число узлов, называемых сферой обслуживания. RELAY - это программа, которая позволяет нескольким людям общаться через сеть в реальном масштабе времени. Для того чтобы начать, вы должны подписаться на RELAY, для чего поместить ваш ID в текущий список пользователей. Взаимодействие с RELAY осуществляется также, как с обычным пользователем. Команды RELAY начинаются с символа /, все что не начинается с / считается сообщением и пересылается всем текущим пользователям.

    RELAY доступна по следующим адресам EARN/Bitnet. В скобках приведено условное имя RELAY-ЭВМ.

    RELAY@AUVM (Wash_DC)

    RELAY@PURCCVM (Purdue)

    RELAY@BEARN (Belgium)

    RELAY@SEARN (Stockholm)

    RELAY@ITESMVF1 (Mexico)

    RELAY@TAUNIVM (Israel)

    RELAY@CEARN (Geneva)

    RELAY@TECMTYVM (Monterrey)

    RELAY@CZHRZU1A (Zurich)

    MASRELAY@UBVM (Buffalo)

    RELAY@DEARN (Germany)

    RELAY@UFRJ (RioJaneiro)

    RELAY@DKTC11 (Copenhagen)

    RELAY@UIUCVMD (Urbana_IL)

    RELAY@FINHUTC (Finland)

    RELAY@USCVM (LosAngeles)

    RELAY@GITVM1 (Atlanta)

    RELAY@UTCVM (Tennessee)

    RELAY@GREARN (Hellas)

    RELAY@UWAVM (Seattle)

    RELAY@HEARN (Holland)

    RELAY@VILLVM (Philadelph)

    RELAY@JPNSUT00 (Tokyo)

    RELAY@YALEVM (Yele)

    RELAY@NDSUVM1 (No_Dakota)

    RELAY@WATDCS (Waterloo)

    Система RELAY доступна пользователям сетей EARN/Bitnet через интерактивный обмен (SEND-команда в VMS/JNET, или PHONE в VAX/VMS). Все ЭВМ-серверы RELAY - это IBM VM/CMS системы, но вам не нужно быть пользователем VM, для того чтобы использовать RELAY. Если вы не в сети EARN/Bitnet, доступ к системе RELAY для вас закрыт. CHART доступен на любом NETSERV.

    При регистрации клиенту посылаются файлы RELAY INFO и RELAY USERGUIDE, которые содержат подробное описание RELAY.

    Краткое руководство по применению RELAY доступно из списка файлов документов EARN. Пошлите e-mail по адресу LISTSERV@EARNCC.BITNET. В теле сообщения напечатайте: GET RELAY MEMO.

    Previous: 4.5.14 Современные поисковые системы    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.16 Некоторые другие процедуры Интернет


    previous up down next index index
    Previous: 4.5.15 Диалог в локальных сетях и в Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.5.17 Сетевое моделирование

    4.5.16 Некоторые другие процедуры Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    NFS

    NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д.

    Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (Рис. 4.5.16.1).

    Рис. 4.5.16.1. Схема реализации nfs-системы клиент-сервер

    RPC (Remote Procedure Call, RFC-1057) процедура, разработанная SUN microsystem, в настоящее время используется практически во всех системах, базирующихся на UNIX. RPC - это программа, которая реализует вызов удаленных подпрограмм, способствуя построению распределенных программ. Она позволяет программе, называемой клиентом, послать сообщение серверу. Далее программа-клиент ожидает сообщения-отклика. RPC работает совместно с универсальной системой представления внешней информации XDP (External Data Representation). Сообщение запрос содержит параметры, которые определяют, что должно быть сделано на удаленной ЭВМ. В свою очередь отклик несет в себе информацию о результатах выполнения запроса.

    RPC может работать как на TCP, так и UDP транспортных уровнях. Использование RPC-техники упрощает программирование, так как не требует написания сетевых программ. Если используется протокол UDP, все что связано с обработкой тайм-аутов, повторных пересылок и пр. спрятано в внутри системных RPC-модулей. Формат RPC-запроса для UDP-версии показан на рис. 4.5.16.2.

    Рис. 4.5.16.2. Формат RPC-запроса

    Поле идентификатор процедуры устанавливается программой-клиента, пакет-отклик использует тот же идентификатор, что позволяет контролировать их соответствие. Каждый новый RPC-запрос имеет новый идентификатор. В настоящее время номер версии rpc равен 2. Следующие три поля содержат переменные: номер программы, номер версии и номер процедуры, которые определяют тип запрашиваемой клиентом процедуры. В поле идентификатор клиента может быть записан цифровой код клиента, идентификатор группы или вообще ничего. Поле верификатор используется при пересылке зашифрованных сообщений. Формат параметров процедуры зависит от типа этой процедуры. Размер поля параметров равен длине UDP-дейтограммы минус сумма длин остальных полей, включая верификатор. В случае работы с TCP-сегментами, где длина пакета не определена, между TCP-заголовком и XID вводится 4-x октетное поле длины RPC-сообщения. Формат RPC-отклика для UDP-версии (Рис. 4.5.16.3):

    Рис. 4.5.16.3. Формат RPC-отклика

    Поле отклик, содержащее 1, указывает на то, что данное сообщение представляет собой отклик на поступивший ранее запрос. Поле статус содержит 0 в случае, если запрос воспринят. Запрос игнорируется при конфликте кодов RPC-версии или неудачной идентификации клиента. Поле флаг результата принимает значение 0 при успешной обработке запроса. Ненулевое значение этого поля указывает на ошибку.

    Для записи параметров RPC-запросов, откликов, параметров и результатов выполнения процедуры используется внешнее представление данных (XDR - External Data Representation, RFC-1014). Отправитель, формируя RPC-сообщение, использует XDR-формат, а получатель преобразует данные из этого формата в традиционное представление.

    Существует два базовых вида отклика: MSG_ACCEPTED (сообщение принято) и MSG_DENIED (не принято). Факт приема сообщения не означает выполнение запрошенных процедур, поэтому клиенту выдается дополнительная информация о результатах взаимодействия его запроса с удаленной системой. RPC может найти применение при построении больших распределенных информационных систем, баз данных и систем управления. XDR позволяет программисту избежать написания специальных программ преобразования. Например, в разных ЭВМ используются различные форматы представления чисел с плавающей запятой. XDP берет на себя согласование форматов и делает написание прикладных программ машинно-независимым.

    Программы RPC-сервера используют большое число портов с нестандартизованными номерами. Для управления использованием этих портов имеется специальная программа (portmapper), которая имеет номер 100000, номер версии -2 и сама пользуется портом номер 111. Распределение номеров портов можно посмотреть с помощью программы:

    /usr/etc/rpcinfo -p

    program

    vers

    proto

    port

     

    [программа

    версия

    протокол

    порт

    название программы]

    100000

    2

    tcp

    111

    portmapper

    100000

    2

    udp

    111

    portmapper

    100029

    1

    udp

    664

    keyserv

    100005

    1

    udp

    702

    mountd (монтирует демон для NFS)

    100005

    2

    udp

    702

    mountd

    100005

    1

    tcp

    705

    mountd

    100005

    2

    tcp

    705

    mountd

    100003

    2

    udp

    2049

    nfs (сама NFS)

    100026

    1

    udp

    714

    bootparam

    100024

    1

    udp

    717

    status

    100024

    1

    tcp

    719

    status

    100021

    1

    tcp

    720

    nlockmgr (NFS-менеждер)

    100021

    1

    udp

    1031

    nlockmgr

    100021

    3

    tcp

    724

    nlockmgr

    100021

    3

    udp

    1032

    nlockmgr

    100010

    1

    udp

    718

    etherstatd

    100020

    2

    udp

    1033

    llockmgr

    100020

    2

    tcp

    729

    llockmgr

    100021

    2

    tcp

    732

    nlockmgr

    100021

    2

    udp

    1034

    nlockmgr

    100011

    1

    udp

    1041

    rquotad

    100001

    2

    udp

    1042

    rstatd

    100001

    3

    udp

    1042

    rstatd

    100001

    4

    udp

    1042

    rstatd

    100002

    1

    udp

    1043

    rusersd

    100002

    2

    udp

    1043

    rusersd

    100012

    1

    udp

    1044

    sprayd

    100008

    1

    udp

    1045

    walld

    Отсюда видно, что некоторые программы имеют несколько версий, а каждая комбинация номера программы, версии и протокола имеет свой собственный номер порта. В таблице 4.5.16.1 приведены ссылки на некоторые RPC-программы, используемые с NFS.

    Таблица 4.5.16.1. Коды программ, используемых в NFS

    Назначение программы

    Номер программы

    Номер версии

    Номер процедуры

    Менеджер портов (port mapper)

    100000

    2

    4

    NFS

    100003

    2

    15

    Монтировщик

    100005

    1

    5

    Менеджер блокировки

    100021

    1,2,3

    19

    Статус-монитор

    100024

    1

    6

    Монтировщик вызывается NFS-клиентом для обеспечения доступа к файловой системе сервера. Взаимодействие с файловой системой производится с помощью указателей файлов (handle), которые для версии 2 требуют 32 байт, а для версии 3 - 64 байт. Хотя NFS с самого начала была сориентирована на применение UDP (что было оправдано для локальных сетей), в настоящее время она в равной мере использует и TCP. Это позволяет NFS работать уже в масштабе всего Интернет. Третья версия NFS предполагает увеличение числа байт на одну команду READ или WRITE с 8192 до 65535 (ограничение, связанное с размером IP-дейтограммы). Увеличена в третьей версии и предельная длина файлов, которая задается уже 64-, а не 32-битным числом.

    RLOGIN (RFC-1281) - процедура удаленного доступа, реализованная в 4BSD UNIX. RLOGIN позволяет администратору сети определить список ЭВМ, авторизация и доступ к которым является общими. Пользователь может организовать групповой доступ к разным ЭВМ, где он авторизован, сохраняя для себя возможность общения с любой из машин, не вводя каждый раз пароль. Одной из реализаций RLOGIN является RSH. RSH включает в себя интерпретатор команд. Форма обращения имеет вид: RSH имя_ЭВМ команда. RLOGIN позволяет взаимодействовать как с внутренними, так и с внешними ресурсами сети и с этой точки зрения предоставляет большие возможности чем Telnet.

    REXECD представляет собой резидентную управляющую программу (демон), которая позволяет исполнять команды на удаленной ЭВМ в рамках TCP/IP сетей. Команда, выданная одной ЭВМ, может быть выполнена на другой ЭВМ, при этом автоматически, если необходимо, осуществляется процедура авторизации. REXECD использует TCP в качестве транспортной среды. Существуют реализации для сред UNIX, AIX и DOS.

    Previous: 4.5.15 Диалог в локальных сетях и в Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.17 Сетевое моделирование


    previous up down next index index
    Previous: 4.5.16 Некоторые другие процедуры Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.6 Электронная торговля в Интернет

    4.5.17 Сетевое моделирование
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Ни один проект крупной сети со сложной топологией в настоящее время не обходится без исчерпывающего моделирования будущей сети (речь, разумеется, идет не о России). Программы, выполняющие эту задачу, достаточно сложны и дороги. Целью моделирования является определение оптимальной топологии, адекватный выбор сетевого оборудования, определение рабочих характеристик сети и возможных этапов будущего развития. Ведь сеть, слишком точно оптимизированная для решений задач текущего момента, может потребовать серьезных переделок в будущем. На модели можно опробовать влияние всплесков широковещательных запросов или реализовать режим коллапса (для Ethernet), что вряд ли кто-то может себе позволить в работающей сети. В процессе моделирования выясняются следующие параметры:

    • Предельные пропускные способности различных фрагментов сети и зависимости потерь пакетов от загрузки отдельных станций и внешних каналов.
    • Время отклика основных серверов в самых разных режимах, в том числе таких, которые в реальной сети крайне нежелательны.
    • Влияние установки новых серверов на перераспределение информационных потоков (Proxy, Firewall и т.д.).
    • Решение оптимизации топологии при возникновении узких мест в сети (размещение серверов, DNS, внешних шлюзов, организация опорных каналов и пр.).
    • Выбор того или иного типа сетевого оборудования (например, 10BaseTX или 100BaseFX) или режима его работы (например, cut-through, store-and-forward для мостов и переключателей и т.д.).
    • Выбор внутреннего протокола маршрутизации и его параметров (например, метрики).
    • Определение предельно допустимого числа пользователей того или иного сервера.
    • Оценка необходимой полосы пропускания внешнего канала для обеспечения требуемого уровня QOS.
    • Оценка влияния мультимедийного трафика на работу локальной сети, например, при подготовке видеоконференций.

    Перечисленные задачи предъявляют различные требования к программам. В одних случаях достаточно провести моделирование на физическом (MAC) уровне, в других нужен уже уровень транспортных протоколов (например, UDP и TCP), а для наиболее сложных задач нужно воспроизвести поведение прикладных программ. Все это должно учитываться при выборе или разработке моделирующей программы. Ведь нужно учесть, что ваша машина должна в той или иной мере воспроизвести действия всех машин в моделируемой сети. Таким образом, машина эта должна быть достаточно быстродействующей и, несмотря на это, моделирование одной секунды работы сети может занять при определенных условиях не один час.

    Результаты моделирования должны иметь точность 10-20%, так как этого достаточно для большинства целей и не требует слишком много машинного времени. Следует иметь в виду, что для моделирования поведение реальной сети, надо знать все ее рабочие параметры: длины кабеля от концентратора до конкретной ЭВМ, задержки используемых кабелей, задержки концентраторов (этот параметр часто отсутствует в документации и его придется брать из документации на сетевой протокол, например из IEEE 802.3). Параметры могут быть определены и прямым измерением. Чем точнее вы воспроизводите поведение сети, тем больше машинного времени это потребует. Кроме того, вам предстоит сделать некоторые предположения относительно распределения загрузки для конкретных ЭВМ и других сетевых элементов, задержек в переключателях, мостах, времени обработки запросов в серверах. Здесь нужно учитывать и характер решаемых на ЭВМ задач. www/ftp-сервер или обычная персональная рабочая станция создают различные сетевые трафики. Определенное влияние на результат могут оказывать и используемые ОС. В случае моделирования реальной сети можно произвести соответствующие измерения, что иногда тоже не слишком просто. Учитывая сложность моделирования на одной ординарной ЭВМ, следует ограничиваться моделированием не более чем одной минуты для каждого из наборов параметров (этого времени достаточно для копирования практически любого файла через локальную сеть). Исключение может составлять моделирование внешнего трафика, но в этом случае весь локальный трафик должен рассматриваться как фоновый.

    4.5.17.1 Аналитическое моделирование

    Определение характеристик сети до того, как она будет введена в эксплуатацию, имеет первостепенное значение. Это позволяет отрегулировать характеристики локальной сети на стадии проектирования. Решение этой проблемы возможно путем аналитического или статистического моделирования.

    Аналитическая модель сети представляет собой совокупность математических соотношений, связывающих между собой входные и выходные характеристики сети. При выводе таких соотношений приходится пренебрегать какими-то малосущественными деталями или обстоятельствами.

    Телекоммуникационная сеть при некотором упрощении может быть представлена в виде совокупности процессоров (узлов), соединенных каналами связи. Сообщение, пришедшее в узел, ждет некоторое время до того, как оно будет обработано. При этом может образоваться очередь таких сообщений, ожидающих обработки. Время передачи или полное время задержки сообщения d равно:

    D = Tp + S + W,

    где Tp, S и W, соответственно, время распространения, время обслуживания и время ожидания. Одной из задач аналитического моделирование является определение среднего значения D. При больших загрузках основной вклад дает ожидание обслуживания W. Для описания очередей в дальнейшем будет использована нотация Д. Дж. Кенделла: A/B/C/K/m/z,

    где А - процесс прибытия: В - процесс обслуживания; С - число серверов (узлов); К - максимальный размер очереди (по умолчанию - ); m - число клиентов (по умолчанию - ); z - схема работы буфера (по умолчанию FIFO). Буквы А и В представляют процессы прихода и обслуживания и обычно заменяются следующими буквами, характеризующими закон, соответствующий распределения событий.

    D - постоянная вероятность;
    M - марковское экспоненциальное распределение;
    G - обобщенный закон распределения;
    Ek - распределение Эрланга порядка k;
    Hk - гиперэкспоненциальное распределение порядка k;

    Наиболее распространенными схемами работы буферов являются FIFO (First-In-First-Out), LIFO (Last-In-First-Out) и FIRO (First-In-Random-Out). Например, запись M/M/2 означает очередь, для которой времена прихода и обслуживания имеют экспоненциальное распределение, имеется два сервера, длина очереди и число клиентов могут быть сколь угодно большими, а буфер работает по схеме FIFO. Среднее значение длины очереди Q при заданной средней входной частоте сообщений l и среднем времени ожидания W определяется на основе теоремы Литла (1961):

    Для варианта очереди M/G/1 входной процесс характеризуется распределением Пуассона со скоростью поступления сообщений l. Вероятность поступления k сообщений на вход за время t равно:

    Пусть N - число клиентов в системе, Q - число клиентов в очереди и пусть вероятность того, что входящий клиент обнаружит j других клиентов, равна:

    Пj = P[n=j], j=0,1,2,. ; П0 = 1- r; r = lt;

    Тогда среднее время ожидания w:

    (формула Поллажека-Хинчина)

    s - среднеквадратичное отклонение для распределения времени обслуживания.

    Для варианта очереди M/G/1 H(t) = P[xё t] = 1 - e-mt (H - функция распределения времени обслуживания). Откуда следует s 2 = t 2.

    Для варианта очереди m/d/1 время обслуживания постоянно, а среднее время ожидания составляет:

    Аналитическая модель для сетей Ethernet (CSMA-CD) разработана Лэмом (S.S.Lam: "A Carrier Sense Multiple Access Protocol for Local Networks," Computer Networks, vol. 4, n. 1, pp. 21-32, January 1980). Здесь предполагается, что сеть состоит из бесконечного числа станций, соединенных каналами с доменным доступом. То есть станция может начать передачу только в начале какого-то временного домена. Распределение сообщений подчиняется закону Пуассона с постоянной скоростью следования l. Среднее значение времени ожидания для таких сетей составляет:

    где е - основание натурального логарифма, t - задержка распространения сигнала в сети. , соответственно первый и второй моменты распределения передачи или обслуживания сообщения. f(l) преобразование Лапласа для распределения времени передачи сообщения. Следовательно

    , а для сообщений постоянной длины f(l)=e-r , где . Для экспоненциального распределения длин сообщений:

    , .

    Рассмотрим вариант сети Ethernet на основе концентратора-переключателя с числом каналов N. При этом будет предполагаться, что сообщения на входе всех узлов имеют пуассоновское распределение со средней интенсивностью l i, распределение сообщений по длине произвольно. Сообщения отправляются в том же порядке, в котором они прибыли. Трафик в сети предполагается симметричным. Очередь имеет модель M/G/1. Среднее время ожидания в этом случае равно:

    ,

    где ,

    , а G=1/(N-1) равно вероятности того, что сообщение отправителя i направлено получателю j. Требование стабильности 1 требует, чтобы Для больших n это приводит к .

    Среднее время распространения сообщения в сети равно , где t равно rtt.

    4.5.17.2 Симуляционное моделирование

    Симуляционное (статистическое) моделирование служит для анализа системы с целью выявления критических элементов сети. Этот тип моделирование используется также для предсказания будущих характеристик системы. Такое моделирование может осуществляться с использованием специализированных языков симулирования и требует априорного знания относительно статистических свойств системы в целом и составляющих ее элементов. Процесс моделирования включат в себя формирование модели, отладку моделирующей программы и проверку корректности выбранной модели. Последний этап обычно включает в себя сравнение расчетных результатов с экспериментальными данными, полученными для реальной сети.

    При статистическом моделировании необходимо задать ряд временных характеристик, например:

    Системное время

    Интервал от момента генерации сообщения до получения его адресатом, включая ожидание в очереди

    Время ожидания

    Промежуток от приема сообщения сетевым интерфейсом до обработки его процессором

    Время распространения

    Задержка передачи сообщения от одного сетевого интерфейса до другого

    Время передачи

    Задержка пересылки сообщения от одного процессора до другого

    Полный список таких временных характеристик включает в себя значительно больше величин.

    В процессе моделирования рассчитываются следующие параметры:

    Статистика очередей

    Средняя длина очереди

    Пиковая длина очереди

    Среднеквадратичное отклонение длины очереди от среднего значения

    Статистика времени ожидания

    Среднее время ожидания

    Максимальное время ожидания

    Среднеквадратичное отклонение времени ожидания

    Статистика системного времени

    Среднее системное время

    Максимальное системное время

    Среднеквадратичное отклонение системного времени

    Полное число сообщений в статистике системного времени

    Пиковое значение числа системных сообщений

    Среднеквадратичное отклонение числа системных сообщений

    Статистика потерь сообщений

    Полное число потерянных сообщений

    Частота потери сообщений

    Доля потерь из-за переполнения очереди

    Доля потерь из-за таймаутов

    Разумеется, реальный перечень вычисляемых параметров может быть существенно шире и определяется конкретными целями расчетов. Рассмотрим частную задачу определения среднего числа связей между процессорами (узлами). Предполагается, что полное число узлов равно N, а схема соединения узлов соответствует изображенной на рис. 4.5.7.1.

    Рис. 4.5.7.1.

    Среднее расстояние от произвольного узла до всех остальных узлов равно D(N+1)/3, где D - расстояние между соседними узлами (предполагается константой).

    Возможны разные подходы к моделированию. Классический подход заключается в воспроизведении событий в сети как можно точнее и поэтапное моделирование последствий этих событий. В реальной жизни события могут происходить одновременно в различных точках сети. По этой причине для моделирования идеально подошел бы многопроцессорный компьютер, где можно воспроизводить любое число процессов одновременно. В любом случае необходимо выбрать некоторый постоянный временной интервал и считать, что события произошли одновременно, если расстояние между ними меньше этого интервала. Для сетей типа ethernet таким временным интервалом может быть бит-тайм (для 10-мегагбитного ethernet это 100нс). Понятно, что это уже отступление от реальности (ведь задержки в сетевом кабеле не кратны этому времени), но не слишком значительное. Надо сказать, что такого рода предположений при моделировании приходится делать много. По этой причине крайне важно сравнивать результаты моделирования с данными, полученными для реальной сети. Если отличия лежат в пределах 10-20%, можно считать, что сделанные предположения не увели программу слишком далеко от жизни и ею можно пользоваться для расчетов. Рассмотренный выше подход пригоден для моделирования сетевого коллапса, так как скорость расчетов здесь зависит от числа узлов и почти не зависит от сетевой загрузки.

    Другим подходом может стать метод, где для каждого логического сегмента (зоны столкновений) сначала моделируется очередь событий. При этом в каждой рабочей станции моделируется последовательность пакетов, ожидающих отправки. Эта очередь может время от времени модифицироваться, например, при получении ЭВМ пакета извне и необходимости послать на него отклик. После того как такая очередь для каждого сетевого объекта (сюда помимо ЭВМ входят мосты, переключатели и маршрутизаторы) построена, запускается программа отправки пакетов. При этом выбирается самый первый по времени пакет (ожидающий дольше других) и проверяются для него условия начала передачи (отсутствие несущей на входе сетевого интерфейса в данный момент и в течение 9,6 мксек до рассматриваемого момента - 96 тайм-битов). Если условия отправки выполнены, он "посылается" в сеть. Вычисляются моменты достижения им всех узлов данного логического сегмента, проверяются условия его столкновения с другими пакетами. Следует заметить, в этом подходе снимаются ограничения "дискретности" временной шкалы, использованной в предыдущем "классическом" подходе. Этот подход позволяет заметно ускорить расчеты при большом числе узлов, но малой загрузке сети. Проблемы реализации данной концепции моделирования связаны с обслуживанием довольно сложного списка, описывающего очередь пакетов, ожидающих отправки. В структуру этого списка включается и описание ситуации в сети на данный временной период. Дополнительные трудности сопряжены с поведением мостов, переключателей и маршрутизаторов, так как они могут вставлять в очередь дополнительные элементы, требующие немедленного обслуживания. Аналогичные вставки в очередь будут вызывать полученные станцией пакеты ICMP или TCP, требующие откликов. Причем такое вставление в очередь асинхронно по отношению к процедуре "отправки" пакетов. Очередь для всей локальной сети может быть единой, тогда пакеты разных логических сегментов должны быть помечены определенными флагами. При переходе из сегмента в сегмент флаг будет меняться. Возможно и построение независимых очередей для каждого из логических сетевых сегментов.

    Данный метод был использован студентом ТСС МФТИ Алексеем Овчаровым в его магитрской диссертации (2000 год) для определения свойств фрагмента сети в условиях, близких к предельным (загрузка на уровне 70-100%). Такие режимы трудно реализовать на практике без серьезного ущерба клиентам сети. Результаты расчета представлены на рис. 4.5.7.2.


    Рис. 4.5.7.2. Зависимость вероятности потери пакета в процентах от загрузки фрагмента сети

    Целью моделирования является определение зависимости пропускной способности сети и вероятности потери пакета от загрузки, числа узлов в сети, длины пакета и размера области столкновений.

    Исходные данные о структуре и параметрах сети берутся из базы данных. Ряд параметров сети задаются конфигурационным файлом (профайлом). Сюда могут записываться емкость буфера интерфейса и драйвера, время задержки обработки запроса (хотя в общем случае эта величина может также иметь распределение) и т.д.. К таким параметрам относятся также: MTU, MSS, TTL, window, некоторые значения таймаутов и т.д.

    Сеть разбивается на логические сегменты (зоны столкновений), в каждой из которых работает независимая синхронизация процессов (хотя эти процессы и влияют друг на друга через мосты, переключатели и маршрутизаторы).

    Полное моделирование сети с учетом рабочих приложений предполагает использование следующих распределений:

    • Распределение по проценту времени использования каждого из узлов для того или иного вида приложений.
    • Распределение узлов сети по их активности.
    • Распределение по используемым протоколам
    • Распределение по длинам пакетов.

    Последние два пункта существенным образом коррелированы с первым, так как используемые протоколы зависят от приложения, а активность узла может определяться, например длиной пересылаемого файла. По этой причине при полномасштабном моделировании сначала определяется, что собирается делать рабочая станция или сервер, (с учетом распределения по приложениям определяется характер задачи: FTP, MS explorer и т.д.). После этого разыгрываются параметры задания (длина файла, удаленность объекта и пр.), а уже на основе этого формируется фрагмент очереди пакетов.

    Задача первого этапа: проверка пропускной способности при вариации загрузки и длин пакетов, подсчет числа столкновений, проверка влияния размера буфера сетевого интерфейса на пропускную способность (влияние размера буфера переключателей по пути до адресата).

    Исходные данные для первого этапа:

    • частота посылки пакетов для каждого из узлов (в начале равная для всех) [d - интервал между пакетами]
    • длина пакета, посылаемого каждым узлом, (в начале равна для всех: минимальная [512 бит] и максимальная [12000 бит])
    • временное распределение моментов посылки пакетов (в начале равномерное)

    Структура описания каждого из узлов включает в себя (формируется с учетом будущего расширения):

    • Номер узла (идентификатор)
    • Код типа узла (байт: рабочая станция, мост, переключатель, маршрутизатор, повторитель)
    • mac-адрес (для повторителя =0)
    • ip-адрес (для повторителя, обычного MAC-моста и переключателя =0)
    • Байт статуса (узел ведет передачу; до узла дошел чужой пакет,..)
    • d (среднее расстояние между концом предыдущего и началом очередного пакета в бит-тактах)
    • Дисперсия ширины пакетов
    • Дисперсия значения d (зазор между последовательными пакетами).
    • Код используемого протокола (IPv4 или IPv6; TCP, UDP, ICMP и т.д.).
    • Полная длина сообщения в байтах
    • Время обработки пакета (задержка посылки отклика в бит-тактах)
    • Длина очередного пакета
    • Байт типа адресации (unicast, broadcast, multicast)
    • Ширина окна (число отправляемых пакетов без подтверждения)
    • Объем входного буфера (число пакетов; может измеряться и в байтах, но тогда нужны специальные указатели)
    • Объем выходного буфера (число пакетов)
    • Байт режима работы (для мостов и переключателей: cut-through; store-and-forward и т.д.; для рабочей станции определяется типом используемого протокола и фазой его реализации)

    Формат описания топологии сети (список)
    Элемент списка:

    • Идентификатор узла (номер)
    • Код типа узла
    • Список узлов соседей (номер_соседа:задержка_до_него)

    Процесс посылки пакета включает в себя (в соответствии с требованиями документа IEEE 802.3):

    1. Проверку возможности начала (отсутствует чужая активность, ipg=9,6 мксек)
    2. Последовательную передачу битов (каждый бит-такт)
    3. Контроль состояния столкновений (на протяжении времени, соответствующего диаметру столкновений сегмента сети)
    4. Обработка случаев столкновения (посылка jam)
    5. При столкновении вычисление номера бит-такта попытки возобновления передачи

    Попытка начала передачи предполагает проверку:

    1. Осуществлялась ли передача на предыдущем бит-такте?
    2. Контроль числа свободных от передачи бит-тактов (<96 ?)

    Процесс приема предполагает:

    1. Контроль окончания приема (бит-такт без данных в канале). Окончание приема может означать переход в режим анализа полученных данных.
    2. Контроль наличия столкновения
    3. Необходимо предусмотреть возможность (в некоторых режимах) контроля адресов (mac и ip) и содержимого пакета и т.д. (включая изменение режима работы узла, например, переход от чтения к передаче). Данный пункт абсолютно необходим для мостов и переключателей.

    Центральный менеджер осуществляет:

    1. Регистрацию начала передачи любым из узлов (номер узла и номер бит-такта)
    2. Расчет положения начала пакета к началу очередного бит-такта для всех возможных путей распространения.
    3. Запись в байты статуса узлов

    Вариант 1 (равномерное распределение по времени)

    Для каждого узла устанавливается определенная средняя частота посылки пакетов. Время посылки предполагается случайным. Средняя частота может быть задана равной для всех узлов. Так как минимальный размер пакета равен 64 байт (51.2 мксек=512 бит-тактов), максимальная частота посылки пакетов составляет ~19.5 кГц.

    Минимальный средний период посылки пакетов определяется в бит-тактах и должен быть больше 512 бит-тактов. Понятно, что пока узел осуществляет передачу, он не может пытаться передать новый пакет (многозадачные, многопользовательские системы с несколькими сетевыми интерфейсами пока рассматривать не будем). По этой причине частота посылки пакетов однозначно определяется паузой между концом предыдущего пакета и началом нового (d). Среднее значение периода посылки пакетов равно Тпакета+96(бит-тактов)+d (значение d величина статистическая). Для каждого узла задается значение d (сначала равное для всех узлов). Если предположить равномерное распределение вероятности (передача пакета может начаться в любой бит-такт с равной вероятностью).

    При определении того, пытаться ли начинать передачу в данный бит-такт будет проверка условия:

    rndm<1/d (выполнение условия предполагает попытку начала передачи).

    Если вероятность прихода n пакетов на время t распределена по закону Пуассона:

    , где L - средняя частота следования событий, то реальное время между событиями t может быть определено как t = -T ln(R). R - случайное число 0ё R ё 1, а T = 1/L.

    Результатами моделирования могут являться (фиксируются отдельно для каждого набора входных параметров):

    1.

    Вероятность потери пакета для логического сегмента и каждой из рабочих станций.

    2.

    Пропускная способность серверов для каждого из логических сегментов (путь сервер -> логический сегмент)

    3.

    Вероятность столкновения для каждого логического сегмента и каждой рабочей станции.

    4.

    Распределение потоков по логическим сегментам (и рабочим станциям) независимо для каждого направления (вход и выход).

    5.

    Распределение потоков для всех входов/выходов переключателей мостов и маршрутизаторов.

    6.

    Доля вспомогательного трафика (ICMP, SNMP, отклики TCP, широковещательные запросы и т.д.) по отношению к информационному потоку для различных узлов сети (серверов, маршрутизаторов)

    7.

    Уровень широковещательного трафика для каждого из логических сегментов

    Previous: 4.5.16 Некоторые другие процедуры Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.6 Электронная торговля в Интернет


    previous up down next index index
    Previous: 4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.1 Ping и Traceroute

    4.5 Процедуры Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    4.5 Процедуры Интернет

    1

    9

    4.5.1 Ping и Traceroute

    4

    27

    4.5.2 Finger

    3

    46

    4.5.3 Удаленный доступ (Telnet)

    8

    48

    4.5.4 Протокол пересылки файлов FTP

    10

    79

    4.5.5 Протокол X-Windows

    2

    33

    4.5.6 WWW

    12

    82

    4.5.7 Протокол новостей NNTP

    10

    45

    4.5.8 Поиск узлов и людей

    1

    3

    4.5.9 Серверы подписки (LISTSERV)

    12

    38

    4.5.10 Электронная почта

    12

    200

    4.5.11 Gopher

    4

    27

    4.5.12 WAIS

    7

    49

    4.5.13 Система поиска файлов Archie

    7

    34

    4.5.14 Современные поисковые системы

    16

    186

    4.5.15 Диалог в локальных сетях и в Интернет

    5

    46

    4.5.16 Некоторые другие процедуры Интернет

    3

    46

    4.5.17 Сетевое моделирование

    8

    66

    Данный раздел наиболее динамично развивающаяся часть Интернет-технологий. Одни виды услуг устаревают и выходят из употребления (Gopher, WAIS, MOSAIC), другие появляются вновь (поисковые машины, например Alta Vista, NetScape, MSExplorer и др.). В последнее время несравненно большее внимание стали уделять сетевой безопасности, системам поиска и диагностическим аспектам работы с сетями. Безопасность вышла на первые позиции из-за внедрения Интернет в область финансов и бизнеса. Последнее время активно развивается технология мультимедиа (интеграция с кабельным телевидением), сфера развлечений (игровые серверы) и информационно-поисковые системы на основе техники WWW.

    Previous: 4.4.21 Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.1 Ping и Traceroute


    previous up down next index index
    Previous: 4.5 Процедуры Интернет    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей
        Next: 4.5.2 Finger

    4.5.1 Ping и Traceroute
    Семенов Ю.А. (ГНЦ ИТЭФ)

    При работе в Интернет время от времени возникают ситуации, когда нужно определить, работоспособен ли тот или иной канал или узел, а в случае работы с динамическими протоколами маршрутизации выяснить, по какому из каналов вы в данный момент работаете. Используется эта процедура и для оценки вероятности потери пакетов в заданных сегментах сети или каналах. Для решения этих задач удобна программа Ping.

    Ping - это процедура, которая базируется на ICMP- и UDP-протоколах пересылки дейтограмм и служит для трассировки маршрутов и проверки работоспособности каналов и узлов (в некоторых программных пакетах эта команда имеет имена trace, hopcheck, tracert или traceroute). Для решения поставленной задачи PING использует отклики протокола ICMP. Применяется PING и при отладке сетевых продуктов. Трассировка может выполняться, например, посредством команды ping -q (пакет PCTCP). При выполнении этой команды ЭВМ сообщит вам Internet адреса всех промежуточных узлов, их имена и время распространения отклика от указанного вами узла. Следует иметь в виду, что трассировка осуществляется непосредственно с помощью IP-протокола (опция записи адресов промежуточных узлов). Ниже приведен пример использования команды Ping. Если вы просто напечатаете команду ping (пакет PCTCP), то ЭВМ выдаст на экран справочную таблицу по использованию этой команды:

    Usage:
    ping [-options] host
    options:

    -d [bytes]

    dump input packet

    (пропечатка входных пакетов).

    -d# [bytes]

    dump output packet

    (пропечатка выходных пакетов).

    -e

    cancel extended security

    (отмена дополнительных мер безопасности)

    -i seconds

    IP time to live

    (установка времени жизни пакетов IP)

    -j dest 1...dest n

    loose source routing

    (свободная маршрутизация).

    -k dest 1...dest n

    strict source routing

    (принудительная маршрутизация).

    -l length

    set length of icmp data

    (установить длину данных для ICMP).

    -n times

    ping host times number of times

    (провести зондирование ЭВМ заданное число раз).

    -o

    no-op option

    (ни каких опций для операций).

    -p precedence

    set IP precedence

    (установка IP-предпочтения).

    -q

    trace route

    (трассировка маршрута).

    -r

    record route

    (запись маршрута).

    -s level [authority]

    basic security

    (базовый уровень безопасности).

    -t

    ping forever

    (режим бесконечного ping).

    -v type

    set type of service

    (установка типа операции).

    -w seconds

    time to wait for answer

    (установка времени ожидания ответа).

    -x [{1|3 dest1..destn}]

    timestamp option

    (опция временных меток).

    -z

    quiet mode

    (набор статистики отключен).

    Команда трассировки маршрута ИТЭФ - сервер научно-исследовательской станции США Мак-Мурдо в Антарктиде (запись в файл route.txt):

    ping -q mcmurdo-gw.mcmurdo.gov > route.txt

    Содержимое файла route.txt будет иметь вид:

    hop 1:

    193.124.224.190

    ???

    имя для GW ИТЭФ пока не придумано

    hop 2:

    193.124.137.13

    MSU-Tower.Moscow.RU.Radio-MSU.net

    Вперед, в космос

    hop 3:

    193.124.137.9

    NPI-MSU.Moscow.RU.Radio-MSU.net

    Через спутник "Радуга"

    hop 4:

    193.124.137.6

    DESY.Hamburg.DE.Radio-MSU.net

    пакеты совершили мягкую посадку в Гамбурге, ДЕЗИ

    hop 5:

    188.1.133.56

    dante.WiN-IP.DFN.DE

    hop 6:

    193.172.4.12

    duesseldorf2.empb.net

    hop 7:

    193.172.4.8

    amsterdam6.empb.net

    hop 8:

    193.172.12.6

    Amsterdam1.dante.net

    Пересекаем Атлантический океан

    hop 9:

    194.41.0.42

    New-York1.dante.net

    вступили на землю США

    hop 10:

    192.103.63.5

    en-0.cnss35.New-York.t3.ans.net

    hop 11:

    140.222.32.222

    mf-0.cnss32.New-York.t3.ans.net

    hop 12:

    140.222.56.2

    t3-1.cnss56.Washington-DC.t3.ans.net

    hop 13:

    140.222.145.1

    t3-0.enss145.t3.ans.net

    hop 14:

    192.203.229.243

    SURA2.NSN.NASA.GOV

    Снова в космос

    hop 15:

    128.161.166.1

    GSFC8.NSN.NASA.GOV

    но теперь через американский

    hop 16:

    128.161.232.1

    GSFC12.NSN.NASA.GOV

    спутник

    hop 17:

    128.161.1.1

    ARC1NEW.NSN.NASA.GOV

    hop 18:

    192.203.230.2

    ARC1.NSN.NASA.GOV

    hop 19:

    192.100.12.2

    ARC2.NSN.NASA.GOV

    hop 20:

    128.161.115.2

    MCMURDO.NSN.NASA.GOV

    Оденьте шапку, мы в Антарктиде!

    Target

    157.132.100.1

    reached on hop 21

    round-trip time 1370 ms

    Фантастика, мы пересекли туда и обратно Европу, два океана и США с востока на запад, побывали в Антарктиде и все это менее чем за полторы секунды.

    Ping позволяет не только проверить работоспособность канала, но измерить ряд его характеристик, включая надежность (например, версия ping для SUN):

    PING -s cernvm.cern.ch 100 64 (пакеты по 100 байт посылаются 64 раза)
    108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=0. time=606. Ms
    .............. (результаты пересылки пакетов с номерами 1-61 опущены)
    108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=62. time=667. Ms
    108 bytes from crnvma.cern.ch (128.141.2.4): icmp_seq=63. time=628. Ms
    ---- PING Statistics ----
    64 packets transmitted, 63 packets received, 1% packet loss (процент потерянных пакетов)

    round-trip (ms) min/avg/max = 600/626/702

    Для получения большей точности следует послать большее число пакетов. В последней строке приведены результаты измерения RTT, где представлены минимальное/среднее/максимальное значения.

    Наибольшее число модификаций имеет BSD-версия ping, если на вашей ЭВМ нет этой удобной программы, можно воспользоваться общедоступной версией по адресу:

    ftp.uu.net /unix/bsd-sources/sbin/ping (см. также приложения).

    Сходную информацию позволяет получить и программа traceroute (использует непосредственно IP-пакеты):

    traceroute -n cernvm.cern.ch
    traceroute to crnvma.cern.ch (128.141.2.4) 30 hops max, 40 byte packets
    1 193.124.224.50 3 ms 2 ms 2 ms
    2 194.85.112.130 3 ms 3 ms 3 ms
    3 194.67.80.5 4 ms 3 ms 3 ms
    4 193.124.137.6 534 ms 534 ms 534 ms
    5 188.1.56.5 545 ms 545 ms 546 ms
    6 193.172.4.12 558 ms (ttl=59!) 549 ms (ttl=59!) 548 ms (ttl=59!)
    7 193.172.4.30 580 ms (ttl=58!) 581 ms (ttl=58!) 581 ms (ttl=58!)
    8 193.172.24.10 586 ms 585 ms 597 ms
    9 192.65.185.1 593 ms 587 ms 598 ms
    10 128.141.2.4 628 ms 602 ms 619 ms

    При написании программ, использующих протокол ICMP, полезно воспользоваться отладочной опцией PING, которая позволяет получить на экране шестнадцатеричный образ посылаемого и получаемого пакетов:

    ping -d# 300 ns.itep.ru

    (версия PCTCP, запрос отклика серверу имен, число байт, подлежащих выдаче, равно 300)

    Dump of outgoing packet
    Version = 4 IP header length = 5 Precedence = Routine
    Type of Service = Normal
    Total length = 284 Protocol = 1 TTL = 64
    45 00 01 1C 00 02 00 00 40 01 71 29 C0 94 A6 81 C1 7C E0 23 IP-заголовок
    08 00 8D BD E9 03 00 01 ... ICMP-заголовок
    host responding, time = 60 ms

    Выдачи ради экономии места сильно сокращены. Тексты пакетов начинаются с кодов IP-версии (=4) и длины заголовка (=5), далее следует байт TOS=0, два байта длины пакета (01 1С) и т.д. в соответствии с требованиями IP-протокола.

    ping -d 300 ns.itep.ru (команда получения текста пакета-отклика на запрос)
    host responding, time = 25 ms
    Dump of incoming packet
    Version = 4 IP header length = 5 Precedence = Routine
    Type of service = Normal
    Total length = 284 Protocol = 1 TTL = 254
    45 00 01 1C EE 29 00 00 FE 01 C5 00 C1 7C E0 23 C0 94 A6 81
    00 00 93 BD EB 03 00 01 ..............

    В принципе, процедуру Ping и Traceroute можно реализовать и с привлечением протоколов UDP и TCP. Рассмотрим следующую модель реализации Traceroute :

    Посылаем последовательно по адресу IP(URL) IP-пакеты со значением TTL=1, 2,... и т.д. Если до больше одного шага, соответствующий маршрутизатор, размещенный по пути следования к адресату, уничтожит посланный пакет и вернет ICMP-сообщение: Time Exceeded (тип ICMP-сообщения=11), указав при этом IP-адрес узла, где это произошло. Послав запрос типа get_name_by_address для присланного IP, можно получить имя узла, откуда пришло данное уведомление. Отсутствие сообщения Time Exceeded (например, после трех попыток) будет говорить о достижении -адресата. В результате такой последовательности посылок будет получена исчерпывающая информация о пути до указанной цели.

    Для данной методики реализации traceroute не существенно, какой протокол использовать, UDP, ICMP или TCP.

    Previous: 4.5 Процедуры Интернет    UP: 4.5 Процедуры Интернет
    Down: 4.5.8 Поиск узлов и людей    Next: 4.5.2 Finger


    previous up down next index index
    Previous: 4.6 Электронная торговля в Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.6.2 SET и другие системы осуществления платежей

    4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0
    Семенов Ю.А. (ГНЦ ИТЭФ)


    Перевод Семенова Ю.А. (ГНЦ ИТЭФ)

      Мерзавцам этим только б воровать,
    Про то торговцы титулами знают,
    Но, кроме денег, им на все плевать.

            Джузеппе Джусти, "Шутки"

    Открытый торговый протокол Интернет IOTP (Internet Open Trading Protocol; D. Burdett, RFC-2801, смотри также RFC-2935) создает базу коммерции через Интернет. Протокол не зависит от используемой платежной системы и т.д.. IOTP способен обрабатывать ситуации, когда продавец выступает в качестве покупателя, обеспечивает оформление и отслеживание доставки товаров и прохождения платежей, или совмещает некоторые или все перечисленные функции.

    IOTP поддерживает:

    • Известные модели торговли
    • Новые модели торговли
    • Глобальную совместимость

    1.1. Коммерция в Интернет

    Рост Интернет и прогресс в электронной коммерции привносят огромные изменения в сферу бизнеса, политики, управления и в само общество. Методы, которые используются партнерами в торговле, обогатились и необратимо изменились. Наиболее заметные изменения характера торговли включают в себя:

    • Присутствие. Операции, требующие личного контакта, становятся исключением, а не правилом. Этот процесс начался при внедрении торговли по почте и по телефону. Электронная коммерция через Интернет еще шире раздвигает область и объем операций, проводимых без личного контакта участников сделок.
    • Аутентификация. Важной частью личного присутствия является возможность партнеров использование знакомых объектов и диалога для подтверждения того, кем они являются. Продавец демонстрирует различными способами свою способность производить кредитные и платежные операции. Покупатель предъявляет физические свидетельства своей платежеспособности, полученные от государства или финансовой организации. При этом учитывается разнообразная объективная информация: местоположение магазина, внешность, знакомство и поведение участников, знакомство с данной фирмой и ее торговым знаком.
    • Инструменты платежа. Несмотря на широкое рзвитие безналичных платежей, заметная часть торговых операций обеспечивается наличными деньгами или даже бартером. Существующая инфраструктура платежной системы по экономическим соображениям не может поддерживать операции с низкими суммами платежей, но и не может от них отказаться.
    • Стоимость операций. Новое значение низкой стоимости операции в Интернет связано с возможностью того, что продавец может предложить, например, объекты с ценой, составляющей долю денежной единицы, которой не существует в реальности.
    • Доставка. Внедряются новые методы доставки, включая доставку по сети, например, информации или программных продуктов. Возможна доставка по частям при играх, просмотре, прослушивании и некоторых других виртуальных услугах, при этом она должна быть подтверждена до осуществления платежа. Логично, что деньги в этом случае не могут быть возвращены.

    1.2. Преимущества IOTP

    Разработки программ для электронной коммерции будут более привлекательны, если они окажутся совместимыми для разных разработчиков. Однако IOTP призван, прежде всего, решить проблему коммуникаций между различными решениями.

    Виды платежей

    IOTP предлагает стандартные рамки для инкапсуляции платежных протоколов. Это означает, что средства платежей смогут лучше взаимодействовать, если они встроены в программы, следующие протоколу IOTP. В результате базовые виды электронных платежей смогут найти более широкое распространение на большем разнообразии рабочих платформ.

    Продавцы

    Существует несколько преимуществ для торговцев:

    • Они смогут предложить более широкий перечень видов платежей,
    • Они смогут быть более уверены, что покупатель будет иметь программу, необходимую для осуществления покупки
    • При получении платежа и расписки от покупателя о получении товара или услуги они смогут обеспечить клиента гарантией, что он имел дело именно с тем человеком или организацией
    • новые торговцы смогут вступить в этот Интернет-рынок с новыми продуктами и услугами, используя новые возможности, предоставляемые IOTP.

    Банки и финансовые организации

    Существует несколько преимуществ для банков и финансовых организаций:

    • они смогут предоставить услуги IOTP для торговцев
    • они найдут новые возможности для реализации услуг, сопряженных с IOTP:

    - предоставление услуг клиентам продавцов
    - деньги от обработки новых платежей и депозитов

    • они имеют возможность построить отношения с новыми продавцами

    Покупатели

    Для покупателей также имеется несколько преимуществ:

    • они получат больший выбор продавцов, с которыми они смогут иметь дело
    • >
    • имеется более удобный интерфейс для осуществления покупки
    • существуют возможности уладить их проблемы через продавца (а не через банк)
    • существует запись их операций, которая может использоваться, например, налоговыми службами

    1.3. Основы IOTP

    Протокол описывает содержимое, формат и последовательность сообщений, которые пересылаются между партнерами электронной торговли - покупателями, торговцами и банками или финансовыми организациями.

    Протокол спроектирован так, чтобы обеспечить его применимость при любых схемах электронных платежей, так как он реализует весь процесс продажи, где передача денег всего лишь один шаг из многих.

    Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д..

    Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу.

    Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки в пределах которых реализуется торговая операция.

    2. Введение

    Открытый торговый протокол Интернет определяет некоторое число различных операций IOTP:

    • Покупка. Осуществляет предложение, оплату и опционно доставку.
    • Возврат. Производит возврат платежа для покупки, выполненной ранее.
    • Обмен ценностями. Включает в себя два платежа, наприммер в случае обмена валют.
    • Аутентификация. Производит проверку для организации или частного лица - являются ли они тем, за кого себя выдают.
    • Отзыв платежа. Осуществляет отзыв электронного платежа из финансового учрежденрия.
    • Депозит. Реализует депозит средств в финансовом учреждении.
    • Запрос. Выполняет запрос состояния операции IOTP, которая находится в процессе реализации, или уже выполнена.
    • Пинг. Простой запрос одного приложения IOTP с целью проверки, функционирует ли другое приложение IOTP.

    Эти операции считаются базовыми, позднее могут быть определены другие операции IOTP. Каждая из перечисленных выше операций IOTP включает в себя:

    • Некоторое число организаций, выполняющих торговую функцию и
    • Набор торговых обменов. Каждый торговый обмен включает в себя обмен данными между торговыми ролями в форме набора торговых компонентов.

    2.1. Торговые роли

    Торговые роли идентифицируют различные обязанности, которые может выполнять организации в процессе торговли. В IOTP используется пять торговых ролей, которые проиллюстрированы на рис. .1.

    Рис. .1. Торговые роли в IOTP

    Определены следующие роли:

    • Покупатель. Человек (или организация), который получает товар или услугу и платит за это.
    • Продавец. Человек (или организация), у которого приобретается а, выполненного потребителем. товар или услуга, который оффициально ответственнен за их предоставление и кто извлекает выгоду в результате платеж.
    • Оператор платежей. Субъект, который получает платеж от потребителя в пользу торговой фирмы или физического лица.
    • Оператор доставки. Субъект, который доставляет товар или предоставляет услугу потребителю от торговой фирмы или лица.
    • Лицо или фирма обслуживающая клиента торговой фирмы. Субъект, который вовлечен в обслуживание клиента торговой фирмы.

    Роли могут выполняться одной организацией или различными организациями. Например:

    • В простейшем случае одна организация (напр., продавец) может оформлять покупку, принимать платеж, доставлять товар и осуществлять обслуживание покупателя.
    • В крайнем случае, продавец может оформить покупку, но предложить покупателю осуществить платеж в банке, попросить доставить товар специальную фирму, выполняющую доставк, и обратиться к третей фирме, обеспечивающей круглосуточное обслуживание, с просьбой помочь покупателю в случае возникновения каких-то непредвиденных проблем.

    Заметим, что в этой спецификации, если не указано обратного, когда используются слова Покупатель (Consumer), Продавец (Merchant), Кассир (Payment Handler), Агент доставки (Delivery Handler) или обслуживание потребителя (Customer Care Provider), подрузамевается торговая роль (Trading Role), а не конкретная организация.

    Любая конкретная организация может выполнять множество ролей. Например компания, которая продает товары или услуги через Интернет, может выполнять роь продавца при продаже товара или услуги и роль потребителя, когда компания покупает товары или услуги сама.

    2.2. Торговый обмен

    Протокол Интернет для торговли (The Internet Open Trading Protocols) идентифицируют четыре торговых обмена, которые включают обмен данными между торговыми ролями. Среди них:

    • Предложение. Обмен предложения (Offer Exchange) предполагает, что продавец предоставляет покупателю причины, почему сделка должна иметь место. Такой обмен называется предложением, если сделка может состояться.
    • Оплата. Платежный обмен (Payment Exchange) предполагает осуществление какого-то платежа между потребителем и кассиром. Направление платежа может быть любым.
    • Доставка. Процедура доставки (Delivery Exchange) сопряжена с передачей товаров или доставкой информации о товарах агентом доставки Потребителю.
    • Аутентификация. Аутентификационный обмен (Authentication Exchange) может использоваться любой из тоговых ролей для аутентификации другой торговой роли и выяснения является ли субъект тем, за кого он себя выдает.

    Операции IOTP состоят из различных комбинаций этих торговых обменов. Например, операция покупки IOTP включает в себя обмены Предложения, Оплаты и Доставки. А операция обмена ценностями IOTP состоит из предложения и двух обменов оплаты.

    Торговые обмены (Trading Exchanges) состоят из торговых компонентов, которые передаются между различными торговыми ролями. Где возможно, число круговых задержек в операциях IOTP минимизируется путем объединения компонентов нескольких торговых обменов в комбинированные сообщения IOTP. Например, операция покупки IOTP объединяет компонент организации доставки и компонент предложения, для того чтобы избежать лишних запросов и откликов Потребителя.

    Ниже каждый торговый обмен IOTP описан более детально. Для простоты описания они рассматриваются как независимые процедуры.

    2.2.1. Предложение

    Целью обмена Предложения является обеспечение Покупателя информацией о сделке с тем чтобы он мог решить, продолжать ли ему эту сделку. Это продемонстрировано ниже на рис. .2.

    1.

    Покупатель (С) решает сделать покупку и шлет информацию о заказе продавцу (М), например в формате HTML.

    C à M

    Данные: информация о том, что покупается (запрос Предложения) - формат запроса не определен в рамках IOTP

    2.

    Продавец проверяет информацию, выданную Покупателем, формирует предложение, опционно его подписывает и посылает Покупателю.

    C ß M

    Отклик на Предложение. Компоненты: Статус; Организации (покупатель, DelivTo, продавец, кассир, Агент обслуживания покупателя); Заказ; Платеж; Доставка; TradingRoleData подпись отклика-предложения (опционно)

    3.

    Покупатель проверяет информацию от продавца и решает, стоит ли осуществлять покупку.

    Рис. .2. Предложение

    Предложение использует следующие торговые компоненты, которые пересылается между покупателем и продавцом.

    • Компонет статус используется для сообщения партнеру что сформирован корректный отзыв-предложение.
    • Компоненты Организации содержит информацию, которая описывает организации, исполняющие определенные торговые роли в данной сделке.
     

    Покупатель предоставляет информацию о том, кто он и, если товар или услуги доставлены, место, куда они доставлены.

     

    Продавец дополняет эту информацию данными о себе, о Кассире, Агенте обслуживания Покупателя и, если товар или услуга должна быть доставлена, то и об агенте доставки.

    o

    Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю.

    o

    Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного.

    o

    Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты.

    o

    Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки.

    o

    Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности.

    Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:

    • низкая стоимость сделки может не требовать подписи
    • сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты
    • некоторые предложения могут не включать в себя доставку товара
    • обмен ценностями включает два платежа
    • продавец может не предлагать покупателю каких-либо услуг.

    Информация, предоставляемая покупателем продавцу, предоставляется различными способами, например, она может быть получена.

    • Используя [HTML] страницы, как часть "практики" покупателей.
    • Используя стандарт OPS (Open Profiling Standard), который был недавно предложен,
    • В форме компонентов Организации, ассоциирующихся с аутентификацией Покупателя Продавцом.
    • Как компоненты Заказа в последней версии IOTP.

    2.2.2. Платежный обмен

    Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем еассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange).

    Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме рис. .3. Возможны и более простые платежные обмены.

    1.

    Покупатель решает что-то купить и посылает информацию об этой операции (запрос предложения) Продавцу, напр., используя HTML.

    C à M

    Информация о том, что покупается (вне рамок стандарта IOTP)

    2.

    Продавец решает, какой тип и протокол платежа следует предложить, записывает эти данные в компонент Brand List и посылает покупателю.

    C ß M

    Компоненты: список типов платежей (Brand List)

    3.

    Покупатель выбирает тип платежа, протокол и вид валюты, формирует компонент выбор типа и посылает его продавцу.

    C à M

    Компонент: Выбор из списка типов платежа (Brand List Selection)

    4.

    Продавец проверяет выбор типа, определяет сумму платежа, опционно подписывает документ и посылает его Покупателю.

    C ß M

    Компонент: Платеж; Организации (продавец и кассир); опционная подпись отклика-предложения, которая подтверждает другие компоненты.

    5.

    Покупатель проверяет объявленную сумму платежа и, если согласен, посылает запрос кассиру.

    C à P

    ЗАПРОС ПЛАТЕЖА. Компоненты: Статус, Платеж; Организации (продавец и Кассир); Информация о торговых ролях (опционно); опционная подпись отклика-предложения, которая подтверждает все прочие компоненты. Данные о схеме платежа.

    6.

    Кассир проверяет информацию, включая опционную подпись и, если все в порядке, начинает обмен компонентами данных по схеме платежа с целью выбора типа и протокола платежа.

    C « P

    ПЛАТЕЖНЫЙ ОБМЕН. Компонент: Данные о схеме платежа

    7.

    Как только обмен протокольными платежными сообщениями завершится, Кассир посылает Покупателю платежную расписку, которая опционно подписывается, с целью подтверждения платежа.

    C « P

    ОТКЛИК на ПЛАТЕЖ. Компоненты: Статус, платежная расписка; платежное заявление; данные о торговых ролях (опционно); опционная подпись отклика-предложения; опционная подпись платежной расписки, которая связывает платеж и предложение

    8.

    Покупатель проверяет платежную расписку

    Рис. .3. Платежный обмен

    Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир:

    • Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit - имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор.
    • Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card).
    • Компонент Статус используется, чтобы проинформировать кассира, что обмен предложения успешно завершился, и кассиром для сообщения о благополучном завершении платежного обмена.
    • Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:

     

    - Роль продавца необходима для того, чтобы Кассир мог идентифицировать, какой продавец инициализировал платеж. Обычно, результатом платежа, реализованного кассиром в пользу продавца, является кредитная или дебитная операция, выполненная со счетом продавца. Эти операции находятся за пределами области действия IOTP

     

    - Роль кассира необходима, чтобы продавец мог проверить, что платежную операцию произвел именно тот Кассир, который нужно.

    • Компонент платеж содержит данные о сумме платежа, валюте и направлении оплаты (кто кому).
    • Компонент подпись "Offer Response", если присутствует, цифровым образом подтверждает целостность и корректность всех остальных компонентов. Заметим, что компоненты списка типов платежа (Brand List) и выбор типа платежа (Brand Selection) не подписываются до тех пор, пока платежные данные не сформированы (шаг 4 на диаграмме).
    • Компонент данные о торговых ролях (Trading Role Data) содержит информацию о других ролях (например, продавца), о которых нужно проинформировать кассира.
    • Компонент схема платежа (Payment Scheme) содержит сообщения платежного протокола, используемого при сделке. Например, это могут быть сообщения SET, сообщения Mondex, сообщения GeldKarte или какого-то другого метода платежа, поддерживаемого IOTP. Содержимое компонента схема платежа (Payment Scheme) определено в приложениях, которые описывают то, как работает IOTP с различными платежными протоколами.
    • Компонент платежной расписки (Payment Receipt) содержит запись о платеже. Содержимое зависит от используемого платежного протокола.
    • Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение корректности платежа путем цифровой подписи компонентов платежной расписки и подписи отклика-предложения. Подпись предложения гарантирует целостность и корректность компонентов заказа, организаций, и доставки, содержащихся в предложении. Эта подпись соединяет платеж и предложение.

    Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8).

    2.2.3. Обмен доставки

    Целью обмена доставки является обеспечить физическую или сетевую доставку купленного товара или услуги покупателю. Второй целью служит передача покупателю "декларации о доставке", предоставляя дополнительную информацию о доставке, такую как номера накладной или номер трайлера, с помощью которого будет доставлен груз. Результат доставки может быть также подтвержден с помощью электронной подписи. Обмен сообщениями показан на диаграмме ниже.

    1.

    Покупатель решает осуществить сделку и посылает информацию продавцу о том, что нужно доставить и как это лучше сделать.

    C à M

    Информация о том, что следует доставить (вне зоны ответственности IOTP)

    2.

    Продавец проверяет информацию, полученную от покупателя, добавляет информацию о том, как будет осуществляться доставка, информацию об организациях, вовлеченных в доставку и, опционно, электронную подпись, после чего отправляет все это покупателю.

    C ß M

    Компоненты: lоставка; jрганизации (fгент доставки, доставит туда-то); заказ, опционная подпись отклика-предложения

    3.

    Покупатель проверяет, корректна ли доставочная информация, получает разрешение на доставку, например путем оплаты, и посылает эти данные агенту доставки.

    C à D

    Запрос доставки. Компоненты: cтатус; доставка, организации: (продавец, агент доставки, DelivTo); Заказ, данные о торговой роли (опционны); опционная подпись отклика-предложения, опционная подпись платежной расписки (из платежного обмена)

    4.

    Агент доставки проверяет информацию и авторизацию. Запускает или диспетчеризует доставку, а также готовит и отправляет накладную покупателю, которая опционно может быть подписана.

    C ß D

    Отклик доставки. Компоненты: статус; накладная (Delivery Note), данные о торговой роли (опционны); опционная подпись отклика доставки

    5.

    Покупатель проверяет накладную и принимает товар или ждет доставки, как это указано в накладной (Delivery Note).

    Рис. .4. Обмен доставки

    Обмен доставки использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и агент доставки:

    • Компонент Статус используется для указания агенту доставки, что предыдущий обмен (например, обмен предложения или платежный обмен) успешно завершился, а агентом доставки для индикации завершения обмена доставки.
    • Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:

      -Адрес доставки указывает, куда должны быть доставлен товар или услуги.
      -Роль агента доставки необходима для того, чтобы он мог проверить, что может выполнить данную операцию;
      -Роль продавца необходима для того, чтобы агент доставки мог определить, какой продавец затребовал доставку.

    • Компонент заказа содержит информацию о товарах или услугах, которые должны быть доставлены.
    • Компонент доставки содержит информацию о том, как будет осуществлена доставка, например по почте или с помощью e-mail.
    • Компонент подписи предложения-отклика (Offer Response), если присутствует, электронным образом подписывает все перечисленные выше компоненты, обеспечивая их целостность.
    • Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение платежа, с помощью электронной подписи компонента платежной расписки и предложения. Это используется агентом доставки для проверки того, что доставка авторизована.
    • Компонент накладной (Delivery Note) содержит информацию об обслуживании покупателя, относящуюся к доставке. Программа покупателя не интерпретирует информацию о доставке, но должна быть способна отобразить эту информацию, как в момент доставки, так и позднее, если покупатель выбирает из списка операций сделку, к которой относится данная доставка.
    • Компонент подпись отклика доставки (Delivery Response), если присутствует, предоставляет подтверждение результатов доставки путем электронной подписи накладной (Delivery Note) и подписей любого отклика-предложения или отклика платежа, которые получил агент доставки.

    2.2.4. Аутентификационный обмен

    Целью аутентификационного обмена является допущение одной организации, например, финансовому учреждению, иметь возможность проверить, что другая организация, например Покупатель, является тем, за кого себя выдает.

    В аутентификационный обмен вовлечены:

    • Аутентификатор - организация, запрашивающая аутентификацию и
    • Аутентифицируемый - организация, которая должна быть аутентифицирована.
    • >

    Это проиллюстрировано на диаграмме ниже.

    1.

    Первая организация, например покупатель, осуществляет действие (например, нажимает на клавишу на HTML-странице), которое требует, чтобы организация была аутентифицирована.

    1 à 2

    Запрос аутентификации (за пределами действия IOTP)

    2.

    Вторая организация генерирует данные вызова и список алгоритмов, которые могут быть использованы для аутентификации и/или запрос данных об организации, после чего посылает все это первой организации.

    1 ß 2

    Запрос аутентификации. Компоненты: запрос аутентификации, запрос информации о торговых ролях.

    3.

    Первая организация опционно проверяет любую подпись, связанную с запросом аутентификации, после чего использует специфицированный алгоритм аутентификации, чтобы сформировать отклик аутентификации, который посылается второй организации вместе с запрошенной информацией об организации.

    1 à 2

    Отклик аутентификации. Компонент: отклик аутентификации, организации

    4.

    Отклик аутентификации проверяется согласно данным вызова для того чтобы выяснить является ли первая организация той, за которую себя выдает, результат записанный в компонент статус посылается первой организации.

    1 ß 2

    Статус аутентификации. Компонент: Статус

    5.

    Первая организация опционно проверяет результаты, записанные в cтатус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру.

    Рис. .5. Обмен аутентификации

    Обмен аутентификации использует следующие торговые компоненты, которыми обмениваются между собой две организации:

    • Компонент запрос аутентификации, который требует аутентификации, указывает, какой алгоритм аутентификации следует употребить.
    • Компонент запроса данных о торговых ролях, который требует информации об организации, например адрес.
    • Компонент отклик аутентификации, который содержит отклик на вызов, сформированный получателем компонента запроса аутентификации.
    • Компонент организации, который содержит результат запроса данных о торговых ролях.
    • Компонент статуса, который содержит результаты верификации отклика аутентификации второго партнера.

    2.3. Обзор базового уровня IOTP

    Здесь описываются операции, которые образуют основу IOTP. Главными факторами, определяющими реализацию IOTP, являются роли, которые поддерживает реализованное решение. Роли в пределах IOTP более детально описаны в разделе 2.1. Базовыми ролями являются: продавец, покупатель, кассир, агент доставки и агент обслуживания покупателя.

    Существует три типа Кассиров:

    • принимающие платеж как часть сделки или совершающие выплату, как возврат платежа;
    • принимающие средства как часть депозитной операции;
    • выдающие средства при отмене сделки.

    Ниже приведенная таблица определяет для каждой роли операции IOTP и торговые блоки, которые должны поддерживаться для каждой роли.

    Продавцы

     

    Склад

    Пла-тиль-щик

    Получа-тель платежа

    Покупатель

    Кассир

    Агент доставки

    Транзакции

    Покупка

    Нужно

       

    Нужно

    Продавцы

     

    Store

    Пла-тиль-щик

    Получа-тель платежа

    Покупатель

    Кассир

    Агент доставки

    Возврат средств

    Нужно

     

     

    b)
    Зависит

     

     

    Аутентификация

    Можно

    Нужна

    Можно

    b)
    Зависит

    Обмен ценностями

    Можно

       

    Нужно

    Отзыв

     

    Нужно

     

    b)
    Зависит

    Депозит

     

     

    Нужно

    b)
    Зависит

    Запрос данных

    Нужно

    Нужно

    Нужно

    Можно

    Нужно

    Нужно

    Ping

    Нужно

    Нужно

    Нужно

    Можно

    Нужно

    Нужно

    Торговые блоки

    TPO

    Нужно

    Нужно

    Нужно

    Нужно

    Выбор TPO

    Нужно

    Нужно

    Нужно

    Нужно

    Запрос Auth

    a)
    Зависит

     

    a)
    Зависит

    a)
    Зависит

    Отклик Auth

    a)
    Зависит

     

    a)
    Зависит

    a)
    Зависит

    Отклик предложения

    Нужно

    Нужно

    Нужно

    Нужно

    Запрос платежа

         

    Нужно

    Нужно

     

    Платежный обмен

         

    Нужно

    Нужно

     

    Платежный отклик

         

    Нужно

    Нужно

     

    Запрос доставки

         

    Нужно

     

    Нужно

    Отклик доставки

         

    Нужно

     

    Нужно

    Продавцы

     

    Склад

    Пла-тильщик

    Получа-тель

    Покупатель

    Кассир

    Агент доставки

    Запрос данных

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Отклик данных

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Запрос Ping

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Отклик Ping

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Подпись

    Нужно

    Нужно

    Нужно

    Ограничено

    Нужно

    Нужно

    Ошибка

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    Нужно

    В выше приведенной таблице:

    • "Нужно" означает, что торговая роль должна поддерживать операцию или торговый блок.
    • "Можно" означает, что программная реализация может поддерживать операцию или торговый блок по усмотрению разработчика.
    • "Зависит" означает, что программная реализация операции или торгового блока зависит от одного из следующих условий:
     

    - Поддерживаются базовые операции аутентификации IOTP;

     

    - Если требуется для данного метода платежа, как это определено в его сопровождающем документе IOTP.

    • "Ограничено" означает, что торговый блок должен быть понят, и c его содержимым можно манипулировать, но не при любых условиях. В частности, в случае блока подписи Покупатель не обязан уметь проверять цифровые подписи.

    Решения IOTP должны поддерживать все операции IOTP и торговые блоки, необходимые, по крайней мере, для одной из ролей (колонка), как это описано в приведенной выше таблице для решений, которые считаются поддерживающими IOTP.

    3. Структура протокола

    В предыдущем разделе дано введение, которое объясняет:

    • Торговые роли, которые выполняют различные организации в ходе реализации сделки: Продавец, Покупатель, Кассир, Агент доставки и Агент обслуживания покупателя.
    • Торговые обмены, каждый из которых предполагает некоторый информационный обмен между торговыми ролями в форме набора торговых компонентов.

    Ниже описано:

    • Как торговые компоненты формируются в торговые блоки и сообщения IOTP, которыми осуществляется обмен в форме XML-документов между различными торговыми ролями.
    • Как производится обмен IOTP-сообщениями между торговыми ролями для того, чтобы выполнить операцию IOTP.
    • XML-определения сообщений IOTP, включая операционный блок ссылки (Transaction Reference Block), - XML-элемент, который идентифицирует IOTP-операцию и IOTP-сообщение Message, сопряженное с ним.
    • Определения ID-атрибутов XML, которые используются для идентификации сообщений IOTP, торговых блоков и компонентов, а также то, как они соотносятся с использованием элементов ссылок из других XML-элементов.
    • Как дополнительные XML-элементы и новые определенные пользователем значения для существующих IOTP-кодов могут использоваться при расширении IOTP.
    • Как IOTP использует элемент Packaged Content для вложения данных, таких как сообщения платежных протоколов или определения заказа, в сообщения IOTP.
    • Как IOTP идентифицирует языки, чтобы можно было использовать различные языки в рамках сообщений IOTP.
    • Как IOTP работает с безопасными и опасными сетевыми позициями (Net Locations), при посылке сообщений.
    • Как могут аннулироваться операции IOTP.

    3.1. Обзор
    3.1.1. Структура сообщений IOTP

    Структура сообщения IOTP и его отношения с торговыми блоками и компонентами проиллюстрировано на диаграмме ниже.

    Рис. .6. Структура сообщения IOTP

    На диаграмме определена концепция блока ссылок операции (Transaction Reference Block). Такой блок содержит среди прочего уникальный идентификатор операции IOTP. Кроме того, каждому блоку и компоненту присваивается ID-атрибут (смотри раздел 3.4), который является уникальным в пределах IOTP. Следовательно, комбинации ID-атрибута и глобального уникального идентификатора в блоке ссылок операции достаточно, для однозначной идентификации любого торгового блока или компонента.

    3.1.2. Операции IOTP

    Предопределенный набор сообщений IOTP, которыми обмениваются торговые роли, составляют операцию IOTP. Это проиллюстрировано ниже на диаграмме.

    Рис. .7. Функциональная схема операция IOTP

    На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов.

    В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):

    • Покупка. Поддерживает предложение, платеж и, опционно, доставку.
    • Возврат. Поддерживает возврат денег для сделанной ранее покупки.
    • Обмен ценностями. Включает в себя два платежа, которые реализуют обмен ценностями, например валютный обмен.
    • Аутентификация. Поддерживает удаленную аутентификацию одной торговой роли другой ролью с помощью различных аутентификационных алгоритмов, и предоставляет информацию об организации - торгового агента, который должен быть аутентифицирован с целью, например, подготовки предложения.
    • Отзыв. Поддерживает отзыв электронного платежа из финансовой организации.
    • Депозит. Поддерживает депозит электронного платежа в финансовой организации.
    • Запрос. Поддерживает запрос состояния транзакции IOTP, которая в данный момент реализуется или уже завершилась.
    • Ping. Эта операция поддерживает простой запрос, который позволяет одному приложению IOTP выяснить, работает ли некоторое другое приложение IOTP.

    3.2. Сообщение IOTP

    Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке.

    XML-определение сообщения IOTP выглядит следующим образом.

    <!ELEMENT IotpMessage
    ( TransRefBlk,

    SigBlk?,

    ErrorBlk?,

    ( AuthReqBlk |

    AuthRespBlk |

    AuthStatusBlk |

    CancelBlk |

    DeliveryReqBlk |

    DeliveryRespBlk |

    InquiryReqBlk |

    InquiryRespBlk |

    OfferRespBlk |

    PayExchBlk |

    PayReqBlk |

    PayRespBlk |

    PingReqBlk |

    PingRespBlk |

    TpoBlk |

    TpoSelectionBlk

    )*

    ) >
    <!ATTLIST IotpMessage
    xmlns CDATA
    'iotp:ietf.org/iotp-v1.0'

    Содержимое:

    TransRefBlkсодержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)

    AuthReqBlk, AuthRespBlk,

    Торговые блоки.

    DeliveryReqBlk

    Торговые блоки присутствуют в сообщениях IOTP, а само содержимое

    DeliveryRespBlk

    торгового блока зависит от типа выполняемой операции IOTP

    ErrorBlk

    смотри определение каждой операции в разделе 9.

    InquiryReqBlk,

     

    InquiryRespBlk,

     

    OfferRespBlk, PayExchBlk,

     

    PayReqBlk

    Полные определения каждого торгового блока описаны в разделе 8.

    PayRespBlk, PingReqBlk,
    PingRespBlk,
    SigBlk,
    TpoBlk,
    TpoSelectionBlk

     

    Атрибуты:

    Xmlns

    Определение [XML Namespace] для сообщений IOTP.

    3.2.1. XML Document Prolog

    Сообщение IOTP является корневым элементом XML-документа. Оно, следовательно, должно предшествоваться соответствующим прологом документа XML. Например:

    <?XML Version='1.0'?>
    <!DOCTYPE IotpMessage >
    <IotpMessage>
    ...

    3.3. Блок ссылок операции (Transaction Reference Block)

    Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:

    • Компонент ID-операции, который однозначно идентифицирует операцию IOTP. Компоненты ID-операции идентичны для всех сообщений IOTP, относящихся к одной IOTP-операции.
    • Компонент ID-сообщения, который предоставляет управляющую информацию о сообщении IOTP, а также однозначно идентифицирует сообщение IOTP в рамках операции IOTP.
    • Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий.

    Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:

    <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
    <!ATTLIST TransRefBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4).

    Cодержимое:

    TransId

    Смотри 3.3.1 Id-компонент операции.

    MsgId

    Смотри 3.3.2 Id-компонент сообщения.

    RelatedTo

    Смотри 3.3.3 Компонент Related To.

    3.3.1. Идентификационная компонента транзакции

    Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже:

    <!ELEMENT TransId EMPTY >

    <!ATTLIST TransId ID

    ID #REQUIRED

    Version

    NMTOKEN #FIXED '1.0'

    IotpTransId

    CDATA #REQUIRED

    IotpTransType

    CDATA #REQUIRED

    TransTimeStamp

    CDATA #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет Id-компонент транзакции в рамках операции IOTP.

    Version

    Определяет версию IOTP и, следовательно структуру сообщений IOTP, которые используются транзакцией IOTP.

    IotpTransId

    Содержит данные, которые однозначно определяют транзакцию IOTP. Это атрибут должен отвечать правилам для идентификаторов сообщений [RFC 822].

    IotpTransTyp

    Это тип исполняемой транзакции IOTP. Для базовой версии IOTP он идентифицирует "стандартную" транзакцию IOTP и предполагает определенную последовательность и содержимое сообщений IOTP, которыми обмениваются торговые роли. Корректными значениями атрибута являются:

    о

    BaselineAuthentication (Базовая аутентификация)

    o

    BaselineDeposit

    o

    BaselinePurchase

    o

    BaselineRefund

    o

    BaselineWithdrawal

    o

    BaselineValueExchange

    o

    BaselineInquiry

    o

    BaselinePing

    Значение IotpTransType управляется процедурой, описанной в разделе 12 IANA Considerations, которая позволяет пользователю определить величины IotpTransType. В последних версиях IOTP, этот список будет расширен с целью поддержки различных типов транзакций IOTP. Вероятно, будет поддержан динамический тип (Dynamic), который указывает, что последовательность шагов в транзакции не является стандартной.

    TransTimeStamp

    Там где система, запускающая транзакцию IOTP, имеет внутренние часы, атрибут устанавливается равным времени старта транзакции IOTP в формате [UTC].

    Главным назначением этого атрибута является обеспечение альтернативного пути идентификации транзакции путем спецификации времени его запуска.

    Некоторые системы не могут генерировать временные метки. В этом случае этот атрибут должен содержать значение "NA" (Not Available).

    3.3.2. Идентификатор сообщения

    Компонент Id-сообщения предоставляет контрольную информацию о сообщении IOTP, а также однозначно идентифицирует сообщение в рамках транзакции IOTP. Его определение выглядит следующим образом.

    <!ELEMENT MsgId EMPTY >

    <!ATTLIST MsgId ID ID #REQUIRED

    RespIotpMsg NMTOKEN #IMPLIED

    xml:lang NMTOKEN #REQUIRED

    LangPrefList NMTOKENS #IMPLIED

    CharSetPrefList NMTOKENS #IMPLIED

    SenderTradingRoleRef NMTOKEN #IMPLIED

    SoftwareId CDATA #REQUIRED

    TimeStamp CDATA #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно идентифицирует сообщение IOTP в рамках транзакции IOTP (смотри раздел 3.4 ID атрибуты). Заметим, что если сообщение IOTP пересылается повторно, тогда значение этого атрибута остается неизменным.

    RespIotpMsg

    Это ID-атрибут содержит Id-компонент сообщения IOTP, откликом на которое оно является. Таким образом все сообщения IOTP в пределах транзакции оказываются связаны. Это поле необходимо каждому сообщению IOTP за исключением первого сообщения IOTP в транзакции.

    SenderTradingRoleRef

    Элемент ссылки (смотри раздел 3.5) торговой роли, которая сформировала сообщение IOTP. Он используется, чтобы идентифицировать сетевую позицию (Net Locations) (смотри раздел 3.9) торговой роли, которой требуется сообщить о технических ошибках (смотри раздел 4.1), связанных с торговыми блоками.

    Xml:lang

    Определяет язык, используемый атрибутом, или дочерние элементы в пределах этого компонента, если не переписан атрибутом xml:lang в дочернем элементе. Смотри раздел 3.8.

    LangPrefList

    Опционный список языковых кодов, который согласуется с идентификацией языков [XML]. Он используется отправителем, чтобы указать порядок предпочтения языков, которые получатель сообщения должен использовать при подготовке отклика. Получатель не обязан использовать один из указанных языков.

    CharSetPrefList

    Опционный список идентификаторов символьных наборов, которые соответствуют символам в [XML]. Он используется отправителем для указания порядока предпочтения символьных наборов, которые получатель может применить при формировании отклика. Получатель не обязан использовать один из указанных символьных наборов.

    SoftwareId

    Содержит информацию, которая идентифицирует программу, сформировавшую сообщение IOTP. Его целью является помочь разрешить проблему совместной работы различных программ, обменивающихся сообщениями. Это простая текстовая строка на языке, определенном xml:lang. Она должна содержать, по крайней мере:

  • имя производителя программного продукта
  • название программного продукта
  • версию программы
  • форму программного обеспечения (build)
  • TimeStamp

    Когда прибор, отправляющий сообщение имеет внутренние часы, атрибут делается равным времени генерации сообщения IOTP в формате [UTC].

    3.3.3. Компонент Related To

    Компонент Related To связывает транзакции IOTP с другими транзакциями или другими событиями с помощью идентификаторов этих событий. Определение этого компонента представлено ниже.

    <!ELEMENT RelatedTo (PackagedContent) >

    <!ATTLIST RelatedTo ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    RelationshipType NMTOKEN #REQUIRED

    Relation CDATA #REQUIRED

    RelnKeyWords NMTOKENS #IMPLIED >
    Атрибуты:

    ID

    Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP.

    xml:lang

    Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.

    RelationshipType

    Определяет тип отношения. Корректными значениями являются:

    • IotpTransaction, в случае которого элемент Packaged Content содержит IotpTransId другой транзакции IOTP.
    • Ссылка, в случае которой элемент Packaged Content содержит указатель на некоторый другой, не-IOTP документ.

    Значения RelationshipType управляются процедурами, определенными в разделе 12 IANA Considerations, которые позволяют пользователю определить свои значения атрибута.

    Relation

    Атрибут Relation содержит фразу на языке, определенном xml:lang, он определяет природу отношений между транзакцией, которая содержит этот компонент и другой транзакцией или другим событием. Окончательное текстовое выражение оставлено на усмотрение составителей программ IOTP.

    Целью атрибута является обеспечение торговых ролей, включенных в транзакцию IOTP, объяснением природы отношений между транзакциями. Следует позаботиться о том, чтобы слова, использованные в атрибуте Relation, правильно указывали "направление" отношений. Например: одна транзакция может быть возвратом денег для другой выполненной ранее транзакции. В этом случае транзакция, которая возвращает деньги, должна содержать слова атрибута Relation, такие как "возврат за", а не "возврат кому" или просто "возврат".

    RelnKeyWords

    Этот атрибут содержит ключевые слова, которые могут быть использованы, чтобы помочь идентифицировать подобные отношения, например все виды возвратов. Ожидается, что рекомендуемые ключевые слова будут выбраны в процессе практического использования. В этой версии спецификации не содержится никаких специальных рекомендаций по ключевым словам

    Cодержимое:

    PackagedContent

    Packaged Content (смотри раздел 3.7) содержит данные, которые идентифицируют связанные транзакции. Его формат варьируется в зависимости от значения атрибута RelationshipType.

    3.4. ID-атрибуты

    IOTP-сообщения, блоки (т.e. блоки ссылок операции и торговые блоки), торговые компоненты (включая ID-компонент транзакции и компонент подписи) и некоторые их дочерние элементы задаются атрибутом "ID" XML, который служит для идентификации этих XML-элементов. Эти элементы используются так, что один элемент может ссылаться на другой. Всем этим атрибутам присваиваются ID.

    Значения каждого ID-атрибута является уникальным в пределах транзакции IOTP т.e. набор IOTP-сообщений, который имеет тот же самый компонент ID транзакции. Однажды присвоенное значение ID-атрибута элемента никогда не меняется. Это означает, что когда элемент копируется, значение ID-атрибута остается неизменным.

    Как следствие можно использовать эти идентификаторы для ссылки и нахождения содержимого любого сообщения IOTP, блока или компонента (смотри раздел 3.5).

    3.4.1. Определение ID-атрибутов сообщений IOTP

    ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже:

    IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
    IotpMsgIdPrefix ::= NameChar (NameChar)*

    IotpMsgIdPrefix

    Кроме того сообщения, которые содержат: торговый блок информационного запроса, информационного отклика, запроса или отклика Ping, используют один и тот же префикс для всех сообщений, посланных Продавцом или Покупателем:

    о

    "M" - Продавец (Merchant)

    о

    "C" - Покупатель (Consumer)

    Для сообщений, которые содержат торговый блок информационного запроса или блок запроса Ping, префикс делается равным "I" (Inquiry).

    Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q".

    Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:

    о

    "P" - Первый Кассир

    o

    "R" - Второй Кассир

    o

    "D" - Агент доставки

    o

    "C" - Доставка (Deliver To)

    Префиксы должны содержать один символ. NameChar имеет то же значение, что и определение NameChar в [XML].

    IotpMsgIdSuffix

    Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для данной торговой роли транзакции IOTP. Рекомендации сводятся к следующему:

    o

    Первому сообщению IOTP, посланному торговой ролью, присваивается суффикс "1".

    o

    Для второго и последующих IOTP-сообщений, посланных той же торговой ролью, суффикс увеличивается на 1 для каждого последующего сообщения.

    o

    Суффикс не может содержать начальных нулей.

    Короче Id-компонент первого сообщения IOTP, посланного Покупателем будет иметь ID-атрибут "C1", второе - "C2", третье - "C3" и т.д. Цифра имеет то же определение что и в [XML].

    3.4.2. Определения ID-атрибута для блока и компонента

    ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:

    BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
    IdSuffix ::= Digit (Digit)*

    IotpMsgId_value

    ID-атрибут. ID-компонента сообщения IOTP, где блок или компонент использован впервые.

    В IOTP, торговые компоненты и торговые блоки копируются из одного сообщения IOTP в другое. I D-атрибут не изменяется, когда существующий торговый блок или компонент копируется в другое сообщение IOTP.

    IdSuffix

    Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для ID-атрибута ID-компонента сообщения, используемого для генерации ID-атрибута. Рекомендуется здесь следующее:

    o

    Первому блоку или компоненту, посылаемому торговой ролью присваивается суффикс "1"

    o

    Для второго и далее блоков или компонентов ID-атрибуты увеличивается на 1 для каждого последующего сообщения.

    o

    Суффикс не может содержать начальных нулей.

    Короче, первый новый блок или компонент добавляется ко второму посылаемому сообщению IOTP, например, первый ID-атрибут - "C2.1", второй - "C2.2", третий - "C2.3" и т.д. Цифра имеет то же определение, что и в [XML].

    3.4.3. Пример использования ID-атрибутов

    На диаграмме проиллюстрировано, как используются значения ID-атрибутов.

    Рис. .8. Пример использования ID-атрибутов

    3.5. Элемент References

    Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:

    • Идентификация элементов XML, чей дайджест включен в компонент подписи.
    • Указание на компонент организации кассира, который используется при платеже.

    Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:

    • Принадлежит той же самой IOTP-транзакции (т.e. Id-компонет транзакции и IOTP-сообщения совпадают).
    • Имеет значение ID-атрибута элемента соответствующее значению ссылки элемента.

    Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.

    Рис. .9. Ссылки элемента (Element References)

    Атрибуты ссылки элемента определены как "NMTOKEN", а не "IDREF" (смотри [XML]). Это сделано потому, что IDREF требует, чтобы элемент XML, на который ссылаются, принадлежал тому же XML-документу. В IOTP это не всегда так.

    3.6. Расширение IOTP

    Базовая версия IOTP определяет минимальный протокол, с которым система, поддерживающая IOTP, должна быть способна работать. По мере разработки новых версий IOTP будут определяться дополнительные типы транзакций IOTP. Кроме того, базовая и будущие версии IOTP будут поддерживать два механизма расширения возможностей IOTP пользователем:

    o дополнительные XML-элементы
    o новые значения существующих IOTP-кодов.

    3.6.1. Дополнительные XML-элементы

    Имена XML элементов и атрибутов используемых в IOTP составляют пространство имен [XML], как это определено атрибутом xmlns элемента IotpMessage. Это позволяет Th IOTP поддерживать включение дополнительных XML-элементов в IOTP-сообщения посредством использования пространства имен XML. Используя XML Namespaces, дополнительные XML-элементы могут быть включены на любом уровне в сообщение IOTP, включая:

    o новые торговые блоки
    o new торговые компоненты
    o новые XML-элементы торгового компонета.

    При этом следуют определенным правилам:

    о

    Любой новый XML-элемент должен быть декларирован согласно правилам [XML Namespaces]

    o

    Новые XML-элементы, которые являются торговыми блоками или компонентами должны содержать ID-атрибуты с именем атрибута ID.

    Для того чтобы быть уверенным, что дополнительные элементы XML могут быть обработаны корректно, IOTP резервирует использование специального атрибута, IOTP:Critical, который принимает значение True или False и может появляться в дополнительных элементах, добавляемых к IOTP-сообщению. Целью этого атрибута является допущение IOTP проинформировать приложение, можно ли безопасно продолжить транзакцию. В частности:

    • Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "True" и IOTP уведомлен приложением, что оно не знает как обрабатывать элемент и его дочерние элементы, тогда транзакция IOTP выдает техническую ошибку (смотри раздел 4.1).
    • Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "False", тогда транзакция IOTP может продолжать работу, если IOTP уведомлен о том, что приложение не знает как обработать этот элемент. В этом случае:

     

    - любые дополнительные XML-элементы, содержащиеся в XML-элементе и определенные в пространтстве имен IOTP, должны включать этот элемен всякий раз, когда IOTP XML- элемен используется или копируется IOTP.

     

    - содержимое дополнительного элемента следует игнорировать, за исключением случая, когда оно должно учитываться при генерации дайджеста в ходе формировании электронной подписи.

    • Если дополнительный XML-элемент не имеет атрибута "IOTP:Critical", тогда он должен обрабатываться так, как если бы имел атрибут "IOTP:Critical" со значением "True"
    • Если XML-элемент содержит атрибут "IOTP:Critical", тогда значение атрибута следует использовать во всех дочерних элементах этого элемента.

    Для того чтобы гарантировать то, что документы, содержащие "IOTP:Critical" корректны, этот атрибут объявляется частью DTD для дополнительных элементов в форме:

    IOTP:Critical

    (True | False ) 'True'

    3.6.2. Opaque Embedded Data

    Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7).

    3.7. Элемент PackagedContent

    Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают:

    o для инкапсуляции сообщений платежной системы, таких как сообщения SET,
    o для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note).

    В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.

    <!ELEMENT PackagedContent (#PCDATA) >
    <!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >

    Атрибуты:

    Name

    Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например:

    <ABCD>
    <PackagedContent Name='FirstPiece'>
    snroasdfnas934k
    <PackagedContent Name='SecondPiece'>
    dvdsjnl5poidsdsflkjnw45
    </PackagedContent>
    </ABCD>

    Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.

    Content

    Идентифицирует, какой тип данных находится в содержимом элемента PackagedContent. Корректными значениями атрибута Content являются:

    о

    PCDATA. Содержимое элемента PackagedContent может рассматриваться как PCDATA и более не обрабатываться.

    о

    MIME. Содержимое элемента PackagedContent является MIME-объектом. Обработка должна включать поиск MIME-заголовков внутри элемента PackagedContent.

    о

    MIME:mimetype. Содержимое элемента PackagedContent является MIME-объектом с заголовком "Content-Type: mimetype". Хотя допускается иметь MIME:mimetype с атрибутом Transform равным NONE, более желательно иметь атрибут Transform равным BASE64. Заметим, что, если используется Transform = NONE, тогда все содержимое должно соответствовать PCDATA. Некоторые символы будет нужно закодировать как объекты XML, или как символьные объекты.

    о

    XML. Содержимое элемента PackagedContent может рассматриваться как XML-документ. Следует использвать секции CDATA, или Transform = BASE64, чтобы гарантировать, что содержимое элемента PackagedContent соответствует PCDATA.

    Transform

    Идентифицирует преобразование, которое было произведено нс даннвми, прежде чем они были помещены элемент. Допустимыми значениями являются:

    • NONE. Содержимое элемента PackagedContent типа PCDATA является корректным представлением данных. Заметим, что разворачивание объекта должно быть произведено (т.e. замена &amp; и &#9;) до анализа данных. Секции CDATA могут встречаться в элементе PackagedContent, где атрибут Transform равен NONE.
    • BASE64. Содержимое элемента PackagedContent типа PCDATA представляет собой BASE64 кодировкуреального содержимого.

    Cодержимое:

    PCDATA

    Это действительные данные, которые вложены в элемент. Формат данных и правила их кодирования записаны в атрибутах Content и Transform.

    3.7.1. Packaging HTML

    PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:

    • Ссылки на любой документы, изображения или другие вещи, такие как звук или WEB-страницы, могут влиять на понимание данных получателем, которые должны соотноситься с другими элементами Packaged, содержащимися в том же родительском элементе, например, описание заказа.
    • Если, для того чтобы удовлетворить рассмотренным выше требованиям, в исходный элемент включен более чем один элемент PackagedContent, тогда атрибут Name верхнего уровня, который определяет ссылки на все другие элементы Packaged, должен иметь значение Main.
    • Относительные ссылки на другие документы, изображения и т.д. одного элемента PackagedContent на другой реализуются путем установления значения относительной ссылки на атрибут Name другого элемента PackagedContent на том же уровне и в пределах того же родительского элемента.
    • Никакие внешние ссылки, которые требуют немедленного разрешения, не должны быть использованы. Так как это может осложнить или сделать невозможным отображение HTML.
    • [MIME] используется, чтобы инкапсулировать данные в пределах каждого элемента Packaged. Это означает, что информация в заголовке MIME использована для идентификации типа данных, которые инкапсулированы.

    Если выше приведенные соглашения не реализуются, например, включением внешних ссылок, которые должны быть разрешены, тогда получатель HTML должен быть об этом проинформирован.

    В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно.

    3.7.2. Пакетирование XML

    Рекомендуется поддержка XML. Когда необходимо отобразить XML, например, чтобы представить содержимое описания заказа Покупателю, разработчики должны следовать новейшим рекомендациям консорциума World Wide Web.

    3.8. Идентификация языков

    IOTP использует идентификацию языка [XML] для того, чтобы специфицировать, какие языки применены в тексте и атрибутах IOTP-сообщения.

    Для того чтобы определить, какие элементы XML содержат атрибуты xml:lang, нужно придерживаться следующих принципов:

    • обязательный атрибут xml:lang содержится в каждом торговом компоненте, где присутствуют атрибуты или содержимое, которое требует отображения или печати на определенном языке;
    • опционный атрибут xml:lang вводится в дочерние элементы торговых компонентов. В этом случае значение xml:lang, если оно имеется, переписывает значение для торгового компонента.

    Атрибуты xml:lang, которые следуют этим принципам, включаются в торговые элементы, а их дочерние XML-элементы определены в разделе 7.

    Отправитель сообщения, обычно Покупатель, может указать свои предпочтения для языка и символьного набора путем спецификации соответствующего списка в Id-компоненте сообщения (смотри раздел 3.3.2). Заметим, что получатель такого сообщения не обязан строго следовать этим предпочтениям, так как он может не иметь необходимых средств для этого. Это также означает, что возможность работать с этими списками не является требованием данной спецификации. Однако возможность реагировать, используя один из объявленных языков или символьных наборов является желательной.

    3.9. Безопасные и небезопасные позиции в сети

    IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:

    • "Безопасные" сетевые позиции, где конфиденциальность данных гарантируется с помощью, например, некоторых методов шифрования, таких как [SSL/TLS].
    • "Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется.

    Заметим, что должны присутствовать безопасная или небезопасная сетевая позиция (Net Location) или обе обязательно.

    Если присутствует одна из двух сетевых позиций, только она и может использоваться. Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.

    3.10. Аннулированные транзакции

    Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент.

    3.10.1. Аннулирование транзакций

    Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен.

    Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли.

    Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене.

    Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца.

    Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка.

    После аннулирования транзакции IOTP, Покупатель должен обратиться в сетевую позицию, специфицированную атрибутом CancelNetLocn, содержащимся в элементе торговой роли для организации, которой был послан блок Cancel. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:

    о

    после получения блока запроса;

    o

    до посылки блока отклика.

    Если торговая роль, отличная от Покупателя, аннулирует транзакцию в любое другое время, это должно восприниматься получателем, как ошибка.

    3.10.2. Обработка аннулированных транзакций

    Если блок Cancel получен Покупателем в момент, когда аннулирование разрешено, тогда покупатель должен прервать транзакцию.

    Если блок Cancel получен торговой ролью, отличной от Покупателя, тогда торговой роли следует ожидать, что Покупатель обратится к сетевойму узлу, специфицированному атрибутом CancelNetLocn, содержащимся в элементе Trading Role.

    4. Обработка ошибок IOTP

    IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений.

    Могут произойти различные ошибки:

    -

    "технические ошибки", которые не зависят от цели сообщения IOTP,

    -

    "деловые ошибки", которые указывают, что имеется специфическая проблема для процесса (напр., для платежа или доставки), который исполняется.

    Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента)

    4.1. Технические ошибки

    К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть:

    o повторная попытка передачи;
    o аннулирование транзакции.

    Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение.

    Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут.

    Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.

    4.2. Рабочие ошибки

    Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны. Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок.

    Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.

    Рабочие ошибки должны обычно представляться пользователю так, чтобы он мог решить, что делать дальше. Например, если ошибка связана с недостаточностью платежных средств в предложении, независящим от типа платежа (смотри раздел 9.1.2.2), пользователь может пожелать выбрать другой счет того же типа или другой тип платежа или даже другую платежную систему. Иными словами, если реализация, базирующаяся на IOTP, допускает это и пользователь может перевести дополнительные средства на счет и совершить еще одну попытку.

    4.3. Глубина ошибки

    Три уровня, на которых могут произойти ошибки в IOTP, включают транспортный уровень, уровень сообщения и уровень блока.

    4.3.1. Транспортный уровень

    Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP.

    Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос.

    Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом.

    Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP.

    Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте.

    4.3.2. Уровень сообщения

    Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3).

    Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:

    • XML not well formed. Документ имеет не верный формат XML (смотри [XML])
    • XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])
    • Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.

    Заметим, что проверки блока подписи включают проверку, где это возможно, того, что каждый из компонентов подпися вычислен правильно. Если подпись вычислена неправильно, тогда данные, которые покрываются подписью не будут признаны истинными. Процедура проверки подписи описана в разделе 6.2.

    4.3.3. Уровень блоков

    Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:

    • техническими ошибками
    • рабочими ошибками

    Технические ошибки далее делятся на:

    • Связанные с проверкой атрибутов блочного уровня и элементов.
    • Связанные с проверкой согласованности блоков и компонентов.
    • Переходные технические ошибки.

    Если случислась техническая ошибка, связанная с блоком или компонентом, формируется компонент Error для посылки отправителю некорректного сообщения.

    4.3.3.1. Проверки атрибутов блочного уровня и элементов

    Проверки элемента и атрибута блочного уровня производятся только в пределах одного и того же блока. Проверки, которые включают в себя перекрестные сверки с другими блоками, относятся к проверкам согласованности блоков и компонент.

    Проверки элемента и атрибута блочного уровня включают в себя:

    • проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;
    • проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;
    • если предыдущие проверки прошли успешно, тогда осуществляется контроль согласованности значений атрибутов и содержимого элементов со значениями атрибутов и содержимым элементов любых других компонентов в пределах блока.

    4.3.3.2. Проверки согласованности компонентов и блоков

    Проверки согласованности компонентов и блоков состоит из:

    • проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;
    • проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;
    • проверки взаимосогласованности атрибутов и элементов в блоках данного сообщения IOTP и блоков, полученных ранее IOTP-сообщений в рамках одной и той же транзакции.

    Если блок проходит проверку атрибутов и элементов блочного уровня и контроль согласованности блоков и компонентов, тогда он обрабатывается IOTP-приложением или какой-то оконечной системой, такой как платежный сервер.

    4.3.3.3. Переходные технические ошибки

    Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.

    4.3.3.4. Рабочие ошибки блочного уровня

    Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.

    Некоторые рабочие ошибки могут быть переходными, при таких обстоятельствах Покупатель может справиться с ситуацией самостоятельно и успешно завершить транзакцию каким-то способом. Например, если на кредитной карточке покупателя недостаточно денег, он может воспользоваться для покупки другой кредитной карточкой.

    Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.

    4.4. Idempotency, последовательность обработки и поток сообщений

    IOTP-сообщения представляют в действительности комбинацию блоков и компонентов, как это описано в 3.1.1 (Структура сообщений IOTP). В будущем при расширении IOTP разнообразие таких комбинаций еще более расширится. Важно, что многократные приемы/передачи одного и того же запроса изменения состояния имеют тот же результат, как и однократная передача/прием этого запроса. Это называется идемпотентностью. Например, покупатель, оплачивая заказ, желает оплатить его только раз. Большинство сетевых транспортных механизмов имеют определенную вероятность доставки одного сообщения несколько раз или не доставить ни разу, что потребует позднее повторной передачи. С другой стороны, запрос состояния можно повторять и при этом каждый раз должно обрабатываться вновь полученное значение. Правильная реализация IOTP может моделироваться по разному различными процессами.

    4.5. Последовательность обработки для роли сервера

    "Роли сервера" - это любые торговые роли, несовпадающие с ролью Покупателя. Они являются "ролями сервера", так как они обычно получают запросы, которые они должны обработать и посылать на них отклики. Однако Роли сервера могут также инициировать транзакции. Более конкретно роли сервера должны быть способны:

    o

    Инициировать транзакцию (смотри раздел 4.5.1). Это могут быть:

     

    -

    платеж, связанный с транзакцией;

     

    -

    инфраструктурные транзакции.

    o

    Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится:

     

    -

    идентификация, если сообщение принадлежит транзакции, которая была запущена ранее;

     

    -

    обработка сообщений-дубликатов;

     

    -

    генерация переходных ошибок, если сервер, который обрабатывает входные сообщения перегружен;

     

    -

    обработка сообщения, если оно лишено ошибок и авторизовано, и при благоприятном исходе, послать отклик отправителю сообщения.

    o

    Аннулировать текущую транзакцию, если поступил такой запрос (смотри раздел 4.5.3)

    o

    Повторно передать сообщение, если ожидается отклик, который не поступил за определенный период времени (смотри раздел 4.5.4).

    4.5.1. Инициализация транзакций

    Роли сервера могут инициировать большое число различных транзакций. В чатности:

    o

    Транзакцию информационного запроса (смотри раздел 9.2.1);

    o

    Транзакцию Ping (смотри раздел 9.2.2);

    o

    Транзакцию аутентификации (смотри раздел 9.1.6);

    o

    Транзакцию, сопряженную с платежем, такую как:

     

    -

    Депозит (смотри раздел 9.1.7);

     

    -

    Покупка (смотри раздел 9.1.8);

     

    -

    Возврат денег (смотри раздел 9.1.9);

     

    -

    Отзыв сделки (смотри раздел 9.1.10);

     

    -

    Обмен ценностями (смотри раздел 9.1.11).

    4.5.2. Обработка входных сообщений

    Обработка входных сообщений включает в себя:

    o

    проверку структуры и идентификацию сообщения;

    o

    выявление и обработку сообщений-дубликатов;

    o

    обработку недублированных, оригинальных сообщений, которая включает в себя:

    -

    выявление ошибок, и, если они не обнаружены,

    -

    обработку сообщений и, если требуется, выработку откликов.

    4.5.2.1. Проверка структуры и идентификация сообщений

    Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.

    Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.

    Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :

    o

    атрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing,

    o

    содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута.

    Далее получатель вводит компонент Error в блок ошибки с новым компонентом TransactionId с новым IotpTransId и отправляет его отправителю исходного сообщения.

    4.5.2.2. Выявление и обработка дублированных сообщений

    Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны.

    Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].

    Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего.

    Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.

    4.5.2.3. Обработка недублированных сообщений

    Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:

    o

    проверку того, что сервер готов для обработки, если это не так, генерируется переходная ошибка;

    o

    проверку, не находится ли транзакция в режиме ошибки или неаннулирована;

    o

    контроль корректности входного сообщения, который предусматривает:

     

    - проверку глубины ошибки сообщения;

     

    - проверку ошибок блочного уровня;

     

    - проверку любых инкапсулированных данных

    o

    проверку ошибок в последовательности полученных блоков;

    o

    генерацию компонентов ошибки для любых обнаруженных ошибок;

    o

    если никаких серьезных или переходных ошибок не выявлено, производится обработка сообщения и, если требуется, генерация отклика отправителю входного сообщения.

    Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId.

    Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время.

    Некоторые серверы могут оказаться перегруженными из-за неожиданного всплеска загрузки. Данный подход позволяет преодолевать ситуации с кратковременными пиковыми нагрузками, запрашивая отправителя переслать сообщение несколько позже.

    Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной. Предполагается следующий контроль:

    o

    предыдущие посланные или полученные сообщения не содержат серьезных (Hard) ошибок;

    o

    транзакция не была анулирована покупателем или торговой ролью сервера.

    Если это имеет место, сообщение игнорируется. Транзакция с серьезной ошибкой или аннулированная транзакция не может быть перезапущена.

    Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:

    • проверку формат XML;
    • проверку того, что все элементы, атрибуты и содержимое блока ссылок транзакции не содержат ошибок и соответствуют спецификации IOTP;
    • проверку цифровой подписи, которая в свою очередь предполагает:
     

    - проверку того, что корректно вычислена электронная подпись;

     

    - проверку того, что значение дайджеста вычислено правильно.

    Проверка ошибок уровня блоков включает:

    о

    проверку в пределах каждого блока (помимо блока ссылок транзакции) того что:

     

    - атрибуты, элементы и содержимое элементов корректно;

     

    - значения атрибутов, элементы и содержимого элементов не противоречат друг другу в пределах блока.

    о

    проверку того, что комбинации блоков корректны

    o

    проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции.

    Если сообщение содержит какие-то инкапсулированные данные, то, если возможно, они проверяются на наличие ошибок.

    4.5.2.4. Проверка ошибок в последовательности блоков

    Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...".

    Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:

    • Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP.
    • Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка.
    • Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка.
    • Блок отклика аутентификации проверяется следующим образом:
     

    - Если блок отклика аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае.

     

    - Если блок отклика аутентификации не относится к аутентификационному запросу, который был ранее послан, то это серьезная (Hard) ошибка, в противном случае.

     

    - Если блок отклика аутентификации получен в рамках IOTP-транзакции, до того как аутентификация успешно завершилась, то это серьезная (Hard) ошибка.

    о

    Блок состояния аутентификации проверяется следующим образом:

     

    - если блок состояния аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок состояния аутентификации не относится к аутентификационному отклику, который был перед эти послан, тогда это серьезная (Hard) ошибка, в противном случае,

     

    - если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка).

    o

    Блок выбора TPO (только для продавца) прооверяется следующим образом:

     

    - если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.

    o

    Блок запроса платежа (только для кассира) проверяется следующим способом:

     

    - если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае

     

    - если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае

     

    - если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае

     

    - если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.

    o

    Блок платежного обмена (только для кассира) проверяется следжующим образом:

     

    - если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае

     

    - если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).

    o

    Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.

    Если сгенерированы какие-либо компоненты Error, то они должны быть собраны в блок Error для посылки отправителю входного сообщения. Заметим, что блоки Error следует отсылать назад отправителю сообщения и ErrorLogNetLocn для торговой роли отправителя, если это специфицировано.

    Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например:

    o потому что не получен корректный отклик (напр., пароль) на аутентификацию или

    o не удалось произвести оплату, так как нехватает денег на кредитной карточке.

    Обработка входного сообщения, лишенного ошибок

    Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:

    • Информационные запросы на транзакции Ping следует игнорировать;
    • Если входное сообщение содержит блок Error с переходной ошибкой, следует подождать необходимое время и затем повторно послать предыдущее сообщение, если не было получено отклика на сообщение, посланное ранее;
    • Если входное сообщение содержит компонент Error с HardError или блок Cancel, тогда последующая обработка транзакции должна быть остановлена. Это включает в себя блокировку отправки любых текущих сообщений или посылку откликов на любые новые приходящие недублированные сообщения;
    • Обработка инкапсулированных сообщений (напр., сообщения платежного протокола) может вызвать дополнительные переходные ошибки;
    • Цифровая подпись может быть корректно сформирована лишь в случае, если сгенерированы все блоки и компоненты и известно, какие элементы в сообщении должны быть подписаны.

    Если выходное сообщение сгенерировано, оно должно быть запомнено, так чтобы иметь возможность, если потребуется, послать его повторно. Заметим, что выходные сообщения, которые содержат переходные ошибки, не запоминаются, так что они формируются заново, при их повторной посылке.

    4.5.3. Аннулирование транзакции

    Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP. Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:

    • если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,
    • если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,
    • определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру.

    Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать.

    4.5.4. Повторная посылка сообщений

    Сервер должен периодически проводить проверки, нет ли транзакций, ожидающих сообщения-отклики и неполчивших их своевременно. Такая задержка может быть связана со следующими факторами:

    о

    из-за используемого танспортного механизма;

    o

    из-за времени, необходимого для обработки инкапсулированных сообщений (напр., платежных) и

    o

    зависит оттого, нужен или нет ввод со стороны человека.

    Если не получено никакого сообщения, оригинальное сообщение должно быть послано повторно. Это должно производиться некоторое число раз в зависимости от надежности используемого транспортного механизма. Если не получено отклика в течении оговоренного времени, транзакция прерывается по таймауту. В этом случае, состояние транзакции устанавливается равным Failed, и выдается код завершения:

    o

    TimedOutRcvr, если транзакция может быть восстановлена позднее, или

    o

    TimedOutNoRcvr, если транзакция невосстановима.

    4.6. Последовательность обработки для роли клиента

    "Роль клиента" в IOTP является торговой ролью Покупателя.

    Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа.

    В частности Покупатель должен быть способен:

    o

    Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:

     

    - платеж, связанный с транзакцией

     

    - инфраструктурные транзакции.

    o

    Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:

     

    - идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;

     

    - обработка дублированных сообщений;

     

    - генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;

     

    - обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.

    o

    Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).

    o

    Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).

    4.6.1. Операции инициализации

    Роль Покупателя может инициировать большое число различных транзакций. В частности:

    o

    Процедуру запроса (смотри раздел 9.2.1)

    o

    Транзакцию Ping (смотри раздел 9.2.2)

    o

    Процедуру аутентификации (смотри раздел 9.1.6)

    4.6.2. Обработка входных сообщений

    Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4).

    Описание обработки входных сообщений для сервера IOTP включает соображения многопроцессности и многозадачности. Для роли покупателя - в частности при работе на изолированной рабочей системе использование много процессности оставляется на усмотрение разработчика.

    4.6.2.1. Поиск ошибки в последовательности блоков

    Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:

    о

    Блоки Error и Cancel,

    o

    Блоки отклика и информационного запроса,

    o

    Блоки запросов аутентификации, отклика и состояния.

    Для других блоков роль покупателя может получать уведомление об ошибках в порядке прихода блоков и может зависеть от типа блоков. Блоки, где важна последовательность проверки перечислены ниже:

    o

    Блок TPO проверяется следующим образом:

     

    - если входное сообщение содержит блок запроса аутентификации и блок отклика на предложение, то это серьезная (Hard) ошибка, в противном случае,

     

    - если входное сообщение содержит блок запроса аутентификации и статуса аутентификации, то это серьезная (Hard) ошибка, в противном случае,

     

    - если входное сообщение содержит блок запроса аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,

     

    - если входное сообщение содержит блок состояния аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,

     

    - если входное сообщение содержит блок состояния аутентификации, а блок состояния аутентификации послан до сообщения-отклика аутентификации, то это серьезная (Hard) ошибка,

     

    - если входное сообщение содержит блок отклика на предложение и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,

    o

    Блок отклика предложения проверяется следующим образом:

     

    - если блок отклика на предложение является частью брэнд-независимого обмена предложения (смотри раздел 9.1.2.2), тогда никакой проверки последовательности не нужно, так как это первое сообщение, в противном случае,

     

    - если блок отклика на предложение не является частью транзакции IOTP, которая распознана покупателем, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок отклика на предложение не относится к транзакции, где в последнем сообщении послан блок выбора TPO, то это серьезная (Hard) ошибка.

    o

    Блок платежного обмена проверяется следующим образом:

     

    - если блок платежного обмена не относится к транзакции IOTP, которая распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,

     

    - если платежный обмен не относится к транзакции IOTP, где только что послан блок платежного запроса или платежного обмена, то это серьезная (Hard) ошибка.

    o

    Блок платежного отклика проверяется следующим образом:

     

    - если блок платежного отклика не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок платежного отклика не относится к транзакции IOTP, где только что послан блок платежного обмена или блок платежного запроса, то это серьезная (Hard) ошибка.

    o

    Блок отклика доставки проверяется следующим образом:

     

    - если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,

     

    - если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка.

    4.6.3. Аннулирование операции

    Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).

    4.6.4. Повторная передача сообщений

    Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).

    5. Соображения безопасности

    Здесь рассматриваются следующие проблемы:

    o

    определение того, следует ли использовать электронную подпись;

    o

    конфиденциальность данных;

    o

    безопасность платежного протокола.

    5.1. Принятие решения о применении электронной подписи

    Использование электронной подписи в IOTP является исключительно опционным. IOTP может успешно работать вообще без цифровых подписей.

    В конце концов, использовать ли цифровую подпись, решает продавец или другая торговая роль, покупатель же решает обеспечивает ли приемлемый уровень риска вариан без электронной подписи. Если продавцы выяснят, что транзакции без подписей не приемлемы, то они имеют следующий выбор:

    o начать использовать подписи,
    o найти метод работы, где не требуются подписи или,
    o выбрать более низкий объем и стоимость торговых операций.

    Перечень некоторых причин использования цифровых подписей представлен ниже:

    • Продавец (или другая торгвая роль) хочет продемонстрировать, что ему можно верить. Если, например, продавец генерирует подпись отклина-предложения (смотри раздел 7.19.2), используя сертификат, полученный от третей стороны, известной покупателю, тогда покупатель может проверить подпись и сертификат, после чего он сможет с приемлемой достоверностью доверять тому, что предложение получено от означенной организации-продавца. В этом случае подписи используют асимметричную криптографию.
    • Продавец, или другая торгвая роль, хочет сгенерировать запись транзакции, которая подходит для определенной цели. Например, с приемлемой достоверностью цифровые подписи могут быть использованы Покупателем, чтобы определить:

    - будет ли сообщение принято налоговой службой, в качестве корректной записи транзакции;

    - если нужна гарантия, например, от "Better Business Bureau" или подобной организации.

    • Кассир или агент доставки, должен знать, что запрос не видоизменен и авторизован. Например, в IOTP, детали того, сколько нужно платить, посылаются покупателю в предложенпии-отклике и затем переадресуются кассиру в платежном запросе. Если запрос не подписан, покупатель может изменить сумму, например, удалив одну цифру. Если Кассир не имеет доступа к исходной платежной информации отклика-предложения, тогда в отсутствии подписи, кассир не может быть уверен, что данные не были модифицированы. Аналогичго, если платежная информация не подписана цифровым образом, кассир не может быть уверен, кто является продавцом, запросившим этот платеж.
    • Кассир или агент доставки хочет предоставить неопровержимую запись совершения платежной операции или выполнения доставки. Если платежный отклик или отклик доставки подписан, тогда покупатель может позднее использовать запись о платеже или доставке, чтобы доказать, что она состоялась. Это может использоваться, например, для целей обслуживания покупателя.

    Ниже приводится список некоторых причин, почему электронная подпись может не использоваться:

    • Торговые роли иногда объединяются, следовательно изменения данных, выполненные покупателем могут быть обнаружены. Одной из причин использования подписи, это выявление того, что изменения внесены покупателем или другим партнером. Однако, если торговые роли имеют доступ к необходимым данным, то можно провести сравнение, нпример, информацию из платежного запроса и из отклика предложения. Доступ к данным может быть реализован, например, продавцом и кассиром, работающими в одной организации.
    • Стоимость криптографии слишком велика. Например, если платеж составляет всего несколько центов, стоимость выполнения криптографических операций, сопряженных с генерацией и проверкой цифровой подписи делает последнюю экономически не целесообразной.

    5.2. Симметричная и асимметричная криптография

    Преимущество использования симметричных ключей заключается в искдючении инфраструктуры, сопряженной с обслуживанием открытых ключей. В этом случае Продавец, Кассир и Агент доставки должны договориться об использовании общего секретного ключа.

    Однако неудобства симметричной криптографии заключается в том, что покупатель не может надежно идентифицировать Продавца, Кассира и Агента доставки с которыми он имеет дело. Это существенно понижает доверие системе покупателя.

    Однако следует заметить, что даже в случае использования асимметричной криптографии Покупатель не нуждается в цифровых сертификатах, так как целостность транзакции определяется кассиром, проверяющим подпись отклика предложения, скопированную с платежного запроса.

    Заметим, что в одной транзакции может использоваться симметричная, асимметричная криптография или обе ее разновидности.

    5.3. Конфиденциальность данных

    Конфиденциальность информации обеспечивается путем пересылки IOTP-сообщений между торговыми ролями, используя секретный канал, такой как [SSL/TLS]. Использование безопасного канала в IOTP является опционным.

    5.4. Безопасность платежного протокола

    IOTP сконструирован так, чтобы быть нечувствительным к используемому платежному протоколу.

    IOTP способствует безопасности, используя цифровые подписи для установления однозначного соответствия запроса и отклика и для аутентификации отправителя сообщений. Например IOTP связывает вместе: предложение, платеж и доставку.

    6. Цифровые подписи и IOTP

    IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач.

    6.1. Как IOTP использует цифровые подписи?

    В IOTP цифровые подписи используются как:

    • Компоненты IOTP (смотри раздел 7).
    • Подпись содержит дайджест одного или более компонентов или торговых блоков, которые могут также включать в себя другие компоненты подписи в любом сообщении;
    • идентификатор:

     

    - того, какая организация сделала подписи;

     

    - какая организация должна обрабатывать подпись с целью проверки.

    Цифровые сертификаты могут быть связаны с цифровой подписью, если используется асимметричная криптография.Однако если используется симметричная криптография, цифровой сертификат заменяется некоторым идентификатором используемого секретного ключа. Способ, с помощью которого формируются компоненты подписи для одного или нескольких элементов, проиллюстрирован ниже на рис. .10.

    Рис. .10. Дайджесты подписи

    Классическим примером того, как одна цифровая подпись подтверждает другую в IOTP, является случай когда Продавец сначала подписывет предложение, формируя подпись отклика предложения, которое позднее подтверждается кассиром с помощью подписи платежной расписки. Таким путем платеж в транзакции IOTP связывается с предложением продавца.

    Заметим, что один Manifest может соответствовать многим элементам подписи "Value", где каждый элемент значения содержит цифровую подпись того же самого Manifest. Это, в частности, позволяет продавцу согласовать применение различных секретных ключей с кассиром и агентом доставки. Детальные описания компонента подписи содержится в разделе 7.19.

    6.1.1. Пример подписи IOTP

    Пример использования подписи проиллюстрирован ниже на рис. .11, где показано как взаимодействуют различные компоненты и элементы друг с другом.

    Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP.

    Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).

    Рис. .11. Пример использование подписи при покупке

    6.1.2. Элементы OriginatorInfo и RecipientInfo

    Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.

    Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.

    Тип подписи IOTP

    Корректная торговая роль

    OfferResponse

    Продавец

    PaymentResponse

    Кассир

    DeliveryResponse

    Агент доставки

    AuthenticationRequest

    Любая роль

    AuthenticationResponse

    Любая роль

    PingRequest

    Любая роль

    PingResponse

    Любая роль

    Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:

    о

    они имеют отношение к организации, генерировавшей подпись,

    о

    данные, защищенные подписью, не были изменены,

    о

    данные были подписаны корректно

    о

    действия, которые нужно предпринять для продавца авторизованы.

    Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат.

    6.1.3. Использование подписей для подтверждения корректного завершения операций

    Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:

    • для отклика предложения, когда продавец делает предложение Покупателю, котоорое может быть затем послано:

     

    - Кассиру, чтобы проверить, что продавец авторизует платеж;

     

    - Агенту доставки, чтобы проверить, что продавец авторизует доставку.

    • Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:

    - Агенту доставки, в блоке запроса доставки для авторизации доставки вместе с подписью отклика предложения, или

    - другому кассиру во втором платежном запросе, чтобы авторизовать второй платеж в транзакции обмена ценностями.

    • Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо.
    • Отклик доставки. Один метод аутентификации партнера по сделке заключается в посылке запроса аутентификации, где определено, что эта процедура предсматривает использование электронной подписи.
    • Запрос состояния транзакции. Блок отклика информационного запроса может быть снабжен цифровой подписью, чтобы удостоверить аутентичность отклика.
    • Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи.

    6.2. Проверка корректности вычисления подписи

    Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).

    Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:

    • проверка того, что блок подписи присутствует и содержит один или более компонентов подписи;
    • идентификация компонента Organisation, который содержит OrgID-атрибут организации, осуществляющей проверку. Если не найдено ни одного компонента организации или обнаружено более одного такого компонента, фиксируется ошибка;
    • использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять.
    • проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:

     

    - используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем

     

    - если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef;

     

    - если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo;

     

    - используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest;

     

    - проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи.

    6.3. Проверка платежа или доставки

    Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом.

    При этом осуществляются следующие шаги:

    • проверка того, что платежный запрос или запрос доставки посланы правильной организацией;
    • проверка того, что в запросе представлены правильные компоненты IOTP;
    • проверка того, что платеж или доставка авторизованы.

    В данном разделе используются следующие термины:

    • "Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного;
    • "Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11);
    • "Операция" используется в связи с операцией, которая реализуется при получении блока запроса. Операцией может быть платеж или доставка;
    • "Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию;
    • "Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации;
    • "Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции;
    • атрибут ActionOrgRef содержит ссылки элемента, которые могут быть использованы для идентификации "Операционной организации", которая должна выполнить операцию.

    6.3.1. Проверка того, что блок запроса послан правильной организацией

    Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.

    6.3.1.1. Платеж

    Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация. Метод доступа к данным для решения поставленных задач проиллюстрирован на рис. .12.


    Рис. .12. Проверка того, что Кассир может осуществить платеж

    Далее выполняются следующие процедуры:

    • Идентификация платежного компонента (смотри раздел 7.9) в блоке полученного платежного запроса.
    • Идентификация компонентов списка видов платежа и выбора вида платежа для платежного компонента. Это включает в себя:

    - идентификацию компонента списка видов платежей (смотри раздел 7.7), значение его ID-атрибута соответствует атрибуту BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента списка видов платежа, возникает состояние ошибки.

    - идентификацию компонента списка выбора вида платежа (смотри раздел 7.8), где значение его атрибута BrandListRef соответствует BrandListRef платежного компонента. Если не обнаружено ни одного или более одного компонента выбора вида платежа, возникает состояние ошибки.

    • идентификация элементов вида платежа, платежного протокола и суммы в пределах списка видов платежа, который был выбран Покупателем. Это включает:

     

    - Элемен вида платежа (смотри раздел 7.7.1), где значение его Id-атрибута соответствует значениюатрибута BrandRef выбора вида платежа. Если не обнаружено ни одного или более одного элемента вида платежа, возникает состояние ошибки.

     

    - Протокольный элемент суммы (смотри раздел 7.7.3) является элементом, где значение его ID

    атрибута соответствует величине атрибута ProtocolAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного протокольного элемента суммы, возникает состояние ошибки.

     

    - Элемент платежного протокола (смотри раздел 7.7.5) представляет собой элемент, значение Id

    атрибута которого соответствует величине атрибута PayProtocolRef в идентифицированном протокольном элементе суммы. Если не обнаружено ни одного или более одного подходящего элемента платежного протокола суммы, возникает состояние ошибки.

     

    - Элемент валютной суммы (смотри раздел 7.7.4) представляет собой элемент, значение Id

    атрибута которого соответствует величине атрибута CurrencyAmountRef в компоненте выбора вида платежа. Если не обнаружено ни одного или более одного подходящего элемента валютной суммы, возникает состояние ошибки.

    • Проверяется совместимость ссылок в списке видов платежа и компонентов выбора вида платежа:

     

    - проверяется, что ссылка элемента существует в атрибуте ProtocolAmountRefs идентифицированного элемента вида платежа, который соответствует ID-атрибуту идентифицированного элемента суммы. Если не может быть обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.

     

    - проверяется, что атрибут CurrencyAmountRefs идентифицированного элемента суммы, содержит ссылку элемента, которая соответствует ID-атрибуту идентифицированного элемента вылютной суммы. Если не обнаружено ни одной или более одной подходящей ссылки элемента, возникает состояние ошибки.

     

    - проверяется совместимость элементов в списке видов платежа. В частности, элементы выбранного вида платежа, суммы, платежного протокола и валютной суммы являются дочерними элементами идентифицированного компонента списка видов платежа. Если это не так, то это ошибка.

    • Проверяется то, что кассир, который получил блок платежного запроса является кассиром, выбранным покупателем. Это включает в себя:

    - идентификацию компонента Organisation для кассира. Это компонент Organisation, где его ID-атрибут соответствует атрибуту ActionOrgRef в идентифицированном элементе платежного протокола. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки.

    - проверку компонента Organisation, который имеет элемент Trading Role с атрибутом Role кассира. Если его нет, происходит ошибка.

    - наконец, если идентифицированный компонент Organisation не совпадает с полученным в блоке платежного запроса, это вызывает ошибку.

    6.3.1.2. Доставка

    Способ доступа к данным Агента доставки при проверке того, может ли он выполнить доставку показан на рис. .13.

    Start
    |
    v
    Y">Delivery
    Component
    |
    |ActionOrgRef
    |
    v
    Organisation
    Component
    |
    -Trading Role
    Element
    (Delivery Handler)
    Рис. .13. Проверка того, что агент доставки может выполнить доставку

    Процедура включает в себя следующие шаги:

    • Идентификацию компонента Delivery в блоке запроса доставки. Если не обнаружено ни одного или более одного подходящего компонента доставки, возникает состояние ошибки.
    • Использование атрибута ActionOrgRef компонента доставки для идентификации компонента Organisation агента доставки. Если не обнаружено ни одного или более одного подходящего компонента Organisation, возникает состояние ошибки.
    • Если компонент Organisation для Агента доставки не имеет элемента торговой роли с атрибутом Role агента доставки, то это ошибка.
    • Наконец, если организация, которая получила блок запроса доставки не идентифицирует компонент Organisation для агента доставки, то это ошибка.

    6.3.2. Проверка компонентов Correct, присутствующих в блоке запроса

    Далее проверяется то, что в блоке платежного запроса (смотри раздел 8.7) или запроса доставки (смотри раздел 8.10) присутствуют правильные компоненты. Если компоненты отсутствуют, то это ошибка.

    6.3.3. Проверка авторизованности операции

    Предыдущие шаги идентифицировали операционную организацию и проверяли наличие всех необходимых компонент. На данном этапе проверяется, что операционная организация авторизована для выполнения данной процедуры.

    Операционная организация идентифицирует Продавца, проверяет, что с ним имеется соглашение, которое допускает выполнение операции, и что любые ограничения этого соглашения выполнены, тогда, если требуются подписи, проверяется, что они подтверждают корректные данные. Эти шаги включают в себя:

    • идентификацию Продавца. Это компонент Organisation с элементом торовой роли, который имеет атрибут Role со значением Продавец. Если не обнаружено ни одного или более одного подходящего элемента торговой роли, возникает состояние ошибки.
    • проверку наличия соглашений операционных организаций с Продавцом, позволяющих выполнение операции. Чтобы решить эту задачу операционная организация должна проверить, что:

     

    - Продавец известен и существует соглашение с операционной организацией (кассиром или агентом доставки);

     

    - им разрешено участвовать в IOTP-транзакции данного типа. Например кассир может согласиться принимать платежи в рамках операций продажи, но не не обслуживать денежные возвраты;

     

    - любые ограничения в их соглашении с продавцом выполнены, например, требуется ли подпись отклика предложения.

    • Проверка корректности подписей. Если подписи необходимы, они должны быть проверены. Это подразумевает:

    - идентификацию и проверку подписей. Это включает операционную организацию, идентифицирующую компоненты подписи, которые содержат ссылки на операционную организацию (смотри 6.3.1). В зависимости от выполняемой IOTP

    транзакции (смотри раздел 9) может идентифицироваться одна или две подписи;

    - проверку того, что компоненты подписи корректны. Это включает проверку того, что существуют элементы дайджеста в элементе Manifest, который относится к обязательным торговым компонентам (смотри раздел 6.3.3.1).

    6.3.3.1. Проверка корректности дайджестов подписи

    Все компоненты Signature, содержащиеся в IOTP-сообщении должны включать элементы Digest, которые относятся к:

    • Id компоненту транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит компонент подписи. Это связывает глобально уникальный IotpTransId с другими компонентами, которые определяют транзакцию IOTP;
    • блоку ссылок транзакции (смотри раздел 3.3) первого сообщения IOTP, которое содержит подпись. Это связывает IotpTransId с информацией о сообщении IOTP, содержащемся в Id-компоненте сообщения (смотри раздел 3.3.2).

    Необходима проверка того, что каждый компонент подписи содержит элементы дайджеста, которые относятся к корректным данным.

    Элементы Digest, которые должны присутствовать, зависят от торговой роли организации, генерирующей цифровую подпись:

    • если подписант является продавцом, тогда:

     

    - элементы дайджеста должны присутствовать во всех компонентах блока запроса, вне зависимости от компонента выбора вида платежа, который является опционным;

    • если подписантом, формирующим цифровую подпись, является кассир, тогда элементы дайджеста должны присутствовать для:

     

    - компонента подписи, сформированной продавцом и, опционно

     

    - один или более компонентов подписи, сформированной предыдущим Кксиром в транзакции.

    7. Торговые компоненты

    Далее рассматриваются торговые компоненты, используемые в IOTP. Торговые компоненты являются дочерними XML-элементами, что показано на диаграмме рис. .14.

    Рис. .14. Торговые компоненты

    Перечень торговых компонентов представлен ниже в порядке их вероятности использования:

    • Компонент протокольных опций
    • Компонент запроса аутентификации
    • Компонент отклика аутентификации
    • Компонент запроса информации о торговой роли
    • Компонент заказа
    • Компонент организации
    • Компонент списка видов платежа
    • Компонент выбора вида платежа
    • Компонент платежа
    • Компонент схема платежа
    • Компонент платежная расписка
    • Компонент доставки
    • Компонент данных доставки
    • Компонент накладной
    • Компонент подписи
    • Компонент сертификата
    • Компонент ошибки

    Заметим, что следующие компоненты в других секциях этой спецификации:

    • Id-компонент транзакции (смотри раздел 3.3.1)
    • Id-компонент сообщения (смотри раздел 3.3.2)

    7.1. Компонент протокольных опций

    Опции протокола представляют собой опции, которые работают с транзакциями IOTP в целом. Определение компонента протокольных опций представлено ниже.

    <!ELEMENT ProtocolOptions EMPTY >
    <!ATTLIST ProtocolOptions ID ID #REQUIRED
    xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED
    SenderNetLocn CDATA #IMPLIEDSecureSenderNetLocn CDATA #IMPLIED
    SuccessNetLocn CDATA #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, которыйоднозначно идентифицирует компонент протокольных опций в транзакции IOTP.

    Xml:lang

    Определяет язык, используемый атрибутами или дочерними элементами в пределах компонента, если значение не переписано атрибутом xml:lang дочернего элемента.

    ShortDesc

    Этот атрибут содержит краткое описание транзакции IOTP на языке, заданном xml:lang. Его целью является объяснение того, какая транзакция осуществляется партнерами.

    Этот компонент используется для облегчения выбора транзакции из списка подобных, например из базы данных транзакций IOTP, которые были запомнены Покупателем, Продавцом и т.д..

    SenderNetLocn

    Содержит небезопасные сетевые позиции отправителя блока TPO, в котором содержится компонент протокольных опций.

    Это сетевая позиция, куда получатель блока TPO должен послать блок выбора TPO, если это требуется. Содержимое атрибута зависит от транспортного механизма.

    SecureSenderNetLocn

    Содержит безопасный сетевой узел отправителя блока TPO, в котором содержится компонент протокольных опций.

    Содержимое этого атрибута зависит от транспортного механизма.

    SuccessNetLocn

    Содержит сетевую позицию, которая должна быть отображена после успешного завершения транзакции.

    Содержимое этого аптрибута зависит от транспортного механизма. Должен присутствовать либо SenderNetLocn, либо SecureSenderNetLocn или оба эти атрибута.

    7.2. Компонент запроса аутентификации

    Этот торговый компонент содержит параметр данных, которые используются при аутентификации одной торговой роли у другой. Его определение представлено ниже.

    <!ELEMENT AuthReq (Algorithm, PackagedContent*)>
    <!ATTLIST AuthReq ID ID #REQUIRED
    AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>

    Если требуется, алгоритм может использовать данные вызова, содержащиеся в элементах Packaged Content из компонента запроса аутентификации. Формат Packaged Content является зависимым от алгоритма.

    Атрибуты:

    ID

    Идентификатор, который однозначно идентифицирует компонент запроса аутентификации для данной транзакции IOTP.

    AuthenticationId

    Идентификатор, специфицированный аутентификатором, который, если прислан организацией, которая получает запрос, позволит аутентификатору определить, какая аутентификационная процедура требуется.

    ContentSoftwareId

    Смотри раздел 14. Словарь

    Cодержимое:

    PackagedContent

    Содержит данные вызова в виде одного или более элементах Packaged Content (смотри раздел 3.7), на которые следует рееагировать, используя алгоритм, опреденный элементом Algorithm.

    Algorithm

    Содержит информацию, которая описывает алгоритм (смотри 7.19. Компоненты подписи), который должен быть использован для генерации отклика аутентификации.

    Алгоритмы, которые могут использоваться, идентифицированы атрибутом Name элемента Algorithm.

    7.3. Компонент отклика аутентификации

    Компонент отклика аутентификации содержит результаты аутентификационного запроса. Используется алгоритм, содержащийся в компоненте запроса аутентификации (смотри раздел 7.2) и выборанный из блока запроса аутентификации (смотри раздел 8.4).

    В зависимости от выбранного алгоритма, результаты его применения будут содержаться в компоненте подписи, которая подтверждает отклик аутентификации, или в элементах Packaged Content компонента отклика аутентификации. Его определение представлено ниже.

    <!ELEMENT AuthResp (PackagedContent*) >
    <!ATTLIST AuthResp ID ID #REQUIRED
    AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
    ContentSoftwareId CDATA #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который для данной транзакции однозначно определяет компонент отклика аутентификации.

    AuthenticationId

    Идентификатор аутентификации, специфицированный аутентификатором, который был включен компонент запроса (смотри раздел 7.2). Это позволяет аутентификатору идентифицировать метод аутентификации.

    SelectedAlgorithmRef

    Ссылка элемента, которая определяет элемент алгоритма, сипользуемого для формирования отклика аутентификации.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Может содержать отклик, сформированный в качестве результата применения алгоритма, выбранного из компонента запроса аутентификации, смотри раздел 7.2.

    Например, для заданной схемы платежа он может содержать данные, зависящие от этой схемы.

    7.4. Компонент запроса информации торговой роли

    Этот торговый компонент содержит список торговых ролей (смотри раздел 2.1), информация для которых запрошена. Результатом запроса торговой роли является набор компонентов Organisation (смотри раздел 7.6), которые описывают каждую из запрошенных торговых ролей. Его определение приведено ниже.

    <!ELEMENT TradingRoleInfoReq EMPTY>
    <!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
    TradingRoleList NMTOKENS #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент информационного запроса для торговой роли в рамках транзакции IOTP.

    TradingRoleList

    Содержит список из одной или более торговых ролей (смотри атрибут TradingRole элемента Trading Role - раздел 7.6.2), для которых была запрошена информация.

    7.5. Компонент заказа

    Компонент Order содержит информацию о заказе. Его определение представлено ниже.

    <!ELEMENT Order (PackagedContent*) >
    <!ATTLIST Order ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    OrderIdentifier CDATA #REQUIRED

    ShortDesc CDATA #REQUIRED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    ApplicableLaw CDATA #REQUIRED

    ContentSoftwareId CDATA #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент Order в пределах текущей транзакции IOTP.

    xml:lang

    Определяет язык, использованный атрибутами или дочерними элементами в пределах компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.

    OrderIdentifier

    Это код, число или другой идентификатор, который автор заказа может использовать для идентификации заказа. В пределах транзакции он должен быть уникальным. Если он используется так, то нет нужды специфицировать содержимое элемента заказа, так как имеется ссылка на нужную информацию в базе данных.

    ShortDesc

    Краткое описание заказа на языке, определенном атрибутом xml:lang. Оно используется для упрощения выбора индивидуального заказа из списка, например, из базы данных заказов, записанных туда продавцом, покупателем и т.д..

    OkFrom

    Дата и время в формате [UTC], после которого предложение, сделанное Продавцом теряет силу.

    OkTo

    Дата и время в формате [UTC], до которого получатель может воспринимать предложение продавца не имеющим силу.

    ApplicableLaw

    Фраза на языке, определенном атрибутом xml:lang, которая описывает штат или страну, юристдикция которой будет использована при разрешении конфликтов и споров.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Опционное описание заказа в виде одного или более элементов Packaged Content (смотри раздел 3.7).

    7.5.1. Содержимое описания заказа

    Элемент Packaged Content будет в норме необходим, однако он может быть опущен там, где достаточная информация о покупке может быть получена из атрибута ShortDesc. Если необходимо полное описание заказа, могут использоваться несколько элементов Packaged Content.

    Хотя сумма и валюта вероятно присутствуют в элементах Packaged Content описания заказа, они содержатся в торговых компонентах, связанных с платежом (список видов платежа, выбор вида платежа и платеж). Это означает, что важно, чтобы сумма, которая действительно дожна быть уплачена, была четко отображена для Покупателя.

    Для совместимости разные реализации должны поддерживать как минимум Plain Text, HTML и XML, что облегчит отображение.

    7.5.2. Временные метки OkFrom и OkTo

    Заметим, что:

    • Дата OkFrom может быть позже чем дата OkFrom компонента Payment (смотри раздел 7.9), связанного с этим заказом, и
    • аналогично, дата OkTo может быть раньше чем дата OkTo компонента Payment (смотри раздел 7.9).

    Продавец в контексте Интернет-коммерции в исходный момент с анонимными покупателями выявляет условия предложения на WEB-странице. Для того чтобы получить товар или услуги покупатель должен согласиться с этими условиями.

    Если предложение ограничено временными рамками, рекомендуется, чтобы продавцы взаимодействовали с покупателями и сообщали им условия заказа в понятной для них форме:

    • предложение ограничено по времени;
    • временные метки OkFrom и OkTo специфицируют время действия предложения;
    • часы, напр., часы продавца, будут использоваться для определения действия предложения.

    Заметим также, что даты OkFrom и OkTo могут также присутствовать в элементах Packaged Content описания заказа, эти даты содержатся в компоненте Order. Важно, чтобы даты OkFrom и OkTo использовались в формате, приемлемом для покупателя.

    7.6. Компонент Organisation

    Компонент Organisation предоставляет информацию об индивидууме или организации. Он может быть использован для различных целей, например:

    • описать продавца, который продает товары,
    • идентифицировать того, кто осуществляет покупку,
    • идентифицировать того, кто будет доставлять товары,
    • обеспечивать облуживание покупателя,
    • описать того, кто будет Кассиром.

    Заметим, что компоненты Organisation, которые должны присутствовать в сообщении IOTP, зависят от выполняемой транзакции. Смотри раздел 9.

    Ниже представлено определение компонента.

    <!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
    <!ATTLIST Org ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    OrgId CDATA #REQUIRED

    LegalName CDATA #IMPLIED

    ShortDesc CDATA #IMPLIED

    LogoNetLocn CDATA #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент Organisation в пределах текущей транзакции IOTP.

    xml:lang

    Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не было изменено с помощью атрибута xml:lang дочернего элемента. Смотри раздел 3.8.

    OrgId

    Код, который идентифицирует организацию, описанную компонентом Organisation. Смотри 7.6.1.

    LegalName

    Для организаций, которые являются коммерческими компаниями, это их легальное название на языке, определенном атрибутом xml:lang. Это необходимо для организаций, чьими торговыми ролями не являются Покупатель или DelivTo.

    ShortDesc

    Краткое описание организации на языке, определенном атрибутом xml:lang. Это обычно имя, под которым известна организация. Например, если легальное название было "Blue Meadows Financial Services Inc.", тогда его короткое имя может быть "Blue Meadows".

    Атрибут используется для упрощения выбора отдельной организации из списка, например из базы данных организаций, вовлеченных в транзакции, которая записана Покупателем.

    LogoNetLocn

    Сетевая позиция, которая может быть использована для загрузки логотипа организации.

    Смотри раздел 10. Содержимое этого атрибута должно соответствовать [RFC1738].

    Cодержимое:

    TradingRole

    Смотри 7.6.2. Элемент торговой роли.

    ContactInfo

    Смотри 7.6.3. Элемент контактной информации.

    PersonName

    Смотри 7.6.4. Персональное имя.

    PostalAddress

    Смотри 7.6.5. Почтовый адрес.

    7.6.1. ID организаций

    ID организаций используются одной из торговых ролей для идентификации торговой роли. Для того чтобы избежать путаницы, это означает, что эти ID должны быть глобально уникальными. На практике это достигается следующим образом:

    • Id организации для всех торговых ролей, за исключением торговой роли Покупателя, используют имена доменов, так как они уникальны по определению,
    • Id организации для торговой роли покупателя выделяется одной из прочих торговых ролей в транзакции и делается уникальным путем присоединения его к другим Id организаций,
    • если покупателю выделено Id организации для данной транзакции, это же Id используется всеми другими торговыми ролями в рамках этой транзакции для идентификации покупателя.

    В частности, содержимое ID организации определяется следующим образом:

    OrgId ::= NonConsumerOrgId | ConsumerOrgId
    NonConsumerOrgId ::= DomainName
    ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
    ConsumerOrgIdPrefix ::= "Consumer:"
    ConsumerOrgIdID организации покупателя состоит из:

    • стандартного префикса, чтобы идентифицировать то, что это организация покупатель. Далее следует
    • один или более символов, которые согласуются с определением "namechar" XML. Смотри спецификации [XML]. За ними следует
    • NonConsumerOrgId организации, которая выдала ConsumerOrgId. Обычно это продавец. Применение символов в верхнем или нижнем регистре не играет роли.

    NonConsumerOrgId

    Если роль не соответствует покупателю, тогда здесь содержится каноническое имя этой организации. Смотри [DNS], за которым опционно следуют дополнительные символы, если требуется сделать NonConsumerOrgId уникальным.

    Заметим, что NonConsumerOrgId не может начинаться с ConsumerOrgIdPrefix. Допускается использование строчных и прописных символов. Ниже приведены примеры Id организации:

    • newjerseybooks.comid организации-продавца;
    • westernbank.co.ukid организации-кассира;
    • consumer:1000247ABH/newjerseybooks.comid организации-покупателя выданный продавцом.

    7.6.2. Элемент торговая роль

    Этот элемент идентифицирует торговую роль человека или организации в данной транзакции IOTP. Заметим, что организация может иметь более чем одну торговую роль и несколько ролей может присутствовать в одном элементе Organisation. Определение элемента представлено ниже:

    <!ELEMENT TradingRole EMPTY >
    <!ATTLIST TradingRole ID ID #REQUIRED

    TradingRole NMTOKEN #REQUIRED

    IotpMsgIdPrefix NMTOKEN #REQUIRED

    CancelNetLocn CDATA #IMPLIED

    ErrorNetLocn CDATA #IMPLIED

    ErrorLogNetLocn CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет элемент торговая роль в пределах текущей транзакции IOTP.

    TradingRole

    Торговая роль организации. Возможные значения:
    o Покупатель. Лицо или организация, которая действует в роли покупателя в данной транзакции.
    o Продавец. Лицо или организация, которая действует в роли продавца в данной транзакции.
    o Агент доставки. Лицо или организация, которая доставляет товар или предоставляет услуги в рамках данной транзакции;
    o DelivTo. Лицо или организация, которая получает товары или услуги в рамках данной транзакции.
    o CustCare. Лицо или организация, которая обеспечивает обслуживание покупателя в данной транзакции.

    IotpMsgIdPrefix

    Содержит префикс, который должен быть использован для всех IOTP сообщений, посланных торговой ролью в данной транзакции. Значения, которые следует использовать определены в 3.4.1.

    CancelNetLocn

    Содержит сетевую позицию, куда покупатель должен обратиться, если он аннулирует транзакцию по какой-либо причине. Атрибут может быть использован торговой ролью для отправки отклика, который более соответствует обстоятельствам конкретной транзакции.

    Этот атрибут:

    • не должен присутствовать, когда TradingRole усановлено равным роли Покупателя или DelivTo,
    • должен присутствовать, когда TradingRole = Продавец, Кассир или Агент доставки.

    Содержимое этого атрибута зависит от транспортного механизма.

    ErrorNetLocn

    Содержит сетевую позицию, которая должна отображаться Покупателем, после того как он получил или сгенерировал блок Error, содержащий компонент Error с атрибутом Severity равным:

    • HardError,
    • Предупреждение, но Покупатель решает не продолжать транзакцию.
    • TransientError и транзакция прерывается по таймауту.

    Этот атрибут:

    • не должен присутствовать, когда TradingRole равно Покупатель или DelivTo,
    • должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

    Содержимое атрибута зависит от транспортного механизма.

    ErrorLogNetLocn

    Опционно. Содержит сетевую позицию, куда Покупателю следует посылать IOTP сообщения, которые содержат блоки Error с компонентами Error сатрибутом Severity равным:

    • HardError,
    • Предупреждение, но Покупатель решает не продолжать транзакцию,
    • TransientError и транзакция прерывается по таймауту.

    Этот атрибут:

    • не должен присутствовать, когда TradingRole = Покупатель,
    • должен присутствовать, когда TradingRole равно Продавец, Кассир или Агент доставки.

    Содержимое этого атрибута зависит от транспортного механизма.

    Атрибут ErrorLogNetLocn может использоваться для посылки сообщений об ошибках программной компании или другой оргаанизации, ответственной за решение проблем с программами, которые посылают входные сообщения. Смотри раздел 7.21.1.

    7.6.3. Элемент контактной информации

    Этот элемент содержит информацию, которая может быть использована для контакта с организацией или частным лицом. Все атрибуты являются опционными, однако по крайней мере один из элементов контактной информации должен присутствовать. Его определения представлено ниже.

    <!ELEMENT ContactInfo EMPTY >

    <!ATTLIST ContactInfo xml:lang

    NMTOKEN #IMPLIED

    Tel CDATA #IMPLIED

    Fax CDATA #IMPLIED

    Email CDATA #IMPLIED

    NetLocn CDATA #IMPLIED >

    Атрибуты:

    xml:lang

    Определяет язык данного элемента. Смотри раздел 3.8.

    Tel

    Телефонный номер, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.

    Fax

    Номер факса, по которому можно контактировать с организацией. Заметим, что это текстовое поле и проверок корректности содержимого не производится.

    Email

    Адрес электронной почты, по которому можно контактировать с организацией. Заметим, что поле должно следовать регламентациям для адресных спецификаций, содержащимся в [RFC822].

    NetLocn

    Адрес Интернет, по которому можно найти информацию об организации, используя WEB-броузер.

    Содержимое этого атрибута должно согласовываться с документом [RFC1738].

    7.6.4. Элемент личного имени

    Этот элемент содержит имя частного лица. Все поля являются опционными, однако GivenName (имя) или FamilyName (фамилия) должны присутствоать. Его опредление представлено ниже.

    <!ELEMENT PersonName EMPTY >

    <!ATTLIST PersonName xml:lang

    NMTOKEN #IMPLIED

    Title CDATA #IMPLIED

    GivenName CDATA #IMPLIED

    Initials CDATA #IMPLIED

    FamilyName CDATA #IMPLIED >

    Атрибуты:

    xml:lang

    Определяет язык с помощью атрибута внутри элемента. Смотри раздел 3.8.

    Title

    Отличительное имя; личное прозвище, наследственное или нет, должность (напр., судья, мэр), дворянское звание (напр., герцог, герцогиня, граф), или используемое при обращение к человеку (напр., Mr, Mrs, Miss, товарищ, господин)

    GivenName

    Имя, под которым человек известен в семье, друзьям или знакомым (имя или фамилия).

    Initials

    Первая буква второго имени (отчества), под которым человек известен в своей семье, друзьям или знакомым.

    FamilyName

    Фамилия. Это обычно часть персонального имени, которая передается по наследству от родителей к детям.

    7.6.5. Элемен почтового адреса

    Этот элемент содержит адрес, который может быть использован, например, для физической доставки товаров, услуг или писем. Его определение предлагается ниже.

    <!ELEMENT PostalAddress EMPTY >

    <!ATTLIST PostalAddress xml:lang

    NMTOKEN #IMPLIED

    AddressLine1 CDATA #IMPLIED

    AddressLine2 CDATA #IMPLIED

    CityOrTown CDATA #IMPLIED

    StateOrRegion CDATA #IMPLIED

    PostalCode CDATA #IMPLIED

    Country CDATA #IMPLIED

    LegalLocation (True | False) 'False' >

    Атрибуты:

    xml:lang

    Определяет язык, используемый атрибутами в этом элементе. Смотри раздел 3.8.

    AddressLine1

    Первая строка почтового адреса, напр.,"The Meadows"

    AddressLine2

    Вторая строка почтового адреса. напр.,"Sandy Lane"

    CityOrTown

    Город в адресе, напр.,"Москва"

    StateOrRegion

    Штат или область в пределах страны, где находится город, напр., "Зюзино"

    PostalCode

    Код, известный как, например почтовый код или zip-код, который обычно используется почтовыми организациями для организации эффективной доставки, напр.,"113303"

    Country

    Страна адреса, напр.,"RU"

    LegalLocation

    Идентифицирует, является ли адрес зарегистрированным адресом организации. По крайней мере один адрес организации должен соответствовать значению "истина" в противном случае торговой ролью является Покупатель или DeliverTo.

    7.7. Компонент списка видов платежей

    Компоненты списка видов платежа содержатся в блоке опций торгового протокола (смотри раздел 8.1) транзакции IOTP. Они содержат список:

    • виды платежа (смотри также раздел 11.1),
    • суммы, которые должны быть заплачены в валюте, которую выбрал или предложил Продавец,
    • платежные протоколы, которые могут использоваться для реализации заданного вида платежа,
    • сетевые позиции Кассиров, которые воспринимают платеж в рамках платежного протокола.

    Определение компонента списка видов платежа представлено ниже.

    <!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>

    <!ATTLIST BrandList ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIREDShortDesc CDATA #REQUIRED

    PayDirection (Debit | Credit) #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент списка видов платежа транзакции IOTP.

    xml:lang

    Определяет язык, использованный атрибутами или дочерними элементами в пределах данного компонента, если только его значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.

    ShortDesc

    Текстовое описание на языке, заданном атрибутом xml:Lang, характеризующее цели списка видов платежа. Эта информация должна быть отображена у получателя списка видов платежа для того чтобы помочь сделать правильный выбор. Это привлекательно, так как позволяет Покупателю выяснить цели предлагаемого списка видов платежа, если транзакция предполагает несколько платежей.

    PayDirection

    Индицирует направление платежа для выбранного вида. Возможные значения:

    • Дебит. Отправитель блока платежного запроса (напр., покупатель), к которому имеет отношение список видов платежа, произведет платеж кассиру.
    • Кредит. Отправитель блока платежного запроса к которому имеет отношение список видов платежа, получит платеж от кассира.

    Cодержимое:

    Brand

    Описывает вид платежа (Brand). Последовательность элементов Brand (смотри раздел 7.7.1) в списке видов плптежа не определяет каких-либо преоритетов. Рекомендуется, чтобы программа, которая обрабатывает этот список видов платежа представляла их в порядке предпочтения получателя.

    ProtocolAmount

    Это связывает конкретный вид платежа с:

    • видами валюты и суммами в элементах CurrencyAmount, которые могут использоватьсясовместно с видами платежа, и
    • Платежными протоколами и Кассирами, которые могут использоваться с этими видами валюты и суммами для конкретного вида платежа.

    CurrencyAmount

    Содержит код валюты и сумму платежа;

    PayProtocol

    Содержит информацию о платежном протоколе и Кассире, которые могут использовать данный вид платежа.

    Отношения между элементами, которые образуют содержание списка видов платежа проиллюстрированы на рис. .15.


    Рис. .15. Отношения элементов списка видов платежа

    Примеры списков видов платежа содержатся в главе 11.2.

    7.7.1. Элемент Brand

    Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit.

    <!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >

    xml:lang NMTOKEN #IMPLIED

    BrandId CDATA #REQUIRED

    BrandName CDATA #REQUIRED

    BrandLogoNetLocn CDATA #REQUIRED

    BrandNarrative CDATA #IMPLIED

    ProtocolAmountRefs IDREFS #REQUIRED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор элемента, относящийся потенциально к компоненту выбора вида платежа (Brand Selection), содержащегося в последнем сообщении платежного запроса, и однозначно идентифицирующий элемент Brand данной транзакции.

    xml:lang

    Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.

    BrandId

    Содержит уникальный идентификатор для вида платежа. Он используется для установления соответствия со списком платежных инструментов, которыми располагает Покупатель, чтобы определить, может ли он обеспечить платеж данного вида.

    Так как значения BrandId управляются процедурами IANA, допускается определение значений самим пользователем.

    BrandName

    Содержит название вида платежа, например MasterCard. Это описание вида платежа, которое отображается для Покупателя на понятном для него языке, заданном атрибутом xml:lang. Например, это может быть "American Airlines Advantage Visa". Заметим, что этот атрибут не используется для установления соответствия с инструментами платежа, которыми располагает Покупатель.

    BrandLogoNetLocn

    Сетевая позиция, которая может быть использована для загрузки логотипа организации. Смотри раздел "Получение логотипа" (раздел 10).

    Содержимое этого атрибута должно соответствовать документу [RFC1738].

    BrandNarrative

    Этот опционный атрибут предназначен для использования Продавцом для индикации специальных условий или выгод, которрые будут действовать, если Покупатель выбкерет определенный вид платежа. Например "5% скидка", "бесплатная доставка", "бесплатная гарантия на один год", и т.д..

    ProtocolAmountRefs

    Идентифицирует протоколы и связанные с ними виды валюты и суммы, которые могут использоваться при данном виде платежа. Специфицируется как список ID протокольных колличественных элементов (смотри раздел 7.7.3), содержащихся в списке видов платежа.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    ProtocolBrand

    Протокольные элементы вида платежа, которые содержат информацию о виде платежа, используемого с определенным платежным протоколом (смотри раздел 7.7.2)

    PackagedContent

    Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о виде платежа, который может использоваться платежным протоколом. Содержимое этой информации определяется в приложении для платежных протоколов, где описывается, как работает платежный протокол с IOTP.

    Пример элементов вида платежа имеется в разделе 11.2.

    7.7.2. Элемент протокола вида платежа

    Элемент протокола вида платежа содержит информацию, которая является специфической для применения определенного протокола к некоторому виду платежей. Его определение предложено ниже.

    <!ELEMENT ProtocolBrand (PackagedContent*) >

    <!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED

    ProtocolBrandId CDATA #REQUIRED >

    Атрибуты:

    ProtocolId

    Должен согласовываться со значением атрибута ProtocolId в элементе платежного протокола (смотри раздел 7.7.5).

    Значения ProtocolId должно быть уникальным в пределах элемента Brand, в противном случае происходит ошибка.

    ProtocolBrandId

    Это идентификатор вида платежа, который должен использоваться с конкретным платежным протоколом. Например, SET и EMV имеют свои определенные, различные значения для Brand Id, для каждого из протоколов.

    Корректные значения этого атрибута описаны в приложении для платежных протоколов, идентифицированных ProtocolId, которые определяют, как платежный протокол работает с IOTP.

    Cодержимое:

    PackagedContent

    Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе и/или виде платежа, которые может использовать платежный протокол. Содержимое этой информации определяется в приложении для платежных протоколов.

    7.7.3. Элемент Protocol Amount

    Элемент Protocol Amount связывает вид платежа с:

    • видом валюты и суммами в элементах Currency Amount (смотри раздел 7.7.4), которые могут использоваться с данным видом платежа, и
    • платежными протоколами и Кассирами, определенными в элементе платежного протокола (смотри раздел 7.7.5), котоый может быть использован для этого видв валюты и сумм платежа.

    Его определение представлено ниже:

    <!ELEMENT ProtocolAmount (PackagedContent*) >
    <!ATTLIST ProtocolAmount ID ID #REQUIRED
    PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
    ContentSoftwareId CDATA #IMPLIED >

    Атрибуты:

    ID

    идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора видов платежа, содержащийся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Protocol Amount для данной транзакции IOTP.

    PayProtocolRef

    Содержит ссылку элемента (смотри раздел 3.5), которая указывает на элемент платежного протокола (смотри раздел 7.7.5), содержащийплатежный протокол и Кассира, которые могут использоваться для данного вида платежа.

    CurrencyAmountRefs

    Содержит список ссылок элемента (смотри раздел 3.5), который указывает на элемент Currency Amount (смотри раздел 7.7.4), описывающий вид валюты и сумму, которые могут использоваться для данного вида платежа.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протокольной сумме, которая может использоваться платежным протоколом. Содержимое этой информации определено в приложении для платежных протоколов.

    Примеры элементов Protocol Amount приведены в секции 11.2.

    7.7.4. Элемент валютной суммы

    Элемент валютной суммы содержит в себе:

    • код валюты (и ее тип),
    • сумму.

    Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:

    <!ELEMENT CurrencyAmount EMPTY >
    <!ATTLIST CurrencyAmount ID ID #REQUIRED
    >Amount CDATA #REQUIREDCurrCodeType NMTOKEN 'ISO4217-A'
    CurrCode CDATA #REQUIRED >

    Атрибуты:

    ID

    Идентификатор элемента, (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Currency Amount данной транзакции IOTP.

    Amount

    Указывает сумму, которая должна быть заплачена. Например $245.35 будет выражено как "245.35". Заметим, что значения меньше наименьшей целой величины вполне допустима. Например одна десятая цента будет записана как "0.001".

    CurrCodeType

    Указывает CurrCode области. Этот атрибут включен с тем, чтобы была возможность поддержания нестандартных "валют" например "торговых марок" и т.д.. Атрибут может принимать значения:

    • ISO4217-A (по умолчанию) указывает код валюты с помощью трех буквенных символов, которые должны согласовываться с [ISO 4217]
    • IOTP указывает, что значения CurrCode управляются процедурой, описанной в разделе 12.

    CurrCode

    Код, идентифицирующий валюту, которая должна использоваться при платеже. Область корректных кодов валюты определена атрибутом CurrCodeType.

    Так как значения CurrCodeType управляются процедурой, описанной в секции 12, допускается определение пользователем собственных значений CurrCodeType. Примеры элементов Currency Amount представлены в разделе 11.2.

    7.7.5. Элемент платежного протокола

    Элемент платежного протокола специфицирует детали для платежного протокола и для Кассира, которые могут использоваться для жанного видв платежа. Один или более таких элементов содержится в каждом списке видов платежа.

    <!ELEMENT PayProtocol (PackagedContent*) >
    <!ATTLIST PayProtocol ID ID #REQUIRED

    xml:lang NMTOKEN #IMPLIED

    ProtocolId NMTOKEN #REQUIRED

    ProtocolName CDATA #REQUIRED

    ActionOrgRef NMTOKEN #REQUIRED

    PayReqNetLocn CDATA #IMPLIED

    SecPayReqNetLocn CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора вида платежа (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент PayProtocol данной транзакции IOTP.

    xml:lang

    Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8.

    ProtocolId

    Состоит из имени протокола и версии, например "SETv1.0".

    Значения ProtocolId определены схемой/методом платежа владельцев в документе, который описывает, как инкапсулировать платежный протокол в IOTP.

    ProtocolName

    Описание платежного протокола и его версии на языке, идентифицированном атрибутом xml:lang. Например "Secure Electronic Transaction Version 1.0". Его целью является помочь, если требуется, в предоставлении информации об используемом платежном протоколе.

    ActionOrgRef

    Ссылка элемента (смотри раздел 3.5) на компонент Organisation для Кассира при данном платежном протоколе.

    PayReqNetLocn

    Сетевая позиция, указывающая куда следует послать платежный запрос в отсутствии гарантии безопасности при заданном протоколе.

    Содержимое этого атрибута зависит от транспортного механизма (и должно быть согласованос документом [RFC1738].

    SecPayReqNetLocn

    Сетевая позиция, указывающая куда следует послать платежный запрос в условиях гарантии безопасности при заданном протоколе. Безопасный платеж предполагает для коммуникации с кассиром использование безопасного канала, такого как [SSL/TLS].

    Содержимое этого атрибута должно согласовываться с регламентациями документа [RFC1738]. Смотри раздел 3.9.

    ContentSoftwareIdСмотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе, который используется платежным протоколом. Содержание этой информации определяется в приложении для платежных ппротоколов.

    Примеры элементов платежного протокола содержатся в разделе 11.2.

    7.8. Компонент выбора вида платежа

    Компонент выбора вида платежа идентифицирует выбор вида платежа, платежный протокол и кассира. Этот элемент используется:

    • в сообщениях платежных запросов в транзакциях покупки и обмена ценностями для идентификации вида платежа, протокола и кассира;
    • чтобы опционно проинформировать продавца об используемом виде платежа с целью возможной последующей коррекции предложения и заказа.

    В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам.

    Определение компонента выбора вида платежа представлено ниже.

    <!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?,

    BrandSelCurrencyAmountInfo?) >

    <!ATTLIST BrandSelection ID ID #REQUIRED

    BrandListRef NMTOKEN #REQUIRED

    BrandRef NMTOKEN #REQUIRED

    ProtocolAmountRef NMTOKEN #REQUIRED
    CurrencyAmountRef NMTOKEN #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции.

    BrandListRef

    Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand.

    BrandRef

    Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа.

    ProtocolAmountRef

    Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже.

    CurrencyAmountRef

    Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже.

    Cодержимое:

    BrandSelBrandInfo,
    BrandSelProtocolAmountInfo,

    Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже
    или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3.

    Используются следующие правила:

    • атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP;
    • на каждый компонент списка видов платежа в блоке опций торгового протокола (смотри раздел 8.1) должен ссылаться один и только один компонент выбора вида платежа.
    • BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef
    • ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef
    • CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef.

    Пример компонента выбора вида платежа включен в раздел 11.2.

    7.8.1. Информационный элемент выбора вида платежа

    Информационный элемент выбора вида платежа cсодержит любую дополнительную информацию, которая может быть необходима для какого-то конкретного вида платежа. Смотри приложение IOTP для платежных методов, где описано применние этого элемента.

    <!ELEMENT BrandSelBrandInfo (PackagedContent+) >
    <!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >

    Атрибуты:

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Элементы Packaged Content (смотри раздел 3.7), содержащие дополнительные данные, которые могут быть необходимы для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

    7.8.2. Элемент Amount Info протокола выбора вида платежа

    Элемент Amount Info протокола выбора вида платежа содержит любую дополнительную информацию, зависящую от платежного протокола, которая может быть необходима для конкретного вида платежа или плптежного протокола. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

    <!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
    <!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Элементы Packaged Content (смотри раздел 3.7), которые могут содержать дополнительную информацию, необходимую для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

    7.8.3. Информационный элемент валютной суммы выбора вида платежа (Brand Selection Currency Amount Info)

    Информационный элемент валютной суммы выбора вида платежа содержит любую дополнительную информацию, зависящую от вида платежа и валюты, которая может быть необходима при конкретном виде платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.

    <!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
    <!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Элементы Packaged Content (смотри раздел 3.7), которые содержат дополнительную информацию, относящуюся к виду платежа и валюты. Смотри приложение IOTP по платежным методам, где описано использование этого элемента.

    7.9. Компонент платежа (Payment)

    Компонент платежа содержит информацию, используемую для управления процедурой выполнения платежа. Он предоставляет информацию о:

    • Временном интервале в пределах которого Кассир может начать платежную операцию;
    • Ссылку на список видов платежа (смотри раздел 7.7), который идентифицирует виды платежа, протоколы, виды валюты и суммы, которые могут использоваться при осуществлении платежа.
    • следует ли предоставлять платежную расписку;
    • должен ли данному платежу предшествовать другой платеж.

    Его определение выглядит следующим образом.

    <!ELEMENT Payment EMPTY > <!ATTLIST Payment ID ID #REQUIRED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    BrandListRef NMTOKEN #REQUIRED

    SignedPayReceipt (True | False) #REQUIRED

    StartAfterRefs NMTOKENS #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно идентифицирует платежный компонент в транзакции IOTP.

    OkFrom

    Дата и время в формате [UTC], после которого кассир может воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа.

    OkTo

    Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного запроса, содержащий компонент платежа.

    BrandListRef

    Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует альтернативные способы осуществления платежа.

    SignedPayReceipt

    Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром.

    StartAfter

    Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно.

    7.10. Компонент платежной схемы

    Компонент платежной схемы содержит информацию платежного протокола для специфической платежной схемы, реализуемой между партнерами, вовлеченными в платеж, например [SET]-сообщение. Определение компонента представлено ниже.

    <!ELEMENT PaySchemeData (PackagedContent+) >
    <!ATTLIST PaySchemeData ID ID #REQUIRED

    PaymentRef NMTOKEN #IMPLIED

    ConsumerPaymentId CDATA #IMPLIED

    PaymentHandlerPayId CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP.

    PaymentRef

    Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1).

    ConsumerPaymentId

    Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь.

    PaymentHandlerPayId

    Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Содержит протокольную информацию о схеме платежа в виде элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа.

    Заметим, что:

    • значения атрибута Name каждого элемента pakaged content определены в приложении для платежных протоколов;
    • значение каждого Name должно быть уникальным для платежа, где платеж определяется как совокупность всех платежных схем или компонентов платежных расписок с идентияным значением атрибута PaymentRef.

    7.11. Компонент платежной расписки

    Плптежная расписка представляет собой запись о платеже, которая показывает, какая сумма заплачена или получена. Она отдичается от расписки о покупке, тем что здесь нет записи о том, что куплено. Обычно в компоенте платежной расписки содержатся данные, которые описывают:

    • сумму платежа и его валюту;
    • дату и время платежа;
    • внутренние числовые ссылки, которые идентифицируют платеж для платежной системы;
    • цифровые подписи, выработанные платежным механизмом и призванные позднее подтвердить, что платеж состоялся.

    Если использованный платежный метод сконфигироирован соответствующим образом, то компонент платежной расписки должен содержать сообщения платежного протокола или ссылки на сообщения, которые подтверждают выполнение платежа.

    Точное определение содержимого платежной расписки зависит от метода платежа. Информация, содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до сведения Покупателя.

    Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю.

    Определение компонента платежной расписки.

    <!ELEMENT PayReceipt (PackagedContent*)>

    <!ATTLIST PayReceipt ID

    ID #REQUIRED

    PaymentRef NMTOKEN #REQUIRED

    PayReceiptNameRefs NMTOKENS #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.

    PaymentRef

    Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка.

    PayReceiptNameRefs

    Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать:

    о

    компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или

    o

    сам компоент платежной расписки. Заметим, что:

    o

    каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны).

    о

    Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись).

    Программа клиента должна спасать все компоненты, на которые имеются ссылки, с тем чтобы платежная расписка могла быть воспроизведена, если это потребуется.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Опционно содержит информацию платежной расписки (платежную схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении платежной схемы.

    Заметим, что:

    о

    значения атрибута Name каждого элемента packaged content определены приложением платежного протокола;

    о

    значение Name должно быть уникальным для каждого платежа, как и для всех схем платежа или компонентов платежной расписки с идентичным значением атрибута PaymentRef.

    Заметим, что должны присутствоать либо атрибут PayReceiptNameRefs, либо элемент PackagedContent или оба.

    7.12. Компоент Payment Note

    Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны дублировать информацию, содержащуюся в компоненте платежной расписки.

    Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже.

    <!ELEMENT PaymentNote (PackagedContent+) >
    <!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Содержит дополнительную, не связанную с платежом информацию, которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри раздел 3.7).

    7.13. Компонент доставки

    Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его определение приведено ниже.

    <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
    <!ATTLIST Delivery ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    DelivExch (True | False) #REQUIRED

    DelivAndPayResp (True | False) #REQUIRED

    ActionOrgRef NMTOKEN #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент доставки транзакции.

    xml:lang

    Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8.

    DelivExch

    Индицирует факт наличия в транзакции сообщений, ассоциированных с обменом доставки. Корректные значения:

    о"Истинно" указывает на наличие обмена доставки.
    o"Ложно" указывает на отсутствие обмена доставки.

    Если DelivExch = true, должен присутствовать элемент DeliveryData. Если DelivExch = false, он может отстутствовать.

    DelivAndPayResp

    Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9) находся в одном и том же сообщении IOTP. Корректные значения:

    o "Истинно" указывает, что оба блока находятся в одном и том же сообщении IOTP и
    o "Ложно" указывает, что каждый блок размещен в разных сообщениях IOTP.

    Атрибут DelivAndPayResp не должен иметь значение "истинно", если DelivExch = "ложно".

    На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:

    о Кассир должен иметь доступ к информации компонента Order, с тем чтобы знать что надо доставлять и
    o Кассир должен должен быть способен осуществить доставку.

    ActionOrgRef

    Ссылка элемента на компонент организации Агента доставки.

    Cодержимое:

    DeliveryData

    Содержит подробности того, как будет осуществляться доставка. Смотри 7.13.1.

    PackagedContent

    Содержит данные "пользователя", определенные для продавца и необходимые агенту доставки в виде одного или нескольких элементов Packaged Content. Смотри раздел 3.7.

    7.13.1. Элемент Delivery Data

    Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.

    <!ELEMENT DeliveryData (PackagedContent*) >

    <!ATTLIST DeliveryData xml:lang

    NMTOKEN #IMPLIED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    DelivMethod NMTOKEN #REQUIRED

    DelivToRef NMTOKEN #REQUIRED

    DelivReqNetLocn CDATA #REQUIRED

    SecDelivReqNetLocn CDATA #REQUIRED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    xml:lang

    Определяет язык, используемый атрибутами компонента. Смотри раздел 3.8.

    OkFrom

    Дата и время в формате [UTC] после которого Агент доставки может принять на обработку блок запроса доставки (смотри раздел 8.10).

    OkTo

    Дата и время в формате [UTC], до которого Агент доставки может принять на обработку блок запроса доставки.

    DelivMethod

    Индицирует метод, с помощью которого могут быть доставлены товары или предоставлены услуги. Корректными считаются значения:

    о Post. Товары будут доставлены по почте или курьером.
    o Web. Товары будут доставлены электронным образом в комоненте Delivery Note.
    o Email. Товары будут доставлены электронным образом через e-mail

    Значения DelivMethod управляются процедурой, описанной в разделе 12, что допускает определение новых кодов пользователем.

    DelivToRef

    Ссылка элемента (смотри раздел 3.4) компонента Organisation транзакции IOTP, которая имеет роль DelivTo. Информация в этом блоке используется, чтобы определить, куда следует доставить покупку. Она должна быть совместимой с DelivMethod. В частности, если DelivMethod является:

    о Post, тогда здесь должен быть элемент почтового адреса, содержащий достаточно информации для доставки по почте,
    o Web, тогда не нужны никакие специфические требования. Информация будет послана на web-страницу Покупателя,
    o Email, тогда здесь должен быть элемент контактной информации с корректным адресом e-mail.

    DelivReqNetLocn

    Содержит сетевую позицию, куда должен быть послан небезопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки. Содержимое этого атрибута зависит от транспортного механизма и должно согласовываться с требованиями документа [RFC-1738].

    SecDelivReqNetLocn

    Содержит сетевую позицию, куда должен быть послан безопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки.

    Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром.

    Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Дополнительная информация о доставке в виде одного или несколько элементов Packaged Content (смотри раздел 3.7), предоставляемая агенту доставки продавцу.

    7.14. Информационный компонент доставки Покупателя

    Информационный компонент доставки покупателя используется покупателем для спецификации идентификатора, который может быть использован им для идентификации доставки. Его определение приведено ниже:

    <!ELEMENT ConsumerDeliveryData EMPTY>
    <!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
    ConsumerDeliveryId CDATA #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет информационный компонент доставки покупателя для данной транзакции.

    ConsumerDeliveryId

    Идентификатор, специфицированный покупателем, который в случае возврата агентом доставки позволяет покупателю идентифицировать процедуру доставки.

    7.15. Компонент Delivery Note

    Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка.

    Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже.

    <!ELEMENT DeliveryNote (PackagedContent+) >

    <!ATTLIST DeliveryNote ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    DelivHandlerDelivId CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент Delivery Note транзакции IOTP.

    xml:lang

    Определяет язык, используемый атрибутами или дочерними элементами в рамках данного компонента, если только его значение не будет переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.

    DelivHandlerDelivId

    Опционный идентификатор, специфицированный Агентом доставки, который в случае возвращения Покупателем в другом компоненте доставки или каким-либо другим способом, позволяет Агенту доставки определить, о какой доставке идет речь. Он необходим для любого компонента доставки, вне зависимости от того содержится ли от в блоке запроса доставки.

    ContentSoftwareId

    Смотри раздел 14. Словарь.

    Cодержимое:

    PackagedContent

    Содержит информацию декларации доставки (delivery note) в виде одного или нескольких элементов Packaged Content (смотри раздел 3.7).

    Если содержимым сообщения доставки является сообщение Mime, тогда Delivery Note может запустить приложение, которое вызываеть реальный процесс доставки.

    7.16. Компонент Status

    Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже.

    <!ELEMENT Status EMPTY >

    <!ATTLIST Status ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    StatusType NMTOKEN #REQUIRED

    ElRef NMTOKEN #IMPLIED

    ProcessState (NotYetStarted | InProgress | CompletedOk | Failed | ProcessError) #REQUIRED
    CompletionCode NMTOKEN #IMPLIED
    ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент Status транзакции IOTP.

    xml:lang

    Определяет язык, используемый атрибутами в пределах компонента. Смотри раздел 3.8.

    StatusType

    Индицирует тип обмена документами, о котором сообщает компонент Status. Он может быть установлен в состояние предложение, платеж, доставка, аутентификация или "неопределено" (Undefined).

    "Непределено" означает, что тип документального обмена не может быть идентифицирован. Это может быть вызвано ошибкой исходного входного обмена сообщениями. Значения StatusType управляется процедурой, описанной в секции 12 (IANA), и допускающей определение новых значений пользователем.

    ElRef

    Если StatusType не установлено равным Undefined (неопределено), тогда ElRef содержит ссылку элемента (смотри раздел 3.5) на компонент, для которого описан Status. Он может относиться к:

    о   компоненту Order (смотри раздел 7.5), если StatusType = Offer,
    o   компоненту Payment (смотри раздел 7.9), если StatusType = Payment,
    o   компоненту Delivery (смотри раздел 7.13), если StatusType = Delivery;
    o   компоненту запрос аутентификации (смотри раздел 7.2), если StatusType = Authentication.

    ProcessState

    Содержит код состояния (State Code), который индицирует текущее состояние исполняемого процесса. Допустимыми значениями ProcessState являются:

    о   NotYetStarted. Получен блок Request, но процесс еще не начат;
    o   InProgress. Обработка блока Request начата, но еще не завершена;
    o   CompletedOk. Обработка блока Request успешно завершена;
    o   Failed. Обработка блока Request не прошла из-за рабочей ошибки (Business Error) (смотри раздел 4.2)
    o   ProcessError. Это значение применяется, только когда компонент Status используется в связис торговым блоком информационного запроса (смотри раздел 8.12). Оно указывает, что была техническая ошибка (смотри раздел 4.1) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки.

    Заметим, что этот код сообщает об обработке блока запроса. Далее, после посылки блока отклика, сопряженного с процессом, может осуществляться асинхронная обработка.

    CompletionCode

    Индицирует то, как завершился процесс. Корректные значения CompletionCode приведены ниже вместе с указанием условий, когда атрибут должен присутствовать и указанием возможности восстановления при неудаче.

    CompletionCode может иметь до 14 символов.

    ProcessReference

    Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения:

    о   когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order;

    o   когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа;

    o   когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note;

    o   когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации.

    Этот атрибут должен отсутствовать в сообщении информационного запроса, когда Покупателю сервис-провайдером IOTP не был дан код ссылки.

    Этот атрибут может быть использован внутри блока информационного отклика (смотри раздел 8.13), для того чтобы предоставить код ссылки для транзакции, которя ранее была недоступна.

    Например, код упаковки может быть не присвоен в момент получения отклика доставки. Однако, если покупатель поздее выдаст запрос состояния транзакции, Агент доставки может проставить код упаковки в атрибут сообщения информационного отклика и послать его Покупателю.

    StatusDesc

    Опционное текстовое описание текущего состояния процесса на языке, заданном атрибутом xml:lang.

    7.16.1. Коды завершения предложения

    Код завершения является единственно необходимым, если атрибут ProcessState = Failed (неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.

    Значение

    Описание

    AuthError

    Ошибка аутентификации. Проверка отклика аутентификации не прошла.

    Восстановление может осуществить Покупатель, повторно предложив блок отклика аутентификации с правильными данными.

    ConsCancelled

    Прервано покупателем (Consumer Cancelled). Покупатель по каким-то причинам решает прервать транзакцию. Это код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.

    MerchCancelled

    Предложение аннулировано (Offer Cancelled). Продавец по каким-то причинам аннулирует свое предложение и прерывает транзакцию. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.

    Unspecified

    Неспецифицированная ошибка. Возникла какая-то неизвестная проблема или ошибка, которая не соответствует ни однму из кодов CompletionCodes. Восстановление невозможно.

    TimedOutRcvr

    Восстановимый таймаут (Recoverable Time Out). Сообщения были посланы, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции.

    Восстановление возможно, если последнее сообщение от другой торговой роли получено снова.

    TimedOutNoRcvr

    Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были посланы повторно, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции. Восстановление невозможно.

    7.16.2. Коды завершения платежа

    CompletionCode необходим, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, когда возможно восстановление. Рекомендуется, чтобы атрибут StatusDesc использовался индивидуальными платежными схемами для предоставления дальнейших пояснений, там где это уместно.

    Значение

    Описание

    BrandNotSupp

    Вид платежа не поддерживается Кассиром.

    Ниже приведены опции восстановления.

    CurrNotSupp

    Валюта не поддерживается. Валюта, в которой выполнен платеж, не поддерживается платежным инструментом или кассиром.

    Если оплата не зависит от вида платежа, тогда покупатель решить проблему путем выбора другой валюты, если она имеется, или заменой вида платежа. Заметим, что это может потребовать замены кассира.

    ConsCancelled

    Отмена Покупателем (Consumer Cancelled). Покупатель по какой-либо причине решил аннулировать платеж. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.

    PaymtCancelled

    Платеж аннулирован (Payment Cancelled). Кассир по каким-то причинам не хочет завершить платежную операцию и аннулирует транзакцию. Этот код является единственно верным в компоненте Status, содержащегося в блоках Cancel или информационного отклика. Опции восстановления смотри ниже.

    AuthError

    Ошибка аутентификации. Аутентификационная проверка платежной схемы не прошла. Восстановление возможно. Чтобы определить, что допустимо, смотри приложение по платежным схемам.

    InsuffFunds

    Нехватает средств. Средств для осуществления платежа недостаточно. Опции восстановления смотри ниже.

    InstBrandInvalid

    Платежный инструмент не приемлем для данного вида платежа. Использован платежный инструмент, который не соответствует выбранному виду платжа. Например, использована кредитная карта Visa, хотя в качестве вида платежа была выбрана MasterCard. Опции восстановления смотри ниже.

    InstNotValid

    Платежный инструмент не приемлем для сделки. Платежный инструмент по каким-то причинам не может быть использован для предлагаемого вида сделки. Опции восстановления смотри ниже.

    BadInstrument

    Плохой инструмент. Имеется проблема с использованным платежным инструментом, что означает, что он не может быть применен для платежа. Опции восстановления смотри ниже.

    Unspecified

    Неспецифицированная ошибка. Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен предоставить объяснение причины. Опции восстановления смотри ниже.

    TimedOutRcvr

    Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение другой торговой роли получено снова.

    TimedOutNoRcvr

    Невосстановимый таймаут. Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

    Если оплата не зависит от вида платежа, тогда восстановление для некоторых видов кода завершения возможно для покупателя, который может выбрать другой вид платежа или новый платежный инструмент для того же вида платежа. Заметим, что это может потребовать замены кассира. Здесь применимы следующие коды: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument и Unspecified.

    Восстановление прооцедуры платежа при покупках, зависящих от вида платежа возможно только в случае, если компонент выбора вида платежа, посланный продавцом покупателю, не изменился. На практике это означает, что должны использоваться тот же элемент вида платежа, платежный протокол и сумма. Единтвенно что можно изменить - это платежный инструмент. Любые другие изменения будут неприемлемы.

    7.16.3. Коды завершения доставки

    Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

    Значение

    Описание

    BackOrdered

    Back Ordered. Товары, подлежащие доставке, ожидают длставки, но еще не доставлены. Доставка будет оформлена, когда товар будет получен. Это справедливо, если ProcessState = CompletedOk. Восстановление невозможно.

    PermNotAvail

    Постоянно не доступен (Permanently Not Available). Товары не доступны и не могут быть перезаказаны. Это справедливо, если ProcessState = Failed. Восстановление не возможно.

    TempNotAvail

    Временно не доступен. Товары временно не доступны и могут быть получены при повторном заказе. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.

    ShipPending

    Задержка доставки. Товары доступны и запланированы к доставке, но еще не доставлены. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.

    Shipped

    Товары доставлены (Goods Shipped). Товар уже доставлен. Ожидается подтверждение доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.

    ShippedNoConf

    Доставлен - никакого подтверждения доставки (Shipped - No Delivery Confirmation). Товары были доставлены, но их доставку невозможно подтвердить. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.

    ConsCancelled

    Аннулировано Покупателем (Consumer Cancelled). Покупатель по какой-то причине решает аннулировать доставку. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.

    DelivCancelled

    Доставка аннулирована (Delivery Cancelled). Агент доставки по какой-то причине отказался завершить процедуру доставки и аннулировал транзакцию. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно.

    Confirmed

    Подтверждено (Confirmed). Все товары были доставлены и получено подтверждение их доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно.

    Unspecified

    Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен прояснить причину. Восстановление невозможно.

    TimedOutRcvr

    Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.

    TimedOutNoRcvr

    Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

    Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1).

    7.16.4. Коды завершения аутентификации

    Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

    Значение

    Описание

    AutEeCancel

    Аннулировано аутентифицируемым (Authenticatee Cancel). Организация по какой-то причине отказывается от аутентификации. Это может быть, например, потому что подпись аутентификационного запроса оказалась некорректной или аутентификатор оказался неизвестным или неприемлемым. Восстановление невозможно.

    AutOrCancel

    Аннулировано аутентификатором (Authenticator Cancel). Организация, запросившая аутентификацию по каким-то причинам отказывается проверять полученный аутентификационный отклик и аннулирует транзакцию. Восстановление невозможно.

    NoAuthReq

    Запрос аутентификации не возможен (Authentication Request Not Available). Аутентифицирующийся субъект не имеет данных, которые должны быть предоставлены. Например, забыт пароль или субъект не авторизован. Восстановление невозможно.

    AuthFailed

    Аутентификация не прошла (Authentication Failed). Аутентификатор проверил аутентификационный отклик, но эта проверка по какой-то причине не прошла. Например, оказался неправильным пароль. Восстановление может быть возможно аутентифицируемым путем повторной посылки отклика аутентификации с корректными данными.

    TradRolesIncon

    Торговые роли несоместимы (Trading Roles Inconsisten). Торговые роли, содержащиеся в атрибуте TradingRoleList компонента информационного запроса торговых ролей (смотри раздел 7.4) не согласуются с торговой ролью, которую аутентифицируемый играет в данной транзакции IOTP. Примеры несогласованности включают в себя:

    о запрос Кассира информации об Агенте доставки;
    о запрос Покупателя информации о Продавце.

    Восстановление может выполнить аутентификатор путем повторной посылки блока аутентификационного запроса с поправленной информацией.

    Unspecified

    Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Восстановление невозможно.

    TimedOutRcvr

    Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь.

    TimedOutNoRcvr

    Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно.

    7.16.5. Неопределенные коды завершения

    Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

    Значение

    Описание

    InMsgHardError

    Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции.

    7.16.6. Коды завершения информационного запроса транзакции

    Код завершения требуется только тогда, когда атрибут ProcessState = Failed. Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.

    Значение

    Описание

    UnAuthReq

    Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос.

    7.17. Компонент данных торговой роли

    Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.

    Компоненты торговой роли определяют:

    o организацию, которая сформировала компонент и
    o организацию, которая его получила.

    Они являются первыми сформированными и включенными в блок "отклик" и затем скопированных в соответствующий блок "запрос". Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.

    Его определение представлено ниже.

    <!ELEMENT TradingRoleData (PackagedContent+) >
    <!ATTLIST TradingRoleData ID ID #REQUIRED
    OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP.

    OrginatorElRef

    Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа).

    DestinationElRefs

    Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки).

    Cодержимое:

    PackagedContent

    Содержит данные, которыые должны быть пересланы между торговыми ролями в виде одного или нескольких элементов PackagedContent, смотри раздел 3.7.

    7.17.1. Кто получает компонент данных о торговой роли

    Ниже описаны правила, которые определяют, что следует делать с компонентами данных торговой роли.

    • Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.
    • Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:

    - компонент данных о торговой роли, а также,

    - компонент Organisation, идентифицированной атрибутом OriginatorElRef.

    7.18. Компонент типа информационного запроса

    Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.

    <!ELEMENT InquiryType EMPTY >
    <!ATTLIST InquiryType ID ID #REQUIREDType NMTOKEN #REQUIRED
    ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP.

    Type

    Содержит тип информационного запроса. Допустимые значения типа запроса:

    o Offer. Запрос касается статуса предложения и обращен к продавцу.
    o Payment. Запрос касается статуса платежа и обращен к кассиру.
    o Delivery. Запрос касается статуса доставки и обращен к агенту доставки.

    ElRef

    Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это:

    о Блок TPO, когда тип = Offer;

    o Компонент Payment, когда тип = Payment;

    o Компонент Delivery, когда тип = Delivery.

    ProcessReference

    Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16).

    7.19. Компонент Signature (подпись)

    Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG].

    В будущем ожидается, что новые версии IOTP зафиксируют какой-то метод цифровой подписи XML в к ачестве стандарта.

    Каждый компонент подписи цифровым образом подтвержжает один или более блоков или компонентов, включая компоненты подписи.

    Компонент подпись:

    • содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest;
    • объединяет элементы дайджестов с другой информацией о типе подписи, об отправителе и потенциальных получателях, а также об используемом алгоритме подписи, и помещает их в элемент Manifest,
    • подписывает элемент Manifest, используя опционный сертификат, идентифицированный в компоненте Certificate блока Signature, помещая результат в элемент Value комполнента Signature.

    Заметим, что может быть много элементов Value, которые содержат подписи элемента Manifest. Компонент Signature может иметь один из четырех типов:

    • Подпись отклика предложения,
    • Подпись отклика платежа,
    • Подпись отклика доставки, или
    • Подпись отклика аутентификации.

    Для общего объяснения подписей смотри раздел 6.

    7.19.1. Использование элементов подписи и атрибутов IOTP

    Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

    Элемент SIGNATURE
    ID-атрибут является обязательным.

    Элемент MANIFEST

    Опционный атрибут LocatorHrefBase содержит текст, который должен быть включен до текста, содержащегося в атрибуте LocatorHREF всех элементов Digest в пределах элемента Manifest.

    Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична.

    Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже).

    Элементы ALGORITHM и PARAMETER
    Элемент algorithm идентифицирует алгоритмы, использованные при формировании подписи. Тип алгоритма определяется значением алгоритма Type, который указывает, следует ли его использовать в качестве Digest-алгоритма, алгоритма подписи или алгоритма Key Agreement. Следует использовать следующие алгоритмы дайджестов:

    • алгоритм [DOM-HASH]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:dom-hash";
    • алгоритм [SHA1]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:fips:sha1" и
    • алгоритм [MD5]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:md5".
    • Следует применять следующие алгоритмы подписи:
    • алгоритм [DSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:us.gov:dsa"
    • алгоритм [HMAC]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:hmac"

    Рекомендуется, чтобы использовался также следующий алгоритм подписи:

    • алгоритм [RSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:rsa"

    Кроме того могут использоваться другие специфические алгоритмы схем платежа. В этом случае значение атрибута name, которое надлежит использовать, специфицировано в приложении по платежным схемам.

    Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например:

    <Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
    <Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
    <Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
    <Algorithm ID=A3 type="signature" name="urn:ibm:hmac">

    Элемент DIGEST

    Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:

    • значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует:
    • символ "#", за которым следует
    • ссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста.

    Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше).

    Элемен атрибут

    Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи.

    Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем.

    Атрибут Critical должен быть установлен равным true.

    Элемент ORIGINATORINFO

    Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature.

    Элемент RECIPIENTINFO

    Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.

    7.19.2. Компонент подписи отклика предложения

    Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:

    • Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит подпись отклика предложения;
    • Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения
    • из блока TPO:

    компонент опций протокола;

    каждый из компонентов Organisation;

    каждый из компонентов списка видов платежа;

    • опционно, все компоненты выбора вида платежа, если они посланы Продавцу в блоке выбора TPO;
    • из блока отклика предложения:

    компонент Order;

    каждый из компонентов Payment;

    компонент Delivery;

    каждый из компонентов запроса аутентификации;

    любой компонент данных о торговой роли.

    Подпись отклика предложения должна также содержать элементы дайджеста для компонентов, которые описывают каждую из организаций, которая может или будет нуждаться в верификации подписи. Это включает в себя:

    • если продавец получил блок выбора TPO, содержащий компоненты выбора вида платежа, тогда генерируется элемент дайджеста для кассира, идентифицированного компонентом выбора вида платежа, и для агента доставки, идентифицированного компонентом Delivery. Смотри раздел 6.3.1.
    • если Продавец не ожидает получить блок выбора TPO, тогда ренерируется элемент дайджеста для Агента доставки и всех Кассиров, вовлеченных в сделку.

    7.19.3. Компонент подписи платежной расписки

    Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:

    • Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись платежной расписки;
    • Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись платежной расписки;
    • компонент подписи отклика предложения;
    • компонент платежной расписки;
    • компонент Payment Note;
    • компонент Status;
    • компонент выбора вида платежа;
    • любой компонент данных о торговой роли.

    7.19.4. Компонент подписи отклика доставки

    Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:

    • Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись отклика доставки;
    • блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;
    • компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);
    • компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);
    • компонент Status;
    • компонент Delivery Note.

    7.19.5. Компонент подписи запроса аутентификации

    Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:

    • блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, которая описывает сообщение и транзакцию IOTP;
    • Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
    • следующие компоненты блока TPO:
     

    - компонент опций протоколов;

     

    - компонент Organisation.

    • следующие компоненты блока запроса аутентификации:
     

    - компоненты запроса аутентификации (если имеются)

     

    - компонент запроса информации о торговой роли (если имеется)

    7.19.6. Компонент подписи отклика аутентификации

    Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:

    • блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, описывающую сообщение и транзакцию IOTP;
    • Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
    • следующие компоненты блока запроса аутентификации:

    - компонент запроса аутентификации, который был использован в аутентификации (если имеется);

    - компонент информационного запроса о торговой роли (если имеются).

    • компоненты Organisation, содержащиеся в блоке отклика аутентификации.

    7.19.7. Компонент подписи информационного запроса

    Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа.

    7.19.8. Компонент подписи

    Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status.

    7.19.9. Компонент подписи запроса Ping

    Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

    7.19.10. Компонент подписи отклика Ping

    Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.

    7.20. Компонент Certificate

    Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19.

    Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key). Структура сертификата определена в [IOTPDSIG].

    7.20.1. Использование в IOTP атрибутов и элементов подписи

    Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.

    Компонент CERTIFICATE
    ID-атрибут является обязательным.

    Элемент VALUE
    ID-атрибут является обязательным.

    7.21. Компонент Error

    Компонент Error содержит информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, которое было получено одной из торговых ролей, вовлеченных в сделку. Для ясности ниже приведены две фразы, которые определяют использование компонента Error:

    • сообщение сопряжено с ошибкой. Сообщение IOTP, которое содержит или вызывает ошибку какого-то вида;
    • сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении.

    Определение компонента Error представлено ниже.

    <!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
    <!ATTLIST ErrorComp ID NMTOKEN #REQUIRED
    xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
    ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED

    MinRetrySecs CDATA #IMPLIED

    SwVendorErrorRef CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет компонент Error транзакции IOTP.

    xml:lang

    Определяет язык, используемый атрибутами или дочерними элементами компонента, если только значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8.

    ErrorCode

    Содержит код ошибки, который указывает на природу ошибки в сообщении. Допустимые значения ErrorCode приведены в секции 7.21.2.

    ErrorDesc

    Содержит текстовое описание ошибки на языке, заданном xml:lang. Содержимое этого атрибута определено поставщиком/разработчиком программного обеспечения, которое сгенерировало компонент Error.

    Severity

    Определяет степень (severity) ошибки. Допустимы следующие значения:

    о
    Warning.
    Индицирует, что хотя имеется ошибочное сообщение, транзакция может продолжаться.

    о
    TransientError.
    Индицирует, что ошибка в сообщении может быть исправлена, если ошибочное сообщение, на которое указывает элемент ErrorLocation, послать повторно.

    o
    HardError.

    Индицирует, что в сообщении имеется неустранимая ошибка, трпнзакция IOTP должна быть остановлена.

    MinRetrySecs

    Этот атрибут должен присутствовать, если Severity равен TransientError. Он равен минимальному числу полных секунд, которое приложение IOTP, получившее сообщение об ошибке, должно подождать прежде чем переадресовать сообщение, идентифицированное элементом ErrorLocation.

    Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.

    SwVendorErrorRef

    Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3).

    Cодержимое:

    ErrorLocation

    Идентифицирует Id транзакции IOTP сообщения с ошибкой и, если возможно, элемент и атрибут сообщения, который вызвал формирование компонента Error.

    Если Severity ошибки не равно TransientError, может быть, если требуется, специфицировано более одного ErrorLocation, в зависимости от природы ошибки (смотри раздел 7.21.2) и от конкретной реализации программы.

    PackagedContent

    Содержит дополнительные данные, которые могут использоваться для понимания ошибки. Его содержимое может варьироваться в зависимости от природы ошибки (смотри раздел 7.21.2) и ои поставщика/разработчика приложения IOTP. Определение f PackagedContent смотри в разделе 3.7.

    7.21.1. Общие принципы обработки ошибок

    Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень "серьезности" (severity), чем TransientError, который имеет серьезность выше, чем Warning.

    7.21.1.1. Severity = предупреждение

    Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:

    • рекомендуется, чтобы информация об ошибке была доведена до сведения пользователя,
    • разработчик приложения IOTP должен:
     

    - продолжеть транзакцию как обычно или

     

    - прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3).

    Если предполагается продолжить транзакцию, тогда, если нет других компонентов Error с более высоким уровнем серьезности, следует проверить, что наличиствуют торговые блоки и компоненты, необходимые для продолжения транзакции. Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError.

    7.21.1.2. Severity = переходная ошибка

    Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:

    • если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:

     

    - сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и

     

    - использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP.

    • Проверить, что только один элемент ErrorLocation содержится в компоненте Error и что он относится к сообщению, которое было послано получателем компонента Error с Severity = TransientError. Если имеется более одного элемента ErrorLocation, тогда генерируется сообщение со степенью серьезности равным HardError.

    7.21.1.3. Severity = Hard Error

    Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error.

    Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается.

    7.21.2. Коды ошибок

    Ниже следующая таблица содержит допустимые значения атрибута ErrorCode компонента Error. Первое предложение описания содержит текст, который должен использоваться для описания ошибки при отображении. Индивидуальные реализации могут транслировать его на альтернативные языки по своему усмотрению. ErrorCode не должен быть длиннее 14 символов.

    Значение

    Описание

    Reserved

    Reserved. Эта ошибка зарезервирована поставщиком/разработчиком программы. Контактируйте, если требуется, с поставщиком/разработчиком программы. Смотри ID-атрибут Software Id-элемента сообщения в блоке ссылок транзакции (раздел 3.3).

    XmlNotWellFrmd

    XML плохо сформирован. Документ XML плохо сформатирован. Смотри [XML]Ю, для того чтобы понять, что значит "хорошо сформатирован". Даже если XML сформатирован плохо, он должен быть просмотрен, найден блок ссылок транзакции, с тем чтобы было можно правильно сформировать отклик Error.

    XmlNotValid

    XML некорректен. Документ XML сформатирован хорошо, но он некорректен. Для того чтобы понять, что значит "корректен" смотри [XML], в частности:

    oдокумент XML не следует регламентациям, определенным декларацией типов документов IOTP (DTD) (смотри раздел 13) и
    o документ XML не следует регламентациям, определенным расширениям декларации типов документов [XML Namespace].

    Для плохо сформатированного XML, следует попытаться извлечь блок ссылок транзакции, с тем чтобы корректно сформировать отклик Error.

    ElUnexpected

    Нестандартный элемент. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации.

    ElNotSupp

    Элемент не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который:

    o согласуется с правилами и ограничениями данной спецификации, но
    o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение.

    ElMissing

    Элемент отстутствует. Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации.

    В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного элемента.

    ElContIllegal

    Содержимое элемента не верно. Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации.

    EncapProtErr

    Ошибка инкапсулированного протокола. Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны.

    AttUnexpected

    Нестандартный атрибут. Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации.

    AttNotSupp

    Атрибут не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP.

    AttMissing

    Атрибут отсутствует. Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать.

    В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.

    AttValIllegal

    Не верно значение атрибута. Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации.

    AttValNotRecog

    Значение атрибута не распознано. Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать.

    MsgTooLarge

    Сообщение имеет слишком больую длину. Сообщение слишком велико для приложения, его обрабатывающего.

    ElTooLarge

    Элемент слишком велик. Элемент слишком велик для приложения, его обрабатывающего.

    ValueTooSmall

    Значение слишком мало. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало.

    ValueTooLarge

    Значение слишком велико. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико.

    ElInconsistent

    Элемент не согласован. Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации:

    о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или
    о значение атрибута не согласуется со значением одного или нескольких других атрибутов.

    В этом случае следует создать элементы ErrorLocation, которые определяют все несогласованные атрибуты или элементы.

    TransportError

    Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма.

    MsgBeingProc

    Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.

    SystemBusy

    Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь.

    Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.

    UnknownError

    Неизвестная ошибка. Индицирует, что транзакция не может завершиться по неидентифицированной причине. Атрибут ErrorDesc следует использовать для индикации природы проблемы. Эта ошибка может быть применена для указания, например, внутренней ошибки оконечного сервера или процесса клиента.

    7.21.3. Элемент положения ошибки

    Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.

    <!ELEMENT ErrorLocation EMPTY >

    <!ATTLIST ErrorLocation ElementType

    NMTOKEN #REQUIRED

    IotpMsgRef NMTOKEN #IMPLIED

    BlkRef NMTOKEN #IMPLIED

    CompRef NMTOKEN #IMPLIED

    ElementRef NMTOKEN #IMPLIED

    AttName NMTOKEN #IMPLIED>

    Атрибуты:

    ElementType

    Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как <!ELEMENT Org, тогда его имя - "Org".

    IotpMsgRef

    Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error.

    BlkRef

    Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка.

    CompRef

    Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка.

    ElementRef

    Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута.

    AttName

    Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута.

    Заметим, что следует включать как можно больше атрибутов. Например, если атрибут в дочернем элементе торгового компонента содержит неверное значение, тогда должны присутствовать все атрибуты ErrorLocation.

    8. Торговые блоки

    Торговые блоки являются дочерними элементами IOTP-сообщения верхнего уровня, которое послано в форме [XML]-документа от одного партнера торговой операции к другому.

    Каждый трговый блок состоит из одного или более торговых компонентов (смотри раздел 7). Это проиллюстрировано на диаграмме.


    Рис. .16. Торговые блоки

    Торговые блоки определены как часть определения сообщения IOTP (смотри раздел 3.1.1). Определение элемента сообщения IOTP представлено ниже:

    <!ELEMENT IotpMessage

    ( TransRefBlk,

    SigBlk?,

    ErrorBlk?,

    ( AuthReqBlk |

    AuthRespBlk |

    AuthStatusBlk |

    CancelBlk |

    DeliveryReqBlk |

    DeliveryRespBlk |

    InquiryReqBlk |

    InquiryRespBlk |

    OfferRespBlk |

    PayExchBlk |

    PayReqBlk |

    PayRespBlk |

    PingReqBlk |

    PingRespBlk |

    TpoBlk |

    TpoSelectionBlk

    )*

    ) >

    Далее в данном разделе определены торговые блоки данной версии IOTP. Это:

    • Блок запроса аутентификации (Authentication Request Block)
    • Блок отклика аутентификации (Authentication Response Block)
    • Блок состояния доставки
    • Блок Cancel
    • Блок запроса доставки
    • Блок отклика доставки
    • Блок Error
    • Блок информационного запроса
    • Блок информационного отклика
    • Блок отклика Offer
    • Блок платежного обмена
    • Блок платежного запроса
    • Блок платежного отклика
    • Блок подписи
    • Блок опций торгового протокола
    • Блок выьора TPO

    Блок ссылок транзакции определен в разделе 3.3.

    8.1. Блок опций торгового протокола

    Торговый блок TPO содержит опции, которые применяются в транзакции IOTP. Определение торгового блока TPO представлено ниже.

    <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
    <!ATTLIST TpoBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок опций торгового протокола транзакции IOTP (смотри раздел 3.4).

    Cодержимое:

    ProtocolOptions

    Компонент протокольных опций (смотри раздел 7.1) определяет опции, которые распространяются на всю транзакцию IOTP (смотри раздел 9).

    BrandList

    Этот компонент списка видов платежа содержит один или более видов протоколов и типов платежа, которые можно выбрать (смотри раздел 7.7).

    Org

    Компоненты Organisation (смотри раздел 7.6) идентифицируют организации и их роли в транзакции IOTP. Роли и организации, которые должны присутствовать, зависят от конкретного типа транзакции. Определения каждой транзакции смотри в разделе 9.

    Блок TPO должен содержать:

    • компонент протокольных опций;
    • компонент Organisation с торговой ролью Продавца;
    • компонент Organisation с торговой ролью Покупателя;
    • опционно, компонент организации торговой ролью DeliverTo, если транзакция предполагает доставку;
    • компоненты списка видов платежа для каждого платежа транзакции;
    • компоненты Organisation для Кассира, включенного в транзакцию;
    • опционно, компоненты Organisation для Агента доставки (если имеется) транзакции;
    • дополнительные компоненты Organisation, которые Продавец захочет включить. Например.

     

    - Агент обслуживания Покупателя;

     

    - источник сертификатов, который предлагает "коды доверия (Credentials)" Продавца или какую-то другую гарантию на товары или услуги.

    8.2. Блок выбора TPO

    Блок выбора TPO содержит результаты выбора, сделанного из списка, содержащегося в блоке протокольных опций (смотри раздел 8.1). Определение блока выбора TPO предлагается ниже.

    <!ELEMENT TpoSelectionBlk (BrandSelection+) >
    <!ATTLIST TpoSelectionBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок выбора TPO транзакции IOTP.

    Cодержимое:

    BrandSelection

    Идентифицирует выбор вида платежаи платежного протокола, которы следует использовать при оплате в транзакции IOTP. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждого предстоящего платежа транзакции IOTP.

    Блок выбора TPO должен содержать по одному компоненту выбора вида платежа для каждого списка видов платежа блока TPO.

    8.3. Блок отклика Offer

    Блок отклика Offer содержит подробности о товарах, услугах, сумме, инструкций доставки или финансовых операциях, которые должны быть осуществлоены. Его определение дано ниже.

    <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
    <!ATTLIST OfferRespBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок отклика Offer транзакции.

    Cодержимое:

    Status

    Содержит статусную информацию об успехе или неудаче подготовки предложения (смотри раздел 4.2). Заметим, что в блоке отклика Offer, значения ProcessState NotYetStarted или InProgress являются нелегальными.

    Order

    Компонент Order содержит подробности о товарах, услугах или финансовой операции, которая имеет место, смотри раздел 7.5.

    Компонент Order должен присутствовать, если только атрибут ProcessState компонента Status не равен Failed.

    Payment

    Компоненты Payment содержат информацию о платежах, которые надлежит произвести, смотри раздел 7.9.

    Delivery

    Компонент Delivery содержит детали предстоящей доставки (смотри раздел 7.13).

    TradingRoleData

    Компонент информации о торговой роли содержит данными должны обменяться торговые роли, вовлеченные в транзакцию (смотри раздел 7.17).

    Блок отклика Offer должен содержать:

    • компонент Order транзакции;
    • компоненты Payment для каждой проплаты транзакции;
    • компонент Delivery транзакции (если предусмотрено).

    8.4. Блок запроса аутентификации

    Блок запроса аутентификации содержит данные, которые используются одной из торговых ролей для получения информации и опционно для аутентификации другой торговой роли. Этот блок содержит:

    • информацию о том, как аутентифицировать себя и/или
    • запрос о дополнительной информации об организации, которую надлежит аутентифицировать.

    Его определение предагается ниже.

    <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
    <!ATTLIST AuthReqBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок запроса аутентификации транзакции.

    Cодержимое:

    AuthReq

    Каждый компонент запроса аутентификации (смотри раздел 7.2) описывет альтернативный путь, с помощью которого получатель запроса аутентификации может себя аутентифицировать, генерируя компонент отклика аутентификации (смотри раздел 7.3).

    Если присутствует один компонент запроса аутентификации, тогда именно он и должен использоваться. Если присутствует несколько компонентов запроса аутентификации, тогда получатель должен выбрать один компонент, основываясь на своих предпочтениях и возможностях программного обеспечения.

    Если нет ни одного компонента запроса аутентификации, это означает, что блок аутентификационного запроса запрашивает присылку компонентов Organisation, как это специфицировано в компоненте информационного запроса торговой роли.

    TradingRoleInfoReq

    Компонент информационного запроса торговой роли (смотри раздел 7.4) содержит список торговых ролей, данные о которых запрашиваются.

    В аутентификационном блоке должен быть по крайней мере один компонент (аутентификационного запроса или информационного запроса торговой роли), в противном случае имеет место ошибка.

    8.5. Блок отклика аутентификации

    Блок отклика аутентификации содержит отклик, который является результатом обработки блока запроса аутентификации. Его определение представлено ниже.

    <!ELEMENT AuthRespBlk (AuthResp?, Org*) >
    <!ATTLIST AuthRespBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок отклика аутентификации транзакции.

    Cодержимое:

    AuthResp

    Опционный компонент аутентификационного отклика, который содержит результаты обработки компонента запроса аутентификации - смотри раздел 7.3.

    Org

    Опционные компоненты Organisation, которые содержат информацию, соответствующую торговым ролям, как это запрошено атрибутом TradingRoleList компонента информационного запроса торговой роли.

    Компоненты, присутствующие в блоке отклика аутентификации должны согласовываться с требованиями соответствующего блока аутентификационного запроса, в противном случае имеет место ошибка.

    8.6. Блок состояния аутентификации

    Блок состояния аутентификации индицирует успех или неудачу верификации блока отклика аутентификации аутентификатором. Его определение представлено ниже.

    <!ELEMENT AuthStatusBlk (Status) >
    <!ATTLIST AuthStatusBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок состояния аутентификации транзакции.

    Cодержимое:

    Status

    Содержит статусную информацию об успехе или неудаче аутентификации (смотри раздел 4.2).

    8.7. Блок платежного запроса

    Блок платежного запроса содержит информацию, которая запускает процедуру платежа. Его описание представлено ниже.

    <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
    Payment, PaySchemeData?, Org*, TradingRoleData*)>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок платежного запроса транзакции.

    Cодержимое:

    Status

    Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., отклика Offer и/или Payment), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Платеж может состояться лишь тогда, когда все предыдущие шаги были успешными.

    BrandList

    Компонент списка видов платежа содержит список из одного или более видов платежа и протоколов, которые могут быть выбраны (смотри раздел 7.7).

    BrandSelection

    Идентифицирует выбор вида платежа, платежного протокола и Кассира, которые должны быть использованы при оплате в данной транзакции. Имеется один компонент выбора вида платежа (смотри раздел 7.8) для каждой проплаты, которую следует выполнить в процессе транзакции.

    Payment

    Компоненты Payment содержит информацию о платеже, который выполняется, смотри раздел 7.9.

    PaySchemeData

    Компонент Payment Scheme содержит специфические данные о платежной схеме, смотри раздел 7.10.

    Org

    Компонент Organisation содержит подробности об организациях, вовлеченных в платеж (смотри раздел 7.6). Присутствие организаций зависит от транзакции и данных, которые должны быть подписаны. Смотри раздел 6.

    TradingRoleData

    Компонент данных о торговой роли содержит информацию, которая нужна для пересылки между торговыми ролями, вовлеченными в транзакцию (смотри раздел 7.17).

    Блок платежного запроса должен содержать:

    • Компонент Organisation с торговой ролью продавца;
    • Компонент Organisation с торговой ролью Покупателя;
    • Компонент Payment для платежа;
    • Компонент Brand List;
    • Компонент выбора вида платежа из списка;
    • Компонент Organisation для Кассира, осуществляющего платеж;
    • Компонент Organisation (если такоая имеется) для организации, которая выполнила предыдущий шаг, например другой Кассир;
    • Компонент Organisation для организации, которая выполняет следующий шаг. Это может быть, например, Агент доставки или Кассир;
    • Компонент Organisation для любых дополнительных организаций, которые Продавец включил в блок отклика Offer;
    • Опционный компонент данных платежной схемы, если это требуется методом платежа, определенном в приложении IOTP;
    • Любой компонент информации о платежной роли, который может потребоваться (смотри раздел 7.17.1).

    8.8. Блок платежного обмена

    Блок платежного обмена содержит специфические данные о платежной схеме, которыми обмениваются две торговые роли в рамках сделки. Его определение представлено ниже.

    <!ELEMENT PayExchBlk (PaySchemeData+)>
    <!ATTLIST PayExchBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок платежного обмена транзакции.

    Cодержимое:

    PaySchemeData

    Этот торговый компонент содержит специфические данные о платежной схеме, смотри раздел 7.10.

    8.9. Блок платежного отклика

    Этот блок платежного отклика содержит информацию о состоянии платежа, опционной платежной расписке и опционные сообщения платежного протокола. Его определение представлено ниже.

    <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
    PaymentNote?, TradingRoleData*)>
    <!ATTLIST PayRespBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок платежного отклика транзакции.

    Cодержимое:

    Status

    Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) платежа. Заметим, что в блоке платежного отклика, значения ProcessState NotYetStarted или InProgress являются нелегальными.

    PayReceipt

    Содержит специфические данные о платежной схеме, которые могут быть использованы для верификации произведенного платежа. Смотри раздел 7.11. Он должен присутствовать, если атрибут ProcessState компонента Status равен CompletedOk. Атрибут PayReceipt является опционным.

    PaySchemeData

    Содержит специфические данные о платежной схеме, например, о сообщениях платежного протокола. Смотри также раздел 7.10.

    PaymentNote

    Содержит дополнительную, несвязанную с платежом информацию, которую кассир желает предоставить покупателю. Например, если выполнен отзыв сделки или осуществлен депозит, он может содержать данные о полученном балансе на счету, после того как данная операция завершена. Смотри раздел 7.12.

    TradingRoleData

    Компонент информации о торговой роли содержит данные, которые нужны для обмена между ролями, участвующими в транзакции (смотри раздел 7.17).

    8.10. Блок запроса доставки

    Блок запроса доставки содержит подробности о товарах или услугах, которые должны быть предоставлены вместе с подписью, которая позволяет удостовериться, что доставка была авторизована. Его определение приведено ниже.

    <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
    ConsumerDeliveryData?, TradingRoleData*)>
    <!ATTLIST DeliveryReqBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок запроса доставки транзакции.

    Cодержимое:

    Status

    Содержит компоненты Status (смотри раздел 7.13) откликов на шаги (напр., платежный отклик), от которых данный шаг зависит. Он используется чтобы индицировать успех или неудачу этих шагов. Доставку следует осуществлять только если все прдыдущие шаги завершились успешно.

    Order

    Компонент Order содержит подробности о товарах, услугах или финансовых операциях, которые имеют место, смотри раздел 7.5. Комоненты Organisation (смотри раздел 7.6) идентифицируют организации их роли.

    Org

    Транзакция IOTP. Роли и организации, которые должны присутствовать зависят от конкретного типа транзакции. Описания транзакций смотри в разделе 9.

    Delivery

    Компонент Delivery содержит подробности доставки, которую следует осуществить (смотри раздел 7.13).

    ConsumerDeliveryData

    Опционный. Содержит идентификатор, специфицированный Покупателем, который в случае возвращения Агентом доставки позволяет покупателю определить, о какой доставке идет речь.

    TradingRoleData

    Компонент данных о торговой роли содержит информацию, которая нужна при обмене между двумя торговыми ролями в процессе транзакции (смотри раздел 7.17).

    Блок запроса доставки содержит:

    • Компонент Organisation с торговой ролью Продавца;
    • Компонент Organisation для торговых ролей Покупателя и DeliverTo;
    • Компонент Delivery;
    • Компонент Organisation для Агента доставки. В частности компонент Organisation, идентифицированный атрибутом ActionOrgRef компонента Delivery;
    • Компонент Organisation (если имеется) для организации, которая осуществила предыдущий шаг, например Кассира;
    • Компоненты Organisation для любой дополнительной организации, которую Продавец включил в блок отклика Offer;
    • Любые компоненты данных о торговой роли, которая может потребоваться (смотри раздел 7.17.1).

    8.11. Блок отклика доставки

    Блок отклика доставки содержит Delivery Note, содержащую подробности о том как будут доставляться товары. Его определение представлено ниже. Заметим, что в блоке отклика Delivery элемент состояния доставки с DeliveryStatusCode равным NotYetStarted или InProgress является нелегальным.

    <!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
    <!ATTLIST DeliveryRespBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок отклика доставки транзакции.

    Cодержимое:

    Status

    Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) доставки. Заметим, что в блоке отклика Delivery, ProcessState равный NotYetStarted или InProgress считается нелегальным.

    DeliveryNote

    Компонент Delivery Note содержит подробности о том, как будут доставляться товары или услуги (смотри раздел 7.15).

    8.12. Торговый блок информационного запроса

    Торговый блок информационного запроса содержит компоненттип запроса и опционно платежной схемы.

    <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
    <!ATTLIST InquiryReqBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет торговый блок информационного запроса транзакции.

    Cодержимое:

    InquiryType

    Компонент тип информационного запроса (смотри раздел 7.18), который содержит код типа запроса.

    PaySchemeData

    Компонент платежная схема (Payment Scheme) (смотри раздел 7.10), который содержит специфические данные конкретных информационных запросов о платежной схеме. Он присутствует, когда атрибут Type компонента типа запроса равен Payment.

    8.13. Торговый блок информационного отклика

    Торговый блок информационного отклика содержит компонент Status и опционно компонент Payment Scheme. Его целью является осуществление запроса о текущем состоянии транзакции или сервера.

    <!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
    <!ATTLIST InquiryRespBlk ID ID #REQUIRED
    LastReceivedIotpMsgRef NMTOKEN #IMPLIED
    LastSentIotpMsgRef NMTOKEN #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет торговый блок информационного отклика транзакции.

    LastReceivedIotpMsgRef

    Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое получил данный сервер от покупателя. Если до этого не получено от покупателя ни одного сообщения, этот атрибут должен содержать значение (Null). Данный атрибут предназначен для отладочных целей.

    LastSentIotpMsgRef

    Содержит ссылку элемента (смотри раздел 3.5) на Id-компонент (смотри раздел 3.3.2) последнего сообщения, которое послал данный сервер покупателю. Если до этого не послано ни одного сообщения покупателю, данный атрибут должен содержать значение (Null). Этот атрибут предназначен для отладочных целей.

    Cодержимое:

    Status

    Содержит статусную информацию об успехе или неудаче (смотри раздел 4.2) определенного торгового обмена (т.e., предложения, платежа или доставки).

    PaySchemeData

    Компонент Payment Scheme (смотри раздел 7.10), который содержит специфические информационные запросы по поводу платежной схемы. Он присутствует, когда атрибут Type атрибута StatusType компонента Status равен Payment.

    8.14. Блок запроса Ping

    Блок запроса Ping используется, чтобы определить, работает ли сервер и является ли криптография совместимой.

    Определение блока запроса Ping предложено ниже.

    <!ELEMENT PingReqBlk (Org*)>
    <!ATTLIST PingReqBlk ID ID #REQUIRED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет запрос Ping торгового блока транзакции.

    Cодержимое:

    OrgОпционные компоненты Organisation (смотри раздел 7.6).

    Если нет ни одного компонента Organisation, тогда запрос Ping является анонимным и служит для проверки, работает ли сейчас сервер.

    Однако, если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping хочет проверить, могут ли быть обработаны цифровые подписи.

    В этом случае отправитель включает:

    • Компонент Organisation, который идентифицирует сам себя, специфицируя торговую роль (или роли), которую он исполняет в транзакции (Продавец, Кассир, и т.д.)
    • Компонент Organisation, который идентифицирует получателя сообщения.

    Эти компоненты используются для формирования подписи блока отклика Ping.

    8.15. Блок отклика Ping

    Блок отклика Ping предоставляет результат выполнения запроса Ping. Он содержит компонент Organisation, который идентифицирует отправителя отклика Ping.

    Если запрос Ping, для которого этот блок является откликом, содержал компоненты Organisation, тогда он также содержит эти компоненты Organisation.

    <!ELEMENT PingRespBlk (Org+)>
    <!ATTLIST PingRespBlk ID ID #REQUIRED
    PingStatusCode (Ok | Busy | Down) #REQUIRED
    SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
    xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет торговый блок запроса Ping транзакции.

    PingStatusCode

    Содержит код, который показывает состояние программы отправителя, которая обрабатывает IOTP-сообщения. Допустимыми значениями являются:

    o Ok. Сервис работает нормально, включая проверку подписей.
    o Busy. Все идет хорошо, но возможны некоторые задержки.
    o Down. Сервер не вполне функционален, но все же может выдать отклик Ping.

    SigVerifyStatusCode

    Заключает в себе код, который показывает состояние проверки подписи. Он присутствует только когда сообщение, содержащее блок запроса Ping имеет также блок Signature. Допустимы следующие значения:

    o Ok. Веоификация подписи прощла успешно.
    o NotSupported. Получатель блока запроса Ping не поддерживает валидацию подписей.
    o Fail. Верификация подписи не прошла.

    Xml:lang

    Определяет язык, использованный в PingStatusDesc. Присутствует тогда, когда имеется PingStatusDesc.

    PingStatusDesc

    Содержит короткое описание состояния сервера, который поылает этот блок отклика Ping. Сервер, если его разработчики хотят, может использовать этот атрибут для посылки более детальной информации, чем содержится в PingStatusCode, он может использоваться, например, для отладрчных целей.

    Cодержимое:

    Org

    Компоненты Organisation (смотри раздел 7.6).

    Компоненты Organisation отправителя отклика Ping всегда содержат кроме того компоненты Organisation, посланные в запросе Ping.

    Значения статусного кода Ping не включают в себя такие значения как Fail, так как, когда программа, получающая сообщение запроса Ping, не работает, не будет послано никакого отклика Ping.

    8.16. Блок подписи

    Блок Signature содержит один или более компонентов Signature и соответствующих сертификатов (если требуется), которые подтверждают данные в рамках данной транзакции. Определение компонента Signature и сертификатов содержится в статье "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Описание их применения в IOTP можно найти в разделах 7.19 и 7.20.

    Определение блока Signature представлено ниже:

    <!ELEMENT IotpSignatures (Signature+, Certificate*) >
    <!ATTLIST IotpSignatures ID ID #IMPLIED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок подписи транзакции.

    Cодержимое:

    Signature

    Компонент Signature. Смотри раздел 7.19.

    Certificate

    Компонент Certificate. Смотри раздел 7.20.

    Содержимое блока Signature зависит от торгового блока, который содержится в том же сообщении, что и блок Signature.

    8.16.1. Блок подписи в отклике предложении

    Блок подписи, который содержится в том же сообщении, что и блок отклика Offer, несет в себе только компонент подписи отклика Offer (смотри раздел 7.19.2).

    8.16.2. Блок подписи в платежном запросе

    Блок Signature, который содержится в том же сообщении, что и блок платежного запроса, содержит в себе:

    • Компонент подписи отклика Offer (смотри раздел 7.19.2) и
    • Если поатеж зависит от предыдущего шага (как указано атрибутом StartAfter компонента Payment), тогда компонент подписи платежной расписки (смотри раздел 7.19.3) генерируется на предыдущем этапе (шаге).

    8.16.3. Блок подписи в платежном отклике

    Блок подписи, который содержится в том же сообщении, что и блок платежного отклика, содержит только компонент подписи платежной расписки (смотри раздел 7.19.3), сформированной на этом этапе (шаге).

    8.16.4. Блок подписи в запросе доставки

    Блок подписи, который содержится в том же сообщении, что и блок запроса доставки, содержит:

    • Компонент подписи отклика Offer (смотри раздел 7.19.2) и
    • Компонент подписи платежной расписки (смотри раздел 7.19.3), сформированный на предшествующем шаге.

    8.16.5. Блок подписи в отклике доставки

    Блок Signature, который содержится в том же сообщении, что и блок отклика доставки, содержит только компонент подписи отклика Delivery (смотри раздел 7.19.4), сформированный на этом шаге.

    8.17. Блок ошибки

    Торговый блок Error содержит один или более компонентов Error (смотри раздел 7.21), которые несет в себе информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, полученном одной из торговых ролей, вовлеченных в сделку.

    Ниже представлены две фразы, которые используются в описании торгового блока Error:

    • ошибочное сообщение. Сообщение IOTP, которое содержит или является причиной ошибки какого-то рода;
    • сообщение, опровещающее об ошибке. Сообщение IOTP, которое содержит торговый блок Error, описывающий ошибку, найденную в сообщении.

    Торговый блок Error может содержаться в любом сообщении, уведомляющем об ошибке. Реакция на такое сообщение зависит от серьезности (severity) ошибки. Разъяснения различных значений серьезности ошибки (и сопряженных с ними действий) дано в определении компонента Error.

    Несмотря на то что торговый блок Error может уведомлять о многих различных ошибках, используя несколько компонентов Error, разработчики приложений могут и не поддерживать такую возможность.

    Структура торгового блока Error представлена ниже.

    <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
    <!ATTLIST ErrorBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок Error транзакции.

    Cодержимое:

    ErrorComp

    Компонент Error (смотри раздел 7.21), который содержит информацию об индивидуальной технической ошибке.

    PaySchemeData

    Опционный компонент Payment Scheme (смотри раздел 7.10), который содержит описание платежной схемы.

    8.18. Блок Cancel

    Блок Cancel используется одной торговой ролью чтобы информировать остальных о том, что транзакция аннулируется. Пример использования включает в себя:

    • Роль Покупателя, информирующую других о том, что он не собирается продолжать транзакцию. Это позволяет серверу завершить транзакцию, не дожидаясь таймаута.
    • Роль, отличная от покупателя, информирует Покупателя о том, что транзакция останавливается. В этом случае Покупатель вряд ли повторно пошлет предыдущее сообщение в предположении, что оно не было получено.

    Его определение имеет вид.

    <!ELEMENT CancelBlk (Status) >
    <!ATTLIST CancelBlk ID ID #REQUIRED >

    Атрибуты:

    ID

    Идентификатор, который однозначно определяет блок Cancel транзакции.

    Cодержимое:

    Status

    Содержит статусную информацию, указывающую, что транзакция была аннулирована.

    9. Транзакции IOTP

    Базовая версия протокола IOTP поддерживает три типа транзакций. Среди них:

    • Транзакции аутентификации IOTP, которые поддерживают аутентификацию одного партнера сделки другим партнером и/или получение информации о другой торговой роли.
    • Транзакции IOTP, которые включают в себя один или более платежей. В частности:

    - Депозит
    - Покупка
    - Возврат денег
    - Отзыв сделки
    - Обмен ценностями

    • Транзакции IOTP предназначенные для проверки корректности функционирования инфраструктуры. В частности:

    - Транзакция запроса состояния и
    - Ping

    Хотя транзакции аутентификации могут выполняться сами по себе, опционно любая платежная операция может предшествоваться аутентификацией. Остальная часть данного раздела поделена на две части, где описывается:

    • Аутентификационные и платежные транзакции (аутентификация, депозит, покупка, возврат денег, аннулирование сделки и обмен ценностями)
    • Инфраструктурные транзакции (транзакция запроса состояния и Ping), которые предназначены для поддержки запросов о том, успешно ли прошла транзакция или правильно ли работает сервер торговой роли.

    9.1. Транзакции аутентификации и платежа

    Транзакции, имеющие отношение к аутентификации и платежу состоят из шести документальных обменов, которые объединяются в последовательности, чтобы реализовать определенную транзакцию.

    Вообще имеется теснаое но не точное соответствие между документальным и торговым обменами. Главное отличие заключается в том, что некоторые документальные обмены включают в себя часть или все два торговых обменов одновременно для того чтобы минимизировать число IOTP-сообщений, посылаемых через Интернет.

    Эти шесть документальных обменов включают в себя:

    • Аутентификация. Это прямая реализация аутентификации торгового обмена;
    • Предложение (Offer), зависимое от вида платежа. Это торговый обмен предложения, объединенный с платежным обменом выбора вида платежа. Его целью является обеспечение Продавца информацией о выборе вида платежа;
    • Предложение, не зависимое от вида платежа. Это также торговый обмен предложения (Offer). Однако в этом случае содержимое отклика Offer не зависит от выбора вида платежа;
    • Платеж. Это непосредственная реализация платежной части торгового обмена;
    • Доставка. Это прямая реализация обмена доставки;
    • Доставка с платежом. Это реализация совмещеных торговых обменов платежа и доставки.

    Эти документальные обмены скомбинированы вместе в различные последовательности, чтобы реализовать каждую из транзакций. Способ, которым они могут комбинироваться проиллюстрирован на рис. .17.

    Рис. .17. Блок-диаграмма обмена сообщениями платежа и аутентификации

    Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP.

    Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).

    9.1.1. Документальный обмен аутентификации

    Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:

    o

    Аутентификатор организация, которая запрашивает аутентификацию;

    o

    Аутентифицируемый - организация, которая должна пройти аутентификацию.

    Аутентификация состоит из:

    • Запрос аутентификации, посылаемый аутентификатором аутентифицируемому,
    • Отклик аутентификации, посылаемый аутентифицируемым аутентификатору в ответ на запрос. Отклик проверяется аутентификатором, результат этой проверки посылается аутентифицируемому, который из этой статусной информации узнает, прошел он аутентификацию или нет.

    Документальный обмен аутентификации предполагает также:

    • Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и
    • Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого.

    Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене представлены на рис. .18.

    1.

    Первая организация предпринимает некоторое действие (например, нажимает кнопку на HTML-странице), которое требует аутентификации

    1 à 2

    Необходимость аутентификации (за пределами протокола IOTP)

    2.

    Вторая организация генерирует: блок запроса аутентификации, содержащий один или несколько компонентов запроса аутентификации и/или компонент информационного запроса о торговой роли, которые посылаются первой организации

    1 ß 2

    Запрос TPO & аутентификации. Сообщение IotpMsg: блоки TransRef; Signature (опционно); TPO; запроса аутентификации

    3

    Запускается приложение IOTP. Если присутствует блок Signature, первая организацияможет использовать проверку параметров доверия (credentials) второй организации. Если все в порядке, первая организация выбирает запрос аутентификации (если присутствует или их более одного), и запускает аутентификационный алгоритм для формирования блока отклика аутентификации. Для генерации компонентов Organisation, если требуется, используетсякомпонент запроса данных о торговой роли. Наконец создается, если нужно, компонент Signature и все компоненты посылаются второй организации для проверки.

    1 à 2

    Отклик аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно) ; Auth Response

    4.

    Вторая организация проверяет отклик Authentication, сопостовляя его с блоком запроса и убеждаясь, что первая организация именно та, за которую она себя выдает. По результатам проверки первой организации посылается статусный блок аутентификации.

    1 ß 2

    Состояние аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно); Auth Response

    5.

    Первая организация проверяет статусный блок и, если все в порядке, завершает транзакцию.

    Рис. .18. Документальный обмен аутентификации

    9.1.1.1. Принципы обработки сообщений

    При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:

    • сформировать и послать аутентификатору сообщение-отклик аутентификации или
    • обнаружив ошибку в запросе аутентификации, послать аутентификатору блок Cancel, содержащий компонент Status аутентификации с атрибутом StatusType и/или ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: AutEeCancel, NoAuthReq, TradRolesIncon или Unspecified.

    Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:

    • атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или
    • атрибут ProcessState = Failed, а атрибут CompletionCode =: AutOrCancel, AuthFailed или Unspecified, в случае неудачи аутентификации,

    Получив сообщение состояния аутентификации (смотри ниже), аутентифицируемый должен проверить компонент Status в блоке состояния. Если он указывает на:

    o

    успех аутентификации, тогда аутентифицируемый должен сделать следующее:

    -

    продолжить следующий шаг транзакции, частью которой является документальный обмен аутентификации, или

    -

    индицировать отказ продолжения транзакции путем посылки аутентификатору блока Cancel, содержащего компонент Status с атрибутом аутентификации StatusType, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) = AutEeCancel.

    o

    аутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен.

    Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола.

    9.1.1.2. Сообщение запроса аутентификации и TPO

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

    • блок опций торгового протокола (смотри раздел 8.1),
    • блок запроса Authentication (смотри раздел 8.4) и
    • опционный блок Signature (смотри раздел 8.16).

    Каждый из них описан ниже.

    Блок опций торгового протокола

    Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

    • один компонент протокольных опций (смотри раздел 7.1), который определяет опции, работающие для всего документального обмена аутентификации.
    • один компонент Organisation (смотри раздел 7.6), который описываетаутентификатор. Компонент торговой роли организации должен указывать на роль, какую играет аутентификатор в данной сделке, например Пордавец или Покупатель.

    Блок запроса аутентификации

    Блок запроса аутентификации (смотри раздел 8.4) должен содержать следующие торговые компоненты:

    • один компонент запроса аутентификации (смотри раздел 7.2), и

    Блок подписи (Запрос аутентификации)

    Если запрос аутентификации был снабжен цифровой подписью, то должен быть включен блок Signature. Он содержит дайджесты следующих XML-элементов:

    o

    блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию;

    o

    Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;

    o

    следующие компоненты блока TPO:

     

    - компонент протокольных опций;

     

    - компонент Organisation.

    • следующие компоненты блока запроса аутентификации:
     

    - компонент запроса аутентификации

     

    - компонент информационного запроса о торговой роли

    9.1.1.3. Сообщение-отклик аутентификации IOTP

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

    • блок отклика Authentication (смотри раздел 8.5) и
    • опционный блок Signature (смотри раздел 8.16).

    Блок отклика AUTHENTICATION
    Блок отклика аутентификации должен содержать следующие торговые компоненты:

    • один компонент отклика аутентификации (смотри раздел 7.3)
    • один компонент Organisation для каждой торговой роли, идентифицированной в атрибуте TradingRoleList компонента информационного запроса о торговой роли, содержащегося в блоке запроса аутентификации.

    Блок SIGNATURE (Отклик аутентификации)

    Если элемент Algorithm (смотри раздел 12) компонента запроса аутентификации содержащийся в блоке запроса аутентификации, указывает, что отклик аутентификации должен содержать цифровую подпись, тогда блок Signature должен быть включен в то же сообщение, где размещается блок отклика аутентификации. Компонент Signature содержит элементы дайджестов для следующиз XML-элементов:

    • блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию IOTP;
    • Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
    • следующие компоненты блока запроса аутентификации:
     

    - компонент запроса аутентификации;

     

    - компонент информационного запроса о торговой роли;

    • компоненты Organisation, содержащиеся в блоке отклика аутентификации.

    Не следует предполагать, что все торговые роли могут поддерживать цифровую подпись данных. В частности не нужно думать, что эта опция поддерживается Покупателем.

    9.1.1.4. Сообщение состояния аутентификации

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:

    • блок состояния аутентификации (смотри раздел 8.5) и
    • опционный блок Signature (смотри раздел 8.16).

    Блок состоояния аутентификации

    Блок состоояния аутентификации (смотри раздел 8.6) должен содержать следующие торговые компоненты:

    • один компонент Status (смотри раздел 7.16) с атрибутом ProcessState = CompletedOk.

    Блок SIGNATURE (состояние аутентификации)

    Если блок состояния аутентификации подписан цифровым образом, тогда блок Signature должен включать то что содержать дайджесты следующих XML-элементов:

    • блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение IOTP и транзакцию;
    • Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
    • Следующие компоненты блока состояния аутентификации:

    - компонент Status (смотри раздел 7.16).

    Если за документальным обменом аутентификации следует документальный обмен предложения (Offer) (смотри раздел 9.1.2), тогда блок состояния аутентификации и блок подписи (состояние аутентификации) могут объединяться с:

    • сообщение TPO (смотри раздел 9.1.2.3), или
    • сообщение TPO и отклик Offer (смотри раздел 9.1.2.6)

    9.1.2. Обмен документами предложения

    Обмен документами предложения oвстречается в двух формах:

    • обмен предложения, зависящего от вида платежа. Где содержимое предложения, напр., детали заказа, сумма, детали доставки, и т.д., зависят от вида платежа и протокола, выбранных покупателем;
    • обмен предложения, не зависящего от вида платежа. Где содержимое предложения не зависит от выбранного вида платежа или протокола.

    Каждый из этих типов документального обмена предложения может следовать за бокументальным обменом аутентификации (смотри раздел 9.1.1).

    9.1.2.1. Документальный обмен предложения, зависящего от вида платежа

    В документальном обмене предложения, зависящего от вида платежа блоки TPO отклика Offer посылаются отдельно продавцом покупателю, т.e.:

    • комонент списка вида платежа посылается покупателю в блоке TPO;
    • Покупатель выбирает вид платежа, платежный протокол и опционно вид валюты из компонента видов платежа;
    • Покупатель посылает выбранные вид платежа, протокол и валюту продавцу в блоке выбора TPO;
    • Продавец использует полученную информацию, чтобы определить содержимое и затем послать блок отклика Offer покупателю.

    Это проиллюстрировано на диаграмме ниже (рис. .19).

    1.

    Покупатель решает совершить покупку и посылает продавцу информацию (напр., используя HTML), которая позволяет продавцу сформировать предложение,

    C à M

    Информация предложения - вне области действия IOTP

    2.

    Продавец решает, какой платежный протокол, валюту и пр. использовать, помещает эти данные в компонент видов платежа в блоке TPO и посылает покупателю

    C ß M

    TPO (опции торгового протокола). IotpMsg: блоки Trans Ref Block; TPO

    3.

    Приложение IOTP запущено. покупатель выбирает вид платежа, платежный протоколи вид валюты. Компонент выбора вида платежа посылается Продавцу.

    C à M

    Выбор TPO. IotpMsg: блоки Trans Ref Block и выбора TPO

    4.

    Продавец использует выбранный вид платежа, плптежный протокол, валюту и информацию предложения для формирования блока отклика Offer, содержащего детали транзакции IOTP, включая цену, и т.д., опционно подписывает его и посылает покупателю

    C ß M

    Отклик OFFER. IotpMsg: блоки Trans Ref, Signature (опционный) и отклика Offer

    5.

    Покупатель проверяет все ли в порядке в Offer, затем комбинирует компоненты из блоков TPO, выбора TPO и отклика Offer, чтобы сформировать следующее сообщение транзакции, и посылает его вместе с блоком подписи (если таковая нужна) соответствующей торговой роли

    . продолжение ...
    Рис. .19. Документальный обмен предложения, зависимого от вида платежа

    Покупатель идентифицирует документальный обмен предложения, зависимого от вида платежа, с помощью отсутствия блока отклика Offer в первом сообщении IOTP.

    Обработка сообщений

    Получив сообщение TPO (смотри ниже), Покупатель может:

    • сформировать и послать сообщение выбора TPO Продавцу, или
    • индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

    Получив сообщение выбора TPO (смотри ниже), Продавец может:

    • сформировать и послать сообщение отклика Offer Покупателю, или
    • индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: MerchCancelled или Unspecified.

    Получив сообщение отклика Offer (смотри ниже), Покупатель может:

    • сформировать и послать следующее сообщение транзакции IOTP соответствующей торговой роли. Это зависит от типа транзакции, или
    • индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState =of Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.

    Если продавец получает сообщение IOTP, содержащее блок Cancel, покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation продавца. Если покупатель получает сообщение, содержащее блок Cancel, тогда информация, содержащаяся в сообщении должна быть доведена до сведения покупателя.

    9.1.2.2. Документальный обмен предложения, независимого от вида платежа

    В документальном обмене предложения, независящего от вида платежа, блоки TPO и отклика Offer посылаются вместе от продавца к покупателю, т.e. имеется одно сообщение IOTP, которое содержит блоки TPO и отклика Offer.

    Обмен сообщениями проиллюстрирован на рис. .20 ниже:

    1.

    Покупатель решает заключить сделку и посылает продавцу информацию (напр., используя HTML), которая позволяет ему подготовить предложение,

    C à M

    Информация предложения - вне пределов действия IOTP

    2.

    Продавец решает, какой применить платежный протокол и валюту, помещает эти данные в компонент списка видов платежа в блок TPO, формирует отклик Offer, содержащий некоторые детали транзакции, например цену, опционно подписывает эту информацию и посылает покупателю

    C ß M

    Отклик TPO & OFFER. IotpMsg: блоки Trans Ref; Signature; TPO; отклика Offer

    3.

    Запускается приложение IOTP. Покупатель выбирает вид платежа, платежный протокол, валюту. Записывает свой выбор в компонент выбора вида платежа, проверяет предложение и, если все в порядке, комбинирует компонент выбора вида платежа и информацию из блоков TPO Block и отклика Offer, чтобы сформировать следующее сообщение транзакции и послать его соответствующей торговой роли.

    . Продолжение ...
    Рис. .20. Обмен для предложения, независимого от вида платежа

    Заметим, что документальный обмен предложения, независимого от видов платежа происходит, когда продавец предлагает покупателю лишь один вид платежа, протокол и вид валюты. Это может произойти и при нескольких предлагаемых видах платежа, если имеется один Кассир и все виды платежа используют один и тот же набор протоколов.

    Заметим, что блоки TPO и отклика Offer могут быть посланы в одном IOTP-сообщении (смотри документальный обмен предложения, зависимого от вида платежа), даже если блок отклика Offer не изменяется. Однако это увеличивает число сообщений в транзакции и следовательно может увеличить время отклика.

    Приложения, поддерживающие торговую роль Покупателя, должны проверять наличие блока отклика Offer в первом сообщении IOTP с тем чтобы определить, является ли обмен зависимым от вида платежа.

    Принципы обработки сообщений

    Получив сообщение TPO и отклика Offer (смотри ниже), Покупатель может:

    • сформировать и послать следующее сообщение IOTP транзакции соответствующей торговой роли. Это зависит от разновидности транзакции.
    • индицировать отказ, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

    Если продавец поличает сообщение, содержащее блок Cancel, тогда Покупатель вероятно направится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation для Продавца.

    9.1.2.3. Сообщение TPO

    Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже.

    Блок TPO (TRADING PROTOCOL OPTIONS)

    Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:

    • Один компонент протокольных опций, который определяет опции, относящиеся ко всей транзакции. Смотри раздел 7.1.
    • Один компонент списка видов платежа (смотри раздел 7.7) для каждого платежа в транзакции, который содержит один или болеее видов платежа и протоколов, которые могут быть выбраны для каждой из проплат.
    • Компоненты Organisation (смотри раздел 7.6), со следующими ролями:

     

    - Продавец, который сделал предложение

     

    - Покупатель, который осуществляет транзакцию

     

    - Кассир. "ID" компонента организщации-кассира содержится в атрибуте PhOrgRef компонента платежа (Payment).

    Если транзакция IOTP включает доставку, тогда блок TPO должен содержать:

    • Компоненты Organisation со следующими ролями:
     

    - Агент доставки (DeliveryHandler), который осуществляет доставку товаров или услуг;

     

    - DelivTo т.e. лицо или организация, куда нужно выполнить доставку.

    Блоки подписи и состояния аутентификации

    Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:

    • блок состояния аутентификации (смотри раздел 8.6) и
    • опционный блок Signature (состояния аутентификации).

    Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации).

    9.1.2.4. Сообщение IOTP выбора TPO

    Сообщение выбора TPO используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок выбора TPO (смотри раздел 8.1), который описан ниже.

    Блок выбора TPO (смотри раздел 8.2) содержит:

    • Один компонент выбора вида платежа (смотри раздел 7.8) для использования в последующем платежном обмене. Он содержит результаты выбора покупателем вида платежа, платежного протокола и вида валюты из списка компонента выбора вида платежа.

    9.1.2.5. Сообщение отклик на предложение IOTP

    Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:

    • блока отклика Offer (смотри раздел 8.1) aиnd
    • опционного блока подписи (смотри раздел 8.16).

    Блок отклика предложения (блок отклика OFFER)

    Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:

    • один компонент Status (смотри раздел 7.16), который индицирует состояние отклика Offer. Атрибут ProcessState должен быть равен CompletedOk;
    • один компонент Order (смотри раздел 7.5), который содержит детали о товарах и услугах, которые покупаются, или о финансовых операциях, которые имеют место;
    • один или более компонентов (смотри раздел 7.9) для каждого платежа, которы надлежит произвести;
    • нуль или один компонент Delivery (смотри раздел 7.13), содержащий детали доставки, которую надлежит осуществить, если транзакция предполагает доставку;
    • нуль или более компонентов данных о торговой роли (смотри раздел 7.17), если это затребовано Продавцом.

    Блок подписи (отклик предложения)

    Если блок состояния аутентификации снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:

    Если отклик Offer снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:

    • блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение и IOTP-транзакцию;
    • Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию;
    • Следующие компоненты блока TPO:
     

    - компонент опций протокола и

     

    - компонент списка видов платежей;

     

    - компоненты всех организаций.

    • следующие компоненты блока отклика предложения:
     

    - компонент заказа;

     

    - все платежные компоненты;

     

    - компонент Delivery, если имеется;

     

    - любые компоненты данных о торговых ролях.

    9.1.2.6. Сообщение TPO и отклика Offer

    Сообщение TPO и отклика Offer используется только в документальном обмене предложения, независящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:

    • блок опций торгового протокола (TPO) (смотри раздел 8.1);
    • блок отклика Offer (смотри раздел 8.1) и
    • опционный блок Signature (смотри раздел 8.16).

    Блок TPO (TRADING PROTOCOL OPTIONS)

    Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3).

    Блок отклика OFFER

    Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5).

    Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6).

    Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:

    • если документальный обмен Offer является зависимым от вида платежа, тогда компонент Signature в блоке подписи дополнительно имеет элемент дайждеста для компонента выбора вида платежа, содержащегося в блоке выбора TPO;
    • если перед документальным обменом Offer имела место аутентификация, тогда компонент Signature в блоке подписи дополнительно содержит элемент дайджеста для блока состояния аутентификации.

    9.1.3. Обмен документами при платеже

    Документальный обмен платежа является непосредственной реализацией последней части платежного обмена (смотри раздел 2.2.2) после того как вид платежа выбран покупателем. Платежный обмен состоит из:

    • Покупатель формирует платежный запрос, используя информацию из предыдущего IOTP-сообщения, и посылает его кассиру;
    • Затем кассир и покупатель обмениваются платежными IOTP-сообщениями, куда инкапсулируются сообщения платежного протокола. Этот обмен происходит вплоть до завершения процедуры платежа и, наконец,
    • Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка.

    IOTP-сообщения, которые используются при платежном обмене показаны на рис. .21.

    1.

    Покупатель формирует блок платежного запроса, если необходимо, инкапсулирует в него сообщение платежного протокола, и посылает кассиру, снабжая при необходимости цифровой подписью

    C à P

    Запрос платежа. IotpMsg: блоки Trans Ref; подписи (опционный); платежного запроса

    2.

    Кассир обрабатывает блок платежного запроса, проверяет подпись, если таковая имеется, и начинает обмен с покупателем сообщениями (вложенными в блок платежного обмена) согласно платежному протоколу

    C « P

    Платежный обмен. IotpMsg: блоки Trans Ref; Pay Exchange

    3.

    Покупатель и кассир продолжают обмен платежными блоками, пока платеж не будет осуществлен и кассир не сформирует платежную расписку (которая опционно может быть снабщена цифровой подписью) и не пошлет ее покупателю. Эта операция завершает платежный обмен.

    C ß P

    Платежный отклик. IotpMsg: блоки Trans Ref; Signature (опционный); платежного отклика

    4.

    Покупатель проверяет, все ли в порядке с платежным откликом. Опционно могут регистрироваться все операции IOTP. После этого покупатель может остановиться или послать очередное сообщение IOTP (снабдив его, если требуется, подписью) соответствующей торговой роли

    Рис. .21. Обмен платежными документами

    9.1.3.1. Принципы обработки сообщений

    Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:

    • сформировать и послать сообщение платежного обмена покупателю, если этого требует платежный протокол или
    • сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
    • индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.

    Получив платежное ообщение, Покупатель может:

    • сформировать и послать платежное сообщение Кассиру или
    • индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.

    Получив платежное ообщение, кассир может:

    • сформировать и послать платежное сообщение покупателю, если этого требует платежный протокол или
    • сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
    • индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.

    Получив платежное ообщение-отклик, Покупатель может:

    • сформировать и послать следующее сообщение транзакции соответствующей торговой роли. Это зависит от разновидности транзакции,
    • остановиться, так как транзакция завершена или
    • индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

    Если покупатель получает сообщение, содержащее блок Cancel, тогда информация из сообщения IOTP должна быть доведена до сведения покупателя и не должны предприниматься никакие другие действия.

    Если кассир получает сообщение, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира, здесь он сможет предпринять некоторые дальнейшие действия.

    Если продавец получает сообщение, содержащее блок Cancel, тогда покупатель должен завершить операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца, здесь он сможет предпринять некоторые дальнейшие действия.

    9.1.3.2. Сообщение платежного запроса

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение может содержать:

    • блок платежного запроса и
    • опционный блок подписи

    Блок платежного запроса (смотри раздел 8.7) состоит из:

    • следующих компонентов копируемых из блока отклика Offer, полученного в ходе предыдущего документального обмена предложения:
     

    - компонент Status

     

    - компонент Payment для выполняемого платежа

    • следующих компонентов блока TPO:

     

    - компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса;

     

    - компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment;

    • одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:

     

    - скопирован из блока выбора вида платежа, если платеж предшествовал документальному обмену предложения, зависящего от вида платежа (смотри раздел 9.1.2.1) или

     

    - сформирован Покупателем. В этом случае он содержит код вида платежа, платежный протокол и вид валюты, выбранные из списка видов платежа (смотри раздел 9.1.2.2).

    • опционного компонента платежной схемы (смотри раздел 7.10), если это требуется для используемого способа платежа (смотри, если нужно, приложение для платежных методов).
    • нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

    Заметим, что:

    • если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа;
    • Кассир, который должен быть сюда включен, идентифицируется компонентом выбора платежа (смотри раздел 7.8). Объясненеи того как идентифицируется Кассир смотри в разделе 6.3.1;
    • компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment;
    • компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей.

    Блок подписи (запрос платежа)

    Если предшествующий документальный обмен предложения содержал цифровую подпись(смотри раздел 9.1.2.5), или подпись была включена в предыдущий платежный отклик (смотри раздел 9.1.3.4), тогда они должны обе быть скопированы в блок подписи сообщения платежного запроса.

    9.1.3.3. Сообщение платежного обмена IOTP

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена.

    Блок платежного обмена (смотри раздел 8.8) включает в себя:

    • один компонент платежной схемы (смотри раздел 7.10), который содержит специфические данные метода платежа. Подробности по платежному методу смотри в приложении.

    9.1.3.4. Платежное сообщение отклика

    Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:

    • платежный блок отклика
    • опционный блок подписи

    Платежный блок отклика (смотри раздел 8.9) включает в себя:

    • один компонент платежной расписки (смотри раздел 7.11), которая содержит специфические данные для платежной схемы, которые позволяют, если нужно, проконтролировать платеж;
    • один компонент платежной схемы (смотри раздел 7.10), который, если требуется, содержит специфические данные метода платежа. Подробности смотри в приложении;
    • опционный компонент накладной (Payment Note) (смотри раздел 7.12);
    • нуль или более компонентов данных о торговой роли (смотри раздел 7.17).

    Блок подписи (платежный отклик)

    Если предоставлена подписанная платежная расписка, что индицируется атрибутом SignedPayReceipt= True компонента Payment, тогда блок Signature должен содержать компонент Signature, который содержит элементы дайджеста следующих видов:

    • блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит первый вариант блока платежного отклика,
    • Id-компонент транзакции (смотри раздел 3.3.1) в блоке ссылок транзакции, который однозначно идентифицирует транзакцию,
    • компонент платежной расписки из блока платежного отклика,
    • компонент накладной (Payment Note) из блока платежного отклика,
    • другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки,
    • компонент Status из блока платежного отклика,
    • любой компонент данных о торговой роли в блоке платежного отклика и
    • все компоненты Signature, содержащиеся в блоке платежного запроса (если имеются).

    9.1.4. Обмен документами при доставке

    Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:

    • Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;
    • Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись.

    Схема обмена сообщениями представлена на рис. .22.

    1.

    Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью

    C à D

    Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки

    2.

    Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю.

    C ß D

    Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки

    3.

    Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее.

    Рис. .22. Обмен документами при доставке

    9.1.4.1. Принципы обработки сообщений

    Получив сообщение-запрос доставки, агент доставки должен проверить авторизацию выполнения такой операции (смотри раздел 6). Далее он может:

    • сформировать и послать покупателю сообщение-отклик доставки или
    • индицировать сбой путем посылки покупателю блока Cancel, содержащего компонент Status с StatusType = Delivery, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равными: DelivCanceled или Unspecified.

    Получив сообщение-отклик доставки, покупатель может считать, что транзакция завершена.

    Если покупатель получает сообщение, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и дальнейшая работа прервана.

    9.1.4.2. Сообщение запроса доставки IOTP

    Сообщение запроса доставки IOTP состоит из:

    • блок запроса доставки и
    • опционный блок подписи

    Блок запроса доставки (смотри раздел 8.10) содержит:

    • следующие компоненты копируются из блока отклика Offer:
     

    - компонент Status (смотри раздел 7.16)

     

    - компонент Order (смотри раздел 7.5)

     

    - компонент Organisation (смотри раздел 7.6) с ролями: Продавец, Агент доставки и DeliverTo

     

    -компонент Delivery (смотри раздел 7.13)

    • следующий компонент из блока платежного отклика:
     

    компонент Status (смотри раздел 7.16).

    • нуль или более компонентовданных о торговых ролях (смотри раздел 7.17).

    Блок подписи (запрос доставки)

    Если предыдущиц документальный обмен Offer содержит подпись отклика Offer илт платежный обмен содержит подпись платежного отклика, тогда тогда они должны быть скопированы в блок подписи.

    9.1.4.3. Сообщение-отклик доставки

    Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи.

    Блок отклика доставки содержит:

    • один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг.

    Блок подписи (отклик доставки)

    Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:

    • Id-компоненту транзакции (смотри раздел 3.3.1) сообщения, которое содержит подпись отклика Delivery;
    • блок ссылок транзакции (смотри раздел 3.3) сообщения, которое содержит подпись отклика доставки;
    • компонент данных покупателя, содержащийся в блоке запроса доставки покупателя;
    • компоненты подписи, содержащиесчя в блоке запроса доставки (если имеется);
    • компонент Status;
    • компонент накладной (Delivery Note)

    9.1.5. Обмен документами в процессе платежа и доставки

    Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:

    • Запрос покупателя начинается с формирования сообщения-запроса платежа, где используется информация предыдущего IOTP-сообщения транзакции. Далее этот запрос направляется кассиру;
    • Кассир и покупатель обмениваются платежными сообщениями, в которые вкладываются сообщения платежного протокола, до тех пор пока транзакция не будет завершена;
    • Кассир посылает покупателю в одном сообщении IOTP:
     

    - блок платежного отклика, содержащий платежную расписку, и

     

    - блок отклика доставки, содержащий подробности о доставленных товарах или услугах.

    IOTP-сообщения, которые вовлечены в этот процесс, показаны на рис. .23.

    1.

    Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью

    C à P

    Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса

    2.

    Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена)

    C « P

    Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена

    3.

    Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю.

    C ß P

    Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки

    4.

    Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли.

    Рис. .23. Документальный обмен платежа и доставки

    Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены.

    Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.

    9.1.5.1. Принципы обработки сообщений

    Получив сообщение платежного запроса или платежного обмена, кассир должен выполнить некоторые действия по документальному платежному обмену (смотри раздел 9.1.3.1).

    Получив сообщение платежного обмена, покупатель также должен выполнить некоторые действия по платежному документальному обмену (смотри раздел 9.1.3.1).

    По получении сообщения платежного отклика и отклика доставки транзакция завершена.

    Если покупатель получает сообщение IOTP, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и более никаких действий не предпринимается.

    Если кассир получает сообщение IOTP, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира.

    Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия.

    9.1.5.2. Сообщение платежного запроса IOTP

    Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).

    9.1.5.3. Сообщение платежного обмена IOTP

    Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3).

    9.1.5.4. Сообщение платежного отклика и отклика доставки

    Содержимое этого сообщения включает в себя:

    • блок платежного отклика,
    • опционный блок подписи (платежный отклик) и
    • блок отклика доставки.

    Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4).

    Блок SIGNATURE (отклик PAYMENT)

    Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4).

    Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).

    9.1.6. Базовая транзакция аутентификации

    Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:

    • перед другой транзакцией IOTP;
    • одновременно с другой транзакцией;
    • независимо от каких-либо других транзакций.

    Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на рис. .24.

    Рис. .24. Базовая транзакция аутентификации

    Пример, использующий базовую транзакцию аутентификации, включает в себя следующие процедуры:

    • когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:

     

    - сформировать безопасный канал связи с покупателем (напр., используя [SSL/TLS]);

     

    - аутентифицировать покупателя, используя базовую транзакцию аутентификации и затем;

     

    - предоставить покупателю доступ к информации и другим услугам с конфиденциальностью, с которой они общаются с добросовестными клиентами.

    • как средство предоставления продавцу компонента Organisation, который содержит информацию о покупателе и торговой роли DelivTo;
    • предоставление возможности аутентифицировать кассира до начала процедуры платежа.

    9.1.7. Базовая транзакция депозита

    Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации.

    Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:

    • опционный документальный обмен аутентификации (смотри раздел 9.1.1);
    • документальный обмен предложения (смотри раздел 9.1.2) и
    • документальный обмен платежа (смотри раздел 9.1.3).

    Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на рис. .25.


    Рис. .25. Базовая транзакция депозита

    Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям.

    Заметим, что:

    • Продавец (финансовая организация) может принять депозит в виде различных видов электронных платежей. Но покупатель, который собирается разместить депозит, обячно знает, каким видом электронного платежа он намерен воспользоваться, по этой причине все многообразие электронных платежей в каждом конкретном случае сводится к одной разновидности. Однако могут быть несколько протоколов, которые могут использоваться с одним и тем же видом электронного платежа. В этом случае предложение, зависимое от вида платежа, може подойти для согласования используемого протокола.
    • Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:

     

    - покупатель может специфицировать номер счета перед началом базовой транзакции депозита или

     

    - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией.

    • Базовая IOTP-транзакция депозита без аутентификации может быть использована:

     

    - если предыдущая транзакция, например, отзыва сделки или аутентификации уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента;

     

    - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен;

     

    - если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом.

    9.1.8. Базовая транзакция покупки

    Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:

    • опционный документальный обмен аутентификации (смотри раздел 9.1.1)
    • документальный обмен предложения (смотри раздел 9.1.2)
    • или:
     

    - документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует

     

    - документальный обмен доставки (смотри раздел 9.1.4)

    • только документальный обмен платежа или
    • комбинированный документальный обменплатежа и доставки (смотри раздел 9.1.5).

    Способы, какими эти документальные обмена могут комбинироваться показаны на рис. .26.


    Рис. .26. Базовая транзакция покупки

    Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12.

    9.1.9. Базовая транзакция возврата денег

    Процесс возврата денег обычно состоит из:

    • запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:

     

    - исходная сделка имела место, например, путем предоставления расписки для исходной транзакции;

     

    - используется некоторый вид аутентификации, чтобы показать, что субъект, запросивший возврат, действительно является покупателем, или представителем покупателя, который осуществлял исходную сделку;

     

    - причину, почему продавец должен вернуть деньги.

    • Продавец соглашается (или нет) вернуть деньги. Это может включать некоторые переговоры между покупателем и продавцом, и если продавец согласен,
    • выполняется возврат денег продавцом покупателю.

    Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:

    • отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6)
    • возвратный платеж продавца покупателю с помощью следующих двух торговых обменов:
     

    - опционный документальный обмен аутентификации (смотри раздел 9.1.1)

     

    - документальный обмен предложения (смотри раздел 9.1.2) и

     

    - документальный обмен платежа (смотри раздел 9.1.3).

    Способы того, как эти документальные обмены взаимодействуют, показаны на рис. .27.


    Рис. .27. Базовая транзакция возврата денег

    Базовая транзакция возврата денег без документального обмена аутентификации может использоваться:

    • когда аутентификация покупателя осуществлена как-то иначе, например, покупатель, чтобы идентифицировать себя ввел представленный ему ранее код. Код может может быть записан на WEB-странице или прислан по электронной почте.
    • когда предыдущая транзакция, например базовая аутентификация, идентифицировала покупателя, при этом используется безопасный канал гарантирует корректность предыдущей аутентификации.
    • когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.

    9.1.10. Базовая транзакция отзыва платежа

    Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации.

    Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца - за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:

    • опционный документальный обмен аутентификации (смотри раздел 9.1.1)
    • документальный обмен предложения (смотри раздел 9.1.2) и
    • документальный обмен платежа (смотри раздел 9.1.3).

    Способы, какими эти документальные обмены могут комбинироваться показаны на рис. .28.


    Рис. .28. Базовая транзакция отзыва сделки

    Заметим, что:

    • Продавец (финансовая организация) может предложить реализацию возврата средств различными видами электронных платежей. Однако может быть несколько различных протоколов для каждого из видов электронных платежей.
    • Продавец (финансовая организация) может использовать результаты аутентификации для того, чтобы идентифицировать не только покупателя, но счета, куда надлежит перевести возвращаемые средства. Если не удается идентифицировать один счет, используются другие средства. Например:

     

    - покупатель может специфицировать номер счета перед началом базовой транзакции отзыва или

     

    - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией.

    • базовая транзакция отзыва может использоваться без аутентификации:

     

    - если предыдущая транзакция, например, депозит или аутентификация уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента;

     

    - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен;

     

    - если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом.

    9.1.11. Базовая транзакция обмена ценностями

    Базовая транзакция обмена ценностями использует документальный обмен платежа, чтобы поддержать обмен ценностями в одной валюте с помощью одного метода оплаты и с привлечением той же или (обычно) другой валюты с помощью того же или иного платежного метода (встречный платеж). Примеры реализации такой процедуры включают в себя:

    • Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах.
    • Платежный обмен с заграничным субъектом посредством идентичных платежных методов. Например, один платеж может заключаться в снятии средств со счета в английских фунтах методом Mondex, а второй - предполагает внесение на счет денег в евро с помощью того же метода Mondex.
    • Платежный обмен с заграничным субъектом посредством различных платежных методов. Например, один платеж может осуществляться по протоколу SET в канадских долларах, а второй - методом GeldKarte в немецких марках.

    Базовый обмен ценностями использует следующие документальные обмены:

    • опционный документальный обмен аутентификации (смотри раздел 9.1.1);
    • документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и
    • два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа.

    Способы, которыми эти документальные обмены комбинируются друг с другом изображены на рис. .29.


    Рис. .29. Базовая транзакция обмена ценностями

    Базовая транзакция обмена ценностями осуществляется в двух вариантах:

    • Обмен ценностями, зависящий от вида платежа. Где содержимое предложения, например курс по которому одна форма ценности обменивается на вторую, зависит от вида платежа и протокола, выбранного клиентом и
    • Обмен ценностями, независящий от вида платежа. Где содержимое предложения, не зависит от вида платежа и протокола, выбранного клиентом.

    В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.

    Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями.

    Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме рис. .30.


    Рис. .30. Подписи при обмене ценностями

    9.1.12. Допустимые комбинации документальных обменов

    Диаграмма на рис. .31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.


    Рис. .31. Допустимые комбинации документальных обменов

    1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:

     

    a) Транзакция IOTP содержит документальный обмен аутентификации (смотри раздел 9.1.1). (Замечание 1)

     

    b) Если последнее сообщение документального обмена аутентификации содержит блоки TPO и отклика предложения, тогда:

       

    i) Транзакция IOTP включает документальный обмен предложения, независимый от вида платежа (смотри раздел 9.1.2.2). (Замечание 2)

     

    c) В противном случае, если последнее сообщение аутентификационного обмена содержит блок TPO, но не содержит блока отклика предложения, тогда:

       

    i) Сообщение IOTP содержит документальный обмен предложения, зависимый от вида платежа (смотри раздел 9.1.2.1). (Замечание 2)

     

    d) В противном случае (сообщение состояния аутентификации документального обмена не содержит ни блока TPO ни блока отклика предложения).

       

    i) Транзакция IOTP содержит только документальный обмен аутентификации. (Замечание 3)

    2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):
      e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2)
     

    f) Если первое сообщение содержит блок отклика предложения, тогда:

       

    i) Транзакция IOTP содержит документальный обмен предложения, независимый от вида платежа (Замечание 2)

     

    g) В противном случае (отсутствие блока отклика предложения в первом сообщении):

       

    i) Транзакция IOTP включает документальный обмен предложения, зависимый от вида платежа (Замечание 2)

    3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:
     

    h) Если блок отклика предложения содержит компонент доставки, тогда:

       

    i) Если атрибут DelivAndPayResp компонента доставки равен "Истинно", то компонент доставки делается равной "Истинно", тогда:

         

    (1) Транзакция IOTP состои из документальных обменов платежа и доставки (смотри раздел 9.1.5) (Замечание 4)

       

    ii) В противном случае (атрибут DelivAndPayResp компонента доставки делается равным "Ложно")

         

    (1) Транзакция состоит из документального обмена платежа (смотри раздел 9.1.3), за которым следует обмен доставки (смотри раздел 9.1.4) (Замечание 4)

     

    i) В противном случае (блок отклика предложения не содержит компонента доставки )

       

    i) если блок отклика предложения содержит только один компонент платежа, тогда:

         

    (1) Транзакция IOTP содержит только один документальный обмен платежа (Замечание 5)

       

    ii) если блок отклика Offer содержит компонент платежа, тогда:

         

    (1) Транзакция IOTP включает в себя два документальных платежных обмена. Атрибут StartAfter компонента платежа используется для индикации того, какой платеж происходит первым. (Замечание 6)

       

    iii) если блок отклика Offer не содержит ни одного или имеет более двух платежных компонентов, то имеет место ошибка

    4) В противном случае (отсутствие блока отклика Offer) имеет место ошибка.

    Ниже представлена таблица типов транзакций, которые могут удовлетворять условиям перечисленным выше.

    Замечание

    Корректность транзакции IOTP

    1.

    Любая транзакция платежа и аутентификации

    2.

    Любая транзакция платежа и аутентификации за исключением базовой аутентификации

    3.

    Транзакция базовой аутентификации или базовой покупки, возврата денег, депозита, отзыва или обмена ценностями с не прошедшей аутентификацией

    4.

    Толко базовая трканзакция покупки

    5.

    Базовая транзация покупки, возврата денег, депозита и отзыва

    6.

    Только базовый обмен ценностями

    9.1.13. Комбинирование аутентификации с другими транзакциями

    Имеется возможность запустить независимую транзакцию аутентификации в любой момент времени, даже в параллель с другой транзакцией IOTP. Обычно она используется:

    • Покупателем, чтобы аутентифицировать продавца, кассира или агента доставки или
    • Кассиром или агентом доставки, чтобы аутентифицировать покупателя.

    В общих чертах базовый процесс состоит из:

    • торговая роль, которая решает выполнить аутентификацию другой торговой роли, откладывает выполнение текущей транзакции;
    • выполняется не связанная ни с чем аутентификация. Это может быть опцией разработчика, подключенной к исходной транзакции с помощью компонента RelatedTo (смотри раздел 3.3.3) в блоке ссылок транзакции;
    • если транзакция аутентификации успешна essful, осходная транзакция возобновляется;
    • если аутентификация не прошла, тогда исходная аутентификация аннулируется.

    Покупатель, например, может:

    • аутентифицировать кассира для платежа в период между получением отклика Offer от продавца и до посылки платежного запроса кассиру;
    • аутентифицировать агента доставки между получением платежного отклика от кассира и до отправки запроса доставки.

    Кассир может аутентифицировать покупателя после получения платежного запроса и до посылки следующего сообщения, относящегося к платежу. агент доставки может аутентифицировать покупателя после получения запроса доставки и до посылки отклика доставки.

    Некоторые платежные методы могут выполнять аутентификацию в ходе платежного обмена. В этом случае информация, необходимая для выполнения аутентификации будет включаться в компоненты платежной схемы.

    В этом примере приложение IOTP не будет уверено, что аутентификация состоялась, так как компоненты платежной схемы, которые содержат аутентификационную информацию, не отличимы о других компонентов платежной схемы.

    9.2. Инфраструктурные транзакции

    Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:

    • транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции;
    • транзакция Ping, которая позволяет одному приложению определить, работает ли соответствующее приложение другой торговой роли и проверить, могут ли обрабатываться подписи.

    9.2.1. Базовая транзакция запроса состояния транзакции IOTP

    Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:

    • торговый блок информационного запроса (смотри раздел 8.12),
    • торговый блок информационного отклика (смотри раздел 8.13)
    • опционный блок подписи (смотри раздел 8.16).

    Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:

    • чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
    • определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.

    Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.

    Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:

    • не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или
    • совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.

    Базовыми требованиями являются:

    • Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:

     

    - Продавцу, после отправки блока выбора TPO,

     

    - Кассиру, после отправки блока платежного запроса,

     

    - Агенту доставки, после отправки блока запроса доставки,

    • другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
    • не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.

    Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:

    • Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.
    • Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.
    • Технические ошибки в сообщении, содержащем сам блок информационного запроса.

    Рабочие ошибки в исходных сообщениях

    Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.

    Технические ошибки в исходных сообщениях

    Возврат блока информационного отклика, содержащего компонент Status. Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка.

    Технические ошибки в блоке информационного запроса

    Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса.

    Сообщения информационого запроса транзакции

    На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.

    1.

    Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли.

    1 à2

    Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса

    2.

    Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается

    1 ß 2

    Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный)

    3.

    Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю.

    Рис. .32. Базовая транзакция статусного запроса

    Блок ссылок транзакции

    Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1).

    Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли. Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:

    • один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.
    • нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.

    Блок подписи (информационный запрос)

    Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос.

    Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:

    • один компонент Signature (смотри раздел 7.19)
    • один или более компонентов сертификата, если таковые нужны.

    Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что:

    • Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;
    • другие торговые роли могут согласовать применение цифровых подписей, если это требуется. Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом.

    С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:

    • один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,
    • нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты.

    Блок SIGNATURE (отклик информационного запроса)

    Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика.

    Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:

    • один компонент Signature (смотри раздел 7.19)
    • один или более компонентов Certificate, если они нужны.

    Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов. В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:

    • Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;
    • другие торговые роли могут договориться о том, что подпись необходима. Например, продавец может потребовать присылки подписанного информационного отклика от кассира.

    9.2.2. Базовая транзакция Ping

    Целью базовой транзакции IOTP Ping является проверка коннективности между торговыми ролями, принимающими участие в транзакции. Это позволяет приложению IOTP сделать следующее:

    • определить, работает ли приложение IOTP другой торговой роли;
    • проконтролировать, могут ли торговые роли работать с цифровыми подписями.

    Например, эта транзакция может быть использована продавцом, чтобы определить, функционирует ли кассир или агент доставки, прежде чем запускать транзакцию, требующую участия этих торговых ролей.

    Торговыми блоками, используемыми транзакцией Ping, являются:

    • блок запроса Ping (смотри раздел 8.14),
    • блок отклика Ping (смотри раздел 8.15) и
    • блок Signature (смотри раздел 8.16).

    Сообщения PING

    На рис. .33 отображен обмен сообщениями прибазовой транзакции Ping.

    1.

    Приложение IOTP первой торговой роли решает проверить, находится ли в рабочем состоянии соответствующее приложение партнера. Оно генерирует блок запроса Ping, опционный блок подписи и шлет их другой торговой роли.

    1 à 2

    Запрос PING. IotpMsg: блоки Trans Ref; подписи (опционный); запроса Ping

    2.

    Вторая торговая роль, которая получает блок запроса Ping, генерирует блок отклика Ping и посылает его отправителю исходного запроса Ping, с блоком подписи, если это требуется.

    1 ß 2

    Отклик PING. IotpMsg: блоки Trans Ref; подписи (опционный); отклика Ping

    3.

    Первая торговая роль проверяет блок отклика Ping и выполняет необходимые действия, если это требуется

    Рис. .33. Базовые сообщения транзакции Ping

    Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса Ping путем включения:

    • компонентов Organisation, которые идентифицируют себя и предполагаемого получателя блока запроса Ping;
    • блок подписи, который гарантирует корректность и целостность запроса Ping.

    Получатель запроса Ping таким образом:

    • знает, кто послал запрос Ping и может следовательно верифицировать подпись запроса;
    • знает, кто должен генерировать подпись отклика Ping.

    Заметим, что запрос Ping:

    • не влияет на выполнение транзакций;
    • в отличии от других сообщений IOTP, таких как TPO или статусный запрос, не запускает новых транзакций IOTP.

    Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении.

    Базовый запрос IOTP Ping может также содержать опционный блок подписи. Приложение IOTP может, например, использовать блок подписи для проверки того, способен ли получатель этого запроса формировать и верифицировать цифровые подписи.

    Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии.

    Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций.

    Блок ссылок транзакции

    IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других.

    Блок запроса PING

    Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7).

    Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для:

    • отправителя блока запроса Ping;
    • верификатора компонента подписи.

    Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping.

    Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты:

    • один компонент Signature (смотри раздел 7.19)
    • один или более компонентов Certificate, если они требуются.

    Блок отклика PING

    Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты:

    • компонент Organisation отправителя сообщения-отклика Ping

    Если транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит:

    • копии компонентов Organisation, содержащиеся в блоке запроса Ping.

    Блок SIGNATURE (отклик PING)

    Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты:

    • один компонент Signature (смотри раздел 7.19);
    • один или более компонентов Certificate, если они нужны.

    10. Получение логотипов

    Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif"

    Где:

    • Logo_net_location получено из атрибута LogoNetLocn элемента вида платежа (смотри раздел 7.7.1) или компонента Organisation. Заметим, что:
    • - содержимое этого атрибута зависит от используемого транспортного механизма (такого как HTTP).
    • - разработчики должны проверить, что если самый правый символ в Logo Net Location представляет собой "/", тогда другой такой же символ не должен включаться в запись адреса логотипа
    • Logo_size идентифицирует размер логотипа,
    • Logo_color_depth идентифицирует насыщенность цвета логотипа;
    • "gif" идентифицирует, что логотип имеет формат "gif" .

    Logo_size и Logo_color_depth специфицирует разработчик программы IOTP, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь.

    10.1. Размер Logo

    Имеется пять стандартных рамеров логотипа. Размеры в пикселях соответствуют в таблице значениям размера логотипа.

    Размер в пикселях

    Размер логотипа значение

    32 x 32 или
    32 x 20

    exsmall (сверх малый)

    53 x 33

    small (малый)

    103 x 65

    medium (средний)

    180 x 114

    large (большой)

    263 x 166

    exlarge (сверх большой)

    10.2. Насыщенность цвета логотипа

    Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.

    Насыщенность цвета

    Цвет логотипа

    (бит на пиксель)

    Значение насыщенности

    4 (16 цветов)

    4

    8 (256 цветов)

    ничего

    24 (16 миллионов цветов)

    24

    Заметим, что если насыщенность цвета логотипа пропущена, тогда извлекается логотип с 256 цветами.

    10.3. Примеры логотипа для сетевой позиции

    Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:

    • "ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами
    • "http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветами

    Организации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".

    11. Виды платежа

    11.1. Определения и выбор вида платежа

    Одной из ключевых черт IOTP является возможность для продавца предложить список видов платежа, чтобы покупатель мог сделать выбор. Ниже рассматриваются:

    • определения платежных инструментов и видов платежа в контексте IOTP. Вводятся опционные категории видов оплаты "Dual Brand" или "поощрительный вид платежа",
    • идентификация и выбор поощрительного вид платежа, который предлагает покупателю некоторые дополнительные выгоды, например скидку. Это означает, что и продавец и покупатель должны быть способны корректно идентияицировать, какой из допустимых поощрительных видов платежа использован.

    11.1.1. Определение платежного инструмента

    Платежный инструмент является средством, с помощью которого покупатель платит за товар или услуги, предлагаемые продавцом. Это может быть, например:

    • кредитная карта, такая как MasterCard или Visa;
    • дебитная карта типа MasterCard Maestro;
    • смарт карта, базирующаяся на системе электронных платежей, такой как Mondex, GeldKarte или Visa Cash;
    • программа, базирующаяся на системе платежей типа CyberCash или DigiCash.

    Большинство платежных инструментов имеют номер, обычно это номер счета, по которому можно идентифицировать платежный инструмент.

    11.1.2. Определение вида платежа

    Вид платежа часто представляет собой марку, которая идентифицирует конкретный тип платежного инструмента. Список видов платежа представляет собой опции, которые предоставляются продавцом покупателю и из которых покупатель делает свой выбор. Каждый вид платежа может иметь разных кассиров. Среди примеров вида платежа:

    • платежные ассоциации и платежные системы частных фирм, например MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, и т.д..
    • поощрительные виды платежа (смотри ниже). Сюда входят:

     

    - store brands, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK)

     

    - совмещенные виды платежа, например American Advantage Visa, где организация использует свой собственный вид платежа обычно в сочетании с платежами рассчетной ассоциации.

    11.1.3. Определение двойственного вид платежа (Dual Brand)

    Двойственный вид платежа (Dual Brand) означает, что отдельный платежный инструмент может использоваться так, как если бы это были два отдельных вида платежа. Например, может существовать одна японская карта "UC" (MasterCard), которую можно использовать как UC-карту или как обычную MasterCard. Виды платежа через UC-карту и MasterCard могут иметь своих собственных, отличных друг от друга Кассиров. Это означает, что:

    • продавец рассматривает, например,"UC" и "MasterCard" как два вида платежа, когда предлагает список видов платежа покупателю,
    • покупатель выбирает вид платежа, например, "UC" или "MasterCard,
    • клиент приложения определяет, какой платежный инструмент подходит для выбранного вида платежа и выбирает, возможно с помощью самого пользователя, оптимальный платежный инструмент.

    Двойственные виды платежа не требуют какого-то специального обслуживания продавцом и, следовательно, не нужно как-то выделять эти виды платежа в DTD. Это происходит потому, что в той части, которая касается продавца, каждый вид платежа в двойственном виде платежа рассматривается как независимый. Только покупатель должен находить соответствие между предлагаемым видом оплаты и имеющимся двойственным платежным инструментом.

    11.1.4. Определение стимулирующего вида оплаты

    Поощрительный вид оплаты предполагает, что если покупатель им воспользуется, то он получит какие-то дополнительные выгоды. Эти выгоды могут быть получены двумя путями:

    • во время покупки. Например, если покупатель платит с помощью "Walmart MasterCard" через сервер Walmart, то он может получить скидку в 5%, это означает, что покупатель в действительности платит меньше,
    • от эмитента платежного средства (карты), когда платеж появляется в ведомости. Например, процент за каждую операцию может быть понижен при частом использовании, основываясь на суммарой величине платежей с использованием данного платежного инструмента.

    Заметим, что:

    • первый пример (получение выгоды в момент покупки), требует чтобы:

     

    - Покупатель информируется о выгоде, которую он может получить при выборе данного вида платежа;

     

    - если вид платежа выбран, продавец изменяет соответствующие компоненты IOTP в отклике Offer, чтобы правильно отразить сумму, которую следует оплатить.

    • второй (получение выгоды от эмитента платежного средства) - не требует, чтобы отклик Offer изменился;
    • каждый поощрительный вид оплаты в списке, предлагаемом продавцом, должен быть идентифицирован как отдельный вид платежа. Например: "Walmart", "Sears", "Marks and Spencer" и "American Advantage Visa", будут рассматриваться как отдельные виды оплаты.

    11.1.5. Идентификация льготных видов платежа

    Имеется две проблемы, которые нужно решить при идентификации поощрительных видов платежа:

    • как продавец или кассир идентифицирует поощрительный вид оплаты, используемый в момент покупки;
    • как покупатель надежно идентифицирует поощрительный вид оплаты в списке видов платежа, представленном продавцом.

    11.1.5.1. Идентификация поощрительных видов платежа Продавцом/Кассиром

    Правильная идентификация того, что покупатель воспользовался поощрительным видом платежа, крайне важно, так как покупатель может объявить, что он имеет право на скидку, которая действует для поощрительного вида платежа, в то время как в действительности это не так. Здесь возможны два подхода:

    • использовать некоторую возможность платежного инструмента или метода, чтобы идентифицировать вид используемого платежа. Например, для данного вида платежа может использоваться сертификат SET, если он доступен, или
    • использовать номер платежного инструмента (карты), чтобы получить информацию о платежном инструменте, например, в базе данных эмитента, чтобы узнать является ли данный вид платежа льготным.

    Заметим, что:

    • первый вариант предполагает доступность SET.
    • второй - возможен, если продавец или кассир имеют доступ к базе данных эмитента карты.

    IOTP не предоставляет продавцу информации о платежном инструменте (напр., карте или номере счета). Эти данные посылаются кассиру в качестве части инкапсулированного платежного протокола. Это означает, что:

    • Продавец будет вынужден предположить, что выбранный платежный инструмент был льготным видом платежа, или
    • Кассир будет вынужден проверить, что платежный инструмент соответствовал льготному виду платежа, платеж аннулируется, если это не так.

    Проверка кассиром, является ли платеж льготным, возможна, если кассир совмещает функции и эмитента карты.

    11.1.5.2. Выбор Покупателем льготных видов платежа

    Существует два способа, как покупатель может выбрать правильно льготный вид платежа:

    • Покупатель визуально выбирает логотип для льготного вида платежа из числа предложенных продавцом,
    • приложение покупателя выбирает зарегистрированный код льготного платежа из списка видов платежа, предложенного продавцом.

    В последнем случае, код покупателя должен совпадать с кодом из списка продавца, в противном случае соответствие не будет зарегистрировано. Способы, которыми программа IOTP покупателя может получить такой код, включают:

    • Покупатель непосредственно вводит этот код. Это располагает к ошибкам и неудобно для клиента, кроме того покупателю надо как-то передать этот код. Этот подход не рекомендуется,
    • Используется один из идентификаторов вида платежа, определенных в IOTP и предварительно загруженных в приложение покупателя,
    • Используется некоторая информация, содержащаяся в программе, или другие данные, связанные с платежным инструментом. Это может быть:

     

    - сертификат SET для видов платежа, которые используют этот протокол оплаты;

     

    - код предоставляется платежной программой, которая работает с конкретным методом оплаты, это может быть приложимо к, например, GeldKarte, Mondex, CyberCash и DigiCash,

    • покупатель устанавливает вручную связь между льготным видом платежа из списка, предложенного продавцом, и определенным платежным инструментом. Делается это при первом использовании льготного вида платежа. Приложение IOTP запоминает код льготного платежа для использования при будущих покупках.

    11.1.5.3. Рекомендации для Id видов платежа в программе покупателя

    Новые Id видов платежа выдаются в соответствии с процедурой, заданной IANA (смотри раздел 12).

    Рекомендуется, чтобы разработчики приложений IOTP покупателя (напр., платежных программ) обеспечивали предварительную загрузку текущего набора идентификаторов вида платежа и предлагали средства пополнения этого списка.

    11.2. Примеры видов платежа

    Данный пример содержит три образца XML для компонента списка видов платежа:

    • вариант с просой кредитной карточкой;
    • список видов платежей, базирующихся на кредитной карте, включая льготные виды платежа, и
    • список видов платежа, базирующийся на комплексных электронных деньгах.

    11.2.1. Простой пример, базирующийся на кредитной карте

    Этот простой пример включает в себя:

    • только основные виды платежей с помощью кредитной карты;
    • одну цену и одну валюту;
    • одного Кассира и
    • один платежный протокол.

    <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h'
    PayDirection='Debit' >
    <Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit'
    BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
    ProtocolAmountRefs='M1.33'>
    </Brand>
    <Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit'
    BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'>
    </Brand>
    <Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express'
    BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' >
    </Brand >
    <ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'>
    </ProtocolAmount>
    <CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/>
    <PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit'
    PayReqNetLocn='http://www.example.com/etill/sccd1' >
    </PayProtocol>
    </BrandList>

    11.2.2. Список платежей с помощью кредитной карты, включая льготные платежи

    Пример списка видов платежей с помощью кредитной карты представлен ниже. Он включает в себя:

    • два обычных вида платежа через кредитную карту и два льготных вида платежа.
    • два платежных протокола:
     

    - SET (Secure Electronic Transactions) смотри [SET] и

     

    - SCCD (Secure Channel Credit Debit) смотри [SCCD].

    <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit'>
    <Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit'
    BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
    </ProtocolBrand>
    </Brand>
    <Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit'
    BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
    </ProtocolBrand>
    </Brand>
    <Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard'
    BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
    BrandNarrative='Double air miles with British Airways MasterCard'
    ProtocolAmountRefs ='M1.7 M1.8' >
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
    </ProtocolBrand>
    </Brand >
    <Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
    BrandLogoNetLocn='ftp://otplogos.walmart.com'
    BrandNarrative='5% off with your Walmart Card on purchases over $150'
    ProtocolAmountRefs='M1.8'>
    </Brand>
    <ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' >
    <PackagedContent Transform="BASE64">
    238djqw1298erh18dhoire
    </PackagedContent>
    </ProtocolAmount>
    <ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' >
    <PackagedContent Transform="BASE64">
    238djqw1298erh18dhoire
    </PackagedContent>
    </ProtocolAmount>
    <CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/>
    <PayProtocol ID ='M1.10' ProtocolId='SET1.0'
    ProtocolName='Secure Electronic Transaction Version 1.0'
    PayReqNetLocn='http://www.example.com/etill/set1' >
    <PackagedContent Transform="BASE64">
    8ueu26e482hd82he82
    </PackagedContent>
    </PayProtocol>
    <PayProtocol ID ='M1.11' ProtocolId='SCCD1.0'
    ProtocolName='Secure Channel Credit/Debit'
    PayReqNetLocn='http://www.example.com/etill/sccd1' >
    <PackagedContent Transform="BASE64">
    82hd82he8226e48ueu
    </PackagedContent>
    </PayProtocol>
    </BrandList>

    11.2.3. Пример выбора вида платежа

    Для оплаты через 'British Airways' MasterCard для выше приведенного варианта и платежного протокола SET список вида платежа будет иметь вид:

    <BrandSelection ID='C1.2' BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7'
    CurrencyAmountRef='M1.9' >
    </BrandSelection>

    11.2.4. Список видов платежа, базирующихся на комплексных электронных деньгах

    Ниже представлен достаточно сложный пример, который включает в себя:

    • платежи, использующие Mondex, GeldKarte, CyberCash или DigiCash;
    • в валютах, в список которых входят доллары США, британские фунты, итальянские лиры, немецкие марки и канадские доллары;
    • скидку на цену, если платеж выпонен через Mondex, используя британские фунты или американские доллары и
    • более одного Кассира для случаев использования Mondex или CyberCash;
    • поддержка более чем одной версии CyberCash для платежного протокола CyberCoin.

    <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co'
    PayDirection='Debit'>
    <Brand ID ='M1.13' BrandId='Mondex' BrandName='Mondex Electronic Cash'
    BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'>
    </Brand>
    <Brand ID ='M1.14' BrandId='GeldKarte' BrandName='GeldKarte Electronic Cash'
    BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'>
    </Brand>
    <Brand ID ='M1.15' BrandId='CyberCoin' BrandName='CyberCoin Eletronic Cash'
    BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20'>
    </Brand >
    <Brand ID ='M1.16' BrandId='DigiCash' BrandName='DigiCash Electronic Cash'
    BrandLogoNetLocn='http://otplogos.digicash.com'
    BrandNarrative='5% off with your Walmart Card on purchases over $150'
    ProtocolAmountRefs='M1.22'>
    </Brand>
    <ProtocolAmount ID ='M1.17' PayProtocolRef='M1.31'
    CurrencyAmountRefs='M1.25 M1.29'>
    </ProtocolAmount>
    <ProtocolAmount ID ='M1.18' PayProtocolRef='M1.32'
    CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
    </ProtocolAmount>
    <ProtocolAmount ID ='M1.19' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.28'>
    </ProtocolAmount>
    <ProtocolAmount ID ='M1.20' PayProtocolRef='M1.34 M1.33'
    CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
    </ProtocolAmount>
    <ProtocolAmount ID ='M1.21' PayProtocolRef='M1.36'
    CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
    </ProtocolAmount>
    <CurrencyAmount ID ='M1.23' Amount='20.00' CurrCode='USD'/>
    <CurrencyAmount ID ='M1.24' Amount='12.00' CurrCode='GBP'/>
    <CurrencyAmount ID ='M1.25' Amount='19.50' CurrCode='USD'/>
    <CurrencyAmount ID ='M1.26' Amount='11.75' CurrCode='GBP'/>
    <CurrencyAmount ID ='M1.27' Amount='36.00' CurrCode='DEM'/>
    <CurrencyAmount ID ='M1.28' Amount='100.00' CurrCode='FFR'/>
    <CurrencyAmount ID ='M1.29' Amount='22.00' CurrCode='CAD'/>
    <CurrencyAmount ID ='M1.30' Amount='15000' CurrCode='ITL'/>
    <PayProtocol ID ='M1.31' ProtocolId='MXv1.0'
    ProtocolName='Mondex IOTP Protocol Version 1.0'
    PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
    </PayProtocol>
    <PayProtocol ID ='M1.32' ProtocolId='MXv1.0'
    ProtocolName='Mondex IOTP Protocol Version 1.0'
    PayReqNetLocn='http://www.mxbankuk.com/vserver' >
    </PayProtocol>
    <PayProtocol ID ='M1.33' ProtocolId='Ccashv1.0' ProtocolName='CyberCoin Version 1.0'
    PayReqNetLocn='http://www.cybercash.com/ccoin' >
    </PayProtocol>
    <PayProtocol ID ='M1.34' ProtocolId='CCashv2.0' ProtocolName='CyberCoin Version 2.0'
    PayReqNetLocn='http://www.cybercash.com/ccoin' >
    </PayProtocol>
    <PayProtocol ID ='M1.35' ProtocolId='GKv1.0' ProtocolName='GeldKarte Version 1.0'
    PayReqNetLocn='http://www.example.com/pgway'>
    </PayProtocol>
    <PayProtocol ID ='M1.36' ProtocolId='DCashv1.0'
    ProtocolName='DigiCash Protocol Version 1.0'
    PayReqNetLocn='http://www.example.com/digicash' >
    </PayProtocol>
    </BrandList>

    12. Соображения IANA

    12.1. Коды контролируемые IANA

    Для того чтобы гарантировать совместимость, коды, используемые IOTP, нужно поддерживать в контролируемой среде так, что их значения и использование были строго определены, а дублирование кодов должно быть исключено. IANA представляет механизм решения этой проблемы, как это описано в RFC 2434.

    Типы элементов и имена атрибутов, к которым эта процедура применяется, приведены ниже в таблице вместе с исходными величинами, разрешенными для этих атрибутов.

    Заметим, что:

    • торговый подписной лист IETF имеет адрес ietf-trade@elistx.com
    • "Специальные эксперты (Designated Experts)" (смотри [IANA]) назначаются IESG.

    Тип элемента/Имя атрибута

    Значения атрибутов

    Алгоритм/Имя

    "sha1" - указывает, что будет использована аутентификация [SHA1]

    (Когда алгоритм является производным от компонента AuthReq)

    "Подпись" - указывает, что аутентификация включает в себя генерацию цифровой подписи.

     

    "Pay:ppp", где "ppp" может быть установлено равным любому допустимому значению для "iotpbrand" (смотри ниже)

    За исключением алгоритмов, которые начинаются с "pay:", новые значения выделяются после просмотра торгового почтового списка IETF и с привлечением "специального эксперта".

    Элемент Algorithm обычно определяется в пределах пространства имен [DSIG]. Со временем эта процедура может измениться.

    Тип элемента/Имя атрибута

    Значения атрибутов

    Вид платежа/BrandId

    Следующий список исходных значений BrandId был получен от организаций, которые сипользуют сертификаты протокола SET с 1-го июня 1999:
    "Amex" - American Express
    "Dankort" - Dankort
    "JCB" - JCB
    "Maestro" - Maestro
    "MasterCard" - MasterCard
    "NICOS" - NICOS
    "VISA" - Visa
    Кроме того определены следующие значения Id видов платежа:
    "Mondex"
    "GeldKarte"

    Новые значения BrandId должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.

    Валютная сумма/CurrCode

    Коды валюты зависят от CurrCodeType (смотри ниже).

    Если CurrCodeType = "ISO4217-A", тогда код валюты является буквенным, определенным в [ISO4217].

    Если CurrCodeType = "IOTP", тогда новые значения должны быть опубликованы через торговый подписной лист IETF и, если в течение трех недель не поступает возражений, они присваиваются в порядке поступления.

    Код типа валюты IOTP, сконструирован так, чтобы позволять поддержку "новых" псевдовалют, таких как loyalty или frequent flyer points. На момент написания этого документа ни один из таких кодов не был лпределен.

    Тип элемента/Имя атрибута

    Значения атрибута

    Валютная сумма/CurrCodeType

    "ISO4217A"
    "IOTP"

    Новые значения атрибута CurrCodeType выделяются после публикования через подписной лист IETF и рассмотрения экспертами.

    DeliveryData/DelivMethod

    "Post"
    "Web"
    "Email"

    Новые значения атрибута Delivery Method выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется данный метод доставки.

    PackagedContent/Content

    "PCDATA"
    "MIME"
    "MIME:mimetype" (где mimetype должен быть тем же, что и в content-type, как это определено в [MIME])
    "XML"

    Если атрибут Content имеет форму "MIME:mimetype", тогда управление новыми значениями для "mimetype" определено в [MIME].

    В противном случае, новые значения атрибута Content выделяются после публикования через подписной лист IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как используется новый атрибут в элементе Packaged Content.

    RelatedTo/RelationshipType

    "IotpTransaction"
    "Reference"

    Новые значения атрибута RelationshipType выделяются после публикования через подписной лист табочей группы IETF и рассмотрения экспертами. Это может потребовать публикации дополнительной документации, описывающей как осуществляется метод доставки.

    Тип элемента/Имя атрибута

    Значения атрибута

    Status/StatusType Предложение
    Платеж
    Доставка
    Аутентификация
    Не идентифицировано
    Новые значения атрибута Status Type выделяются после: oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Status и
    oрассмотрения документа в торговом почтовом листе IETF и экспертами.

    Документ, описывающий новые значения атрибута Status Type, может быть объединен с документами, описывающими новые торговые роли и типы подписей (смотри ниже).

    TradingRole/TradingRole

    "Consumer"
    "Merchant"
    "PaymentHandler"
    "DeliveryHandler"
    "DelivTo"

    oпубликации в Торговой Рабочей Группе IETF, документа RFC, описывающего торговый обмен, торговые роли и соответствующие компоненты, которые относятся к Trading Role и
    oрассмотрения документа в торговом почтовом листе IETF и экспертами.

    Документ, описывающий новые значения атрибута Trading Role может быть объединен с документами, описывающими новые значения Status Types (смотри выше) и типы подписей (смотри ниже).

    Тип элемента/Имя атрибута

    Значения атрибута

    TransId/IotpTransType

    "BaselineAuthentication"
    "BaselineDeposit"
    "BaselineRefund"
    "BaselineWithdrawal"
    "BaselineValueExchange"
    "BaselineInquiry"
    "BaselinePing"
    Новые значения атрибута IotpTransType выделяются после:

    oпубликации через почтовый список IETF, в виде документа RFC, описывающего новую транзакцию IOTP и
    oрассмотрения документа в почтовом списке торговой рабочей группы IETF и экспертами.

    Attribute/Content
    (смотри компонент Signature)

    "OfferResponse"
    "PaymentResponse"
    "DeliveryResponse"
    "AuthenticationRequest"
    "AuthenticationResponse"
    "PingRequest"
    "PingResponse"
    Новые значения кода, которые описывают тип подписи выделяются после:

    oпубликации в Торговой Рабочей Группе IETF документа RFC, описывающего торговый обмен, где используются подписи и
    oрассмотрения документа в торговом почтовом листе IETF и экспертами.

    Документ, описывающий новые значения типа подписи, может быть объединен с документами, описывающими новые типы Status и торговые роли (смотри выше).

    12.2. Коды, неконтролируемые IANA

    Помимо формального выбора и регистрации кодов, как это описано выше, для разработчиков существует необходимость экспериментировать с новыми кодами IOTP. По этой причине могут использоваться "коды определенные пользователем", что не требует регистрациив IANA. Определение кода, задаваемого пользователем, выглядит следующим образом:

    user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*

    NameChar

    NameChar имеет то же определение, что и [XML] определение NameChar.

    Рекомендуется использование имен доменов (смотри [DNS]), для того чтобы сделать коды, определенные пользователем, уникальными, хотя этот метод и не является совершенно надежным.

    13. Определения типов данных протокола IOTP

    Этот раздел содержит XML DTD для IOTP.

    <!--
    ******************************************************
    * *
    * INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
    * Имя файла: ietf.org/rfc/rfc2801.dtd *
    * *
    * Отличие от версии 07 (iotp-v1.0-protocol-07.dtd) *
    * - никаких изменений *
    * *
    * Copyright Internet Engineering Task Force 1998-2000*
    * *
    ******************************************************
    ******************************
    * Определение сообщения IOTP *
    ******************************
    -->
    <!ELEMENT IotpMessage ( TransRefBlk, IotpSignatures?, ErrorBlk?,
    ( AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk |
    DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk |
    PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk
    )* ) >
    <!ATTLIST IotpMessage xmlns CDATA 'iotp:ietf.org/iotp-v1.0' >

    <!--
    ***************************************
    * Определение блока ссылок транзакции *
    *************************************** -->
    <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*)>
    <!ATTLIST TransRefBlk ID ID #REQUIRED>
    <!ELEMENT TransId EMPTY>
    <!ATTLIST TransId ID ID #REQUIRED
    Version NMTOKEN #FIXED '1.0'IotpTransId CDATA #REQUIRED
    IotpTransType CDATA #REQUIREDTransTimeStamp CDATA #REQUIRED>

    <!ELEMENT MsgId EMPTY>
    <!ATTLIST MsgId ID ID #REQUIRED

    RespIotpMsg NMTOKEN #IMPLIED

    xml:lang NMTOKEN #REQUIRED

    LangPrefList NMTOKENS #IMPLIED

    CharSetPrefList NMTOKENS #IMPLIED

    SenderTradingRoleRef NMTOKEN #IMPLIED

    SoftwareId CDATA #REQUIRED

    TimeStamp CDATA #IMPLIED>

    <!ELEMENT RelatedTo (PackagedContent) >

    <!ATTLIST RelatedTo ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    RelationshipType NMTOKEN #REQUIRED

    Relation CDATA #REQUIRED

    RelnKeyWords NMTOKENS #IMPLIED>

    <!--
    **********************************
    * Общий элемент Packaged Content *
    ********************************** -->
    <!ELEMENT PackagedContent (#PCDATA)>
    <!ATTLIST PackagedContent Name CDATA #IMPLIED

    Content NMTOKEN "PCDATA"

    Transform (NONE|BASE64) "NONE">

    <!--
    ***********************
    * Торговые компоненты *
    *********************** -->
    <!-- PROTOCOL OPTIONS COMPONENT -->
    <!ELEMENT ProtocolOptions EMPTY >
    <!ATTLIST ProtocolOptions ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    ShortDesc CDATA #REQUIRED

    SenderNetLocn CDATA #IMPLIED

    SecureSenderNetLocn CDATA #IMPLIED

    SuccessNetLocn CDATA #REQUIRED>

    <!-- AUTHENTICATION DATA COMPONENT -->
    <!ELEMENT AuthReq (Algorithm, PackagedContent*)>
    <!ATTLIST AuthReq ID ID #REQUIRED
    AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
    <!-- AUTHENTICATION RESPONSE COMPONENT -->
    <!ELEMENT AuthResp (PackagedContent*) >
    <!ATTLIST AuthResp ID ID #REQUIRED
    AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
    ContentSoftwareId CDATA #IMPLIED>
    <!-- TRADING ROLE INFO REQUEST COMPONENT -->
    <!ELEMENT TradingRoleInfoReq EMPTY>
    <!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
    TradingRoleList NMTOKENS #REQUIRED>
    <!-- ORDER COMPONENT -->
    <!ELEMENT Order (PackagedContent*)>
    ><!ATTLIST Order ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    OrderIdentifier CDATA #REQUIRED

    ShortDesc CDATA #REQUIRED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    ApplicableLaw CDATA #REQUIRED

    ContentSoftwareId CDATA #IMPLIED>
    <!-- ORGANISATION COMPONENT -->
    <!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
    <!ATTLIST Org ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    OrgId CDATA #REQUIRED

    LegalName CDATA #IMPLIED

    ShortDesc CDATA #IMPLIED

    LogoNetLocn CDATA #IMPLIED>
    <!ELEMENT TradingRole EMPTY>
    ><!ATTLIST TradingRole ID ID#REQUIRED

    TradingRole NMTOKEN #REQUIRED

    IotpMsgIdPrefix NMTOKEN #REQUIRED

    CancelNetLocn CDATA #IMPLIED

    ErrorNetLocn CDATA #IMPLIED

    ErrorLogNetLocn CDATA #IMPLIED>
    <!ELEMENT ContactInfo EMPTY>
    <!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED

    Tel CDATA #IMPLIED

    Fax CDATA #IMPLIED

    Email CDATA #IMPLIED

    NetLocn CDATA #IMPLIED>

    <!ELEMENT PersonName EMPTY >
    <!ATTLIST PersonName xml:lang NMTOKEN #IMPLIED

    Title CDATA #IMPLIED

    GivenName CDATA #IMPLIED

    Initials CDATA #IMPLIED

    FamilyName CDATA #IMPLIED>

    <!ELEMENT PostalAddress EMPTY>
    <!ATTLIST PostalAddress xml:lang NMTOKEN #IMPLIED

    AddressLine1 CDATA #IMPLIED

    AddressLine2 CDATA #IMPLIED

    CityOrTown CDATA #IMPLIED

    StateOrRegion CDATA #IMPLIED

    PostalCode CDATA #IMPLIED

    Country CDATA #IMPLIED

    LegalLocation (True | False) 'False' >
    <!-- BRAND LIST COMPONENT -->
    <!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>

    <!ATTLIST BrandList ID

    ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    ShortDesc CDATA #REQUIRED PayDirection

    (Debit | Credit) #REQUIRE>
    <!ELEMENT Brand (ProtocolBrand*, PackagedContent*)>
    <!ATTLIST Brand ID ID #REQUIRED

    xml:lang NMTOKEN #IMPLIED

    BrandId CDATA #REQUIRED

    BrandName CDATA #REQUIRED

    BrandLogoNetLocn CDATA #REQUIRED

    BrandNarrative CDATA #IMPLIED

    ProtocolAmountRefs IDREFS #REQUIRED

    ContentSoftwareId CDATA #IMPLIED>
    <!ELEMENT ProtocolBrand (PackagedContent*) >
    <!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED
    ProtocolBrandId CDATA #REQUIRED>
    <!ELEMENT ProtocolAmount (PackagedContent*) >

    <!ATTLIST ProtocolAmount ID

    ID #REQUIRED

    PayProtocolRef IDREF #REQUIRED

    CurrencyAmountRefs IDREFS #REQUIRED

    ContentSoftwareId CDATA #IMPLIED>
    <!ELEMENT CurrencyAmount EMPTY >

    <!ATTLIST CurrencyAmount ID

    ID #REQUIRED

    Amount CDATA #REQUIRED

    CurrCodeType NMTOKEN 'ISO4217-A'

    CurrCode CDATA #REQUIRED>
    <!ELEMENT PayProtocol (PackagedContent*) >
    <!ATTLIST PayProtocol ID ID #REQUIRED

    xml:lang NMTOKEN #IMPLIED

    ProtocolId NMTOKEN #REQUIRED

    ProtocolName CDATA #REQUIRED

    ActionOrgRef NMTOKEN #REQUIRED

    PayReqNetLocn CDATA #IMPLIED

    SecPayReqNetLocn CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED >
    <!-- BRAND SELECTION COMPONENT -->
    <!ELEMENT BrandSelection (BrandSelBrandInfo?,

    BrandSelProtocolAmountInfo?,

    BrandSelCurrencyAmountInfo?)>

    <!ATTLIST BrandSelection ID

    ID #REQUIRED

    BrandListRef NMTOKEN #REQUIRED

    BrandRef NMTOKEN #REQUIRED

    ProtocolAmountRef NMTOKEN #REQUIRED
    CurrencyAmountRef NMTOKEN #REQUIRED>
    <!ELEMENT BrandSelBrandInfo (PackagedContent+)>
    <!ATTLIST BrandSelBrandInfo ID ID #REQUIRED
    ContentSoftwareId CDATA #IMPLIED>
    <!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
    <!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
    ContentSoftwareId CDATA #IMPLIED>
    <!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
    <!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
    ContentSoftwareId CDATA #IMPLIED >
    <!-- PAYMENT COMPONENT -->
    <!ELEMENT Payment EMPTY>

    <!ATTLIST Payment ID

    ID #REQUIRED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    BrandListRef NMTOKEN #REQUIRED

    SignedPayReceipt (True | False) #REQUIRED

    StartAfterRefs NMTOKENS #IMPLIED>
    <!-- PAYMENT SCHEME COMPONENT -->
    <!ELEMENT PaySchemeData (PackagedContent+) >

    <!ATTLIST PaySchemeData ID

    ID #REQUIRED

    PaymentRef NMTOKEN #IMPLIED

    ConsumerPaymentId CDATA #IMPLIED

    PaymentHandlerPayId CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    <!-- PAYMENT RECEIPT COMPONENT -->
    <!ELEMENT PayReceipt (PackagedContent*) >

    <!ATTLIST PayReceipt ID ID #REQUIRED

    PaymentRef NMTOKEN #REQUIRED

    PayReceiptNameRefs NMTOKENS #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>

    <!-- PAYMENT NOTE COMPONENT -->
    <!ELEMENT PaymentNote (PackagedContent+)>
    <!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
    <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
    <!ATTLIST Delivery ID ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    DelivExch (True | False) #REQUIRED

    DelivAndPayResp (True | False) #REQUIRED

    ActionOrgRef NMTOKEN #IMPLIED>

    <!ELEMENT DeliveryData (PackagedContent*) >

    <!ATTLIST DeliveryData xml:lang

    NMTOKEN #IMPLIED

    OkFrom CDATA #REQUIRED

    OkTo CDATA #REQUIRED

    DelivMethod NMTOKEN #REQUIRED

    DelivToRef NMTOKEN #REQUIRED

    DelivReqNetLocn CDATA #IMPLIED

    SecDelivReqNetLocn CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED>
    <!-- CONSUMER DELIVERY DATA COMPONENT -->
    <!ELEMENT ConsumerDeliveryData EMPTY>
    <!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
    ConsumerDeliveryId CDATA #REQUIRED>
    <!-- DELIVERY NOTE COMPONENT -->
    <!ELEMENT DeliveryNote (PackagedContent+)>

    <!ATTLIST DeliveryNote ID

    ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    DelivHandlerDelivId CDATA #IMPLIED

    ContentSoftwareId CDATA #IMPLIED >
    <!-- STATUS COMPONENT -->
    <!ELEMENT Status EMPTY>

    <!ATTLIST Status ID

    ID #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    StatusType NMTOKEN #REQUIRED

    ElRef NMTOKEN #IMPLIED

    ProcessState (NotYetStarted | InProgress |

    CompletedOk | Failed | ProcessError) #REQUIRED
    CompletionCode NMTOKEN #IMPLIED

    ProcessReference CDATA #IMPLIED

    StatusDesc CDATA #IMPLIED >

    <!-- TRADING ROLE DATA COMPONENT -->
    <!ELEMENT TradingRoleData (PackagedContent+)>
    <!ATTLIST TradingRoleData ID ID #REQUIRED
    <!-- INQUIRY TYPE COMPONENT -->
    <!ELEMENT InquiryType EMPTY>

    <!ATTLIST InquiryType ID

    ID #REQUIRED

    Type NMTOKEN #REQUIRED

    ElRef NMTOKEN #IMPLIED

    ProcessReference CDATA #IMPLIED >
    <!-- ERROR COMPONENT -->
    <!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*)>

    <!ATTLIST ErrorComp ID

    NMTOKEN #REQUIRED

    xml:lang NMTOKEN #REQUIRED

    ErrorCode NMTOKEN #REQUIRED

    ErrorDesc CDATA #REQUIRED

    Severity (Warning|TransientError|HardError) #REQUIRED

    MinRetrySecs CDATA #IMPLIED

    SwVendorErrorRef CDATA #IMPLIED>

    <!ELEMENT ErrorLocation EMPTY >

    <!ATTLIST ErrorLocation ElementType

    NMTOKEN #REQUIRED

    IotpMsgRef NMTOKEN #IMPLIED

    BlkRef NMTOKEN #IMPLIED

    CompRef NMTOKEN #IMPLIED

    ElementRef NMTOKEN #IMPLIED

    AttName NMTOKEN #IMPLIED>
    <!--
    **********************
    * ТОРГОВЫЕ БЛОКИ *
    ********************** -->

    <!-- TRADING PROTOCOL OPTIONS BLOCK -->
    <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
    <!ATTLIST TpoBlk ID ID #REQUIRED >
    <!-- TPO SELECTION BLOCK -->
    <!ELEMENT TpoSelectionBlk (BrandSelection+)>
    <!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
    <!-- OFFER RESPONSE BLOCK -->
    <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
    <!ATTLIST OfferRespBlk ID ID #REQUIRED >

    <!-- AUTHENTICATION REQUEST BLOCK -->
    <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
    <!ATTLIST AuthReqBlk ID ID #REQUIRED>

    <!-- AUTHENTICATION RESPONSE BLOCK -->
    <!ELEMENT AuthRespBlk (AuthResp?, Org*)>
    <!ATTLIST AuthRespBlk ID ID #REQUIRED>

    <!-- AUTHENTICATION STATUS BLOCK -->
    <!ELEMENT AuthStatusBlk (Status) >
    <!ATTLIST AuthStatusBlk ID ID #REQUIRED>

    <!-- PAYMENT REQUEST BLOCK -->
    <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
    Payment, PaySchemeData?, Org*, TradingRoleData*)>
    <!ATTLIST PayReqBlk ID ID #REQUIRED>

    <!-- PAYMENT EXCHANGE BLOCK -->
    <!ELEMENT PayExchBlk (PaySchemeData)>
    <!ATTLIST PayExchBlk ID ID #REQUIRED>

    <!-- PAYMENT RESPONSE BLOCK -->
    <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
    PaymentNote?, TradingRoleData*) >
    <!ATTLIST PayRespBlk ID ID #REQUIRED>
    <!-- DELIVERY REQUEST BLOCK -->
    <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
    ConsumerDeliveryData?, TradingRoleData*) >
    <!ATTLIST DeliveryReqBlk ID ID #REQUIRED>

    <!-- DELIVERY RESPONSE BLOCK -->
    <!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
    <!ATTLIST DeliveryRespBlk ID ID #REQUIRED>

    <!-- INQUIRY REQUEST BLOCK -->
    <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? )>
    <!ATTLIST InquiryReqBlk ID ID #REQUIRED >

    <!-- INQUIRY RESPONSE BLOCK -->
    <!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
    <!ATTLIST InquiryRespBlk ID ID #REQUIRED
    LastReceivedIotpMsgRef NMTOKEN #IMPLIED
    LastSentIotpMsgRef NMTOKEN #IMPLIED>

    <!-- PING REQUEST BLOCK -->
    <!ELEMENT PingReqBlk (Org*)>
    <!ATTLIST PingReqBlk ID ID #REQUIRED>

    <!-- PING RESPONSE BLOCK -->
    <!ELEMENT PingRespBlk (Org+)>
    <!ATTLIST PingRespBlk ID ID #REQUIRED
    PingStatusCode (Ok | Busy | Down) #REQUIRED
    BR/P> xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>

    <!-- ERROR BLOCK -->
    ><!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*)>
    <!ATTLIST ErrorBlk ID ID #REQUIRED>

    <!-- CANCEL BLOCK -->
    <!ELEMENT CancelBlk (Status)>
    <!ATTLIST CancelBlk ID ID #REQUIRED>
    <!--
    *****************************
    * Определение блока подписи *
    ***************************** -->
    <!ELEMENT IotpSignatures (Signature+ ,Certificate*)>
    <!ATTLIST IotpSignatures ID ID #IMPLIED>

    <!--
    *******************************************
    * Определение компонента подписи IOTP *
    ******************************************* -->

    <!ELEMENT Signature (Manifest, Value+) >
    <!ATTLIST Signature ID ID #IMPLIED>

    <!ELEMENT Manifest ( Algorithm+,
    Digest+,
    Attribute*,
    OriginatorInfo,
    RecipientInfo+ )>

    <!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED>

    <!ELEMENT Algorithm (Parameter*)>
    <!ATTLIST Algorithm ID ID #REQUIRED
    >type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED>

    <!ELEMENT Digest (Locator, Value)>
    <!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED>

    <!ELEMENT Attribute ( ANY ) >
    <!ATTLIST Attribute type NMTOKEN #REQUIRED
    >critical ( true | false ) #REQUIRED>

    <!ELEMENT OriginatorInfo ANY >
    <!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED>

    <!ELEMENT RecipientInfo ANY >
    <!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED
    SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
    RecipientRefs NMTOKENS #IMPLIED>

    <!ELEMENT KeyIdentifier EMPTY>
    <!ATTLIST KeyIdentifier value CDATA #REQUIRED>

    <!ELEMENT Parameter ANY >
    <!ATTLIST Parameter type CDATA #REQUIRED>
    ><!--
    *******************************************
    * Определение компонента сертификата IOTP *
    ******************************************* -->
    <!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) )>

    <!ATTLIST Certificate ID ID #IMPLIEDtype NMTOKEN #REQUIRED>

    <!ELEMENT IssuerAndSerialNumber EMPTY >
    <!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA
    #REQUIRED>
    <!--
    **************************************
    * Определение компонента SHARED IOTP *
    ************************************** -->
    <!ELEMENT Value ( #PCDATA )>
    <!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64'>

    <!ELEMENT Locator EMPTY>
    <!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED>

    14. Словарь

    В этом разделе содержится словарь некоторых терминов, используемых в данной спецификации.

    Имя

    Описание

    Аутентификатор

    Организация, которая запрашивает аутентификацию другой организации

    Аутентифицируемый

    Организация, которая осуществляет аутентификацию у аутентификатора

    Рабочая ошибка (Business Error)

    Смотри компонент Status.

    Вид платежа (Brand)

    Вид платежа представляет собой идентификатор определенного типа платежного инструмента. Список видов платежа явлется перечнем платежных опций, которые предоставляются продавцом покупателю и из которого последний выбирает вид оплаты. Каждый вид платежа может иметь разных кассиров. Примеры видов платежей включают в себя:

    о   частные и корпоративные виды платежей, например MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, и т.д.. вльготные виды платежа (смотри ниже). Последние включают в себя:

    o   магазинные виды платежа, где платежный инструмент предоставляется покупателю конкретным продавцом, например Walmart, Sears или Marks and Spencer (UK)

    o   комбинированные виды платежа, например American Advantage Visa, где компания использует свою собственную системы о   платы, которая совмещается с каким-то корпоративным видом платежей.

    Покупатель

    Организация, которая обычно платит за товары или услуги.

    ContentSoftwareId

    Содержит информацию, которая идентифицирует программу, генерирующую содержимое элемента. Ее целью является помощь в разрешении проблем совместимости, которые могут возникнуть в результате несоответствия между сообщениями, выработанными различными программами. Это текстовая строка на языке, определенном xml:lang. Этот идентификатор должен содержать как минимум:

  • наименования разработчика программы
  • название программы
  • версию программы и
  • структуру программы
  • Рекомендуется, чтобы этот атрибут включался всякий раз, когда программа, которая сформировала содержимое, не может быть идентифицирована атрибутом SoftwareID Id-компонента сообщения (смотри раздел 3.3.2)

    Агент обслуживания

    Организация, которая обслуживает покупателя, обычно от имени продавца. Примеры обслуживания покупателя включают в себя, реагирование на задачи, которые ставит покупатель в ходе реализации транзакций IOTP, в которых он участвует.

    Агент доставки

    Организация, которая непосредственно доставляет товары или услуги покупателю от имени продавца. Доставка может иметь цифровую форму (напр., в виде сообщений [MIME]), или физическую форму с привлечением почты или курьеров.

    Документальный обмен

    Документальный обмен состоит из последовательности сообщений, которыми обмениваются партнеры в рамках одного или двух торговых операций одновременно. Документальные обмены могут комбинироваться, образуя конкретную транзакцию IOTP.

    Двойственный вид платежа (Dual Brand)

    Двойственный вид платежа означает, что один платежный инструмент может использоваться так, как будто имеются два независимых вида платежа. Например, японская карта "UC" MasterCard может быть использована как UC-карта или как обычная MasterCard. Платежи с помощью UC-карты и MasterCard могут иметь разных Кассиров. Это означает, что:

    o   Продавец рассматривает, например "UC" и "MasterCard" как два независимых вида платежа, когда предлагает Покупателю список видов платежей, Покупатель выбирает вид платежа, например "UC" или "MasterCard,

    o   Приложение IOTP Покупателя определяет, какой платежный инструмент подходит для выбранного вида платежа, и делает свой выбор.

    Блок Error

    Блок Error сообщает, что в полученном сообщении IOTP обнаружена техническая ошибка. Обычно технические ошибки вызываются ошибками в XML или сбоями в процессе обработки сообщения. Часто генерация или получение блока Error вызывает прерывание транзакции. Эти ошибки отличаются от рабочих ошибок (Business Error), о которых сообщается в компонентах Status. Последние ошибки также могут привести к срыву выполнения транзакции.

    Блок Exchange

    Блок Exchange посылается при торговом обмене от одной торговой роли к другой. Он содержит один или более торговых компонентов. Блоки Exchange при торговом обмене всегда посылаются после блоков Request и до блока Response (отклика). Соджержимое блока Exchange зависит от типа торгового обмена.

    Сообщение IOTP

    Сообщение IOTP является самой внешней структурой, в которую помещаются документы, которыми обмениваются торговые роли, принимающие участие в сделке. Это хорошо сформатированный XML-документ. Документы, которые содержат сообщение, состоят из:

    o   блок ссылок транзакции, служащий для однозначной идентификации, частью которой является сообщение IOTP;

    o   опционный блок Signature, который служит для цифровой подписи торговых блоков или компонентов, связанных с транзакцией IOTP;

    o   опционный блок Error для уведомления о технических ошибках, содержащихся в предыдущем полученном сообщении IOTP и

    o   последовательность торговых блоков IOTP, которые несут данные, необходимые для выполнения транзакции.

    Транзакция IOTP

    Транзакция IOTP (Internet Open Trading Protocol) представляет собой набор IOTP-сообщений, передаваемых торговыми ролями. Правила о том, что могут содержать IOTP-сообщения, определяются типом транзакции.

    Тип транзакции IOTP

    Тип транзакции идентифицирует ее разновидность. Примерами транзакции могут служить: покупка, возврат денег, аутентификация, отзыв, депозит. Типы транзакции IOTP определяет:

    o   торговые обмены, которые могут включаться в транзакцию;

    o   то, как эти торговые обмены могут комбинироваться, чтобы обеспечить достижение цели транзакции;

    o   какие торговые блоки могут быть включены в IOTP-сообщения, образующие транзакцию.

    Продавец

    Организация, которая предоставляет товары или услуги, и получает выгоду от платежей за них

    Агент обслуживания Покупателя

    Организация, которая вовлекается в диалог с покупателем от имени продавца с целью разрешения возникающих проблем

    Организация

    Компания или частное лицо, которое принимает участие в сделке и выполняет определенную торговую роль. Организации могут выполнять и несколько торговых ролей в одной сделке

    Кассир

    Организация, которая физически получает платеж от покупателя для продавца

    Платежный инструмент

    Платежный инструмент представляет собой средство, с помощью которого покупатель платит за товары или услуги, предлагаемые продавцом. Это может быть, например:

  • кредитная карта, такая как MasterCard или Visa;
  • >
  • дебетная карта, такая как MasterCard's Maestro;
  • смарт-карта, базирующаяся на электронном платежном инструменте, таком как Mondex, GeldKarte или Visa Cash
  • электронный платежный счет, базирующийся на программе, такой как CyberCash's CyberCoin или DigiCash.
  • Все платежные инструменты имеют номер, обычно это номер счета, с помощью которого платежный инструмент может быть идентифицирован.

    Льготный вид платежа

    Льготный вид платежа предполагает, что, если покупатель воспользуется этим видом оплаты, тогда он получит дополнительную выгду, которая может быть реализована двумя путями:

  • в момент покупкиse. Например, если покупатель платит с помощью "Walmart MasterCard" на WEB-сайте Walmart, тогда он получает скидку 5%, а это означает, что покупатель в действительности заплатит меньше,
  • от эмитента платежного инструмента (карты), когда платеж появится в ведомости. Например, если сумма платежей с использованием данного платежного инструмента превысила некоторое значение.
  • В списке видов платежа, предлагаемом продавцом, каждый льготный вид должен идентифицироваться, как независимый.

    Компонент Receipt (расписка)

    Компонент Receipt является записью об успешном завершении торгового обмена. Примеры компонентов Receipt включают в себя: платежные расписки и накладные при доставке (Delivery Notes). Их содержимое зависит от технологии выполнения торгового обмена. Например, платежная расписка SET (Secure Electronic Transaction) состоит из платежных сообщений SET, которые фиксируют результат оплаты.

    Блок запроса

    Блок запроса является торговым блоком, который содержит запрос начала торгового обмена. Торговые компоненты в блоке запроса могут быть подписаны с помощью блока Signature, что позволит идентифицировать отправителя. Авторизация начала торгового обмена может быть выполнена с помощью подписей, содержащихся в компонентах Receipt, которые вложены в блоки откликов предыдущего торгового обмена. Примерами блоков запроса могут служить запросы платежа и запросы доставки

    Блок отклика

    Блок отклика является торговым блоком, который указывает, что торговый обмен завершился. Он посылается торговой ролью, которая получила блок запроса, торговой роли. Блок отклика содержит компонент Status с информацией о завершении торгового обмена, например, он указывает, завершился ли торговый обмен успешно. Для некоторых торговых обменов блок отклика содержит компонент Receipt (расписка). Компоненты Receipt могут цифровым образом подписывать сообщение с использованием блока Signature, что делает завершение торгового обмена неопровержимым. Примеры блоков отклика включают в себя отклики предложения, платежа и доставки.

    Блок подписи

    Блок подписи является торговым блоком, который содержит одну или более цифровых подписей в виде компонентов Signature. Компонент Signature может цифровым образом подписывать любой блок или компонент в любом сообщении IOTP

    Компонент Status

    Компонент Status содержит информацию, которая описывает состояние торгового обмена. До завершения торгового обмена компонент Status может указывать на то, как он проходит. Если же торговый обмен завершился, компонент Status может говорить лишь об успешном завершении или о наличии рабочей ошибки. Рабочая ошибка указывает, что продолжение торгового обмена невозможно, так как нарушено какое-то правило, например, "нет достаточных средств". При этом не предполагается каких-либо технических ошибок, связанных с содержимым или форматом IOTP-сообщения в транзакции.

    Техническая ошибка

    Смотри блок Error.

    Торговый блок

    Торговый блок состоит из одного или более торговых компронент. Один или более торговых блоков может содержаться в IOTP-сообщениях, которые пересылаются в форме XML-документов от одной торговой роли к другой. Сущетсвует три типа торговых блоков:

    o блок Request,
    o блок Exchange или
    o блок Response

    Торговый компонент

    Торговый компонент является собранием XML-элементов и атрибутов. Торговые компоненты являются дочерними элементами Торговых блоков. Примерами торговых компонентов являются: Предложение, Список видов платежей, Платежная расписка, Доставка [информации], Сумма платежа

    Торговый обмен

    Торговый обмен предполагает обмен последовательностью документов, пересылаемых между торговыми ролями. Документы могут иметь форму торговых блоков или они могут быть пересланы каким-то другим образом, например, путем ввода данных на WEB-странице. Каждый торговый обмен состоит из трех главных частей:

  • посылки блока запроса торговой ролью (инициатором) другой торговой роли (получателю);
  • опционного обмена одним или более блоков между инициатором и получателем до тех пор пока
  • торговая роль, которая получила блок запроса, не отправит блок отклика инициатору.

  • Примерами торговых обменов/услуг могут служить:

  • платеж, где покупатель осуществляет платеж кассиру;
  • доставка, где покупатель запрашивает, и опционно получает, товар или услугу от агента доставки;
  • аутентификация, где любая торговая роль может запросить и получить информацию о другой торговой роли;
  • предложение, которое получает покупатель от продавца, имеет целью предложить какую-то торговую сделку (транзакцию).
  • Торговая роль

    Торговая роль идентифицирует различные способы, которыми организации могут участвовать в сделке. Существует пять торговых ролей: Покупатель, Продавец, Кассир, Агент доставки и Агент обслуживания покупателя.

    Блок ссылок транзакции

    Блок ссылок транзакции идентифицирует транзакцию IOTP. Он содержит данные, которые идентифицируют:

  • тип транзакции;
  • транзакцию IOTP, снабжая ее уникальным идентификатором;
  • сообщение IOTP, снабжая его уникальным идентификатором.
  • Блок ссылок транзакции может также содержать ссылки на другие транзакции, которые, вообще говоря, могут и не быть транзакциями IOTP

    15. Ссылки

    [Base64]

    Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

    [DOM-HASH]

    Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.

    [DNS]

    Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

    [DNS]

    Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

    [DSA]

    The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project.

    [ECCDSA]

    Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986.

    [HMAC]

    Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

    [HTML]

    Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.

    [HTML]

    Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/

    [HTTP]

    Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996.

    [HTTP]

    Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC-2616, June 1999.

    [IANA]

    The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/

    [ISO4217]

    ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.

    [IOTPDSIG]

    Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC-2802, April 2000.

    [MD5]

    Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992.

    [MIME]

    Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

    [MIME]

    Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996.

    [MIME]

    Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, November 1996.

    [MIME]

    Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC-2047, November 1996.

    [MIME]

    Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC-2048, November 1996.

    [MIME]

    Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC-2049, November 1996.

    [OPS]

    Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others.

    [RFC1738]

    Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994.

    [RFC2434]

    Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998.

    [RSA]

    RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978.

    [SCCD]

    Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development.

    [SET]

    Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>.

    [SSL/TLS]

    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999.

    [SHA1]

    [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm

    [UTC]

    Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601.

    [UTF16]

    The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1

    [X.509]

    ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate)

    [XML

    Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names"

    [XML]

    Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.

    Previous: 4.6 Электронная торговля в Интернет    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.6.2 SET и другие системы осуществления платежей


    previous up down next index index
    Previous: 4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8

    4.6.2 SET и другие системы осуществления платежей
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Идеальная платежная система должна отвечать следующим требованиям:

    1. Безопасность системы должна препятствовать воровству денег на всех этапах выполнения операции.
    2. Себестоимость операции должна быть низкой для всех участников.
    3. Система должна обеспечивать высокий уровень конфиденциальности для клиента.
    4. Схема и реализация должны быть простыми (не нужно использовать сложных протоколов)
    5. Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).
    6. Система должна уметь выполнять операции с любыми долями самой мелкой денежной единицы.
    7. Должна предоставлять достаточное количество данных для целей аудита.
    8. Система должна быть свободной, то есть не иметь ограничений владельца.

    Ни одна из существующих платежных систем не отвечает всем этим требованиям в полной мере. Существует много платежных схем, например:

    А. Электронные монеты
    Б. Электронные чеки
    В. Электронные переводы (трансферты)

    Разумеется, могут существовать и методы, сочетающие в себе любые комбинации этих схем. Эти методы должны работать не только с традиционными деньгами, но с их заменителями, акциями, облигациями, золотыми слитками, товарами и услугами. Во всех моделях помимо основных участников - продавца и покупателя , необходим посредник. Назовем его банкиром (кассиром) . Теперь рассмотрим названные выше платежные модели более подробно.

    Модель электронных монет

    Эта схема моделирует традиционную денежную систему. Банкир формирует цифровые сертификаты, называемые монетами, и приобретаемые участниками сделок. Эти сертификаты могут быть банкиром выкуплены. Клиенты используют эти сертификаты (монеты) для расчетов как обычные деньги. Эту модель достаточно трудно реализовать из-за проблемы повторного использования сертификатов для покупок. Есть у этой модели и преимущества, например, плательщик не должен иметь контакт с банкиром в реальном масштабе времени в момент платежа, да и уровень конфиденциальности здесь вполне приемлем.

    Модель электронных чеков

    Данная модель с хорошей точностью воспроизводит практику применения обычных чеков. Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен.

    Модель электронных переводов

    Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет.

    Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.

    • Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.
    • Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.
    • Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.
    • Банкир должен иметь возможность доказать третьей стороне, что он при работе со счетами строго следовал платежным поручениям. Это позволит ему отвести обвинения в осуществлении неавторизованных платежных операций.
    • Плательщик должен быть уверен, что платеж будет осуществлен именно тому продавцу товара или услуг, кому он хотел. Это подразумевает иммунитет системы против преднамеренных искажений платежных сообщений.
    • Система должна противостоять фальсификации расписок банкира.
    • Все возможные конфликты между банкиром и его клиентами должны разрешаться с помощью анализа сообщений, снабженных электронными подписями.
    • Конфликты между клиентами должны разрешаться без участия банкира.
    • Система должна быть устойчива против любых форм фальсификации. Даже в случае раскрытия секретного ключа клиента, она не должна допускать слишком больших потерь.

    Не менее важную роль имеет конфиденциальность любых финансовых операций.

    • Посторонние лица не должны получать никакой существенной информации об активности клиентов платежной системы и банкира.
    • Получатель платежа не должен получать информации, позволяющей идентифицировать плательщика.
    • Банкир не должен получать информацию о том, какой товар или услуга оплачиваются.

    Это не следует рассматривать как исчерпывающий список требований к безопасности и конфиденциальности.

    4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)

    Разработчики технологии WWW, HTML и XML (группа W3C; http://www.w3.org/TR/WD-mptp-951122) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром ("PayWord and MicroMint - Two Simple Micropayment Schemes", R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.

    Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.

    При разработке протокола принимались во внимание следующие риски.

    • Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)
    • Мошенничество (например, направление фиктивного платежного поручения).
    • Неавторизованный отзыв платежа
    • Неавторизованная модификация заказа
    • Ошибка при выполнении кредитной операции
    • Дублирование платежного поручения (клиентом или третьим лицом)
    • Отказ от услуги (клиент или продавец отказываются использовать свои счета)
    • Отказ выполнения платежа
    • Недоставка (платеж получен, а товар не доставлен).

    Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной.

    Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина.

    Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид:

    СП = [B, ID, AП, PKП, E, IП]SKB

    где B - идентификатор (имя) брокера; ID - идентификатор покупателя; AП - адрес доставки; PKП - общедоступный ключ покупателя; Е - время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП - дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB - секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером.

    Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии).

    Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, ., wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению:

    wi = H(wi+1) для i= n-1, n-2,.,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H - представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера.

    i-платеж (для i = 1, 2, .) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, ., wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца.

    Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж.

    В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.

    4.6.2.2. MicroMint

    MicroMint (при вольной интерпретации это выражение можно перевести как микромонетный двор) представляет собой еще одну платежную систему, базирующуюся на модели электронных монет. Здесь не используется общедоступный ключ шифрования. Электронные монеты в этой схеме формируются брокером, который продает их пользователям. Пользователи передают эти монеты продавцам в качестве оплаты товаров или услуг. Продавцы возвращают эти монеты брокеру, который осуществляет перевод реальных денег на счет продавца.

    Электронная монета представляет собой последовательность бит, которая может быть легко проверена, но которую достаточно трудно сформировать. Алгоритм MicroMint устроен так, что формирование большого числа монет стоит дешевле (из расчета на одну монету), чем формирование одной или нескольких. Брокер формирует партию монет, например раз в месяц. При этом действие прежней партии монет истекает, и они не могут более использоваться. Продавцы возвращают полученные монеты в конце каждого дня.

    Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х12) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.

    k-кратным столкновением называется набор строк х1, х2, ., хk для которых H(x1)=H(x2)=.=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, ., хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.

    H(x1)=H(x2)=.=H(xk)=y

    Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет. Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации.

    Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов.

    Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA - программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу.

    При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя.

    Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, ., хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется.

    Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри "PayWord and Micromint: Two simple micropayment schemes" Ronald L. Riverst и Adi Shamir, 7 мая 1996).

    Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет.

    Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.

    • Все фальшивые монеты теряют силу в конце месяца.
    • Фальшивые монеты могут быть сформированы после того, как брокер выбросил на рынок новую партию монет в начале месяца.
    • Брокер может обнаружить присутствие фальшивок из-за того, что некоторые фальшивые монеты неизбежно не соответствуют ни одной из настоящих, которые все зарегистрированы.
    • Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию.

    Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной.

    Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно.

    Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, ., хk)=h(U), где h - хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу.

    Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, ., хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),., yk=(xk) удовлетворяют условию yi+1 - yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,.,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным.

    Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев.

    Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.

    4.6.2.3. Безопасный протокол электронных платежей SET

    Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. "SET - Secure Electronic Transaction Specification"). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет. Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:

    1. Аутентификация. Все участники кредитных операций идентифицируются с помощью электронных подписей. Это касается клиента-покупателя, продавца, банкира, выдавшего кредитную карточку, и банкира продавца.
    2. Конфиденциальность. Все операции производятся в зашифрованном виде.
    3. Целостность сообщений. Информация не может быть подвергнута модификации по дороге в противном случае это будет сразу известно.
    4. Подсоединение. SET позволяет подключить к базовому сообщению дополнительный текст и послать его одному из партнеров.
    5. Безопасность. Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях.
    6. Совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.
    7. Независимость от транспортного протокола. Безопасность операций не должна зависеть от уровня безопасности транспортного протокола. Такие гарантии особенно важны, так как протокол SET ориентирован для работы в Интернет.

    На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:

    1. Регистрацию держателя карточки
    2. Регистрацию продавца
    3. Запрос покупки
    4. Авторизацию платежа
    5. Перевод денег
    6. Кредитные операции
    7. Возврат денег
    8. Отмену кредита
    9. Дебитные операции

    Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца.

    Практика электронной торговли позволяет выделить семь этапов сделки.

    Этап

    Действие

    1

    Владелец карты просматривает позиции каталога продавца:

    1. В реальном масштабе времени на WEB-сервере
    2. На CD-диске на своей рабочей станции
    3. Читая бумажную версию каталога
    4. Через поисковую систему посредника

    2

    Владелец карты выбирает понравившийся товар или услугу.

    3

    Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов).

    4

    Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт.

    5

    Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов.

    6

    Продавец запрашивает платежную авторизацию от эмитента карты.

    7

    Продавец посылает подтверждение заказа.

    8

    Продавец доставляет заказанный товар или услугу

    9

    Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты.

    Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов 5, 6, 7 и 9. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях.

    Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие.

    Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры - код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму.

    Каждая цифра номера умножается на его "вес". Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы).

    Схема взаимодействия субъектов в протоколе SET показана на рис. 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.

    Рис. 4.6.2.1. Схема взаимодействия субъектов протокола SET

    1. Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.
    2. Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе - номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).
    3. Продавец выделяет часть, адресованную банкиру, и направляет ее по месту назначения. Программа SET WEB-сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка.
    4. Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.
    5. Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.
    6. Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.
    7. WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.
    8. Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.
    9. Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).

    Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом.

    Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование.

    В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.

    Рис. 4.6.2.2. Регистрация владельца карты в центре сертификации

    Сертификаты владельцев карт являются электронным представлением самих платежных карт. Так как они подписаны цифровым образом, их не сможет модифицировать третья сторона. Сертификат владельца карты не содержит номера счета и срока ее действия. Вместо этого там закодирована с привлечением хэш технологии информация о счете и секретный код, известный только программе владельца карты. Если номер счета, срок его действия и секретный код известны, корректность сертификата может быть проверена, но извлечь эту информацию из сертификата, даже зная часть перечисленных параметров практически невозможно. В рамках протокола SET владелец карты передает информацию о счете и секретный код расчетному центру, где эта информация верифицируется.

    Сертификат посылается владельцу карты только в случае, когда это одобряется финансовой организацией, выпустившей эту карту. Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы.

    Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже.

    Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы.

    Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.

    Рис. 4.6.2.3. Регистрация продавца.

    Продавец должен зарегистрироваться в СА до того, как он получит платежные инструкции от владельца карты или будет участвовать в транзакциях с расчетным центром. Перед посылкой запроса СА продавец должен получить его общедоступный ключ. Продавец должен также скопировать регистрационную форму в своем банке и идентифицировать получателя в запросе регистрации, посылаемом в СА. Регистрационная процедура начинается с посылки СА запроса сертификата СА, содержащего его общедоступный ключ и соответствующую регистрационную форму. СА идентифицирует банк продавца и выбирает подходящую регистрационную форму. В отклик СА вкладывается эта форма и его сертификат, содержащий общедоступный ключ. Этот сертификат продавец в дальнейшем использует в регистрационном процессе. Раз программа продавца имеет копию СА-сертификата, продавец может воспринимать платежные инструкции и обрабатывать транзакции SET. Прежде чем запрос сертификата будет обработан, продавец должен установить связь со своим банком (получателем). Продавцу нужны две пары общедоступных/секретных ключей - для ключевого обмена и для цифровой подписи. Эти ключи формируются программой продавца. Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА.

    Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу.

    После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу.

    Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца.

    SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный. В рамках протокола используются следующие значения символов-префиксов участников сделки:

    Символы-префиксы

    Участник сделки

    C

    Владелец карты (Cardholder)

    M

    Продавец (Merchant)

    P

    Расчетный центр (Payment Gateway)

    CA

    Сертификационный центр (Certificate Authority)

    Рассмотрим диаграмму конечных состояний протокола SET (см. рис. 4.6.2.4).

    Рис. 4.6.2.4. Диаграмма реализации протокола SET

    Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.).

    Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным "истинно", так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured - сделка оплачена) и заказ обрабатывается.

    Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued).

    Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена. С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes).

    Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты.

    Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:

    XID

    20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения).

    RRPID

    20-байтовое число, которое однозначно идентифицирует запрос.

    locallD-M

    1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца

    paySysID

    1-64 байтовый идентификатор транзакции

    MerOrderNum

    1-25 байтовый номер заказа продавца

    Рассмотрим более подробно функции субъектов протокола SET.

    Держатель карты (Cardholder)

    Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги.

    Продавец (Merchant)

    Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей.

    Эмитент (Issuer)

    Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции.

    Получатель (Acquirer)

    Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент.

    Расчетный центр
    (Payment Gateway)

    Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем.

    Платежная система (Brand)

    Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.)

    Сертификационный центр (Certificate Authority -CA)

    Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА - гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем.

    Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq).

    В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции.

    Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются.

    Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты).

    Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard).

    Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты.

    Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов. Банк продавца получает свои сертификаты из платежной системы (brand).

    Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы.

    Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583).

    Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.

    • Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).
    • Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.

    Каждая платежная система обеспечивает поддержку CRL в пределах зоны своей ответственности. Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы.

    Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций.

    Информация о счете владельца карты для продавца шифруется его общедоступным ключом. Доступ продавца к этой информации является опционным, (см. замечания выше). При выборе данной опции должны быть приняты меры для обеспечения конфиденциального хранения этих данных на сервере продавца. Как минимум эта информация должна храниться в зашифрованном виде и к ней должен быть ограниченный доступ.

    Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения.

    Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью.

    Цифровой конверт сообщения (MessageWrapper). MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется. Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1.

    Таблица 4.6.2.1. Поля MessageWrapper

    Название поля

    Описание

    Message-Wrapper

    {MessageHeader, Message, [MWExtension]}}

    MessageHeader

    {Version, Revision, Date, [MessageID], [RRPID], SWIdent}

    Version

    Версия SET-сообщения

    Revision

    Подтип SET-сообщения

    Date

    Дата генерации сообщения

    MessageID

    {[LID-C], [LID-M], [XID]}

    RRPID

    Идентификатор, позволяющий объединять в пары запросы и отклики

    SWIdent

    Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов

    Message

    < PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error>

    LID-C

    Локальный идентификатор, генерируемый системой владельца карты или для его системы

    LID-M

    Локальный идентификатор, генерируемый системой продавца или для его системы

    XID

    Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes)

    MWExtension

    Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности.

    Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений.

    При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа.

    При описании протокола используется нотация представленная в таблице 4.6.2.2.

    Таблица 4.6.2.2. Нотация протокола SET

    Понятие

    Нотация

    Описание

    Группа (tuple)

    {A,B,C}

    Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы

    Компонент

    T={A,B,C}

    Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т.

    Упорядоченное объединение

    A|B|C

    Служит для обозначения упорядоченного объединения элементов A,B и C

    Опционное значение

    [A]

    Значение A является опционным

    Допускается любое вложение этих скобок

    Выбор

    <A,B,C>

    Обозначает, что должно присутствовать одно из значений A,B или C

    Опционный выбор

    [<A,B,C>]

    То же, что и предыдущее, но сам выбор опционен

    Кратное использование

    {A+}

    Группа содержит один или более элементов A

    {A*}

    Группа содержит нуль или более элементов A

    {[A]+}

    Означает, что группа содержит:

    один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать)

    Исключающее ИЛИ

    Å

    Обозначает операцию исключающее ИЛИ

    Таблица 4.6.2.3. Операторы, используемые протоколом SET

    Нотация

    Оператор

    Описание

    H(t)

    хэш

    160-битовый хэш группы t

    HMAC(t,k)

    Ключевой хэш-механизм

    160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1
    HMAC(t,k) = H(k Å opad) | H((k Å ipad)|t)),

    где ipad - байт 0х36, повторенный 64 раза;

    opad - байт 0х5С, повторенный 64 раза; а

    Å - знак операции исключающее ИЛИ.

    L(t1,t2)

    Связь

    Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)}

    Нотация операторов цифровой подписи

    S(s,t)

    Подписанное сообщение

    Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7.

    Нотация операторов двойной цифровой подписи

    SO(s,t)

    Только подпись

    Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1.

    Нотация операторов шифрования

    E(r,t)

    Асимметричное шифрование
    (цифровой конверт)

    Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData.

    EH(r,t)

    Шифрование целостности

    Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте.

    EX(r,t,p)

    Дополнительное шифрование

    Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t - группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p - параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r.

    EXH(r,t,p)

    Дополнительное шифрование с обеспечением целостности

    Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH

    EK(k,t)

    Симметричное шифрование посредством ключа k

    Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData

    Нотация операторов инкапсуляции

    Enc(s,r,t)

    Простая инкапсуляция с подписью

    Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData

    EncK(k,s,t)

    Простая инкапсуляция с подписью и предоставленным ключом

    Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData.

    EncX(s,r,t,p)

    Дополнительная инкапсуляция с подписью

    Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP

    EncB(s,r,t,b)

    Простая инкапсуляция с подписью с загрузкой

    Подписанное зашифрованное сообщение с загрузкой (baggage)

    EncBX(s,r,t,p,b)

    Дополнительная инкапсуляция с подписью и загрузкой

    Подписанное, Е-шифрованное составное сообщение с загрузкой

    OAEP - Bellare-Rogaway Optimal Asymmetric Encryption Padding
    HMAC - ключевой хэш-механизм, базирующийся на алгоритме SHA-1.

    В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит.

    Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 -(||BL||mod 8) октетов. Каждый из байтов заполнителя содержит код 8 -(||BL||mod 8).

    Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах - 030303.

    Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES.

    SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP.

    Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.

    Шаг

    Действие

    1

    Алиса запускает программу вычисления дайджеста сообщения, которое она намерена послать Бобу. Этот дайджест будет использован для проверки отсутствия модификации сообщения в процессе его транспортировки от Алисы к Бобу.

    2

    Алиса шифрует дайджест сообщения с использованием своего секретного ключа, формируя цифровую подпись.

    3

    Формируется псевдослучайный код (симметричный ключ) и с помощью его шифруется сообщение, цифровая подпись и сертификат Алисы, который содержит в себе ее общедоступный ключ. Чтобы дешифровать данное сообщение Бобу будет нужен указанный выше симметричный ключ.

    4

    Сертификат Боба, который Алиса должна была получить заранее, содержит копию общедоступного ключа Боба. Чтобы гарантировать безопасность пересылки симметричного ключа, Алиса должна зашифровать его с использованием общедоступного ключа Боба. Зашифрованный таким способом симметричный ключ заносится в одно из полей цифрового конверта (иногда единственное поле), куда в свою очередь будет вложено зашифрованное сообщение.

    5

    Алиса посылает сообщение Бобу. При этом в его состав входит:
    Сообщение, зашифрованное с применением симметричного ключа, цифровая подпись, сертификат и асимметрично зашифрованный симметричный ключ (цифровой конверт).

    6

    Боб получает сообщение от Алисы, дешифрует ключ-конверт с привлечением своего секретного ключа и получает в свое распоряжение симметричный ключ.

    7

    Боб использует симметричный ключ для дешифрования текста сообщения, подписи Алисы и ее сертификата.

    8

    Осуществляется дшифрация подписи Алисы с привлечением ее общедоступного ключа, который берется из ее сертификата. В результате получается дайджест посланного сообщения.

    9

    Боб независимо вычисляет дайджест полученного сообщения с привлечением того же алгоритма, что был использован Алисой.

    10

    Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису.

    В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи.

    Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту).

    Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения. Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения.

    В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца).

    Важным принципом при анализе работы программ SET является идемпотентность - реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа "шторма запросов", оно может не реагировать на эти запросы.

    XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения. Его длина составляет 20 байт.

    BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product.

    Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ.

    Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq.

    Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers.

    Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.

    • SignedData для вложения подписанной информации
    • EnvelopedData для инкапсуляции зашифрованных данных
    • EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма
    • DigestedData для инкапсуляции хэшированных или связанных данных

    Тип SignedData из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.

    Рис. 4.6.2.5. SignedData

    Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest.

    Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.

    Рис. 4.6.2.6. EnvelopedData

    В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo.

    Тип EncryptedData из PKCS #7 проиллюстрирован на рис. 4.6.2.7.

    Рис. 4.6.2.7. EncryptedData

    Тип DigestedData из PKCS #7 проиллюстрирован на рис. 4.6.2.8.

    Рис. 4.6.2.8. DigestedData

    Обработка сообщений

    Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4.

    Таблица 4.6.2.4. Отправление сообщения

    Шаг

    Действие

    1

    Генерация сообщения SET

    2

    Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0)

    3

    Вложить код даты, включая время.

    4

    Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается.

    5

    Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса.

    6

    Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта

    7

    Вкладывается Message

    8

    Производится DER-кодирование вложенного сообщения

    9

    Сообщение передается на транспортный уровень

    Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5.

    Таблица 4.6.2.5. Прием и обработка входного сообщения

    Шаг

    Действие

    1

    Извлекается цифровой конверт сообщения

    2

    Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode.

    3

    Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений

    4

    Произвести DER-декодирование сообщения

    5

    Если сообщение содержит SignedData, произвести следующее:

      1. Актуализовать системный кэш с учетом полученных CRL.
      2. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов
      3. Проверить подпись сообщения

    6

    Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData

    7

    Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается.

    8

    Обработать сообщение

    9

    Актуализовать системный журнал с учетом состояния транзакции

    Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:

    • Контроль сертификатов X.509
    • Контроль сертификатов SET
    • Обработку CRL (Certificate Revocation List)
    • Обработку BrandCRLIdentifier (BCI)

    На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6.

    Таблица 4.6.2.6. Верификация сертификатов

    Шаг

    Действие

    1

    Верифицировать каждый сертификат в цепи согласно правилам X.509

    2

    Проверить то, что расширения KeyUsage, CertificatePolicies, PriviteKeyUsage и AuthorityKeyIdentifier находятся в согласии c Х.509.

    3

    Если получено новое значение BCI:

    а. Проверить его подпись, используя сертификат CRL центра сертификации платежной системы

    б. Проверить, что BrandName в BCI соответствует тому, что проверено в цепочке сертификации

    в. Проверить, что дата NotAfter меньше текущей даты

    г. Проверить SequenceNum. Если оно больше чем SequenceNum из кэша BCI запомнить BCI и проверить, что все CRL, содержащиеся в BCI находятся в кэше CRL. Запомнить любой CRL, который пока нет в кэше

    4

    Провести верификацию для каждого нового полученного CRL,

    5

    Проверить каждый сертификат

    4.6.2.1.1. Оттиски (Thumbprints)

    Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:

    • UnsignedCertificate
    • UnsignedCertificateRevocationList
    • UnsignedBrandCRLIdentifier

    Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7.

    Таблица 4.6.2.7. Посылка оттиска

    Шаг

    Действие

    1

    Инициализировать буфер для запоминания оттисков

    2

    Добавить оттиск (хэш):

    • Для каждого сертификата, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому сертификату.
    • Для каждого CRL, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому CRL.
    • Для каждого BCI, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому BCI.

    3

    Присылается результат работы шага 2.

    Получатель проверяет то, что отправитель владеет всеми сертификатами, CRL и BCI, необходимыми для завершения обработки сообщения. Получатель может проигнорировать оттиски и послать эту информацию запросившему. Обработка оттисков получателем представлена в таблице 4.6.23.8.

    Таблица 4.6.2.8. Обработка оттисков получателем

    Шаг

    Действие

    1

    Инициализировать буфер для запоминания оттисков

    2

    Для каждого из них:

    • Для сертификата, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить соответствует ли оттиск (хэш) сертификата одному из полученных в сообщении-запросе. Если соответствие найдено, сертификат в кэше удаленной системы существует и его не нужно включать в отклик. Если соответствия нет или список пуст, то включить сертификат в сообщение отклик.
    • Для CRL, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствие имеется, то CRL в кэше удаленной системы существует и его не следует помещать в отклик. Если соответствия нет или список пуст, то данное CRL включается в отклик.
    • Для BCI, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли CRL-оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствия нет или список пуст, то данное CRL включается в отклик.

    3

    Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике.

    Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.

    Шаг

    Действие

    1

    Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t

    2

    Добавить результат шага 1 в группу t

    3

    Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2

    4

    Послать результат работы шага 3

    Другие варианты инкапсуляции осуществляются сходным образом.

    Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования - RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9.

    Таблица 4.6.2.9. Процедура асимметричного шифрования

    Шаг

    Действие

    1

    Инициализировать и загрузить информационные поля, зависимые от типа сообщения

    2

    Преобразовать информационные поля, подлежащие шифрованию, в формат DER

    3

    Сформировать новый ключ DES

    4

    Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC.

    5

    Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4.

    6

    Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)

    7

    Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3.

    8

    Применить OAEP для буфера цифрового конверта

    9

    Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r

    10

    Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9

    11

    Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5

    12

    Прислать результат шага 11

    Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10.

    Таблица 4.6.2.10. Асимметричное шифрование с гарантией целостности

    Шаг

    Действие

    1

    Инициализировать и загрузить информационные поля, зависимые от типа сообщения

    2

    Преобразовать информационные поля, подлежащие шифрованию, в формат DER

    3

    Вычислить хэш SHA-1 результата шага 2

    4

    Сформировать новый ключ DES

    5

    Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC.

    6

    Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5.

    7

    Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)

    8

    Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5.

    9

    Применить OAEP для буфера цифрового конверта

    10

    Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r

    11

    Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10

    12

    Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6

    13

    Прислать результат шага 12

    Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11.

    Таблица 4.6.2.11. Процедура симметричного шифрования

    Шаг

    Действие

    1

    Инициализировать и загрузить информационные поля, зависимые от типа сообщения

    2

    Преобразовать информационные поля, подлежащие шифрованию, в формат DER

    3

    Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC.

    4

    Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3.

    5

    Прислать результат шага 4

    Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования.

    Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента > content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo.

    Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7.

    В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12.

    Таблица 4.6.2.12. Процедура формирования цифровой подписи

    Шаг

    Действие

    1

    Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию

    2

    Преобразовать информацию, подлежащую подписанию в формат DER

    3

    Использовать результат шага 2 для инициализации компонента content из ContentInfo.

    4

    Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста

    5

    Вычислить дайджест сообщения, используя SHA-1 для результата шага 3

    6

    Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов

    7

    Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута - значением дайджеста, вычисленного на этапе 5

    8

    Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData

    9

    Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData

    10

    Если тип сообщения требует двух подписей, повторить шаги с 4 по 9

    Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13.

    Таблица 4.6.2.13. Процедура ключевого хэширования

    Шаг

    Действие

    1

    Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36

    2

    Установить opad равным буферу, содержащему 64 байта с кодами 0х5С

    3

    Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля.

    4

    Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad

    5

    Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4

    6

    Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора

    7

    Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad

    8

    Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7

    9

    Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора

    10

    Прислать результат работы шага 9

    Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP.

    Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора.

    Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14.

    Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.

    Шаг

    Действие

    1

    Установить B равным адресу группы t, для которой вычисляется дайджест

    2

    Установить L равным длине группы t

    3

    Инициализировать 160-битный буфер для хранения хэша SHA-1

    4

    Вычислить хэш SHA-1 для буфера, используя B и L

    5

    Положить результат шага 4 в поле digest DigestedData

    6

    Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm

    7

    Установить значение версии равным нулю

    Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1.

    Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными.

    Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15.

    Таблица 4.6.2.15. Описание алгоритма OAEP

    Шаг

    Действие

    1

    Подготовить дополнительные данные, как это описано в формате сообщения

    2

    Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию

    3

    Сформировать новый случайный ключ для DES-шифрования регулярной части данных

    4

    Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block).

    5

    Взять байт, содержащий код 0х03 (тип блока - BT), семь байтов нулей (байты верификации - V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB

    6

    Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1

    7

    Вычислить А=DB Å H1(E-Salt)

    8

    Осуществить присвоение B= E-Salt Å H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1

    9

    Присвоить I случайное значение, не равное 0х00 или 0х80

    10

    Зашифровать полученный блок R с помощью RSA

    Алгоритм работа OAEP показан на рисунке 4.6.2.9.

    В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.

    Рис. 4.6.2.9. Диаграмма работы OAEP

    Обработка ошибок

    Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения.

    Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем.

    Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое "невозможное событие" все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error . Сообщения, которые не являются протокольными для SET, просто игнорируются.

    Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.

    Шаг

    Действие

    1

    Сформировать ErrorTBC следующим образом:

    1. Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16)
    2. Сформировать новый ErrorNonce
    3. Если ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения.
    4. Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификата
    5. Если ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификата
    6. ErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика.

    2

    Подписать сообщение Error, если имеется сертификат подписи

    3

    Вызвать формирование цифрового конверта и отправить сообщение

    Для сообщения Error определены следующие поля

    Имя поля

    Описание

    Error

    <Signed Error, UnsignedError >

    SignedError

    S(EE, ErrorTBS)

    UnsignedError

    ErrorTBS

    Неподписанная версия Error будет использоваться, если объект не имеет сертификата подписи

    ErrorTBS

    { ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg}

    ErrorCode

    Цифровой код, определяющий условия ошибки (см. табл. 4.6.2.16)

    ErrorNonce

    Разовый код, который гарантирует, что подпись генерируется для трудно предсказуемых данных

    ErrorOID

    Объектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку

    ErrorThumb

    Оттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи

    ErrorMsg

    <MessageHeader, BadWrapper>

    MessageHeader

    Заголовок сообщения, которое вызвало ошибку

    BadWrapper

    Цифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт)

    Таблица 4.6.2.16. ErrorCode

    Ошибка

    Описание

    unspecifiedFailure

    Причина неудачи не фигурирует в списке стандартных ошибок

    messageNotSupported

    Этот вполне корректный тип сообщения не поддерживается получателем

    decodingFailure

    Произошла ошибка в процессе DER-кодирования сообщения

    invalideCertificate

    Сертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат.

    expiredCertificate

    Время действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат.

    revokedCertificate

    Сертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат.

    missingCertificate

    Сертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя.

    signatureFailure

    Цифровая подпись сообщения не может быть верифицирована

    badMessageHeader

    Заголовок сообщения не может быть обработан

    wrapperMsgMismatch

    Содержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения.

    versionTooOld

    Номер версии сообщения слишком стар для получателя

    versionTooNew

    Номер версии сообщения слишком нов для получателя

    unrecognizedExtension

    Сообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb идентифицирует сертификат

    messageTooBig

    Сообщение слишком длинно для получателя

    signatureRequired

    Неподписанная версия сообщения неприемлема

    messageTooOld

    Дата сообщения слишком далеко в прошлом для получателя

    messageTooNew

    Дата сообщения слишком близка для получателя

    thumbsMismatch

    Оттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне

    unknownXID

    Получен неизвестный RRPID

    challengeMismatch

    Вызов, посланный в запросе, не согласуется с вызовом в отклике

    Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут.

    Работа с сертификатами

    В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:

    • Нужно сформировать пару #1 корневых ключей R1
    • Сгенерировать сертификат для корневого ключа #1 (C1)
    • Сформировать пару #2 корневых ключей R2
    • Вычислить оттиск (хэш - H2) общедоступной составляющей R2

    С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом.

    Когда приходит время заменить корневой сертификат R1, производятся следующие операции:

    • Вычисляется общедоступная часть корневого ключа #3 (R3)
    • Определяется оттиск R3 (хэш H3)
    • Формируется сертификат корневого ключа #2 (C2 - содержит H3)

    Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.

    Рис. 4.6.2.10. Иерархия субъектов сертификации

    Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority). Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List).

    BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы.

    Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL.

    Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы.

    Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA.

    Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д.

    Любой центр сертификации выполняет следующие функции:

    • Формирование и выдача сертификата
    • Обновление сертификатов
    • Контроль работоспособности сертификатов и удаление непригодных

    Формирование сертификатов осуществляется различными методами, зависящими от типа объекта. Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования.

    Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2).

    • Владелец карты посылает запрос сертификата
    • ССА производит шифрование сертификата для защиты передачи номера платежной карты в ССА
    • Владелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССА
    • ССА откликается посылкой формы для регистрации сертификата карты
    • Владелец карты заполняет форму, которая включает в себя его общедоступный ключ, и посылает форму в ССА для регистрации
    • ССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты.

    Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель - acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.

    • Продавец посылает запрос сертификата в МСА.
    • МСА откликается посылкой регистрационной формы.
    • Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.
    • Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу.

    Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации.

    Аннулирование сертификата может производиться по разным причинам, например, из-за реального или кажущегося раскрытия секретного ключа, из-за изменения регистрационной информации или по причине истечения срока пригодности. При аннулировании идентификатор и некоторые другие характеристики сертификата заносятся немедленно в список CRL. Последний сразу подлежит рассылке всем субъектам, которые могут использовать этот сертификат.

    При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.

    Рис. 4.6.2.11. Иерархия проверок

    Основной протокол

    Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект - EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего.

    Прежде чем запросить сертификат владелец карты должен выполнить следующее:

    • Получить счет в одной из платежных систем, например, в VISA или MasterCard.
    • Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа. Понятно, что местом его хранения не может быть оперативная память, да и дисковые накопители вряд ли можно считать приемлемым местом записи, если хотя бы теоретически к ним может быть получен доступ.
    • Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации владельца карты. Это должно быть сделано в соответствии с требованиями эмитента карты.
    • Иметь URL или электронный почтовый адрес для связи с ССА.
    • Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.

    Продавец должен иметь следующее, прежде чем посылать запрос сертификата:

    • Идентификатор, присланный получателем (Acquirer - банк продавца)
    • Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа.
    • Программа продавца должна иметь определенную информацию, объем и характер которой согласуется с банком продавца.
    • URL или электронный почтовый адрес для связи с MCA.
    • Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.

    Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата:

    • Возможностью формировать пары ключей (секретый/общедоступный) и местом их надежного храниения.
    • Получить банковский идентификационный номер BIN (Bank ID)
    • Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации платежного центра. Объем и характер этой информации согласуется с банком продавца.
    • Иметь URL или электронный почтовый адрес для связи с PCA
    • Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.

    После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:

    • Приложение владельца карты посылает CardCInitReq CCA. При этом используется идентификатор платежной системы или идентификатор, полученный из стартового сообщения.
    • ССА посылает приложению SET сообщение CardCInitRes.
    • Приложение владельца карты посылает ССА сообщение RegFormReq.
    • ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.
    • Приложение владельца карты заполняет регистрационную форму, заносит свой общедоступный ключ и сертификат, подлежащий обновлению (если имеется) в CertReq и посылает его ССА.
    • ССА формирует сертификат, включает его в CertRes и посылает владельцу карты.

    Функционирование приложения продавца и платежного центра имеет свою специфику:

    • Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.
    • СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.
    • Приложение SET отображает эту форму и требования. Пользователь должен заполнить регистрационную форму и согласиться с предлагаемыми требованиями.
    • Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.
    • СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру.

    Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13. Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.

    Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА

    Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений.

    Приложение SET формирует сообщение CardCInitReq следующим образом.

    Шаг

    Действие

    1

    Генерируется RRPID

    2

    Генерируется LID-EE

    3

    Формируется новый случайный Chall-EE

    4

    Копируется BrandID, который запомнен или получен в инициализирующем сообщении

    5

    Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты

    6

    Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА

    Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17.

    Таблица 4.6.2.17. Структура сообщения CardCInitReq

    CardCInitReq

    {RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]}

    RRPID

    Идентификатор пары запрос/отклик

    LID-EE

    Локальный ID, сформированный для системы владельца карты

    Chall-EE

    Вызов владельца карты по поводу пригодности подписи, адресованный ССА

    BrandID

    Идентификатор платежной системы для запрошенного сертификата

    Thumbs

    Список оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты

    ССА, получив CardCInitReq, выполнит следующие операции:

    Шаг

    Действие

    1

    Получить CardCInitReq из сообщения Receive

    2

    Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID

    3

    Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes

    После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.

    Шаг

    Действие

    1

    Сформировать структуру данных CardCInitResTBS, для этого:

    • Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReq
    • Сформировать опционно LID-CA
    • Заполнить CAEThumb оттиском сертификата шифрования данных CCA
    • Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifier
    • Скопировать список оттисков из CardCInitReq

    2

    Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS.

    Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков.

    3

    Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты

    Формат отклика CardCInitRes представлен в таблице ниже.

    CardCInitRes

    S(CA, CardCInitResTBS)

    CardCInitResTBS

    {RRPID, LID-EE, Chall -EE, [LID-CA], CAEThumb, [BrandCRLIdentifier], [Thumbs]}

    RRPID

    Идентификатор пары запрос/отклик

    LID-EE

    Копируется из CardCInitReq

    Chall-EE

    Копируется из CardCInitReq

    LID-CA

    Локальный ID. Генерируется системой CCA или для нее

    CAEThumb

    Оттиск сертификата ключевого обмена CCA, котоый владелец карты должен использовать для шифрования RegFormReq

    BrandCRLIdentifier

    Смотри секцию описания BrandCRLIdentifier

    Thumbs

    Копируется из CardCInitR

    Приложение владельца карты обрабатывает сообщение CardCInitRes в следующей последовательности:

    Шаг

    Действие

    1

    Получить CardCInitRes из входного сообщения (Receive)

    2

    Проверить, что RRPID соответствует тому, что был послан в CardCInitReq и тому, который получен в цифровом конверте сообщения CardCInitRes. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным unknownRRPID

    3

    Проверить, что полученный список оттисков соответствует тому, что был послан в сообщении CardCInitReq. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным thumbsMismatch

    4

    Проверить, что полученный Chall-EE равен посланному в CardCInitReq. Если равенство отсутствует, посылается сообщение об ошибке с кодом ErrorCode равным challengeMismatch.

    5

    Запомнить LID-CA (если этот элемент был включен) для последующей записи в RegFormReq. Проверить, что полученный Chall-EE равен посланному в CardCInitReq.

    6

    Проверить, что приложение владельца карты поддерживает один из алгоритмов, перечисленных в туннельном расширении сертификата шифрования CA. Если приложение владельца карты не поддерживает ни одного общего с СА алгоритма, следует уведомить об этом пользователя и прервать дальнейшую обработку сообщения СА.

    Если приложение владельца карты успешно обработало отклик CardCInitRes, оно может сформировать и послать сообщение RegFormReq. Это сообщение шифруется приложением владельца карты с использованием сертификата, полученного от ССА в CardCInitRes. Последовательность формирования и посылки RegFormReq представлена ниже в таблице.

    Шаг

    Действие

    1

    Сформировать RegFormReqData согласно следующему формату:

    • Сформировать новый RRPID
    • Скопировать LID-EE, посланный в CardCInitReq
    • Сформировать новый Chall-EE2
    • Если такой элемент был включен в CardCInitRes, скопировать LID-CA
    • Заполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца карты
    • Заполнить поле языка (Language)
    • Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется).

    2

    Сформировать структуру RegFormReqTBE:

    • Ввести ReqFormReqData
    • Заполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель.
    • Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly

    3

    Оформить поле данных, подлежащих дополнительному шифрованию:

    • Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байт
    • Для маскирования PAN сгенерировать новый EXNonce

    4

    Зашифровать данные, используя оператор EXH со следующими параметрами:

    • RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE и
    • Результатом шага 3 в качестве данных, подлежащих шифрованию

    Для шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes

    5

    Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА

    Структура сообщения RegFormReq представлена в таблице 4.6.2.18.

    Таблица 4.6.2.18. Структура RegFormReq

    RegFormReq

    EXH(CA, RegFormReqData, PANOnly)

    RegFormReqData

    {RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]}

    PANOnly

    Структуру смотри в табл. ниже

    RRPID

    ID пары запрос/отклик

    LID-EE

    Копируется из CardCInitRes

    Chall-EE2

    Вызов ЕЕ, имеющий целью обновление подписи СА

    LID-CA

    Копируется из CardCInitRes

    RequestType

    Смотри табл. 4.6.2.19

    Language

    Предпочтительный язык последующего текста

    Thumbs

    Списки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты

    Поля данных PANOnly

    Имя поля

    Описание

    PAN

    Номер платежной карты владельца

    EXNonce

    Случайное число, используемое для маскирования PAN

    Таблица 4.6.2.19. Значения кодов RequestType

    Тип запроса

    Только сертификат подписи

    Только сертификат шифрования

    Оба сертификата

    Начальный запрос владельца карты

    1

    2*

    3*

    Запрос обновления владельца карты

    10

    11*

    12*

    * указывает на значения, зарезервированные для будущего использования

    Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.

    Шаг

    Действие

    1

    Извлечь RegFormReq из входного сообщения

    2

    Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя.

    3

    Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка.

    4

    Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID

    После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.

    Шаг

    Действие

    1

    Сформировать RegFormTBS в соответствии со следующей процедурой:

    • Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqData
    • Если в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса.
    • Сгенерировать новый Chall-CA
    • Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier.
    • Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде:
    1. Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и Language
      1. Включить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено.
      2. Опционно добавляется URL для отображения логотипа платежной системы или карты.

    2. CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes.
    • Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData:
        1. Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты.
        2. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.

    2

    Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.

    3

    Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes

    Структура сообщения RegFormRes представлена в таблице 4.6.2.20.

    Таблица 4.6.2.20. Структура RegFormRes

    RegFormRes

    S(CA, RegFormResTBS)

    RegFormResTBS

    {RRPID, LID-EE, Chall-EE2,[LID-CA], Chall-CA, [CAEThumb], RequestType, RegFormOrReferral, [BrandCRLIdentifier], [Thumbs]}

    RRPID

    ID пары запрос/отклик

    LID-EE

    Копируется из RegFormReq

    Chall-EE2

    Копируется из RegFormReq

    LID-CA

    Локальный ID. Формируется для системы СА.

    Chall-CA

    СА обращение по поводу пригодности сертификата запрашивающей стороны

    CAEThumb

    Оттиск сертификата ключевого обмена, который должен использоваться для шифрования CertReq. Если это поле отсутствует, используется сертификат, идентифицированный в CardCIntRes.

    RequestType

    Смотри табл. 4.6.2.19

    RegFormOrReferral

    Смотри табл. 4.6.2.21

    BrandCRLIdentifier

    Смотри описание в разделе о BrandCRLIdentifier ниже.

    Thumbs

    Копируется из RegFormReq

    Таблица 4.6.2.21. Структура поля RegFormOrReferral

    RegFormOrReferral

    <RegFormData, ReferralData>

    RegFormData

    {[RegTemplate], PolicyText}

    ReferralData

    {RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}

    RegTemplate

    {RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq}

    PolicyText

    Заявление, которое должно быть отображено в системе отправителя запроса вместе с RegTemplate

    Reason

    Заявление, связанное с запросом и отображаемое в системе отправителя запроса

    ReferralURLSeq

    {ReferralURL +}

    Опционные URL ссылок, перечисленные в порядке важности

    RegFormID

    Идентификатор, присвоенный СА

    BrandLogoURL

    URL базовой страницы расчетной системы

    CardLogoURL

    URL базовой страницы финансовой организации

    RegFieldSeq

    {RegField +}

    ReferralURL

    URL альтернативного СА для обработки запросов сертификатов для данного объекта

    RegField

    {[FieldId], FieldName, [FieldDesc], [FieldLen], FieldRequired, FieldInvisible}

    FieldID

    Идентификаторы объекта для полей регистрационной формы

    FieldName

    Одно или более имен полей, которые должны быть отображены в качестве меток для заполнения формы; текст записывается на языке, определенном в RegFormReq или Me-AqCInitReq

    FieldDesc

    Описание содержимого поля на языке, заданном в RegFormReq или Me-AqCInitReq; содержит дополнительную информацию для использования в случае, когда владелец карты запросит помощи при заполнении формы

    FieldLen

    Максимальная длина поля

    FieldRequired

    Булево значение, указывающее на необходимость ввода (должен ли поле заполнить владелец карты или оно будет заполнено приложением) (невидимое поле)

    FieldInvisible

    Булево значение, указывающее на то, что поле не должно отображаться пользователю; приложение должно заполнить FieldValue, основываясь на FieldID, или оставить его пустым

    Приложение владельца карты обрабатывает сообщение RegFormRes следующим образом:

    Шаг

    Действие

    1

    Получить RegFormRes из входного сообщения

    2

    Проверить подпись. Если подпись некорректна, отправить сообщение об ошибке с ErrorCode равным signatureFailure.

    3

    Получить RRPID, RequestType, LID-EE, Chall-EE2, CAEThumb из RegFormTBS

    4

    Проверить, что RRPID является тем же самым, что и идентификатор, записанный в цифровом конверте сообщения, и совпадет с кодом, присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным unknownRRPID.

    5

    Проверить, что RequestType, LID-EE и Chall-EE2 идентичны присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным challengeMismatch.

    6

    Если был включен CAEThumb, запомнить соответствующий сертификат шифрования, использованный для шифрования CertReq.

    7

    Проверить, что полученные оттиски, соответствуют посланным в сообщении CardCInitReq. Если соответствия нет, отправить сообщение об ошибке с ErrorCode равным thumbsMismatch.

    8

    Если в RegFormTBS включены данные RegFormData то:

    • Запоминается LID-CA
    • Прежде чем приложение SET сформирует CertReq, отображается текст общих требований и необходимый отклик пользователя
    • Отображаются видимые поля регистрационной формы и приглашение для заполнения их пользователем.
    • Если RegFormRes содержит URL, отображаются логотипы платежной системы или эмитента карты.
    • Заполняются видимые поля регистрационной формы. Если поле является необходимым, а приложение не может его заполнить, оно остается пустым, а остальная часть формы заполняется и посылается обычным порядком.
    • После того как пользователь завершил ввод, формируется сообщение CertReq.

    9

    Если в RegFormResTBS включено поле ReferralData то:

    • Отображается причина (Reason)
    • Если включено ReferralLoc, отображаются URL или электронный адрес из ReferralLoc
    • CertReq не формируется. Протокол переходит к формированию CardCInitReq

    Пары сообщений Me-AqCInitReq/Res используются продавцом или расчетным центром для получения регистрационной формы сертификата. Продавец или расчетный центр запускают сертификатный протокол путем посылки запроса Me-AqCInitReq. Это сообщение содержит банковскую информацию продавца или расчетного центра, тип запрашиваемого сертификата, а также сертификаты, CRL и BrandCRLIdentifier, которые хранятся в надежном сертификатном кэше. Если MCА или РСА имеют регистрационные формы на подходящем языке для указанного банка, она присылается в сообщении Me-AqCInitRes вместе с любыми сертификатами, CRL и BrandCRLIdentifier, которые могут потребоваться продавцу или расчетному центру для проверки цифровой подписи. Если MCА или РСА не имеют подходящей регистрационной формы и/или имеют дополнительную информацию относительно отклонения поступившего запроса, эти данные также заносятся в Me-AqCInitRes. Схема работы протокола сертификатов для данного случая показана на рис. 4.6.2.13.

    Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA

    При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:

    Шаг

    Действие

    1

    Сформировать новый RRPID

    2

    Сформировать новый LID-EE

    3

    Сформировать новый случайный код Chall-EE

    4

    Занести BrandID, который хранится в приложении или получен в стартовом сообщении

    5

    Заполнить поле RequestType

    6

    Заполнить поле Language (язык)

    7

    Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются)

    8

    Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID.

    9

    Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА.

    Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22.

    Таблица 4.6.2.22. Формат Me-AqCInitReq

    Me-AqCInitReq

    {RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]}

    RRPID

    ID пары запрос/отклик

    LID-EE

    Локальный ID; формируется ЕЕ-системой или для нее

    Chall-EE

    Обращение EE к СА по поводу пригодности подписи

    RequestType

    Смотри табл. 4.6.2.24

    IDData

    См. табл. 4.6.2.23

    BrandID

    BrandID запрошенного сертификата

    Langauage

    Желательный язык последующих текстов

    Thumbs

    Список оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ

    Формат поля IDData описан в таблице 4.6.2.23.

    Таблица 4.6.2.23. Формат IDData

    IDData

    <MerchantAcquirerID, AcquirerID> (только для продавца и получателя)

    MerchantAcquirerID

    {MerchantBIN, MerchantBIN}

    AcquirerID

    {AcquirerBIN, [AcquirerBusinessID]}

    MerchantBIN

    Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer)

    MerchantID

    Идентификатор продавца, присвоенный ему его банком (Acquirer)

    AcquirerBIN

    Идентификационный номер банка для Acquirer (BIN получателя)

    AcquirerBusinessID

    Рабочий идентификационный номер банка продавца

    Таблица 4.6.2.24. Значения RequestType для продавца и платежного центра

    Тип запроса

    Только сертификат подписи

    Только сертификат шифрования

    Оба
    сертификата

    Начальный для продавца

    4

    5

    6

    Начальный для расчетного центра

    7

    8

    9

    Обновление для продавца

    13

    14

    15

    Обновление для расчетного центра

    16

    17

    18

    Получив Me-AqCInitReq, СА производит его обработку следующим образом:

    Шаг

    Действие

    1

    Выделяеть Me-AqCInitReq из входного сообщения

    2

    Проверяеть, что RRPID из цифрового конверта сообщения совпадает с полученным в Me-AqCInitReq. Если это не так, формируется сообщение об ошибке с errorCode unknownRRPID.

    3

    Запоминается RRPID, LID-EE, Chall-EE, BrandID, Language, Thumbs и IDData

    Проверив корректность Me-AqCInitReq, CA формирует Me-AqCInitRes. Эта операция включает в себя следующие шаги:

    Шаг

    Действие

    1

    Сформировать сообщение Me-AqCInitResTBS:

    • Скопировать RRPID, LID-EE и Chall-EE из Me-AqCInitReq
    • Опционно сгенерировать LID-CA для данного вида запроса обслуживания
    • Сгенерировать новый Chall-CA
    • Если регистрационная форма продавца или платежного центра доступна для BIN, языка и RequestType, то:
    1. Заполнить поле RegFormData, используя RegTemplate и PolicyText, соответствующие Requesttype, BIN и Language
    1. Опционно включить URL для отображения логотипа платежной системы и/или карты
    2. Включить RegFormID и RegFieldSeq. При обновлении RegFieldSeq может быть опущено.
    1. Если СА посредством AcctData аутентифицирует продавца или расчетный центр, заполнить поле AcctDataField, указывая наименование данных, подлежащих вводу, описание, их длину и будут ли данные вводиться ЕЕ (конечным пользователем).
    • Если соответствующая форма для продавца или расчетного центра не доступна, заполняется поле ReferralData:
      1. Включить причину отказа обслуживания, которая будет отображена для продавца или расчетного центра
      2. Опционно включить в ReferralLoc электронный адрес и/или URL, где пользователь может получить дополнительную информацию, об отказе обслуживания.
    • Включить оттиск сертификата шифрования CA, CAEThumb.
    • Если BrandCRLIdentifier в полученном Me-AqCInitReq не специфицирован, ввести BrandCRLIdentifier.
    • Скопировать список оттисков (Thumbs) из Me-AqCInitReq
    • Скопировать RequestType, полученный в Me-AqCInitReq.

    2

    Подписать Me-AqCInitResTBS, установить тип содержимого SignedData равным id-set-content-Me-AqCInitResTBS.

    3

    Сформировать цифровой конверт и послать сообщение Me-AqCInitRes продавцу или расчетному центру.

    MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см. табл. 4.6.2.25)

    Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA

    Me-AqCInitRes

    S(CA, Me-AqCInitResTBS)

    Me-AqCInitResTBS

    {RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}

    RRPID

    ID пары запрос/отклик

    LID-EE

    Копируется из Me-AqCInitReq

    Chall-EE

    Копируется из Me-AqCInitReq

    LID-CA

    Локальный ID; генерируется СА системой или для нее

    Chall-CA

    СА обращение по поводу пригодности сертификата запрашивающей стороны

    RequestType

    Смотри табл. 4.6.2.24

    RegFormOrReferral

    Смотри табл. 4.6.2.21

    AcctDataField

    RegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq

    CAEThumb

    Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq

    BrandCRLIdentifier

    Смотри раздел описания BrandCRLIdentifier ниже.

    Thumbs

    Копируется из Me-AqCInitReq

    Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes следующим образом:

    Шаг

    Действие

    1

    Получить Me-AqCInitRes из входного сообщения.

    2

    Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.

    3

    Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType

    4

    Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.

    5

    Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.

    6

    Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.

    7

    Если в Me-AqCInitResTBS включено поле RegFormData то:

    • Запомнить LID-CA и Chall-CA
    • Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq
    • Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей
    • Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты
    • Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля
    • Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq.

    8

    После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.

    9

    Если в Me-AqCInitResTBS включено поле ReferrelData, то:

    • Отображается причина
    • Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc
    • CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq

    Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq.

    Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме.

    Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме.

    Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме.

    Запрос сертификата (CertReq) содержит в себе:

      • Новые общедоступные ключи.
      • Обновляемые сертификаты (если таковые есть).
      • Заполненную регистрационную форму.
      • Информацию об аккоунте ЕЕ
      • Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,
      • Другие контрольные коды

    Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа.

    Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq.

    ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo.

    Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.

    Шаг

    Действие

    1

    Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата

    2

    Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.

    3

    Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код - CardSecret.

    4

    Генерируется 160-битовый случайный код - EXNonce

    5

    Формируется CertReqTBS:

    • Генерируется RRPID
    • Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType.
    • Заполняется поле RequestData
    • Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый.
    • Генерируется новый Chall-EE3
    • Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения.
    • Если ЕЕ является продавец карты или расчетный центр, то:
    1. заполняется поле IDData и,
    2. если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ
    • Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret.
    • Сформировать EXNonce
    • Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes
    • Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.

    6

    • Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь.
    • Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА.
    • Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им.
    • Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.

    7

    Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0.
    Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.

    8

    Данные укладываются в конверт с использованием техники EncX:
    Включить:
    Обработка

    а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.
    Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS.
    Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату.
    Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи.
    Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName="Null-DN", т.е. RDNSequence равна кодированному NULL.
    Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS.
    b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию
    Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes
    c. CertReqTBEX в качестве данных, подлежащих шифрованию
    Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
     

    9

    Сформировать цифровой конверт и послать сообщение CertReq центру СА

    Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:

    Шаг

    Действие

    1

    Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи

    2

    Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования

    3

    Сгенерируется 160-битное случайное число - EXNonce

    4

    Данные CertReqData формируются следующим образом:

    • Генерируется RRPID
    • Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем.
    • Заполняется поле ReqestDate
    • Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое.
    • Генерируется новое Chall-EE3
    • Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется.
    • Заполнить поле IDData
    • Занести RegFormID, полученный из Me-AqCInitRes
    • Занести новую или скорректированную форму RegForm
    • Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА.
    • Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению.
    • Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты.

    5

    Поместить данные в цифровой конверт, используя инкапсуляцию Enc:
    Включить:
    Обработка

    • CertReqData в качестве информации, подлежащей подписыванию.

    То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.
    Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS.
    Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату.
    Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи.
    Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным "Null-DN". Тип содержимого SignedData делается равным id-set-content-CertReqData.
    Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE.

    • Ключ DES в качестве данных, подлежащих дополнительному шифрованию

    Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования "обычных данных". Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes.

    • CertReqTBE в качестве обычных данных, подлежащих шифрованию

    Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.

     

    6

    Подготовить цифровой конверт и послать CertReq центру СА

    Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26:

    Таблица 4.6.2.26. Формат CertReq

    CertReq

    <EncX(EE, CA, CertReqData, AcctInfo), Enc(EE, CA, CertReqData)>
    Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ:

    • секретный ключ нового сертификата подписи
    • существующий сертификат подписи для запроса сертификата шифрования или
    • существующий сертификат подписи для запроса обновления

    Эти подписи без соответствующего сертификата являются лишь проформой; они доказывают лишь то, что ЕЕ владеет секретным ключом.

    CertReqData

    {RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]}

    AcctInfo

    <PANData0, AcctData>
    Если отправитель запроса - владелец карты, вводится PANData0.
    Если отправитель запроса - продавец или получатель, вводится AcctData

    RRPID

    ID пары запрос/отклик

    LID-EE

    Копируется из RegFormRes или Me-AqCInitRes

    Chall-EE3

    Обращение ЕЕ по поводу обновления подписи СА

    LID-CA

    Копируется из RegFormRes или из Me-AqCInitRes

    Chall-CA

    Копируется из RegFormRes или из Me-AqCInitRes

    RequestType

    Смотри таблицу 4.6.2.24

    RequestDate

    Дата запроса сертификата

    IDData

    См. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты.

    RegFormID

    Идентификатор, присвоенный СА

    RegForm

    { RegFormItems +}
    Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ

    CABackKeyData

    {CAAIgId, CAKey}

    publicKeySorE

    {[ PublicKeyS], [PublicKeyE]}
    Общедоступный ключ объекта. Должен быть специфицирован, по крайней мере, один ключ. Пользователь может запросить сертификат подписи, сертификат шифрования или оба эти сертификата.

    EEThumb

    Оттиск сертификата ключа шифрования, который обновляется

    Thumbs

    Списки сертификатов, включая корневой, CRL и BrandCRLIdentifier, используемые в данный момент ЕЕ.

    PANData0

    См. табл. 4.6.2.27

    AcctData

    См. табл. 4.6.2.28

    RegFormItems

    {FieldName, FieldValue}

    CAAlgId

    Идентификатор симметричного алгоритма шифрования

    CAKey

    Секретный ключ, соответствующий идентификатору алгоритма

    PublicKeyS

    Предлагаемый для сертификации общедоступный ключ подписи

    PublicKeyE

    Предлагаемый для сертификации общедоступный ключ шифрования

    FieldName

    Одно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq

    FieldValue

    Величина, введенная ЕЕ

    Таблица 4.6.2.27. Формат PANData0

    PANData0

    {PAN, CardExpiry, CardSecret, EXNonce}

    PAN

    Первичный номер счета (Primary Account Number) для данной карты

    CardExpiry

    Дата пригодности карты

    CardSecret

    Предложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain.

    EXNonce

    Новый код (Nonce) для предотвращения атак на PANData0

    Таблица 4.6.2.28. Формат AcctData

    AcctData

    {AcctIdentification, EXNonce}

    AcctIdentification

    Для продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца)

    EXNonce

    Новый код Nonce для предотвращения атак на PANData0

    СА проверяет CertReq (EncX) следующим образом.

    Шаг

    Действие

    1

    Получить CertReq из входного сообщения

    • Если RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail.
    • Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq.
      1. Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail.
      2. Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure.
    • Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure.

    2

    Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования

    3

    Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID.

    4

    Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch.

    5

    Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer.

    6

    Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA.

    7

    Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA.

    8

    Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты.

    9

    Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer.

    10

    Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed.

    Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq.

    При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется.

    Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.

    Шаг

    Действие

    1

    CertResData формируется как:

    • Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReq
    • Генерируется или копируется из CertReq (если имеется) LID-CA
    • Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg)
    • CertStatusCode устанавливается равным "Request Complete"
    • Формируется Nonce-CCA
    • Вычисляются и заносятся оттиски EE-сертификатов, CertThumbs.
    • Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier.

    2

    Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке.

    • Подписать данные посредством сертификата подписи СА
    • Установить тип данных SignedData равным id-set-content-CertResData.
    • Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData.
    • Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq.
    • Установить тип содержимого EncriptedData равным id-set-content-CertResTBE

    3

    Сформировать цифровой конверт и послать EE CertRes.

    Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage. Подписанное сообщение CertRes формируется следующим образом:

    Шаг

    Действие

    1

    Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS.

    2

    Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от "Request Complete", создается CertResData:

    • Копируется LID-EE и Chall-EE3 из CertReq
    • Опционно заносится EEMessage
    • Из табл. 4.6.2.30 заносится значение CertStatusCode
    • Если CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме.

    3

    Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes

    Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29.

    Таблица 4.6.2.29. Формат CertRes

    CertRes

    <S(CA, CertResData), EncK(CABackKeyData, CA, CertResData)>
    EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData

    CertResData

    {RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]}

    CABackKeyData

    Копируется из CertReq

    RRPID

    ID пары запрос/отклик

    LID-EE

    Копируется из CertReq

    Chall-EE3

    Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти.

    LID-CA

    Копируется из CertReq. Если в CertReq его нет, то присваивается новое значение.

    CertStatus

    {CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]}

    CertThumbs

    Если запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования

    BrandCRLIdentifier

    Смотри раздел об идентификаторах списков отмененных сертификатов платежной системы.

    Thumbs

    Копируется из CertReq.

    CertStatusCode

    Нумерованный код, указывающий на статус запроса сертификата

    Nonce-CCA

    Присутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА.

    EEMessage

    Сообщение на естественном языке, предназначенное для отображения в системе ЕЕ

    CAMsg

    {[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]}

    FailedItemSeq

    {FailedItem+}

    CardLogoURL

    URL - указатель на логотип эмитента карты

    BrandLogoURL

    URL - указатель на логотип платежной системы

    CardCurrancy

    Вид валюта, хранящейся на счете владельца карты

    CardholderMsg

    Сообщение на естественном языке владельца карты, которое должно быть отображенопрограммой

    FailedItem

    {ItemNumber, ItemReason}

    ItemNumber

    Указывает на позицию в списке полей регистрационной формы, интерпретация которой невозможна. Значение нуль указывает на поле AcctData

    ItemReason

    Причина неудачи. Текстовое поле на естественном языке.

    Таблица 4.6.2.30. Статусные коды для запросов сертификата

    Код

    Значение

    Источник

    requestComplete

    Запрос сертификата одобрен

    CA

    invalidLanguage

    В запросе указан неверный язык

    CA

    invalidBIN

    Запрос сертификата отклонен из-за некорректного BIN

    Эмитент или получатель

    sigValidationFail

    Запрос сертификата отклонен по причине некорректной подписи

    CA

    decryptionError

    Запрос сертификата отклонен из-за ошибки дешифрования

    CA

    requestInProgress

    Запрос сертификата обрабатывается

    СА, эмитент или получатель

    rejectedByIssuer

    Запрос сертификата отклонен эмитентом карты

    Эмитент

    requestPended

    Запрос сертификата ждет обработки

    СА, эмитент или получатель

    rejectedByAquirer

    Запрос сертификата отклонен банком продавца (получателем)

    Получатель

    regFormAnswerMalformed

    Запрос сертификата отклонен из-за неверной позиции в регистрационной форме.

    CA

    rejectedByCA

    Запрос сертификата отклонен центром сертификации

    CA

    unableToEncryptCertRes

    Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты

    CA

    Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:

    Шаг

    Действие

    1

    Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier.

    2

    Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.

    3

    Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch.

    4

    Если CertStatusCode указывает "Certificate request complete" (с запросом сертификата все в порядке), то:

    • Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи.
    • Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.
    • В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency.
    • Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate.
    • В случае владельца карты выполняются следующие дополнительные действия:
      1. Для того чтобы получить PANSecret, вычисляется (Nonce-CCAÅ CardSecret)
      2. Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата.

    5

    Если CertStatusCode равен "MalFormed Registration Form Items", это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата.

    6

    Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq

    7

    Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage.

    Информационные сертификатные запросы и обработка статуса

    Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов).

    Если CertStatusCode из CertRes равен "Certificate Request in Progress" или "Certificate Request Pending". EE формирует CertInqReq для получения сертификата следующим образом:

    Шаг

    Действие

    1

    Копируется LID-CA3 из CertRes в поле данных "CertInqReqTBS"

    2

    Генерируется новый RRPID

    3

    Генерируется новый LID-EE

    4

    Генерируется новый Chall-EE3

    5

    Копируется LID-CA из предыдущего CertRes

    6

    Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq.

    7

    Формируется цифровой конверт и посылается CertInqReq в центр СА.

    Формат сообщения представлен в таблице ниже.

    Таблица 4.6.2.31. Формат CertInqReq

    CertInqReq

    S(EE, CertInqReqTBS)

    CertInqReqTBS

    {RRPID, LID-EE, Chall-EE3, LID-CA}

    RRPID

    Идентификатор пары запрос/отклик

    LID-EE

    Копируется из CertRes

    Chall-EE3

    Требование ЕЕ по поводу обновления подписи СА

    LID-CA

    Копируется из CertRes

    Центр СА обрабатывает CertInqReq следующим образом:

    Шаг

    Действие

    1

    Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX)

    2

    Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID.

    3

    Используя LID-CA в качестве индекса, определяется статус CertReq.

    4

    Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode

    После обработки CertInqReq СА формирует CertInqRes. Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично.

    Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32.

    Таблица 4.6.2.32. Поля формата сертификата Х.509

    Имя

    Ограничения на формат и значения

    Описание

    Version (Версия)

    Целое

    Указывает на версию сертификата

    SerialNumber

    Целое

    Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат

    Signature.AlgorithmIdentifier

    OID и тип

    Определяет алгоритм, используемый для генерации подписи сертификата

    Issuer (эмитент)

    Имя

    Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат

    Validity.notBefore

    Время UTC

    Специфицирует время, когда сертификат становится активным

    Validity.notAfter

    Время UTC

    Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты.

    Subject

    Имя

    Содержит уникальное имя объекта владельца ключа

    SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier

    OID и тип

    Специфицирует алгоритм, который может использоваться с этим ключом.

    SubjectPublicKeyInfo. subjectPublicKey

    Строка битов

    Содержит общедоступный ключ, представленный в запросе сертификата

    IssuerUniqueID

     

    В SET не используется

    SubjectUniqueID

     

    В SET не используется

    Extensions.extnId

    Формат OID

    Содержит расширение OID, как это определено Х.509 или SET

    Extensions.critical

    Булево: 0=ложно
    1=истинно

    Каждое описание расширения определяет то, какое значение должно принимать это поле

    Extensions.extnValue

     

    Информация расширения

    Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET:

    • countryName [2 5 4 6]
    • organizationName [2 5 4 10]
    • organizationUnitName [2 5 4 11]
    • commonName [2 5 4 3]

    Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType).

    OID имен (ASN.1)

    id-at-countryNameOBJECT IDENTIFIER ::= { id-at 6 }
    id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }
    id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }
    id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 }

    Владелец карты
    countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
    organizationName=<BrandID> (идентификатор платежной системы)
    organizationalUnitName=<Название финансового учреждения, выпустившее карту>
    organizationalUnitName=<Опционно - название карты>
    commonName=<Уникальный идентификатор владельца карты>
    Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту.

    Продавец
    countryName=< Страна, где размещается банк продавца - Acquirer>
    organizationName=<BrandID>
    organizationalUnitName=<Название банка продавца>
    commonName=<Имя продавца, как написано в заявлении владельца карты>
    Расчетный центр
    countryName=<Страна, где размещается банк продавца - Acquirer>
    organizationName=<BrandID>
    organizationalUnitName=<Название банка продавца>
    commonName=<Уникальный идентификатор расчетного центра>
    Центр сертификации владельца карты
    countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
    organizationName=<BrandID>
    organizationalUnitName=<Описательное имя>
    commonName=<Опционный уникальный идентификатор>
    Центр сертификации продавца
    countryName=<Страна, где размещается банк продавца - Acquirer >
    organizationName=<BrandID>
    organizationalUnitName=<Описательное имя>
    commonName=<Опционный уникальный идентификатор>
    Центр сертификации расчетного центра
    countryName=<Страна, где размещается банк продавца - Acquirer >
    organizationName=<BrandID>
    organizationalUnitName=<Описательное имя>
    commonName=<Опционный уникальный идентификатор>
    Геополитический центр сертификации
    countryName=<Страна геополитической организации>
    organizationName=<BrandID>
    organizationalUnitName=<Описательное имя>
    commonName=<Опционный уникальный идентификатор>
    Центр сертификации платежной системы (Brand)
    countryName=<Страна, где размещен центр сертификации платежной системы>
    organizationName=<BrandID>
    organizationalUnitName=<Описательное имя>

    commonName=<Опционный уникальный идентификатор>
    Корневой центр сертификации
    countryName=<Страна, где размещен корневой центр сертификации - СА>
    organizationName=<Корневой центр SET>
    commonName=<Опционный - уникальный ID>
    Поля имен в имени субъекта сертификата определены в таблице ниже:

    Country

    2 символа кода страны (ISO 3166)

    BrandID

    <Brand Name>:<Product>, где название продукта является опционным.

    Brand Name

    Платежная система карты, которая определяется разработчиками платежной системы.

    Product Type

    Опционное поле, которое определяет тип продукта в рамках заданной платежной системы.

    Описательное имя

    Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например:

    • Название финансовой организации
    • Название организации, выполняющей функцию СА
    • Название платежной системы
    • Имя объекта, ответственного за одобрение сертификатов

    Официальное название карты

    Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д.

    Название финансовой организации

    Имя финансовой организации, выпускающей расчетные карты

    Уникальный идентификатор владельца карты

    Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета.

    Уникальный идентификатор расчетного центра

    Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN.

    Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета. PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом:

    Hash(KÅ opad|hash((KÅipad)|text)),

    где Å - оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:

    K

    Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA.

    Text

    Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry.

    Text ::= SEQUENCE {

    pan              PAN
    cardExpiry CardExpiry
    }
    PAN ::= NumberString (SIZE(1..19))
    CardExpiry ::= NumericString (SIZE(6)) --YYYMM
    Время истечения действия карты

    ipad

    64 байта, содержащих код 0x36

    opad

    64 байта, содержащих код 0x5C

    K дополняется нулями до 64 байт.

    Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName.

    Профайлы сертификатов

    В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET.

    Таблица 4.6.2.33. Типы сертификатов

    Объект

    Цифровая подпись

    Шифрование_ключей/
    шифрование_данных

    Подпись

    keyCert

    Подпись

    CRL

    Владелец карты

    Х

         

    Продавец

    Х

    Х

       

    Расчетный центр

    Х

    Х

       

    Центр сертификации владельца карты

    Х

    Х

    Х

     

    Центр сертификации продавца

    Х

    Х

    Х

     

    Центр сертификации расчетного центра

    Х

    Х

    Х

    Х

    Геополитический центр сертификации

    Х

     

    Х

    Х

    Центр сертификации платежной системы

       

    Х

    Х

    Корневой центр сертификации

       

    Х

    Х

    ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата.

    Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать:

    • привилегии keyCertSign и offLineCRLSign или
    • keyEncipherment и dataEncipherment

    В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ).

    Таблица 4.6.2.34. Обязательные расширения сертификата ЕЕ.

     

    Сертификат владельца карты

    Сертификат продавца

    Сертификат расчетного центра

    Расширение Х.509

    Подпись

    Подпись

    Шифрова-ние ключа

    Подпись

    Шифрова-ние ключа

    AuthorityKeyIdentifier

    Х

    Х

    Х

    Х

    Х

    KeyUsage

    Х

    Х

    Х

    Х

    Х

    PrivateKeyUsagePeriod

    Х

    Х

     

    Х

     

    CertificatePolicies

    Х

    Х

    Х

    Х

    Х

    SubjectAltName

    O

    O

    O

    O

    O

    BasicConstraints

    Х

    Х

    Х

    Х

    Х

    IssuerAltName

    O

    O

    O

    O

    O

    Частное расширение

    HashedRootKey

             

    CertificateType

    Х

    Х

    Х

    Х

    Х

    MerchantData

     

    Х

    Х

       

    CardCertRequired

           

    Х

    Tunneling

           

    Х

    SETExtensions

           

    Х

    Х - обязательный
    O - опционный

    Таблица 4.6.2.35. Обязательные расширения сертификатов СА

     

    СА

    Корневой центр сертификации

    Расширение Х.509

    Цифровая
    подпись

    Подпись
    серти-фиката

    Шифрова-ние ключа

    Подпись
    CRL

    Подпись сертификата & CRL

    AuthorityKeyIdentifier

    Х

    Х

    Х

    Х

    Х

    KeyUsage

    Х

    Х

    Х

    Х

    Х

    PrivateKeyUsagePeriod

    Х

    Х

     

    Х

     

    CertificatePolicies

    Х

    Х

    Х

    Х

    Х

    SubjectAltName

    O

    O

    O

    O

    O

    BasicConstraints

    Х

    Х

    Х

    Х

    Х

    IssuerAltName

    O

    O

    O

    O

    O

    Частное расширение

    HashedRootKey

           

    Х

    CertificateType

    Х

    Х

    Х

    Х

    Х

    MerchantData

             

    CardCertRequired

             

    Tunneling

       

    Х

       

    SETExtensions

             

    Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:

    • Номер CRL. Номера монотонно возрастают.
    • Список серийных номеров устаревших сертификатов.
    • Даты, когда конкретные сертификаты были признаны устаревшими.
    • Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).
    • Уникальное имя СА, который поддерживает данный CRL.
    • Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL.

    В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509).

    Таблица 4.6.2.36. Формат полей CRL и ограничения для их значений

    Имя поля

    Формат и ограничения на значение

    Описание

    CRL.version (версия)

    Целое; V2

    Определяет версию CRL. В настоящее время =2.

    CRL.signature
    .algorithmIdentifier

    OID и тип

    Определяет алгоритм, использованный для подписи CRL

    CRL.Issuer

    Имя

    Содержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА

    CRL.thisUpdate

    Время UTC

    Определяет время, когда был сформирован CRL

    CRL.nextUpdate

    Время UTC

    Определяет время, когда CRL устареет

    CRL.revokedCertificate
    .certSerialNumber

    Целое

    Номер по порядку устаревшего сертификата

    CRL. RevokedCertificate
    .revocationDate

    Время UTC

    Дата признания сертификата устаревшим

    CRL. RevokedCertificate
    .extensions

    Расширения

    Не используется в SET

    CRL.extensions

    Расширения

    В этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier

    Следующие СA должны поддерживать CRL в рамках SET:

    • корневой СА - для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.
    • СА платежных систем - для поддержки незапланированной замены или прекращения действия сертификата, выданного центром сертификации платежной системы.
    • геополитические СА - для поддержки незапланированной замены сертификатов CCA, MCA или PCA.
    • CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра.

    Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL.

    При получении нового CRL должны проводиться следующие проверки:

    1. Сначала проверяется подпись:

      • Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.
      • Расширение KeyUsage в сертификате подписи указывает на CRLsign(6)
    2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.
    3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом

    Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:

        1. IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRL
        2. certSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL.

    Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber.

    BrandCRLIdentifier

    BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы. BrandCRLIdentifier содержит в себе следующую информацию:

    • Номер BCI (увеличивается для каждого нового BCI)
    • Название платежной системы
    • Время пригодности BCI
    • Список номеров CRL (из расширения номера CRL)
    • Эмитент и серийный номер сертификата СА платежной системы, который используется для подписи BCI (включается в расширение)

    Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов.

    Запросы и отклики сертификатов

    Запрос сертификата посылается клиентом вышестоящему центру сертификации (СА). Последний формирует сертификат и отсылает его отправителю запроса в подписанном сообщении отклике. Различные объекты ответственны за подпись разных сертификатов, как это показано ниже.

    Сертификат для:

    Формируется и подписывается:

    СА платежной системы

    Корневой СА

    Геополитический СА

    СА платежной системы

    ССА, МСА или РСА

    Геополитический СА, если таковой имеется, в противном случае СА платежной системы

    Сообщения запросы от СA форматируются согласно CertificationRequest, специфицированному в PKCS#4 версии 1.0. CertificationRequest содержит общедоступный ключ, DN субъекта и атрибуты, которые должен сертифицировать подписывающий СА.

    Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest.

    Таблица 4.6.2.37. Атрибуты CertificationRequest

     

    ССА, МСА или РСА

    Геополитический центр сертификации или СА платежной системы

    Атрибут SET

    Цифровая подпись

    Сертификат подписи

    Шифрова-ние ключа

    Подпись CRL

    Сертификат и подпись CRL

    KeyUsage

    X

    X

    X

    X

    X

    PrivateKeyUsagePeriod

    X

    X

     

    X

    X

    AdditionalPolicy

    O

    O

    O

    O

    O

    SubjectAltName

    O

    O

    O

    O

    O

    CertificateType

    X

    X

    X

    X

    X

    Tunneling

       

    X

       

    Х - обязательный
    O - опционный

    При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:

    Шаг

    Действие

    1

    Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest

    2

    Используя общедоступный ключ, присланный в запросе, проверить подпись

    3

    Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name

    4

    Используя тип сертификата и атрибуты использования ключа, проверить, что имеются необходимые атрибуты (см. таблицу 4.6.2.37)

    5

    Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА.

    6

    Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован.

    7

    Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData.

    8

    SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET.

    Рассылка CRL

    CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.

    Шаг

    Действие

    1

    Сформировать CRLNotificationTBS:

    • Занести в поле данные текущую дату
    • Занести в CRLThumbprint оттиск, несущий в себе CRL

    2

    Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS

    3

    Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения.

    4

    Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME.

    CRL-Notification-сообщение содержит следующие поля:

    Название поля

    Описание

    CRL-Notification

    S(CA, CRLNotificationTBS)

    CRL-NotificationTBS

    {Date, CRLThumbprint}

    Дата

    Дата, когда сформировано сообщение

    CRLThumbprint

    Оттиск CRL, заключенный в CRL-секцию SignedData

    При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:

    Шаг

    Действие

    1

    Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate.

    2

    Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch.

    3

    Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI.

    CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:

    Шаг

    Действие

    1

    Заполнить NotificationResTBS:

    • Вставить дату из сообщения CRLNotification
    • Вставить оттиск полученного CRL

    2

    Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-CRLNotificationResTBS

    3

    Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА.

    Сообщение-отклик CRLNotification содержит следующие поля.

    Название поля

    Описание

    CRL-NotificationRes

    S(CA, CRLNotificationTBS)

    CRL-NotificationResTBS

    {Date, CRLThumbprint}

    Дата

    Копируется из сообщения CRLNotification

    CRLThumbprint

    Оттиск CRL, копируется из сообщения CRLNotification

    При получении отклика CRLNotification СА проверяет то, что дата и оттиск соответствуют значениям из запроса. Если соответствия нет, посылается сообщение об ошибке, а запрос CRLNotification посылается повторно.

    Получение BCI

    BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА.

    Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных.

    Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.

    Шаг

    Действие

    1

    Заполнить BCIDistributionTBS:

    • Ввести текущую дату
    • Включить последнюю версию BCI

    2

    Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL.

    3

    Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом.

    Сообщение BCI Distribution содержит в себе следующие поля:

    Название поля

    Описание

    BCIDistribution

    S(CA, BCIDistributionTBS)

    BCIDistributionResTBS

    {Date, BCIDistribution}

    Дата

    Дата формирования сообщения

    BrandCRLIdentifier

    Список текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы.

    Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:

    Шаг

    Действие

    1

    Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы.

    2

    Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить.

    3

    Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается.

    4

    Запомнить все CRL и BrandCRLIdentifier для последующей рассылки

    Структуры данных

    Сообщения SET включают в себя несколько структур данных, которые содержат информационные элементы, переносимые из одного сообщения в другое. Информационные поля сообщения с протокольной точки зрения непрозрачны.

    TransID

    TransID предоставляет всю информацию для уникально определенной транзакции и характеристики транзакции, частью которой является данное сообщение. В частности TransID позволяет участнику процесса связать каждое сообщение с определенной транзакцией. Структура данных в TransID представлена ниже в таблице.

    TransID

    {LID-C, [LID-M], XID, PReqData, [PaySysID], Language}

    LID-C

    Локальный ID. Метка, генерируемая системой владельца карты или для нее.

    LID-M

    Локальный ID. Метка, генерируемая системой продавца или для нее.

    XID

    Глобально уникальный идентификатор

    PReqData

    Дата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq.

    PaySysID

    Используется некоторыми платежными системами для пометки транзакций

    Language

    Естественный язык владельца карты

    TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты. XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET.

    Таблица 4.6.2.38. Условия формирования и использование поля TransID

    Сообщение

    LID-C

    LID-M

    XID

    PaySysID

    PInitReq

    R

    C1

    N/P

    N/P

    PInitRes

    ß

    ß (C2)

    R

    N/P

    PReq

    ß

    ß

    ß (R3)

    N/P

    PRes

    ß

    ß (C2)

    ß

    C4

    InqReq

    ß

    ß

    ß

    C5

    InqRes

    ß

    ß

    ß

    C4

    AuthReq

    ß

    ß

    ß

    N/P

    AuthRes

    ß

    ß

    ß

    C6

    AuthRevReq

    ß

    ß

    ß

    C

    AuthRevRes

    ß

    ß

    ß

    ß

    CapReq

    I

    I

    I

    I

    CapRes

    I

    I

    I

    I

    CapRevReq

    I

    I

    I

    I

    CapRevRes

    I

    I

    I

    I

    CredReq

    I

    I

    I

    I

    CredRes

    I

    I

    I

    I

    CredRevReq

    I

    I

    I

    I

    CredRevRes

    I

    I

    I

    I

    PCertReq

    N/P

    C

    N/P

    N/P

    PCertRes

    N/P

    ß

    N/P

    N/P

    BatchAdminReq

    I

    I

    I

    I

    BatchAdminRes

    I

    I

    I

    I

    CardCInitReq

    R

    N/P

    N/P

    N/P

    CardCInitRes

    ß

    N/P

    N/P

    N/P

    Me-AdCInitReq

    N/P

    C

    N/P

    N/P

    Me-AdCInitRes

    N/P

    ß

    N/P

    N/P

    RegFormReq

    ß

    ß

    N/P

    N/P

    RegFormRes

    ß

    ß

    N/P

    N/P

    CertReq

    ß

    ß

    N/P

    N/P

    CertRes

    ß

    ß

    N/P

    N/P

    CertInqReq

    ß

    ß

    N/P

    N/P

    CertInqRes

    ß

    ß

    N/P

    N/P

    R

    Поле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт.

    C

    Наличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения.

    N/P

    (Not Present) Отсутствует как в сообщении так и в цифровом конверте.

    ß

    Копируется из запроса или предыдущего сообщения, дублируется в цифровом конверте

    I

    Может присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте.

    Примечания:

          1. Копируется из процесса инициализации SET (если имеется)
          2. Если для данной транзакции нет предшествующего LID-M, продавец может сформировать его для данного сообщения.
          3. Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.
          4. Если послано после получения AuthRes с PaySysID
          5. Если послано после получения PRes с PaySysID
          6. Может быть сформировано расчетным центром для данного сообщения.

    Алгоритм формирования TransID представлен ниже:

    Шаг

    Действие

    1

    Если сообщение для данной транзакции получено раньше, следует запомнить все его поля.

    2

    Если это новая транзакция, сформировать все необходимые поля (см таблицу выше)

    3

    Заполнить любые опционные поля, которые могут быть сформированы данным объектом.

    Обработка TransID зависит от типа сообщения.

    Платежная инструкция

    Платежная инструкция (PI) является одной из важнейших информационных структур SET. Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца - Acquirer). Эта информация не может быть прочитана продавцом.

    Имеется три разновидности PI. Первые два формируются владельцем карты, третье - расчетным центром.

    PIUnsigned

    Формируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned.

    Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится.

    PIDualSigned

    Формируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных.

    AuthToken

    Формируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq.
    Этот вариант используется для поддержки доставки по частям и передается назад из расчетного центра после первичной авторизации с тем, чтобы использоваться для запросов последующих авторизаций.

    Платежная инструкция имеет структуру представленную в таблице 4.6.2.39.

    Таблица 4.6.2.39. Структура PI

    PI

    <PIUnsigned, PIDualSigned, AuthToken>
    Владелец карты создает PIUnsigned или PIDualSigned инструкцию.
    Расчетный центр формирует AuthToken для поддержки поставки по частям и последовательных платежей. Продавец запишет PI для последующего вложения в AuthReq.

    PIUnsigned

    EXH(P, PI-OILink, PANToken)} (См. табл. 4.6.2.46)

    PIDualSigned

    {PISignature, EX(P, PI-OILink, PANData)} (См. табл. 4.6.2.45)

    AuthToken

    См. табл. 4.6.2.42

    PI-OILink

    L(PIHead, OIData) (см. табл. 4.6.2.40)

    PISignature

    SO(C, PI-TBS)

    PI-TBS

    {HPIData, HOIData}

    HPIData

    DD(PIData)

    HOIData

    DD(OIData)

    PIData

    {PIHead, PANData} (см. табл. 4.6.2.40 и 4.6.2.45)

    Таблица 4.6.2.40. Структура PIHead

    PIHead

    {TransIDs, Inputs, MerchantID, [InstallRecurData], TransStain, SWIdent, [AcqBackKeyData], [PIExtensions]}

    TransIDs

    См. выше описание TransIDs

    Inputs

    {HOD, PurchAmt}

    MerchantID

    Копируется из сертификата подписи продавца

    InstallRecurData

    См. табл. 4.6.2.41

    TransStain

    HMAC(XID, CardSecret)

    SWIdent

    Строка, идентифицирующая программное обеспечение (разработчик и версия), инициирующее запрос. Оно специфицируется в PI, чтобы расчетный центр знал программное обеспечение владельца карты.

    AcqBackKeyData

    {AcqBackAlg, AcqBackKey}

    PIExtensions

    Данные из расширения платежных инструкций должны быть финансовыми и важными для обработки авторизации расчетного центра, эмитента или финансовой сети

    Прикладные данные в этом сообщении состоят из PIData, от которых PANData отличается более сильной криптографической обработкой. PANData - это информация платежной карты. PIData включает в себя все прочие данные о покупке, идентификацию транзакции и переменные криптографической поддержки.

    Таблица 4.6.2.41. Структура InstallRecurData

    InstallRecurData

    {InstallRecurDInd, [IRExtensions]}

    InstallRecurDInd

    < InstallTotalTrans, Recurring >

    IRExtensions

    Данные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра

    InstallTotalTrans

    Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей

    Recurring

    {RecurringFrequency, RecurringExpiry}

    RecurringFrequency

    Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями)

    RecurringExpiry

    Окончательная дата, после которой никакие авторизации не разрешены

    Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту.

    AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42.

    Таблица 4.6.2.42. Структура AuthToken

    AuthTokenData

    {TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque}

    PANToken

    Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40)

    TransIDs

    PurchAmt

    MerchantID

    AcqBackKeyData

    InstallRecurData

    RecurringCount

    Число реализованных рекуррентных авторизаций

    PrevAuthDateTime

    Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций

    TotalAuthAmount

    Полное число авторизованных в результате всех авторизаций для данного XID

    AuthTokenOpaque

    Невидимые данные, генерируемые расчетным центром

    AuthToken формируется следующим образом:

    Шаг

    Действие

    1

    Генерируется AuthTokenTBE как:
    Если это первая авторизация (выполнена согласно PI)

    а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData
    б. RecurringCount делается равным 1
    в. В PrevAuthDateTime записывается текущая дата
    г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthToken

    Если это очередная аутентификация (сгенерирована из предыдущего AuthToken)

    а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData
    б. Инкрементируется на 1 RecurringCount
    в. В PrevAuthDateTime записывается текущая дата
    г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthToken

    Если это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken)

    а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData
    б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1
    в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken.

    2

    Сформировать PANToken (см. табл. 4.6.2.46)

    3

    С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p.

    Обработка AuthToken выполняется в следующем порядке:

    Шаг

    Действие

    1

    Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра.

    2

    Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed

    3

    Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch.

    4

    Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией:

        1. Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired.
        2. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon.

    5

    Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты.

    6

    Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу.

    AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43.

    Таблица 4.6.2.43. Структура AcqCardMsg

    AcqCardMsg

    EncK(AcqBackKeyData, P, AcqCardCodeMsg)
    AcqBackKeyData
    предоставляется владельцем карты в PI.
    Зашифрованное сообщение адресуется владельцу карты.

    AcqBackKeyData

    Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40)

    AcqCardCodeMsg

    {AcqCardCode, AcqCardMsgData}

    AcqCardCode

    Числовой код

    AcqCardMsgData

    {[AcqCardText], [AcqCardURL], [AcqCardPhone]}

    AcqCardText

    Текстовое сообщение, отображаемое владельцу карты

    AcqCardURL

    URL HTML-сообщения, отображаемого владельцу карты

    AcqCardPhone

    Телефонный номер, предоставляемый владельцу карты

    Для AcqCardCode определены следующие значения:

    messageOfDay

    Банк продавца хочет, чтобы это сообщение было передано всем

    accountInfo

    Информация о счете должна быть передана назад пользователю

    сallCustomerService

    Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов

    CapToken предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44.

    Таблица 4.6.2.44. Структура CapToken

    CapToken

    <Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}>
    P1
    и P2 обозначают платежные центры:

    • P1 - отправителя
    • P2 - получателя

    В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2)

    CapTokenData

    {AuthRRPID, AuthAmt, TokenOpaque}

    PANToken

    Смотри табл. 4.6.2.46

    AuthRRPID

    RRPID, который появляется в соответствующем AuthReq или AuthRevReq

    AuthAmt

    Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты

    TokenOpaque

    Невидимые данные, определенные расчетным центром

    Алгоритм формирования CapToken показан ниже:

    Шаг

    Действие

    1

    Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes

    2

    Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов

    3

    Если продавец получает PANToken из своего банка, тогда:

    • Занести PANToken из PI
    • Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секции

    В противном случае:

    • Использовать Enc инкапсуляцию с CapTokenData

    Обработка CapToken производится следующим образом:

    Шаг

    Действие

    1

    Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc.

    2

    Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest.

    3

    Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound

    4

    Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest.

    5

    Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса.

    PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45.

    Таблица 4.6.2.45. Структура PANData

    PANData

    {PAN, CardExpiry, PANSecret, EXNonce}

    PAN

    Первичный номер счета, обычно номер счета карты

    CardExpiry

    Дата действительности карты

    PANSecrit

    Секретный код, используемый совместно владельцем карты, расчетным центром и сертификационным центром владельца карты. Предотвращает атаки на PAN в сертификате владельца карты.

    EXNonce

    Новый код (Nonce), который препятствует атаке на PANData

    Формирование PANData осуществляется согласно алгоритму, рассмотренному ниже.

    Шаг

    Действие

    1

    Занести в PAN номер счета владельца карты

    2

    Записать в CardExpiry дату действительности карты

    3

    Занести PANSecret, который был получен от СА вместе с сертификатом владельца карты. Для владельца карты без сертификата все октеты этого поля устанавливаются равными нулю.

    4

    Сформировать новое значение EXNonce

    PANToken подобно PANData содержит информацию, идентифицирующую определенную платежную карту. PANToken используется, когда для сокрытия данных PANSecret не нужен. Структура PANToken показана в таблице 4.6.2.46.

    Таблица 4.6.2.46. Структура PANToken

    PANToken

    {PAN, CardExpiry, EXNonce}

    PAN

    Первичный номер счета, обычно номер счета карты

    CardExpiry

    Дата действительности карты

    EXNonce

    Новый код (Nonce), который препятствует атаке на PANData

    Формирование PANToken осуществляется достаточно просто:

    Шаг

    Действие

    1

    Занести в PAN номер счета владельца карты

    2

    Записать в CardExpiry дату действительности карты

    3

    Сформировать новое значение EXNonce.

    Структура SaleDetail

    SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47.

    Таблица 4.6.2.47. Структура SaleDetail

    SaleDetail

    {[BatchID],[BatchSequenceNum], [PayRecurInd], [MerOrderNum], [AuthCharInd], [MarketSpecSaleData], [CommercialCardData], [OrderSummery], [CustomerReferenceNumber], [CustomerServicePhone], OktoPrintPhoneInd, [SaleExtensions]}
    Это поле может появляться в AuthReq с флагом CaptureNow установленным равным TRUE или в сообщениях, связанных с платежным запросом.

    BatchID

    Идентификация последовательности операций в системе продавец и его банк

    BatchSequenceNum

    Порядковый номер позиции в данной последовательности расчетных операций.

    PayRecurInd

    Номер типа транзакции

    MerOrderNum

    Номер заказа продавца

    AuthCharInd

    Копируется из AuthResPayload

    MarketSpecSaleData

    {[MarketSpecDataID], [MarketSpecCapData]}

    CommercialCardData

    Описание позиции в платежном запросе (см. табл. 4.6.2.48)

    OrderSummary

    Краткое описание заказа

    CustomerReferenceNumber

    Номер ссылки, присвоенный заказу владельца карты

    CustomerServicePhone

    Номер телефона службы обслуживания клиентов данного продавца

    OKtoPrintPhoneInd

    Булево число, указывающее, может ли эмитент выдавать телефон службы сервиса в ответ на запрос владельца карты.

    SaleExtensions

    Данные этого расширения должны быть финансовыми и важными для обработки платежного запроса расчетного центра или эмитента

    MarketSpecDataID

    Копируется из AuthResPayload

    MarketSpecCapData

    <MarketAutoCap, MarketHotelCap, MarketTransportCap>

    MarketAutoCap

    Описание оплаты проката автомобиля (см. табл. 4.6.2.49)

    MarketHotelCap

    Описание оплаты гостиницы (см. табл. 4.6.2.50)

    MarketTransportCap

    Данные о пассажире (см. табл. 4.6.2.51)

    PayRecurInd может принимать следующие значения:

    unknown

    Тип транзакции неизвестен

    singleTransaction

    Транзакция состоит из одной авторизации и платежного запроса

    recurringTransaction

    Транзакция состоит из нескольких авторизаций и платежных запросов, которые повторяются регулярно

    installmentPayment

    Транзакция состоит из нескольких авторизаций и заказов-резервирований, которые выполняются фиксированное число раз

    otherMailOrder

    Прочие транзакции заказов по почте

    Структура коммерческих данных карты представлена в таблице 4.6.2.48.

    Таблица 4.6.2.48. Структура коммерческих данных карты

    CommercialCardData

    {[ChargeInfo], [MerchantLocation], [ShipFrom], [ShipTo], [ItemSeq]}

    ChargeInfo

    {[TotalFreightShippingAmount], [TotalDutyTariffAmount], [DutyTariffReference], [TotalNationalTaxAmount], [TotalLocalTaxAmount], [TotalOtherTaxAmount], [TotalTaxAmount], [MerchantTaxID], [MerchantDutyTariffRef], [CustomerDutyTariffRef], [SummaryCommodityCode], [MerchantType]}

    MerchantLocation

    Местоположение продавца

    ShipFrom

    Адрес отправки

    ShipTo

    Адрес получателя

    ItemSeq

    {Item +}
    Номера от 1 до 999

    TotalFreightShippingAmount

    Общее количество позиций, подлежащих обработке и доставке

    TotalDutyTariffAmount

    Полная сумма налога или тариф для заказа

    DutyTariffReference

    Код ссылки, приписанный налогу или тарифу для данного заказа

    TotalNationalTaxAmount

    Полная величина национального налога (с продаж или на добавленную стоимость), распространяющегося на данный заказ

    TotalLocalTaxAmount

    Размер местного налога, распространяющегося на данный заказ

    TotalOtherTaxAmount

    Прочие налоги, действующие для данного заказа

    TotalTaxAmount

    Полный размер налога для данного заказа

    MerchantTaxID

    Индивидуальный идентификационный номер продавца

    MerchantDutyTariffRef

    Код налога или тарифа, приписанный продавцу

    CustomerDutyTariffRef

    Код налога или тарифа, приписанный владельцу карты

    SummaryCommodityCode

    Код товара, приложимый ко всему заказу

    MerchantType

    Тип продавца

    Item

    {Quantity, [UnitOfMeasureCode], Descriptor, [CommodityCode], [ProductCode], [UnitCost], [NetCost], DiscountInd, [DiscountInd], [NationalTaxAmount], [NationalTaxAmount], [NationalTaxRate], [NationalTaxType], [LocalTaxAmount], [LocalTaxAmount], ItemTotalCost}

    Quantity

    Количество предметов или услуг данного типа

    UnitOfMeasureCode

    Единицы измерения для данной позиции в заказе

    Descriptor

    Описание позиции в заказе

    CommodityCode

    Код вида товара для данной позиции заказа

    ProductCode

    Код продукта для данной позиции заказа

    UnitCost

    Цена единицы товара

    NetCost

    Чистая цена единицы товара

    DiscountInd

    Указывает, распространяется ли скидка на данную позицию в заказе

    DiscountAmount

    Величина скидки для данной позиции заказа

    NationalTaxAmount

    Величина национального налога, применимого к данной позиции заказа

    NationalTaxRate

    Национальный налог (с продаж или на добавленную стоимость), применимый к данной позиции заказа

    NationalTaxType

    Ставка национального налога, действующая для данной позиции заказа

    LocalTaxAmount

    Величина местного налога, действующая для данной позиции заказа

    OtherTaxAmount

    Величина прочих налогов

    ItemTotalCost

    Полная цена данной строки заказа

    Структура данных MarketAutoCap представлена в таблице 4.6.2.49.

    Таблица 4.6.2.49. Структура MarketAutoCap

    MarketAutoCap

    {[RenterName], [RentalLocation], RentalDateTime, [AutoNoShow], [RentalAgreementNumber], [ReferenceNumber], [InsuranceType], [InsuranceType], [ReturnLocation], ReturnDateTime, AutoCharges}

    RenterName

    Имя лица, сдающего авто в аренду

    RentalLocation

    Адрес фирмы сдающей авто в аренду

    RentalDateTime

    Дата (опционно время), когда авто было взято в аренду

    AutoNoShow

    Числовой код, указывающий, что клиент не предъявил во время арендованную машину

    RentalAgreementNumber

    Номер арендного соглашения

    ReferenceNumber

    Код аренды

    InsuranceType

    Тип страховки, выбранный арендатором

    AutoRateInfo

    {AutoApplicableRate, [LateReturnHourlyRate], [LateReturnHourlyRate], [FreeDistance], [VehicleClassCode], [CirporateID]}

    ReturnLocation

    Адрес фирмы, куда следует вернуть авто (см. табл. 4.6.2.51)

    ReturnDateTime

    Дата (опционно время) возвращения автомобиля

    AutoCharges

    {RegularDistanceCharges, [LateReturnCharges], [TotalDistance], [ExtraDistanceCharges], [InsuranceCharges], [FuelCharges], [AutoTowingCharges], [OneWayDropOffCharges], [TelephoneCharges], [ViolationsCharges], [DelivaryCharges], [ParkingCharges], [OtherCharges], [TotalTaxAmount], [AuditAdjustment]}

    AutoApplicableRate

    <DailyRentalRate, WeeklyRentalRate>

    LateReturnHourlyRate

    Почасовая плата за опоздание возврата

    DistanceRate

    Помильная оплата за превышение допустимого пробега

    FreeDistance

    Расстояние, которое может пройти машина в день, без увеличения арендной платы.

    VehicleClassCode

    Класс арендуемого автомобиля

    CorporateID

    Корпоративный идентификационный номер, который применяется для определения арендной платы

    RegularDistanceCharges

    Сумма расходов за аренду (исключая расходы, перечисленные ниже)

    LateReturnCharges

    Сумма выплаты за возвращения автомобиля после оговоренного срока.

    TotalDistance

    Полный пробег автомобиля.

    ExtraDistanceCharges

    Сумма оплаты избыточного пробега (сверх оговоренного в договоре)

    InsuranceCharges

    Сумма страховки

    FuelCharges

    Оплата горючего

    AutoTowingCharges

    Оплата буксировки

    OneWayDropOffCharges

    Оплата одностороннего разрыва арендного договора

    TelephoneCharges

    Расходы использования телефона в арендованной машине

    ViolationsCharges

    Сумма штрафов за нарушения за время аренды автомобиля

    DelivaryCharges

    Оплата доставки арендованного автомобиля

    ParkingCharges

    Оплата парковки арендованного автомобиля

    OtherCharges

    Оплата расходов, не определенных в других позициях

    TotalTaxAmount

    Сумма налогов, связанная с арендой автомобиля

    AuditAdjustment

    Сумма изменения объема транзакции в результате аудита в компании, предоставляющей автомобили в аренду.

    DailyRentalRate

    Дневная арендная плата

    WeeklyRentalRate

    Арендная плата за неделю

    Структура данных MarketHotelCap представлена в таблице 4.6.2.50.

    Таблица 4.6.2.50. Структура MarketHotelCap

    MarketHotelCap

    {[ArriveDate], [RentalLocation], DepartureDate, [DurationOfStay], [FolioNumber], [PropertyPhone], [CustomerServicePhone], [ProgramCode], [HotelRateInfo], HotelCharges}

    ArriveDate

    Дата регистрации владельца карты в отеле

    HotelNoShow

    Цифровой код, указывающий, что клиент не был зарегистрирован в этом отеле своевременно

    DepartureDate

    Дата отбытия владельца карты из отеля

    DurationOfStay

    Число дней пребывания владельца карты в отеле

    FolioNumber

    Номер книги

    PropertyPhone

    Номер телефона отеля

    CustomerServicePhone

    Номер телефона системы обслуживания клиентов отеля или сети отелей

    ProgramCode

    Код, указывающий тип специальной программы пребывания клиента

    HotelRateInfo

    {DailyRoomRate, [DailyTaxRate]}

    HotelCharges

    {RoomCharges, [RoomTax], [PrepaidExpenses], [FoodBeverageCharges], [RoomServiceCharges], [MiniBarCharges], [LaundryCharges], [TelephoneCharges], [BusinessCenterCharges], [ParkingCharges], [MovieCharges], [HealthClubCharges], [GiftShopCharges], [FolioCashAdvances], [OtherCharges], [TotalTaxAmount ], [AuditAdjustment]}

    DailyRoomRate

    Стоимость проживания в день. В эту сумму входят налоги, если не специфицирована переменная DailyTaxRate.

    DailyTaxRate

    Размер налога за проживание одного дня в гостинице

    RoomCharges

    Полная стоимость проживания в номере с учетом дополнительных расходов, перечисленных ниже

    RoomTax

    Налог, взымаемый с суммы RoomCharges

    PrepaidExpenses

    Полный размер предоплаты

    FoodBeverageCharges

    Оплата еды и напитков

    RoomServiceCharges

    Оплата обслуживания номера

    MiniBarCharges

    Оплата пользования минибаром

    LaundryCharges

    Оплата услуг прачечной

    TelephoneCharges

    Плата за пользование телефоном

    BusinessCenterCharges

    Оплата за услуги бизнес-центра

    ParkingCharges

    Оплата парковки

    MovieCharges

    Оплата за просмотр фильмов в номере

    HealthClubCharges

    Оплата услуг оздоровительного клуба

    GiftShopCharges

    Оплата покупок в сувенирном магазине

    FolioCashAdvances

    Сумма, предварительно внесенная за номер

    OtherCharges

    Другие расходы

    TotalTaxAmount

    Сумма налогов, включенная в счет

    AuditAdjustment

    Изменение платежа в результате перепроверки расчетов в отеле

    Структура данных MarketTransportCap представлена в таблице 4.6.2.51.

    Таблица 4.6.2.51. Структура MarketTransportCap

    MarketTransportCap

    {PassangerName, DepartureDate, OrigCityAirport, [TripLegSeq], [TicketNumber], [TravelAgencyCode], [TravelAgencyName], [Restrictions]}

    PassangerName

    Имя пассажира, кому выдается билет

    DepartureDate

    Дата отбытия

    OrigCityAirport

    Город начала путешествия

    TripLegSeq

    {TripLeg +}
    от одной до 10 TripLeg-записей

    TicketNumber

    Номер билета

    TravelAgencyCode

    Код турагенства

    TravelAgencyName

    Название турагенства

    Restrictions

    Численный код, указывающий на ограничения выплат и расходов

    TripLeg

    {DateOfTravel, CarrierCode, ServiceClass, StopOverCode, DestCityAirport, [FareBasisCode], [DepartureTax]}

    DateOfTravel

    Дата путешествия

    CarrierCode

    Код перевозчика данного тура

    ServiceClass

    Класс услуг тура

    StopOverCode

    Числовой код, указывающий на допустимость остановок в пути при совершении тура

    DestCityAirport

    Аэропорт места назначения тура

    FareBasisCode

    Код базовой цены тура

    DepartureTax

    Налог при отбытии для данного тура

    Структура данных, указывающих место (Location), представлена в таблице ниже.

    Location

    {CountryCode, [City], [StateProvince], [PostalCode], [LocationID]}

    CountryCode

    Код страны ISO 3166

    City

    Название города

    StateProvince

    Название или аббревиатура штата или провинции

    PostalCode

    Почтовый код

    LocationID

    Идентификатор, который использует продавец, чтобы специфицировать один из своих адресов

    Структура данных RRTags представлена в таблице 4.6.2.52.

    Таблица 4.6.2.52. Структура RRTags

    RRTags

    { RRPID, MerTermIDs, Date}

    RRPID

    Новый идентификатор пары запрос/отклик

    MerTermIDs

    {MerTermIDs, [TerminalID], [AgentNum], [ChainNum], [StoreNum]}

    Date

    Текущая дата для устаревающих записей

    MerchantID

    Владелец карты заносит эти данные в PIHead. Этот код копируется из MerID в сертификат подписи продавца.

    TerminalID

    Продавец вводит эти данные в AuthReq.

    AgentNum

    Продавец вводит эти данные в AuthReq.

    ChainNum

    Продавец вводит эти данные в AuthReq.

    StoreNum

    Продавец вводит эти данные в AuthReq.

    Формирование RRTags производится следующим образом

    Шаг

    Действие

    1

    Формируется новый RRPID и запоминается в базе данных транзакции.

    2

    Заносятся MerTermIDs из записанных данных продавца, описывающих место продажи.

    3

    Записывается текущая дата в поле Date.

    Целью BatchStatus является предоставление данных о состоянии платежной линии между расчетным центром и продавцом или для согласования объемов платежей продавца в расчетный центр. Структура данных BatchStatus представлена в таблице 4.6.2.53.

    Таблица 4.6.2.53. Структура BatchStatus

    BatchStatus

    {OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]}

    OpenDateTime

    Дата и время открытия платежной линии

    ClosedWhen

    {CloseStatus, CloseDateTime}

    BatchDetails

    {CloseDateTime, [BrandBatchDetailsSeq]}

    BatchExtensions

    Данные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса

    CloseStatus

    Цифровой код, указывающий статус закрытия платежной линии

    CloseDateTime

    Дата и время закрытия платежной линии

    BatchTotals

    {TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]}

    BrandBatchDetailsSeq

    {BrandBatchDetails +}

    TransactionCountCredit

    Число транзакций, которые внесли вклад в кредит продавца.

    TransactionTotalAmtCredit

    Полная сумма, внесенная на счет продавца

    TransactionCountDebit

    Число транзакций, которые внесли вклад в дебет продавца

    TransactionTotalAmtDebit

    Полная сумма, снятая со счета продавца

    BatchTotalExtensions

    Данные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса.

    Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail.

    BrandBatchDetails

    {BrandID, BatchTotals}

    BrandID

    Тип платежной системы карты без типа продукта

    Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54.

    Таблица 4.6.2.54. Структура TransactionDetail

    TransactionDetail

    {TransIDs, AuthRRPID, BrandID, BatchSequenceNum, [ReimbursementID], TransactionAmt, TransactionAmtType, [TransactionStatus], [TransExtensions]}

    TransIDs

    Идентификаторы транзакций обработки авторизации/оплаты для заданной позиции

    AuthRRPID

    RRPID, который присутствует в соответствующих AuthReq или AuthRevReq

    BrandID

    Платежная система карты (без типа продукта)

    BatchSequenceNum

    Порядковый номер позиции в пакете платежей

    ReimbursmentID

    Цифровой код, указывающий на тип оплаты для заданной позиции

    TransactionAmt

    Сумма для позиции, тип которой указан в TransactionAmtType. Сумма всегда обозначается положительным числом.

    TransactionAmtType

    Цифровой код, указывающий тип суммы (кредит или дебет)

    TransactionStatus

    Цифровой код, индицирующий результат прохождения транзакции для вышестоящей системы

    TransExtensions

    Данные в расширении для административного отклика последовательности платежей (batch) должны иметь финансовый характер и использоваться при обработке административного запроса для заданной последовательности платежей.
    Информация, имеющая отношение к обработке запроса должна размещаться в расширении BatchAdminResData.

    Суммы в платежных сообщениях SET характеризуются тремя полями: валюта, сумма и amtExp10. Эти поля содержат ASCII-строки, формат которых охарактеризован в таблице ниже.

    Поле

    Определение

    currency (валюта)

    Значение представляется в виде строки ASCII-символов, характеризующей три цифры кода валюты (ISO 4217) Например, платеж в долларах США будет обозначен кодом 840. Возможные значения лежат в диапазоне 1-999 включительно.

    amount (cумма)

    Значение представляется в виде строки ASCII-символов, характеризующей сумму платежа в указанной валюте. Значение должно соответствовать положительному числу.

    amtExp10

    Значение представляется в виде строки ASCII-символов, характеризующей десятичный показатель степени:

    cумма * (10 amtExp10). Значение может быть как положительным, так и отрицательным.

    Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и -2.

    Поля Date

    Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате:

    YYYYMMDDHHMM[SS[.f]f]f]]]Z

    где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму:

    20011003102853.33Z,

    что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня.

    Поток платежных сообщений

    Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система.

    Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes.

    На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.

    Рис. 4.6.2.14. Диаграмма обмена для протокола покупки

    На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.

    Рис. 4.6.2.15. Опции обмена сообщениями при покупке

    Рис. 4.6.2.15а. (продолжение)

    Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.

    Обработка запросов/откликов инициализации платежа

    Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика. В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз.

    Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.

    Шаг

    Действие

    1

    Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом

    2

    Занести в поле Language, значение которое выбрал владелец карты для данной транзакции

    3

    Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды.

    4

    Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение.

    5

    Сформировать новый код Chall-C

    6

    На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET).

    7

    Заполнить поле BIN (первые 6 цифр номера счета владельца карты)

    8

    Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат.

    9

    Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются).

    10

    Опционно. Заполнить любые расширения PInitReq.

    11

    Занести все это в цифровой конверт и послать продавцу

    Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55.

    Таблица 4.6.2.55. Структура PInitReq

    PInitReq

    { RRPID, Language, LID-C, [LID-M], Chall-C, BrandID, BIN, [Thumbs], [PIRqExtensions]}

    RRPID

    Идентификатор пары запрос/отклик

    Language

    Естественный язык владельца карты

    LID-C

    Локальный ID. Метка, формируемая системой владельца карты или для нее.

    LID-M

    Копируется из сообщения инициации SET (если имеется)

    Chall-C

    Вызов владельца карты, служащий для гарантии новизны подписи продавца

    BrandID

    Выбранная владельцем карты платежная система

    BIN

    Номер идентификации банка из номера счета владельца карты (первые 6 цифр)

    Thumbs

    Оттиски списка сертификатов, CRL и BrandCRLIdentifier из кэша владельца карты

    PIRqExtensions

    Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.

    Алгоритм обработки PInitReq продавцом представлен ниже.

    Шаг

    Действие

    1

    Извлечь запрос из входного сообщения

    2

    Если LID-M присутствует, найти запись транзакции, базирующуюся на LID-M. Если запись не найдена:

    • Прислать сообщение Error c ErrorCode равным unknownLID
    • Прервать обработку PInitReq

    3

    Если LID-M отсутствует, найти запись транзакции, на основе критериев, выходящим за пределы регламентаций SET. Если продавец не сформировал LID-M для этой транзакции, опционно сгенерировать LID-M и занести его в запись транзакции.

    4

    Сформировать новый XID

    5

    Занести XID, RRPID, Language, LID-C, Chall-C, BrandID и BIN в запись транзакции

    6

    Если оттиски присутствуют, произвести спасение записи транзакции

    7

    Если имеется какое-либо расширение PInitReq, произвести его обработку. Если расширение не распознано и флаг критичности равен TRUE, сформировать сообщение Error, в противном случае игнорировать расширение. Если расширение распознано, его следует обработать.

    Формирование продавцом отклика PInitRes осуществляется следующим образом.

    Шаг

    Действие

    1

    Сформировать структуру данных PInitRes следующим образом:

    1. Сгенерировать TransID согласно следующей процедуре:
    • Скопировать LID-C, XID и Language из записи транзакции
    • Если запись транзакции содержит LID-M, скопировать его
    • Занести текущую дату в TransIDs.PReqDate
    1. Скопировать RRPID из записи транзакции
    2. Скопировать Chall-C из записи транзакции
    3. Сформировать новый Chall-M
    4. Если оттиск для текущего BrandCRLIdentifier не получен или устарел, занести новый BrandCRLIdentifier
    5. На основе информации из PInitReq (BrandID, BIN и сертификат владельца карты) выбрать расчетный центр. Записать в PEThumb оттиск сертификата выбранного расчетного центра.
    6. Скопировать оттиски из PInitReq, если он имеется. Это позволяет владельцу карты проверить, что продавцу корректно доставлены все посланные оттиски.
    7. Опционно: добавить любые PIRqExtensions

    2

    Ввести Compose SignedData. Если оттиск для Cert-PE не получен в PInitReq, включить в подпись Cert-PE.

    3

    Вставить все эти данные в цифровой конверт и послать владельцу карты

    Информационная структура PInitRes представлена ниже в таблице 4.6.2.56.

    Таблица 4.6.2.56. Структура PInitRes

    PInitRes

    S(M, PInitResData)

    PInitResData

    {TransIDs, RRPID, Chall-C, Chall-M, [BrandCRLIdentifier], PEThumb, [Thumbs], [PIRsExtensions]}

    TransIDs

    Смотри описание структуры TransID выше

    RRPID

    Идентификатор пары запрос/отклик

    Chall-C

    Копируется из сообщения PInitReq

    Chall-M

    Вызов продавца, служащий для проверки новизны подписи владельца карты

    BrandCRLIdentifier

    Список текущих CRL для всех СА в рамках заданной платежной системы.

    PEThumb

    Оттиск сертификата ключевого обмена расчетного центра.

    Thumbs

    Копируется из PInitReq

    PIRsExtensions

    Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных.

    При получении владельцем карты сообщения PInitRes он обрабатывает его следующим образом.

    Шаг

    Действие

    1

    Извлечь PInitRes из входного сообщения

    2

    Вызвать Receive SignedData

    3

    Проверить TransID следующим образом:

    1. Осуществить поиск транзакции с использованием LID-C. Если поиск безуспешен:
    • Послать сообщения Error с ErrorCode равным unknownLID
    • Остановить обработку PInitRes
    1. Если LID-M был послан во время инициализационного процесса SET, сравнить LID-M с LID-M в записи транзакции. Если они неэквивалентны, то:
    • Послать сообщение Error с ErrorCode равным unknownLID
    • Остановить обработку PInitRes

    с) Если LID-M не был послан и имеется LID-M, то:

    • Послать сообщение Error с ErrorCode равным unknownLID
    • Остановить обработку PInitRes

    4

    Сравнить RRPID со значением из записи транзакции. Если они отличаются, то:

    1. Послать сообщение Error с ErrorCode равным unknownRRPID
    2. Остановить обработку PInitRes

    5

    Сравнить Сhall-C со значением из записи транзакции. Если они отличаются, то:

    1. Послать сообщение Error с ErrorCode равным challengeMismatch.
    2. Остановить обработку PInitRes

    6

    В опционном варианте управления со стороны владельца карты из сертификата продавца извлекается его имя и отображается для пользователя. Если владелец карты одобряет кандидатуру, процесс продолжается, в противном случае обработка PInitRes прерывается.

    7

    Занести данные, включая TransID и Chall-M, в запись транзакции

    8

    Обработать BrandCRLIdentifier, если он присутствует.

    9

    Использовать PEThumb для идентификации сертификата шифрования (Cert-PE), чтобы использовать в PReq при шифровании данных для расчетного центра.

    10

    Проверить, что сертификат платежной системы продавца и сертификат расчетного центра (Cert-PE) согласуются с платежной системой владельца карты, указанной в PInitReq. Если согласия нет, владелец карты оповещается об этом, а обработка PInitReq прерывается.

    11

    Если поле Thumbs присутствует, сравнить его значение с тем, что прислано в PInitReq. Если значения совпадают, перейти к исполнению пункта 14, в противном случае:

    • Послать сообщение Error с ErrorCode равным thumbsMismatch
    • Остановить обработку PInitRes

    12

    Если поле Thumbs отсутствует, проверить, что Thumbs не было послано в PInitReq. Если Thumbs было послано в PInitReq, то:

    • Послать сообщение Error с ErrorCode равным thumbsMismatch
    • Остановить обработку PInitRes

    13

    Если PIRsExtensions существуют, их необходимо обработать. Если они не распознаны, а флаг критичности (criticality) равен TRUE, сформировать сообщение Error, в противном случае расширения следует игнорировать.

    14

    Проверить Cert-PE (идентифицированный в PEThumb) для неподписанных транзакций. Если индикатор в Cert-PE не допускает неподписанных транзакций, а владелец карты не имеет сертификата, информировать его о том, что транзакция не может быть продолжена и прервать обработку.

    15

    Владелец карты может теперь продолжить процедуру посылкой запроса покупки.

    Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует иметь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации.

    Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется.

    Обработка заказа-покупки

    Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа.

    Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).

    Рис. 4.6.2.16. Обработка запроса покупки

    Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца. Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP).

    Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привлечением секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу.

    Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе.

    Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов.

    Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись.

    PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:

    • C PI используется OAEP
    • В блок OAEP включается H(PIHead) (вместе с PANData)
    • С PIHead используется H(OIData)
    • Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead.

    Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).

    Шаг

    Действие

    1

    Извлечь PurchAmt и OD

    2

    Сформировать OIData следующим образом:
    a)

    Если имел место обмен PInitReq/ PInitRes:

    Скопировать TransIDs из PInitRes

    В противном случае:

    Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID

    b)

    Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца

    Если имел место обмен PInitReq/PInitRes:

    Скопировать Chall-c из PInitRes

    В противном случае:

    Сформировать новый Chall-C

    c)

    Сформировать новый ODSalt

    d)

    Сформировать HODInput посредством следующей процедуры:

    • Скопировать OD из данных процесса инициализации SET
    • Записать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET.
    • Скопировать ODSalt из пункта 2 с)
    • Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurData
    • Опционно: добавить любые ODExtensions
    e)

    Сформировать HOD с HODInput из пункта 2 d

    f)

    Если имел место обмен PInitReq/ PInitRes:

    Скопировать Chall-M из PInitRes и не заполнять BrandID

    В противном случае:

    Не заполнять Chall-M
    Записать BrandID, указав предпочтительный тип карты

    g)

    Произвести записьв поле BIN с HODInput из пункта 2d

    h)

    Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш

    i)

    Опционно: добавить любые расширения OIExtensions.

    3

    Сформировать PIHead следующим образом:
    a)

    Скопировать TransIDs, вычисленные в пункте 2.а

    b)

    Сгенерировать Inputs согласно процедуре:

    • Скопировать HOD из пункта 2.е
    • Скопировать PurchAmt из шага 2.d.2
    c)

    Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога

    d)

    Скопировать InstallRecurData из пункта 2.d.4 (если имеется)

    e)

    Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями.

    f)

    Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения

    g)

    Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом:

    1. Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f.
    2. Сформировать новый AcqBackKey (приемлемый для AcqBackAlg)
    h)

    Опционно добавить любые PIExtensions

    4

    Сформировать PANData

    5

    Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2)

    6

    Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет.

    Когда расчетный центр готов шифровать данные для конечного пользователя (ЕЕ), его сертификат содержит список симметричных алгоритмов шифрования, которые он поддерживает, в порядке их предпочтения. Конечный пользователь, который хочет иметь шифрованные данные, выбирает первый алгоритм из списка, который он способен использовать. Ключ для этого алгоритма передается расчетному центру в сообщении PReq.

    Реализация PReqDualSigned рассмотрена ниже.

    Шаг

    Действие

    1

    Сформировать PISignature:

      1. Сформировать PI-TBS:
      1. Сгенерировать HPIData в виде дайджеста PIData
      2. Сгенерировать HOIData в виде дайджеста OIData
      1. Выполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t).

    2

    Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p)

    3

    Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2.

    4

    Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.).

    5

    Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2)

    6

    Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5.

    Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned). Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57.

    Таблица 4.6.2.57. Структура PReqDualSigned

    PReqDualSigned

    {PIDualSigned, OIDualSigned}

    PIDualSigned

    Смотри описание PI (выше)

    OIDualSigned

    L(OIDualSigned, PIData)

    OIData

    Смотри табл. 4.6.2.59

    PIData

    {PIHead, PANData}

    Структура данных в случае PReqUnsigned показана в таблице 4.6.2.58.

    Таблица 4.6.2.58. Структура PReqUnsigned

    PReqUnsigned

    {PIUnsigned, OIUnsigned}

    PIUnsigned

    Смотри описание PI (выше)

    OIUnsigned

    L(OIData, PIDataUnsigned)

    OIData

    Смотри табл. 4.6.2.59

    PIDataUnsigned

    {PIHead, PANToken} (см. табл. 4.6.2.40 и 4.6.2.45)

    Структура данных сообщения PReq для PReqDualSigned и PreqUnsigned показана в таблице 4.6.2.59.

    Таблица 4.6.2.59. Структура PReq для PReqDualSigned и PreqUnsigned

    OIData

    {TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]}

    TransIDs

    Копируется из PInitRes, если имеется

    RRPID

    ID пары запрос/отклик

    Chall-C

    Копируется из соответствующего PInitReq (см. табл. 4.6.2.55)

    HOD

    DD(HODInput)

    Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью

    ODSalt

    Копируется из HODInput

    Chall-M

    Вызов продавца владельцу карты относительно свежести подписи

    BrandID

    Выбранная владельцем карты платежная система

    BIN

    Идентификационный номер банка из номера счета владельца карты (первые 6 цифр)

    ODExtOIDs

    Список объектных идентификаторов из ODExtensions

    OIExtensions

    Данные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации.

    HODInput

    {OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]}

    OD

    Описание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д.

    PurchAmt

    Число транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40).

    ODSalt

    Новое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD.

    InstallRecurData

    См. табл. 4.6.2.41

    ODExtensions

    Данные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу.

    При получении PReq продавец производит следующие действия.

    Шаг

    Действие

    1

    Извлекает PReq из входного сообщения

    2

    Если получено PReqDualSigned, производит проверку подписи;

      1. Извлекает OIData и HPData из OIDualsigned
      2. Формирует HOIData в виде дайджеста OIData
      3. Формирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В.
      4. Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t).
      5. Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq.
      6. Переходит к выполнению пункта 4.

    3

    Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то:

        1. Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись)
        2. Останавливает обработку PReq

    4

    Производит обработку TransIDs:
    Проводит поиск транзакций, базирующихся на XID.
    Если запись такой транзакции найдена
    Сравнивает LID-C и LID-M с записью. Если соответствия нет:

    1. Возвращает сообщение Error c ErrorCode = unknownLID
    2. Останавливает обработку PReq

    В противном случае сверяет Chall-M с записью. Если соответствия нет, то:

    1. Присылает сообщение Error c ErrorCode = challengeMismatch
    2. Останавливает обработку PReq

    В противном случае

    1. Формирует новую запись транзакции
    2. Спасает LID-C, PReqDate и Language
    3. Опционно формирует LID-M

     

    5

    Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то:

    1. Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен)
    2. Останавливает обработку PReq

    6

    Запоминает Chall-C, чтобы вернуть его в последующем PRes

    7

    Запоминает оставшиеся переменные из сообщения в базе данных

    8

    Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется)

    9

    Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes

    После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:

    Шаг

    Действие

    1

    Сформировать PResData:

    1. Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центра
    2. Скопировать RRPID из PReq (или из InqReq)
    3. Скопировать Chall-C из PReq (или из InqReq)
    4. Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifier
    5. Сформировать PresPayloadSeq:
      1. Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2.
      2. Если расчетный центр отклонил заказ, сформировать PresPayload:
      • Установить CompletionCode = orderReject
      • Скопировать AcqCardMsg из AuthRes, если имеется.
      • Перейти к пункту 2
      1. Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2.
      2. Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2.
      3. Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже

    2

    Ввести Compose SignedData

    3

    Вставить сообщение в цифровой конверт и послать владельцу карты

    Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:

    Шаг

    Действие

    1

    Если выполнена только авторизация:

    1. Установить CompletionCode = authorizationPerformed
    2. Сформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq.

    2

    Если оплата (capture) выполнена:

      1. Установить CompletionCode = capturePerformed
      2. Сформировать Results, как это описано ниже, опуская CredStatusSeq

    3

    Если кредитование осуществлено;

      1. Установить CompletionCode = creditPerformed
      2. Сформировать Results, как это описано ниже

    4

    Опционно добавить любые PRsExtensions

    Формирование поля Results производится согласно следующему алгоритму:

    Шаг

    Действие

    1

    Скопировать AcqCardMsg из AuthRes, если этот отклик имеется

    2

    Если позиция авторизована, сформировать AuthStatus:

      1. Скопировать AuthDate из записи транзакции
      2. Скопировать AuthCode из записи транзакции
      3. Вычислить AuthRatio, как AuthReqAmt ÷ PurchAmt
      4. Если в AuthRes присутствуют данные о конвертации валюты, скопировать их

    3

    Если позиция оплачена, сформировать CapStatus:

    1. Скопировать CapDate из записи транзакции
    2. Скопировать CapCode из записи транзакции
    3. Вычислить CapRatio, как CapReqAmt ÷ PurchAmt

    4

    Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus:

    1. Скопировать CreditDate из записи транзакции
    2. Скопировать CreditCode из записи транзакции
    3. Вычислить CreditRatio, как CapRevOrCredReqAmt ¸ PurchAmt

    Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60.

    Таблица 4.6.2.60. Структура PRes, формируемая продавцом

    PRes

    S(M, PresData)

    PResData

    {TransIDs, RRPID, Chall-C, [BrandCRLIdentifier], PresPayloadSeq}

    TransIDs

    Копируется из PReq

    RRPID

    Идентификатор пары запрос/отклик

    Chall-C

    Копируется из соответствующего PInitReq

    BrandCRLIdentifier

    Список текущих CRL для всех СА в зоне ответственности СА платежной системы

    PResPayloadSeq

    {PresPayload +}
    Одна запись для каждой выполненной авторизации. Отмена авторизации удаляет запись из PResPayload. Если не было авторизаций, появляется одна позиция с соответствующей статусной записью

    PResPayload

    См. табл. 4.6.2.61

    Структура данных PResPayload представлена в таблице 4.6.2.61

    Таблица 4.6.2.61. Структура PResPayload

    PResPayload

    {CompletionCode, [Results], [PrsExtensions]}

    CompletionCode

    Цифровой код, указывающий на состояние завершения транзакции

    Results

    {[AcqCardMsg], [AuthStatus], [AuthStatus], [CredStatusSeq]}

    PRsExtensions

    Отклик на запрос покупки не зашифрован и по этой причине не должен содержать конфиденциальную информацию

    AcqCardMsg

    Копируется из AuthRes (см. табл. 4.6.2.43)

    AuthStatus

    {AuthDate, AuthCode, AuthRatio, [CurrConv]}

    CapStatus

    {CapData, CapCode, CapRatio}
    Данные присутствуют здесь, только если CapReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.

    CredStatusSeq

    {CredStatus +}
    Данные присутствуют, только если CredReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные.

    AuthDate

    Данные авторизации. Копируются из AuthRRTags.Date (см. табл. 4.6.2.64)

    AuthCode

    Цифровой код, указывающий на состояние авторизационного процесса. Копируется из AuthResPayload.

    AuthRatio

    AuthReqAmt ÷ PurchAmt

    CurrConv

    {CurrConvRate, CardCurr}
    Информация о конвертировании валюты, копируется из AuthResPayload

    CapData

    Дата оплаты, копируется из CapPayload

    CapCode

    Цифровой код, указывающий на состояние оплаты, копируется из CapResPayload

    CapRatio

    CapReqAmt ÷ PurchAmt

    CreditStatus

    {CreditDate, CreditCode, CreditRatio}

    Данные присутствуют, только если реализован запрос CreditReq. Эта информация удаляется CredRevReq

    CreditDate

    Дата кредита. Копируется из CapRevOrCredCode.

    CreditCode

    Цифровой код, указывающий на состояние кредита. Копируется из CapRevOrCredResPayload.CapRevOrCredCode. (см. табл. 4.6.2.74)

    CreditRatio

    CapRevOrCredReqAmt ÷ PurchAmt

    Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62).

    Таблица 4.6.2.62. Коды завершения операции

    meanonglessRatio

    PurchAmt=0; отношение не может быть вычислено

    orderRejected

    Продавец не может обработать заказ

    orderReceived

    Процессы авторизации отсутствуют

    orderNotReceived

    Информационный запрос получен до заказа

    authorizationPerformed

    См. AuthStatus

    capturePerformed

    См. CapStatus

    creditPerformed

    См. CreditStatus

    Владелец карты обрабатывает полученный отклик PRes следующим образом.

    Шаг

    Действие

    1

    Извлекается отклик из входного сообщения

    2

    Чтобы проверить подпись продавца, производится обращение к Received Signed Data,

    3

    На основе Trans.LID-C ищется запись транзакции. Если запись не найдена:

    1. Посылается сообщение Error c ErrorCode равным unknownLID
    2. Прерывается обработка PRes

    4

    Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет:

    1. Посылается сообщение Error c ErrorCode равным unknownXID
    2. Прерывается обработка PRes

    5

    Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет:

    1. Посылается сообщение Error c ErrorCode равным unknownRRPID
    2. Прерывается обработка PRes

    6

    Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет:

    1. Посылается сообщение Error c ErrorCode равным challengeMismatch
    2. Прерывается обработка PRes

    7

    Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной.

    8

    Для каждого PResPayload из PresPayloadSeq выполняются следующие действия:

    1. Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio).
    2. В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmount*CapRatio).
    3. В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmount*AuthRatio).
    4. В противном случае сообщить результат транзакции на основе CompletionCode.
    5. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы.

    Обработка информационных запросов

    Пара сообщений InqReq/InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.

    Шаг

    Действие

    1

    1. Копируется InqReqData из предыдущего запроса
    2. Формируется новый RRPID
    3. Генерируется новый Chall-С
    4. Опционно добавляются любые InqReqExtensions

    2

    Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData

    3

    Вставить сообщение в цифровой конверт и послать продавцу

    Структура данных запроса InqReq представлена в таблице 4.6.2.63.

    Таблица 4.6.2.63. Структура InqReq

    InqReq

    <InqReqSigned, InqReqData>

    InqReqSigned

    S(C, InqReqData)

    InqReqData

    {TransIDs, RRPID, Chall-C2, [InqRqExtensions]}

    TransIDs

    Копируется из самого последнего: PReq, PRes, InqReq

    RRPID

    Идентификатор пары запрос/отклик

    Chall-C2

    Новый вызов владельца карты по поводу подписи продавца.

    InqRqExtensions

    Информационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации.

    Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:

    Шаг

    Действие

    1

    Извлекается запрос из входного сообщения

    2

    Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда:

    1. Прислать сообщение InqRes c CompletionCode = signatureRequired.
    2. Прервать обработку InqReq

    В противном случае перейти к пункту 4.

    3

    Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла:

    1. Прислать сообщение Error с ErrorCode = signatureFailure
    2. Прервать обработку InqReq

    4

    Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет:

    1. Прислать сообщение Error c ErrorCode = wrapperMsgMismatch
    2. Прервать обработку InqReq

    5

    Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен:

    1. Прислать InqRes c CompletionCode = orderNotReceived.
    2. Прервать обработку InqReq

    6

    Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то:

    1. Прислать сообщение Error c ErrorCode = unknownXID.
    2. Прервать обработку InqReq

    7

    Сформировать PResPayloadSeq

    Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.

    Рис. 4.6.2.17. Авторизация платежей

    Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр.

    Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись.

    После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты.

    Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты.

    При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса. Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель).

    Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу.

    Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись.

    Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе.

    Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты.

    Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа. В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.

    Шаг

    Действие

    1

    Сгенерировать AuthTags (см. табл. ниже)

    2

    Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI.

    3

    Сгенерировать AuthReqPayload (см. табл. ниже)

    4

    Опционно для одновременной авторизации и резервирования заказа:

    1. Установить CaptureNow = TRUE
    2. Сгенерировать SaleDetail (см. табл. 4.6.2.47)
    3. Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа).

    Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа.

    5

    Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken.

    6

    Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра.

    7

    Осуществить EncB-инкапсуляцию

    8

    Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы.

    9

    Поместить сообщение в цифровой конверт и отправить адресату

    Процедура формирования AuthTags показана в таблице ниже.

    Шаг

    Действие

    1

    Заполнить поле AuthRRTags (см. табл. 4.6.2.52)

    2

    Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID.

    3

    Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes

    Схема формирования поля данных AuthReq показана ниже.

    Шаг

    Действие

    1

    Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE.

    2

    Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData

    3

    Установить AuthReqAmt равным числу авторизаций

    4

    Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты.

    5

    Если при некотором платеже необходимы данные MerchData, добавить их в сообщение.

    6

    Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки.

    7

    Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты.

    8

    Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение.

    9

    Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE.

    Структура данных сообщения AuthReq представлена в таблице 4.6.2.64.

    Таблица 4.6.2.64. Структура AuthReq

    AuthReq

    EncB(M, P, AuthReqData, PI)

    AuthReqData

    {AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]}

    PI

    См. табл. 4.6.2.39.

    AuthReqItem

    {AuthTags, [CheckDigests], AuthReqPayload}

    MThumbs

    Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца.

    CaptureNow

    Булева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация.

    SaleDetail

    См. табл. 4.6.2.47

    AuthTags

    {AuthRRTags, TransIDs, [AuthRetNum]}

    CheckDigests

    {HOIData, HOD2}

    используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken

    AuthReqPayload

    См. табл. 4.6.2.65

    AuthRRTags

    RRTags
    Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации.

    TransIDs

    Копируется из соответствующего поля OIData (см. табл. 4.6.2.59)

    AuthRetNum

    Идентификация запроса авторизации, используемого в пределах финансовой сети.

    HOIData

    DD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.

    HOD2

    DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.

    Структура данных AuthReqPayload представлена в таблице 4.6.2.65.

    Таблица 4.6.2.65. Структура AuthReqPayload

    AuthReqPayload

    {SubsequentAuthInd, AuthReqAmt, [AVSData],
    [SpecialProcessing], [CardSuspect],
    RequestCardTypeInd, [InstallRecurData],
    [MarketSpecAuthData], MerchData, [ARqExtensions]}

    SubsequentAuthInd

    Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки

    AuthReqAmt

    Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие

    AVSData

    {[StreetAddress], Location}
    Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.

    SpecialProcessing

    Числовое поле, указывающее тип запрошенной обработки

    CardSuspect

    Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения

    RequestCardTypeInd

    Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).

    InstallRecurData

    См. табл. 4.6.2.41.

    MarketSpecAuthData

    < MarketAutoAuth, MarketHotelAuth, MarketTransportAuth >
    Специфические авторизационные данные рынка

    MerchData

    {[MerchCatCode], [MerchGroup]}

    ARqExtensions

    Данные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты.

    StreetAddress

    Адрес улицы владельца карты

    MarketAutoAuth

    {Duration}

    MarketHotelAuth

    {Duration, [Prestige]}

    MarketTransportAuth

    {}
    В настоящее время нет авторизационных данных для этого сегмента рынка

    MerchCatCode

    4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.

    MerchGroup

    Числовой код, идентифицирующий общую категорию продавца

    Duration

    Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).

    Prestige

    Числовой тип приоритета, определяется платежной системы карты.

    Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.

    Шаг

    Действие

    1

    Извлечь запрос из транспортного сообщения

    2

    Дешифровать PI

    3

    Сравнить TransIDs из AuthTags и PIHead или AuthToken:

    1. Проверить что коды XID идентичны
    2. Проверить что коды LID-C идентичны
    3. Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения

    Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch

    4

    Если PI является AuthToken:

    1. Обработать AuthToken

    В противном случае, если PI подписаны:

    1. Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch.
    2. Проверить PANData
    3. Запомнить данные из PANData

    В противном случае, если PI не подписаны:

    1. Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired
    2. Верифицировать хэш в EXH
    3. Запомнить данные из PANToken

    5

    Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed

    6

    Обработать PIHead:

    1. Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами.
    2. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией.
    3. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch.
    4. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch
    5. Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension
    6. Запомнить данные от PIHead

    7

    Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.

    8

    Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.

    9

    Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported

    10

    Выполнить авторизацию через финансовую сеть платежной карты

    11

    Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты

    12

    Продолжить формирование сообщения AuthRes

    Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.

    Шаг

    Действие

    1

    Получить необходимые данные от авторизационного процесса

    2

    Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.

    3

    Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.

    4

    Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра:

    1. Вставить Cert-PE в цифровой конверт PKCS#4
    2. Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью

    5

    Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса

    6

    Заполнить поле PANToken, если это необходимо для сертификата продавца,

    7

    Заполнить AuthResBaggage (опционно):

    1. Опционно заполнить CapToken
    2. Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты.
    3. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE).

    Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.

    8

    Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.

    9

    Если PANToken имеется, реализовать EncBX-инкапсуляцию

    10

    Вставить сообщение в цифровой конверт и отправить владельцу карты

    Расчетный центр формирует AuthResPayload следующим образом.

    Шаг

    Действие

    1

    Сгенерировать CapResPayload

    Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса

    1. Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq.
    2. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported

    3

    Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.

    4

    Заполнить ResponseData:

    1. Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса.
    2. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса.
    3. Занести в AuthCharInd значение, присланное авторизационным процессом

    Структура полей AuthRes представлена в таблице 4.6.2.66.

    Таблица 4.6.2.66. Структура полей AuthRes

    AuthRes

    <EncB(P, M, AuthResData, AuthResBaggage), EncBX(P, M, AuthResData, AuthResBaggage, PANToken)>

    AuthResData

    {AuthTags, [BrandCRLIdentifier], [PEThumb], AuthResPayload}

    AuthResBaggage

    {[CapToken], [AcqCardMsg], [AuthToken]}

    PANToken

    См. табл. 4.6.2.46. Посылается, если сертификат продавца указывает на то, что информация предназначена продавцу.

    AuthTags

    Копируется из соответствующего AuthReq; TransIDs и AuthRetNum могут быть актуализованы с привлечением текущей информации

    BrandCRLIdentifier

    Список текущих CRL для всех СА в зоне ответственности СА платежной системы.

    PEThumb

    Оттиск сертификата расчетного центра предоставляется, если AuthReq.Mthumbs указывает то, что он нужен продавцу

    AuthResPayload

    См. табл. 4.6.2.67.

    CapToken

    См. табл. 4.6.2.44.

    AcqCardMsg

    Если владелец карты включил AcqBackKeyData в PIHead, расчетный центр может послать это поле продавцу в шифрованном сообщении для владельца карты. Продавец должен скопировать AcqCardMsg в любой последующий отклик PRes или InqRes, посылаемый владельцу карты.

    AuthToken

    Продавец использует это поле в качестве PI в последующих запросах AuthReq. См. табл. 4.6.2.42.

    Структура AuthResPayload представлена ниже в таблице 4.6.2.67.

    Таблица 4.6.2.67. Структура AuthResPayload

    AuthResPayload

    {AuthHeader, [CapResPayload], [ARsExtensions]}

    AuthHeader

    {AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}

    CapResPayload

    Присылается, если CaptureNow имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.

    ARsExtensions

    Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.

    AuthAmt

    Копируется из AuthReqPayload.AuthReqAmt

    AuthCode

    Числовой код, индицирующий результат процесса авторизации

    ResponseData

    {[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}

    BatchStatus

    См. табл. 4.6.2.53.

    CurrConv

    {CurrConvRate, CardCurr}

    AuthValCodes

    {[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}

    RespReason

    Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)

    CardType

    Числовой код, который указывает на тип карты, использованной для транзакции.

    AVSResult

    Числовой код отклика адресной верификационной службы

    LogRefID

    Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)

    CurrConvRate

    Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.

    AuthReqAmt

    Код валюты владельца карты в стандарте ISO 4217

    ApprovalCode

    Код одобрения, присваиваемый транзакции эмитентом

    AuthCharInd

    Числовое значение, которое указывает условия, при которых выполнена авторизация.

    ValidationCode

    4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях.

    MarketSpecDataID

    Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью)

    Список возможных значений кода AuthCode приведен ниже

    approved

    Запрос авторизации удовлетворен

    unspecifiedFailure

    Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.

    declined

    Запрос авторизации отклонен

    noReply

    Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.

    callIssuer

    Эмитент запрашивает телефонный вызов от продавца

    amountError

    Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)

    expiredCard

    Срок действия карты истек

    invalidTransaction

    Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.

    systemError

    Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.

    piPreviouslyUsed

    Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).

    recurringTooSoon

    Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).

    recurringExpired

    Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)

    piAuthMismatch

    Дата в PI от владельца карты не согласуется с данными в OD от продавца.

    installRecurMismatch

    InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.

    captureNotSupported

    Расчетный центр не поддерживает платеж (capture).

    signatureRequired

    Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы.

    cardMerchBrandMismatch

    Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.

    Обработка продавцом отклика AuthRes производится следующим образом.

    Шаг

    Действие

    1

    Получить отклик из входного сообщения

    2

    Извлечь запись транзакции и сравнить с AuthTags:

    1. Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID
    2. Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.

    3

    Если в сообщение включен BrandCRLIdentifier, запомнить CRL.

    4

    Обработать AuthResPayload

    5

    Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата

    6

    Если BatchStatus присутствует, обработать и запомнить данные.

    7

    Обработать AuthResBaggage:

    1. Запомнить CapToken, если это поле присутствует
    2. Если имеется AcqCardMsg, запомнить его для отправки владельцу карты
    3. Запомнить AuthToken, если имеется, для последующей авторизации.

    Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken

    8

    Если присутствует PANToken, записать его в безопасную локальную память

    9

    Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.

    Алгоритм обработки AuthResPayload представлен ниже.

    Шаг

    Действие

    1

    Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.

    2

    Обрабатать CapResPayload:

    1. Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension
    2. Обработать CapCode с целью определения результата
    3. Обработать SaleDetail в соответствии с политикой платежной системы карты
    4. Для успешной оплаты заказа, записать CapCode и CapAmt.

    Если делался запрос оплаты (capture), будет возвращен CapResPayload

    3

    Если имеется CurrConv, запомнить его для переадресации владельцу карты

    4

    Обработать AuthCode, AuthAmt и ResponseData:

    1. Для определения результата обрабатывается AuthCode.
    2. Запомнить AuthCode и AuthAmt для получения успешного результата.
    3. Запомнить ValidationCode для успешного исхода, если это поле имеется.
    4. Запомнить AuthValCode, если имеется.
    5. Запомнить AVSResult, если имеется.
    6. Запомнить LogRefID, если имеется.

    Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode.

    Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0). При этом код отклика не переписывается.

    Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode.

    Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode.

    Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации.

    Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках.

    Запрос/отклик платежа (CapReq/CapRes)

    Пара сообщений CapReq/CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).

    Рис. 4.6.2.18. Обработка платежных запросов

    После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка.

    Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов.

    Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты.

    После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу.

    Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика. Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка.

    Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.

    Шаг

    Действие

    1

    Заполнить поле CapRRTags

    2

    Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken

    3

    Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier

    4

    Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem:

    1. Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции.
    2. Заполнить CapPayload
    3. Заполнить SaleDetail, как это требует политика платежной системы карты.
    4. Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes

    5

    Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль.

    6

    В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken

    7

    Опционно заполняется CRqExtensions

    8

    Если включено PANToken, использовать EncBХ-инкапсуляцию

    9

    Если PANToken не включено, использовать EncB-инкапсуляцию

    10

    Вложить сообщение в цифровой конверт и послать владельцу карты

    Генерация CapPayload осуществляется согласно алгоритму.

    Шаг

    Действие

    1

    Занести в поле CapDate текущее значение даты

    2

    Занести в CapReqAmt сумму выплаты

    3

    Скопировать AuthResPayload из соответствующего AuthRes

    4

    Опционно заполнить CPayExtensions

    Формат сообщения CapReq представлен в таблице 4.6.2.68

    Таблица 4.6.2.68. Формат CapReq

    CapReq

    <EncB(M, P, CapReqData, CapTokenSeq), EncBX(M, P, CapReqData, CapTokenSeq, PANToken)>
    CapTokenSeq является внешним "багажом".
    Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq.

    CapReqData

    {CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]}

    CapTokenSeq

    {[CapToken] +}
    Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю.

    PANToken

    См. табл. 4.6.2.46.

    CapRRTags

    RRTags.
    Новый RRPID и Date

    MThumbs

    Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца.

    CapItemSeq

    {CapItem +}
    Один или более CapItem в упорядоченном массиве

    CRqExtensions

    Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту.
    Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload

    CapToken

    Копируется из соответствующего AuthRes или AuthRevRes

    CapItem

    {TransIDs, AuthRRPID, CapPayload}

    TransIDs

    Копируется из соответствующего AuthRes или AuthRevRes

    AuthRRPID

    RRPID, который появляется в соответствующем AuthReq или AuthRev

    CapPayload

    См. табл. 4.6.2.69.

    Структура данных CapPayload представлена в таблице 4.6.2.69.

    Таблица 4.6.2.69. Структура CapPayload

    CapPayload

    {CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]}

    CapDate

    Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты.

    CapReqAmt

    Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты.

    AuthReqItem

    См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса.

    AuthResPayload

    См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика.

    SaleDetail

    См. табл. 4.6.2.47.

    CPayExtensions

    Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту.
    Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData.

    Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.

    Шаг

    Действие

    1

    Извлечь запрос из входного сообщения

    2

    Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension

    3

    Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче:

    1. Обработать CapPayload
    2. Если CapToken присутствует:
      1. Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken
      2. Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken
      3. Обработать TokenOpaque
    1. В противном случае, если допустимы платежи без CapToken:
      1. Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing
      2. Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData.
    1. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken
    2. Проверить TransIDs
      1. Извлечь запись транзакции
      2. Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID
      3. Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLID

    f) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат.

    Расчетный центр обрабатывает CapPayLoad следующим образом.

    Шаг

    Действие

    1

    Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension

    2

    Запомнить SaleDetail

    3

    Проверить, что BatchID является открытой платежной линией для BrandAndBIN.

    1. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown.
    2. Если линия не открыта, отклонить платеж с CapCode = batchClosed

    4

    Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown.

    Расчетный центр формирует отклик CapRes согласно следующему алгоритму.

    Шаг

    Действие

    1

    Получить данные о платеже от платежного процесса

    2

    Скопировать CapRRTags из CapReq

    3

    Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел.

    4

    Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE:

    1. Вложить Cert-PE в цифровой конверт PKCS#7
    2. Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью

    5

    Опционно занести в поле BatchSequenceNum состояние текущих платежных линий

    6

    Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload

    7

    Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом:

    1. Скопировать TransIDs из соответствующего CapReqItem
    2. Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется
    3. Заполнить CapResPayload

    8

    Опционно заполнить CRsExtensions

    9

    Вставить сообщение в цифровой конверт и послать продавцу

    Генерация CapResPayload осуществляется следующим образом.

    Шаг

    Действие

    1

    Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem

    2

    Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem

    3

    Опционно заполнить CRsPayExtensions

    Структура сообщения-отклика CapRes показана в таблице 4.6.2.70.

    Таблица 4.6.2.70. Структура CapRes

    CapRes

    Enc(P, M, CapResData)

    CapResData

    {CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]}

    CapRRTags

    RRTag >s; копируется из CapReq

    BrandCRLIdentifier

    Список текущих CRL для всех СА в области ответственности платежной системы СА.

    PEThumb

    Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается.

    BatchStatusSeq

    {BatchStatus +}

    CapResItemSeq

    {CapResItem +}
    Заказ соответствует CapReq

    CRsExtensions

    Данные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег.

    BatchStatus

    См. табл. 4.6.2.53.

    CapResItem

    {TransIDs, AuthRRPID, CapResPayload}

    TransIDs

    Копируется из соответствующего CapReq

    AuthRRPID

    RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq

    CapResPayload

    См. табл. 4.6.2.71.

    Структура данных CapResPayload представлена в таблице 4.6.2.71.

    Таблица 4.6.2.71. Структура CapResPayload

    CapResPayload

    {CapCode, CapAmt, [BatchID], [BatchSequenceNum],
    [CRsPayExtensions]}

    CapCode

    Цифровой код, указывающий на состояние платежа

    CapAmt

    Копируется из соответствующего CapReq

    BatchID

    Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq

    BatchSequenceNum

    Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq

    CRsPayExtensions

    Данные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег.

    Продавец обрабатывает отклик CapRes следующим образом.

    Шаг

    Действие

    1

    Извлекается отклик из входного сообщения

    2

    Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается

    3

    Извлекается запись транзакции и производится сравнение CapRRTags:

    1. Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID
    2. Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID

    4

    Если в сообщение включен BrandCRLIdentifier, запомнить все CRL.

    5

    Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата.

    6

    Для каждого CapResItem в CapResSeq:

    1. Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается.
    2. Обработать CapCode для получения результата операции
    3. Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID.

    7

    Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus

    В таблице ниже представлены допустимые значения CapCode.

    success

    Платежная позиция обработана расчетным центром успешно

    unspecifiedFailure

    Причина неудачи неизвестна

    duplicateRequest

    Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID)

    authExpired

    Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты.

    authDataMissing

    В платежном запросе отсутствует авторизационная информация

    invalidAuthData

    Авторизационная информация для данной транзакции некорректна

    capTokenMissing

    Для обработки данной позиции необходимо поле CapToken, а его нет

    invalidCapToken

    Поле CapToken некорректно для данной транзакции

    batchUnknown

    Расчетный центр не знает о существовании платежной линии для данной позиции

    batchClosed

    Платежная линия для данной позиции закрыта

    unknownXID

    Не распознан идентификатор XID

    unknownLID

    Не распознан идентификатор LID

    Сообщения отзыва платежа и кредита синтактически идентичны и выполняют сходную функцию. Алгоритм формирования информационной структуры CapRevOrCredReqData продавцом представлен ниже.

    Шаг

    Действие

    1

    Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой.

    2

    Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром.

    3

    Заполнить одну или более позиций в CredRevOrCredReqItems:

    1. Скопировать TransIDs из соответствующего CapRes.
    2. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется.
    3. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq).
    4. Заполнить NewBatchID, если кредитная линия транзакции закрыта.
    5. Заполнить CapRevOrCredReqData с текущей датой и временем
    6. Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload.
    7. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken.
    8. Опционно заполнить CRvRqItemExtensions

    4

    Опционно заполнить CRvRqExtensions

    Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72.

    Таблица 4.6.2.72. Структура CapRevOrCredReqData

    CapRevOrCredReqData

    {CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]}

    CapRevOrCredRRTags

    RRTags .

    Новый идентификатор RRPID и Date для данной пары.

    MThumbs

    Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца

    CapRevOrCredReqItemSeq

    {CapRevOrCredReqItem +}

    Один или более CapRevOrCredReqItem в виде упорядоченного массива

    CRvRqExtensions

    Данные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом.

    CapRevOrCredReqItem

    {TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]}

    TransIDs

    Копируется из соответствующего CapRes.

    Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса

    CapPayload

    См. табл. 4.6.2.69

    NewBatchID

    Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию.

    CapRevOrCredReqDate

    Дата подачи запроса

    CapRevOrCredReqAmt

    В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload

    NewAccountInd

    Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца.

    CRvRqItemExtensions

    Данные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром

    Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.

    Шаг

    Действие

    1

    Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается.

    2

    Обрабатывается каждое CapRevOrCredItem:

    1. Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions
    2. Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem
      1. Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID.
      2. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID
    1. Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch.
    2. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown.
    3. Запоминается CapRevOrCredAmt
    4. Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети.

    3

    На основе TransIDs в AuthRevTags извлекается запись транзакции.

    Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.

    Шаг

    Действие

    1

    Заполнить поле CapRevOrCredTags

    2

    Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел.

    3

    Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то:

    1. Ввести Cert-PE в цифровой конверт PKCS#7
    2. Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью

    4

    Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено.

    5

    Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом:

    1. Скопировать TransIDs из соответствующего CapRevOrCredReqItem
    2. Если доступно, скопировать RRPID из соответствующего CapRevOrCredItem

    Заполнить CapRevOrCredResPayload следующим образом:

      1. Занести в CapRevOrCredCode результат кредита или отзыва платежа
      2. Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва
      3. Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem
      4. Опционно заполнить CRvRsPayExtensions

    6

    Опционно заполнить CRvRsExtensions

    Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73.

    Таблица 4.6.2.73. Структура CapRevOrCredResData

    CapRevOrCredResData

    {CapRevOrCredRRTags, [BrandCRLIdentifier],
    [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions]

    CapRevOrCredRRTags

    RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData

    BrandCRLIdentifier

    Список текущих CRL для всех СА в зоне ответственности СА платежной системы.

    PEThumb

    Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается

    BatchStatusSeq

    {BatchStatus +}

    CapRevOrCredResItemSeq

    {CapRevOrCredResItem +}
    Один или более CapRevOrCredResItem в упорядоченном массиве

    CRvRsExtensions

    Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром

    BatchStatus

    См. табл. 4.6.2.53.

    CapRevOrCredResItem

    {TransIDs, AuthRRPID, CapRevOrCredResPayload}

    TransIDs

    Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags

    AuthRRPID

    RRPID, который появляется в соответствующем AuthReq или >AuthRevReq

    CapRevOrCredResPayload

    См. табл. 4.6.2.74

    Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74.

    Таблица 4.6.2.74. Структура CapRevOrCredResPayload

    CapRevOrCredResPayload

    {CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]}

    CapRevOrCredCode

    Числовой код, характеризующий состояние отзыва платежа или кредита.

    CapRevOrCredActualAmt

    Копируется из соответствующего CapRevOrCredReqItem.

    BatchID

    Идентификатор платежной линии сделки для банка продавца

    BatchSequenceNum

    Порядковый номер позиции в последовательности платежей

    CRvRsPayExtensions

    Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит.

    Допустимые значения кода CapRevOrCredCode представлены ниже

    success

    Позиция была успешно обработана расчетным центром

    unspecifiedFailure

    Причина неудачи не специфицирована

    duplicateRequest

    Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID)

    originalProcessed

    Запрос платежа для данной позиции был уже обработан

    originalNotFound

    Специфицированная позиция расчетным центром не обнаружена

    capPurged

    Информация о платеже была удалена из памяти транзакций расчетного центра

    missingCapData

    Информация о платеже отсутствует в запросе отзыва платежа или кредита

    missingCapToken

    Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита

    invalidCapToken

    Маркер CapToken некорректен

    batchUnknown

    Платежная линия для данной позиции расчетному центру неизвестна

    batchClosed

    Платежная линия для данной позиции уже закрыта

    Обработка продавцом CapRevOrCredResData осуществляется следующим образом.

    Шаг

    Действие

    1

    Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension.

    2

    Обработать CapRevOrCredTags

    3

    Извлечь запомненную запись транзакции и обработать TransIDs следующим образом:

    1. Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID
    2. Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.

    4

    Если в сообщение включен BrandCRLIdentifier, запомнить CRL.

    5

    Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата.

    6

    Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат

    7

    Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом

    1. Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension
    2. Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID
    3. Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.
    4. Обработать CapRevOrCredPayload следующим образом:
      1. Обработать CapRevOrCredCode для получения результата
      2. Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt
      3. Обработать BatchID и BatchSequenceNum, если таковые имеются

    Пара сообщений CapRevReq/CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75.

    Таблица 4.6.2.75. Структура CapRevReq

    CapRevReq

    <EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)>
    CapTokenSeq является внешним "багажом".
    Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq

    CapRevData

    CapRevOrCredReqData

    CapTokenSeq

    {[CapToken] +}

    Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в
    CapRevOrCredReqData.CapRevOrCredReqItemSeq.
    Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL)

    PANToken

    См. табл. 4.6.2.46

    CapToken

    Копируется из соответствующего AuthRes или AuthRevRes

    Структура отклика показана ниже CapRevRes.

    CapRevRes

    Enc(P,M, CapRevResData)

    CapRevResData

    CapRevOrCredResData

    Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.

    Шаг

    Действие

    1

    Генерируется информация CredReqData

    2

    Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом:

    1. Если доступно, записать CapToken для соответствующей транзакции.
    2. В противном случае (если недоступно), записать NULL.

    Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq

    3

    Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции.
    Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq

    4

    Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию.

    5

    Вставить сообщение в цифровой конверт и послать владельцу карты

    Структура запроса CredReq показана в таблице 4.6.2.76.

    Таблица 4.6.2.76. Структура CredReq

    CredReq

    <EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)>
    CapTokenSeq является внешним "багажом".
    Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS

    CredReqData

    CapRevOrCredReqData ; см. табл. 4.6.2.72.

    CapTokenSeq

    {[CapToken] +}
    Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq.
    Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL

    PANToken

    См. табл. 4.6.2.46

    CapToken

    Копируется из соответствующего AuthResили AuthRevRes

    Расчетный центр обрабатывает полученный CredReq следующим образом.

    Шаг

    Действие

    1

    Извлекается запрос из входного сообщения

    2

    Для каждой позиции, для которой продавец получил маркер CapToken:

    1. Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing
    2. Проверяется CapToken

    3

    Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem.

    Формирование CredRes осуществляется в следующей последовательности.

    Шаг

    Действие

    1

    Получить отклик из финансовой сети платежной карты

    2

    Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе

    3

    Включить Enc-инкапсуляцию для полученных результатов

    4

    Поместить сообщение в цифровой конверт и отправить владельцу карты

    Формат отклика CredRes представлен ниже.

    CredRes

    Enc(P, M, CredResData)

    CredResData

    CapRevOrCredResData; см. табл. 4.6.2.74.

    Продавец обрабатывает CredRes за два шага:

        1. Получается отклик CredRes из входного сообщения
        2. Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму.

    Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита. Формирование запроса CredRevReq осуществляется следующим образом.

    Шаг

    Действие

    1

    Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq

    2

    Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом:

    1. Если доступен, занести CapToken для соответствующей транзакции
    2. В противном случае, если маркер не доступен, записать NULL

    3

    Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции.

    Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq.

    4

    Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию.

    5

    Вставить сообщение в цифровой конверт и направить владельцу карты

    Структура запроса CredRevReq показана в таблице 4.6.2.77.

    Таблица 4.6.2.77. Структура CredRevReq

    CredRevReq

    <EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)>
    CapTokenSeq является внешним "багажом".
    Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq.

    CredRevReqData

    CapRevOrCredReqData; см. табл. 4.6.2.72

    CapTokenSeq

    {[CapToken] +}
    Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq.
    Заметим, что любой CapToken может быть опущен, т.е. может быть NULL

    PANToken

    См. табл. 4.6.2.46

    CapToken

    Копируется из соответствующего AuthRes<=2> или AuthRevRes

    Расчетный центр обрабатывает запрос CredRevReq следующим образом.

    Шаг

    Действие

    1

    Выделить запрос из входного сообщения

    2

    Для каждой позиции, для которой продавец получил CapToken:

    1. Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing
    2. Проверить CapToken

    3

    Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem

    Формирование отклика CredRevRes осуществляется в следующей последовательности.

    Шаг

    Действие

    1

    Получить отклик из финансовой сети платежной карты

    2

    Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе.

    3

    Включить для полученного результата Enc-инкапсуляцию

    4

    Вложить отклик в цифровой конверт и отправить владельцу карты

    Отклик CredRevRes имеет достаточно простой формат:

    CredRevRes

    Enc(P, M, CredRevResData)

    CredRevResData

    CredRevOrCredResData; См. табл. 4.6.2.74.

    Продавец обрабатывает полученный отклик следующим образом

    Шаг

    Действие

    1

    Извлекается отклик из входного сообщения

    2

    Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа.

    Обработка запроса сертификата расчетного центра включает в себя два сообщения, запрос от продавца к расчетному центру и отклик последнего, направляемый продавцу. В запросе продавец просит расчетный центр прислать ему сертификат, который необходим для последующего шифрования сообщений от продавца к расчетному центру. Сертификат присылается в сообщении-отклике. Генерация запроса PCertReq выполняется в следующей последовательности.

    Шаг

    Действие

    1

    Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52.

    2

    Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра.

    3

    Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты:

    1. Заполнить поле BrandID
    2. Опционно заполнить поле BIN

    4

    Опционно заполнить поле PCRqExtensions

    5

    Ввести S (см. описание оператора подпись выше)

    6

    Вложить сообщение в цифровой конверт и отправить владельцу карты

    Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.

    PCertReq

    S(M, PCertReqData)

    PCertReqData

    {PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]}

    PCertTags

    RRTags.
    Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата

    MThumbs

    Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца.

    BrandAndBINSeq

    {BrandAndBIN +}
    Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs

    PCRqExtensions

    Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации

    BrandAndBIN

    {BrandID, [BIN]}

    BrandID

    Платежная система карты (без указания типа).

    BIN

    Идентификационный номер банка для обработки транзакции продавца в расчетном центре.

    Таблица 4.6.2.78. Структура сообщения PCertReq

    Расчетный центр обрабатывает PCertReq следующим образом

    Шаг

    Действие

    1

    Расчетный центр получает PCertReq из входного сообщения

    2

    Обрабатываются расширения PCRqExtensions. Если встречается нераспознанное расширение, помеченное как критическое, прислается отклик unrecognizedExtensions, а PCertReq отбрасывается.

    3

    Обрабатывается BrandIDSeq и MThumbs

    4

    Формируется и посылается PCertRes

    Формирование PCertRes осуществляется в следующей последовательности

    Шаг

    Действие

    1

    Скопировать PCertTags из PCertReq в PCertRes

    2

    Для каждого BrandAndBIN в BrandIDSeq из PCertReq:

    1. Если доступен корректный сертификат:
      1. Заполнить соответствующий сертификат шифрования расчетного центра Cert-PE
      2. Занести в PCertCode, соответствующий PCertResItem c "успешным" кодом PCertCode
      3. Занести в CertThumb оттиск присланного сертификата
    1. В противном случае, если сертификаты недоступны, так как не поддерживается данная платежная система, занести PCertCode, соответствующего PСertResItem c кодом PCertCode = brandUnsupported и опустить CertThumb
    2. В противном случае, если платежная система поддерживается, но BIN неизвестен, занести в поле PCertCode соответствующего PсertResItem код PCertCode = unknownBIN и опустить CertThumb
    3. В противном случае занести в поле PCertCode соответствующего PCertResItem код PCertCode = unspecifiedFailure и опустить CertThumb

    3

    Для каждой платежной системы, для которой необходим сертификат, прислать текущее значение BrandCRLIdentifier, если только Mthumbs не содержит оттиска для текущего BrandCRLIdentifier

    4

    Опционно заполнить PCRqExtensions

    Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79.

    Таблица 4.6.2.79. Структура PCertRes

    PCertRes

    S(P, PCertResTBS)

    PCertResTBS

    {PCertTags, [BrandCRLIdentifierSeq], PCertResItems, [PCRsExtensions]}

    PCertTags

    RRTag s; копируется из PCertReq.

    BrandCRLIdentifierSeq

    {BrandCRLIdentifier +}

    PCertResItems

    {PCertResItem +}

    Один или более статусных кодов и оттисков сертификатов, которые возвращаются в соответствии один к одному с PCertReq.BrandAndBINSeq

    PCRsExtentions

    Сертификатный отклик расчетного центра не шифруется, по этой причине данное расширение не должно содержать конфиденциальных данных.

    BrandCRLIdentifier

    Список текущих CRL для всех CA в зоне ответственности CA платежной системы. См. раздел о BrandCRLIdentifier

    PCertResItem

    {PCertCode, [CertThumb]}

    PCertCode

    Цифровой код, указывающий результат PCertReq

    CertThumb

    Оттиск возвращенного сертификата

    Продавец обрабатывает PCertRes следующим образом.

    Шаг

    Действие

    1

    Извлекается отклик из входного сообщения

    2

    Обрабатываются PCRsExtensions. Если встречается нераспознанное расширение, помеченное как критическое, присылается отклик unrecognizedExtensions и отбрасывается PCertRes

    3

    Извлекаются сертификаты из Cert-PE

    4

    Проверяются сертификаты в Cert-PE путем сравнения их с CertThumbs в PCertResItems. Отбрасываются все сертификаты, которые не прошли сверку.

    5

    Обработатывается каждый BrandCRLIdentifier из присланной последовательности таких идентификаторов.

    6

    Продолжается обработка сообщений, которые ожидали сертификатов, присланных в PCertRes.

    Стандартизованы следующие значения PcertCode, собранные в таблице 4.6.2.80.

    Таблица 4.6.2.80. Значения PCertCode

    success

    Запрос обработан успешно

    unspecifiedFailure

    Запрос не прошел из-за неспецифицированной причины

    brandNotSupported

    Запрос не прошел из-за того, что платежная система, специфицированная в PCertReq, не поддерживается

    unknownBIN

    Запрос не прошел из-за того, что BIN, специфицированный в PCertReq, не поддерживается.

    Управление платежными линиями (Batch)

    Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные.

    Платежная линия формируется расчетным центром, когда продавец открывает ее для накопления транзакций и сумм. Все транзакции, которые проплачиваются, объединяются в специфическую группу (платежную линию - batch) или группу по умолчанию, если не определена специальная платежная линия (группа платежей). Следует учитывать, что в группу платежей могут входить операции, выполненные в рамках различных платежных систем. Поддержка групп платежей позволяет продавцу и расчетному центру улаживать проблемы, связанные с различными несогласованностями.

    Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия.

    Если содержанием платежных линий управляет расчетный центр, продавец не должен вставлять BatchID и BatchSequenceNum в платежные транзакции. Открытие и закрытие платежной линии контролируется в этом случае расчетным центром, который может включать BatchID и BatchSequenceNum в возвращаемую структуру SaleDetail. Продавец при этом не может удалять транзакции из группы или закрывать платежные линии, определенные идентификаторами BatchID, сформированными расчетным центром. Продавец может запросить статусную информацию для любой платежной линии, которая имеет известный BatchID. Расчетный центр возвращает BatchStatus для запрошенной платежной линии. Продавец может запросить BatchStatus для определенных платежных систем или итоговый баланс для конкретной платежной линии.

    Если продавец управляет содержимым платежной линии, тогда он может предоставлять информацию BatchStatus расчетному центру для любого BatchID. Расчетный центр проверяет данные, предоставленные продавцом в BatchStatus путем сверки с информацией, накопленной у него. При этом продавец получит отклик, в котором будет отражено соответствие этих сумм.

    Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.

    Шаг

    Действие

    1

    Если это первое сообщение, направленное расчетному центру после получения нового секретного ключа, или если это первое сообщение в данный день, в цифровой конверт этого сообщения следует вложить сертификаты для секретных ключей и цепочку сертификатов платежной системы, выбранных продавцом для подписи и шифрования сообщений BatchAdmin.

    2

    Сформировать RRTags

    3

    Если новая платежная линия открыта:

    1. Установить BatchOperation = open
    2. Занести в поле BatchID идентификатор для неиспользуемой платежной линии.
    3. Опционно занести в поле BrandAndBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые могут появиться в данной группе платежей.
    4. Установить ReturnBatchSummeryIndicator = FALSE
    5. Опустить все остальные поля сообщения

    4

    Если платежная линия (группа платежей) пуста:

    1. Установить BatchOperation = purged
    2. Занести в BatchID идентификацию для неиспользуемой платежной линии
    3. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы платежей.
    4. Установить ReturnBatchSummeryIndicator = FALSE
    5. Опустить все остальные поля сообщения

    5

    Если платежная линия закрыта:

    1. Установить BatchOperation = closed
    2. Занести в BatchID идентификацию для открытой платежной линии
    3. Установить ReturnBatchSummeryIndicator = FALSE
    4. Опустить все остальные поля сообщения

    6

    Если нужно запросить состояние платежной линии у расчетного центра:

    1. Опустить BatchOperation
    2. Занести в BatchID идентификацию для платежной линии
    3. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить объем статусной информации, возвращаемой в BatchAdminRes.
    4. Установить ReturnBatchSummeryInd = TRUE
    5. Опустить все остальные поля сообщения

    7

    Если нужно запросить детальные данные о платежной линии у расчетного центра:

    1. Опустить BatchOperation
    2. Занести в BatchID идентификацию платежной линии
    3. Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы (платежной линии).
    4. Если необходима итоговая информация платежной линии, установить ReturnBatchSummeryInd = TRUE, в противном случае = FALSE
    5. Если это первый (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить StartingPoint равным значению NextSequence, полученному в предшествующем отклике BatchAdminRes для данной последовательности.
    6. Занести MaximumItems наибольший номер позиции, которую нужно послать в BatchAdminRes
    7. Опустить все остальные поля сообщения

    8

    Если нужно послать состояние платежной линии расчетному центру:

    1. Опустить BatchOperation
    2. Занести в BatchID идентификацию для платежной линии
    3. Опустить BrandandBIN
    4. Установить ReturnBatchSummeryInd = FALSE
    5. Сформировать BatchStatus:
            1. Занести в поле BatchTotals значения для всех транзакций данной группы (batch)
            2. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.

    f) Опустить все остальные поля сообщения

    9

    Если нужно передать расчетному центру детальные данные о платежной линии:

    1. Опустить BatchOperation
    2. Занести в BatchID идентификацию для платежной линии
    3. Опустить BrandandBIN
    4. Установить ReturnBatchSummeryInd = FALSE
    5. Если это последний (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить NextStartingPoint равным значению, позволяющему расчетному центру проверить, что группа платежей принята в правильной последовательности.
    6. Заполнить TransactionDetail для набора позиций платежной линии.
    7. Если NextStartingPoint = 0, опционно сформировать BatchStatus:
      1. Занести в BatchTotals значения для всех транзакций платежной линии.
      2. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии.

    h) Если продавец хочет прервать передачу BranchBatchDetails, установить значение поля MaximumItem равным 0, в противном случае опустить это поле.

    10

    Реализовать операцию подписи для результата шагов 1-9, используя сертификат подписи продавца для любой платежной системы, известной расчетному центру.

    11

    Включить сертификат шифрования продавца для той же платежной системы, что была выбрана на предшествующем шагу. Общедоступный ключ этого сертификата будет использоваться расчетным центром при дешифровке сообщений BatchAdminRes.

    12

    Зашифровать BatchAdminReqTBE, используя сертификат расчетного центра и установить тип содержимого равным id-set-content-BatchAdminReqTBE.

    13

    Вложить сообщение в цифровой конверт и послать владельцу карты

    Структура запроса BatchAdminReq представлена в таблице 4.6.2.81.

    Таблица 4.6.2.81. Структура BatchAdminReq

    BatchAdminReq

    Enc(M, P, BatchAdminReqData)

    BatchAdminReqData

    {BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]}

    BatchAdminRRTags

    RRTags.
    Новый идентификатор RRPID и Date (дата)

    BatchID

    Идентификатор платежной линии для счета банка продавца

    BrandAndBINSeq

    {BrandAndBIN +}

    BatchOperation

    Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии

    ReturnBatchSummaryInd

    Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные.

    ReturnTransactionDetail

    {StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]}
    Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты.

    BatchStatus

    См. табл. 4.6.2.53.

    TransDetails

    {NextStartingPoint, TransactionDetailSeq}

    BARqExtensions

    Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов.

    BrandAndBIN

    {BrandID, [BIN]}

    StartingPoint

    Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes

    MaximumItems

    Максимальное число позиций, которые следует прислать в этой группе.

    ErrorsOnlyInd

    Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки.

    BrandID

    Тип платежной системы (без указания типа продукта).

    NextStartingPoint

    Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций.

    TransactionDetailSeq

    {TransactionDetail +}

    BIN

    Идентификационный номер банка для обработки транзакций продавца.

    TransactionDetail

    См. табл. 4.6.2.54

    Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.

    Шаг

    Действие

    1

    Выделить запрос из входного сообщения

    2

    Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure.

    3

    Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID.

    4

    Если BatchOperation = open:

    1. Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen.
    2. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.
    3. Если имеется BrandIDSeq:
      1. Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported.
      2. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN.
      3. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии.
    1. Открыть платежную линию для использования продавцом и установить BAStatus = success.
    2. Продолжить процесс посылкой BatchAdminRes

    Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open.

    5

    Если BatchOperation = purge:

    1. Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.
    2. Если BrandIDSeq присутствует:
      1. Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.
      2. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.
      3. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN.
    1. В противном случае, удалить все транзакции из группы платежей
    2. Установить BAStatus = success
    3. Продолжить работу посылкой сообщения BatchAdminRes
    Любые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge.

    6

    Если BatchOperation = close:

    1. Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID.
    2. Установить BAStatus = success
    3. Продолжить работу посылкой сообщения BatchAdminRes

    Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close.

    7

    Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE:

    1. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.
    2. Если BrandAndBIN включен:
    1. Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.
    2. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.
    3. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN.
    1. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями.
    2. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes.
    3. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу.

    NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE.

    8

    Если включено поле StartingPoint:

    1. Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.
    2. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.
    3. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes.
    4. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint.
    5. Если имеется BrandAndBIN:
      1. Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.
      2. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.
      3. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd.

    f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes

    9

    Если код BatchOperation опущен, а BatchStatus имеется:

    1. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.
    2. Если имеется поле BrandBatchDetails:
      1. Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch.
      2. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN.
      3. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN.
    1. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует.
    2. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus.
    3. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту.
    4. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes

    10

    Если код BatchOperation опущен и включено поле TransactionDetails:

    1. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable.
    2. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint.
    3. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes.
    4. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes.
    5. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes.
    6. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes.

    Последовательность BrandAndBIN игнорируется.

    Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.

    Шаг

    Действие

    1

    Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом.

    2

    Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData.

    3

    Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE.

    4

    Вложить сообщение в цифровой конверт и послать владельцу карты.

    Структура отклика BatchAdminRes представлена в таблице 4.6.2.82.

    Таблица 4.6.2.82. Структура BatchAdminRes

    BatchAdminRes

    Enc(P, M, BatchAdminResData)

    BatchAdminResData

    {BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]}

    BatchAdminTags

    RRTags; копируется из предшествующего BatchAdminReq

    BatchID

    Идентификатор платежной линии между продавцом и его банком.

    BAStatus

    Числовой код, указывающий на состояние открытой платежной линии.

    BatchStatus

    См. табл. 4.6.2.53.

    TransmissionStatus

    Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня

    SettlementInfo

    {SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate}

    TransDetails

    {NextStartingPoint, TransactionDetailSeq}

    BARsExtensions

    Данные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии.
    Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail.

    SettlementAmount

    Занесенная через сеть на счет продавца сумма

    SettlementType

    Числовой код, указывающий тип суммы

    SettlementAccount

    Счет продавца

    SettlementDepositDate

    Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца

    NextStartingPoint

    Нуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение

    TransactionDetailSeq

    {TransactionDetail +}

    TransactionDetail

    См. табл. 4.6.2.54..

    В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID

    unspecified

    Неизвестное значение

    standard

    Стандартная скорость обмена

    keyEntered

    Скорость обмена для транзакций key-entered (ввод с клавиатуры)

    electronic

    Скорость обмена для электронных транзакций

    additionalData

    Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные

    enhancedData

    Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации).

    marketSpecific

    Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт).

    Продавец получает и обрабатывает BatchAdminRes следующим образом.

    Шаг

    Действие

    1

    Извлекается отклик BatchAdminRes из входного сообщения.

    2

    Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed.

    3

    Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID.

    4

    Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны.

    5

    Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы.

    6

    Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin.

    7

    Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца.

    Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet (http://www.microsoft.com/commerce/wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$.

    Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash (http://www.digicash.nl) или Millicent - http://www.millicent.digital.com/). Схема First Virtual (http://www.fv.com) предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон.

    Система CyberCash (http://www.cybercash.com) базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши "оплатить". Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций.

    Previous: 4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8


    previous up down next index index
    Previous: 4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 5 Диагностика локальных сетей и Интернет

    4.6.4 Смарт-карты EMV
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Спецификация карты ICC (Integrated Circuit Card)

    В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.

    IEC 512-2:1979

    Спецификации для электромеханических компонентов оборудования - Часть 2: Тесты сопротивления контактов, тесты проверки изоляции и перегрузок

    FIPS Pub 180-1:1995

    Стандарт на безопасные хэши. Спецификация терминала платежных систем для карт с интегральными схемами

    ISO 639:1988

    Коды названий языков

    ISO 3166:1997

    Коды названий стран

    ISO 4217:1995

    Коды валют и фондов

    ISO/IEC 7811-1:1995

    Идентификационные карты - Метод записи - Часть 1: Тиснение

    ISO/IEC 7811-3:1995

    Идентификационные карты - Метод записи - Часть 3: Положение вытисненных символов на картах ID-1

    ISO/IEC 7813:1995

    Идентификационные карты - Карты для финансовых операций

    ISO/IEC DIS 7816-1:1998

    Идентификационные карты - Карты с интегральными схемами, имеющими внешние контакты.

    Часть 1:

    Физические характеристики ISO/IEC DIS 7816-2:1998

    Часть 2:

    Размеры и положение контактов

    ISO/IEC 7816-3:1989

    Часть 3:

    Электрические сигналы и протоколы передачи

    ISO/IEC 7816-3:1992

    Часть 3:

    Протокол типа T=1, асинхронный полудуплексный протокол блочной передачи

    ISO/IEC 7816-3:1994

    Часть 3:

    Выбор типа протокола

    ISO/IEC 7816-4:1995

    Часть 4:

    Команды обмена

    ISO/IEC 7816-5:1994

    Часть 5:

    Процедура для выработки прикладных идентификаторов

    ISO/IEC 7816-6:1996

    Часть 6:

    Информационные элементы

    ISO 8731-1:1987

    Часть 1:

    Алгоритмы аутентификации сообщений (DEA)

    ISO 8372:1987

    Обработка информации. Режимы работы для 64-битовых блочных алгоритмов шифрования/дешифрования

    ISO/IEC 8825:1990

    Информационная технология. Соединение открытых систем. Спецификация базовых правил кодирования для синтаксической нотации ASN.1

    ISO 8583:1987

    Сообщения банковских карт - Спецификации сообщений - Содержимое финансовых транзакций

    ISO 8583:1993

    Сообщения транзакций банковских карт - Спецификации сообщений

    ISO 8859:1987

    Обработка сообщений - 8-битовые графические символьные наборы

    ISO/IEC 9796-2: 1997

    Информационная технология - Методы безопасности - Схема восстановления сообщений с цифровой подписью. Часть 2: Механизм использования хэш-функций

    ISO/IEC 9797:1994

    Информационная технология - Методы безопасности - Механизм информационной целостности, использующий функцию криптографической проверки на базе алгоритма блочного шифра

    ISO/IEC 10116: 1997

    Информационная технология - режимы работы алгоритмов n-битовых блочных шифров

    ISO/IEC 10118-3: 1998

    Информационная технология - Методы безопасности - хэш-функции

    Рис. 4.6.4.1. Расположение контактов на лицевой стороне карты

    Рис. 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм)

    Всего на карте 8 контактов. На рис. 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В.

    Таблица 4.6.4.1.

    Контакт

    Назначение

    Контакт

    Назначение

    С1

    VCC - напряжение питания

    С5

    GND - земля

    С2

    RST - сброс

    С6

    Не используется

    С3

    CLK - тактовые импульсы

    С7

    Вход/Выход (I/O)

    VCC - напряжение питания 5 ╠ 0,5В при токе 50 мА при любых частотах работы микросхемы.

    В таблице 4.6.4.2 представлены параметры входных информационных сигналов

    VIH- Высокий уровень входного сигнала
    VIL- Низкий уровень входного сигнала
    VOH- Высокий уровень выходного сигнала
    VOL- Низкий уровень выходного сигнала
    tR- Время нарастания сигнала
    tF- Время спада сигнала

    Таблица 4.6.4.2

     

    Минимум

    Максимум

    VIH

    0,7xVcc

    Vcc

    VIL

    0

    0,8 В

    tR и tF

    -

    1,0 мксек

    Если передача не осуществляется, состояние драйвера ICC должно соответствовать режиму приема. В таблице 4.6.4.3 представлены параметры выходных информационных сигналов

    Таблица 4.6.4.3

     

    Условия

    Минимум

    Максимум

    VOH

    -20мкА<IOH<0, Vcc= min

    0,7xVcc

    Vcc

    VOL

    0< IOL < 1мА, Vcc = min

    0

    0,4 В

    tR и tF

    C IN(терминала) =30пФ макс

    -

    1,0 мксек

    В таблице 4.6.4.4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц.

    Таблица 4.6.4.4

     

    Минимум

    Максимум

    VIH

    Vcc-0,7В

    Vcc

    VIL

    0

    0,5 В

    tR и tF

    -

    9% тактового периода

    В таблице 5 представлены характеристики сигнала сброса (RST).

    Таблица 4.6.4.5

     

    Минимум

    Максимум

    VIH

    Vcc-0,7В

    Vcc

    VIL

    0

    0,6 В

    tR и tF

    -

    1,0 мксек

    ICC выдерживает уровни сигнала на шине RST от -0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно. Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек.

    Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства.

    После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ╠0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на рис. 4.6.4.3.

    Рис. 4.6.4.3. Последовательность активации контактов ICC

    Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.

    Рис. 4.6.4.4. Диаграмма реализации "холодного" сброса

    После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте. Диаграмма холодного сброса ICC показана на рис. 4.6.4.4.

    Команда сброса может поступать и в процессе обычной работы - так называемый "теплый" сброс. Временная диаграмма такого сброса показана на рис. 4.6.4.5.

    Рис. 4.6.4.5. Временная диаграмма "теплого" сброса

    Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0') на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1' шина RST переходит в состояние H, после чего завершается процедура сброса аналогично "холодному" варианту.

    Процедура деактивации контактов ICC показана на рис. 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc становится равным нулю и процедура в пределах 100 мсек завершается. При гальваническом отключении контактов Vcc должно быть не более 0,4 В. По завершении процедуры карта может быть извлечена из интерфейсного устройства.

    Рис. 4.6.4.6. Временная диаграмма дезактивации контактов ICC

    Исходная длительность такта на шине I/O определяется как:

    t = 372/f секунд,

    где f частота в Гц. В общем случае t определяется как:

    t = F/(Df),

    где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.

    Рис. 4.6.4.7. Диаграмма передачи символов по шине I/O

    Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O. Время стробирования составляет 0,2 t. Время между началами передачи последовательных символов составляет t(10╠0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H).

    Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации.

    В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке.

    На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов.

    При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров.

    ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6.

    Таблица 4.6.4.6. Базовый ATR для T=0

    Символ

    Значение

    Примечания

    TS

    3B или 3F

    Указывает на прямую или инверсную схему передачи бит

    T0

    6x

    Присутствуют TB1 и TC1; х обозначает число исторических байтов

    TB1

    00

    VPP не требуется

    TC1

    00 - FF

    Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

    Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола.

    Таблица 4.6.4.7. Базовый ATR для T=1

    Символ

    Значение

    Примечания

    TS

    3B или 3F

    Указывает на прямую или инверсную схему

    T0

    Ex

    Присутствуют TB1 - TD1; х обозначает число исторических байтов

    TB1

    00

    VPP не требуется

    TC1

    00 - FF

    Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

    TD1

    81

    TA2 - TC2 отсутствуют; TD2 присутствует; должен работать протокол T=1

    TD2

    31

    TA3 и TB2 присутствуют; TC3 и TD3 отсутствуют; должен работать протокол T=1

    TA3

    10 - FE

    Возвращает IFSI, что указывает на начальное значение размера информационного поля для ICC и IFSC равное 16-254 байтам

    TB3

    Старший полубайт =0-4
    Младший полубайт =0-5

    BWI = 0-4
    CWI = 0-5

    TCK

     

    Контрольный символ

    Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32.

    TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации.

    ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений:
    (H)LHHLLLLLLH - инверсная схема, значение 3F.
    (H)LHHLHHHLLH - прямая схема, значение 3B
    Последний бит этих кодов Н является битом четности (смотри рис. 4.6.4.7).

    T0 - символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15). Смотри таблицу 4.6.4.8.

    Таблица 4.6.4.8

     

    b8

    b7

    b6

    b5

    b4

    b3

    b2

    b1

    Только Т=0

    0

    1

    1

    0

    X

    X

    X

    X

    Только Т=1

    1

    1

    1

    0

    X

    X

    X

    X

    Символы интерфейса TA1-TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола.

    TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1.

    Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D.

    ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0.

    TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t.

    TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 - TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов.

    ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2.

    Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно. Базовый отклик ATR не содержит ТА2.

    ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует.

    ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А.

    TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 - TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 - TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1).

    ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается.

    ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) - BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший - 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4. Формат ТВ3 показан в таблице 4.6.4.9.

    Таблица 4.6.4.9

     

    b8

    b7

    b6

    b5

    b4

    b3

    b2

    b1

    Только Т=1

    0

    X

    X

    X

    0

    Y

    Y

    Y

    XXX лежит в интервале 000-100, а YYY - 000-101

    Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1).

    TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 - не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3.

    ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК.

    Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует "теплый" сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации.

    Если во время отклика на холодный или теплый сброс интервал между двумя последовательными символами превысит 9600t, терминал прерывает сессию путем инициализации дезактивации спустя 14400t после стартового бита последнего полученного символа.

    Если отклик на холодный или теплый сброс не завершился в пределах 19200t , терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты.

    Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации.

    4.6.4.1. Команды

    Команды всегда инициируются прикладным уровнем терминала TAL (Terminal Application Layer), который посылает инструкции ICC через транспортный уровень TTL (Terminal Transport Layer). Команда содержит последовательность из 5 байт: CLA, INS, P1, P2 и P3.

    Имя байта

    Назначение

    CLA

    Класс команды (1 байт).

    INS

    Код инструкции (1 байт).

    P1 и P2

    Cодержат дополнительные специфические параметры (по 1 байту).

    Р3

    Указывает либо длину посылаемых в команде данных, либо максимальную длину данных, которые должны быть присланы в отклике от ICC (зависит от кода INS).

    Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0.

    Получив команду, ICC откликается отправкой процедурного или статусных байтов. Процедурный байт указывает TTL, какая операция является следующей. Отклик терминала на процедурный байт представлен в таблице 4.6.4.10.

    Таблица 4.6.4.10. Отклик терминала на процедурный байт

    Значение процедурного байта

    Действие терминала

    Байт равен INS

    Все остальные байты данных будут переданы TTL, или TTL будет готов принять все остальные байты от ICC

    Байт равен дополнению INS

    Следующий байт данных будет передан TTL или TTL будет готов принять следующий байт от ICC

    60

    TTL введет дополнительное время выдержки (Work Waiting Time)

    61

    TTL будет ждать следующий процедурный байт, затем пошлет ICC команду GET RESPONSE с максимальной длиной "xx", где хх равно значению второго процедурного байта

    6C

    TTL будет ждать следующий процедурный байт, после чего немедленно повторно пошлет ICC предыдущий командный заголовок, используя длину "xx", где хх равно значению второго процедурного байта

    Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения.

    Командное сообщение, посылаемое от прикладного уровня, и сообщение-отклик ICC называются APDU (Application Protocol Data Unit). Формат APDU показан на рисунке 4.6.4.8.

    Рис. 4.6.4.8. Структура командного APDU.

    Все поля заголовка имеют по одному байту. Поле данных содержит Lc байт.

    Lc

    Число байт в поле данные (0 или 1 байт)

    Le

    Максимальное число байт в поле данных отклика (0 или 1 байт)

    Если параметры Р1 и Р2 не используются, коды полей должны равняться 00.

    Формат отклика APDU аналогичен показанному на 4.6.4.8.

    Поле данных имеет переменную длину и, вообще говоря, может отсутствовать. Однобайтовые поля SW1 и SW2 должны присутствовать обязательно. SW1 характеризует состояние обработки команды, а SW2 - является квалификатором обработки команды.

    Кодировка команд для полей CLA и INS представлена в таблице 4.6.4.11.

    Таблица 4.6.4.11. Кодирование командного байта

    CLA

    INS

    Назначение

    APPLICATION BLOCK (Заблокировать приложение)

    18

    APPLICATION UNBLOCK (Разблокировать приложение)

    16

    CARD BLOCK (Заблокировать карту)

    82

    EXTERNAL AUTHENTICATE (Внешняя аутентификация)

    АЕ

    GENERATE APPLICATION CRYPTOGRAM (Сформировать прикладную криптограмму)

    84

    GET CHALLENGE (Получить вызов)

    СА

    GET DATA (Получить данные)

    А8

    GET PROCESSING OPTIONS (Получить опции обработки)

    88

    INTERNAL AUTHENTICATE (Внутренняя аутентификация)

    24

    PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK - изменение/разблокировка персонального идентификатора

    В2

    READ RECORD (Прочесть запись)

    А4

    SELECT (Выбор)

    20

    VERIFY (Проверка)

    Dx

    RFU для платежных систем

    Ex

    RFU для платежных систем

    Xx

    RFU производителя для кодирования INS собственника

    Ех

    xx

    RFU эмитента для кодирования INS собственника

    Статусные байты SW1 и SW2 указывают TTL, что обработка команды завершена. Значения этих байт интерпретируются в зависимости от обрабатываемой команды. Коды и значения полей SW1 и SW2 представлены в таблице 4.6.4.12.

    Таблица 4.6.4.12. Кодирование статусных байтов SW1, SW2

    SW1

    SW2

    Значение

    90

    00

    Нормальная обработка
    Процесс завершился успешно


    62
    63
    63


    83

    00

    Сх

    Обработка с предупреждением
    Состояние постоянной памяти не изменилось; выбранный файл некорректен
    Состояние постоянной памяти изменилось; аутентификация не прошла
    Состояние постоянной памяти изменилось; счетчик задан "x" (0-15)


    69
    69
    69



    83
    84
    85
    81
    82
    83

    Контроль ошибок
    Команда не разрешена; метод аутентификации блокирован
    Команда не разрешена; запрошенные данные некорректны
    Команда не разрешена; условия использования не выполнены
    Неверные параметры Р1 Р2; функция не поддерживается
    Неверные параметры Р1 Р2; файл не найден
    Неверные параметры Р1 Р2; запись не найдена

    Таблица 4.6.4.12А. Сводные данные по командам/откликам

    Команда

    CLA

    INS

    P1

    P2

    Lc

    Данные

    Le

    APPLICATION BLOCK

    8C/84

    1E

    00

    00

    Число байт данных

    Код аутенти-фикации сообщения (MAC)

    -

    APPLICATION UNBLOCK

    8C/84

    18

    00

    00

    Число байт данных

    Компонент MAC

    -

    CARD BLOCK

    8C/84

    16

    00

    00

    Число байт данных

    Компонент MAC

    -

    EXTERNAL AUTHENTICATE

    00

    82

    00

    00

    8-16

    Issue Authentication Data

    -

    GENERATE APPLICATION CRYPTOGRAM

    80

    AE

    Парам.
    ссылки

    00

    Перемен.

    Данные транзакции

    00

    GET DATA

    80

    CA

    9F36

    9F13

    9F17

    9F36

    9F13

    9F17

    -

    -

    00

    GET PROCESSING OPTIONS

    80

    A8

    00

    00

    Перемен.

    Processing Option Data Object List (PDOL)

    00

    INTERNAL AUTHENTICATE

    00

    88

    00

    00

    Длина аутент. данных

    Аутентиф. данные

    00

    PIN CHANGE/UNBLOCK

    8C/84

    24

    00

    00, 01 или 02

    Число байт данных

    PIN данные

    -

    READ RECORD

    00

    B2

    Номер записи

    Парам.

    ссылки

    -

    -

    00

    SELECT

    00

    A4

    Парам.
    ссылки

    Опции выбора

    05-10

    Имя файла

    00

    VERIFY

    00

    20

    00

    Квали-фикатор

    Перемен

    PIN данные транзакции

    -

    GET CHALLENGE

    00

    84

    00

    00

    -

    -

    00

    Блочный протокол Т=1 предполагает передачу блоков данных между TAL (Terminal Application Layer) и ICC. Эти блоки несут в себе команды, R-APDU (Response Application Protocol Data Unit) и управляющую информацию. Структура блока показана на рисунке 4.6.4.10. Поля заголовка и эпилога (хвостовика) являются обязательными. Биты b1-b3 NAD указывают на адрес отправителя (SAD), а b5-b7 - адрес получателя (DAD). В настоящее время адресация узлов не поддерживается и по этой причине в поле NAD следует записывать код 00. Биты b4 и b8 равны нулю. Код PCB определяет тип блока. Существует три типа блоков: информационные (I-блок), готовности приема (R-блок, подтверждение) и управляющие (S-блок).

    Заголовок (Prologue)

    Данные

    Эпилог

    Адрес узла (NAD)

    Управляющий протокольный байт (PCB)

    Длина
    (LEN)
     

    APDU или управляющая информация (INF)

    EDC
    (код детектирования ошибки)

    1 байт

    1 байт

    1 байт

    0-254 байта

    1 байт

    Рис. 4.6.4.9. Структура блока

    Кодирование PCB зависит от его типа, оно представлено в таблицах 4.6.4.13-15.

    Таблица 4.6.4.13. Кодирование PCB I-блоков

    b8

    0

    b7

    Номер по порядку

    b6

    Цепочка (есть еще данные)

    b5-b1

    Зарезервировано на будущее

    Таблица 4.6.4.14. Кодирование PCB R-блоков

    b8

    1

    b7

    0

    b6

    0

    b5

    Номер по порядку

    b4-b1

    0 - Отсутствие ошибки
    1 - EDC и/или ошибка четности
    2 - другие ошибки
    остальные коды зарезервированы

    Таблица 4.6.4.15. Кодирование PCB S-блоков

    b8

    1

    b7

    1

    b6

    0 - запрос
    1 - отклик

    b5-b1

    0 - запрос повторной синхронизации
    1 - запрос размера поля данных
    2 - запрос абортирования
    3 - расширение BWT-запроса
    4 - VPP-ошибка
    остальные коды зарезервированы

    Поле LEN определяет размер информационного поля и может равняться 0-254. R-блоки не имеют поля данных. Блоки I- и S-типов нумеруются по модулю 2, их число может равняться 0 или 1 (первый блок имеет номер 0). Счетчик нумерации сбрасывается в 0 после ресинхронизации.

    Поле EDC представляет собой объединение всех байт блока, начиная с NAD и кончая последним байтом поля INF (если это поле присутствует), с помощью операции исключающее ИЛИ.

    Максимальный размер поля данных ICC (IFSC) блока определяется параметром ТА3, присылаемым ICC в отклике на сброс. IFSI может принимать значения 10-FE, что означает для IFSC диапазон 16-254 байта. Максимальный размер поля данных терминала (IFSD) составляет 254 байта.

    Время ожидания блока BWT (Block Waiting Time) в общем случае вычисляется согласно следующей формуле. Реально BWT может лежать в диапазоне (971-15371)t.

    Когда отправитель намерен передать объем данных больше, чем это определено параметрами IFSC или IFSD, он должен разбить эту последовательность байтов на несколько I-блоков. Передача этих блоков осуществляется с привлечением механизма цепочек. Для объединения I-блоков в цепочку используется бит b6 в PCB (смотри табл. 4.6.4.13). Если b6=0, то это последний блок в цепочке. Если же b6=1, далее следует как минимум еще один блок. Получение любого I-блок с b6=1 должно быть подтверждено R-блоком. Последний блок цепочки, посланный терминалом, подтверждается I-блоком, если получен безошибочно, или R-блоком, при обнаружении ошибки. В случае ICC получение последнего блока цепочки подтверждается R-блоком при обнаружении ошибки. Если ошибки не было, терминал просто посылает очередной I-блок, если должна обрабатываться очередная команда. Передача цепочки возможна в одно и тоже время только в одном направлении. Когда терминал является получателем, он воспринимает цепочки I-блоков, передаваемых ICC, если длина блоков ≤ IFSD. Если получателем является ICC, карта воспринимает цепочку I-блоков, посланных терминалом и имеющих длину LEN=IFSC, за исключением последнего блока, длина которого может лежать в диапазоне (1-IFSC). Если длина блока > IFSC, ICC такой блок отвергает, послав R-блок с битами b4-b1 в PCB, равными 2.

    4.6.4.2. Элементы данных и файлы

    Приложение в ICC содержит набор информационных элементов. Терминал может получить доступ к этим элементам после успешного выбора приложения. Информационным элементам присваиваются имена, они имеют определенное описание содержимого, формат и кодирование. Информационный объект состоит из метки (tag), кода длины и значения. Метка однозначно идентифицирует объект в рамках данного приложения. Поле длина определяет число байт в поле значение. Объекты могут объединяться, образуя составные объекты. Определенное число простых или составных объектов могут образовывать записи. Присвоение меток регламентируется документами ISO/IEC 8825 и ISO/IEC 7816. Записи, содержащие информационные объекты, хранятся в файлах ICC. Структура файла и метод доступа зависят от назначения файла. Организация файлов определяется приложениями платежной системы PSA (Payment System Application). Проход к набору PSA в ICC разрешается с помощью выбора среды платежной системы PSE (Payment System Environment). Когда PSE присутствует, файлы, относящиеся к PSA, доступны для терминала через древовидную структуру каталога. Каждая ветвь этого дерева является файлом определения приложения ADF (Application Definition File) или файлом определения каталога DDF (Directory Definition File). ADF является входной точкой одного или нескольких прикладных первичных файлов AEF (Application Elementary File). ADF со стороны терминала воспринимается как файл, содержащий информационные объекты, которые инкапсулированы в FCI (File Control Information). Информационные файлы состоят из последовательности пронумерованных записей. Каждому файлу присваивается короткий идентификатор SFI (принимает значения 1-10), с помощью которого можно обращаться к файлу. Чтение каталога осуществляется с помощью команды READ RECORD.

    Когда PSE присутствует, ICC поддерживает структуру каталога для списка приложений в пределах PSE (определяется эмитентом карты). Каждому приложению присваивается идентификатор AID (Application Identifier; ISO/IEC 7816-5). К любому ADF или DDF в карте обращение производится посредством имени DF (Dedicated File). DF для ADF соответствует AID и для данной карты должно быть уникальным. Формат записи каталога PSE показан на рисунке 4.6.4.11.

    Метка

    70

    Длина
    данных
    (L)

    Метка
    61

    Длина элемента 1 каталога

    Элемент каталога 1 (ADF или DDF)

    .
    .
    .

    Метка
    61

    Длина элемента N каталога

    Элемент каталога N (ADF или DDF)

    Рис. 4.6.4.11. Формат записи каталога PSE

    Содержимое полей элемент каталога характеризуется в таблицах 4.6.4.16 и 4.6.4.17.

    Таблица 4.6.4.16. Формат элемента каталога DDF

    Метка (Tag)

    Длина

    Значение

    9D

    5-16

    Имя DDF

    73

    переменная

    Шаблон каталога

    Таблица 4.6.4.17. Формат элемента каталога ADF

    Метка (Tag)

    Длина

    Значение

    0х4F

    5-16

    Имя ADF (AID)

    0х50

    1-16

    Метка приложения

    0х9F12

    1-16

    Предпочитаемое имя приложения

    0х87

    1

    Индикатор приоритетности приложения

    0х73

    переменная

    Шаблон каталога

    Понятно, что в области, где используются карты ICC, наиболее важными являются аспекты безопасности.

    4.6.4.3. Соображения безопасности

    1. Статическая аутентификация данных

    Статическая аутентификация выполняется терминалом, использующим цифровую подпись, которая базируется на методике общедоступных ключей. Эта техника позволяет подтвердить легитимность некоторых важных данных, записанных в ICC и идентифицируемых с помощью AFL (Application File Locator).

    Статическая аутентификация требует существования сертификационного сервера (или центра), который имеет надежную защиту и способен подписывать общедоступные ключи эмитента карты. Каждый терминал должен содержать общедоступный ключ центра сертификации для каждого приложения, распознаваемого терминалом. Взаимодействие клиента, центра сертификации и эмитента карты показано на рисунке 4.6.4.12.

    Рис. 4.6.4.12. Диаграмма статической аутентификации данных

    Карта ICC, которая поддерживает статическую аутентификацию данных, должна содержать следующие информационные элементы.

    • Индекс общедоступного ключа сертификационного цента. Это однобайтовый элемент, содержащий двоичное число, которое указывает на общедоступный ключ и связанный с ним алгоритм сертификационного центра приложения. Этот ключ хранится в терминале и должен использоваться с данной картой.
    • Сертификат общедоступного ключа эмитента карты. Этот элемент имеет переменную длину и предоставляется центром сертификации эмитенту карты.
    • Подписанные данные приложения. Информационный элемент переменной длины, формируемый эмитентом карты с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате эмитента.
    • Остаток (remainder) общедоступного ключа эмитента. Опционный элемент переменной длины ICC.
    • Показатель степени общедоступного ключа эмитента. Информационный элемент переменной длины, предоставляемый эмитентом карты.

    Для поддержки статической аутентификации ICC должна содержать статические прикладные данные, подписанные секретным ключом эмитента. Общедоступный ключ эмитента записывается в ICC вместе с сертификатом общедоступного ключа. Модуль общедоступного ключа сертификационного ключа имеет NCA байт, где NCA ≤ 248, показатель степени этого ключа равен 2, 3 или 216+1.

    Общедоступный ключ эмитента имеет модуль ключа, содержащий NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части. Одна часть, состоящая из NCC -36 старших байт модуля (левые цифры общедоступного ключа эмитента), и вторая часть с оставшимися NЭ - (NCC - 36) младшими байтами. Показатель степени общедоступного ключа эмитента должен быть равен 2, 3 или 216+1.

    Вся необходимая информация, необходимая для статической аутентификации записывается в ICC (смотри таблицу 4.6.4.18 и 4.6.4.19). За исключением RID (Registered Application Provider Identifier), который может быть получен из AID (Application Identifier), эта информация может быть получена посредством команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

    Таблица 4.6.4.18. Данные, сопряженные с общедоступным ключом эмитента, которые должны быть подписаны центром сертификации.

    Имя поля

    Длина
    (байт)

    Описание

    Формат сертификата

    1

    Шестнадцатеричное число 0х02

    Идентификационный номер эмитента

    4

    Левые 3-8 цифр номера первичного счета PAN (Primary Account Number)

    Дата истечения действительности сертификата

    2

    MMГГ, после которых данный сертификат не действителен

    Серийный номер сертификата

    3

    Двоичное число уникальное для сертификата сертификационного центра

    Индикатор хэш-алгоритма

    1

    Идентифицирует хэш-алгоритм, используемый для получения электронной подписи

    Индикатор алгоритма общедоступного ключа эмитента

    1

    Идентифицирует алгоритм цифровой подписи, используемый с общедоступным ключом эмитента

    Длина общедоступного ключа эмитента

    1

    Идентифицирует длину модуля общедоступного ключа эмитента в байтах

    Длина показателя общедоступного ключа эмитента

    1

    Идентифицирует длину показателя общедоступного ключа эмитента в байтах

    Общедоступный ключ эмитента или левые цифры этого ключа

    NCC - 36

    Если NЭ ≤ NCC -36, это поле состоит из общедоступного ключа эмитента дополненного справа NCC - 36 - NЭ байтами, равными BB.

    Если NЭ > NCC -36, это поле состоит из NCC - 36 старших байт общедоступного ключа эмитента

    Остаток общедоступного ключа эмитента

    0 или
    NЭ - NCC + 36

    Это поле присутствует, только если NЭ > NCC -36, оно состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента

    Показатель общедоступного ключа эмитента

    1 или 3

    Показатель общедоступного ключа эмитента, равный 2, 3 или 216+1.

    Таблица 4.6.4.19. Статическая прикладная информация, подписываемая эмитентом

    Имя поля

    Длина
    (байт)

    Описание

    Формат подписанных данных

    1

    Шестнадцатеричное число 0х03

    Индикатор хэш-алгоритма

    1

    Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи

    Код аутентификации данных

    2

    Код, присвоенный эмитентом

    Код заполнителя

    NЭ - 26

    Код байта заполнителя, равный 0хBB

    Статические данные, подлежащие аутентификации

    Перемен-ная

    Статические данные, которые подлежат аутентификации согласно требованиям приложения ICC

    Таблица 4.6.4.20. Информационные объекты, необходимые для аутентификации статических данных

    Метка (Tag)

    Длина

    Значение

    -

    5

    Зарегистрированный идентификатор провайдера приложения (RID)

    0х8F

    1

    Индекс общедоступного ключа сертификационного центра

    0х90

    NCC

    Сертификат общедоступного ключа эмитента

    0х92

    NЭ - NCC + 36

    Остаток общедоступного ключа эмитента (если присутствует)

    0х9F32

    1 или 3

    Показатель общедоступного ключа эмитента

    0х93

    NЭ

    Подписанные статические прикладные данные

    -

    Переменная

    Статические данные, которые должны быть аутентифицированы

    Терминал считывает индекс общедоступного ключа сертификационного центра. Используя этот индекс и RID, терминал идентифицирует и извлекает из своей памяти модуль и показатель общедоступного ключа сертификационного центра, а также сопутствующую информацию, определяет алгоритм обработки. Если какой-то из перечисленных компонентов отсутствует, аутентификация не состоится.

    Если сертификат общедоступного ключа эмитента имеет длину отличную от модуля общедоступного ключа сертификационного центра, то аутентификация не пройдет.

    Для того чтобы получить данные, представленные в таблице 4.6.4.21, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных сообщения не равен BC, аутентификация не удалась.

    Таблица 4.6.4.21. Формат восстановленных данных сертификата общедоступного ключа эмитента

    Имя поля

    Длина
    (байт)

    Описание

    Заголовок восстановленных данных

    1

    Шестнадцатеричное число 0х6A

    Формат сертификата

    1

    Шестнадцатеричное число 0х02

    Идентификационный код эмитента

    4

    Левые 3-8 цифр РАN, дополняемые справа кодами 0хF

    Дата истечения действия сертификата

    2

    Дата ММГГ, после которой сертификат становится недействительным

    Серийный номер сертификата

    1

    Двоичное число уникальное для сертификата, выданного центром сертификации

    Индикатор хэш-алгоритма

    1

    Идентифицирует хэш-алгоритм, используемый для получения кода поля результата хэширования при вычислении электронной подписи

    Индикатор алгоритма общедоступного ключа эмитента

    1

    Идентифицирует алгоритм цифровой подписи, который должен быть использован совместно с общедоступным ключом эмитента

    Длина общедоступного ключа эмитента

    1

    Идентифицирует длину модуля общедоступного ключа эмитента в байтах

    Длина показателя общедоступного ключа эмитента

    1

    Идентифицирует длину показателя степени общедоступного ключа эмитента в байтах

    Общедоступный ключ эмитента или левые цифры общедоступного ключа эмитента

    NCC - 36

    Если NЭ ≤ NCC - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NCC - 36 - NЭ байтами, содержащими код BB.
    Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байт общедоступного ключа эмитента

    Результат хэширования

    20

    Хэш-код общедоступного ключа эмитента и сопряженной с ним информации

    Хвостовик восстановленных данных

    1

    Шестнадцатеричное число 0хВС

    Проводится проверка заголовка восстановленных данных и, если он не равен 0х6А, аутентификация аннулируется.

    Проверяется поле формат сертификата и, если его код не равен 0х02, аутентификация отвергается.

    Далее объединяются слева направо, начиная со второго и кончая десятым, информационные элементы, представленные в таблице 4.6.4.21 (от поля формат сертификата до общедоступного ключа эмитента или левых цифр этого ключа), к результату добавляется хвостовик общедоступного ключа эмитента (если он имеется) и показатель этого ключа.

    Результат данного объединения подвергается хэшированию согласно заданному алгоритму. Полученный результат сравнивается со значением поля результат хэширования (см. табл. 4.6.4.21). Если совпадения нет, аутентификация не состоялась.

    Проверяется, что идентификационный номер эмитента соответствует левым цифрам 3-8 PAN. При несоответствии аутентификация отвергается.

    Проверяется, не закончился ли срок действия сертификата. Если срок истек, аутентификации не происходит.

    Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации, серийного номера сертификата является корректным, в противном случае аутентификация не проходит.

    Если не распознан индикатор алгоритма общедоступного ключа эмитента, аутентификация также не пройдет. Если все предыдущие проверки прошли успешно, то производится объединение левых цифр общедоступного ключа эмитента и его остатка (если таковой имеется) с целью получения модуля общедоступного ключа эмитента, после чего процесс переходит в следующую фазу проверок подписанных статических прикладных данных.

    Если подписанные статические прикладные данные имеют длину, отличную от длины модуля общедоступного ключа эмитента, аутентификация не состоится.

    Для того чтобы получить данные, представленные в таблице 4.6.4.22, берутся подписанные статические прикладные данные и общедоступный ключ эмитента. Если хвостовик восстановленных данных окажется не равным BC, аутентификация отвергается.

    Таблица 4.6.4.22. Формат восстановленных данных из подписанных статических прикладных данных.

    Имя поля

    Длина
    (байт)

    Описание

    Заголовок восстановленных данных

    1

    Шестнадцатеричное число 0х6А

    Формат подписанных данных

    1

    Шестнадцатеричное число 0х03

    Индикатор хэш-алгоритма

    1

    Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи

    Код данных аутентификации

    2

    Код, присвоенный эмитентом

    Код заполнителя

    NЭ - 26

    Код байтов заполнителя, равный 0хBB

    Результат хэширования

    20

    Хэш статических прикладных данных, которые должны быть аутентифицированы

    Хвостовик восстановленных данных

    1

    Шестнадцатеричное число 0хВС

    Проверяется заголовок восстановленных данных и, если он не равен 0х6A, аутентификация не проходит.

    Проверяется формат подписанных данных и, если его код не равен 0х03, аутентификация не проходит.

    Объединяются информационные элементы, начиная со второго по пятый (см. табл. 4.6.4.22), добавляются данные, подлежащие аутентификации, после чего вычисляется хэш. Полученный результат сравнивается со значением поля результата хэширования. При несовпадении аутентификация терпит неудачу. Если все предшествующие проверки прошли успешно, данные считаются аутентифицированными.

    4.6.4.4. Динамическая аутентификация данных

    Динамическая аутентификация данных выполняется терминалом, с использованием цифровой подписи, базирующейся на технике общедоступного ключа, и имеет целью аутентифицировать ICC и подтвердить легитимность динамической информации, записанной на ICC. Динамическая аутентификация требует наличия центра аутентификации, который подписывает общедоступные ключи эмитента. Каждый терминал должен иметь общедоступные ключи сертификационного центра для каждого приложения, распознаваемого терминалом. Схема аутентификации динамических данных показана на рис. 4.6.4.12.

    Рис. 4.6.4.12. Схема динамической аутентификации данных

    ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.

    • Индекс общедоступного ключа сертификационного центра. Этот элемент состоит из одного байта, который указывает, какой из общедоступных ключей сертификационного центра и алгоритм, доступный терминалу, следует использовать с данной картой ICC.
    • Сертификат общедоступного ключа эмитента. Этот элемент переменной длины записывается в ICC эмитентом карты. Когда терминал проверяет этот элемент, он аутентифицирует общедоступный ключ и сопутствующие данные ICC.
    • Остаток общедоступного ключа эмитента.
    • Показатель общедоступного ключа эмитента.
    • Остаток общедоступного ключа ICC.
    • Показатель общедоступного ключа ICC.
    • Секретный ключ ICC. Элемент переменной длины, используемый для формирования подписанных динамических прикладных данных.

    ICC, которые поддерживают аутентификацию динамических прикладных данных, должны сформировать следующий информационный элемент.

    Подписанные динамические прикладные данные. Этот информационный элемент переменной длины формируется ICC с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате общедоступного ключа ICC.

    Чтобы поддерживать аутентификацию динамических данных, каждый терминал должен запоминать большое число общедоступных ключей сертификационного центра, и ставить им в соответствие информацию, которая должна использоваться с этими ключами. Терминал способен найти любой такой ключ, заданный RID и индексом общедоступного ключа сертификационного центра, полученных от ICC.

    ICC, поддерживающая аутентификацию динамических данных должна иметь пару ключей, один из которых является секретным, служащим для цифровой подписи, другой - общедоступный для верификации. Общедоступный ключ ICC запоминается ИС картой в сертификате общедоступного ключа, сформированном эмитентом карты. Общедоступный ключ эмитента сертифицирован центром сертификации. Как следствие для верификации подписи ICC терминал должен сначала верифицировать два сертификата, для того чтобы получить и аутентифицировать общедоступный ключ ICC, который далее служит для проверки корректности динамической подписи ICC.

    Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ≤ 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC - 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ - (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1.

    Модуль общедоступного ключа ICC содержит NIC байт, где NIC ≤ 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна - состоит из NЭ - 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC - (NЭ - 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1.

    Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC. За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

    Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.

    Имя поля

    Длина
    (байт)

    Описание

    Формат сертификата

    1

    Шестнадцатеричное число 0х02

    Идентификационный номер эмитента

    4

    Левые 3-8 цифр от PAN (дополняемые справа кодами 0хF)

    Дата истечения времени действия сертификата

    2

    Дата ММГГ, после которой сертификат становится недействительным

    Серийный номер сертификата

    3

    Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации

    Индикатор хэш-алгоритма

    1

    Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи

    Индикатор алгоритма общедоступного ключа эмитента

    1

    Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента

    Длина общедоступного ключа эмитента

    1

    Идентифицирует длину модуля общедоступного ключа эмитента в байтах

    Длина показателя общедоступного ключа эмитента

    1

    Идентифицирует длину показателя общедоступного ключа эмитента в байтах

    Общедоступный ключ эмитента или левые цифры этого ключа

    NCC - 36

    Если NЭ ≤ NCC - 36, это поле состоит из полного общедоступного ключа эмитента дополненного справа NCC -36 - NЭ байт с кодом 0хBB.
    Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байтов общедоступного ключа эмитента

    Остаток общедоступного ключа эмитента

    0 или
    NЭ -NCC + 36

    Это поле присутствует только если NЭ > NCC - 36 и состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента

    Показатель общедоступного ключа эмитента

    1 или 3

    Показатель общедоступного ключа эмитента равен 2, 3 или 216+1

    Таблица 4.6.4.24. Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты

    Имя поля

    Длина
    (байт)

    Описание

    Формат сертификата

    1

    Шестнадцатеричное число 0х04

    PAN (Primary Application Number) приложения

    10

    PAN дополненный справа кодами 0хF

    Дата истечения времени действия сертификата

    2

    Дата ММГГ, после которой сертификат становится недействительным

    Серийный номер сертификата

    3

    Двоичное число, уникальное для данного сертификата, присваиваемое эмитентом

    Индикатор хэш-алгоритма

    1

    Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи

    Индикатор алгоритма общедоступного ключа ICC

    1

    Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC

    Длина общедоступного ключа ICC

    1

    Идентифицирует длину модуля общедоступного ключа ICC в байтах

    Длина показателя общедоступного ключа ICC

    1

    Идентифицирует длину показателя общедоступного ключа ICC в байтах

    Общедоступный ключ ICC или левые цифры этого ключа

    NЭ - 42

    Если NIC ≤ NЭ - 42, это поле состоит из полного общедоступного ключа ICC дополненного справа NЭ - 42 - NIC байт с кодом 0хBB.

    Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC

    Остаток общедоступного ключа ICC

    0 или

    NIC - NЭ + 42

    Это поле присутствует, только если NIC > NЭ - 42 и состоит из NЭ - N + 42 младших байт общедоступного ключа ICC

    Показатель общедоступного ключа ICC

    1 или 3

    Показатель общедоступного ключа ICC равен 2, 3 или 216+1

    Данные, подлежащие аутентификации

    Переменная

    Статические данные, подлежащие аутентификации согласно спецификации ICC для платежных систем

    Таблица 4.6.4.25. Информационные объекты, необходимые для аутентификации общедоступного ключа

    Метка (Tag)

    Длина
    (байт)

    Описание

    -

    5

    Зарегистрированный идентификатор провайдера приложения (RID)

    0х8F

    1

    Индекс общедоступного ключа центра сертификации

    0х90

    NCC

    Сертификат общедоступного ключа эмитента

    0х92

    NЭ - NCC + 36

    Остаток общедоступного ключа эмитента (если имеется)

    0х9F32

    1 или 3

    Показатель общедоступного ключа эмитента

    0х9F46

    NЭ

    Сертификат общедоступного ключа ICC

    0х9F48

    NIC - NЭ + 42

    Остаток общедоступного ключа ICC (если он имеется)

    0х9F47

    1 или 3

    Показатель общедоступного ключа ICC

    -

    Переменная

    Данные, подлежащие аутентификации

    Терминал считывает индекс общедоступного ключа центра сертификации. Используя этот индекс и RID, терминал может идентифицировать и извлечь из памяти модуль и показатель общедоступного ключа сертификационного центра и сопряженную с ним информацию. Если терминал не сможет найти нужные данные, сертификация не состоится.

    Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит.

    Для того чтобы получить восстановленные данные, представленные в таблице 4.6.4.26, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных не равен 0хBC, аутентификация динамических данных не проходит.

    Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается.

    Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается.

    Объединяются слева направо информационные элементы со второго по десятый (см. табл. 4.6.4.26), добавляется остаток общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Для полученной строки применяется соответствующий алгоритм хэширования. Сравнивается вычисленный хэш и восстановленное значение поля результата хэширования. При несовпадении аутентификация не проходит.

    Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.

    Имя поля

    Длина
    (байт)

    Описание

    Заголовок восстановленных данных

    1

    Шестнадцатеричное число 0х6А

    Формат сертификата

    1

    Шестнадцатеричное число 0х02

    Идентификационное число эмитента

    4

    Левые 3-8 цифр из PAN, дополненные справа кодами 0хF

    Дата истечения времени действия сертификата

    2

    Дата ММГГ, после которой сертификат становится недействительным

    Серийный номер сертификата

    3

    Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации

    Индикатор хэш-алгоритма

    1

    Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи

    Индикатор алгоритма общедоступного ключа эмитента

    1

    Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента

    Длина общедоступного ключа эмитента

    1

    Идентифицирует длину модуля общедоступного ключа эмитента в байтах

    Длина показателя общедоступного ключа эмитента

    1

    Идентифицирует длину показателя общедоступного ключа эмитента в байтах

    Общедоступный ключ эмитента или левые цифры этого ключа

    NCC - 36

    Если NЭ ≤ NСС - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NСС - 36 - NЭ байтами с кодом 0хBB.
    Если NЭ > NСС - 36, это поле состоит из NСС - 36 старших байтов общедоступного ключа эмитента

    Результат хэширования

    20

    Хэш общедоступного ключа эмитента и сопряженных данных

    Хвостовик восстановленных данных

    1

    Шестнадцатеричное число 0хВС

    Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается.

    Проверяется срок действия сертификата и, если он истек, аутентификация отвергается.

    Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации и серийного номера сертификата корректно.

    Если индикатор алгоритма общедоступного ключа эмитента не распознан, аутентификация не проходит. Если все вышеперечисленные проверки прошли успешно, осуществляется объединение левых цифр общедоступного ключа эмитента и остатка этого ключа (если он имеется). Это делается для получения модуля общедоступного ключа эмитента. После данной процедуры система переходит к извлечению общедоступного ключа ICC.

    Если сертификат общедоступного ключа ICC имеет длину, отличную от длины модуля общедоступного ключа эмитента, авторизация не проходит.

    Для того чтобы получить данные, специфицированные в таблице 4.6.4.27, используется сертификат общедоступного ключа ICC и общедоступный ключ эмитента. Если хвостовик восстановленных данных не равен 0хВС, аутентификация не проходит.

    Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит.

    Если код формата сертификата не равен 0х04, аутентификация также не проходит.

    Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.

    Имя поля

    Длина

    (байт)

    Описание

    Заголовок восстановленных данных

    1

    Шестнадцатеричное число 0х6А

    Формат сертификата

    1

    Шестнадцатеричное число 0х04

    PAN приложения

    10

    PAN, дополненный справа кодами 0хF

    Дата истечения времени действия сертификата

    2

    Дата ММГГ, после которой сертификат становится недействительным

    Серийный номер сертификата

    3

    Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации

    Индикатор хэш-алгоритма

    1

    Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи

    Индикатор алгоритма общедоступного ключа ICC

    1

    Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC

    Длина общедоступного ключа ICC

    1

    Идентифицирует длину модуля общедоступного ключа ICC в байтах

    Длина показателя общедоступного ключа ICC

    1

    Идентифицирует длину показателя общедоступного ключа ICC в байтах

    Общедоступный ключ ICC или левые цифры общедоступного ключа ICC

    NЭ - 42

    Если NIC ≤ NЭ - 42, это поле состоит из полного общедоступного ключа ICC, дополненного справа NЭ - 42 - NIC байтами с кодом 0хBB.
    Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC

    Результат хэширования

    20

    Хэш общедоступного ключа ICC и сопряженных с ним данных

    Хвостовик восстановленных данных

    1

    Шестнадцатеричное число 0хВС

    Объединяются слева направо поля из таблицы 4.6.4.27, начиная со второго до десятого, добавляется остаток общедоступного ключа ICC (если имеется), показатель общедоступного ключа ICC и данные, подлежащие аутентификации. Это объединение хэшируется согласно указанному алгоритму. Результат сравнивается со значением поля результат хэширования. При несовпадении аутентификация не проходит.

    Восстановленный PAN должен быть равен PAN приложения (ICC). После этого проверяется срок пригодности сертификата. Если все выше перечисленные проверки оказались успешными, система переходит к последующим тестам.

    После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта).

    ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения.

    Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны

    Имя поля

    Длина
    (байт)

    Описание

    Формат подписанных данных

    1

    Шестнадцатеричное число 0х05

    Индикатор хэш-алгоритма

    1

    Индицируется алгоритм хэширования, используемый для получения результата

    Длина динамических данных ICC

    1

    Идентифицирует длину LDD динамических данных ICC в байтах

    Динамические данные ICC

    LDD

    Динамические данные, сформированные и/или записанные в ICC

    Символы заполнителя

    NIC - LDD - 25

    (NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB

    Динамические данные терминала

    Переменная

    Объединение информационных элементов, специфицированных DDOL

    Длина динамических данных ICC LDD удовлетворяет условию 0 ≤ LDD ≤ NIC - 25. 3-9 самых левых байтов динамических данных ICC включают в себя 1 байт длины динамического числа ICC, за которым следует 2-8 байт значения этого числа (тэг 9F4C, 2-8 двоичных байтов). Динамическое число ICC формируется ICC.

    Кроме данных, перечисленных в таблице 4.6.4.28, для аутентификации динамических данных необходимы информационные объекты:

    Подписанные динамические данные приложения (NIC байтов; тэг 9F4B) и DDOL (тэг 9F49).

    Если подписанные динамические данные приложения имеют длину отличную от длины модуля общедоступного ключа ICC, аутентификация не проходит.

    Чтобы получить восстановленные данные, описанные в таблице 4.6.4.29 для подписанных динамических данных приложения используется общедоступный ключ ICC. Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит.

    Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения

    Имя поля

    Длина
    (байт)

    Описание

    Заголовок восстановленных данных

    1

    Шестнадцатеричное число 0х6А

    Формат подписанных данных

    1

    Шестнадцатеричное число 0х05

    Индикатор алгоритма хэширования

    1

    Индицируется алгоритм хэширования, используемый для получения результата при вычислении цифровой подписи

    Длина динамических данных ICC

    1

    Идентифицирует длину динамических данных ICC в байтах

    Динамические данные ICC

    LDD

    Динамические данные, сформированные и/или записанные в ICC

    Символы заполнителя

    NIC - LDD - 25

    (NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB

    Результат хэширования

    20

    Хэш динамических данных приложения и сопряженной информации

    Хвостовик восстановленных данных

    1

    Шестнадцатеричное число 0хВС

    Далее проверяется заголовок восстановленных данных, если его код не равен 0х6А, аутентификация не проходит. Проверяется код формата подписанных данных и, если он не равен 0х05, аутентификация не проходит.

    Производится объединение слева направо шести информационных элементов из таблицы 4.6.4.29 (начиная с поля формата подписанных данных). Производится хэширование этого объединения, после чего полученный результат сравнивается со значением поля результата хэширования и, если совпадения нет, аутентификация не проходит. Если все предыдущие шаги оказались успешными, аутентификация динамических данных завершается успехом.

    4.6.4.5. Безопасный обмен сообщениями

    Целью безопасного обмена сообщениями является обеспечение конфиденциальности, целостность данных и аутентификация отправителя. Принято два формата сообщений.

    Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code).

    Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4.

    Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.

    Рис. 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями

    Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт.

    В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт.

    Вычисление s байтов МАС (4≤s≤8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC.

    Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено.

    При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется).

    В случае формата 2 сообщение формируется согласно спецификации используемой платежной схемы. Но оно всегда содержит заголовок команды APDU.

    Если МАС специфицирован, как имеющий длину менее 8 байтов, он получается из старших (левых) байтов 8-байтного результата его вычисления.

    Формат зашифрованных командных данных показан на рисунке 4.6.4.14.

    Тэг

    Длина

    Значение

    T

    L

    Криптограмма (зашифрованные данные)

    Рис. 4.6.4.14. Формат 1 для зашифрованных командных данных

    Тэг, согласно спецификации ISO/IEC 7816-6 определяется характером исходных (незашифрованных данных). Четный тэг используется, если объект должен быть включен в вычисление МАС; во всех остальных случаях тэг должен быть нечетным.

    В случае формата 2 поле данных команды шифруется как целое, исключение составляет MAC, если он присутствует (см. рис. 4.6.4.15)

    Значение 1

    Значение 2

    Криптограмма (зашифрованные данные)

    МАС (если имеется)

    Рис. 4.6.4.15. Формат 2 поля данных команды

    Процедура шифрования начинается с получения ключа сессии, который вычисляется на основе мастерного ключа шифрования ICC (см. выше). Шифрование производится с использованием 64-битного блочного шифра ALG в режиме СВС (симметричная схема).

    Для увеличения безопасности может использоваться PIN (Personal Identification Number). Верификация PIN осуществляется терминалом с использованием асимметричного алгоритма (общедоступный и секретный ключи).

    Более полное описание технологии EMV вы можете найти по адресу (английская версия): ftp://saturn.itep.ru/~emvcard.pdf

    Не исключено, что конкуренцию EMV-картам в торговле через Интернет составят виртуальные кредитные карты, применение которых упомянуто во введении.

    Previous: 4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 5 Диагностика локальных сетей и Интернет


    previous up down next index index
    Previous: 4.6.2 SET и другие системы осуществления платежей    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.6.4 Смарт-карты EMV

    4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8
    Семенов Ю.А. (ГНЦ ИТЭФ)


    Протокол CyberCash (RFC-1898, D. Eastlake, CyberCash Credit Card Protocol Version 0.8. February 1996) предназначен для осуществления платежей через Интернет посредством кредитных карточек.

    CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом.

    CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.

    1.1. Обзор системы

    Система CyberCash предназначена для обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash.

    Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть.

    Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.

    Рис. .1. Схема взаимодействия субъектов сделки

    1.2. Соображения безопасности

    В системе CyberCash особое внимание уделяется вопросам безопасности. Система использует самые современные технологии шифрования и способна адаптировать любые новые схемы шифрования, которые появятся в будущем.

    1.2.1. Аутентификация и идентификация личности

    Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для "персон" покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой.

    В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ.

    Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту.

    Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.

    1.2.2. Конфиденциальность

    Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа.

    Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции.

    1.3. Работа с кредитной картой

    При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону. Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.)

    При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.

    2. Формат заголовка общего сообщения

    Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет.

    В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена.

    2.1. Формат сообщения

    Сообщения CyberCash состоят из следующих компонентов:

    1. Заголовок - определяет начало сообщения CyberCash и включает информацию о версии.
    2. Прозрачная часть - содержит данные, которые не являются конфиденциальными.
    3. Невидимые части - содержат финансовую информацию сообщения и защищены от разглашения или искажения. Невидимая часть может отсутствовать в некоторых сообщениях. Если она присутствует, она обеспечивает защиту от искажения прозрачной части.
    4. Завершающая секция - определяет конец сообщения CyberCash и содержит контрольный код, который позволяет судить о том, что сообщение дошло без искажений. Заметим, что этот код призван детектировать случайные искажения сообщения.

    В CyberCash сообщении запрещены нулевые символы (значение нуль) или символы, характеризуемые восемью битами. "Двоичные" значения, которые могут содержать такие коды, представляются с помощью base64, описанного в документе RFC-1521.

    2.2. Детали формата

    Заголовок содержит одну строку, которая выглядит следующим образом

    $$-CyberCash-0.8-$$
    или
    $$-CyberCash-1.2.3-Extra-$$

    Он содержит в себе несколько полей, разделенных символом минус "-"

    1.

    "$$" - литерная строка со значением $ в колонке 1.

    2.

    "CyberCash" - литерная строка (регистр не существенен)

    3.

    x.y или x.y.z - номер версии формата сообщения. x - первичный номер версии. y - номер субверсии. z, если присутствует, номер субсубверсии.

    4.

    "Extra" - опционная дополнительная алфавитно-цифровая строка.

    5.

    "$$" - литерная строка.

    Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы.

    Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall.

    2.3. Части тела

    Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности.

    Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label).

    Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа.

    Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк.

    Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.

    2.4. Открытая часть

    Открытая часть сообщения включает любые текстовые данные, связанные с финансовой транзакцией, а также информацию, необходимую CyberCash и другим, для того чтобы дешифровать скрытую часть. Она всегда включает поле транзакции, которое представляет собой номер транзакции, сформированный источником запроса, это поле копируется в отклик. Открытая часть всегда включает поле даты, которое представляет собой местную дату и время, переносимые без изменений в соответствующие поля отклика. Во всех случаях кроме начальной регистрации открытая часть содержит ID персоны источника запроса.

    В сообщениях, подготовленных для сервера, существует киберключ (cyberkey:) поле, которое идентифицирует, какой из общедоступных ключей сервера был использован для шифрования ключа сессии.

    2.5. Скрытая часть

    Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются.

    Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные.

    Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением.

    Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто.

    2.6. Завершающая часть

    Завершающая секция служит для выделения конца сообщения. Она содержит несколько полей разделенных "-".

    1.

    "$$" - строка литералов.

    2.

    "CyberCash" - строка литералов (не чувствительна к регистру).

    3.

    "End" - строка литералов (не чувствительна к регистру).

    4.

    Контрольная сумма передачи.

    5.

    "$$" - строка литералов.

    Контрольная сумма передачи вычисляется согласно алгоритму MD5. Номер версии в начальной строке содержит исключительно печатные символы и размещается после второго $$ этой строки и до первого $$ завершающей строки. Заметим, что все пробелы (SP, TAB, LF и CR) не включаются в этот хэш. Терминаторы меток (: или ;) включаются туда, также как любые строки #-комментариев. Заметим также, что опционная символьная строка "Extra" в начальной $-строке в хэш не включается. Основной идеей является обеспечение корректности передачи, избегая зависимости от шлюзов (gateways) или любой обработки, которая может изменить завершающую строку или преобразовать символы табуляции, пробелы или символы разрыва строки.

    2.7. Примеры сообщений

    Простое сообщение от клиента:

    $$-CyberCash-0.8-$$
    id: DONALD-69
    transaction: 918273645
    date: 199512250102
    cyberkey:CC1001
    opaque:

    GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
    aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
    elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
    EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
    $$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$

    Сообщение от продавца:

    $$-CyberCash-a.b.c-extra-$$
    merchant-ccid: acme-69
    merchant-date: 19951231115959
    merchant-transaction: 987654321
    label: value

    labelx: multiple line
    value...
    # Комментарий
    # еще одна строка комментария
    label; text with a real
    multi-line
    format !
    merchant-cyberkey: CC1001
    merchant-opaque:

    C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
    /iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
    66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
    6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
    sDrWehG/UbFTPD26trlYRnnY
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

    3. Подписи и хэши

    Входные сообщения-запросы CyberCash обычно имеют подпись всех полей. Эта подпись передается в пределах скрытой части сообщения. Она позволяет серверу аутентифицировать источник сообщения.

    Сообщения от продавца клиенту, инициализирующие процедуру покупки, имеют поля подписанные продавцом. Эти поля и эта подпись включаются клиентом в скрытую часть сообщения продавцу, так что когда все передается серверу, он может проверить, что клиент получил именно ту информацию, которую ему передал продавец.

    3.1. Цифровые подписи

    Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA.

    Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке.

    В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения.

    Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.

    3.2. Хэш-коды

    Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение.

    Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности.

    До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются.

    Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями).

    4. Форматы специальных сообщений

    Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла.

    4.1. Регистрация персоны и нахождение приложения

    Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2.

    Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя.

    4.1.1. R1 - регистрация

    Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash.

    #########################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    transaction: 123123213
    date: 19950121100505.nnn
    cyberkey: CC1001
    opaque:
    FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
    MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
    vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
    JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
    +lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
    #####################################################################
    Скрытый ключ: Сгенерирован с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
    #####################################################################
    Содержимое скрытой секции:
    type: registration
    swversion: 0.8win
    content-language: en-us
    requested-id: MyRequestedCCID
    email: myemail@myemailhost.com
    pubkey:
    0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
    E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
    signature:
    v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
    dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom
    #####################################################################
    подпись покрывает следующие поля: transaction, date, cyberkey, type, swversion, content-language, requested-id, email, pubkey
    #####################################################################
    Объяснение:
    content-language (язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.

    4.1.2 R2 - отклик регистрации

    Это сообщение предоставляет отклик об успехе или неудаче R1.

    #####################################################################
    Отправитель: CyberServer
    Получатель: CyberApp
    #####################################################################

    Пример сообщения:
    $$-CyberCash-0.8-$$
    transaction: 12312313
    date: 19950121100505.nnn
    opaque:
    r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
    dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
    kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
    fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
    gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
    #####################################################################
    Скрытый ключ. Тот же самый, что и ключ сессии для R1 в случае той же транзакции и того же соединения (ID может отсутствовать).
    #####################################################################
    Содержимое скрытой секции:
    type: registration-response
    server-date: 19950121100506.nnn
    requested-id: MyRequestedCCID
    response-id: CyberCashHandle
    >email: myemail@myemailhost.com
    response-code: success/failure/etc.
    pubkey:
    0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
    E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
    swseverity: fatal/warning [отсутствует, если все в порядке]
    swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
    message;
    Произвольный текст уведомления об успехе или неудаче.
    Этот текст должен быть отображен для владельца приложения CyberCash...
    В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация).

    Объяснение:

    responseid

    применяется для предоставления уникального ID, если в результате ошибки потерян ID, использованный ранее. Если причина неудачи не связана с дублированным ID, это поле может быть опущено.

    responseid

    предоставляет действительный ID с присоединенными контрольными символами в случае успеха.

    swseverity

    может предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок.

    4.1.3. GA1 - get-application (получение приложения)

    Используется CyberApp, чтобы получить обновленную версию.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:
    $$-CyberCash-0.8-$$
    transaction: 123123213
    date: 19950121100505.nnn
    cyberkey: CC1001
    opaque:
    VHMS611wGkUmR6bKoI+ODoSbl7L5PKtEo6aM88LCidqN+H/8B4xM3LxdwUiLn7rMPkZi
    xOGb+5d1lRV7WeTp21QYlqJr8emc6FAnGd5c0csPmcnEpTFh9xZDJaStarxxmSEwm2mw
    l2VjEUODH6321vjoMAOFQWn7ER0o
    $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
    #####################################################################
    Скрытый ключ. Генерируется с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
    #####################################################################
    Содержимое скрытой секции:
    type: get-application
    swversion: 0.8win

    Объяснение:

    Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить.

    4.1.4. GA2 - отклик получения приложения (get-application-response)

    Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи.

    #####################################################################
    Отправитель: CyberServer
    Получатель: CyberApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    transaction: 12312313
    date: 19950110102333.nnn
    opaque:
    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$

    #####################################################################
    Скрытый ключ: ключ сессии от GA1
    #####################################################################
    Содержимое скрытой секции:

    type: get-application-response
    server-date: 19950110102334.nnn
    response-code: success/failure/etc.
    message; Текст сообщения отображается пользователю, предоставляя дополнительную информацию об успехе или неудаче.
    swversion: 0.8win
    application-url: http://foo.cybercash.com/server/0.8WIN.EXE
    >application-hash: lSLzs/vFQ0BXfU98LZNWhQ==

    В качестве хэша приложения используется MD5.
    application-url и application-hash при ошибке опускаются.
    swversion является версией, подлежащей передаче покупателю.

    4.2. Привязка кредитных карт (Binding Credit Cards)

    Система CyberCash сконструирована так, чтобы предоставить организации, выпустившей кредитную карту, возможность определить, может ли она использоваться через CyberCash. Покупатель, после регистрации персоны в CyberCash, как это описано выше, может связать каждую кредитную карту по своему желанию с персоной в системе CyberCash. Это делается с помощью сообщения BC1, посылаемого покупателем своему серверу CyberCash, и отклика BC4, приходящего от сервера.

    4.2.1. BC1 - подключение кредитной карты (Bind-Credit-card)

    Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: MyCyberCashID
    date: 19950121100505.nnn
    transaction: 12312314
    cyberkey: CC1001
    opaque:
    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

    #####################################################################
    Скрытый ключ. Формируется из ключа шифрования CyberCash идентифицированного в CyberKey
    #####################################################################

    Содержимое скрытой секции:

    type: bind-credit-card
    swversion: 0.8win
    card-number: 1234567887654321
    card-type: mastercard
    card-salt: 46735210
    card-expiration-date: 05/99
    card-name: John Q. Public
    card-street:
    card-city:
    card-state:
    card-postal-code:
    card-country:
    signature:
    tX3odBF2xPHqvhN4KVQZZBIXDveNi0eWA7717DNfcyqh2TpXqgCxlDjcKqdJXgsNLkY7
    GkyuDyTF/m3SZif64giCLjJRKg0I6mqI1k/Dcm58D9hKCUttz4rFWRqhlFaj
    #####################################################################
    Подпись покрывает следующие поля: id, date, transaction, cyberkey, type, swversion, card-number, card-salt, card-expiration-date, card-name, card-street, card-city, card-state, card-postal-code, card-country
    #####################################################################

    Объяснение:

    salt необходимо из-за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.

    4.2.2. BC4 - отклик подключения кредитной карты (bind-credit-card-response)

    Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
    #####################################################################
    Получатель: CyberApp
    #####################################################################

    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: mycybercashid
    transaction: 12312314
    date: 19950121100505.nnn
    opaque:
    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

    #####################################################################
    Скрытый ключ. Ключ сессии от BC1 и ID
    #####################################################################

    Содержимое скрытой секции:

    type: bind-credit-card-response
    server-date: 19950121100506.nnn
    swseverity: fatal/warning [absent if ok]
    swmessage; message about obsoleteness of customer software to be shown to the customer. [only resent if SWSeverity present]
    response-code: success/failure/etc.
    card-number: 1234567887654321
    card-type: visa
    card-salt: 47562310
    card-expiration-date: 01/99
    card*: [other card* lines to also be given in CH.1 message]
    message; Простой текст для пользователя может содержать много строк.

    Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.

    4.3. Сообщения покупателя о покупке, содержащие данные о кредитной карте

    Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash "payment", продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash.

    Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.

    4.3.1. PR1 - запрос платежа (payment-request)

    Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    type: payment-request
    merchant-ccid: ACME-012
    merchant-order-id: 1231-3424-234242
    merchant-date: 19950121100505.nnn
    note;
    Товары ACME

    Покупка 4 пар "Rocket Shoes" по цене $39.95 каждая.
    Доставка и вручение $5.00

    Общая цена: 164.80

    Доставить по адресу: Wily Coyote 1234 South St. Somewhere, VA 12345
    merchant-amount: usd 164.80
    accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
    url-pay-to: http://www.ACME.com/CybercashPayment
    >url-success: http://www.ACME.com/ordersuccess
    >url-fail: http://www.ACME.com/orderfail
    merchant-signed-hash:
    a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
    Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD $$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$

    Скрытая секция здесь отсутствует.
    #####################################################################
    При формировании подписанного продавцом хэша используется секретный ключ продавца. Хэш формируется для полей: type, merchant-ccid, merchant-order-id, date, note, merchant-amount, accepts, url-pay-to, url-success, url-fail
    #####################################################################

    Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию.

    accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например,

    MasterCard
    AmericanExpress
    Распознаны как
    Master card
    American express
    Не распознаны. MasterCard и masterCard распознаются оба как master card.
    За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием.

    url-pay-to указывает, куда следует послать CH1.

    url-fail и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи.

    4.3.2. CH1 - платеж через кредитную карту (credit-card-payment)

    Это сообщение осуществляет представление кредитной карты для выполнения платежа. ####################################################################
    Отправитель: CyberApp
    Получатель: MerchantApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    type: card-payment
    id: myCyberCashID
    order-id: 1231-3424-234242
    merchant-ccid: ACME-012
    transaction: 78784567
    date: 19950121100505.nnn
    pr-hash: c77VU/1umPKH2kpMR2QVKg==
    pr-signed-hash:
    a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
    Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
    cyberkey: CC1001
    opaque:
    iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
    3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
    9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
    5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
    3ard3Q==
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

    #####################################################################
    Скрытый ключ. Создан с использованием общедоступного ключа шифрования CyberCash, на который указывает CyberKey.
    #####################################################################
    Содержимое скрытой секции:
    swversion: 0.8win
    >amount: usd 10.00
    card*: [из успешно прошедшего BC4 (включает в себя время действительности кредитной карты, ее номер, тип и card-salt)]
    Подпись:

    meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh
    mm9BVmHRwCq6+8ylZXixGHI1I9A/ufAMrpqMIi6DS3PRlc8WC3CCWoAHyAqr
    #####################################################################
    type, id, order-id, merchant-ccid, transaction, date, pr-hash, pr-signed-hash, cyberkey, swversion, amount, card*
    #####################################################################
    Поле pr-signed-hash тождественно полю подписанного продавцом хэша (merchant-signed-hash) в сообщении PR1.

    4.3.3. CH2 - отклик оплаты с помощью карты (charge-card-response)

    Отклик покупателю на CH1-попытку оплатить покупку с помощью кредитной карты. Индицирует успех или неудачу.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberApp
    ##################################################################### Пример сообщения:

    $$-CyberCash-0.8-$$
    type: charge-card-response
    merchant-ccid: ACME-012
    id: myCyberCashID
    transaction: 78784567
    date: 1995121100500.nnn
    merchant-date: 19950121100505.nnn
    merchant-response-code: failure/success/etc.
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
    Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
    merchant-message; Это сообщение от продавца следует отобразить пользователю. Может иметь много строчек и не имеет защиты.
    opaque: [может отсутствовать, смотри объяснение]
    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    >rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

    #####################################################################
    Скрытый ключ. Ключ сессии покупателя, взятый из CH1 и переданный через CM1 для ID и транзакции.
    #####################################################################
    Закрытая секция содержит (из CM.6):

    server-date: 19950121100706.nnn
    amount: usd 10.00
    order-id: 1231-3424-234242
    card*: [из успешного BC4]
    response-code: failure/success/etc.
    swseverity: fatal/warning
    swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
    message;

    Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash.

    Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения.

    Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу. Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.

    4.4. Сообщения продавца о покупке, связанные с кредитной картой

    Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения.

    Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7

    Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым.

    Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом.

    4.4.1. CM1 - auth-only (аутентификация)

    Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-69
    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    merchant-cyberkey: CC1001
    cyberkey: CC1001
    opaque:

    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    merchant-opaque:
    6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
    aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
    dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
    j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
    F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
    mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
    mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################

    Содержимое скрытой секции продавца:

    type: auth-only
    order-id: 12313424234242
    merchant-amount: usd 10.00
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
    Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn
    merchant-signature:

    v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY
    GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
    #####################################################################
    Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey. Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
    #####################################################################
    Содержимое закрытой части и подпись: (в точности как в CH1)

    swversion: 0.8win
    amount: usd 10.00
    card*: [from successful BC4 (includes card-expiration-date, card-number, and card-salt)]
    Подпись:

    48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
    +IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
    #####################################################################
    Подпись продавца покрывает следующие поля:
    merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
    Подпись покупателя: смотри CH1
    #####################################################################
    Пояснение:

    Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.

    4.4.2. CM2 - auth-capture

    Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:
    [exactly the same as CM1 except
    type: auth-capture
    ]

    4.4.3. Сообщение CM3 - post-auth-capture

    Сообщение аналогично CM1 за исключением того, что оно имеет другой тип и снабжено полем кода авторизации (которое включено в подпись).

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-012

    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    merchant-cyberkey: CC1001
    cyberkey: CC1001
    opaque:

    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    merchant-opaque:

    6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
    aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
    dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
    j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
    F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
    mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
    mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

    #####################################################################
    Содержимое скрытой секции продавца:

    type: post-auth-capture
    authorization-code: a12323
    order-id: 1231-3424-234242
    merchant-amount: usd 10.00
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
    Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn
    merchant-signature:

    vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6
    Mnptzc6phJi3Ar0s0oumELsdc8upJdXpNpJV021PGJXfDKfHP0heJIWLodXr
    #####################################################################
    Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в merchant-cyberkey.
    Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
    #####################################################################
    Содержимое закрытой секции и подпись: (в точности как в CH1) swversion: 0.8win
    amount: usd 10.00
    card*: [в случае успешного BC4 (включает в себя card-salt, номер карты и срок действия карты)]
    Подпись:

    48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
    +IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs

    #####################################################################
    Подпись продавца покрывает следующие поля:
    merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, authorization-code, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
    #####################################################################

    Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена.

    4.4.4. Сообщение об удалении CM4

    Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись).

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-012
    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    merchant-cyberkey: CC1001
    cyberkey: CC1001
    opaque:

    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    merchant-opaque:
    6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
    aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
    dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
    j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
    F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
    mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
    mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################
    Содержимое скрытой секции продавца:

    type: void
    retrieval-reference-number: 432112344321
    order-id: 1231-3424-234242
    merchant-amount: usd 10.00
    pr-hash: WATCQuH2q17lRuoxD78YBg==
    pr-signed-hash:

    8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
    kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn
    Подпись продавца:

    lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
    #####################################################################
    Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в Merchant-CyberKey.
    Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
    #####################################################################
    Содержимое закрытой секции и подпись: (в точности как в CH1)

    swversion: 0.8win
    amount: usd 10.00
    card*: [из успешного bc4 (содержит card-salt, номер карты и срок ее действия)]
    Подпись:

    48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
    +IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
    #####################################################################
    Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, retrieval-reference-number, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
    #####################################################################<> Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.

    4.4.5. CM5 - возврат

    Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:
    [в точности как и CM1, только поле type: return]

    4.4.6. CM6 - отклик на операцию оплаты (charge-action-response)

    Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию.

    #####################################################################
    Отправитель: CyberServer
    Получатель: MerchantApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-012
    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    opaque:

    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    merchant-opaque:
    6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
    aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
    dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
    j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
    F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
    mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
    mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################
    Скрытый ключ продавца. Ключ сессии, который совпадает с CM1/2/3/4/5 для той же транзакции и CCID продавца.
    Скрытый ключ. Тот же ключ сессии покупателя, что и в сообщении CH1 переданном через CM* для данного ID и транзакции
    #####################################################################
    Содержимое скрытой секции продавца:

    type: charge-action-response
    server-date: 19950121100706.nnn
    action-code: XXX [per ISO 8583]
    response-code: failure/success/etc.
    order-id: 1231-3424-234242
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
    kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
    retrieval-reference-number: 432112344321
    authorization-code: a12323
    card-hash: 7Tm/djB05pLIw3JAyy5E7A==
    {
    card-prefix: nnxxxx [Returned if merchant is not full-PAN]
    }
    или
    {
    card-number: 1234567890123456 [Returned if merchant is full-PAN]
    }
    expiration-date: 12/34 [всегда присутствует]
    merchant-swseverity: fatal/warning
    merchant-swmessage; Сообщение для продавца об устаревшем номере протокола в стартовой $$-строке сообщения продавца.
    merchant-message;
    Свободный текст, поясняющий причины неудачи или успеха.
    Этот текст направляется сервером продавцу...
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn

    Содержимое скрытой секции (покупателя):
    server-date: 19950121100706.nnn
    amount: usd 10.00
    order-id: 1231-3424-234242
    card*: [from successful BC4]
    response-code: failure/success/etc.
    swseverity: fatal/warning
    swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя. [присутствует только, когда имеется SWSeverity]
    message;
    Свободный текст, поясняющий причины неудачи или успеха. Этот текст следует отобразить покупателю с помощью приложения CyberCash.

    retrieval-reference-number

    необходимо для аннулирования.

    authorization-code

    необходим для post-auth-capture. Оба эти поля присутствуют только в сообщении CM6, если оно было присланы банком. Все зависит от выполняемой операции.

    card-prefix

    (префикс карты) представляет собой первые две и последние четыре цифры номера кредитной карты. По усмотрению банка продавца присылается номер кредитной или ее префикс.

    card-hash

    является в действительности хэшем всего номера кредитной карты и salt, представленной покупателем. card-hash необходим для того, чтобы продавец мог, если хочет, сортировать транзакции покупателя по его кредитным картам, не зная их номеров.

    card*

    представляет собой поля card*, полученные вместе с сообщениями CM*, присланными в качестве отклика. Они появляются в алфавитном порядке.

    server-date

    дублируется в целях безопасности в закрытой секции покупателя.

    []

    комментарии, появляющиеся после некоторых полей.

    4.4.7. Последовательности сообщений MM*

    Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.

    4.4.8. CD1 - запрос данных о кредитной карте

    Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений.

    #####################################################################
    Отправитель: MerchantApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:
    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-69
    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    merchant-cyberkey: CC1001
    cyberkey: CC1001
    opaque:

    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
    merchant-opaque:
    6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
    aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
    dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
    j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
    F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
    mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
    mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################
    Содержимое скрытой секции продавца:
    type: card-data-request
    password: xyzzy
    server-date: 19950121100505.nnn [optional]
    order-id: 12313424234242
    merchant-amount: usd 10.00
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
    +X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn
    Подпись продавца:

    8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
    kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
    #####################################################################
    Скрытый ключ продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицированного в merchant-cyberkey.
    Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
    #####################################################################
    Содержимое закрытой секции и подпись: (в точности как в CH1)

    swversion: 0.8win
    amount: usd 10.00
    card*: [от успешного BC4 (включает в себя время действия карты, номер карты и card-salt)]
    Подпись:

    48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
    +IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
    #####################################################################
    Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, password, server-date, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
    Подпись покупателя: смотри CH1
    #####################################################################
    [смотри также объяснения для CM1]

    Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции. Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу.

    Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.

    4.4.9. CD2 - отклик на данные кредитной карты

    Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте.

    #####################################################################
    Отправитель: CyberServer
    Получатель: MerchantApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: ACME-012
    merchant-transaction: 123123
    merchant-date: 19950121100705.nnn
    merchant-opaque:

    t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP
    2Z0BClVHLmhIBY7+QXx5iCEGHy8JKC9IWyNNi2O/OOIDgLeJAkMSZYbNQrSKViY34imS
    0s7Q6uDk9wV0fixjvRBuNO2B7urWWsqfkLOYDnHy0RvhyUzYxLrMaTX+/6IkyU5Z0lH3
    BXYBUNV8DgitEjgLXmyWuXRDlEBN02yeZgsFRm9GmuBHfCTySm2XqnifizpmKMUa9UiH
    onNx9W86fuBdcJF7CJgH5Gct2M/dx/f2VpoRkmeSmWxFrYi8wgtvddSXF9my40NZ8WZz
    CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5
    L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo
    5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl
    xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################
    Скрытый ключ: ключ сессии из CD1.
    #####################################################################
    Содержимое скрытой секции:

    type: card-data-response
    server-date: 19950121100706.nnn
    response-code: failure/success/etc.
    order-id: 1231-3424-234242
    pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
    pr-signed-hash:

    IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
    +X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
    card-hash: 7Tm/djB05pLIw3JAyy5E7A==
    card-number: 4811123456781234
    card-type: visa
    card-name: John Q. Public
    expiration-date: 01/99
    merchant-swseverity: fatal/warning
    merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
    merchant-message;
    Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
    id: myCyberCashID
    transaction: 78784567
    date: 19950121100505.nnn

    Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.

    4.5. Прикладные сообщения и уведомления об ошибках

    Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке.

    Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту.

    Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером.

    Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2.

    4.5.1. P1 - ping

    Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:
    $$-CyberCash-0.8-$$
    type: ping
    id: myCyberCashID [optional]
    transaction: 123123213
    date: 19950121100505.nnn
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

    #####################################################################
    id является опционным, так как персона может быть еще не установлена.

    4.5.2. P2 - отклик на ping

    Отклик на ping P1. Для минимизации избыточности здесь не используется никаких криптографических методов.

    #####################################################################
    Отправитель: CyberServer
    Получатель: CyberApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    type: ping-response
    id: myCyberCashID [если присутствует в P1]
    transaction: 12312313
    date: 19950121100505.nnn
    server-date: 19950121100506.nnn
    swseverity: fatal/warning [отсутствует, если все в порядке]
    swmessage; Говорит CyberApp, что оно использует устаревший протокол.
    Данный текст отображается для пользователя. [Присутствует только при наличии SWSeverity.]
    response-code: success/failure/etc.
    message;
    Свободный текст комментария об ошибке или успехе.
    Этот текст должен быть отображен отправителю его прикладной программой CyberCash.
    supported-versions: 08.win, 0.81win, 0.8mac

    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
    #####################################################################
    swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
    supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.

    4.5.3. TQ1 - запрос транзакции

    Запрос клиента серверу о состоянии транзакции.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: MyCyberCashID
    date: 19950121100505.nnn
    transaction: 12312314
    cyberkey: CC1001
    opaque:

    VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
    >21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
    L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
    3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
    bnf+muO0+kiNPXVvEzRrO8o=
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

    #####################################################################
    Скрытый ключ. Генерируется ключом шифрования CyberCash, идентифицированным CyberKey
    #####################################################################
    Содержимое скрытой секции:

    type: transaction-query
    swversion: 0.8win
    begin-transaction: 1234
    end-transaction: 4321
    Подпись:

    jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X
    vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym
    #####################################################################
    Подпись содержит в себе поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
    #####################################################################
    Объяснение:
    Это запрос клиента сообщить ему о состоянии предшествующей транзакции или транзакций.

    begin-transaction и end-transaction могут совпадать.

    4.5.4. TQ2 - аннулирование транзакции

    Запрос клиента серверу в связи с аннулированием транзакции.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: MyCyberCashID
    date: 19950121100505.nnn
    transaction: 12312314
    cyberkey: CC1001
    opaque:

    VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
    21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
    L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
    3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
    bnf+muO0+kiNPXVvEzRrO8o=
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
    #####################################################################
    Скрытый ключ: полученный из ключа шифрования CyberCash, заданного CyberKey
    #####################################################################
    Содержимое скрытой секции:
    type: transaction-cancel
    swversion: 0.8win
    begin-transaction: 1234
    end-transaction: 4321
    Подпись:

    kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn
    ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ
    #####################################################################
    Подпись защищает следующие поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
    #####################################################################
    Объяснение:<> Это попытка клиента аннулировать предыдущую транзакцию или транзакции.<> begin-transaction и end-transaction могут совпадать.

    Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.

    4.5.5. TQ3 - отклик транзакции (transaction-response)

    Отклики, генерируемые TQ1 или TQ2

    #####################################################################
    Отправитель: CyberServer
    Получатель: CyberApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: mycybercashid
    date: 19950121100505.nnn
    transaction: 12312314
    server-date: 19950121100505.nnn
    opaque:

    eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ
    3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s
    s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX
    PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD
    JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv
    fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6
    TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI
    IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy
    35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1
    +yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC
    VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY
    Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor
    dMTGWn0ifETy2VXt
    $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
    #####################################################################
    Скрытый ключ. Ключ сессии из TQ1/TQ2 для текущих значений транзакции и ID.
    #####################################################################
    Содержимое скрытой секции:

    type: transaction-response
    response-code: success/failure/etc.
    message; текстовое сообщение, посылаемое сервером покупателю.
    swseverity: fatal/warning
    swmessage; Сообщение, указывающее, что программа CyberApp является устаревшей. Может содержать несколько строк.
    report-fee: usd 0.15 [если не равно нулю]

    transaction-1: old-transaction-number
    transaction-status-1: success/failure/pending/cancelled/etc.
    server-date-1: 19951212125959.nnn
    date-1: 19950121100505.nnn
    type-1: auth-only/etc.

    Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты. Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.).

    Термины

    "исходная транзакция"

    относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера.

    "request"

    относится к запрашивающим сообщениям TQ.2 или TQ.1.

    id:

    идентификатор сообщения-запроса

    date:

    дата сообщения-запроса

    transaction:

    транзакция сообщения-запроса

    server-date:

    текущая дата/время

    type:

    Отклик транзакции

    response-code:

    код отклика для сообщения-запроса, может быть одним из:

    "success"

    означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса.

    "failure-hard"

    означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине.

    "failure-swversion"

    означает, что запрос не был обработан из-за проблем ревизии программного обеспечения.

    message:

    сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика:

    "success"

    сообщение проигнорировано.

    "failure-hard"

    используется стандартное сообщение уведомление о неудаче.

    "failure-swversion"

    в случае фатальной ошибки используется стандартное сообщение типа swversion

    swseverity:

    относится к сообщению-запросу

    swmessage:

    относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N)

    transaction-N:

    номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из:

    "success"

    исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится.

    "failure"

    исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится.

    "pending"

    исходная транзакция все еще обрабатывается и окончательный результат пока не известен.

    "canceled"

    исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled".

    server-date-1:

    поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.

    date-1:

    поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.

    type-1:

    поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.

    4.5.6. UNK1 - неизвестная ошибка

    Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту.

    #####################################################################
    Отправитель: MerchantApp или CyberServer
    Получатель: CyberApp или MerchantApp
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    type: unknown-error
    unknown-error-message:
    Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
    {
    server-date: 19950121100506.nnn [если послано сервером]
    }
    или
    {
    merchant-date: 19950121100506.nnn [если послано продавцом]
    }
    x-id: mycybercashID
    x-transaction: 123123213
    x-date: 19950121100505.nnn
    x-cyberkey: CC1001
    x-opaque:

    2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
    9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
    TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
    5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
    GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
    lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
    Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
    $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$

    Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д.

    Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу. Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1.

    4.5.7. DL1 - диагностическая запись

    Клиентская диагностическая запись о плохом сообщении от продавца или сервера.

    #####################################################################
    Отправитель: CyberApp
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    id: MyCyberCashID
    date: 19950121100505.nnn
    transaction: 1234
    cyberkey: CC1001

    opaque:

    2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
    9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
    TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
    5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
    GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
    lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
    Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

    #####################################################################
    Скрытый ключ. Генерируется из ключа шифрования CyberCash, идентифицируемого в CyberKey
    #####################################################################
    Содержимое скрытой секции:
    type: diagnostic-log
    message: incorrect order-id
    swversion: 0.8win
    x-type: original-message-type
    x-transaction: original-transaction-number
    x-opaque: [ели нельзя дешифровать]

    9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
    5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
    #####################################################################
    Приложение клиента не ожидает отклика на это сообщение. Если дешифрация прошла успешно, дешифрованное исходное сообщение будет заключено в закрытую секцию. Если дешифровка не прошла, не дешифрованная закрытая секция берется из исходного сообщения.

    4.5.8. DL2 - диагностические журнальные записи продавца (merchant-diagnostic-log)

    Диагностическая запись продавца о плохом сообщении от сервера.

    #####################################################################
    Отправитель: CyberMerchant
    Получатель: CyberServer
    #####################################################################
    Пример сообщения:

    $$-CyberCash-0.8-$$
    merchant-ccid: MyCyberCashID
    merchant-transaction: 1234
    merchant-date: 19950121100505.nnn
    merchant-cyberkey: CC1001
    merchant-opaque:

    2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
    9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
    TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
    5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
    GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
    lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
    Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
    $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
    #####################################################################
    Скрытый ключ. Генерируется из ключа шифрования CyberCash, заданного в CyberKey
    #####################################################################
    Содержимое скрытой секции:

    type: merchant-diagnostic-log
    server-date: 19950121100505.nnn [optional]
    message: incorrect order-id
    x-type: original-message-type
    x-transaction: original-transaction-number
    x-opaque: [если невозможно дешифровать]

    9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
    5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
    #####################################################################

    Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение.

    4.6. Таблица описанных сообщений

    C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash

    FLOW

    Раздел

    Имя

    C->S

    4.2.1

    BC.1 bind-credit-card

    S->C

    4.2.2

    BC.4 bind-credit-card-response

    C->M

    4.3.2

    CH.1 credit-card-payment

    M->C

    4.3.3

    CH.2 credit-card-response

    M->S

    4.4.8

    CD.1 запрос данных о кредитной карте

    S->M

    4.4.9

    CD.2 отклик на запрос о кредитной карте

    M->S

    4.4.1

    CM.1 только аутентификация

    M->S

    4.4.2

    CM.2 auth-capture

    M->S

    4.4.3

    CM.3 post-auth-capture

    M->S

    4.4.4

    CM.4 void

    M->S

    4.4.5

    CM.5 возврат

    S->M

    4.4.6

    CM.6 отклик на платеж

    C->S

    4.5.7

    DL.1 диагностическая запись

    M->S

    4.5.7

    DL.2 диагностическая запись продавца

    C->S

    4.1.3

    GA.1 получение приложения

    S->C

    4.1.4

    GA.2 получение отклика приложения

    M->S

    4.4.7

    MM.1 только аутентификация продавца

    M->S

    4.4.7

    MM.2 merchant-auth-capture

    M->S

    4.4.7

    MM.3 merchant-post-auth-capture

    M->S

    4.4.7

    MM.4 merchant-void

    M->S

    4.4.7

    MM.5 merchant-return

    S->M

    4.4.7

    MM.6 отклик продавца на процедуру оплаты

    C->S

    4.5.1

    P.1 ping

    S->C

    4.5.2

    P.2 отклик на ping

    M->C

    4.3.1

    PR.1 запрос платежа

    C->S

    4.1.1

    R.1 регистрация

    S->C

    4.1.2

    R.2 отклик на регистрацию

    C->S

    4.5.3

    TQ.1 запрос о состоянии транзакции

    C->S

    4.5.4

    TQ.2 аннулирование транзакции

    S->C

    4.5.5

    TQ.3 отклик на транзакцию

    S->C, S->M, M->C

    4.5.6

    UNK.1 неизвестная ошибка

    5. Дальнейшие разработки

    Список возможностей, которые доступны в системе CyberCash, расширяется. В настоящее время реализована универсальная система расчетов, включающая эффективную пересылку небольших сумм денег, планируются различные дальнейшие улучшения.

    5.1. Процесс авторизации кредитной карты и расчета

    Существует шесть шагов обработки кредитной карты, как это описано ниже. Первые четыре присутствуют всегда, если транзакция завершена. Пятый и шестой являются опционными.

    (1)

    авторизация: продавец контактирует со своим покупателем, который в свою очередь получает от банкира, выпустившего кредитную карту, подтверждение или отрицание своей кредитоспособности. Эти данные он пересылает продавцу.

    (2)

    приобретение (capture): платежная информация для покупки вводится продавцом в расчетный документ.

    (3)

    оплата (clearance): обработка перечня товаров. Это вызывает появление товаров из перечня в записи о покупке для данной кредитной карты. Эта запись посылается банку, предоставившему кредитную карту покупателю.

    (4)

    урегулирование (settlement): межбанковская операция по пересылке денежных средств.

    (5)

    удаление (void): продавец отменяет шаг 2 (или 6), сумма оплаты удаляется из расчетного документа. Операция должна быть выполнена до осуществления оплаты.

    (6)

    кредит (credit): продавец вводит отрицательную сумму оплаты в расчетный документ. Эта сумма появится в записи о покупке владельца кредитной карты.

    Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются "терминальными покупками" ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера.

    6. Соображения безопасности

    Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.

    Ссылки

    [ISO 4217]

    Codes for the representation of currencies and funds

    [ISO 8583]

    Financial transaction card originated messages - Interchange message specifications, 1993-12-15.

    [RFC-822]

    Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982.

    [RFC-1521]

    Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993.

    [RFC-1766]

    Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.

    Previous: 4.6.2 SET и другие системы осуществления платежей    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.6.4 Смарт-карты EMV


    previous up down next index index
    Previous: 4.5.17 Сетевое моделирование    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет
        Next: 4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0

    4.6 Электронная торговля в Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

      Что перед логикой рублей
    Ничтожны все химеры
    И в честь безденежных людей
    Давно нет в мире веры.

        Джузеппе Джусти, "Шутки" (середина 19-го века)

    Бурное развитие Интернет во всем мире и в РФ открыло ряд направлений бизнеса: предоставление услуг Интернет, электронная почта, IP-телефония и т.д. На подходе сфера сетевых развлечений и виртуальной реальности, этому способствует впечатляющий прогресс в разработке мультимедиа стандартов и протоколов MPEG-4 и MPEG-7. Банки давно использовали специализированные сети для расчетов, в последнее время они стали осваивать возможности общедоступных сетей. Реклама через Интернет стала высокодоходной деятельностью даже в России. Особое положение в этом ряду занимает электронная коммерция через Интернет. Более года назад был разработан торговый протокол IOTP, который перекрывает почти неограниченный спектр услуг, начиная от торговых сделок и оплаты, вплоть до доставки и послепродажного обслуживания, разработан целый спектр платежных протоколов, что сняло последние технические проблемы на пути внедрения торговли через сети Интернет. Одной из проблем была слабая защищенность транспортировки данных по каналам Интернет. Нельзя сказать, что в этой сфере решены все проблемы, но, тем не менее, за последние годы достигнуты впечатляющие успехи. В основном это связано с разработкой эффективных алгоритмов и программ шифрования (симметричных и асимметричных), аутентификации, электронной подписи, сертификации и безопасных каналов (например, TSL). Электронная торговля бурно развивается, прежде всего, в США, но и в России с несколькими миллионами пользователей Интернет у этого вида бизнеса неплохие шансы уже сегодня. В разделе 15, написанном Сергеем Джужей (выпускником кафедры ТСС МФТИ), приведены примеры практического воплощения подобных проектов.

    В "МК" за 11-12-2001 появилась заметка "Космонавты сходили по магазинам прямо на орбите", где сообщалось о покупках сделанных космонавтами В. Дежуровым и М. Тюриным с борта международной космической станции. Покупки были осуществлены с помощью виртуальной платежной карты VISA. Понятно, что торговля в космосе не станет в ближайшее время бурно развивающимся бизнесом, это лишь говорит о впечатляющих возможностях новых технологий.

    В перспективе для торговли через Интернет нет никаких ограничений. Но есть ряд областей, где именно этот вид торговли находится вне конкуренции. Это, прежде всего сфера сетевых развлечений, коммерческой информации, дистанционного обучения, платных консультаций, а также продажа небольших программ, например, антивирусных, программ защиты от SPAM и т.д. В этом случае Интернет позволяет понизить цену для покупателя и издержки для продавца.

    С протокольной точки зрения здесь есть две задачи: обеспечение необходимого, масштабируемого уровня сервиса и гарантирование достаточно высокой безопасности для всех участников. При этом предполагается, что транспортные проблемы решает стэк протоколов Интернет.

    Основы электронной коммерции были заложены с появлением кредитных карт. Но настоящий бум возник после широкого внедрения Интернет, когда появилась возможность доступа к этой сети с домашней ЭВМ. Сейчас вряд ли кто-либо из клиентов Интернет в России покупает ЭВМ или даже бытовую технику, не просмотрев соответствующую информацию в сети и не выбрав поставщика с наилучшим предложением. Электронная торговля возникла из рекламы через Интернет. Сначала фирма создавала свой WEB-сервер, где были представлены товары или услуги с указанием их расценок. Позднее через форму HTML стало возможным сделать заказ. Так появились первые Интернет-магазины. Оплата на первом этапе производилась исключительно через кредитные карточки. Но скоро выяснилось, что существуют области, где кредитные карты не оптимальны (речь идет о покупках с ценами, сопоставимыми с одним центом, а себестоимость операции с кредитной картой относительно высока), да и безопасность первых систем оплаты оставляла желать лучшего. Так появились самые разнообразные схемы платежей.

    За рубежом через Интернет покупаются не только билеты на самолет или в театр, но даже автомобили. Просмотрев предложения в сети, изучив на дисплее интерьер салона и технические параметры, выбрав и оплатив покупку, клиент находит следующим утром ключи от авто в своем почтовом ящике, а саму машину на парковке у дома. Для россиянина это звучит как сказка. Разные торговые системы базируются на удаленном доступе типа telnet (SSH) или на технологии WEB-серверов (SSL).

    Многим знакома компания, торгующая книгами amazon.com. Появились аналогичные предложения по книгам, CD, видеокассетам и другим мелочам и в России. Прогресс этой ветви бизнеса сдерживается отсутствием развитой системы электронных платежей, да и российская банковская система совершенно не отвечает своему основному назначению. По сложившейся традиции российский банкир считает деньги вкладчика своими, и в соответствии с этой концепцией строит свою финансовую политику. Скажу прямо, я не доверю российскому банкиру и рубля, солидный швейцарский, немецкий или американский банк другое дело. А ведь банковское дело не может существовать без доверия.

    Основные проблемы торговли через Интернет

    Проблема доверия не так проста и за рубежом, но уже по иной причине. Программное обеспечение, обслуживающее электронную торговлю и банковские операции, может иметь случайные или преднамеренные ошибки. Достаточно вспомнить банковскую программу, которая при начислении процентов по вкладам всегда округляла результат до цента в меньшую сторону, а разницу (доли цента) переводила на счет автора программы, что при большом числе операций составило многие тысячи долларов. С этой точки зрения желательно, чтобы тексты программ были общедоступны. Но такие программы достаточно сложны, создание их требует больших инвестиций, и по этой причине их тексты обычно составляют коммерческую тайну. А человек должен доверить свои с таким трудом заработанные деньги этой программе. Согласитесь, что это психологически не так просто. По этой причине верификация и сертификация таких программ выступает на лидирующие позиции.

    Эти и многие другие обстоятельства, безусловно, тормозят развитие электронной торговли, но остановить прогресс в этой области даже они не в силах. Электронная коммерция базируется на определенном уровне доверия, риска и надежности, так как получение товара или услуги разнесено по времени с получением денег или платежного документа. Для того чтобы сделка состоялась, партнеры должны быть уверены, что вероятность риска находится на приемлемо низком уровне, а возможная потеря по недобросовестной сделке должна перекрываться прибылью от остальных сделок. На этом принципе существует Интернет-торговля дешевыми товарами - ковриками для мыши или небольшими программами (цена товара или услуги не более 10-30 долларов США). Впрочем, и это относится не к РФ, где царствует предоплата, так как продавец не без основания считает, что вероятность недобросовестности клиента достаточно велика. Все это создает большие неудобства для честных покупателей и ограничивает объемы продаж. Все действующие системы Интернет-магазинов в РФ базируются на доставке и наличной оплате или на различных схемах предоплаты. Не трудно видеть, что эта жуликоватость наносит в конечном итоге ущерб развитию экономики, от которого страдают все граждане. Мне представляется даже, что постепенное внедрение электронной торговли позволит постепенно поменять жизненную философию широкого слоя вовлеченного в этот процесс населения, я уже не говорю о характере самого бизнеса.

    Так как современный бизнес повсеместно базируется на использовании вычислительной техники (ЭВМ, электронные кассовые аппараты, банкоматы и пр.), внедрение электронной коммерции является естественным процессом.

    Любая современная торговая фирма имеет уже работающую систему склад-магазин, учитывающую наличие запасов, объемы продаж по конкретным позициям, что повышает эффективность и позволяет проконтролировать действенность рекламы. А это еще одно приложение Интернет. Вместо широковещательного навязывания всем детских подгузников можно перейти к адресной рекламе. Я страдаю от спама (нелегальная рассылка различных коммерческих, а часто и откровенно мошеннических предложений), но готов получать время от времени информацию о результатах испытаний различных компонентов вычислительной техники и сетевого оборудования (позитивным примером такого рода рекламы можно считать сервер www.tolly.com ). Рекламный бизнес через Интернет в США только в 1995 году принес 55 миллионов долларов, сейчас эти объемы превзойдены более чем на порядок.

    Интернет с его TCP/IP транспортом не может считаться безопасным. По этой причине разработки последних лет были ориентированы на решение этой проблемы. Разработаны протоколы STT (Secure Transaction Technology), SSL, TLS, L2TP, SHTTP, SEPP (Secure Electronic Payment Protocol) и, наконец, SET (Secure Electronic Transactions), предусмотрены специальные меры и в новом протоколе IPv6. Большинство WEB-серверов используют OS UNIX, где администратор системы (root) имеет привилегии, открывающие ему доступ ко всем каталогам и файлам. Это создает еще один источник угроз.

    С начала 90-х годов началось развитие электронных платежных средств на основе кредитных карт со встроенными микропроцессорами (Integrated Circuit Card Specifications for Payment Systems). Такие карты обеспечивают более высокий уровень безопасности, так как могут предложить надежную аутентификацию самой карты и ее владельца. Процессор может использовать записанные в нем индивидуальные ключи шифрования, известные только банку эмитенту карты и/или ее пользователю. Карта имеет 8 внешних контактов (см. раздел 4.5). Стандарт на такие карты описан в документе ISO 7816 (Identification cards - Integrated circuit(s) cards with contacts). Этот стандарт базируется на нескольких более общих стандартах, имеющих отношения к идентификационным картам, - ISO 7810, ISO 7811, ISO 7812 и ISO 7813. Смарт-карта содержит ИС (20х20мм), где на одном кристалле интегрирован 8-битовый процессор, выполняющий все логические и вычислительные операции (10МГц); ROM - память, ориентированная только на чтение, запись в которую производит изготовитель ИС и где хранится операционная система и прикладные программы (16K); EEPROM - ROM с возможностью электрической перезаписи, которая предназначена для записи и хранения балансовых данных и индивидуальной информации владельца карты (8K); RAM> - оперативная память (512 байт); система ввода-вывода (приведенные цифры относятся к карте Mondex). Себестоимость смарт-карты составляет около 5$. Можно быть уверенным, что приведенные цифры к моменту публикации устареют. Карта является объектом, с которой злоумышленник может экспериментировать неограниченно долго с привлечением любой техники.

    Изготовление карты и запись в нее информации производится различными участниками. Разработано ряд дополнительных мер для поднятия уровня безопасности. Код программ в ROM является невидимым, тестовые контакты после контроля содержимого карты дезактивируются. Содержимое программ, занесенных в ROM, закрыто и известно только разработчикам. Запись в EEPROM осуществляется с помощью нескольких команд в строго определенном порядке. Как команды, так и их порядок известны только разработчику и производителю карты. Более того, содержимое EEPROM контролируется с помощью специального хэш-кода. Содержимое EEPROM защищено от воздействия UV-излучения и любых других видов электромагнитного излучения. Ключи шифрования заносятся на карту в процессе персонализации и не могут быть считаны потом. Никакие тексты каких-либо программ никогда не публикуются. Считается, что спецификация для смарт-карт в части безопасности будет в будущем пересмотрена.

    Объединение лидеров в этой области - Europay, MasterCard и VISA разработало спецификацию EMV (по первым буквам фирм участниц; декабрь 1993 года, в 1995-96 опубликованы улучшенные версии). Серьезным ограничением в этой области является отсутствие единого международного стандарта.

    За последние годы разработано много различных систем выполнения платежей: ASH, Achex, BankNet, BidPay, BillPoint, BIPS, CAFE, Cartio, CashBox, CyberCash, DebitNet, DigiCash, DigiGold, eCash, E-gold, EMV, Gmoney, HashCash, iBill, IPAY, iPIN, Kagi, MagnaCash, Mondex, PayCash, PayPal, PayWord, PCPay, PocketPass, MicroMint, Millicent, NetCard, NetCash, NetCheque, NetPay, NetChex, Qpass, QuickCommerce, SOX, SET, TeleCheck, Transfer, WebCharge, WebMoney, WiSP, WorldPay, Ziplock и т.д. (смотри, http://ganges.cs.tcd.ie/mepeirce/Project/oninternet.html), которые обеспечивают расчеты в широком диапазоне требований по надежности и безопасности. Каждому уровню цен, товаров или услуг должен соответствовать определенный вид электронных платежей. Первой безопасной сетевой системой платежей была First Virtual (1995 г). Приведенный перечень систем платежей является достаточно случайным и неполным. Из этого списка ряд систем работают в РФ (например, WebMoney Transfer и PayCash). Разработано и используется уже десятки таких систем, которые прокладывают дорогу чисто электронным деньгам. Область использования наличных бумажных и металлических денег постепенно сужается и со временем этот традиционный вид платежей уйдет в историю (см., например, статью "Будущее денег" http://www.businessweek.com/1995/24/b3428001.htm ). Для РФ новые платежные системы, работающие без кредитных карт, особенно привлекательны, так как число граждан России, имеющих такие карты, незначительно. Внедрение электронных денег, решая многие проблемы, ставит ряд новых.

    1. Кто будет выпускать и регулировать выпуск электронных денег (в случае бумажных денег - это функция центрального национального банка)? Коммерческий банк может предоставить кредитов на сумму, превосходящую наличные депозиты. В случае электронных денег это создает еще большую свободу при операциях такого рода. Уже имеются прецеденты эмиссии электронных денег структурами, не имеющими никакого отношения к банковской системе.
    2. Как будут решаться проблемы налогов? Ведь в этом случае трудно отследить движение денег из-за его глобального характера.
    3. Кто должен определить стандарты на электронные деньги и операции с ними?
    4. Кто и как будет обеспечивать безопасность операций и защиту интересов покупателей-клиентов?

    Список таких вопросов можно существенно расширить. Электронные деньги существенно меняют и функции банков, более того некоторые операции банков могут выполняться другими структурами, например, сетевыми сервис-провайдерами или компаниями-разработчиками программного обеспечения. Так, например, MicroSoft через десятки миллионов пользователей Windows может легко захватить заметный сегмент в сфере предоставления кредитов в виде электронных денег. Интернет здесь может использоваться как при покупке через сеть, так и при оплате традиционной (очной) покупки. Схемы взаимодействия участников сделки могут быть весьма замысловатыми, ведь покупатель может быть в одной стране, продавец - в другой, банк покупателя - в третьей, а банк продавца - в четвертой. Учитывая, что в сделке, кроме того, могут участвовать компания, осуществляющая доставку покупки, и фирма, выполняющая обслуживание товара, например мобильного телефона, ситуация еще более осложняется. Понятно, что необходимо определенное юридическое обеспечение подобного рода операций, но уже это выходит за рамки данной книги.

    Электронная коммерция поменяет современную жизнь также, как Интернет изменил среду общения и доступ к информации.

    В торговле основную прибыль всегда давала информация (знание конъюнктуры рынка, знание производителей и пр.). Современный этап с его взрывным развитием технологий делает этот фактор решающим.

    Несколько лет назад я наблюдал, как в книжном магазине в Гамбурге продавали одну книгу. Вещь достаточно ординарная, если бы не одно обстоятельство, - эта книга печаталась и переплеталась в присутствии покупателя. Название я ее забыл, но помню, что автором был американец. Уже здесь видны определенные проблемы. Как проконтролировать тираж, чтобы авторские права не пострадали, как и где начислять налоги на эту деятельность?

    До недавнего времени программы продавались в коробках, произведенных фирмой разработчиком (практически как книги). Новейшей тенденцией является торговля программами (пока дешевыми) через Интернет. Для этого имеются все средства и предпосылки. Но эта схема порождает немало юридических и коммерческих проблем. Здесь и упомянутая проблема налогов (пока в США торговля через Интернет не облагается налогами), и нарушения авторских прав. Ведь нужно определить, кто должен платить налоги, дилер, продавший программу, или фирма разработчик, а это не безразлично, если они расположены в разных странах. Да и взаимоотношения между дилером и разработчиком нужно как-то урегулировать, так как нужен надежный контроль за проданным количеством копий программы. Где здесь место таможни (пока продавались коробки с программами, были сопроводительные бумаги, на которых можно было после оплаты сбора поставить штамп "Таможня дала добро")? Сходные проблемы ждут разработчиков и продавцов компьютерных игр, музыкальных CD и DVD-дисков, а в перспективе очень многих других товаров.

    Развитию электронной торговли способствуют широко распространенные системы склад-магазин (смотри рис. 2.1 и 2.2). Здесь склад и магазин могут иметь общего хозяина, а могу принадлежать и различным фирмам. Прямого отношения к электронной торговле эти структуры не имеют, но при их создании решались некоторые проблемы и создавались программы, которые могут найти применение в электронной коммерции.

    Рис. 2.1. Простейшая схема системы склад-магазин

    Рис. 2.2. Продвинутая схема системы склад-магазин

    В реальной жизни сервер может размещаться на оптовом складе, который обслуживает сеть магазинов, база данных может быть распределенной и т.д., суть от этого не меняется. В любой из этих схем должна быть решена проблема безопасности и надежности передачи информации, а это роднит эти схемы со схемами электронной торговли. В общем случае взаимоотношения между складом и магазином могут быть исключительно коммерческими, что делает эти объекты субъектами, осуществляющими торговые операции. Взаимоотношения с современным банком в любом случае относится к сфере электронной коммерции. Наличие таких структур заметно стимулирует внедрение электронной торговли, так как эта технология предполагает взаимодействие различных систем распределенных баз данных.

    В общем случае в электронной коммерции могут быть задействованы 5 субъектов - продавец, покупатель, банкир, агент доставки и агент обслуживания. Взаимодействие этих субъектов и документооборот между ними регламентируется протоколом IOTP.

    Теперь попытаемся проанализировать, в чем заключаются преимущества и недостатки электронной торговли для покупателя и продавца.

     

    Преимущества

    Недостатки

    Покупатель

    Возможность выбора и приобретения товара или услуги, не выходя из дома (экономия времени).

    Отсутствие возможности ознакомиться со свойствами товара до его приобретения

    Относительная анонимность покупки

    Угроза злоупотреблений в случае раскрытия номера кредитной карты

    Немедленная доставка и сопровождение программ при покупке их через сеть

    Как правило, невозможность возврата товара при обнаружении неприемлемого качества

    Получение новых недоступных ранее услуг в сфере развлечений, консультаций, обучения, подписка на газеты, ком-мерческую информацию и пр.

     

    Получение дополнительной информации о необходимых товарах

    Назойливость почтовой рекламы (SPAM)

    Продавец

    Расширение числа покупателей при неизменных торговых площадях

    Дополнительные издержки на внедрение системы

    Возможность автоматического выявления и регистрации IP>-адресов потенциальных клиентов

    Потенциальная угроза нанесения ущерба хакерами

    Дополнительная реклама через Интернет

    Возможность кражи программ при торговле через сеть (неоплата покупки)

    Облегчение взаимодействия с обслуживающими банками и партнерами, если эта проблема не была решена раньше

     

    По специфике взаимодействия продавца и покупателя выделяются несколько областей бизнеса. К таким областям относятся взаимодействия клиент-клиент P2P (Person-to-Person), продавец-покупатель B2C (Business-to-Consumer) и бизнесмен-бизнесмен B2B (Business-to-Business). Деление это достаточно условно, один и тот же субъект в одних операциях выступает как покупатель в других как продавец.

    Схема P2P работает при распродаже старых компонентов ЭВМ, книг, кустарных изделий и пр. их владельцами, при обмене и покупке-продаже различных предметов коллекционерами, а также при оказании услуг по ремонту настройке сложного бытового оборудования или, например, в сфере индивидуального обучения.

    Более перспективной представляется схема B2C>, именно к этому классу относятся практически все Интернет-магазины. В РФ пару лет назад возник бум создания таких структур. Даже ТВ было привлечено к рекламе некоторых из них. Пожалуй, это было несколько преждевременно. Сохранились лишь несколько книжных магазинов, торговля бытовой техникой, произведениями искусства, лекарствами и т.д.. Пытаются выжить некоторые Интернет-аукционы, которые по своей функции являются, чем-то средним между B2C и P2P. Следует обратить внимание, что почти все они не используют сетевых платежных систем. Во многих случаях отсутствие коммерческого успеха связано с тем, что такие магазины не дают сверхприбылей, но требуют получения лицензий и других начальных инвестиций. Сюда относится и отсутствие достаточного платежеспособного спроса у той части населения, которая знакома с технологиями Интернет и имеет к нему доступ, неразвитая кредитная и банковская системы.

    В РФ более успешной оказалась область В2В, охватывающая оптовую торговлю медикаментами, металлами, нефтепродуктами, стройматериалами и т.д.. Но даже здесь этот бизнес сильно отличается от аналогичной деятельности, скажем, в США.

    Как уже отмечалось выше, торговля сопряжена не только с оплатой товара и его получением, но с немалым объемом документов (заказы, счета, чеки, накладные, расписки, платежные поручения и т.д.). В настоящее время специально для торговли через Интернет разработан открытый протокол торговли через Интернет IOTP (Internet Open Trading Protocol).

    Previous: 4.5.17 Сетевое моделирование    UP: 4.5.8 Поиск узлов и людей
    Down: 5 Диагностика локальных сетей и Интернет    Next: 4.6.1 Открытый торговый протокол Интернет- IOTP версия 1.0


    previous up down next index index
    Previous: 5.1 Сетевая диагностика с применением протокола SNMP    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность
        Next: 5.3 Применение 6-го режима сетевого адаптера для целей диагностики

    5.2 Диагностика на базе ICMP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Безусловно SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не дает решить все проблемы. Не все объекты в Интернет имею активные SNMP-агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах.

    Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика может произойти из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты mac-уровня). Если сеть правильно сконфигурирована, реализуются только так называемые "короткие" столкновения, когда столкновение происходит не позднее, чем при передаче 64-го байта. Но если при построении сети допущены ошибки, возможны более поздние столкновения, что становится дополнительной причиной потери пакетов. Тогда может проявиться зависимость вероятности столкновения от длины пакета.

    Следует учитывать, что если столкновение зафиксировано передающей стороной до завершения посылки пакета, то потери пакета не произойдет, так как передача будет повторена на физическом уровне. Потеря из-за столкновения может произойти только для короткого пакета при слишком больших задержках в логическом сегменте.

    Понятно, что вероятность столкновений пропорциональна плотности вероятности потока запросов от активных узлов логического сегмента (зоны столкновений). По этой причине, зондируя определенный удаленный логический сегмент можно оценить вариации загрузки.

    Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP-протокола.

    При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов.

    Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента позволяет оперативно локализовать неисправный сетевой элемент (см. рис. 5.2.1). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это позволяет даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.

    Рис. 5.2.1. Схема, поясняющая диагностические возможности протокола ICMP

    Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена). Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, а известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, обслуживающие многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы.

    Сканируя всю сеть периодически в течение суток и регистрируя процент потерь пакетов в сети, можно выявить и неисправные сетевые интерфейсы. Такой интерфейс при включении может портить условия распространения пакетов по сегменту. Обнаружив корреляцию между повышением вероятности потерь пакетов и включением определенной ЭВМ, можно сделать именно такой вывод и позднее независимо исследовать именно этот сетевой интерфейс.

    Протокол ICMP можно использовать и для измерения размера зоны столкновений, что крайне важно для успешной работы локальной сети, ведь превышение предельного размера зоны приводит к резкому росту числа столкновений. Вычислить размер зоны бывает затруднительно, так как для повторителей и концентраторов довольно часто время задержки не указывается. Разумеется, что оно должно быть меньше предельно допустимого, разрешенного документом 802.3, но кто может дать гарантию? Для решения поставленной задачи следует использовать ICMP пакеты минимальной длины. Программа посылает пакеты ICMP и воспринимает отклики, регистрируя долю потерянных пакетов. Для зондирования выбирается самая удаленная рабочая станция или сервер (см. рис. 5.2.2). Программа должна уметь посылать ICMP-пакеты, не дожидаясь отклика. Пакеты посылаются парами с зазором между ними t. Далее варьируем t и добиваемся максимума вероятности потери пакетов. Зазор t, при котором будет достигнут максимум потерь, соответствует реальному значению задержки, характеризующей зону столкновений для данного логического сегмента сети. Периодическая посылка пакетов слишком сильно перегрузит сеть, именно по этой причине следует периодически посылать пары пакетов. При этом период посылки таких пар должен быть достаточно велик, чтобы исключить влияние процессов восстановления после столкновения (> 1сек).

    Рис. 5.2.2. Схема зондирования

    RTT в данном случае равно 2Т+t, где t - время задержки отклика в зондируемой ЭВМ. Зазор между пакетами t должен быть больше t. Если t больше Т, то точность измерения будет невелика. Можно подумать, что при t ё t вероятность столкновения будет равна 100%, но это не так. В этом случае столкновения не будет, ведь интерфейс обнаружит несущую у себя на входе и передачу не начнет. Передача отклика может начаться не ранее 9,6 мксек после завершения первого пакета-зонда (IPG). Если t < 9,6 мксек, передача отклика начнется через 9,6 мксек, если же больше, то через t. На практике 100% потери за счет столкновений будут реализовываться при t < t < Т+t (при t > 9,6 мксек). При t > t+t столкновения не будет, так как до измерительной машины дойдет пакет от исследуемой ЭВМ и передача не начнется из-за обнаружения интерфейсом несущей в кабельном сегменте. Следует иметь в виду, что при детектировании столкновения обе ЭВМ попытаются через некоторое время повторить попытку. Эта попытка вероятнее всего увенчается успехом, ведь они начнут ее не одновременно. Для извлечения нужных данных надо считывать содержимое регистра интерфейса, где записывается число случаев столкновений. Определив диапазон временных зазоров между пакетами-зондами, при которых происходят столкновения со 100% вероятностью, мы получим значение Т. Здесь требуются достаточно точные часы с разрешающей способностью лучше 10 мксек. Если таких часов нет, можно использовать время исполнения команд, предварительно прокалибровав это время при достаточно большом числе их исполнения.

    Ниже на рисунке 5.2.3 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа позволяет не только отображать такого рода диаграммы но и измеряет относительные потери для различных сегментов сети (написана Сергеем Тимохиным). Предусмотрена возможность вывода списка машин активных в любой заданный интервал времени. По горизонтали отложено время суток 0-24 часа, а по вертикали - число ЭВМ, присылающих отклики на icmp-запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)

    Рис. 5.2.3. Пример круглосуточного мониторинга активности в сети с использованием ICMP-зондирования

    Другим примером такого мониторинга могут служить программы, контроля внешних каналов ИТЭФ и связей в пределах локальной сети. Смотри страницы:

    http://saturn.itep.ru/trace/intern/start.htm
    и
    http://saturn.itep.ru/trace/extern/start_trace.htm

    Previous: 5.1 Сетевая диагностика с применением протокола SNMP    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность    Next: 5.3 Применение 6-го режима сетевого адаптера для целей диагностики


    previous up down next index index
    Previous: 5.2 Диагностика на базе ICMP    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность
        Next: 5.4 Причины циклов пакетов и осцилляции маршрутов

    5.3 Применение 6-го режима сетевого адаптера для целей диагностики
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Использование 6-го режима работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты адресованные ей, а также широковещательные и мультикастинг пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля.

    6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности.

    6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, accounting database в случае маршрутизаторов Cisco), но 6-й режим предоставляет большую гибкость и возможности.

    К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис. 5.3.1).

    Рис. 5.3.1.

    Выделенная ЭВМ может полностью отслеживать трафик из зоны сети "C" и лишь транзитный поток пакетов для зон "A" "B" и "D" (например, из зоны А в зону D). Пакеты внутреннего трафика для зон А, В и D не доступны.

    Previous: 5.2 Диагностика на базе ICMP    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность    Next: 5.4 Причины циклов пакетов и осцилляции маршрутов


    previous up down next index index
    Previous: 5.3 Применение 6-го режима сетевого адаптера для целей диагностики    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность
        Next: 5.5 Конфигурирование сетевых систем

    5.4 Причины циклов пакетов и осцилляции маршрутов
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Для рядового пользователя информация данного раздела не может представлять никакого интереса. Некоторые продвинутые пользователи иногда могут обратить внимание на то, что программа traceroute начинает (вместо нормального отображения пути до цели) выдавать попеременно имена двух соседних узлов. Это может позабавить, если конечно не влияет на решение пользователем его текущих задач. Но в любом случае вмешаться и исправить что-либо он не в силах. О причинах такого поведения сети можно прочесть в разделах, посвященных вопросам маршрутизации.

    Начнем с локальных сетей. В разделе о мостах 4.1.1.4, там где говорилось об алгоритме "расширяющееся дерево" отмечалась недопустимость того, чтобы две ЭВМ в локальной сети могли соединяться друг с другом различными путями. Здесь подразумевается соединение через систему мостов, повторителей/концентраторов и переключателей. Такого рода соединение через маршрутизаторы допустимо, но и там следует к этому относиться с определенной осторожностью. Рассмотрим фрагмент сети, изображенный на рис. 5.4.1.

    Рис. 5.4.1. Пример ошибочной топологии локальной сети

    Пакеты от машины 1 через концентратор 1 и 2 попадут в концентратор 2, эти же пакеты попадут туда через мост. В результате возникнет встречное кольцевое движение идентичных пакетов. Кроме того, переключатели и мост попытаются разобраться с этим безобразием и начнут посылать широковешательные пакеты, чтобы выяснить с каким из портов на самом деле связаны эти ЭВМ. Они от рождения убеждены, что одна и та же ЭВМ может быть доступна только через один порт. Таким образом, всплески загрузки сети, особенно широковещательной, должны привлекать внимание администратора. В данном примере, если система переключателей и мостов не поддерживает алгоритма "расширяющееся дерево", администратор сам должен разорвать эту кольцевую структуру.

    Зацикливание пакетов возможно также при использовании внутреннего протокола маршрутизации IGRP, где некорректный выбор параметра вариация приводит к тому, что система при распределении потоков по нескольким направлениям воспринимает путь "назад", как вполне приемлемый.

    Еще один вариант циклов пакетов возникает при использовании маршрутов по умолчанию (более детально это описано в разделе, посвященном маршрутизации 4.4.11). Так при наличии канала между сетями А и Б внешние маршрутизаторы этих сетей сконфигурированы так, что в сети А пакет адресованный не А, направляется в Б, а в сети Б все пакеты с местом назначения не Б, направляются сети А. Такая конфигурация возможна и она будет работать нормально до тех пор, пока в одной из сетей не появится пакет с ошибочным адресом, не соответствующем ни сети А, ни Б. Такой пакет будет двигаться между сетями А и Б до тех пор пока не выработает свой ресурс по TTL.

    Похожие проблемы возникают при реализации, например, протокола маршрутизации RIP (см. раздел 4.4.11.1), что сильно замедляет там процедуру установления равновесного маршрута.

    Протоколы маршрутизации работают с системами, где имеют место огромные задержки. И как всякая система управления с задержанной обратной связью такие системы склонны к осцилляциям. Допустим некоторый узел, оценив метрику нескольких маршрутов, принял решение перейти на новый маршрут. Если он это сделает, об этом окружающие маршрутизаторы узнают с заметной задержкой и соответствующим образом изменят свои оценки метрик фрагментов пути. Когда (снова с задержкой) исходный маршрутизатор получит информацию об этих оценкам, может случится, что старый маршрут окажется предпочтительнее нового, и все начнется сначала.

    Рассмотренные в данном разделе относительно экзотические явления (кроме примера из локальных сетей, здесь имеет место не экзотика, а стихийное бедствие) встречаются не так часто, но администратор сети должен принимать в расчет и такие возможности. Любой из упомянутых эффектов может сильно ухудшить эксплуатационные параметры сети, а то и вовсе вывести ее из строя.

    Previous: 5.3 Применение 6-го режима сетевого адаптера для целей диагностики    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность    Next: 5.5 Конфигурирование сетевых систем


    previous up down next index index
    Previous: 5.4 Причины циклов пакетов и осцилляции маршрутов    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность
        Next: 6 Сетевая безопасность

    5.5 Конфигурирование сетевых систем
    Семенов Ю.А. (ГНЦ ИТЭФ)

    От корректности конфигурации сети зависит ее эффективная работа, надежность и безопасность. К сожалению набор параметров, определяющих конфигурацию, сильно зависит от используемой операционной системы и конкретного сетевого программного обеспечения. Большинство локальных сетей сегодня строятся вокруг серверов, которые работают под ОС UNIX (если не считать одноранговых сетей MS Windows). По этой причине ниже будут описаны конфигурационные файлы именно этой ОС. Название конфигурационных файлов и их назначения приведены в таблице 5.5.1.

    Таблица 5.5.1. Конфигурационные файлы

    Название файла

    Назначение

    /etc/hosts

    База данных имен ЭВМ и их IP-адресов (ею пользуются такие утилиты, как ping и ifconfig)

    /etc/networks

    База данных имен ЭВМ и их MAC-адресов (адресов сетевых карт)

    /etc/ethers

    Опционный файл, который содержит имена субсетей, их сетевые маски или сетевые адреса доменов

    /etc/protocols

    Конфигурационный файл, где содержится перечень имен поддерживаемых протоколов и их кодов. Первое поле содержит официальное название протокола, далее следует код протокола, третье поле содержит псевдоним протокола.

    /etc/services

    Файл, определяющий взаимодействие в системе клиент-сервер. Первое поле содержит название процесса (Echo, tcpmux, systat, netstat, chargen, TFTP, NNTP, POP-3, login, talk и т.д.), второе поле хранит номер порта и имя протокола.

    /etc/syslog

    Определяет типы сообщений и проход к log-файлу

    /etc/inetd.conf

    Содержит последовательность записей, определяющих работу протоколов Интернет: имя услуги (из файла /etc/services); тип сокета (stream, dgram, raw или rdm); протокол (из файла /etc/protocols); статус ожидания (wait-status); пользователь; проход к серверу.

    /etc/routed

    Используется при загрузке системы, определяет взаимодействие с другими машинами

    /etc/passwd

    Содержит информация для идентификации пользователей и их паролей

    /etc/hosts.equiv

    Содержит имена машин и пользователей, что позволяет авторизованному пользователю входить в другие машины, не вводя пароль.

    /etc/bootptab

    Определяет адреса и загрузочные файлы

    /etc/snmp.conf

    Определяет содержимое поля community и допустимые адреса

    /etc/resolv.conf

    Служба имен. Определяет имя локального домена и следующего вышестоящего сервера имен.

    /etc/named.boot

    Определяет положение баз данных, других серверов имен и доменов, обслуживаемых named.

    /usr/local/domain/named.fwd

    База данных имен для обычных запросов. Проход может быть и иным, он указывается в named.boot.

    /usr/local/domain/named.rev

    База данных сервера имен для запросов в IN-ADDR.ARPA. Замечание о проходе в предшествующем пункте справедливо и здесь.

    /usr/local/domain/named.ca

    База данных сервера имен для инициализации кэша. Замечание о проходе для named.fwd справедливо и здесь. Смотри также документ RFC-1033. Содержимое файла можно прочитать с помощью процедуры nslookup.

    Файл /etc/passwd содержит записи аутентификационных параметров пользователей. Каждая запись содержит 7 полей. В первом поле записано имя пользователя (LOGIN ID) в представлении ASCII. Второе поле содержит зашифрованный пароль пользователя. Шифрование осуществляется с добавлением символов, что делает обратную дешифровку невозможной. Причем одно и то же слово при таком методе может быть зашифровано различным способом. Третье поле является числовым номером пользователя (UID). В четвертом поле записывается код группы пользователей, к который принадлежит данный клиент. Пятое поле содержит комментарий администратора. В шестом поле хранится имя базового каталога пользователя. В заключительном поле записывается имя командного интерпретатора, который будет использоваться по умолчанию. В новейших версиях UNIX файл /etc/passwd содержит только "x" во втором поле записи для каждого пользователя, что указывает на использование файла /etc/shadow, где в зашифрованном виде содержатся пароли пользователей. Доступ к этому файлу имеет только администратор. Информация о членах групп пользователей хранится в файле /etc/group/.

    Файл /usr/lib/aliases используется для создания почтовых ящиков, которым не соответствуют какие-либо аккоунты. Здесь прописываются псевдонимы, которым система пересылает поступающие почтовые сообщения. Строка переадресации в этом файле имеет форму:
    alias: имя_пользователя или
    alias: имя_пользователя_1, имя_пользователя_2, ..., имя_пользователя_N.

    В первом случае вся почта приходящая alias переадресуется пользователя с указанным именем. Во втором - всем пользователям, имена которых представлены в списке. Если список не умещается в одной строке, перед вводом "возврата каретки" следует напечатать символ "/". В качестве аккоунтов могут использоваться как локальные так и стандартные почтовые адреса. Для особо длинных списков можно ввести специальную строку в файл /usr/lib/aliases:
    authors:":include:/usr/local/lib/authors.list", где authors - псевдоним, а authors.list - файл, содержащий список адресатов, кому следует переслать сообщение.

    Наиболее мощной и по этой причине наиболее опасной возможностью файла псевдонимов является переадресация входной почты программе, указанной в псевдониме. Когда первым символом имени аккоунта в псевдониме является вертикальная черта (|), то управление будет передано программе, чье имя следует за этим символом, а входные почтовые сообщения будут передаваться этой программе, например строка:

    listserv: "|/usr/local/bin/listserv -l"

    обеспечит пересылку почты программе listserv, как если бы исполнялась команда cat mailfile|listserv -l. Эта техника используется для интерпретации содержимого поля subject или тела сообщения в качестве команд управления подписными листами.

    Файл named.boot, который служит для инициализации сервера имен, имеет следующую структуру. Строки, начинающиеся с точки с запятой являются комментариями. Строка sortlist определяет порядок, в котором выдаются адреса сервером, если их число в отклике превышает 1. Запись directory, описывает положение информационных файлов (имя проход/каталога). Строка cashe, служит для инициализации кэша сервера имен с использованием файла named.ca. Этот также как и другие файлы должны находиться в каталоге, указанном в записи directory. Записи primary указывают, в каких файлах размещена информация таблиц соответствия имен и IP-адресов. Последняя запись primary содержит информацию для локальной ЭВМ. В записях secondary специфицируется данные, которые должны считываться с первичного сервера и из локальных файлов.

    В файле named.local содержится локальный интерфейс обратной связи сервера имен. Файл включает в себя только одну запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первого поля записи задает имя зоны. Четвертое поле этой записи содержит имя первичного сервера имен данного субдомена, а следующее поле хранит имя администратора, ответственного за данный субдомен (его почтовый адрес). Запись SOA включает в себя список из 5 чисел, заключенный в скобки.

    • Версия или серийный номер. Первое число в списке увеличивается каждый раз при актуализации файла. Вторичные серверы имен проверяют и сравнивают номер версии файла первичного сервера с имеющимся у них кодом, для того чтобы определить, следует ли копировать базу данных DNS.
    • Время обновления (refresh time). Определяет время в секундах, задающее период запросов вторичного DNS к первичному.
    • Время повторной попытки. Задает время в секундах, когда вторичный сервер имен может повторить запрос в случае неудачи предыдущего.
    • Время истечения пригодности (expiration time). Верхний предел временного интервала в секундах по истечении которого база данных вторичного DNS считается устаревшей без проведения актуализации.
    • Минимум. Значение по умолчанию для таймера TTL для экспортируемых ресурсных записей.

    Файл /etc/hosts.equiv позволяет составить список ЭВМ, объединенных в группу. Пользователь, находящийся в одной из ЭВМ этой группы, может установить связь с другой, не вводя своего пароля. Понятно, что применение этого метода входа, предоставляя некоторые удобства, создает и определенные угрозы с точки зрения сетевой безопасности.

    Файл .rhosts, который размещается в корневом каталоге пользователя, позволяет ему описать список ЭВМ, куда он имеет доступ. При этом появляется возможность войти из данной ЭВМ в любую из названных машин без ввода пароля. Замечания об использовании файла hosts.equiv в полном объеме справедливы и в данном случае.

    Если к ЭВМ подключены модемы, необходимо применение так называемого dialup-пароля. Удаленный пользователь помимо своего ID и пароля должен ввести еще и dialup-пароль, который является общим для всех работающих на данной ЭВМ. Если все три параметра аутентификации корректны, доступ будет разрешен. При ошибке в любом из трех компонентов ЭВМ попросит повторить их ввод, не указывая, где совершена ошибка. Файл /etc/dpasswd является исполняемым и может реализовать ряд опций.

    • a [список] характеризует список терминалов, который добавляется к /etc/dialups. Пользователь при входе с такого терминала должен будет ввести пароль dialup. Элементы в списке заключаются в кавычки и разделяются пробелами или запятыми.
    • d [список] определяет список терминалов, которые должны быть удалены из /etc/dialups и пользователю будет не нужно в будущем вводить пароль dialup при входе с этих терминалов.
    • r [список] меняет login shell на /bin/sh для каждого из пользователей, перечисленных в списке.
    • s [shell] модифицирует запись в файле /etc/d_passwd или добавляет новую запись.
    • u [список] создает новое ядро (shell) для имен, указанных в списке. Добавляются записи в etc/d_passwd для нового ядра, а пароль работает для всех пользователей из списка, если не оговорено обратного.
    • x [shell] удаляет shell и пароль из файла /etc/d_passwd

    Previous: 5.4 Причины циклов пакетов и осцилляции маршрутов    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность    Next: 6 Сетевая безопасность


    previous up down next index index
    Previous: 4.6.4 Смарт-карты EMV    UP: 4.5.8 Поиск узлов и людей
    Down: 6 Сетевая безопасность
        Next: 5.1 Сетевая диагностика с применением протокола SNMP

    5 Диагностика локальных сетей и Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    5 Диагностика локальных сетей и Интернет

    15

    91

    5.1 Сетевая диагностика с применением протокола SNMP

    14

    209

    5.2 Диагностика на базе ICMP

    4

    23

    5.3 Применение 6-го режима сетевого адаптера для целей диагностики

    2

    12

    5.4 Причины циклов пакетов и осцилляции маршрутов

    2

    14

    5.5 Конфигурирование сетевых систем

    3

    15

    Читатели неизбежно делятся на две категории:

    а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство).
    б. Пользователи сети, кто вынужден эту среду осваивать и в ней жить.

    Вторая категория, в силу своего численного превосходства, способна задать столько вопросов, на которые первая, даже будучи столь же многочисленной, не смогла бы ответить. Вопросы бывают простые, например:

    "Почему не работает электронная почта?" (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: "Как уменьшить задержку отклика, если канал перегружен?"

    Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ЭВМ) и многопротокольных сетей (Novell, DECnet, TCP/IP, AppleTalk и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:

    • связана проблема с оборудованием или программным обеспечением;
    • отказ вызван повреждением программы, неверным выбором конфигурации или ошибочными действиями оператора.

    Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.).

    В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части. По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Но не следует пренебрегать такими простыми средствами, как отсутствие обрыва или закоротки сетевого кабеля. Нужно помнить, что сопротивление сегмента толстого коаксиального кабеля не должно превышать 5 Ом, тонкого - 10 Ом, а скрученные пары не должны иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом (24AWG) из расчета на 100 м.

    Следует помнить, что сетевая диагностика является основой сетевой безопасности. Только администратор, знающий все о том, что происходит в сети, может быть уверен в ее безопасности.

    Ниже будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС. Сложные (дорогостоящие, но весьма эффективные) аппаратно-программные диагностические комплексы здесь не рассматриваются. Проблемы маршрутизации и конфигурирования системы также выходят за рамки данного рассмотрения.

    В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump (lss:os2warez@merlin.itep.ru ftp.ee.lbl.gov/tcpdump.tar.Z, для SUN или BSD 4.4; ftp.ee.lbl.gov.libpcap.tar.Z), netwatch (windom.ucar.edu), snmpman (http://www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp.eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de /windows/util). Программа tcpdump создана в университете Калифорнии и доступна по адресу ftp.ee.lbl.gov. Эта программа переводит интерфейс ЭВМ в режим приема всех пакетов, пересылаемых по данному сетевому сегменту. Такой режим доступен и для многих интерфейсов IBM/PC (например, популярный NE2000 Eagle, mode=6), но tcpdump на этих машинах не работает. Tcpdump написана на СИ, она отбирает и отображает на экране пакеты, посылаемые и получаемые данным интерфейсом. Критерии отбора могут варьироваться, что позволяет проанализировать выполнение различных сетевых процедур. В качестве параметров при обращении к программе могут использоваться наименования протоколов, номера портов и т.д., например, tcpdump TCP port 25. Существует довольно большое число модификаторов программы (опций). К сожалению для рядовых пользователей программа не доступна - требуются системные привилегии. Описание применения программы можно найти по указанному выше адресу, а также в [10]. Другой полезной служебной программой является sock (socket или sockio). Эта программа способна посылать TCP и UDP пакеты, она может работать в четырех режимах.

    1. Программа устанавливает канал клиент-сервер и переадресует стандартный ввод серверу, а все полученные пакеты от сервера переправляет на стандартный вывод. Пользователь должен специфицировать имя сервера или его адрес и наименование операции или номер порта, ей соответствующий.

    2. Работа в режиме диалогового сервера (опция -s). В этом режиме параметром операции является ее имя или номер порта (или комбинация IP-адреса и номера порта), например: sock -s 100. После установления связи с клиентом программа переадресовывает весь стандартный ввод клиенту, а все что посылается клиентом, отправляет на стандартный вывод.

    3. Режим клиента-отправителя (опция -i). Программа выдает в сеть заданное число раз (по умолчанию 1024) содержимое буфера с объемом в 1024 байта. Опции -n и -w позволяют изменить число и размер посылок.

    4. Режим приема и игнорирования данных из сети (опция -i и -s).

    Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС MS-DOS, UNIX, Windows NT, VMS и других: ping, tracetoute, netstat, arp, snmpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery. Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты. Сводный перечень конфигурационных и диагностических команд набора протоколов TCP/IP представлен в таблице 5.1.

    Таблица 5.1.

    Название команды

    Назначение

    arp

    Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса)

    chnamsv

    Служит для изменения конфигурации службы имен на ЭВМ (для TCP/IP)

    chprtsv

    Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере

    gettable

    Получает таблицы ЭВМ в формате NIC

    hostent

    Непосредственно манипулирует записями адресного соответствия ЭВМ в конфигурационной базе данных системы

    hostid

    Устанавливает или отображает идентификатор данной ЭВМ

    hostname

    Устанавливает или отображает имя данной ЭВМ

    htable

    Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки

    ifconfig

    Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP)

    ipreport

    Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла

    iptrace

    Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет

    lsnamsv

    Отображает информацию базы данных DNS

    lsprtsv

    Отображает информацию из базы данных сетевой службы печати

    mkhost

    Создает файл таблицы ЭВМ

    mknamsv

    Конфигурирует службу имен клиента (для TCP/IP)

    mkprtsv

    Конфигурирует службу печати ЭВМ (для TCP/IP)

    mktcpip

    Устанавливает требуемые величины для запуска TCP/IP на ЭВМ

    namerslv

    Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы

    netstat

    Отображает состояние сети

    no

    Конфигурирует сетевые опции

    rmnamsv

    Удаляет TCP/IP службу имен из ЭВМ

    rmprtsv

    Удаляет службу печати на машине клиента или сервере

    route

    Служит для ручного манипулирования маршрутными таблицами

    ruptime

    Отображает состояние каждой ЭВМ в сети

    ruser

    Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступом внешних ЭВМ к программам

    securetcpip

    Активизирует сетевую безопасность

    setclock

    Устанавливает время и дату для ЭВМ в сети

    slattach

    Подключает последовательные каналы в качестве сетевых интерфейсов

    timedc

    Присылает информацию о демоне timed

    trpt

    Выполняет отслеживание реализации протокола для TCP-сокетов

    Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet [4]. Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. Обычно эта машина базируется на ОС UNIX. DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ЭВМ имеют SNMP-резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC-1256, 1885, -1788, -792).

    Протокол ICMP используется в наиболее популярной диагностической программе ping входит в поставку практически всех сетевых пакетов). Возможная форма вызова этой программы имеет вид:

    ping <имя или адрес ЭВМ или другого объекта> [размер пакета] [число посылок]

    размер пакета задается в байтах (по умолчанию равно 56). Процедура выполнения ping может быть прервана нажатием клавиш ctrl-C. В различных реализациях программа ping имеет много различных опций, которые позволяют измерять статистические характеристики канала (например, потери), определение задержки в канале (RTT), отображение посылаемых пакетов и получаемых откликов, а также определение маршрута до интересующего объекта. Ping используется для определения доступности сервис-провайдера и т.д. Иногда ping является составной частью более мощной диагностической программы (например, netwatch). Ниже приведен пример использования команды tracetoute, которая во многом эквивалентна ping (но базируется непосредственно на IP, используя соответствующие опции):

    traceroute kirk.Bond.edu.au (посмотрим, как идут пакеты до этого сервера в Австралии)

    (IP-адрес=131.244.1.1 узнан, зондирование начинается, допустимо не более 30 шагов)

    traceroute to kirk.Bond.edu.au (131.244.1.1) 30 hops max, 40 byte packets
    1 ITEP-FDDI-BBone (193.124.224.50) 2 ms 2 ms 2 ms
    2 MSU-Tower-2.Moscow.RU.Radio-MSU.net (194.67.80.65) 3 ms 3 ms 3 ms
    3 NPI-MSU.Moscow.RU.Radio-MSU.net (194.67.80.5) 4 ms 3 ms 3 ms
    4 NPI-P.Moscow.RU.Radio-MSU.net (194.67.80.18) 4 ms 5 ms 4 ms
    5 DESY-P.Hamburg.DE.Radio-MSU.net (194.67.80.14) 317 ms 310 ms 329 ms
    6 DESY.Hamburg.DE.Radio-MSU.net (194.67.82.17) 312ms 320ms 312ms (маршрут через Германию)
    7 188.1.56.5 (188.1.56.5) 321 ms 357 ms 327 ms
    8 188.1.56.10 (188.1.56.10) 347 ms 467 ms 356 ms
    9 DE-f0-0.eurocore.bt.net (194.72.24.193) 331 ms 337 ms 331 ms
    10 NL-s1-1.eurocore.bt.net (194.72.24.202) 355 ms 435 ms 343 ms
    11 NL-f0.dante.bt.net (194.72.24.2) 367 ms 353 ms 573 ms
    12 New-York2.dante.net (194.72.26.10) 497ms 493ms 489ms (пересекли Атлантический океан)
    13 f1-0.t32-0.New-York.t3.ans.net (204.149.4.9) 546 ms 501 ms 490 ms
    14 h5-0.t36-1.New-York2.t3.ans.net (140.223.33.10) 540 ms 506 ms 571 ms
    15 * f2.t36-0.New-York2.t3.ans.net (140.223.36.221) 503 ms 505 ms
    16 h13.t40-0.Cleveland.t3.ans.net (140.223.37.10) 802 ms 795 ms 523 ms
    17 h14.t24-0.Chicago.t3.ans.net (140.223.25.9) 537 ms 509 ms 526 ms
    18 h13.t96-0.Denver.t3.ans.net (140.223.25.18) 545 ms 531 ms 545 ms
    19 h12.t8-0.San-Francisco.t3.ans.net (140.223.9.17) 853 ms 584 ms 592 ms
    20 border2-fddi1-0.SanFrancisco.mci.net (206.157.77.1) 563 ms 591 ms 753 ms
    21 telstra-ds3.SanFrancisco.mci.net (204.70.33.10) 691 ms * 691 ms
    22 telstra.SanFrancisco.mci.net (204.70.204.6) 759 ms 815 ms 753 ms (достигли Тихого океана)
    23 Fddi0-0.pad-core2.Sydney.telstra.net (139.130.249.227) 766 ms 1054 ms 837 ms (океан позади - Австралия!)
    24 Serial4-4.cha-core1.Brisbane.telstra.net (139.130.249.202) 781 ms 776 ms 810 ms
    25 qld-new.gw.au (139.130.247.227) 836 ms 917 ms 806 ms
    26 139.130.5.2 (139.130.5.2) 816 ms 796 ms 811 ms
    27 203.22.86.241 (203.22.86.241) 800 ms 787 ms 838 ms
    28 203.22.86.194 (203.22.86.194) 850 ms 790 ms 768 ms
    29 kirk.Bond.edu.au (131.244.1.1) 781 ms (ttl=226!) 918 ms (ttl=226!) 799 ms (ttl=226!)

    Цель достигнута за 29 шагов! (Путь бывает и длиннее, но редко).

    Программа traceroute посылает по три пакета с нарастающими значениями TTL, если отклик на пакет не получен печатается символ *. Большие задержки (RTT) в приведенном примере определяются спутниковыми каналами связи (время распространения сигнала до спутника!).

    Для того чтобы правильно реагировать на нештатные ситуации, надо хорошо представлять себе, как сеть должна работать в нормальных условиях. Для этого надо изучить сеть, ее топологию, внешние связи, конфигурацию программного обеспечения центральных серверов и периферийных ЭВМ. Следует иметь в виду, что изменение конфигурации является обычно привилегией системного администратора и в любых сомнительных случаях нужно обращаться к нему. Неквалифицированные действия при реконфигурировании системы могут иметь катастрофические последствия.

    Сетевое оборудование, имеющееся в BSD UNIX-системе, описано в документации intro(4), которая доступна через справочную систему man, например:

    man - 4 intro | grep Ether (Выделенная строка представляет собой команду, введенную с клавиатуры, следующий за ней текст - отклик ЭВМ на эту команду)
    a network interface for the 10-Megabit Ethernet, along with
    SunOS supports the 10-Megabit Ethernet as its primary net-
    ie ie(4S) Intel 10 Mb/s Ethernet interface
    le le(4S) LANCE 10Mb/s Ethernet interface

    Для того чтобы получить дополнительную информацию об этих интерфейсах, можно выдать команду dmesg (или просмотреть файл /usr/adm/messages):

    dmesg | grep le0
    le0 at SBus slot f 0xc00000 pri 6 (onboard)
    le0: AUI Ethernet

    Работа сетевого обеспечения базируется на нескольких резидентных программах (демонах): routed и gated (маршрутизация), named (сервер имен), inetd (Интернет услуги). Перечень демонов базовых услуг представлен в таблице 5.2.

    Таблица 5.2. Основные TCP/IP демоны

    Название демона

    Назначение

    fingerd

    Предоставляет информацию об удаленном пользователе

    ftpd

    Реализует функции сервера передачи файлов (протокол FTP)

    gated

    Реализует функции маршрутизации шлюза для протоколов RIP, HELLO, EGP, BGP и SNMP

    inetd

    Реализует управление сетевыми услугами Интернет

    named

    Реализует услуги сервера имен (DNS)

    rexecd

    Реализует серверные функции для команд rexec (удаленное исполнение)

    rlogind

    Реализует серверные функции для команд rlogin (авторизация)

    routed

    Управляет сетевыми маршрутными таблицами

    rshd

    Реализует серверные функции для команд удаленного исполнения

    rwhod

    Реализует серверные функции для команд rwho и ruptime

    syslogd

    Читает и записывает в журнал сообщения

    talkd

    Реализует серверные функции для команд talk

    telnetd

    Реализует серверные функции для протокола TELNET

    tftpd

    Реализует серверные функции для протокола TFTP

    timed

    При загрузке системы устанавливает демон timeserver

    Конфигурация inetd определяется содержимым файла /etc/inetd.conf. Для ознакомления с содержимым файла достаточно с клавиатуры ввести команду:

    head -16 /etc/inetd.conf
    # @(#)inetd.conf 1.24 92/04/14 SMI
    # Configuration file for inetd(8). See inetd.conf(5).
    # To re-configure the running inetd process, edit this file, then
    # send the inetd process a SIGHUP.
    # Internet services syntax:
    # <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args>
    # Ftp and telnet are standard Internet services.

    #ftp

    stream

    tcp

    nowait

    root

    /usr/etc/in.ftpd

    in.ftpd

    #ftp

    stream

    tcp

    nowait

    root

    /usr/etc/wrapper.3.9.4/tcpd

    in.ftpd -dl

    ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd -lio

    Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере ftp). Далее следует поле типа соединителя (socket): stream (TCP поток байтов); dgram - передача данных в виде UDP-дейтограмм. Следующее поле характеризует протокол, используемый данным видом сервиса (TCP или UDP). За ним идет поле, которое описывает способ реализации процедуры (wait/nowait; для поточных серверов nowait). Следующее поле представляет собой идентификатор пользователя (UID), но обычно пользователем является системный администратор - root. Встречается два исключения. Процедура finger выполняется с UID=nobody или daemon, а uucp использует реальное имя пользователя. За полем uid следует поле сервера (в примере /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd). В это поле заносится полное описание пути к программе-серверу, запускаемой inetd. Завершающим полем является поле аргументы, куда записывается строка, передаваемая программе-серверу. Содержимое файла inetd.conf должно быть предметом особой заботы администратора, так как от содержимого этого файла зависит эффективная работа сети и ее безопасность.

    Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig). Рассмотрим пример использования процедуры nslookup (здесь выполнены запросы по серверам имен, по почтовым серверам и по параметрам зоны ответственности):

    Nslookup (запуск сервера)
    Default Server: ns.itep.ru
    Address: 193.124.224.35
    set type=NS (запрос данных о серверах имен)
    > > Server: ns.itep.ru
    Address: 193.124.224.35

    eunet.fi

    (определяем имя запрашиваемого узла)

    Non-authoritative answer:

    eunet.fi

    nameserver = ns1.EUNET.FI

    eunet.fi

    nameserver = ns2.EUNET.FI

    eunet.fi

    nameserver = ns3.eunet.fi

    eunet.fi

    nameserver = ns.eu.net

    eunet.fi

    nameserver = ns0.EUNET.FI

    Authoritative answers can be found from (официальные данные могут быть получены от):

    eunet.fi

    nameserver = ns1.EUNET.FI

    set type=ANY (запрос всей информации)
    ..........................................
    Non-authoritative answer:

    eunet.fi

    nameserver = ns1.EUNET.FI

    eunet.fi

    nameserver = ns2.EUNET.FI

    eunet.fi

    nameserver = ns3.eunet.fi

    eunet.fi

    nameserver = ns.eu.net

     

    origin = ns1.eunet.fi

     

    mail addr = hostmaster.eunet.fi

     

    serial = 199607235

     

    refresh = 28800 (8 hours)

     

    retry = 7200 (2 hours)

     

    expire = 604800 (7 days)

     

    minimum ttl = 86400 (1 day)

    eunet.fi

    preference = 10, mail exchanger = pim.eunet.fi (Основной почтовый сервер)

    eunet.fi

    preference = 50, mail exchanger = mail.eunet.fi

    eunet.fi

    nameserver = ns0.EUNET.FI

    Authoritative answers can be found from:

    eunet.fi

    nameserver = ns1.EUNET.FI

    eunet.fi

    nameserver = ns2.EUNET.FI

    eunet.fi

    nameserver = ns3.eunet.fi

    eunet.fi

    nameserver = ns.eu.net

    eunet.fi

    nameserver = ns0.EUNET.FI

    ns1.EUNET.FI

    internet address = 192.26.119.7

    ns2.EUNET.FI

    internet address = 192.26.119.4

    ns3.eunet.fi

    internet address = 192.26.119.4

    ns.eu.net

    internet address = 192.16.202.11

    pim.eunet.fi

    internet address = 193.66.4.30

    mail.eunet.fi

    internet address = 192.26.119.7

    ns0.EUNET.FI

    internet address = 192.26.119.1

    set type=MX

    (запрос информации о почтовых серверах)

    ...................................
    Non-authoritative answer:

    eunet.fi

    preference = 50, mail exchanger = mail.eunet.fi

    (имена почтовых серверов)

    eunet.fi

    preference = 10, mail exchanger = pim.eunet.fi

     

    (Параметр preference характеризует степень предпочтения почтового сервера, чем он ниже - тем выше предпочтение.)

    Authoritative answers can be found from:

    eunet.fi

    nameserver = ns1.EUNET.FI

    eunet.fi

    nameserver = ns2.EUNET.FI

    eunet.fi

    nameserver = ns3.eunet.fi

    eunet.fi

    nameserver = ns.eu.net

    eunet.fi

    nameserver = ns0.EUNET.FI

    mail.eunet.fi

    internet address = 192.26.119.7

    pim.eunet.fi

    internet address = 193.66.4.30

    ns1.EUNET.FI

    internet address = 192.26.119.7

    ns2.EUNET.FI

    internet address = 192.26.119.4

    ns3.eunet.fi

    internet address = 192.26.119.4

    ns.eu.net

    internet address = 192.16.202.11

    ns0.EUNET.FI

    internet address = 192.26.119.1

    set type=SOA (запрос параметров, зоны сервера имен, см. RFC-1034-35)
    .......................................
    Non-authoritative answer (см. документы RFC-1034-35):

     

    origin = ns1.eunet.fi

     

    mail addr = hostmaster.eunet.fi

     

    serial = 199607235

     

    refresh = 28800 (8 часов)

     

    retry = 7200 (2 часа)

     

    expire = 604800 (7 дней)

     

    minimum ttl = 86400 (1 день)

    Authoritative answers can be found from:

    eunet.fi

    nameserver = ns1.EUNET.FI

    eunet.fi

    nameserver = ns2.EUNET.FI

    eunet.fi

    nameserver = ns3.eunet.fi

    eunet.fi

    nameserver = ns.eu.net

    eunet.fi

    nameserver = ns0.EUNET.FI

    ns1.EUNET.FI

    internet address = 192.26.119.7

    ns2.EUNET.FI

    internet address = 192.26.119.4

    ns3.eunet.fi

    internet address = 192.26.119.4

    ns.eu.net

    internet address = 192.16.202.11

    ns0.EUNET.FI

    internet address = 192.26.119.1

    >exit

    (команда выхода из nslookup)

    Рассмотренный пример показывает, что DNS-сервер весьма важный объект узла, от него зависит скорость обслуживания запросов и надежность системы в целом. Именно по этой причине помимо основного любой узел имеет несколько вторичных DNS-серверов.

    Программа dig функционально является аналогом nslookup, но в прикладном плане имеет определенные отличия, она снабжена рядом полезных опций (таблица 5.3):

    Таблица 5.3 Опции программы dig

    Тип запроса

    Запись DNS-сервера

    a

    Адресная запись

    any

    Любой тип записи

    axfr

    Все записи, относящиеся к зоне

    hinfo

    Записи, характеризующие ЭВМ

    mx

    Записи, определяющие почтовый обмен

    ns

    Записи сервера имен

    soa

    Начало записей для зоны ответственности DNS-сервера

    txt

    Текстовые записи

    Ниже приведен пример использования команды dig для сервера имен узла DESY (Гамбург):

    dig @vxdesy.desy.de ns
    ; <<>> DiG 2.0 <<>> @vxdesy.desy.de ns
    ; (3 servers found)
    ;; res options: init recurs defnam dnsrch
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
    ;; flags: qr rd ra; Ques: 1, Ans: 9, Auth: 9, Addit: 9
    ;; QUESTIONS:
    ;;., type = NS, class = IN
    ;; ANSWERS:

    .

    185470

    NS

    A.ROOT-SERVERS.NET.

    .

    185470

    NS

    H.ROOT-SERVERS.NET.

    .

    185470

    NS

    B.ROOT-SERVERS.NET.

    .

    185470

    NS

    C.ROOT-SERVERS.NET.

    .

    185470

    NS

    D.ROOT-SERVERS.NET.

    .

    185470

    NS

    E.ROOT-SERVERS.NET.

    .

    185470

    NS

    I.ROOT-SERVERS.NET.

    .

    185470

    NS

    F.ROOT-SERVERS.NET.

    .

    185470

    NS

    G.ROOT-SERVERS.NET.

    ;; AUTHORITY RECORDS:

    .

    185470

    NS

    A.ROOT-SERVERS.NET.

    .

    185470

    NS

    H.ROOT-SERVERS.NET.

    .

    185470

    NS

    B.ROOT-SERVERS.NET.

    .

    185470

    NS

    C.ROOT-SERVERS.NET.

    .

    185470

    NS

    D.ROOT-SERVERS.NET.

    .

    185470

    NS

    E.ROOT-SERVERS.NET.

    .

    185470

    NS

    I.ROOT-SERVERS.NET.

    .

    185470

    NS

    F.ROOT-SERVERS.NET.

    .

    185470

    NS

    G.ROOT-SERVERS.NET.

    ;; ADDITIONAL RECORDS:

    A.ROOT-SERVERS.NET.

    531366

    A

    198.41.0.4

    H.ROOT-SERVERS.NET

    531366

    A

    128.63.2.53

    B.ROOT-SERVERS.NET.

    531366

    A

    128.9.0.107

    C.ROOT-SERVERS.NET.

    578733

    A

    192.33.4.12

    D.ROOT-SERVERS.NET.

    578733

    A

    128.8.10.90

    E.ROOT-SERVERS.NET.

    547664

    A

    192.203.230.10

    I.ROOT-SERVERS.NET.

    578733

    A

    192.36.148.17

    F.ROOT-SERVERS.NET.

    531366

    A

    192.5.5.241

    G.ROOT-SERVERS.NET.

    531366

    A

    192.112.36.4

    ;; FROM: ns.itep.ru to SERVER: vxdesy.desy.de 131.169.30.46
    ;; WHEN: Thu Jul 25 12:07:54 1996
    ;; MSG SIZE sent: 17 rcvd: 429

    Программа ifconfig служит для контроля состояния сетевых интерфейсов, их конфигурирования и проверки. С помощью этой команды интерфейсу присваивается IP-адрес, субсетевая маска и широковещательный адрес. Примером использования ifconfig для получения информации об интерфейсе может служить:

    ifconfig le0

    le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>
    inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32

    Флаг UP означает, что интерфейс готов к использованию, DOWN указывает на необходимость перевода интерфейса в состояние UP с помощью команды ifconfig le0 up. Если эта команда не проходит, следует проверить соединительный кабель или сам интерфейс. Флаг RUNNING говорит о том, что интерфейс работает. При отсутствии этого флага следует проверить правильность инсталляции. Флаг BROADCAST указывает на то, что интерфейс поддерживает широковещательный режим адресации (MULTICAST - допускает многоадресное обращение). Флаг NOTRAILERS - показывает, что интерфейс не поддерживает trailer-инкапсуляцию (Ethernet). Вторая строка отклика на команду начинается с ключевого слова inet (Интернет) и содержит IP-адрес, маску субсети и широковещательный адрес. На ошибку в задании маски субсети указывает факт доступности удаленных ЭВМ и машин локальной субсети при недоступности ЭВМ соседних субсетей. При неверном задании IP-адреса возможны самые разные ошибки. При неверной сетевой части адреса команда Ping будет вызывать ошибку типа "no answer". Ошибка же в части адреса, характеризующей ЭВМ, может быть не замечена в течение длительного времени, если носителем ошибочного адреса является персональная ЭВМ, обращений к которой извне не происходит. Определенное время можно использовать и чужой IP-адрес. Такого рода ошибки не могут быть выявлены с помощью ifconfig, здесь хорошую службу может оказать программа arp (см. описание протокола в RFC-826). Эта программа позволяет анализировать преобразование IP-адресов в физические (Ethernet). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):

    -a

    отображает содержимое всей ARP-таблицы

    -d <имя ЭВМ>

    удаляет запись из ARP-таблицы

    -s <имя ЭВМ> <Ethernet-адрес>

    добавляет новую запись в таблицу

    Ниже приведен пример исполнения команды arp, которая печатает имя объекта, его IP- и физический адреса (следует иметь в виду, что содержимое ARP-таблиц изменяется со временем, время хранения записи задается администратором сети):

    arp -a

    itepgw.itep.ru

    (193.124.224.33) at 0:0:c:2:3a:49

    ITEP-FDDI-BBone.ITEP.RU

    (193.124.224.50) at 0:0:c:2:fb:c5

    RosNET-Gw.ITEP.Ru

    (193.124.224.37) at 0:c0:14:10:1:cd

    nb.itep.ru

    (193.124.224.60) at 0:80:ad:2:24:b7

    Указанием на наличие ошибки в ARP-таблице может служить сообщение о недоступности или неизвестности ЭВМ при выполнении команд типа FTP или telnet. Такие сообщения возможны, например, при использовании одного и того же IP-адреса двумя ЭВМ. Все зависит от того, какая из машин успела "прописаться" в ARP-таблице раньше. Просматривая таблицу, администратор может заметить, что одному и тому же IP-адресу временами соответствуют разные физические адреса. Легальность адреса может быть проверена с помощью содержимого файла /etc/ethers. Первые три байта физического адреса характеризуют производителя интерфейса (см. Assigned Numbers, RFC-1700), что может помочь найти "IP-двойника". Если анализ ARP-таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet. Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина.

    Одной из наиболее информативных команд является netstat (за исчерпывающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение). Эта команда может вам дать информацию о состоянии интерфейсов на ЭВМ, где она исполнена:

    netstat -i

    Name

    Mtu

    Net/Dest

    Address

    Ipkts

    Ierrs

    Opkts

    Oerrs

    Collis

    Queue

    le0

    1500

    193.124.224.32

    ns

    966204

    0

    584033

    0

    846

    0

    lo0

    1536

    127.0.0.0

    127.0.0.1

    4191

    0

    4191

    0

    0

    0

    Name - имя интерфейса, если в этом поле стоит *, это означает, что интерфейс в состоянии down; Net/Dest - показывает IP-адрес сети или ЭВМ, куда интерфейс осуществляет доступ; Address - IP-адрес интерфейса; Ipkt - число принятых пакетов; Ierr - число ошибок при приеме пакетов; Opkts - число отправленных пакетов через данный интерфейс, Oerrs - число ошибок при отправке; Collis - число столкновений в сегменте Ethernet, зафиксированных интерфейсом; Queue - длина очереди пакетов, ждущих отправки. Программа nrtstat позволяет ознакомиться и с маршрутной таблицей:

    netstat -nr

    Маршрутная таблица

    Место назначения

    Маршрутизатор

    Флаги

    Refcnt

    Use

    Интерфейс

    192.148.166.185

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.161

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.97

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.177

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.129

    193.124.224.33

    UGHD

    1

    192

    le0

    192.148.166.145

    193.124.224.33

    UGHD

    0

    72

    le0

    192.148.166.170

    193.124.224.33

    UGHD

    0

    4

    le0

    192.148.166.26

    193.124.224.60

    UGHD

    0

    19

    le0

    192.148.166.131

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.140

    193.124.224.33

    UGHD

    0

    0

    le0

    192.148.166.173

    193.124.224.33

    UGHD

    0

    2

    le0

    192.148.166.182

    193.124.224.33

    UGHD

    0

    20

    le0

    192.148.166.142

    193.124.224.33

    UGHD

    0

    300

    le0

    Колонка место назначения указывает на конечную точку маршрута, колонка маршрутизатор - имя маршрутизатора, через который достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Флаг "M" указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг <null> говорит о том, что адресат достижим непосредственно.

    Возможности netstat не ограничиваются локальной сетью или автономной системой, с помощью ее можно получить некоторую информацию об удаленных ЭВМ или маршрутизаторах. Например:

    netstat -r 194.85.112.34

    input packets

    (le0) errs

    output packets

    errs

    colls

    input packets

    Total errs

    Output packets

    errs

    colls

    7636610

    0

    4578719

    0

    5918

    7674851

    0

    4616960

    0

    5918

    Это может быть полезно при экспресс диагностике внешних каналов связи, когда простого ping или traceroute оказалось недостаточно. Если возникло подозрение относительно маршрутизации пакетов, можно сначала проверить работает ли программа gated, для этого выдайте команду:

    ps 'cat /etc/gated.pid'

    после чего обратитесь к системному администратору :-).

    Если нужно получить информацию о смонтированных файловых системах, вы можете воспользоваться командой:

    showmount -e ns (ns - имя ЭВМ)
    export list for ns.itep.ru:
    /u1/SunITEP saturn.itep.ru,suncom.itep.ru

    Крайне полезна для контроля конфигурации системы команда host, она имеет много опций и с ее помощью можно узнать о доступных типах услуг, об именах и IP-адресах почтовых серверов и серверов имен, о кодах их предпочтения и т.д..

    host -a vitep5
    Trying domain "itep.ru"
    rcode = 3 (Non-existent domain), ancount=0
    Trying null domain
    rcode = 0 (Success), ancount=6

    vitep5.itep.ru

    86400

    IN

    WKS

    192.148.166.198 tcp ftp telnet

     

    vitep5.itep.ru

    86400

    IN

    HINFO

    VAX-8530

    VMS 5.3

    vitep5.itep.ru

    86400

    IN

    MX

    15

    mx.itep.ru

    vitep5.itep.ru

    86400

    IN

    MX

    200

    relay1.kiae.su

    vitep5.itep.ru

    86400

    IN

    MX

    210

    relay2.kiae.su

    vitep5.itep.ru

    86400

    IN

    A

    192.148.166.198

     

    Additional information:

    relay1.kiae.su

    18938 IN

    A

    193.125.152.6

    relay1.kiae.su

    18938 IN

    A

    193.125.152.1

    relay2.kiae.su

    18938 IN

    A

    193.125.152.1

    Во второй колонке данной выдачи указано время жизни пакетов (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса. В пятой колонке идут названия серверов, IP-адреса ЭВМ и коды предпочтения (15, 200 и 210). Более подробно о возможностях этой команды можно ознакомиться в [11].

    В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, использующие протокол SNMP, проверяют наличие посредством специального запроса доступность SNMP-демона, с помощью ICMP-протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public). Это может делаться автоматически или по запросу оператора. SNMP-протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. Для решения этой задачи можно использовать соответствующую программу, которая регулярно опрашивает MIB интересующих вас ЭВМ, а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов (mode=6). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте. Введя в программу определенные фильтры (отбор по IP-адресам отправителей, получателей, по широковещательным запросам или определенным протоколам) можно узнать много полезного о своей сети. К сожалению, этот метод пригоден только в отношении логического сегмента, к которому подключена ваша ЭВМ. Такие программы могут использоваться для контроля сетевых ресурсов, если ЭВМ размещена на соответствующем сегменте, что может оказаться актуально в связи с коммерциализацией сетевых услуг. По этой причине метод диагностики через SNMP-резидентов более универсален. Упомянутые в начале программы Tcpdump и Etherfind крайне полезны для отладки программ, работающих с сетевыми пакетами. Они позволяют отображать все входящие и посылаемые пакеты. Следует иметь в виду, что эти программы потенциально опасны с точки зрения несанкционированного доступа и, поэтому их применение часто возможно только для привилегированных пользователей. Работа интерфейса в режиме перехвата всех пакетов также представляет угрозу безопасности сети (возможность получения чужих паролей). С учетом этого обстоятельства должно приветствоваться использование программного обеспечения, где содержимое пакетов терминального обмена подвергается шифрованию-дешифрованию.

    Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами (ftp.sgi.com, каталог sgi/src/ttcp или vgr.brl.mil ftp/pub/ttcp.c).

    Перечисленные режимы работают в рамках протокола TCP, для исследования процессов, требующих UDP, следует использовать опцию -u. Существует множество других опций, обеспечивающих реализацию самых разнообразных режимов работы (см. [10] и справочные руководства на вашей ЭВМ).

    Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу TCP/IP протоколов для SunOS 4.1.3.

    IPFORWARDING - значение этой константы инициализирует системную переменную ip_forwarding. Если она равна -1, IP-дейтограммы никогда не переадресуются, а переменная уже никогда не меняется. Если же она равна 0 (значение по умолчанию), IP-дейтограммы не переадресуются. Переменная принимает значение 1, когда доступны несколько интерфейсов. При значении константы, равном 1, переадресация всегда разрешена.

    SUBNETSARELOCAL - константа, определяющая начальное значение переменной ip_subnetsarelocal. Если она равна 1 (по умолчанию), то IP-адрес места назначения с идентификатором сети, идентичным с тем, что имеет ЭВМ- отправитель, считается локальным вне зависимости от идентификатора субсети. Если константа равна нулю, то локальным будет считаться только адрес, принадлежащий данной субсети (при совпадении идентификаторов сети и субсети).

    IPSENDREDIRECTS - константа, используемая для определения стартового значения переменной ip_sendredirects. Если константа равна 1, (по умолчанию) ЭВМ при выполнении процедуры forward посылает ICMP-сообщения о переадресации. При равенстве нулю ICMP-сообщения не посылаются.

    DIRECTED_BROADCAST - константа, определяющая начальное значение переменной ip_dirbroadcast. Если константа равна 1 (по умолчанию), получаемые дейтограммы, адрес места назначения которых является широковещательным адресом интерфейса, переадресуются на канальный широковещательный уровень. При равенстве нулю такие дейтограммы ничтожаются.

    Ряд системных переменных содержится в файле in_proto каталога /usr/kvm/sys/netinet. При изменении этих переменных система должна быть перезагружена.

    tcp_default_mss значение MSS протокола TCP для нелокальных адресатов, по умолчанию равна 512.

    tcp_keepidle определяет число 500 мс тактов между посылками запросов о работоспособности. По умолчанию равна 14400 (2 час.).

    tcp_keepintvl определяет число 500 мс тактов между посылками запросов о работоспособности, когда не получено никакого отклика. По умолчанию эта переменная равна 150 (75сек).

    tcp_keeplen используется для обеспечения совместимости с ранними версиями (4.2BSD), должна равняться 1.

    tcp_nodelack при неравенстве нулю требует отправки немедленного отклика (ACK), по умолчанию равна нулю.

    tcp_recvspace определяет размер входного TCP-буфера и влияет на величину окна. По умолчанию эта переменная равна 4096.

    tcp_sendspace определяет размер выходного TCP-буфера, по умолчанию равна 4096.

    tcp_ttl задает значение поля TTL в TCP-сегменте, по умолчанию имеет значение 60.

    udp_cksum при неравенстве нулю требует вычисления контрольной суммы для отправляемых UDP-дейтограмм и проверки контрольных сумм для получаемых UDP-дейтограмм, если поле контрольной суммы не равно нулю. По умолчанию переменная равна нулю.

    udp_recvspace определяет размер входного UDP-буфера, по умолчанию равна 18000, что соответствует двум 9000-байтным дейтограммам.

    udp_sendspace задает объем выходного UDP-буфера, ограничивая предельную длину посылаемой дейтограммы. По умолчанию переменная равна 9000.

    udp_ttl определяет значение поля TTL для UDP-дейтограмм, значение по умолчанию - 60.

    Для изменения значений этих переменных необходимо иметь системные привилегии.

    Previous: 4.6.4 Смарт-карты EMV    UP: 4.5.8 Поиск узлов и людей
    Down: 6 Сетевая безопасность    Next: 5.1 Сетевая диагностика с применением протокола SNMP


    previous up down next index index
    Previous: 5 Диагностика локальных сетей и Интернет    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность
        Next: 5.2 Диагностика на базе ICMP

    5.1 Сетевая диагностика с применением протокола SNMP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Обслуживание и диагностирование больших многосегментных, многопротокольных сетей, размещенных на большой территории, а в некоторых случаях и в нескольких городах (например, корпоративные сети типа Интранет), представляет собой тяжелую проблему.

    Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901, 1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042; std16, std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на рис. 4.1.1.

    Рис. 4.1.1. Пример диагностируемой сети

    Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ. Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены.

    Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны.

    Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками. В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig (venera.isi.edu/pub), hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch (windom.ucar.edu), snmpman (http:// www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp,eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.

    Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community; формат пакетов описан, например, в книге Семенова Ю.А. "Протоколы и ресурсы Интернет", Москва, "Радио и связь", 1996). Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.

    При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):

    interface.iftable.ifentry.ifinucastpkts

    Число полученных обычных пакетов;

    interface.iftable.ifentry.ifinnucastpkts

    Число полученных широковещательных и мультикаст-пакетов;

    interface.iftable.ifentry.ifinerrors

    Число ошибок при приеме пакетов;

    interface.iftable.ifentry.ifoutucastpkts

    Число посланных обычных пакетов;

    interface.iftable.ifentry.ifinnucastpkts

    Число посланных широковещательных и мультикаст-пакетов;

    interface.iftable.ifentry.ifinunknownprotos

    Число полученных пакетов с неизвестным кодом протокола;

    ip.ipinreceives

    Полное число ip-дейтограмм, включая полученные с ошибкой;

    ip.ipinhdrerrors

    Число входных ip-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, ttl и т.д.

    ip.ipinaddrerrors

    Число полученных пакетов с ошибкой в адресе;

    ip.ipinunknownprotos

    Число входных ip-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой;

    ip.ipreasmreqds

    Число полученных фрагментов, которые требуют сборки;

    ip.ipindelivers

    Число ip-дейтограмм, принятых без ошибок (включая icmp);

    icmp.icmpinmsgs

    Число полученных icmp-пакетов;(другие 10 контролируемых переменных icmp-группы из соображений экономии места из списка исключены);

    udp.udpindatagrams

    Число принятых udp-дейтограмм;

    udp.udpoutdatagrams

    Число отправленных udp-дейтограмм;

    udp.udpnoports

    Полное число udp-дейтограмм, для которых не существует приложения для указанного номера порта;

    udp.udpinerrors

    Число udp-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту;

    tcp.tcpinsegs

    Число принятых tcp-сегментов;

    tcp.tcpoutsegs

    Число отправленных TCP-сегментов;

    tcp.tcpretranssegs

    Число tcp-сегментов с повторной пересылкой;

    tcp.tcpoutrsts

    Число сегментов с флагом rst=1;

    tcp.tcpinerror

    Число tcp-сегментов, полученных с ошибкой.

    Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели.

    Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так переменная snmpinbadcommunityuses {snmp 5} может сообщить о попытках несанкционированного доступа к базе mib. Переменные snmpintoobigs {snmp 8}, snmpingenerrs {snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д. полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, если ipfragfails велико, о неверном выборе MTU.

    Рассмотрим средние значения некоторых переменных за сутки. Так переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормально. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети, если соотнести эти цифры с входным и выходным потоками пакетов можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результат работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки случилось мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках tcp-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети, чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.

    Рис. 4.1.2. Вариации tcpinsegs и udpindatagrams в течение недели

    Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели. На рис. 4.1.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На рис. 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программой last на ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.

    ms977

    pts/0

    vitep5.itep.ru

    tue sep 10 23:49 - 00:16 (00:27)

    ms977

    pts/2

    vitep5.itep.ru

    tue sep 10 22:20 - 23:46 (01:26)

    ostrouh

    pts/0

    athene.itep.ru

    tue sep 10 18:30 - 18:43 (00:13)

    titovich

    pts/0

    athene.itep.ru

    tue sep 10 18:30 - 18:30 (00:00)

    vita

    pts/3

    athene.itep.ru

    tue sep 10 14:55 - 15:56 (01:00)

    checho

    pts/12

    itep05.itep.ru

    tue sep 10 13:35 - 13:37 (00:01)

    fomin

    pts/10

    hydra.ifh.de

    tue sep 10 13:16 - 13:22 (00:06)

    checho

    pts/7

    itep05.itep.ru

    tue sep 10 13:09 13:16 (00:07)

    illarion

    pts/7

    xt07.itep.ru

    tue sep 10 12:45 12:45 (00:00)

    vita

    pts/9

    athene.itep.ru

    tue sep 10 11:55 13:03 (01:07)

    bely

    pts/12

    pcx01.itep.ru

    tue sep 10 11:49 12:02 (00:13)

    vita

    pts/13

    athene.itep.ru

    tue sep 10 11:49 11:52 (00:03)

    efre

    pts/4

    pcx10.itep.ru

    tue sep 10 10:05 10:24 (00:18)

    checho

    pts/0

    169-151-147.ipt.

    tue sep 10 05:07 05:09 (00:01)

    ssemen

    ftp

    clotho.itep.ru

    mon sep 09 20:14 20:15 (00:01)

    ssemen

    ftp

    clotho.itep.ru

    mon sep 09 19:34 19:35 (00:00)

    ostrouh

    pts/3

    athene.itep.ru

    mon sep 09 19:20 19:40 (00:20)

    ozero

    pts/0

    athene.itep.ru

    mon sep 09 19:13 22:44 (03:30)

    ozero

    pts/5

    itep05.itep.ru

    mon sep 09 18:05 18:32 (00:27)

    olyalin

    pts/6

    itep05.itep.ru

    mon sep 09 16:19 16:27 (00:08)

    efre

    ftp

    pcx10.itep.ru

    mon sep 09 16:14 16:15 (00:00)

    mara

    pts/1

    hpl3pur2.cern.ch

    mon sep 09 16:02 16:27 (00:24)

    mara

    pts/1

    hpl3pur2.cern.ch

    mon sep 09 15:50 15:54 (00:04)

    itep977

    pts/2

    1mars.itep.ru

    mon sep 09 15:22 15:23 (00:00)

    ozero

    pts/20

    aix0.itep.ru

    mon sep 09 15:06 15:36 (00:29)

    ozero

    pts/12

    itep05.itep.ru

    mon sep 09 14:56 14:56 (00:00)

    galy

    pts/16

    athene.itep.ru

    mon sep 09 14:27 14:31 (00:03)

    bely

    pts/15

    vitep5.itep.ru

    mon sep 09 14:09 10:36 (20:27)

    sed

    pts/5

    pcx11.itep.ru

    mon sep 09 14:01 14:01 (00:00)

    kisel

    pts/1

    vxitep.itep.ru

    mon sep 09 13:59 15:22 (01:22)

    ozero

    pts/12

    itep05.itep.ru

    mon sep 09 13:53 14:55 (01:02)

    ozero

    pts/2

    193.148.166.214

    mon sep 09 13:40 13:41 (00:00)

    ozero

    pts/8

    193.148.166.214

    mon sep 09 13:32 13:37 (00:04)

    vita

    pts/9

    aix0.itep.ru

    mon sep 09 13:32 13:32 (00:00)

    vita

    pts/2

    vitep5.itep.ru

    mon sep 09 13:32 13:32 (00:00)

    checho

    pts/3

    itep05.itep.ru

    mon sep 09 13:11 13:12 (00:00)

    efre

    pts/3

    pcx10.itep.ru

    mon sep 09 12:12 12:23 (00:10)

    kisel

    pts/2

    vxitep.itep.ru

    mon sep 09 12:11 12:43 (00:32)

    checho

    pts/6

    itep05.itep.ru

    mon sep 09 12:02 12:03 (00:00)

    kisel

    ftp

    pcx11.itep.ru

    mon sep 09 11:42 11:43 (00:00)

    kisel

    ftp

    ion04.cern.ch

    mon sep 09 10:59 11:06 (00:06)

    galy

    pts/1

    athene.itep.ru

    mon sep 09 10:57 10:58 (00:00)

    titovich

    pts/4

    athene.itep.ru

    mon sep 09 10:20 10:21 (00:01)

    korol

    pts/0

    193.124.225.174

    mon sep 09 05:20 05:57 (00:37)

    Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и рис. 5.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.

    Рис. 5.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts

    По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На рис. 5.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 5.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos.

    На рис. 5.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на рис. 5.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).

    Рис. 5.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)

    Рис. 5.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.

    Рис. 5.1.6(а, б). Суточные вариации потоков TCP-сегментов

    Previous: 5 Диагностика локальных сетей и Интернет    UP: 5 Диагностика локальных сетей и Интернет
    Down: 6 Сетевая безопасность    Next: 5.2 Диагностика на базе ICMP


    previous up down next index index
    Previous: 6.1 Технические средства сетевой безопасности    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.3 Система Firewall

    6.2 Виртуальные локальные сети VLAN, Интранет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Широкое внедрение ИНТРАНЕТ, где группы разбросанных по сети пользователей локальных сетей объединяются друг с другом с помощью виртуальных каналов VLAN (Virtual Local Area Network; http://www.3com.com/nsc/200374.html), потребовало разработки новых протоколов. Архитектура VLAN позволяет эффективно разделять трафик, лучше использовать полосу канала, гарантировать успешную совместную работу сетевого оборудования различных производителей и обеспечить высокую степень безопасности. При этом пакеты следуют между портами в пределах локальной сети. В последнее время для задач построения VLAN разработан стандартный протокол IEEE 802.10 (3-ий сетевой уровень). Этот протокол предполагает, что пакеты VLAN имеют свои идентификаторы, которые и используются для их переключения. Протокол может поддерживать работу 500 пользователей и более. Полное название стандарта - IEEE 802.10 Interoperable LAN/MAN Security (MAN - Metropolitan Area Network - региональная или муниципальная сеть). Стандарт принят в конце 1992 года. Количество VLAN в пределах одной сети практически не ограничено. Протокол позволяет шифровать часть заголовка и информационное поле пакетов.

    Стандарт ieee 802.10 определяет один протокольный блок данных (PDU), который носит название SDE (Secure Data Exchange) PDU. Заголовок пакета ieee 802.10 имеет внутреннюю и внешнюю секции и показан на рис. 6.2.1.

    Рис. 6.2.1 Формат пакета IEEE 802.10

    Поле чистый заголовок включает в себя три субполя. MDF (Management Defined Field) является опционным и содержит информацию о способе обработки PDU. Четырехбайтовое субполе said (Security Association Identifier) - идентификатор сетевого объекта (VLAN ID). Субполе 802.10 LSAP (Link Service Access Point) представляет собой код, указывающий принадлежность пакета к протоколу vlan. Предусматривается режим, когда используется только этот заголовок.

    Защищенный заголовок копирует себе адрес отправителя из mac-заголовка (MAC - Media Access Control), что повышает надежность.

    Поле ICV (Integrity Check Value) - служит для защиты пакета от несанкционированной модификации. Для управления VLAN используется защищенная управляющая база данных SMIB(security management information base).

    Наличие VLAN ID (said) в пакете выделяет его из общего потока и переправляет на опорную магистраль, через которую и осуществляется доставка конечному адресату. Размер поля data определяется физической сетевой средой. Благодаря наличию mac-заголовка VLAN-пакеты обрабатываются как обычные сетевые кадры. По этой причине VLAN может работать в сетях TCP/IP (Appletalk или Decnet менее удобны). В среде типа Netbios работа практически невозможна. Сети ATM прозрачны для VLAN. Протокол VLAN поддерживается корпорацией cisco, 3com и др.. Хотя VLAN ориентирован на локальные сети, он может работать и в WAN, но заметно менее эффективно. В последнее время разработано большое число специальных программных средств сетевой безопасности. Среди них Firewall занимает лидирующее положение.

    В разделе "Повторители, мосты (бриджи), мультиплексоры, переключатели и маршрутизаторы" упоминалась технология виртуальных сетей (vlan). Созданная для целей безопасности эта техника оказалась полезной для структуризации локальных сетей, приводящей к улучшению их рабочих характеристик. В настоящее время доступны переключатели, маршрутизаторы и даже концентраторы, поддерживающие виртуальные сети.

    Виртуальные сети просто необходимы, когда локальная сеть в пределах одного здания совместно используется несколькими фирмами, а несанкционированный доступ к информации желательно ограничить. Принцип построения виртуальной сети показан на рис. 6.2.2.

    Рис. 6.2.2. Схема переключателя (или концентратора) с поддержкой VLAN.

    Для формирования VLAN необходимо устройство, где возможно осуществлять управление тем, какие порты могут соединяться. Например, пусть запрограммирована возможность пересылки пакетов между портами 1, 3 и 6, 2 и 5, а также между портами 4, 7 и 8. Тогда пакет из порта 1 никогда не попадет в порт 2, а из порта 8 в порт 6 и т.д. Таким образом, переключатель как бы разделяется на три независимых переключателя, принадлежащих различным виртуальным сетям. Управление матрицей переключения возможно через подключаемый из вне терминал или удаленным образом с использованием протокола SNMP. Если система переключателей, концентраторов (и возможно маршрутизаторов) запрограммирована корректно, возникнет три независимые виртуальные сети.

    Данная технология может быть реализована не только в рамках локальной сети. Возможно выделение виртуальной сети в масштабах Интернет. В сущности, идея создания корпоративных сетей в Интернет (ИНТРАНЕТ) является обобщением идей виртуальных сетей на региональные сети.

    Такая корпоративная сеть должна иметь один шлюз для входа в Интернет. Такой шлюз может выполнять функции Firewall, решая проблемы безопасности корпоративной сети.

    Previous: 6.1 Технические средства сетевой безопасности    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.3 Система Firewall


    previous up down next index index
    Previous: 6.2 Виртуальные локальные сети VLAN, Интранет    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.3.1 Список видов атак, зарегистрированных Network ICE

    6.3 Система Firewall
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Учитывая важность проблемы защиты, разработана специальная система firewall ("огненная стена"). Система firewall заменяет маршрутизатор или внешний порт сети (gateway). Защищенная часть сети размещается за ним. Пакеты, адресованные Firewall, обрабатываются локально, а не просто переадресуются. Пакеты же, которые адресованы объектам, расположенным за Firewall, не доставляются. По этой причине хакер вынужден иметь дело с системой защиты ЭВМ Firewall. Схема взаимодействия Firewall с локальной сетью и внешним Интернет показана на рис. 6.3.1.

    Рис. 6.3.1. Схема Firewall

    Такая схема проще и надежнее, так как следует заботиться о защите одной машины, а не многих. Экран, маршрутизатор и ЭВМ управления экраном объединены небольшой, незащищенной локальной сетью. Основные операции по защите осуществляются здесь на IP-уровне. Эту схему можно реализовать и на одной ЭВМ, снабженной двумя интерфейсами. При этом через один интерфейс осуществляется связь с Интернет, а через второй - с защищенной сетью. Такая ЭВМ совмещает функции маршрутизатора-шлюза, экрана и управления экраном. Возможна реализация Firewall, показанная на рис 6.3.2. Здесь функция экрана выполняется маршрутизатором.

    Рис. 6.3.2. Схема Firewall, где функцию экрана выполняет маршрутизатор

    В этой схеме доступ из Интернет возможен только к прокси-серверу, ЭВМ из защищенной сети могут получить доступ к Интернет тоже только через прокси-сервер. Ни один пакет посланный из защищенной ЭВМ не может попасть в Интернет и, аналогично, ни один пакет из Интернет не может попасть непосредственно защищенной ЭВМ. Возможны и другие более изощренные схемы, например со вторым "внутренним" Firewall для защиты от внутренних угроз.

    Недостатки FireWall происходят от ее преимуществ, осложняя доступ извне, система делает трудным и доступ наружу. По этой причине система FireWall должна выполнять функции DNS (сервера имен) для внешнего мира, не выдавая никакой информации об именах или адресах внутренних объектов, функции почтового сервера, поддерживая систему псевдонимов для своих клиентов. Псевдонимы не раскрываются при посылке почтовых сообщений во внешний мир. Служба FTP в системе может и отсутствовать, но если она есть, доступ возможен только в сервер FireWall и из него. Внутренние ЭВМ не могут установить прямую FTP-связь ни с какой ЭВМ из внешнего мира. Процедуры telnet и rlogin возможны только путем входа в сервер FireWall. Услуги типа NFS, rsh, rcp, finger и т.д. не допускаются. Ни одна из ЭВМ в защищенной сети не может быть обнаружена с помощью PING (ICMP) извне. И даже внутри сети будут возможны только определенные виды трафика между строго определенными машинами. Понятно, что в целях безопасности защищенная сеть не может иметь выходов во внешний мир помимо системы экран, в том числе и через модемы. Экран конфигурируется так, чтобы маршрут по умолчанию указывал на защищенную сеть. Экран не принимает и не обрабатывает пакеты внутренних протоколов маршрутизации (например, RIP). ЭВМ из защищенной сети может адресоваться к экрану, но при попытке направить пакет с адресом из внешней сети будет выдан сигнал ошибки, так как маршрут по умолчанию указывает назад в защищенную сеть. Для пользователей защищенной сети создаются специальные входы для FTP (см. библиографию раздела 6 "Сетевая безопасность в Интернет"), telnet и других услуг. При этом не вводится каких-либо ограничений по транспортировке файлов в защищенную сеть и блокируется передача любых файлов из этой сети, даже в случае, когда инициатором FTP-сессии является клиент защищенной сети. Единственные протоколы, которым всегда позволен доступ к ЭВМ Firewall являются SMTP (электронная почта) и NNTP (служба новостей). Внешние клиенты Интернет не могут получить доступа ни к одной из защищенных ЭВМ ни через один из протоколов. Если нужно обеспечить доступ внешним пользователям к каким-то данным или услугам, для этого можно использовать сервер, подключенный к незащищенной части сети (или воспользоваться услугами ЭВМ управления экраном, что нежелательно, так как снижает безопасность). ЭВМ управления экраном может быть сконфигурирована так, чтобы не воспринимать внешние (приходящие не из защищенной сети) запросы типа FTP, telnet и пр., это дополнительно повысит безопасность. Стандартная система защиты здесь часто дополняется программой wrapper (см. раздел 6 "Сетевая безопасность в Интернет"). Немалую пользу может оказать и хорошая система регистрации всех сетевых запросов. Системы FireWall часто используются и в корпоративных сетях, где отдельные части сети удалены друг от друга. В этом случае в качестве дополнительной меры безопасности применяется шифрование пакетов. Система FireWall требует специального программного обеспечения. Следует иметь в виду, что сложная и дорогостоящая система FireWall не защитит от "внутренних" злоумышленников. Нужно тщательно продумать систему защиты модемных каналов (сама система FireWall на них не распространяется, так как это не внешняя часть сети, а просто удаленный терминал).

    Если требуется дополнительная степень защиты, при авторизации пользователей в защищенной части сети могут использоваться аппаратные средства идентификации, а также шифрование имен и паролей.

    При выборе той или иной системы Firewall следует учитывать ряд обстоятельств.

    1. Операционная система. Существуют версии Firewall, работающие с UNIX и Windows NT. Некоторые производители модифицируют ОС с целью усиления безопасности. Выбирать следует ту ОС, которую вы знаете лучше.
    2. Рабочие протоколы. Все Firewall могут работать с FTP (порт 21), e-mail (порт 25), HTTP (порт 80), NNTP (порт 119), Telnet (порт 23), Gopher (порт 70), SSL (порт 443) и некоторыми другими известными протоколами. Как правило, они не поддерживают SNMP.
    3. Типы фильтров. Сетевые фильтры, работающие на прикладном уровне прокси-сервера, предоставляют администратору сети возможность контролировать информационные потоки, проходящие через Firewall, но они обладают не слишком высоким быстродействием. Аппаратные решения могут пропускать большие потоки, но они менее гибки. Существует также "схемный" уровень прокси, который рассматривает сетевые пакеты, как черные ящики и определяет, пропускать их или нет. Отбор при этом осуществляется по адресам отправителя, получателя, номерам портов, типам интерфейсов и некоторым полям заголовка пакета.
    4. Система регистрации операций. Практически все системы Firewall имеют встроенную систему регистрации всех операций. Но здесь бывает важно также наличие средств для обработки файлов с такого рода записями.
    5. Администрирование. Некоторые системы Firewall снабжены графическими интерфейсами пользователя. Другие используют текстовые конфигурационные файлы. Большинство из них допускают удаленное управление.
    6. Простота. Хорошая система Firewall должна быть простой. Прокси-сервер (экран) должен иметь понятную структуру и удобную систему проверки. Желательно иметь тексты программ этой части, так как это прибавит ей доверия.
    7. Туннелирование. Некоторые системы Firewall позволяют организовывать туннели через Интернет для связи с удаленными филиалами фирмы или организации (системы Интранет). Естественно, что информация по этим туннелям передается в зашифрованном виде.

    Информацию по системам Firewall можно найти по следующим адресам.

    URL

    Содержание

    http://search.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

    Автоматическая конфигурация прокси для Netscape и Microsoft броузеров

    http://www.software.digital.com

    Alta Vista Firewall

    http://www.cyberguardcorp.com/

    CyberGuard Firewall

    http://www.raptor.com/

    Eagle Firewall

    http://www.checkpoint.com/

    Firewall-1

    http://www.tis.com/

    Gauntlet Firewall

    http://www.on.com/

    ON Guard Firewall

    http://www.sctc.com

    BorderWare Firewall

    ftp://ftp.nec.com/pub/socks/

    SOCKS прокси

    ftp://ftp.tis.com/pub/firewalls/toolkit

    Средства для работы с Firewall

    majordomo@greatcircle.com

    Подписной лист по проблематике Firewall. Для подписки в тело сообщения следует поместить subscribe firewall. Там же имеется архив: http://www.greatcircle.com/firewalls

    Previous: 6.2 Виртуальные локальные сети VLAN, Интранет    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.3.1 Список видов атак, зарегистрированных Network ICE


    previous up down next index index
    Previous: 6.3 Система Firewall    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4 Системы шифрования

    6.3.1 Список видов атак, зарегистрированных Network ICE
    Семенов Ю.А. (ГНЦ ИТЭФ)

    (смотри http://advice.networkice.com/advice/Intrusions/)

    Число официально зарегистрированных в мире сетевых инцидентов различного рода возрастает экспоненциально, о чем можно судить по рис. 1. (см. http://www.cert.org/stats/). Этот рост совпадает с ростом числа узлов в интернет, так что процент хулиганов и шизефреников величина похоже инвариантная. Атаки можно разделить на несколько классов:

    • Базирующиеся на дефектах протоколов, например, TCP.
    • Использующие дефекты операционной системы
    • Пытающиеся найти и воспользоваться дефектами программ-приложений, включая, например, CGI
    • Эксплуатирующие человеческие слабости (любопытство, алчность и пр., например, троянские кони)

    Список номеров портов для известных троянских коней можно найти в http://www.simovits.com/nyheter9902.html

    К первому типу относятся и атаки типа SMURF, ICMP flood и TCP SYN flood. ICMP flood не использует эффектов усиления на локальных широковещательных адресах, а работает c адресами типа 255.255.255.255. Здесь следует заметить, что для аналогичных целей хакеры могут использовать и протоколы TCP или UDP.

    Рис. 1. Распределение числа официально зарегистрированных сетевых инцидентов по годам.

    Ниже на рис. 2 показано распределение атак сети ИТЭФ по их разновидностям (Это и последующие два распределения построены студентом МФТИ А.Тарховым).


    Рис. 2.

    На рис.3 показана зависимость числа атак от времени суток, полученная за 19 дней.


    Рис. 3.

    На рис.4 показано распределение атак по доменным зонам. Из распределения видно, что этому занятию предаются чаще всего "жители" больших и комерческих сетей. Хотя нельзя исключить, что именно они являются чаще жертвами хакеров.


    Рис. 4.
    Код атаки Описание атаки
    2000001 Land attack. Атакер пытается замедлить работу вашей машины, послав пакет с идентичными адресами получателя и отправителя. Для стека протоколов Интернет такая ситуация не нормальна. ЭВМ пытается выйти из бесконечной петли обращений к самой себе. Имеются пэтчи для большинства операционных систем.
    2000002 Unknown IP protocol. Традиционными транспортными протоколами являются UDP, TCP и ICMP, которые работают поверх протокола IP. Код протокола определяется полем тип протокола заголовка IP-дейтограммы. Существует большое число протоколов, которые идентифицируются с помощью номеров портов, например, HTTP, использующий в качестве транспорта TCP. Появление незнакомого протокола должно всегда настораживать, так как может нарушить нормальную работу программ.
    2000003 Teardrop attack. Опасное перекрытие IP-фрагментов, сформированное программой teardrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя.
    2000004 NewTear attack. Опасное перекрытие IP-фрагментов, сформированное программой newtear . Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным.
    2000005 SynDrop attack. Опасное перекрытие IP-фрагментов, сформированное программой syndrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем.
    2000006 TearDrop2 attack. Тоже что и, например, SynDrop, но для программы teardrop2
    2000007 Bonk DoS..
    2000008 Boink DoS. Тоже что и, например, SynDrop, но для программы boink
    2000009 IP Fragment overlap. Смотри, например 2000005
    2000010 IP last fragment length changed..
    2000011 Too much IP fragmentation..
    2000012 Ping of death. Предпринимается попытка послать пакет, длина которого больше теоретического предела 65536 байтов. Системы до 1997 года были уязвимы для такой атаки. Это делалось, например с помощью ping -l 65550.
    2000013 IP source route. Попытка вторжения с использованием IP-опции "маршрут отправителя". В настоящее время эта опция заблокирована большинством маршрутизаторов.
    2000014 Zero length IP option. Некоторые системы при этом повисают
    2000015 Nestea attack. Опасное перекрытие IP-фрагментов, сформированное программой nestea. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя.
    2000016 Empty fragment. Когда пакеты слишком длины, они могут быть фрагментированы. Система контроля фиксирует фрагмент с нулевой длиной. Например, IP-заголовок имеет 20-байт, а данных вообще нет. Это может указывать, что:
    • Атакер пытается обойти систему контроля вторжения.
    • Некоторое сетевое оборудование (маршрутизаторы/переключатели) работают некорректно, генерируя такие фрагменты.
    • Имеется ошибка в стеке TCP/IP машины, посылающей пакет.
    • Атакер пытается предпринять DoS-атаку против вашей системы.
    Ядра Linux для версий между 2.1.89 и 2.2.3 были уязвимы для атак DoS с привлечением этой методики. Каждый такой фрагмент вызывает некоторую потерю памяти. Повторно посылая такие фрагменты, можно вызвать кризис из-за отсутствия свободной памяти. Ceotcndetn cкрипт с именем sesquipedalian, который был написан для использования этой ошибки.
    2000017 IP unaligned timestamp.
    2000018 Jolt2.
    2000019 Jolt.
    2000020 IP microfragment. Некоторые программы рушатся при получении временной метки, не выровненной по границе, кратной 32 бит.
    2000021 SSping attack. Попытка атаки с помощью некорректного формата фрагментов.
    2000022 Flushot attack.
    2000023 IP source route end.
    2000024 Oshare attack.
    2000025 IP fragment data changed.
    2000101 Traceroute. Кто-то пытается отследить путь от своей машины к вашей. Утилита traceroute широко используется в Интернет для поиска пути между машинами. Программа traceroute выполняет эту работу и определяет виртуальный путь через Internet. Программа traceroute не является опасной. Не существует способа проникнуть в вашу ЭВМ, используя ее. Однако она помогает хакеру отследить ваши соединения через Интернет. Эта информация может использоваться для компрометации некоторых других участников ваших связей. Например, в прошлом этот вид информации использовался хакерами для того, чтобы отключить свою жертву от Интернет, заставив ближайший маршрутизатор повесить телефонную линию.
    2000102 Echo storm. Необычно большое число ping пакетов пришло за ограниченный период времени. Pings Довольно частой атакой домашних пользователей, играющих в сетевые игры или общающихся через сеть, является блокировка их канала с помощью большого числа пакетов Ping. Сейчас ведутся работы, для того чтобы позволить пользователю конфигурировать configuration file, чтобы было можно игнорировать такое вторжение. Смотри статью q000050.
    2000103 Possible Smurf attack initiated..
    2000104 ICMP unreachable storm..
    2000105 ICMP subnet mask request. Поступил извне ICMP-запрос маски. В норме этого не должно быть. Атакер исследует структуру сети.
    2000106 Ping sweep.
    2000107 Suspicious Router advertisement. Подозрительное анонсирование новых маршрутов. Атакер возможно пытается перенаправить трафик на себя. Для этого может использоваться, в том числе, и ICMP-протокол. Соответствующие опции должны всегда вызывать подозрение.
    2000108 Corrupt IP options. Опции IP на практике почти не используются. По этой причине в их обработке имеется достаточно много ошибок. Ими часто пытаются воспользоваться хакеры. Появление в пакете IP-опций должно вызывать подозрения.
    2000109 Echo reply without request. Это может быть результатом взаимодействия хакера с засланным троянским конем. Может быть это и результатом дублирования вашего IP-адреса. В любом случае такие пакеты достойны внимания.
    2000110 ICMP flood..
    2000111 Twinge attack. То же, что и ICMP-flood
    2000112 Loki. Атака, использующая "заднюю дверь" приложения или ОС. Это может быть сделано для сокрытия трафика, например под видом ICMP-эхо или UDP-запросов к DNS и т.д. Воспользуйтесь командой netstat , чтобы выяснить, какие raw SOCKET открыты.
    2000201 UDP port scan..
    2000202 UDP port loopback. Пакет UDP путешествует между двумя эхо-портами. Такие пакеты могут делать это бесконечное число раз, используя всю имеющуюся полосу сети и производительность ЦПУ. Имеется несколько стандартных услуг такого рода, которые могут работать в системе. Среди них:
    echo (порт 7)
    дневная квота (порт 17)
    chargen (порт 19)

    Атакер может создать проблемы, фальсифицируя адрес отправителя и вынуждая две машины бесконечно обмениваться откликами друг с другом. Таким образом, может быть парализована вся сеть (ведь хакер может послать много таких пакетов). Например, хакер может имитировать посылку пакета от ЭВМ-A (порт chargen) к ЭВМ-B (порт echo). Эхо-служба ЭВМ-B пошлет отклик ЭВМ-A и т.д.
    2000203 Snork attack. Регистрируются UDP-дейтограммы с портом назначения 135 (Microsoft Location Service), и отправитель с портом 7 (Echo), 19 (Chargen) или 135. Это попытка замкнуть две службы (если они разрешены/активированы) и заставить их бесконечно обмениваться пакетами друг с другом. Существует пэтч для блокировки таких атак (смотри сайт Microsoft).
    2000204 Ascend Attack. Атака маршрутизаторов Ascend путем посылки UDP-пакета в порт 9.
    2000205 Possible Fraggle attack initiated.Это не атака вашей ЭВМ. Это скорее попытка перегрузить систему третьей стороны. Это может быть также попытка выявить всех сетевых соседей. Internet поддерживает широковещательную адресацию. Это позволяет послать один "пакет" сотням ЭВМ "субсети". Эта техника позволяет ЭВМ оповестить окружение о своем присутствии. Атакер, используя технику, называемую "spoofing", атакует третью сторону. Атакер притворяется жертвой и посылает эхо-пакеты в субсеть. Каждая включенная ЭВМ откликнется "отправителю". Этот вид атаки был использован югославскими хакерами против сайтов в США и НАТО. Системы Firewall блокируют такие пакеты по умолчанию. Разные пакеты могут быть посланы ЭВМ, чтобы вызвать эхо-отклик. Сюда входят:
    ICMP Echo Используются стандартной командой 'ping' Применяется также в smurf-атаке, которая подобна fraggle.
    UDP Echo Эхо-порт UDP, который перенаправляет трафик отправителю. Это первичный пакет, используемый для запуска атаки fraggle.
    chargen Перенаправляет произвольный трафик отправителю
    daytime Присылает значение текущего времени отправителю.
    quotd Присылает отправителю "quote of the day" или "fortune cookie".
    2000207 UDP short header. Заголовок UDP-дейтограммы содержит менее 8 байт (в надежде сломать программу-обработчик)
    2000208 Saihyousen attack. Атака против ConSeal PC Firewall
    2000209 W2K domain controller attack. Атакер посылает error-пакет вашей ЭВМ на UDP порт 464, а ваша система отвечает, возможно получение бесконечного цикла.
    2000210 Echo_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 7.
    2000211 Chargen_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 19.
    2000301 TCP port scan.
    2000302 TCP SYN flood.
    2000303 WinNuke attack.
    2000304 TCP sequence out-of-range.
    2000305 TCP FIN scan. Разновидность TCP-сканирования. Однако хакер здесь пытается осуществить так называемое "FIN-сканирование". Он пытается закрыть несуществующее соединение сервера. Это ошибка, но системы иногда выдают разные результаты в зависимости от того, является ли данная услуга доступной. В результате атакер может получить доступ к системе.
    2000306 TCP header fragmentation.
    2000307 TCP short header.
    2000308 TCP XMAS scan. Посылается TCP-сегмент с ISN=0 и битами FIN, URG и PUSH равными 1.
    2000309 TCP null scan. Посылается TCP-сегмент с ISN=0 и битами флагов равными нулю.
    2000310 TCP ACK ping.
    2000311 TCP post connection SYN.
    2000312 TCP FIN or RST seq out-of-range..
    2000313 TCP OS fingerprint. Посылается необычная комбинация TCP-флагов с тем, чтобы посмотреть реакцию. А по реакции определить вид ОС.
    2000314 NMAP OS fingerprint.
    2000315 Zero length TCP option.
    2000316 TCP small segment size..
    2000317 TCP SYN with URG flag.
    2000318 TCP Invalid Urgent offset.
    2000319 RFProwl exploit.
    2000320 TCP data changed.
    2000321 Queso Scan. Попытка определения версии ОС или прикладной программы
    2000401 DNS zone transfer.
    2000402 DNS cache poison. Атакер послал запрос DNS-серверу, который содержит также и отклик. Это может быть попыткой компрометировать DNS-серверов. Это может быть также результатом работы ISP, который перенаправляет своих клиентов на прокси-сервер. Это вероятнее всего вторжение в систему Для того чтобы улучшить рабочие параметры, DNS-серверы пытаются "кэшировать" имена локально. Серверы просматривают секции откликов всех пакетов, приходящих в систему. Они запоминают эти отклики на короткое время на случай, если кто-то еще нуждается в этой информации. Очевидной проблемой является случай, когда такой пакет содержит ложную информацию. В частности, кто-то может послать запрос в DNS, содержащий, кроме того, дополнительную информацию в секции отклика. Старые серверы воспринимают эту информацию, кэшируют ее, и выдают в ответ на запрос, если таковой поступит. (Новые DNS-серверы лишены этой дырки, но существует еще достаточно много старых серверов). Если ваш DNS-сервер обновлен, атака такого рода невозможна.
    2000403 DNS name overflow.
    2000404 DNS non-Internet lookup. DNS-запрос послан не DNS-серверу или запрос имеет некорректный формат.
    2000405 DNS malformed.
    2000406 DNS Internet not 4 bytes.
    2000407 DNS HINFO query.
    2000408 DNS spoof successful.
    2000409 DNS IQUERY.
    2000410 DNS I-Query exploit.
    2000411 DNS Chaos lookup.
    2000413 NetBIOS names query.
    2000414 DNS spoof attempt.
    2000415 DNS NXT record overflow.
    2000416 DNS null. DNS-запрос не содержит ни поля запросов, ни поля ответов ни поля дополнительной информации.
    2000417 DNS BIND version request. Сервер BIND DNS содержит в своей базе данных запись CHAOS/TXT с именем "VERSION.BIND". Если кому-то нужна эта запись, присылается версия программы BIND soft. Такой запрос сам по себе не является атакой, но может являться разведывательным рейдом. Однако, если возвращается версия типа "4.9.6-REL" или "8.2.1", это указывает, что у вас установлена версия с хорошо известной дыркой, связанной с переполнением буфера.
    2000418 AntiSniff DNS exploit. Программа AntiSniff может быть использована путем посылки специального DNS-кадра. В случае успеха, атакер может использовать программу, работающую в системе, где работает AntiSniff. AntiSniff представляет собой программу, которая разработана L0pht Heavy Industries в июле 1999. Атакер может использовать L0pht AntiSniff для получения информации о сети, которая может оказаться для него полезной при последующих атаках. Атакер может также использовать L0pht AntiSniff для определения положения компрометированных ЭВМ, переведенных в режим 6 (sniffing), которые могут им позднее использоваться.
    2000419 Excessive DNS requests.
    2000420 DNS ZXFR. Предпринята попытка осуществить зонный обмен DNS с транспортным сжатием, что само по себе нормально (популярный алгоритм "gzip"). Подобно всем зонным обменам, это позволяет удаленному атакеру сформировать карту вашей сети. Такой обмен может быть частью атаки, если поступает извне.
    2000421 DNS TSIG name overflow.
    2000422 DNS name overflow contains %.
    2000423 DNS name overflow very long.
    2000501 SMB malformed. Существует ошибка в старой версии SMB (система Microsoft для совместного использования файлов и принтеров в сети). Эта ошибка может быть использована при авторизации, путем посылки специально сформированных пакетов. При реализации этого трюка машина крэшится. Данная атака может быть предпринята успешно для систем Windows NT 4.0 SP4 и Windows 95 (все версии). Заметим, что имеются пэтчи для всех систем. Для того чтобы дырка работала, "File and Print Sharing" должно быть разрешено.
    2000502 SMB empty password.
    2000503 SMB I/O using printer share.
    2000504 SMB password overflow.
    2000505 SMB file name overflow.
    2000506 SMB Unicode file name overflow.
    2000507 SMB unencrypted password.
    2000508 RFParalyze exploit.
    2000600 HTTP Attack.
    2000601 HTTP URL overflow.
    2000602 HTTP cgi starting with php. Специально сконструированный URL может позволить нежелательный доступ к CGI на сервере
    2000603 HTTP URL directory traversal/climbing. Ситуация выглядит так, как будто атакер пытается прочесть посторонние файлы вашей системы. Обычная ошибка web-броузера заключается в том, что хакер может специфицировать URL, который выглядит как /../../../foo/bar.txt. Эта атака удается, так как программист не осуществляет двойной проверки URL, чтобы убедиться, корректен ли файл web-сайта. Сигнатурой такой атаки может быть наличие в URL последовательности ../... Иногда такого рода атака может быть имитирована некорректными связями, размещенными на странице. Это говорит о некорректной конфигурации. Во-первых, проверьте параметры URL, чтобы выяснить к какому файлу намерен получить доступ атакер. Затем проверьте, получил ли атакер доступ к файлу. Если это действительно критичный файл, и атакер был успешен, необходимо предпринять срочные действия. Например, если атакер получил доступ к файлу паролей, необходимо заменить все пароли. Следует также проверить является ли версия сервера новейшей и использованы ли все существующие пэтчи безопасности. Большинство таких атак предпринимается против "встроенных" web-серверов (т.e. web-серверов, добавленных в качестве части другого программного продукта), а не против реальных web-серверов типа Apache и IIS.
    2000604 HTTP asp with . appended.
    2000605 HTTP cgi with ~ appended.
    2000606 HTTP URL has many slashes.
    2000607 HTTP URL with ::$DATA appended. Предпринята попытка доступа к файлу с завершающей последовательностью ::$DATA. Некоторые серверы в этом случае возвращают исходный файл asp, вместо того, чтобы его (asp) исполнить, таким образом атакер получает критическую информацию о сервере. Исходные тексты программы сервера часто содержат пароли, имена скрытых файлов и т.д.
    2000608 HTTP GET data overflow.
    2000609 Данные HTTP CGI содержат ../../../... Данные, переданные в URL, имеют подозрительный проход, содержащий ../../../..; Этот проход может быть использован для доступа к привилегированным файлам. Атакер пытается добраться по дереву каталогов до нужных ему файлов. Некоторые приложения Web используют проходы, содержащие ../../../.. . Вам следует рассмотреть URL и аргумент GET с целью проверки их корректности. Если проход в аргументе GET, указывает на попытку доступа к привилегированным данным, возможно ваш сервер скомпрометирован.
    2000610 HTTP URL with blank appended.
    2000611 HTTP GET data with repeated char.
    2000612 IIS Double-Byte Code attempt. Специально сформированный URL, который может позволить нежелательный доступ . Выполняется попытка доступа к URL с завершающими %81 - %FE. Некоторые серверы возвращают в этом случае исходный файл, а не выполняют его, таким образом предоставляется атакеру критическая информация о сервере. Исходный текст программы сервера часто содержит скрытые пароли, имена файлов или данные об ошибках в программе.
    2000613 HTTP HOST: repeated many times.
    2000614 HTTP URL contains old DOS filename.
    2000615 HTTP ACCEPT: field overflow.
    2000616 HTTP URL contains /./.
    2000617 HTTP URL contains /....
    2000618 HTTP GET data contains /....
    2000619 HTTP URL scan.
    2000620 Whisker URL fingerprint.
    2000621 Web site copying.
    2000622 HTTP Authentication overflow.
    2000623 HTTP POST data contains ../../../... Некоторые Web-серверы используют "скрытое" поле формы, содержащее имя файла, чтобы управлять работой программы сервера. Однако несмотря на то, что поле скрытое, оно может быть переписано. Когда форма поступает серверу, он может пренебречь проверкой корректности значения поля. Таким образом, посылая некорректную форму, хакер может получить доступ к файлам Web-сервера, содержащим критическую информацию.
    2000624 HTTP POST data contains /....
    2000625 HTTP URL with repeated char.
    2000626 HTTP POST data with repeated char.
    2000627 HTTP URL bad hex code.
    2000628 HTTP URL contains %20.
    2000629 HTTP User-Agent overflow.
    2000630 HTTP asp with \ appended. Произошла попытка доступа к файлу asp с завершающим символом \. В некоторых ситуациях, вместо исполнения программы asp будет возвращен исходный asp-файл. Это раскроет атакеру критическую информацию о сервере. Исходный текст программы сервера часто содержит пароли, скрытые имена файлов или ошибки, которые в такой ситуации относительно легко найти. Хакер может затем использовать эту скрытую (hidden) информацию для вскрытия сервера.
    2000631 URL with repeated ..
    2000632 HTTP JavaServer URL in Caps.
    2000633 HTTP URL with +.htr appended.
    2000634 HTTP path contains *.jhtml or *.jsp.
    2000635 HTTP POST data contains script.
    2000636 HTTP HOST: field overflow.
    2000638 HTTP Cookie overflow.
    2000639 HTTP UTF8 backtrack.
    2000640 HTTP GET data contains script.
    2000641 HTTP login name well known.
    2000642 HTTP DAV PROPFIND overflow.
    2000643 SubSeven CGI.
    2000644 Repeated access to same Web service.
    2000645 HTTP URL with double-encoded ../.
    2000646 HTTP field with binary.
    2000647 HTTP several fields with binary.
    2000648 HTTP CONNECTION: field overflow.
    2000700 POP3 Attack.
    2000701 POP3 USER overflow.
    2000702 POP3 password overflow.
    2000703 POP3 MIME filename overflow.
    2000704 POP3 command overflow.
    2000705 POP3 AUTH overflow.
    2000706 POP3 RETR overflow.
    2000707 POP3 MIME filename repeated chars.
    2000708 POP3 MIME filename repeated blanks.
    2000709 POP3 Date overflow.
    2000710 POP3 APOP name overflow.
    2000711 POP3 false attachment.
    2000800 IMAP4 Attack.
    2000801 IMAP4 user name overflow.
    2000802 IMAP4 password overflow.
    2000803 IMAP4 authentication overflow.
    2000804 IMAP4 command overflow.
    2000805 IMAP4 Parm Overflow.
    2000901 Telnet abuse.
    2000902 Telnet login name overflow.
    2000903 Telnet password overflow.
    2000904 Telnet terminal type overflow.
    2000905 Telnet NTLM tickle.
    2000906 Telnet Bad Environment.
    2000907 Telnet Bad IFS. В UNIX, переменная "IFS" специфицирует символ, разделяющий команды. Если значение этой переменной изменено, тогда система детектирования вторжения не будет способна корректно интерпретировать команды. Более того, кто-либо может изменить эту переменную для того, чтобы модифицировать работу некоторых скриптов ядра. В частности плохой IFS станет разграничителем, используемым при разборе любых вводов, таких как имена файлов или DNS-имена. В этом случае, нужно установить IFS соответствующим символу '/' или '.'. Вообще, если вы хотите жить немного спокойнее, лучше заблокировать применение telnet, предложив пользователям перейти на SSH.
    2000908 Telnet Environment Format String Attack. В районе августа 2000, выявлено большое число атак типа "format string". Эти атаки связаны с попыткой проникнуть в Telnet-машины путем посылки некорректных переменных окружения (environmental variables with format commands).
    2000909 Telnet RESOLV_HOST_CONF. Переменная окружения RESOLV_HOST_CONF посылается с привлечением поля опций Telnet. Это поле не должно никогда изменяться таким способом. Это может означать попытку получения доступа к критическим файлам типа паролей и т.д.
    2000910 Telnet bad TERM. Совершена попытка исказить "TERM" Telnet. Клиент Telnet может эмулировать многие виды терминалов текстового типа. Клиент передает эту информацию серверу с помощью переменной "TERM" или команды "term-type". Если обнаружено необычное значение этой переменной, возможно предпринята атака против вашей системы.
    2000911 Telnet bad TERMCAP.
    2000912 Telnet XDISPLOC.
    2000913 Telnet AUTH USER overflow.
    2000914 Telnet ENV overflow.
    2000915 Telnet login name well known.
    2000916 Telnet Backdoor. Атакер пытается воспользоваться известным именем/паролем "задней" двери telnet Trigger . Протокольный анализатор извлекает login name и пароль из входной строки Telnet и сравнивает их со списком известных параметров доступа для задней двери telnet. Некоторые из них приведены ниже:
    wh00t! Пароль задней двери предоставляемый rootkit для Linux, разработанного в 1994 .
    lrkr0x Пароль задней двери предоставляемый Rootkit I для Linux, разработанного в 1996
    satori Rootkit IV для Linux.
    rewt Задняя дверь пользовательского аккоунта, которая предоставляет root-привилегии.
    h0tb0x Пароль задней двери для FreeBSD rootkit 1.2 (1/27/97).
    2001000 SMTP Attack.
    2001001 SMTP pipe in mail address. кто-то пытается компрометировать e-mail сервер путем посылки исполняемого кода shell внутри e-mail адреса. Это имеет целью компрометировать e-mail сервер, а также субсистему, обрабатывающую заголовки почтового сообщения. Ниже приводится пример SMTP-сессии с попыткой реализации такой атаки:
    HELO
    MAIL FROM: |/usr/ucb/tail|/usr/bin/sh
    RCPT TO: root
    DATA
    From: attacker@example.com
    To: victim@example.com
    Return-Receipt-To: |foobar
    Subject: Sample Exploit
    2001002 SMTP DEBUG command. Кто-то сканирует вашу систему с целью выявления ее уязвимости. В 1988, червь Morris уложил Интернет Internet. Одним из путей распространения червя являлась программа sendmail. Sendmail поддерживала нестандартную команду "DEBUG", которая позволяет любому получить контроль над сервером. Червь Morris автоматизировал этот процесс для распространения через системы sendmail Internet. Сейчас маловероятно, что вы найдете такую старую почтовую систему. Следовательно, такая атака будет означать, что кто-то использует универсальный сканер уязвимости. Иногда система может выйти из синхронизма (сбой в ISN), что вызывает большие потери пакетов. В таких условиях по ошибке может быть запущена команда DEBUG. Например, если вы работаете с версией сервера для системы 486, который обрабатывает большое количество e-mail, такая десинхронизация может произойти. Уязвимой системой является Sendmail/5.5.8.
    2001003 SMTP login name overflow.
    2001004 SMTP EXPN command.
    2001005 SMTP VRFY command.
    2001006 SMTP WIZ command.
    2001007 SMTP Too many recipients.
    2001008 SMTP corrupted MAIL command.
    2001009 SMTP email name overflow.
    2001010 SMTP corrupted RCPT command.
    2001011 SMTP relay attempt. Предпринята попытка использования SMTP в качестве ретранслятора сообщений - это может случиться, когда спамер некорректно использует SMTP-сервер. Это одна из наиболее успешных атак на Internet. Спамер регулярно ищет в Интернет ретранслирующие e-mail сервера. Примерно половина всех e-mail серверов поддерживают ретрансляцию в той или иной форме.
    2001012 SMTP command overflow.
    2001013 SMTP mail to decode alias. Обнаружено сообщение, адресованное пользователю с именем decode. Это может быть попыткой взломать почтовый сервер, или это может быть частью сканирования системы. Это достаточно старый трюк, выявленный в 1990. Системы UNIX позволяют посылать почту клиенту с именем decode, чтобы передать сообщение не клиенту, а программе uudecode. Атакер может попытаться таким образом переписать файлы таким образом, чтобы проникнуть в систему. Эта дырка связана с файлом /etc/aliases, содержащим строку типа:
    decode: |/usr/bin/uudecode
    Сейчас, такой тип вторжения может проявиться лишь в случае универсального сканирования с целью выявления уязвимости вашей системы. Например, атакер пытается передать по каналу uuencoded-файл после команды DATA. HELO
    MAIL FROM: test@example.com
    RCPT TO: decode
    DATA
    begin 644 /usr/bin/.rhosts
    $*R`K"@``
    `
    end
    .
    QUIT

    Этот пример пытается атаковать систему путем записи строки "+ +" в файл ".rhosts". Это будет указывать системе, что следует доверять любому, кто вошел в нее через программу типа 'rlogin'. Этот вид атаки существенен только для почтовых серверов, работающих под UNIX. Просмотрите файл "aliases", размещенный в /etc/aliases. Проверьте, нет ли строк типа:
    decode: |/usr/bin/uudecode
    uudecode: |/usr/bin/uuencode -d
    Удалите эти строки. Заметим, что новые системы не допускают такой возможности.
    2001014 SMTP mail to uudecode alias.
    2001015 SMTP too many errors.
    2001016 SMTP MIME file name overflow.
    2001017 SMTP uucp-style recipient.
    2001018 SMTP encapsulated relay.
    2001019 STMP encapsulated Exchange relay. Spam-атака. Выявляется инкапсулируемый почтовый адрес вида <IMCEASMTP-user+40destination+2Ecom@relay.com>. Некоторые версии Microsoft Exchange не способны проверять эти типы адресов, таким образом, они могут использоваться спамерами для посылки неавторизованной почты.
    2001020 SMTP mail to rpmmail alias.
    2001021 SMTP MIME name overflow.
    2001022 SMTP MIME filename repeated chars.
    2001023 SMTP MIME filename repeated blanks.
    2001024 SMTP ETRN overflow.
    2001025 SMTP Date overflow.
    2001026 SMTP Recipient with trailing dot.
    2001027 SMTP FROM: field overflow.
    2001028 SMTP MIME null charset. Обнаружено незнакомое почтовое сообщение, вероятно сконструированное, чтобы разрушить почтовый сервер. В заголовки "Reply-To:" сообщения встраиваются исполняемые Shell и PERL коды. Когда система откликается, эти коду будут исполнены. Например, старые версии list-сервера MAJORDOMO исполняют любой PERL-скрипт, который вставлен в это поле.
    2001030 SMTP ENVID overflow.
    2001031 SMTP false attachment.
    2001032 SMTP Expn Overflow.
    2001033 SMTP Vrfy Overflow.
    2001034 SMTP Listserv Overflow.
    2001036 SMTP Auth Overflow.
    2001040 SMTP Xchg Auth.
    2001041 SMTP Turn.
    2001101 Finger.
    2001102 Finger forwarding. Предпринята попытка использования программы finger для переадресации запроса другой системе. Это часто делается атакерами, чтобы замаскировать свою идентификацию. Finger поддерживает рекурсивные запросы. Запрос типа "rob@foo@bar" просит "bar" сообщить информацию о "rob@foo", заставляя "bar" послать запрос "foo". Эта техника может использоваться для сокрытия истинного источника запроса. Finger является опасным источником информации и по этой причине должен быть заблокирован в /etc/inetd.conf.
    2001103 Finger forwarding overflow.
    2001104 Finger command.
    2001105 Finger list.
    2001106 Finger filename.
    2001107 Finger overflow.
    2001108 Finger search. Демон "cfinger" позволяет осуществлять поиск любых или всех имен пользователей, при вводе "search.*". Эта возможность поиска предоставляет атакеру легкий способ пронумеровать всех пользователей системы. Широкополосные сканеры (напр. CyberCop Scanner, ISS Scanner) осуществляют сканирование этого типа. Сигнатурой для этого вида атаки является наличие строки "search.*" в качестве имени пользователя.
    2001109 Finger Backdoor. Кто-то пытается повторно войти в систему через известную заднюю дверь в finger. Раз система была компрометирована, атакеры могу оставит для себя открытую "потайную" дверь, через которую они смогут войти, когда захотят. Например, одна потайная дверь допускает посылку finger команды "cmd_rootsh", которая открывает shell с привилегиями суперпользователя. Заметим, что если потайная дверь действительно имеется, ваша система уже была скомпрометирована. В настоящее время, все известные потайные двери finger существуют только в системах UNIX. Если вы столкнулись с такой проблемой то, во-первых, просмотрите информацию откликов, которая может быть в наличии. Если вы обнаружили какие-то уведомления об ошибках, то вероятно попытка вторжения не была успешной (но не обольщайтесь). Во-вторых, если вы озабочены возможностью наличия потайной двери в системе, исполните команду finger сами. Чтобы устранить уязвимость данного вида, следует, во-первых, рассмотреть возможность удаления услуги finger вообще. Это опасная услуга, которая предоставляет полезную информацию атакерам. Во-вторых, если вы чувствуете, что система компрометирована, следует заново инсталлировать операционную систему. Поищите потайную дверь в списке пользователей. Трудно представить, что какой-то пользователь в вашей системе имеет имя "cmd_shell". Многие широкодиапазонные сканеры ищут такие потайные двери.
    2001110 Finger Scan. Производится сканирование известных из Finger имен пользователей с целью получения персональной информации. Например, если вы направляете запрос finger "jsmith", вы вероятно ищите данные о "Jane Smith". В безопасных сетях, любое использование finger подозрительно, так как оно может раскрыть важную информацию о пользователе. Однако, существует в системе большое число не пользовательских аккоунтов, таких как "adm", "bin" или "demo". Попытки Finger обратиться к этим аккоунтам указывают, что кто-то использует протокол finger для того, чтобы сканировать сервер с целью получения более существенной информации. В настоящее время, finger работает на UNIX-системах. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные, а за помощь им вам не платят.
    2001111 Finger Enumeration. Зафиксированы подозрительные команды finger. Finger используется для поиска информации о пользователях. Некоторые системы допускают множественный поиск пользователей. Здесь возможны некорректности. Например, запрос finger о пользователе с именем "e" выдаст список всех пользователей в системе, содержащими "e" в своем имени. Некоторые системы finger допускают также спецификацию множественных имен. Это означает, что finger для "a b c d e f...x y z" перечисляет всех пользователей в системе. В настоящее время, finger работает в основном на системах UNIX. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные.
    2001201 TFTP file not found.
    2001202 TFTP file name overflow.
    2001203 TFTP Traversal.
    2001204 TFTP Exe Transfer.
    2001205 TFTP Web Transfer.
    2001206 TFTP Echo Bounce.
    2001301 FTP invalid PORT command. Если вы такое обнаружили, это означает, что совершается попытка вторжения в вашу FTP-систему. Немногие ЭВМ допускают такую атаку. Команда "PORT" является частью протокола FTP но обычно незаметна для пользователя, хотя он часто и получает статусные сообщения "PORT command successful". Это уведомляет противоположную сторону о том, кода следует направлять данные. Эта команда форматируется в виде списка из 6 чисел, разделенных запятыми. Например:
    PORT 192,0,2,63,4,01
    Данная команда сообщает противоположной стороне, что данные следует отправлять по адресу 192.0.2.63, порт 1025. Если эта команда искажена, то вероятно атакер пытается компрометировать FTP-сервис. Однако, так как большинство FTP-сервисов противостоит этому типу атаки, шансов у хакера в этом варианте немного.
    2001302 FTP PORT bounce to other system.
    2001303 FTP PORT restricted.
    2001304 FTP CWD ~root command.
    2001305 FTP SITE EXEC command. Старые версии FTP-серверов поддерживают эту команду, которая разрешает нежелательный доступ к серверу. В версиях wu-ftpd ниже 2.2, имеется возможность исполнения программы (об этом хакер может только мечтать) . Ниже показана сессия, где "robert" имеет легальный аккоунт в системе и пытается реализовать режим строчно-командного доступа к shell. 220 example.com FTP server (Version wu-2.1(1) ready.
    Name (example.com:robert): robert
    331 Password required for robert.
    Password: foobar
    230 User robert logged in.
    Remote system type is UNIX.
    Using binary mode to transfer files.
    ftp> quote "site exec cp /bin/sh /tmp/.runme"
    200-cp /bin/sh /tmp/runme
    ftp> quote "site exec chmod 6755 /tmp/.runme"
    200-chmod 6755 /tmp/runme
    ftp> quit
    221 Goodbye.
    Теперь пользователь авторизован и может работать с shell на уровне привилегий root в каталоге /tmp.
    2001306 FTP USER name overflow.
    2001307 FTP password overflow.
    2001308 FTP CWD directory overflow.
    2001309 FTP file name overflow.
    2001310 FTP command line overflow.
    2001311 FTP pipe in filename. Совершена попытка исполнить программу на FTP-сервере. Допускающее это ошибка имеется во многих FTP-демонах около 1997, таких что, если перед именем файла присутствует символ PIPE (|), сервер пытается исполнить программу имя которой следует за ним. Так как FTP-сервер обычно работает с привилегией root, может произойти его компрометация. Проверьте, что у вас работает новейшая версия сервера.
    2001312 FTP MKD directory overflow.
    2001313 ProFTPD snprintf exploit.
    2001314 FTP SITE PSWD exploit.
    2001315 FTP compress exec exploit.
    2001316 FTP file exec exploit.
    2001317 FTP command too long.
    2001318 FTP data too long.
    2001319 FTP NLST directory overflow.
    2001320 FTP SITE ZIPCHK metacharacters.
    2001321 FTP SITE ZIPCHK buffer overflow.
    2001322 FTP SITE EXEC exploit.
    2001323 FTP PrivilegedBounce. Кто-то пытается нарушить безопасность FTP-сервиса, чтобы сканировать другие ЭВМ. Если атака FTP используется при одновременной спецификации привилегированного порта, можете не сомневаться - это сетевая атака. Возможно, что FTP-переадресация на непривилегированный порт является результатом FTP-прокси. По этой причине комбинированная атака рассматривается как отдельная сигнатура. Это позволяет атакеру маскировать свою сетевую идентичность. Возможно также, что атакер, используя эту технику, может обойти некоторые плохо конфигурированные фильтры пакетов или firewalls. Например, если ваш mail-сервер допускает соединения посредством telnet с вашим внутренним FTP-сервером, а с внешними ЭВМ из Internet не допускает, атакер сможет соединиться с вашим telnet-портом на вашем SMTP методом переадресации через ваш FTP-сервер. К системам допускающим такую атаку относятся SunOS 4.1.x, Solaris 5.x, большинство систем, работающих со старыми FTP-серверами. Чтобы покончить с такого рода угрозой раз и навсегда. Просмотрите, какие ЭВМ и порты вовлечены в этот процесс. Если это ваши ЭВМ, проконтролируйте, как это реализовано. Если же это не ваша ЭВМ, убедитесь, что администратор этой машины, видит, что в соединении участвует ваш FTP-сервер, и если атака осуществлена, ваша машина будет выглядеть, как источник этой атаки. Вы можете провзаимодействовать с этим администратором или по крайней мере записать logs оригинального источника атаки. После этих дипломатических шагов вам следует установить новую версию FTP-сервера, где данная ошибка исправлена, например, wu-ftpd 2.4.2 beta 15 или более новую.
    2001324 FTP Site Exec DotDot. Попытка неавторизованного доступа. Некоторые версии wu-ftpd позволяют использовать команду site exec для удаленных машин. Путем предоставления прохода с определенными параметрами, удаленный пользователь может исполнить произвольные команды на FTP-сервере. Эта атака позволяет атакующему выполнять команды на атакуемой машине. Это может привести к получению им доступа root-уровня. Такой дефект имеют системы wu-ftpd 2.4.1 и ранее. Чтобы защитить себя от таких атак, просмотрите команды, которые атакер использовал. Если они представляют угрозу для атакуемой ЭВМ, можете считать машину скомпрометированной. Обновите программное обеспечение FTP-сервера или замените его вообще.
    2001325 FTP Site Exec Format Attack.
    2001326 FTP Site Exec Tar.
    2001327 FTP Site Chown Overflow.
    2001328 FTP AIX Overflow.
    2001329 FTP HELP Overflow.
    2001330 FTP Glob Overflow.
    2001331 FTP Pasv DoS.
    2001332 FTP Mget DotDot.
    2001401 RWHO host name overflow.
    2001501 Back Orifice scan. Кто-то сканирует вашу систему на предмет троянского коня "Back Orifice". Back Orifice сканы наиболее частые атаки, встречающиеся в Internet. Ваша машина просканирована, но еще не выбрана для атаки. Это означает, что хакер сканирует тысячи ЭВМ в Interent, надеясь найти одну, которая была скомпрометирована посредством Back Orifice. Хакер не обязательно охотится именно на вашу ЭВМ. Большинство взломов происходит путем установки хакером инфицированных программ или документов в Internet в надежде, что какой-то неосторожный клиент скопирует и запустит их у себя. Хакер сканирует затем Internet и ищет эти скомпрометированные ЭВМ. Но даже, если ваша машина была скомпрометирована программой Back Orifice, ваша субсистема firewall может заблокировать доступ к ней.
    2001502 Netbus response.
    2001503 Quake backdoor.
    2001504 HP Remote watch.
    2001505 Back Orifice response.
    2001506 Back Orifice ping.
    2001507 PCAnywhere ping. Кто-то пингует систему для того чтобы проверить, работает ли PCAnywhere. Это может быть атака, но может быть и случайный инцидент. PCAnywhere является продуктом Symantec, который позволяет осуществить удаленное управление ЭВМ. Она является очень популярной в Internet для этих легальных целей, позволяя администраторам удаленно контролировать серверы. Хакеры часто сканируют Internet с целью поиска машин, поддерживающих этот продукт. Многие пользователи используют пустые пароли или пароли, которые легко угадать (например слово "password"). Это предоставит легкий доступ хакеру. Если хакер захватил контроль над машиной, он не только могут украсть информацию, но и использовать эту машину для атаки других ЭВМ в Интернет. Случайные сканирования клиентами PCAnywhere обычно видны со стороны соседей. Программа инсталлирует иконку, названную "NETWORK", которая сканирует локальную область. Хотя эти сканы не содержат враждебных намерений, они могут создавать дискомфорт. Чтобы проверить, что на самом деле имеет место, следует рассмотреть IP-адрес атакер. Если IP-адрес относится к локальному сегменту (т.e. подобен вашему IP-адресу), тогда ничего страшного. В противном случае (адрес внешний) - имеет место атака вашей системы. PCanywhere сканирует то, что называется диапазоном "класса C", например, 192.0.2.0 - 192.0.2.255. Если вы не работаете с PCAnywhere, тогда проблем нет. В противном случае, читайте советы по обеспечению безопасности сервера PCAnywhere.
    2001508 ISS Ping Scan.
    2001509 ISS UDP scan.
    2001510 Cybercop FTP scan.
    2001511 WhatsUp scan.
    2001512 Back Orifice 2000 ping.
    2001513 Back Orifice 2000 auth.
    2001514 Back Orifice 2000 command.
    2001515 Back Orifice 2000 response.
    2001517 Scan by sscan program.
    2001518 phAse Zero trojan horse activity. Возможная попытка вторжения. Программа phAse Zero обладает всеми стандартными особенностями троянского коня, включая возможность выгружать и загружать файлы в ЭВМ с помощью FTP, исполнять программы, стирать и копировать файлы, а также читать и записывать в конфигурационную базу данных (registry). Здесь имеется функция 'Trash Server', которая удалит все файлы из каталога вашей системы Windows. phAse Zero работает под Windows 95, 98 и Windows NT.
    2001519 SubSeven trojan horse activity.
    2001520 GateCrasher trojan horse activity.
    2001521 GirlFriend trojan horse activity.
    2001522 EvilFTP trojan horse activity. Неавторизованная попытка вторжения. Троянский конь EvilFTP является одним из многих программ подобного рода, который может использовать атакер для доступа к вашей компьютерной системы без вашего ведома. Когда программа, содержащая троянского коня работает, EvilFTP инсталлирует FTP-сервер на порт12346 с login "yo" паролем "connect." Этот троянский конь при инсталляции в удаленной системе позволяет атакеру выгружать и загружать файлы для системы, где он инсталлирован.
    2001523 NetSphere trojan horse activity.
    2001524 Trinoo Master activity.
    2001525 Trinoo Daemon activity.
    2001526 NMAP ping. Для проверки вашей системы на уязвимость используется программа NMAP. NMAP -очень популярная программа, используемая хакерами для сканирования Internet. Она работает под Unix, и имеет много конфигурационных опций и использует несколько трюков, чтобы избежать детектирования системами, детектирующими вторжение. NMAP не позволяет хакеру вторгнуться в систему, но допускает получение им полезной информации о конфигурации системы и доступных услугах. Программа часто используется как прелюдия более серьезной атаки.
    2001527 NetSphere Client. Активность клиента NetSphere. Это указывает, имеется пользователь в вашей сети, который применил NetSphere для хакерства. Это не должно быть заметно клиентам, если только они сами не работают с NetSpheres.
    2001528 Mstream agent activity.
    2001529 Mstream handler activity.
    2001530 SubSeven password-protected activity.
    2001531 Qaz trojan horse activity.
    2001532 LeakTest trojan horse activity.
    2001533 Hack-a-tack trojan horse activity.
    2001534 Hack-a-tack trojan horse ping.
    2001535 Bionet trojan horse activity.
    2001536 Y3K trojan horse ping.
    2001537 Y3K trojan horse activity.
    2001601 FTP login failed.
    2001602 HTTP login failed.
    2001603 IMAP4 login failed.
    2001604 POP3 login failed.
    2001605 rlogin login failed.
    2001606 SMB login failed.
    2001607 SQL login failed.
    2001608 Telnet login failed.
    2001609 SMTP login failed.
    2001610 PCAnywhere login failed.
    2001611 SOCKS login failed.
    2001612 VNC login failed.
    2001701 rpc.automountd overflow.
    2001702 rpc.statd overflow.
    2001703 rpc.tooltalkd overflow.
    2001704 rpc.admind auth.
    2001705 rpc.portmap dump.
    2001706 rpc.mountd overflow.
    2001707 RPC nfs/lockd attack.
    2001708 rpc.portmap.set.
    2001709 rpc.portmap.unset.
    2001710 rpc.pcnfs backdoor.
    2001711 rpc.statd dotdot file create.
    2001712 rpc.ypupdated command.
    2001713 rpc.nfs uid is zero.
    2001714 rpc.nfs mknod.
    2001715 rpc.nisd long name.
    2001716 rpc.statd with automount.
    2001717 rpc.cmsd overflow.
    2001718 rpc.amd overflow.
    2001719 RPC bad credentials.
    2001720 RPC suspicious credentials.
    2001721 RPC getport probe.
    2001722 rpc.sadmind overflow.
    2001723 rpc.SGI FAM access.
    2001724 RPC CALLIT unknown.
    2001725 RPC CALLIT attack.
    2001726 RPC CALLIT mount.
    2001727 rpc.bootparam whoami mismatch.
    2001728 RPC prog grind.
    2001729 RPC high-port portmap.
    2001730 RPC ypbind directory climb.
    2001731 RPC showmount exports.
    2001732 RPC selection_svc hold file.
    2001733 RPC suspicious lookup.
    2001734 RPC SNMPXDMID overflow.
    2001735 RPC CALLIT ping.
    2001736 RPC yppasswdd overflow.
    2001737 rpc.statd Format Attack.
    2001738 RPC Sadmind Ping.
    2001739 RPC Amd Version.
    2001801 IRC buffer overflow.
    2001802 SubSeven IRC notification.
    2001803 IRC Trinity agent.
    2001804 Y3K IRC notification.
    2001901 IDENT invalid response. Чужой сервер пытается использовать identd клиента. Многие программы осуществляют реверсивные lookups IDENT. Эти программы уязвимы к атакам, когда сервер присылает некорректный отклик.
    2001902 IDENT scan.
    2001903 IDENT suspicious ID.
    2001904 IDENT version.
    2001905 IDENT newline.
    2002001 SNMP Corrupt.
    2002002 SNMP Crack. Обнаружено большое число строк community (паролей), которые индицируют попытку вскрыть систему контроля паролей. Большое число сообщений SNMP с различными строками community за ограниченный период времени должны рассматриваться как подозрительная активность, и как попытка подобрать корректное значение поля community. SNMP(Simple Network Management Protocol) используется для мониторирования параметров оборудования. Однако, это крайне небезопасный протокол, и ничто не препятствует простому подбору пароля путем простого перебора. Следует конфигурировать систему так, чтобы она была доступна со стороны ограниченного числа машин. Рекомендуется также использовать максимально возможно длинные строки community, что позволит зарегистрировать подбор до того, как он успешно завершится.
    2002003 SNMP backdoor. Атакер пытается использовать известную "потайную дверь" сетевого оборудования. Однако, многие приборы имеют пароли для "потайной двери", которые могут использоваться для обхода нормальных проверок, предусмотренных нормальной системой обеспечения безопасности. Скрытые и недокументированные строки community имеются во многих субагентах SNMP, которые могут позволить атакерам поменять важные системные параметры. Удаленные атакеры могут убить любой процесс, модифицировать маршруты, или заблокировать сетевые интерфейсы. Важно то, что атакер может выполнить апосредовано произвольные команды, требующие привилегий суперюзера.
    2002004 SNMP discovery broadcast. Атакер посылает команду SNMP GET по широковещательному адресу. Это может быть попыткой определить, какие системы поддерживают различные возможности SNMP. Это часто дает полную информацию об управляемом приборе, и иногда может предоставить полный контроль над прибором. В то же время, SNMP крайне небезопасный протокол, с легко угадываемым паролем. В результате, он является популярным протоколом для хакеров.
    2002005 SNMP sysName overflow.
    2002006 SNMP WINS deletion. Совершена попытка стереть записи WINS через интерфейс SNMP сервера. Это может быть попытка реализовать Denial-of-Service (DoS) или просканировать систему безопасности. Клиенты Windows контактируют с системой WINS для того, чтобы найти серверы. Многие системы уязвимы для атак при помощи SNMP-команд, посланных серверу для того, чтобы стереть записи. Это не взламывает сервер, но после стирания записи в базе данных, клиенты и серверые смогут более найти друг друга. Однако этот отказ обслуживания (DoS) может предварять другие атаки. Это может быть частью широко диапазонного сканирования с целью поиска слабых точек в сети. Эта атака может быть против систем, где нет работающих SNMP или WINS.
    2002007 SNMP SET sysContact. Совершена попытка удаленно установить поле sysContact через SNMP. Это вероятно сканирование уязвимых мест вашей системы. Группа SNMP "system" используется всеми MIB. Она часто сканируется хакерами при предварительной разведке. Одним из способов сканирования является выполнение команд SET для поля "sysContact" для того, чтобы просмотреть, реагирует ли какая-либо система. Такие SET часто используют для взлома хорошо известные пароли/communities.
    2002008 SNMP lanmanger enumeration.
    2002009 SNMP TFTP retrieval.
    2002010 SNMP hangup. Совершена попытка подвесить пользователя коммутируемой телефонной сети с помощью протокола SNMP. Некоторые типы сетевого оборудования (Ascend, Livingston, Cisco, etc.) могут допускать такое подвешивание пользователей. Это может быть обычным отказом обслуживания (DoS) в chat-комнатах и при играх в реальном времени. Один участник в chat-комнате может не любить другого. Он может взять IP-адрес жертвы, затем осуществлять поиск, пока не найдут прибор доступа, через который подключен клиент телефонной сети.
    2002011 SNMP disable authen-traps. Совершена попытка заблокировать трэпы неудач SNMP-аутентификации, возможно с целью замаскировать активность хакера. Если строка community некорректна, прибор может послать на консоль управления трэп "authentication-failure". Эти строки community не управляют доступом всего SNMP-агента MIB. Вместо этого, они управляют "видами" MIB: различные строки community могут позволять управление различными частями MIB. Предположим сценарий, где атакер желает взломать строку community, отвечающую за секцию MIB поставщика. Это включает множество (возможно миллионы) попыток выяснить правильный пароль. Следовательно, чтобы избежать оповещений об атаке, нападающий должен заблокировать трэпы, которые могут поступить на консоль.
    2002012 SNMP snmpdx attack. Совершена попытка заменить Sun Solstice Extension Agent, используя SNMP. Это может быть попытка вскрыть систему. Sun Solaris 2.6 поставляется со встроенной SNMP. В этот пакет входит возможность "extension agents": агенты, которые подключены к первичному SNMP-агенту для управления другими частями системы. Следует просмотреть log-book b jndtnbnm на вопросы:
    Имеется ли платформа управления, которая может выполнять подобные операции? Является ли строка "community" одной из "печально" известных для Solaris (в особенности "all private")? Параметр "val" содержит имя программы, которая будет исполнена. Выглядит ли это как демон или выглядит ли она как программа, предназначенная для компрометации системы? Типичными вариантами компрометации является создание xterm или скрипта, который изменяет /etc/passwd.
    2002013 SNMP 3Com communities. Совершена попытка прочесть строку community/пароля устройства 3Com с помощью SNMP. Это может быть попыткой проникновения в систему. Многие старые версии оборудования 3Com содержат дефекты, которые делают строку community/пароля общедоступной. Атакер, чтобы получить пароли, может прочесть специфические таблицы, используя строку community+"public". После этого атакер получает полный контроль над прибором. Такого рода атаки возможны для хабов 3Com SuperStack II версий ранее 2.12, карт HiPer Arc, с кодами выпуска ранее 4.1.59.
    2002014 SNMP dialup username.
    2002015 SNMP dialup phone number.
    2002016 SNMP scanner.
    2002017 SNMP passwd.
    2002018 SNMP community long.
    2002019 SNMP echo bounce. Обнаружен пакет UDP путешествующий между портами SNMP и ECHO. Техника, которая иногда используется, заключается в том, что пакеты SNMP посылаются службе ECHO промежуточной системы. IP-адрес отправителя фальсифицируется так, чтобы ECHO посылалось службе SNMP атакуемой системы. Атакуемый объект доверяет промежуточной системе и поэтому принимает пакет.
    2002020 SNMP HP Route Metachar.
    2002101 rlogin -froot backdoor.
    2002102 rlogin login name overflow.
    2002103 rlogin password overflow.
    2002104 rlogin TERM overflow.
    2002105 Rlogin login name well known.
    2002201 Melissa virus.
    2002202 Papa virus.
    2002203 PICTURE.EXE virus.
    2002204 W97M.Marker.a virus.
    2002205 ExploreZip worm.
    2002206 Keystrokes monitored.
    2002207 PrettyPark worm.
    2002208 ILOVEYOU worm.
    2002209 Worm extensions.
    2002210 Worm address.
    2002301 Duplicate IP address.
    2002401 NNTP name overflow.
    2002402 NNTP pipe seen.
    2002403 NNTP Message-ID too long.
    2002500 Suspicious URL.
    2002501 bat URL type.
    2002502 cmd URL type.
    2002503 CGI aglimpse. Совершена попытка исполнить программу aglimpse, которая имеет известные уязвимости. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. Большая часть того, что вы читали в новостях о хакерских "штучках", является описанием слабостей таких программ и повреждений web-сайта. Особенно много информации можно найти о слабостях cgi-bin. Если скрипт виден внешнему миру, вам следует удалить его из данного каталога. Следует также удалить все динамическое содержимое, которое не является абсолютно необходимым для работы web-сайта. Выполните двойную проверку скриптов, которые вы действительно используете, на предмет наличия в них брешей уязвимости. Данная атака является стандартной, использующей метасимвольный CGI на PER. Программа PERL передает "поврежденный" ввод пользователя непосредственно в интерпретатору shell.
    2002504 CGI AnyForm2. Совершена попытка исполнить программу anyform2, которая имеет известную уязвимость. Программа AnyForm cgi-bin содержит уязвимость, которая позволяет удаленному атакеру исполнять программы Web-сервера. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ.
    2002505 CGI bash. Совершена попытка исполнить скрипт bash, который в случае успеха, позволит хакеру получить доступ к серверу. Это программа shell, которая может исполнять произвольные операции на сервере. Если она была случайно помещена в удаленно доступный каталог, и, если вы обнаружили, что какие-то параметры системы стали доступны хакеру, считайте свою систему скомпрометированной. Вы должны немедленно удалить эту программу из данного каталога, проверить систему на наличие троянских коней и проконтролировать, не изменялась ли ее конфигурация.
    2002506 CGI campas. Совершена попытка исполнить campas, которая имеет известную уязвимость. Это известный скрипт, поставляемый с оригинальными web-серверами NCSA. Он оказался весьма популярным среди хакеров (вместе с phf), но в настоящее время его важность незначительна. Эта точка уязвимости позволяет удаленному атакеру исполнять команды на ЭВМ Web-сервера, как если бы он работал на самой машине, где размещен httpd. Эта уязвимость разрешает доступ хакеру к файлам web-сервера. При определенных конфигурациях web-сервера возможно получение хакером административного доступа к ЭВМ.
    2002507 CGI convert.bas.
    2002508 CGI csh.
    2002509 CGI faxsurvey.
    2002510 CGI finger. Произведена попытка исполнить программу finger, который может позволить хакеру неавторизованный доступ к серверу. Атакер сканирует web-сервер системы и ищет потенциальные точки уязвимости в секции "dynamic content generation". Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователь получает доступ к сайту. Существуют сотни таких программ, которые имею окна уязвимости. в данном примере, хакер просматривает web-сервер и ищет одну из таких уязвимых программ. Дополнительную информацию можно найти в cgi-bin exploits. Если этот скрипт виден внешнему миру, его следует удалить из данного каталога. Следует удалить также все динамические данные, которые совершенно необходимы для работы web-сайта.
    2002511 CGI formmail.
    2002512 CGI formmail.pl.
    2002513 CGI glimpse. Попытка исполнения программы glimpse, которая известна своими уязвимостями. Эти уязвимости позволяют атакеру исполнять команды на ЭВМ Web-сервера во время работы процесса пользователя в httpd. В зависимости от конфигурации web-сервер, это может позволить атакеру получит root или административный доступ к ЭВМ. В любом случае, атакер сможет изменить содержимое web-сайта.
    2002514 CGI guestbook.cgi.
    2002515 CGI guestbook.pl.
    2002516 CGI handler. Попытка исполнения CGI-хандлера, который обладает известными слабостями Эта CGI-программа является частью "Outbox Environment" в системах SGI IRIX. Программа может использоваться для выполнения любой команды на web-сервере. Для того, чтобы реализовать это, используйте программу Telnet следующим образом:
    telnet www.example.com 80
    GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0
    Используйте символ TAB, чтобы ввести пробел в пределах команды.
    2002517 CGI htmlscript.
    2002518 CGI info2www.
    2002519 CGI machineinfo.
    2002520 CGI nph-test-cgi.
    2002521 CGI perl. Произведена попытка исполнить perl-скрипт, который позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций.
    2002522 CGI perl.exe. Произведена попытка исполнить perl.exe, которая позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций.
    2002523 CGI pfdispaly.cgi.
    2002524 CGI phf.
    2002525 CGI rguest.exe.
    2002526 CGI wguest.exe.
    2002527 CGI rksh.
    2002528 CGI sh.
    2002529 CGI tcsh.
    2002530 CGI test-cgi.tcl.
    2002531 CGI test-cgi.
    2002532 CGI view-source.
    2002533 CGI webdist.cgi.
    2002534 CGI webgais.
    2002535 CGI websendmail.
    2002536 CGI win-c-sample.exe.
    2002537 CGI wwwboard.pl.
    2002538 CGI uploader.exe.
    2002539 CGI mlog.html.
    2002540 CGI mylog.html.
    2002541 CGI snork.bat.
    2002542 CGI newdsn.exe.
    2002543 FrontPage service.pwd.
    2002544 .bash_history URL.
    2002545 .url URL type.
    2002546 .lnk URL type.
    2002547 WebStore admin URL.
    2002548 Shopping cart order URL.
    2002549 Order Form V1.2 data URL.
    2002550 Order Form data URL.
    2002551 EZMall data URL.
    2002552 QuikStore configuration URL.
    2002553 SoftCart password URL.
    2002554 Cold Fusion Sample URL.
    2002555 favicon.ico bad format.
    2002556 Site Server sample URL.
    2002557 IIS sample URL.
    2002558 IIS password change.
    2002559 IIS malformed .HTR request.
    2002560 IIS data service query.
    2002561 .htaccess URL.
    2002562 passwd.txt URL.
    2002563 NT system backup URL.
    2002564 CGI imagemap.exe.
    2002565 adpassword.txt URL.
    2002566 CGI whois suspicious field.
    2002567 Cold Fusion cache URL.
    2002568 IIS malformed HTW request.
    2002569 CGI finger.cgi.
    2002570 WebSpeed admin URL.
    2002571 UBB suspicious posting.
    2002572 SubSeven ICQ pager URL.
    2002573 Oracle batch file URL.
    2002574 sojourn.cgi argument contains %20.
    2002575 Index Server null.htw exploit.
    2002576 FrontPage extension backdoor URL. Прислан "подозрительный" URL. Библиотека dvwssr.dll, встроенная в расширения FrontPage 98 для IIS, включает в себя ключ шифрования "Netscape engineers are weenies!". Этот ключ может быть использован для маскирования имени запрошенного файла, который затем передается в качестве аргумента в dvwssr.dll URL. Любой, кто имеет привилегии доступа к web-серверу ЭВМ мишени может загрузить любую Web-страницу, включая файлы текстов программ ASP. Используя файл dvwsrr.dll можно также переполнить буфер. Успешная атака может позволить исполнение на сервере удаленной программы.
    2002577 FrontPage htimage.exe URL.
    2002578 InfoSearch CGI exploit.
    2002579 Cart32 Clientlist URL.
    2002580 Cart32 ChangeAdminPassword URL.
    2002581 Listserv CGI exploit.
    2002582 Calendar CGI exploit. Подозрительный URL. Конфигурационный параметр содержит мета-символы, которые вероятно означают, что атакер пытается использовать слабости в некоторых версиях CGI-скрипта. В случае успеха, он сможет выполнить произвольную команду на сервере.
    2002583 Rockliffe CGI exploit.
    2002584 RealServer Denial-of-service URL.
    2002585 Java Admin Servlet backdoor URL. Административный модуль Java Web Server допускает компиляцию и исполнение программы Java server с помощью специального URL. Если атакеру удалось загрузить свой собственный Java-код на сервере, он может тогда скомпилировать и исполнить этот код и получить контроль над серверной системой.
    2002586 DOS DoS URL.
    2002587 Auction Weaver CGI exploit.
    2002589 CGI jj exploit.
    2002590 classifieds.cgi.
    2002591 BNBSurvey survey.cgi.
    2002592 YaBB exploit.
    2002593 Webplus CGI exploit.
    2002594 Squid cachemgr.cgi.
    2002595 IIS system32 command.
    2002596 Webevent admin.
    2002597 Unify UploadServlet.
    2002598 Thinking Arts directory traversal.
    2002599 Lotus Domino directory traversal.
    2002600 Commerce.cgi directory traversal.
    2002601 CGI mailnews suspicious field.
    2002602 FrontPage Publishing DoS.
    2002603 way-board cgi file access.
    2002604 roads cgi file access.
    2002605 Hack-a-tack ICQ pager URL.
    2002606 Bionet ICQ pager URL.
    2002607 IIS .printer overflow.
    2002608 ISAPI index extension overflow.
    2002609 Y3K ICQ pager URL.
    2002610 HTTP Pfdisplay Execute.
    2002611 HTTP Pfdisplay Read.
    2002701 SMB passwd file.
    2002702 SMB sam file.
    2002703 SMB winreg file.
    2002704 SMB pwl file type.
    2002705 SMB win.ini file.
    2002706 Startup file access.
    2002707 SMB autoexec.bat file access.
    2002710 SMB RICHED20.DLL access.
    2002801 MS rpc dump. Атакер пытается сканировать вашу систему для услуг RPC/DCOM. Возможно он ищет слабости в системе доступа. Была попытка загрузки списка всех услуг RCP/DCOM. Это специальная команда, которая может быть послана к "RPC End-Point Mapper" работающему с port 135. Эта атака не направлена непосредственно на вторжение. Она является частью (разведывательного этапа) reconnaissance атаки. Команда 'epdump' попросит ЭВМ Windows перечислить все работающие сервисы. Хакер, получив эти данные, сможет эффективнее искать слабые места в вашей обороне. Если хакер найдет какие-то их этих услуг, он вероятно попытается воспользоваться ими. Например, существуют пути, посредством которых спамер может направить e-mail через Microsoft Exchange Servers. Путем выполнения 'epdump', спамер может выяснить, работает ли машина в качестве сервера. Если это так, спамер может затем заставить систему переадресовать SPAM своим "клиентам". Зафильтруйте порт 135 в firewall, как для UDP так и TCP.
    2002802 MS share dump.
    2002803 MS domain dump.
    2002804 MS name lookup.
    2002805 MS security ID lookup.
    2002806 Malformed LSA request.
    2002807 RFPoison attack.
    2002808 LsaLookup Denial of Service.
    2002901 PPTP malformed.
    2002902 IGMP fragments.
    2002903 SNTP malformed.
    2002904 XDMCP gdm exploit.
    2002905 VNC no authentication.
    2002906 VCF attachment overflow.
    2002907 SNTP overflow.
    2002908 Quake Exploit.
    2002911 RADIUS User Overflow.
    2002912 RADIUS Pass Overflow.
    2003001 HTTP port probe.
    2003002 POP3 port probe.
    2003003 SMTP port probe.
    2003004 FTP port probe.
    2003005 IMAP4 port probe.
    2003006 TELNET port probe.
    2003007 FINGER port probe.
    2003008 RLOGIN port probe.
    2003009 NetBIOS port probe.
    2003010 NNTP port probe.
    2003011 DNS TCP port robe.
    2003012 PCANYWHERE port probe.
    2003013 SQL port probe.
    2003014 MSRPC TCP port probe.
    2003015 XWINDOWS port probe. Возможно хакер просканировал вашу систему, чтобы проверить, доступно ли XWINDOWS. Иногда это делается в ходе подготовки будущей атаки, или иногда это делается с целью выяснения, уязвима ли ваша система.
    2003016 RPC TCP port probe.
    2003017 SOCKS port probe. Кто-то сканирует вашу систему, чтобы проверить, не работает ли там SOCKS. Это означает, что хакер хочет устроить переадресацию трафика через вашу систему на какой-то другой сетевой объект. Это может быть также chat-сервер, который пытается определить, не пробует ли кто-то использовать вашу систему для переадресации. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ к внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации.
    2003018 PPTP port probe.
    2003019 IRC port probe.
    2003020 IDENT port probe.
    2003021 Linux conf port probe.
    2003022 LPR port probe.
    2003101 TCP trojan horse probe.
    2003102 TCP port probe. Кто-то пытался получить доступ к вашей машине, но не смог. Это довольно распространенный вид атаки. Типовой хакер сканирует миллионы ЭВМ, не обольщайтесь вы не являетесь главным объектом интересов хакеров, но и расслабляться пожалуй не следует.
    2003103 Netbus probe. Кто-то попрововал получить доступ к вашей ЭВМ с помощью "NetBus Trojan Horse" и потерпел неудачу. Хакер ищет ЭВМ, скомпрометированную посредством этой программы. Раз вы не скомпрометированы, хакер потерпел неудачу. Программа Trojan рассылается клиентам в надежде, что какой-то легкомысленный человек ее запустит. Задача такой программы похитить пароль, установить вирус, или переформатировать ваш диск. Специальную популярную группу образуют троянские кони, обеспечивающие удаленный доступ к вашей машине. Такие программы хакер пытается прислать по почте, через chat или новости, при этом хакер может не знать, где в Интернет находится ваша ЭВМ (он не знает, кто читает новости, да и по почте он рассылает эту гадость по тысячам адресов). Хакер знает только, кто является вашим провайдером, и вынужден сканировать всех клиентов данного ISP. При таком сканировании хакера устроит ситуация, когда вы получили данного троянского коня от другого атакера.
    2003104 Proxy port probe. Атакер сканирует вашу систему с целью обнаружения прокси-сервера. Затем атакер может воспользоваться вашим прокси-сервером для анонимного просмотра Internet. В настоящее время сканирование TCP-портов 3128,8000 или 8080 рассматривается как обращение к прокси.
    2003105 SubSeven port probe.
    2003106 T0rn port probe.
    2003201 SECURITY/SAM reg hack. Была предпринята попытка доступа к ключу registry под HKLM/SECURITY/SAM. Под этим ключом зарегистрированы имена и пароли пользователей. Хотя пароли зашифрованы, они могут быть проанализированы off-line и выяснены путем грубого перебора.
    2003202 RUN reg hack. Была предпринята попытка записи в ключи registry, которые управляют программой при загрузке системы или когда в систему входит новый пользователь. Такими ключами являются
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnce
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnceEx
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServices
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesOnce
    HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesEx
    Если имела места попытка записи в один из этих ключей, это может быть попыткой продвинуть Trojan Horse.
    2003203 RDS reg hack. Была предпринята серьезная попытка скомпрометировать систему или легальная сетевая платформа осуществляет удаленное конфигурирование системы. Осуществлена попытка удаленной записи ключей registry
    HKLM\SOFTWARE\Microsoft\DataFactory\HandlerInfo или
    HKLM\SOFTWARE\Microsoft\Jet\3.5\Engines\SandboxMode.
    Эти ключи ограничивают удаленный доступ к определенным базам данных в системе Windows. Атакер может попытаться установить свои значения для этих объектов registry, так что неавторизованный удаленный доступ может быть осуществлен позднее через точку уязвимости RDO exploit. По умолчанию, эти ключи могут быть переписаны кем угодно. Разрешения должны быть изменены так, что только администратор мог их менять.
    2003204 Index Server reg hack. Была предпринята попытка удаленного доступа к записям Index Server's registry. Сделана попытка доступа к ключу registry Remove remote access в HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths
    2003205 NT RASMAN Privilege Escalation attempt. Была предпринята попытка удаленного доступа к троянскому коню RAS manager. Сделана попытка доступа к ключу registry HKLM\SYSTEM\CurrentControlSet\Services\RASMan, который удаленно изменяет программу путем изменения сервера, при следующем запуске ЭВМ, будет исполнена специфицированная программа.
    2003206 LSA Secrets attempt. Была предпринята попытка удаленного доступа к "Local System Authority" через вызов registry. Атакер получает удаленный доступ к информации о секретных пароля хremotely. Эти пароли хранятся в зашифрованном виде в registry.
    2003207 AeDebug reg hack.
    2003208 IMail privilege escalation attempt.
    2003209 SQL Exec Passwd. Была предпринята попытка сканирования записей SQLExecutive registry. Происходит подозрительное чтение записей registry из SQL-сервера. Иногда пароли записываются в registry, что делает систему уязвимой.
    2003301 AOL Instant Messenger overflow.
    2003302 AOL w00w00 attack.
    2003401 SNMP port probe.
    2003402 RPC UDP port probe.
    2003403 NFS port probe.
    2003404 TFTP port probe.
    2003405 MSRPC UDP port probe.
    2003406 UDP ECHO port probe.
    2003407 CHARGEN port probe.
    2003408 QOTD port probe.
    2003409 DNS UDP port probe.
    2003410 MSDNS port probe.
    2003411 NFS-LOCKD port probe.
    2003412 Norton Antivirus port probe.
    2003501 UDP Trojan Horse probe.
    2003502 UDP port probe.
    2003601 FTP passwd file.
    2003602 FTP sam file.
    2003604 FTP pwl file type.
    2003605 FTP win.ini file.
    2003606 FTP Host File.
    2003701 TFTP passwd file.
    2003702 TFTP sam file.
    2003704 TFTP pwl file type.
    2003705 TFTP win.ini file.
    2003706 TFTP Host File.
    2003707 TFTP Alcatel files.
    2003801 HTTP GET passwd file. Была предпринята подозрительная попытка доступа к файлу. Сделана попытка доступа к файлу passwd, который содержит зашифрованные Unix-пароли. Атакер может после этого использовать общедоступные программные средства для вскрытия паролей, содержащихся в этом файле.
    2003802 HTTP GET sam file.
    2003804 HTTP GET pwl file type.
    2003806 HTTP GET AltaVista password.
    2003901 HTTP POST passwd file.
    2003902 HTTP POST sam file.
    2003904 HTTP POST pwl file type.
    2003905 HTTP POST win.ini file. Была предпринята попытка удаленного доступа к системному файлу WIN.INI посредством Web-формы. Эта попытка может быть сопряжена с намерением реконфигурировать систему, чтобы реконфигурированная система при последующем запуске загрузила троянского коня.
    2004001 SOCKS connect. Кто-то подключился через вашу систему, используя протокол SOCKS. Это может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ, а также сервер chat, пытающийся определить, не пробует ли кто-то проскочить через вашу систему чтобы работать анонимно на "халяву". SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. Ваша внутренняя сеть должна использовать IP-адреса, которые никогда не появляются в Internet. Такими адресами обычно являются "192.168.x.x", "172.16.x.x" или "10.x.x.x".
    2004002 SOCKS over SOCKS. Кто-то подключился через вашу систему, используя протокол SOCKS. то может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ. В этом случае, трафик оказывается инкапсулированным в SOCKS, это означает, что атакер вероятно намерен использовать вашу систему для переадресации к другой системе SOCKS. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины.
    2004101 Java contains Brown Orifice attack.
    2004201 HTTP Cross site scripting.
    2004301 DHCP Domain Metachar.
    2004302 BOOTP File Overflow.
    2004303 UPNP NOTIFY overflow.
    2004401 SubSeven email.
    2004402 Bionet email. Программа троянского коня Bionet имеет возможность посылать оповещения через e-mail, когда система, содержащая троянского коня, загружается. Это позволяет хакеру знать, что Bionet работает, и ваша система может быть компрометирована хакером. Судя по всему ваша система скомпрометирована. Вам следует использовать антивирусную программу, чтобы немедленно удалить троянского коня Bionet из вашей системы.
    2004403 Y3K email.
    2004501 HTTP GET contains xp_cmdshell. В качестве аргумента URL обнаружена строка xp_cmdshell; это обычно указывает, что предпринята попытка исполнить команду shell для атакера исполнять на сервере команды shell.
    2004502 HTTP POST contains xp_cmdshell. В данных, передаваемых Web-сайту, обнаружена строка xp_cmdshell. Это обычно указывает, что предпринята попытка выполнить команду shell на SQL-сервере. Если SQL-сервер некорректно сконфигурирован, имеется возможность для атакера выполнять на сервере команды shell.
    2004601 Code Red I.
    2004602 Code Red II.
    2004603 Code Red II+.
    2009100 DNS crack successful.
    2009201 ISS Scan.
    2009202 CyberCop Scan.
    2009203 Nessus Scan.
    2009204 Satan Scan.
    2009205 Saint Scan.
    2009206 Cerebus Scan.
    2009207 Retina Scan.
    2010000-2010999 User-specified filename.
    2011000-2011999 User-specified URL.
    2012000-2012999 User-specified email recipient.
    2013000-2013999 User-specified email pattern.
    2014000-2014999 User-specified MIME-attached filename.
    2015000-2015999 User-specified TCP probe port.
    2016000-2016999 User-specified UDP probe port.
    2017000-2017999 User-specified registry key.
    2018000-2018999 User-specified TCP trojan response.
    2019000-2019999 User-specified IRC channel name.
    2020000-2020999 User-specified Java pattern.
    2900001 Application Terminated.
    2900002 Application Added.
    2900003 Application Communication Blocked.
    Config Configuration parameters.

    Previous: 6.3 Система Firewall    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4 Системы шифрования


    previous up down next index index
    Previous: 6.3.1 Список видов атак, зарегистрированных Network ICE    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.1 Алгоритм DES

    6.4 Системы шифрования
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Проблема сокрытия содержания послания при его транспортировке волновала людей с древних пор. Известно, что еще Цезарь (100-44 годы до нашей эры) при переписке использовал шифр, получивший его имя. В 1518 году Джоанес Тритемиус написал первую книгу по криптографии, где впервые были описаны многоалфавитные подстановочные шифры. Лишь в 1918 году во время первой мировой войны в Германии была применена шифровальная система ADFGVX. Позднее в 1933-45 годах в Германии была разработана и применена первая шифровальная машина (на этом принципе работает система crypt в UNIX). Мощное развитие криптография получила в период второй мировой войны. С этой шифровальной машиной связан и первый успех в области вскрытия сложных шифров.

    Чаще всего шифруются тексты документов, но в последнее время шифрованию подвергаются и изображения, голосовые данные и даже тексты программ.

    Шифрование предполагает преобразование исходного текста Т с использованием ключа К в зашифрованный текст t. Симметричные криптосистемы для шифрования и дешифрования используется один и тот же ключ К. Появившиеся в последние годы системы с открытым ключом, осуществляют шифрование с помощью общедоступного ключа, для дешифрования в этом случае необходим секретный ключ, который порождается совместно с открытым. Как шифрование, так и дешифрование может реализоваться программно или аппаратно. При этом должны выполняться определенные требования:

    • Знание использованного алгоритма не должно снижать надежность шифрования.
    • Длина зашифрованного текста должна быть равна длине исходного открытого текста (это требование относится к числу желательных и выполняется не всегда).
    • Зашифрованный текст не может быть прочтен без знания ключа.
    • Каждый ключ из многообразия ключей должен обеспечивать достаточную надежность.
    • Изменение длины ключа не должно приводить к изменению алгоритма шифрования.
    • Если известен зашифрованный и открытый текст сообщения, то число операций, необходимых для определения ключа, не должно быть меньше полного числа возможных ключей.
    • Дешифрование путем перебора всех возможных ключей должно выходить далеко за пределы возможностей современных ЭВМ.
    • Если при шифровании в текст вводятся дополнительные биты, то алгоритм их внесения должен быть надежно скрыт.
    • Не должно быть легко устанавливаемой зависимости между последовательно используемыми ключами.
    • Алгоритм может быть реализован аппаратно.

    В симметричных криптосистемах могут использоваться одно- или многоалфавитные подстановки (например, одно-алфавитная подстановка Цезаря), при этом производится замена символов исходного текста на другие с использованием достаточно сложных алгоритмов. Многоалфавитные подстановки несравненно более надежны. К числу простых методов шифрования относится способ перестановок символов исходного текста (этот метод эффективен только лишь при достаточно большой длине исходного текста). Множество перестановок символов для текста из N символов равно N!, что до какой-то степени гарантирует надежность процедуры. Несколько большую надежность предлагает метод гаммирования, когда на исходный текст накладывается псевдослучайная последовательность бит, генерируемая на основе ключа шифрования, например, с использованием операции исключающего ИЛИ. Обратное преобразование (дешифрование) выполняется генерацией точно такой же псевдослучайной последовательности и наложением ее на зашифрованной текст. Гаммирование уязвимо для случая, когда злоумышленнику становится известен фрагмент исходного текста. В этих обстоятельствах он без труда восстановит фрагмент псевдослучайной последовательности, а по нему и всю последовательность. Так если достаточно большое число сообщений начинается со слов "Секретно", а в конце ставится дата сообщения, расшифровка становится вопросом времени и терпения.

    Ключ может быть одноразового и многоразового использования. Одноразовый ключ достаточно большой длины (или бесконечный) может обеспечить сколь угодно высокую надежность, но его использование создает неудобства, связанные с его транспортировкой (ключ должен быть как-то доставлен получателю зашифрованного послания). В табличке 6.4.1 приведен пример использования такого вида ключа.

    Таблица 6.4.1.

    Исходный текст

    9

    5

    18

    1

    3

    19

    20

    3

    21

    11

    20

    6

    Используемый ключ

    23

    5

    13

    14

    10

    17

    5

    1

    13

    9

    27

    11

    Зашифрованный текст

    32

    10

    31

    15

    13

    36

    25

    4

    34

    20

    47

    17

    Зашифрованный текст получается здесь из исходного добавлением значения очередного кода ключа (сложение может быть заменено вычитанием или операцией исключающее ИЛИ). Исходный текст в данном случае невозможно восстановить без знания ключа.

    Примером шифрования с использованием секретного ключа является метод Видженера (Vigenere; www.massconfusion.com/crypto/lecture/method6.html), относящийся к числу много алфавитных подстановок. Здесь берется небольшое целое число m и алфавит после каждой символьной подстановки сдвигается на m символов. Например, для m=4

    1. abcdefghijklmnopqrstuvwxyz
       ghijklmnopqrstuvwxyzabcdef
    2. opqrstuvwxyzabcdefghijklmn
    3. lmnopqrstuvwxyzabcdefghijk
    4. fghijklmnopqrstuvwxyzabcde

    Ключ = golf (смотри левую вертикальную колонку символов).

    Исходный текст разбивается на группы по m символов (в рассмотренном случае по 4). Для каждой группы первый символ заменяется соответствующей буквой первого алфавита, вторая - из второго и т.д. Например, фраза "get me out of here please" будет преобразована следующим образом:

    getm eout ofhe repl ease
    mser kcfy utsj xsaq kohj.

    Наибольшее распространение в последнее время получило блочное шифрование, где последовательность процедур воздействует на блок входного текста. Одним из наиболее известных таких методов стал DES (Data Encryption Standard), который работает с блоками данных по 64 байта (1998 год). Существует четыре режима работы:

    ECB

    electronic code book.

    CBC

    cipher block chaining

    CFB

    cipher feedback

    OFB

    output feedback.

    Из-за того, что алгоритм DES в настоящее время представляется устаревшим и не обеспечивает достаточной надежности, довольно часто исходный текст последовательно шифруется трижды с помощью различных ключей.

    Шифрование и дешифрование базируются на использовании ключей. Математически это можно выразить следующим образом (cм. lglwww.epfl.ch/~jkienzle/digital_money/node11.html; www.ee.mtu.edu/courses/ ee465/groupa/overview.html):

    EK(M) = C
    DK(c) = M, где K - ключ, M - исходный текст; C - зашифрованный текст.

    Эффективность системы шифрования определяется числом кодовых комбинаций или ключей, которое необходимо перебрать, чтобы прочесть зашифрованный текст. Существует две системы ключей шифрования/дешифрования. Для симметричных алгоритмов предполагается, что ключ дешифрования может быть вычислен по известному ключу шифрования. Оба ключа при этом должны быть секретными (например, система DES). Отправитель и получатель должны знать ключи до начала обмена (эти ключи могут и совпадать). Набор таких ключей может быть достаточно большим и в процессе инициализации осуществляется выбор пары ключей, которые будут использованы в данной сессии. В общем случае могут использоваться довольно большие кодовые таблицы, но такая схема неудобна для многоточечного обмена.

    Шифры бывают поточными и блочными. В первом случае обработка исходного текста производится побитно или побайтно. Во втором - текст перед обработкой разбивается на блоки.

    Асимметричные схемы шифрования/дешифрования предполагают существования независимых ключей для шифрования и дешифрования. Причем один не может быть получен из другого и наоборот. В идеале ключ дешифровки не может быть получен из шифрующего ключа за любое разумное время. В этом случае ключ шифрования может быть сделан общедоступным (например, алгоритм RSA). Партнеры до начала коммуникаций должны послать друг другу ключи шифрования КШО и КШП (ключи шифрования отправителя и получателя). Возможность перехвата таких ключей опасности не представляет. Дешифрование выполняется с помощью ключей КДО и КДП, которые образуют пары с КШО и КШП соответственно и формируются совместно. Ключи КШО и КШП обычно пересылаются на фазе инициализации сессии информационного обмена.

    Шифрование может осуществляться по определенным правилам с помощью таблиц шифрования или ключей. При этом могут использоваться самые разные алгоритмы, в том числе, например, перемещение символов текста определенным образом. За свою историю люди придумали достаточно большое число способов шифрования. Новейшие из них базируются на методиках, заимствованных из теории чисел. По этой причине, прежде чем переходить к следующему разделу, введем некоторые определения.

    Конгруентность. a конгруентно b по модулю n (a nb), если при делении на n a и b, получается идентичный остаток. Так 100 11 34 (100 и 34 при делении на 11 дают остаток 1) и -6 810 (ведь -6 =8(-1)+2). Мы всегда имеем a nb для некоторого 0 ё bё n-1. Если a nb и с d, то справедливы равенства:

    a +c n(b + d) и ac nbd

    Аналогичная процедура для деления не всегда справедлива: 6 1218 но 3N 9. Приведенные здесь и далее математические определения и обоснования взяты из: http://lglwww.epfl.ch/~jkienzle/digital/node20.html.

    Необходимо также вспомнить о знакомом всем со школьной скамьи понятии наибольшего общего делителя. Для a и b число (a,b) является наибольшим общим делителем, который делит a и b без остатка:

    (56,98)=14; (76,190)=38

    Теорема 1. Для любых a,b существуют целые числа x,y, для которых ax+by=(a,b). В данной статье не приводится доказательств представленных утверждений, их следует искать в книгах по дискретной математике.

    В этом можно убедиться, решая уравнение 30x+69y=3 путем последовательных упрощающих подстановок (ищется целочисленное решение:

    30x+69y=3

    30x'+9y=3

    [x'=x+2y]

    3x'+9y'=3

    [y'=y+3x']

    3x"+0y'=3

    [x"=x'+3y']

    Легко видеть, что x"=1, y'=0 является решением окончательного уравнения. Мы можем получить решение исходного уравнения путем обратной подстановки.

    x'=x"-3y'=1 y=y'-3x'=-3 x=x'-1y=7

    Мы можем решить уравнение вида 30x+69y=15 путем умножения нашего решения: y=-15, x=35. Должно быть ясно, что уравнение не будет иметь целочисленного решения, если 15 заменить на что-то некратное (30,69)=3.

    Все другие целочисленные решения 30x+69y=15 могут быть получены, варьируя первое решение:

    y=-15+(30/3)t x=35 -(69/3)t для целого t

    Если мы проделаем то же для произвольного равенства ax+by=(a,b), мы возможно получим один из коэффициентов равным нулю, а другой - (a,b). В действительности эта процедура представляет собой алгоритм Евклида для нахождения наибольшего общего делителя.

    Важно то, что этот процесс реализуем на ЭВМ даже в случае, когда a и b имеют несколько сотен значащих цифр. Легко показать, что 600-значное число не потребует более чем 4000 уравнений. Теорема 1 справедлива и для простых чисел.

    Следствие 1.

    Если p является простым числом, ar pas и a N 0, тогда r s.

    Следствие 2.

    Если p простое число и a N 0 mod p, тогда для любого b существует y, для которого ay pb.

    Следствие 3.

    ("Теорема о китайском остатке"). Если (p,q)=1, тогда для любого a,b существует n, для которого n pa и n qb.

    Во многих криптографических приложениях используется:

    a a2 a3 . mod p, где a и p целые числа.

    Оказывается, можно выполнить такие вычисления даже для случая, когда в указанную процедуру вовлечены достаточно большие числа, например:

    432678 mod 987.

    Фокус заключается в том, что берется число и осуществляется возведение в квадрат.

    4322 = 186624; 186624 mod 987 = 81; 4324 mod 987 = 812 mod 987 = 639
    4328 -> 6392 mod 987 -> 690 .. 432512 -> 858
    так как 678= 512+128+32+4+2, то:
    432678->(81)(639)..(858) -> 204

    Вычисления с использованием показателя включают в себя ограниченное число умножений. Если числа содержат несколько сотен цифр, необходимы специальные подпрограммы для выполнения таких вычислений. Рассмотрим последовательность степеней 2n mod 11:

    2 4 8 5 10 9 7 3 6 1

    Здесь числа от 1 до 10 появляются в виде псевдослучайной последовательности.

    Теорема 2

    Пусть p является простым числом. Существует такое a, что для каждого 1ё b ё p-1, существует такое 1ё x ё p-1, что ax pb, a не обязательно равно 2.

    Степени 2 mod 7 равны 2, 4, 1. Далее числа повторяются, а числа 3, 5, или 6 не могут быть получены никогда. Рассмотрим некоторые следствия этой теоремы.

    Следствие 4. Пусть a соответствует требованиям теоремы 2, тогда ap-1 p1.
    Следствие 5.
    Для любого b N 0, bp-1 p1.
    Следствие 6
    . Если x (p-1)y, тогда bx pby

    Лемма
    Пусть b N 0, d наименьшее положительное число, такое что bd p1. Тогда для любого с>0 c bc p1 d делит c без остатка. В частности для следствия 5, d делит p-1 без остатка.

    Согласно теореме 2, если p простое число, существует такое a, при котором равенство ax pb имеет решение для любого bN 0. Такое значение a называется примитивным корнем p, а x называется дискретным логарифмом b. Получение b при заданных a и x относительно просто, определение же x по a и b заметно сложнее. Многие современные системы шифрования основываются на факте, что никаких эффективных путей вычисления дискретных логарифмов не найдено. Никакого эффективного метода определения примитивных корней также неизвестно. Однако часто возможно найти примитивные корни в некоторых специальных случаях. Возьмем p=1223. p-1=2*13*47. Согласно лемме, если a не примитивный корень, тогда мы либо имеем a26 , a94 или
    a611 12231. a=2 и a=3 не годятся, но a=5 соответствует всем трем условиям, таким образом, это значение является примитивным корнем. Мы могли бы сказать, что a=4 не может быть признано примитивным корнем без проверки.

    Легко показать, что если a примитивный корень, ax примитивный корень в том и только том случае, если (x,p-1)=1. В этом примере это означает, что число примитивных корней равно

    1222*(1/2)*(12/13)*(46/47)=552

    Таким образом, если мы выберем а произвольно, вероятность того, что это будет примитивный корень равна ~.45. Выбирая а наугад и тестируя, можно сравнительно быстро найти примитивный корень.

    Наиболее современные системы шифрования используют асимметричные алгоритмы с открытым и секретным ключами, где нет проблемы безопасной транспортировки ключа. К числу таких систем относится алгоритм rsa (rivest-shamir-adleman - разработчики этой системы - Рональд Ривест, Ади Шамир и Леонард Адлеман, 1977 год), базирующийся на разложение больших чисел на множители.

    Другие сходные алгоритмы используют целочисленные логарифмы и вычисление корней уравнений. В отличие от других систем эти позволяют кроме шифрования эффективно идентифицировать отправителя (электронная подпись). К системам с открытым ключом предъявляются следующие требования:

    • Зашифрованный текст трудно (практически невозможно) расшифровать с использованием открытого ключа.
    • Восстановление закрытого ключа на основе известного открытого должно быть нереализуемой задачей на современных ЭВМ. При этом должна существовать объективная оценка нижнего предела числа операций, необходимых для решения такой задачи.

    К сожалению, эти алгоритмы достаточно медленно работают. По этой причине они могут использоваться для транспортировки секретных ключей при одном из традиционных методов шифрования-дешифрования.

    Но следует помнить, что не существует абсолютных мер защиты. На рис.6.4.1. показан способ нарушения конфиденциальности в системах с двухключевой схемой шифрования.

    Рис. 6.4.1.

    Если хакер умудрится вставить свою ЭВМ в разрыв канала, соединяющего субъектов А и В, у него появляется возможность перехватывать в том числе и шифрованные сообщения. Пусть субъект А сформировал пару ключей К и К (ключ с индексом 2 является секретным), аналогичную пару ключей сгенерировал субъект В (К и К ). Хакер же тем временем подготовил две пары ключей (К1ХА2ХА и К1ХВ2ХВ ). Когда субъект А пошлет открытый ключ К субъекту В, хакер его подменит ключом К1ХА . Аналогичную процедуру он проделает с ключом К, посланным от В к А. Теперь сообщение А к В, зашифрованное с помощью ключа К1ХА будет послано В. Хакер его перехватывает, дешифрует с помощью ключа К2ХА, шифрует с помощью ключа К1ХВ и посылает В. Субъект В, получив послание, дешифрует его с помощью "секретного" ключа К2ХВ, полученного от хакера (о чем он, естественно, не подозревает). Аналогичная процедура будет проведена и при посылки сообщения от В к А. В сущности единственным параметром который изменится существенным образом будет время доставки сообщения, так как это время будет включать дешифровку и повторную шифровку сообщения. Но при использовании быстродействующей ЭВМ и при работе с традиционной электронной почтой это может оказаться незаметным. Понятно, что между А и В появится дополнительный шаг (hop). Но и это может быть легко замаскировано под прокси сервер или Firewall.

    Решить эту проблему можно путем пересылки открытого ключа своему партнеру по какому-то альтернативному каналу или сверки его по телефону.

    Полезную информацию по системам шифрования можно получить на следующих серверах:

    www.cs.hut.fi/crypto/
    www.subject.com/crypto/crypto.html
    www.rsa.com/
    www.netscape.com/newsref/ref/rsa.html
    www.microsoft.com/workshop/prog/security/pkcb/crypt.htm
    www.semper.org/sirene/people/gerrit/secprod.html
    www.fri.com/~rcv/deschall.htm
    www.cl.cam.ac.uk/brute/

    Previous: 6.3.1 Список видов атак, зарегистрированных Network ICE    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.1 Алгоритм DES


    previous up down next index index
    Previous: 6.4 Системы шифрования    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.2 Алгоритм шифрования RSA

    6.4.1 Алгоритм DES
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Стандарт шифрования DES (Data Encryption Standard) был разработан в 1970-х годах, он базируется на алгоритме DEA.

    Исходные идеи алгоритма шифрования данных DEA (data encryption algorithm) были предложены компанией IBM еще в 1960-х годах и базировались на идеях, описанных Клодом Шенноном в 1940-х годах. Первоначально эта методика шифрования называлась lucifer (разработчик Хорст Фейштель, название dea (см. http/:snoopy.falkor.gen.nz/~rae/des.html) она получила лишь в 1976 году. Lucifer был первым блочным алгоритмом шифрования, он использовал блоки размером 128 бит и 128-битовый ключ. По существу этот алгоритм являлся прототипом DEA. В 1986 в Японии (NIT) разработан алгоритм FEAL(Fast data Encipherment ALgorithm), предназначенный для использования в факсах, модемах и телефонах (длина ключа до 128 бит). Существует и ряд других разработок.

    DEA (ANSI x3.92-1981; www.cryptosoft.com/html/fips46-2.htm) оперирует с блоками данных размером 64 бита и использует ключ длиной 56 бит. Такая длина ключа соответствует 1017 комбинаций, что обеспечивало до недавнего времени достаточный уровень безопасности. В дальнейшем можно ожидать расширения ключа до 64 бит (например, LOKI) или вообще замены DES другим стандартом.

    Входной блок данных, состоящий из 64 бит, преобразуется в выходной блок идентичной длины. Ключ шифрования должен быть известен, как отправляющей так и принимающей сторонам. В алгоритме широко используются перестановки битов текста.

    Вводится функция f, которая работает с 32-разрядными словами исходного текста (А) и использует в качестве параметра 48-разрядный ключ (J). Схеме работы функции f показана на рис. 6.4.1.1. Сначала 32 входные разряда расширяются до 48, при этом некоторые разряды повторяются. Схема этого расширения показана ниже (номера соответствуют номерам бит исходного 32-разрядного кода).

    32 1 2 3 4 5
    4 5 6 7 8 9
    8 9 10 11 12 13
    12 13 14 15 16 17
    16 17 18 19 20 21
    20 21 22 23 24 25
    24 25 26 27 28 29
    28 29 30 31 32 1

    Для полученного 48-разрядного кода и ключа выполняется операция исключающее ИЛИ (XOR). Результирующий 48-разрядный код преобразуется в 32-разрядный с помощью S-матриц. На выходе S-матриц осуществляется перестановка согласно схеме показанной ниже (числа представляют собой порядковые номера бит).

    16 7 20 21
    29 12 28 17
    1 15 23 26
    5 18 31 10
    2 8 24 14
    32 27 3 9
    19 13 30 6
    22 11 4 25

    Рис. 6.4.1.1. Алгоритм работы функции f

    Преобразование начинается с перестановки бит (IP - Initial Permutation) в 64-разрядном блоке исходных данных. 58-ой бит становится первым, 50-ый - вторым и т.д. Схема перестановки битов показана ниже.

    58 50 42 34 26 18 10 2
    60 52 44 36 28 20 12 4
    62 54 46 38 30 22 14 6
    64 56 48 40 32 24 16 8
    57 49 41 33 25 17 9 1
    59 51 43 35 27 19 11 3
    61 53 45 37 29 21 13 5
    63 55 47 39 31 23 15 7

    Полученный блок делится на две 32-разрядные части L0 и R0. Далее 16 раз повторяются следующие 4 процедуры:

    • Преобразование ключа с учетом номера итерации i (перестановки разрядов с удалением 8 бит, в результате получается 48-разрядный ключ)

    Пусть A=Li, а J - преобразованный ключ. С помощью функции f(A,J) генерируется 32-разрядный выходной код.
    Выполняется операция XOR для Ri f(A,J), результат обозначается Ri+1.
    Выполняется операция присвоения Li+1=Ri.

    Структурная схема реализации алгоритма dea показана на рис. 6.4.1.2.

    Рис. 6.4.1.2. Структурная схема реализации алгоритма DEA

    Инверсная перестановка разрядов предполагает следующее размещение 64 бит зашифрованных данных (первым битом становится 40-ой, вторым 8-ой и т.д.).

    40 8 48 16 56 24 64 32
    39 7 47 15 55 23 63 31
    38 6 46 14 54 22 62 30
    37 5 45 13 53 21 61 29
    36 4 44 12 52 20 60 28
    35 3 43 11 51 19 59 27
    34 2 42 10 50 18 58 26
    33 1 41 9 49 17 57 25

    S-матрицы представляют собой таблицы содержащие 4-ряда и 16 столбцов. Матрица S(1) представлена ниже (эта матрица, также как и те, что приведены в ссылке 2, являются рекомендуемыми).

    No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
    0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
    1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
    2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
    3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13

    Исходный 48-разрядный код делится на 8 групп по 6 разрядов. Первый и последний разряд в группе используется в качестве адреса строки, а средние 4 разряда - в качестве адреса столбца. В результате каждые 6 бит кода преобразуются в 4 бита, а весь 48-разрядный код в 32-разрядный (для этого нужно 8 S-матриц). Существуют разработки, позволяющие выполнять шифрование в рамках стандарта DES аппаратным образом, что обеспечивает довольно высокое быстродействие.

    Преобразования ключей Kn (n=1,.,16; Kn = KS(n,key), где n - номер итерации) осуществляются согласно алгоритму, показанному на рис. 6.4.1.3.

    Рис. 6.4.1.3. Алгоритм вычисления последовательности ключей Kn

    Для описания алгоритма вычисления ключей Kn (функция KS) достаточно определить структуру "Выбора 1" и "Выбора 2", а также задать схему сдвигов влево (табл. 6.4.1.2). "Выбора 1" и "Выбора 2" представляют собой перестановки битов ключа (PC-1 и PC-2; табл. 6.4.1.1). При необходимости биты 8, 16,., 64 могут использоваться для контроля четности.

    Для вычисления очередного значения ключа таблица делится на две части С0 и D0. В С0 войдут биты 57, 49, 41,., 44 и 36, а в D0 - 63, 55, 47,., 12 и 4. Так как схема сдвигов задана (табл. 6.4.1.2) C1,D1; Cn, Dn и так далее могут быть легко получены из C0 и D0. Так, например, C3 и D3 получаются из C2 и D2 циклическим сдвигом влево на 2 разряда

    Таблица 6.4.1.1

    PC-1 (Выбор 1)

    PC-2 (Выбор 2)

    57 49 41 33 25 17 9

    14 17 11 24 1 5

    1 58 50 42 34 26 18

    3 28 15 6 21 10

    10 2 59 51 43 35 27

    23 19 12 4 26 8

    19 11 3 60 52 44 36

    16 7 27 20 13 2

    63 55 47 39 31 23 15

    41 52 31 37 47 55

    7 62 54 46 38 30 22

    30 40 51 45 33 48

    14 6 61 53 45 37 29

    44 49 39 56 34 53

    21 13 5 28 20 12 4

    46 42 50 36 29 32

    Таблица 6.4.1.2

    Номер итерации

    Число сдвигов влево

    1

    1

    2

    1

    3

    2

    4

    2

    5

    2

    6

    2

    7

    2

    8

    2

    9

    1

    10

    2

    11

    2

    12

    2

    13

    2

    14

    2

    15

    2

    16

    1

    Previous: 6.4 Системы шифрования    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.2 Алгоритм шифрования RSA


    previous up down next index index
    Previous: 6.4.1 Алгоритм DES    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.3 Электронная подпись

    6.4.2 Алгоритм шифрования RSA
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Алгоритм RSA предполагает, что посланное закодированное сообщение может быть прочитано адресатом и только им. В этом алгоритме используется два ключа - открытый и секретный. Данный алгоритм привлекателен также в случае, когда большое число субъектов (N) должно общаться по схеме все-со-всеми. В случае симметричной схемы шифрования каждый из субъектов каким-то образом должен доставить свои ключи всем остальным участникам обмена, при этом суммарное число используемых ключей будет достаточно велико при большом значении N. Применение асимметричного алгоритма требует лишь рассылки открытых ключей всеми участниками, суммарное число ключей равно N.

    Сообщение представляется в виде числа M. Шифрование осуществляется с помощью общедоступной функции f(M), и только адресату известно, как выполнить операцию f-1 . Адресат выбирает два больших простых (prime) числа p и q, которые делает секретными. Он объявляет n=pq и число d, c (d,p-1)=(d,q-1)=1 (один из возможных способов выполнить это условие, выбрать d больше чем p/2 и q/2). Шифрование производится по формуле:

    f(M) Md mod n,

    где M и f(M) оба ё n-1. Как было показано, может быть вычислено за разумное время, даже если M, d и n содержит весьма большое число знаков. Адресат вычисляет M на основе Md , используя свое знание p и q. В соответствие со следствием 6, если
    dc (p-1)1, тогда (Md)e p1.

    Исходный текст M получается адресатом из зашифрованного F(M) путем преобразования: M = (F(M))e (mod pq). Здесь как исходный текст, так и зашифрованный рассматриваются как длинные двоичные числа.

    Аналогично (Md)e qM, если dc (q-1)1. e удовлетворяет этим двум условиям, если cd (p-1) (q-1)1. Теорема 1 гласит, что мы можем позволить e=x, когда x является решением уравнения dx + (p-1)(q-1)y = 1.

    Так как (Md)e - M делимо на p и q, оно делимо и на pq, следовательно, мы можем определить M, зная Md , вычислив его значение в степени e и определив остаток от деления на pq. Для соблюдения секретности важно, чтобы, зная n, было нельзя вычислить p и q. Если n содержит 100 цифр, подбор шифра связан с перебором ~1050 комбинаций. Данная проблема изучается уже около 100 лет. RSA-алгоритм запатентован (20 сентября 1983, действует до 2000 года).

    Теоретически можно предположить, что возможно выполнение операции f-1 , не вычисляя p и q. Но в любом случае задача эта не проста и разработчики считают ее трудно факторизуемой.

    Предположим, что мы имеем зашифрованный текст f(M) и исходный текст M, и мы хотим найти значения p и q. Нетрудно показать, что таких исходных данных для решения задачи недостаточно - надо знать все возможные значения Mi.

    Проясним использование алгоритма RSA на конкретном примере. Выбираем два простые числа p=7; q=17 (на практике эти числа во много раз длиннее). В этом случае n = p*q будет равно 119. Теперь необходимо выбрать e, выбираем e=5. Следующий шаг связан с формированием числа d так, чтобы d*e=1 mod [(p-1)(q-1)]. d=77 (использован расширенный алгоритм Эвклида). d - секретный ключ, а e и n характеризуют открытый ключ. Пусть текст, который нам нужно зашифровать представляется M=19. С = Memod n. Получаем зашифрованный текст C=66. Этот "текст" может быть послан соответствующему адресату. Получатель дешифрует полученное сообщение, используя М= Cdmod n и C=66. В результате получается M=19.

    На практике общедоступные ключи могут помещаться в специальную базу данных. При необходимости послать партнеру зашифрованное сообщение можно сделать сначала запрос его открытого ключа. Получив его, можно запустить программу шифрации, а результат ее работы послать адресату. На использовании общедоступных ключей базируется и так называемая электронная подпись, которая позволяет однозначно идентифицировать отправителя. Сходные средства могут применяться для предотвращения внесения каких-либо корректив в сообщение на пути от отправителя к получателю. Быстродействующие аппаратные 512-битовые модули могут обеспечить скорость шифрования на уровне 64 кбит в сек. Готовятся ИС, способные выполнять такие операции со скоростью 1 Мбайт/сек. Разумный выбор параметра e позволяет заметно ускорить реализацию алгоритма.

    Previous: 6.4.1 Алгоритм DES    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.3 Электронная подпись


    previous up down next index index
    Previous: 6.4.2 Алгоритм шифрования RSA    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.4 Безопасная почта PGP

    6.4.3 Электронная подпись
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В конце любого письма мы привыкли ставить подпись с тем, чтобы уведомить получателя о том, кто является отправителем данного документа. Кроме того, подпись ответственного лица придает документу юридическую силу. По мере внедрения электронных средств доставки документов (факс и электронная почта) проблема их достоверности обрела крайнюю актуальность. Ведь копирование любой последовательности битов или пикселей не представляет никакой трудности. Современные телекоммуникационные каналы уязвимы для перехвата и искажения пересылаемых документов.

    Рассмотрим сначала то, от каких действий злоумышленника должна защищать система идентификации.

    • Отказ от выполненных действий. Субъект утверждает, что он не посылал некоторый документ, хотя на самом деле он его послал.
    • Модификация документа. Получатель модифицирует полученный документ и утверждает, что именно такую версию документа он и получил.
    • Подделка. Субъект фабрикует сообщение и утверждает, что оно ему прислано.
    • Перехват. Злоумышленник С перехватывает сообщение, посланное А к В с целью модификации.
    • Маскировка. Посылка сообщения от чужого имени.
    • Повтор. Злоумышленник С посылает повторно сообщение от А к Б, перехваченное им ранее.

    Решение практически всех этих проблем может быть реализовано с помощью электронной подписи, базирующейся на алгоритме RSA. Рассмотрим принципы, на которых базируется электронная подпись.

    Пусть имеются секретные коды d, p и q, а также открытые e и n=pq. Пусть также А передает сообщение DATA адресату Б. Электронная подпись отправителя А базируется на его секретном ключе и открытом ключе получателя Б. Сначала отправитель с помощью хэш-функции (SHS - Secure Hash Standard; www.nist.gov/itl/div897/pubs/fip180-1.htp) генерирует дайджест своего сообщения длиной 160 бит (5 слов). Затем с помощью своего секретного ключа он формирует электронную подпись. При этом А не может отказаться от того, что именно он послал сообщение, так как только он знает свой секретный ключ. Электронную подпись нельзя использовать повторно и подписанный документ нельзя модифицировать, так как любые модификации неизбежно изменят его дайджест, а, следовательно, и электронную подпись. Получатель с помощью открытого ключа дешифрует код электронной подписи, а затем с использованием дайджеста проверяет ее корректность.

    Национальный институт стандартов США принял стандарт DSS (Digital Signature Standard; www.itl.nist.gov/div897/pubs/fip198.htm), в основу которого легли алгоритмы Эль-Гамаля и RSA.

    Рассмотрим алгоритмы вычисления дайджеста сообщения, электронной подписи и идентификации отправителя. Начнем с алгоритма SHA (Secure Hash Algorithm).

    Сначала сообщение разбивается на блоки длиной 512 бит. Если длина сообщения не кратна 512, к последнему блоку приписывается справа 1, после чего он дополняется нулями до 512 бит. В конец последнего блока записывается код длины сообщения. В результате сообщение приобретает вид n 16-разрядных двоичных слов M1,M2,.,Mn. M1 содержит первый символ.

    Алгоритм SHA использует 80 логических функций f0,f1,.,f79, которые производят операции над тремя 32-разрядными словами (B,C,D):

    ft(B,C,D) = (B AND C) OR ((NOT B) AND D)

    для 0 ёtё 19

    ft(B,C,D) = B XOR C XOR D

    для 20 ё t ё 39

    ft(B,C,D) = (B AND C) OR (B AND D) OR (C AND D)

    для 40 ё t ё 59

    ft(B,C,D) = B XOR C XOR D

    для 60 ё t ё 79

    В алгоритме используется также 80 констант K1,K2,., K79:

    Kt = 5A827999

    для 0 ё t ё 19

    Kt = 6ED9EBA1

    для 20 ё t ё 39

    Kt = 8F1BBCDC

    для 40 ё t ё 59

    Kt = CA62C1D6

    для 60 ё t ё 79

    Вводится 5 переменных Hi инициализируемых как:

    H0 = 67452301
    H1 = EFCDAB89
    H2 = 98BADCFE
    H3 = 10325476
    H4 = C3D2E1F0

    Делим массив M на группы из 16 слов W0, W1,.,W15 (W0 самое левое слово).

    Для t = 16 - 79 wt = S1(Wt-3 XOR Wt-8 XOR Wt-14 XOR Wt-16)

    Ak означает операцию циклического сдвига влево на k разрядов.

    Пусть теперь A = H0, B = H1, C = H2, D = H3, E = H4.
    for t = 0 to 79 do
    TEMP = S5(A) + ft(B,C,D) + E + Wt + Kt. (TEMP - временная переменная).
    E = D; D = C; C = S30(B); B = A; A = TEMP;
    Пусть H0 = H0 + A; H1 = H1 + B; H2 = H2 + C; H3 = H3 + D; H4 = H4 + E.

    В результате обработки массива М будет получено 5 слов H0, H1, H2, H3, H4 с общей длиной 160 бит, которые и образуют дайджест сообщения. Полученная кодовая последовательность с высокой степенью уникальности характеризует сообщение. Любое редактирование сообщения практически неизбежно приведет к изменению дайджеста. Поскольку алгоритм вычисления дайджеста общеизвестен, он не может рассматриваться как гарантия предотвращения модификации сообщения. Смысл вычисления дайджеста заключается в уменьшении объема данных, подлежащих шифрованию. Для того чтобы превратить дайджест в электронную подпись надо воспользоваться секретным ключом. Схема реализации алгоритма DSA (Digital Signature Standard) показана на рис. 6.4.3.1.

    Рис. 6.4.3.1. Схема вычисления и верификации электронной подписи (DSA)

    DSA использует следующие параметры (www.itl.nist.gov/div897/pubs/fip186.htm):

    p - простое число, которое при 512ё L ё 1024 удовлетворяет условию 2L-1 < p < 2L, L кратно 64.
    q - простой делитель p-1, где 2159 < q < 2160 .
    g = h(p-1)/q mod p, где h любое целое, для которого 1 < h < p-1 и h(p-1)/q mod p > 1.
    x равно случайному или псевдослучайному целому числу, для которого 0 < x < q.
    y = gx mod p.

    k равно случайному или псевдослучайному целому числу, для которого 0 < k < q.

    Целые p, q и g могут быть общедоступными и использоваться группой пользователей. Секретным и открытым ключами являются х и у, соответственно. Параметры х и k используются только для формирования электронной цифровой подписи и должны храниться в секрете. Параметр k генерируется для каждой подписи.

    Подпись сообщения M представляет собой два числа r и s, вычисленные согласно формулам:

    r = (gk mod p) mod q
    s = (k-1(SHA(M) + xr)) mod q
    . (здесь k-1 величина обратная k).

    SHA(M) - представляет собой дайджест сообщения M (160-битовая строка). После вычисления r и s следует проверить, не равно ли одно из них нулю.

    Для верификации электронной подписи проверяющая сторона должна иметь параметры p, q и g, а также открытый ключ отправителя (подписанта) y.

    Пусть M`, r` и s` представляют собой полученное сообщение и электронную подпись. Получатель начинает верификацию с проверки условия 0 < r` < q и 0 < s` < q. Если хотя бы одно из условий не выполнено, электронная подпись некорректна. Далее производится вычисление:

    w = (s`)-1 mod q
    u1 = ((SHA(M`)w) mod q
    u2 = ((r`)w) mod q
    v = (((g)u1 (y)u2) mod p) mod q.

    Если v = r`, верификация подписи завершилась успешно и получатель может с высокой вероятностью быть уверен, что он получил сообщение от партнера, владеющего секретным ключом х, соответствующим открытому ключу у. Если же v не равно r`, то сообщение было модифицировано или подписано самозванцем. В ссылке 3 на предыдущей странице можно найти описание алгоритма нахождения (проверки) простых чисел и генерации псевдослучайных чисел.

    Previous: 6.4.2 Алгоритм шифрования RSA    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.4 Безопасная почта PGP


    previous up down next index index
    Previous: 6.4.3 Электронная подпись    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.5 Алгоритм Эль Гамаля

    6.4.4 Безопасная почта PGP
    Семенов Ю.А. (ГНЦ ИТЭФ)

    В связи с массовым внедрением электронной почты и, в перспективе, полным вытеснением традиционной, проблема конфиденциальности доставки электронных сообщений становится крайне актуальной. В последние годы разработано несколько почтовых систем, предоставляющих эту конфиденциальность. Примером такой системы может служить PEM - почта с улучшенной защитой от несанкционированного доступа (PEM - Privacy Enhanced Mail, RFC-1421, 1422, 1423 и 1424). Первая разработка в области электронной криптографии относится к 1976 году, когда была создана система Диффи-Хелмана (Diffie-Hellman) с общедоступным шифровальным ключом. Позднее, в 1977 году Ривестом, Шамиром и Адлеманом была предложена двух ключевая система RSA (Rivest-Shamir-Adleman). Эта разработка была выполнена под патронажем Национального научного фонда США (NSF) и в 1983 году запатентована в США.

    PEM является стандартом Интернет для улучшения защищенности электронной почты. PEM использует криптографическую технику для обеспечения контроля правильности передачи сообщения, защищенности и идентификации. Стандарт позволяет вам знать, что полученное сообщение не было изменено, быть уверенным, что ваше сообщение будет получено именно тем и только тем, кому было адресовано.

    Предусмотрена интеграция MIME (Multipurpose Internet Mail Extensions) и PEM. Существует подписной лист (LISTSERV) для пользователей, интересующихся вопросами развития и использования PEM. Для подписки необходимо послать соответствующее сообщение по адресу pem-dev-request@tis.com.

    Для пользователей PEM имеется еще один подписной лист: tispem-users@tis.com. Для подписки следует направлять заявки по адресу: tispem-users-request@tis.com. С вопросами по использованию TIS/PEM следует обращаться в tispem-support@tis.com.

    Имеется версия программного обеспечения PEM в свободном доступе, например, TIS/PEM V7.0 (UNIX, только для США и Канады). Эта версия содержит в себе:

    • поддержку однопользовательского режима с возможностью совместного использования некоторых процедурных модулей;
    • легко читаемую базу данных для каждого пользователя;
    • поддержку для большего числа баз данных;
    • гибкую систему управления доступом;
    • гибкую систему поверки;
    • системы верификации, кодирования, декодирования и электронной подписи, совместимые с другими почтовыми серверами;
    • поддержку интеграции MIME-PEM.

    Система TIS/PEM доступна через анонимное FTP в США и Канаде по адресу: ftp.tis.com pub/PEM/README; pub/PEM/LICENSE; pub/PEM/BUGS. Файл README содержит дополнительные инструкции по применению PEM.

    Несравненно большей популярностью пользуется конфиденциальная почтовая система PGP (Pretty Good Privacy - замечательная конфиденциальность). История создания PGP довольно драматична (см. http://www.dcs.ex.ac.uk/~aba/timeline/. Создателем PGP является Фил Циммерман (США, 1991 год). PGP базируется на двух ключевой системе шифрования RSA и алгоритме IDEA (International Data Encryption Algorithm, предложен Ксейа Лайем и Джеймсом Массейем, Швейцария). Творение Циммермана было встречено без энтузиазма Агентством Национальной Безопасности США и против него было возбуждено уголовное дело. Хотя АНБ и могущественно, здравый смысл и закон в данном случае восторжествовали. Что же касается патента на RSA, он не является международным и вся ответственность за использование программ, базирующихся на данном алгоритме, лежит на пользователе (юридически ситуация весьма запутана). В России применение любой системы шифрования (формально даже архивирование!) требует лицензирования. Все правительства любят все держать в тайне, но не любят, когда кто-то пытается хранить в тайне что-то от правительства (даже если это любовные письма; если вы интересуетесь юридической стороной проблемы использования PGP, смотрите в http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Чему здесь удивляться, ведь история "черных кабинетов" (в том числе и в России) исчисляется столетиями.

    PGP версия 2.5 (http://www.ifi.uio.no/~staalesc/PGP ) (и более поздние используют RSAREF 1.0 вместо MPILIB) представляет собой публично доступный (легальный!) пакет электронной почты со встроенной системой шифрования сообщений. Пакет обеспечивает конфиденциальность переписки и пересылки файлов. Конфиденциальность заключается в том, что только лица, кому адресовано послание или файл, смогут его прочесть. PGP поддерживает технологию электронной подписи, гарантирующей получателю, что сообщение пришло именно от вас. Предусмотрен контроль неизменности сообщения в процессе доставки (принцип сходен с идеей CRC). При этом не требуется каких-либо секретных каналов для пересылки ключей кодирования. Именно эта схема являлась до недавнего времени основной. Главный ее недостаток - необходимость транспортировки секретного ключа. PGP использует технику шифрования с общедоступными ключами, совмещая удобства системы кодирования RSA с быстродействием традиционных методов. Существуют коммерческие версии PGP, встроенные в известные текстовые редакторы WORD и другие. В PGP предусмотрена схема, резко ускоряющая дешифровку. Возможно применение большого набора пар общедоступных и секретных ключей. Имеется система авторизации, контролирующая доступ к ключам и препятствующая использованию краденных секретных ключей. Предусмотрены и другие методы повышения секретности пересылки любых сообщений.

    Пакет работает под MS-DOS, UNIX, Windows. Данная версия позволяет посылать сообщение сразу нескольким адресатам. Пакет имеет встроенную справочную систему (Help на английском, французском и испанском языках. Описания, инструкции по постановке и использованию можно найти по адресу: FTP ftp.uu.net/pub/security/pgp.

    Previous: 6.4.3 Электронная подпись    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.5 Алгоритм Эль Гамаля


    previous up down next index index
    Previous: 6.4.5 Алгоритм Эль Гамаля    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.7 IDEA - международный алгоритм шифрования данных

    6.4.6 Алгоритм Диффи-Хелмана
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля.

    Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение

    A = qx mod n

    По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение

    B = qy mod n

    Партнер P1, получив В, вычисляет Kx = Bx mod n, а партнер P2 вычисляет Ky = Ay mod n. Алгоритм гарантирует, что числа Ky и Kx равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить Kx или Ky .

    Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать того, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".)

    Previous: 6.4.5 Алгоритм Эль Гамаля    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.7 IDEA - международный алгоритм шифрования данных


    previous up down next index index
    Previous: 6.4.6 Алгоритм Диффи-Хелмана    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.8 Алгоритм шифрования SAFER

    6.4.7 IDEA - международный алгоритм шифрования данных
    Семенов Ю.А. (ГНЦ ИТЭФ)

    IDEA является блочным алгоритмом шифрования данных, запатентованным швейцарской фирмой Ascom (http://fn2.freenet.edmonton.ab.ca/~jsavard/co0404.html). Фирма, правда, разрешила бесплатное некоммерческое использование своего алгоритма (применяется в общедоступном пакете конфиденциальной версии электронной почты PGP). Здесь в отличие от алгоритма DES не используются S-блоки или таблицы просмотра. В IDEA применяются 52 субключа, каждый длиной 16 бит. Исходный текст в IDEA делится на четыре группы по 16 бит. Для того чтобы комбинировать 16 битные коды, используется три операции: сложение, умножение и исключающее ИЛИ. Сложение представляет собой обычную операцию по модулю 65536 с переносом. При составлении таблицы умножения принимаются специальные меры для того, чтобы операция была обратимой. По этой причине вместо нуля используется код 65536. Рассмотрим алгоритм IDEA.

    Пусть четыре четверти исходного текста имеют имена A, B, C и D, а 52 субключа - К(1), К(2),., К(52). Перед реализацией алгоритма выполняются операции:

    А = А*К(1); B = B + K(2); C = C + K(3); D = D * K(4);

    Первый цикл вычислений включает в себя:

    E = A XOR C; F = B XOR D
    E = E * K(5)
    F = F + E
    F = F * K(6)
    E = E + F
    A = A XOR F
    C = C XOR F
    B = B XOR E
    D = D XOR E

    Меняем местами В и С.

    Повторяем это всё 8 раз, используя К(7) - К(12) для второго раза и, соответственно, К(43) - К(48) - для восьмого. После восьмого раза В и С местами не меняются. Выполняем после этого операции:

    A = A * K(49)
    B = B + K(50)
    C = C + K(51)
    D = D * K(52)

    В результате закодированный текст имеет ту же длину, что и исходный. Схема этого весьма запутанного алгоритма может быть пояснена на рис. 6.4.7.1. По своему характеру алгоритм напоминает процедуры вычисления хэш-функции.

    Рис. 6.4.7.1. Схема реализации алгоритма шифрования IDEA

    При дешифровке используется тот факт, что A XOR B не изменяется, если C A и B будет произведена операция XOR C использованием любого числа. Это утверждение справедливо для любых значений А и В. Операции сложения (слагаемые заменяются их дополнением по модулю 2) и умножения (множители заменяются из обратными величинами по модулю 65537) также допускают инверсию. Первые четыре ключа дешифровки (KD) определяются несколько иначе, чем остальные.

    KD(1) = 1/K(49);
    KD(2) = -K(50);
    KD(3) = -K(51);
    KD(4) = 1/K(52);

    Последующие операции производятся восемь раз с добавлением 6 к индексу ключей дешифрования и вычитанием 6 из индекса ключей шифрования.

    KD(5) = K(47)
    KD(6) = K(48)
    KD(7) = 1/K(43)
    KD(8) = -K(45)
    KD(9) = -K(44)
    KD(10) = 1/K(46)

    Субключи IDEA генерируются следующим образом. 128-битовый ключ IDEA определяет первые восемь субключей (128=8*16). Последующие ключи (44) получаются путем последовательности циклических сдвигов влево этого кода на 25 двоичных разрядов.

    SKIPJACK

    Skipjack - секретный в прошлом блочный алгоритм, который ассоциируется с микросхемой Clipper (описание стало открытым в июне 1989 года). Алгоритм представляет собой альтернативу решениям, предлагаемым в алгоритмах IDEA и Safer (развитие идей DES, Lucifer и Blowfish). Блок исходных данных также как и в idea разбиваются на четыре группы. Алгоритм легко реализуется на обычной ЭВМ. Skipjack включает в себя 32 цикла шифрования. Эти циклы имеют две разновидности (А и В). Цикл А выполняет следующие операции.

    Первая группа бит исходного текста подвергается шифрованию с использованием G-перестановок (четырех цикличный шифр Файстела - специальный класс блочных шифров, где зашифрованный текст получается из исходного путем многократного использования одного и того же преобразования, напоминает шифр DES. Исходный текст разделяется на две части. Функция преобразования f и ключ используются для преобразования одной из половин а результат объединяется со второй частью исходного кода с помощью операции исключающее ИЛИ. После этого части меняются местами и процедура повторяется и т.д.). Для полученного результата и номера цикла (RN = 1-32) и четвертой группы исходного текста (W4) выполняется операция XOR. После этого производится перенос: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.

    Цикл В осуществляет следующие преобразования.

    Для второй группы бит исходного текста (W2) выполняется операция XOR с номером цикла и первой группой бит исходного текста (W2 = (W2 XOR RN) XOR W1). Затем первая группа блока (W1) подвергается шифрованию с использованием G-перестановок. После этого производится перенос данных: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.

    Последовательность выполнения алгоритма Skipjack предполагает выполнение 8 циклов типа А, 8 циклов В, 6 циклов А и 8 циклов В.

    Рис. 6.4.7.2. Блок-схема алгоритма шифрования Skipjack

    G-перестановки включают в себя разделение группы из 16 бит на две подгруппы по 8 бит. Подобно DES левая половина кода не изменяется в процессе реализации цикла шифрования, а используется в качестве входного параметра F-функции, для результата которой и правой части кода выполняется операция XOR. В отличии от DES половины кода меняются местами лишь после завершающего цикла.

    F-функция G-перестановок достаточно проста: входные данные и субключ цикла объединяются операцией XOR, а результат заменяется кодом из таблицы просмотра (lookup-таблица - F). Субключи для G имеют длину 8 бит и являются первыми четырьмя байтами 80-битового исходного ключа. Первые 4 байта используются в первом цикле, следующие 4 - во втором, последние 2 байта вместе с первыми двумя - в третьем и т.д. 12 первых циклов реализации алгоритма шифрования Skipjack показаны на рис. 6.4.7.2. Первый цикл типа А отображен вместе со схемой реализации G-функции. Для следующих 7 циклов типа А G-функция отмечена квадратиком с буквой G. Цифрами (1-12) отмечен ввод данных для цикла с соответствующим номером. При реализации F-функции используется таблица (16*16) перестановок кодов 0-255.

    В случае дешифровки циклы выполняются в обратном порядке. Аналогом цикла А при дешифровке является последовательность операций:

    Для групп бит W1 и W2 и номера цикла выполняется операция XOR (циклы здесь нумеруются, начиная с 32 до 1). Затем W2 подвергается обратной G-перестановке, после чего выполняется перенос: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3. Аналог цикла типа В при дешифровке включает в себя следующие операции:

    Группа бит W2 подвергается обратной G-перестановке. W3 объединяется с номером цикла и группой бит W2 с помощью операции исключающее ИЛИ. После чего производится перемещение: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3.

    Previous: 6.4.6 Алгоритм Диффи-Хелмана    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.8 Алгоритм шифрования SAFER


    previous up down next index index
    Previous: 6.4.7 IDEA - международный алгоритм шифрования данных    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.9 Аутентификация в Интернет

    6.4.8 Алгоритм шифрования SAFER
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Алгоритм шифрования SAFER (Secure And Fast Encryption Routine; http://fn2.freenet.edmonton.ab.ca/~jsavard/co0403.html) не использует разбивку исходного текста на блоки (как это делается в DES или IDEA). Здесь исходный текст пропускается через S-матрицы, которые заменяются на обратные версии при дешифровании. В SAFER используется 8 циклов. Первый шаг цикла заключается в использовании первого субключа для преобразования 8 байт исходного текста. То, как используется субключ, зависит от номера байта в группе. Так для 1-го, 4-го, 5-го и 8-го для этого служит операция XOR, а для 2-го, 3-го, 6-го и 7-го байтов применяется операция сложения.

    Затем при обработке текста в S-матрице байты, для которых было применено исключающее ИЛИ, поступают на обычную матрицу, для остальных применяется инвертированная. s-матрицы представляют собой таблицы байтов, которые получаются по формуле 45N mod 257, где N -номер кода в таблице (после чего выделяются 8 младших разрядов).

    1 45 226 147 190 69 21 174
    120 3 135 164 184 56 207 63
    8 103 9 148 235 38 168 107
    189 24 52 27 187 191 114 247

    64 53 72 156 81 47 59 85
    227 192 159 216 211 243 141 177
    255 167 62 220 134 119 215 166
    17 251 244 186 146 145 100 131

    241 51 239 218 44 181 178 43
    136 209 153 203 140 132 29 20
    129 151 113 202 95 163 139 87
    60 130 196 82 92 28 232 160

    4 180 133 74 246 19 84 182
    223 12 26 142 222 224 57 252
    32 155 36 78 169 152 158 171
    242 96 208 108 234 250 199 217

    0 212 31 110 67 188 236 83
    137 254 122 93 73 201 50 194
    249 154 248 109 22 219 89 150
    68 233 205 230 70 66 143 10

    193 204 185 101 176 210 198 172
    30 65 98 41 46 14 116 80
    2 90 195 37 123 138 42 91
    240 6 13 71 111 112 157 126

    16 206 18 39 213 76 79 214
    121 48 104 54 117 125 228 237
    128 106 144 55 162 94 118 170
    197 127 61 175 165 229 25 97

    253 77 124 183 11 238 173 75
    34 245 231 115 35 33 200 5
    225 102 221 179 88 105 99 86
    15 161 49 149 23 7 58 40

    Обратная матрица при этом имеет вид.

    128 0 176 9 96 239 185 253
    16 18 159 228 105 186 173 248
    192 56 194 101 79 6 148 252
    25 222 106 27 93 78 168 130

    112 237 232 236 114 179 21 195
    255 171 182 71 68 1 172 37
    201 250 142 65 26 33 203 211
    13 110 254 38 88 218 50 15

    32 169 157 132 152 5 156 187
    34 140 99 231 197 225 115 198
    175 36 91 135 102 39 247 87
    244 150 177 183 92 139 213 84

    121 223 170 246 62 163 241 17
    202 245 209 23 123 147 131 188
    189 82 30 235 174 204 214 53
    8 200 138 180 226 205 191 217

    208 80 89 63 77 98 52 10
    72 136 181 86 76 46 107 158
    210 61 60 3 19 251 151 81
    117 74 145 113 35 190 118 42

    95 249 212 85 11 220 55 49
    22 116 215 119 167 230 7 219
    164 47 70 243 97 69 103 227
    12 162 59 28 133 24 4 29

    41 160 143 178 90 216 166 126
    238 141 83 75 161 154 193 14
    122 73 165 44 129 196 199 54
    43 127 67 149 51 242 108 104

    109 240 2 40 206 221 155 234
    94 153 124 20 134 207 229 66
    184 64 120 45 58 233 100 31
    146 144 125 57 111 224 137 48

    После обработки с помощью S-матрицы используется второй субключ, который воздействует на блок преобразуемых данных. В этом случае используется другая последовательность операций: ADD, XOR, XOR, ADD, ADD, XOR, XOR, ADD (сравните с порядком операций, указанным в первом абзаце главы). Далее байты группируются: второй байт заменяется суммой первого байта и второго, первый - суммой нового значения второго байта и первого, четвертый - суммой третьего и четвертого, третий - суммой нового значения четвертого и третьего и т.д. вплоть до 8 байта включительно (см. рис. 6.4.8.1). При суммировании в результате операции учитываются только младшие 8 бит. По завершении этой процедуры байты выкладываются в следующем порядке (цифры означают старое положений байтов):

    1. 3 5 7 2 4 6 8

    Рис. 6.4.8.1. Блок-схема реализации цикла алгоритма SAFER

    После этого процедуры группирования и суммирования и перемешивания байтов повторяются.

    Дешифровка в рамках алгоритма SAFER реализуется для каждой из процедур (путем замены их на обратные), примененной при шифровании независимо.

    В качестве первого 64-битного субключа используется основной ключ шифрования. Для генерации последующих ключей используется циклический сдвиг влево на 3 бита. Полученные результаты объединяются с определенной константой (специфичной для каждого цикла) с помощью операции исключающее ИЛИ (XOR). Для первого субключа эта константа равна нулю. Далее используются константы, приведенные ниже:

    16733B1E8E70BD86
    477E2456F1778846
    B1BAA3B7100AC537
    C95A28AC64A5ECAB
    C66795580DF89AF6
    66DC053DD38AC3D8
    6AE9364943BFEBD4
    9B68A0655D57921F
    715CBB22C1BE7BBC
    63945F2A61B83432
    FDFB1740E6511D41
    8F29DD0480DEE731
    7F01A2F739DA6F23
    FE3AD01CD1303E12
    CD0FE0A8AF82592C
    7DADB2EFC287CE75
    1302904F2E723385
    8DCFA981E2C4272F
    7A9F52E115382BFC
    42C708E409555E8C

    Previous: 6.4.7 IDEA - международный алгоритм шифрования данных    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.9 Аутентификация в Интернет


    previous up down next index index
    Previous: 6.4.8 Алгоритм шифрования SAFER    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования

    6.4.9 Аутентификация в Интернет
    Семенов Ю.А. (ГНЦ ИТЭФ)

    1. Введение

    Аутентификационные требования вычислительных систем и сетевых протоколов варьируются в весьма широких пределах. Пароли, которые уязвимы для атак пассивного типа, не могут удовлетворить требованиям современного Интернет [CERT94]. А помимо пассивных атак в сетевой среде сплошь и рядом предпринимаются активные методы [Bellovin89, Bellovin92, Bellovin93, CB94, Stoll90].

    2. Определения и терминология, используемые в данном документе

    Активная атака . Попытка некорректной модификации данных с целью аутентификации или авторизации с помощью вставления ложных пакетов в поток данных или их модификации.

    Асимметричная криптография. Криптографическая система, которая использует различные ключи для шифрования и дешифрования. Эти два ключа являются математически связанными. Называется также криптографией с общедоступным ключом.

    Аутентификация. Идентификация источника информации.

    Авторизация. Предоставление прав доступа на основе аутентификации.

    Конфиденциальность. Защита информации, так чтобы лицо, не авторизованное для доступа к данным, не могло их читать, даже если имеется доступ к соответствующему каталогу или сетевому пакету.

    Шифрование. Механизм, используемый для обеспечения конфиденциальности.

    Целостность . Защита информации от неавторизованной модификации.

    Сертификат ключа . Информационная структура, состоящая из общедоступного ключа, идентификатора лица, системы и информации, аутентифицирующей ключ и ассоциацию общедоступного ключа с идентификатором. Ключи, используемые PEM, являются примером сертификата ключа [Kent93].

    Пассивная атака. Атака на систему аутентификации, которая не предполагает введения каких-либо данных в поток, но базируется на возможности мониторинга информации, которой обмениваются другие партнеры. Эта информация может быть использована позднее.

    Исходный текст (Plain-text). Незашифрованный текст.

    Атака воспроизведения (Replay Attack). Атака на систему аутентификации путем записи и последующего воспроизведения ранее посланных корректных сообщений или их частей. Любая неизменная информация, такая как пароль или биометрические данные могут быть записаны и использованы позднее для имитации аутентичности.

    Симметричная криптография. Система шифрования, которая использует один и тот же ключ для шифрования и дешифрования. Иногда называется криптографией с секретным ключом.

    3. Аутентификационные технологии

    Существует некоторое число различных классов аутентификации, начиная с полного ее отсутствия до очень строгих механизмов контроля. Для различных целей могут использоваться разные виды аутентификации.

    3.1. Отсутствие аутентификации

    Простейшая аутентификационная система не имеет аутентификации вовсе. Изолированная от сети частная персональная ЭВМ является примером, где аутентификация не нужна. Другим примером может служить автономная общедоступная рабочая станция, обслуживающая некоторые конференции, где раскрытие информации или ее модификация не являются критическими.

    3.2. Аутентификационные механизмы, уязвимые для пассивных атак

    Простая проверка пароля является наиболее общей формой аутентификации. Простые аутентификационные проверки имеют различные формы: ключ может быть паролем, запомненным пользователем, он может быть физическим или электронным объектом, принадлежащим пользователю, он может быть уникальной биологической характеристикой. Простые аутентификационные системы считаются "раскрывающими", так как, если ключ передается по сети, он может быть перехвачен злоумышленником. Имеются сообщения об успешных пассивных атаках в Интернет с помощью "расколотых" уже ЭВМ [CERT94]. Механизмы раскрывающей аутентификации уязвимы для атак "воспроизведения". Ключи доступа могут быть запомнены в атакуемой машине и при наличии бреши в системе безопасности можно получить доступ ко всем паролям. Обычно форма хранения паролей допускает их сверку, но не чтение.

    3.3. Аутентификационные механизмы, уязвимые для активных атак

    Не раскрывающие парольные системы созданы для предотвращения атак воспроизведения. Разработано несколько систем для генерации не раскрываемых паролей. Система аутентификации S/Key (TM), разработанная в Bellcore генерирует много одноразовых паролей из одного секретного ключа [Haller94]. Она не использует физических объектов (token), поэтому удобна для аутентификации машина-машина. Аутентификация S/Key не требует запоминания секретного ключа пользователя, что является преимуществом при работе с ненадежными вычислительными системами. В ее сегодняшнем виде система S/Key уязвима для переборных атак со словарем в случае неудачного выбора пароля. Система CHAP протокола PPP не является раскрывающей, но применима только локально [LS92, Simpson93].

    3.4. Аутентификационные механизмы, не уязвимые для пассивных атак

    По мере расширения применения сетей растет необходимость более жесткой аутентификации. В открытых сетях большое число пользователей могут получить доступ к информации, переносимой по сети. При желании пользователь может сымитировать ситуацию, при которой посланная им информация будет восприниматься, как посланная другим сетевым объектом.

    Более мощные аутентификационные системы используют вычислительные возможности партнеров, участвующих в процессе аутентификации. Аутентификация может быть однонаправленной, например аутентификация пользователей в вычислительной системе, или она может быть взаимной, когда оба партнера должны идентифицировать друг друга. Некоторые системы аутентификации используют криптографические методы и формируют общий секретный код (например, ключ сессии), который может быть использован при последующем обмене. Например, пользователю после завершения процесса аутентификации может быть предоставлен аутентификационный билет, который может быть использован для получения других услуг без дополнительной аутентификации. Эти системы аутентификации могут также обеспечить, когда требуется, конфиденциальность (используя шифрование) при передаче данных по незащищенным сетям.

    4. Криптография

    Криптографические механизмы широко используются для осуществления аутентификации в современных сетях. Существует два базовых вида криптографии (симметричная и асимметричная). Одной из фундаментальных проблем для криптографии является транспортировка секретных ключей.

    4.1. Симметричная криптография

    Симметричная криптография включает в себя все системы, которые используют один и тот же ключ для шифрования и дешифрования. Таким образом, если кто-либо получит ключ, он сможет дешифровать и читать информацию, зашифрованную с его помощью. Такое лицо сможет шифровать и посылать любые данные, выдавая их за информацию, посланную легальным владельцем этого секретного ключа. Это означает, что знание ключа нежелательным третьим лицом полностью компрометирует конфиденциальность системы. Следовательно, используемые ключи должны доставляться безопасным способом, либо курьером, либо с применением специального протокола пересылки ключей, лучшим из которых является алгоритм Нидхэма-Шрёдера [NS78, NS87]. Широко используется алгоритм DES (Data Encryption Standard), который был стандартизован для защиты правительственной информации в США. Он представляет собой один из лучших симметричных алгоритмов шифрования [NBS77].

    Хорошо известной системой, работающей в открытых сетях, является система аутентификации Kerberos (TM), которая была разработана в рамках проекта Athena в MIT [SNS88, BM91, KN93]. Система Kerberos базируется на алгоритме DES и использует специальный сервер, который хранит секретные ключи всех пользователей и услуг. Он может генерировать коды, которые позволяют пользователям и процессам идентифицировать себя в других системах. Как в любой схеме с распределенной аутентификацией, эти верительные коды работают в пределах местного административного домена. Следовательно, если пароль пользователя раскрыт, злоумышленник будет способен маскироваться под этого пользователя и проникнуть в любую систему, обслуживаемую Kerberos. Так как сервер Kerberos знает все секретные ключи, он должен быть достаточно безопасным. Ключи сессии Kerberos могут использоваться для обеспечения конфиденциальности при обмене между любыми объектами в пределах зоны действия сервера.

    4.2. Асимметричная криптография

    В конце 1970, главным прорывом в криптографии стала разработка асимметричной криптографии. Здесь для шифрования и дешифрования используются разные ключи, которые генерируются совместно. Наилучшая асимметричная система базируется на алгоритме, предложенном Rivest, Shamir и Adleman, и называется по инициалам авторов RSA [RSA78].

    SPX представляет собой экспериментальную систему, которая преодолевает ограничения системы Kerberos путем применения криптографии с общедоступным ключом RSA [TA91]. SPX предполагает глобальную иерархию сертифицирующих узлов по одному или более для каждого из партнеров. Она использует цифровую подпись, которая состоит из строки кодов, зашифрованных секретным ключом отправителя, и которая может быть проверена с помощью соответствующего общедоступного ключа. Общедоступные ключи предполагаются правильными, так как получены с сертифицирующей подписью. Критические секции аутентификационного обмена шифруются посредством общедоступных ключей получателя, что препятствует атаке воспроизведения.

    4.3. Криптографические контрольные суммы

    Криптографические контрольные суммы являются одним из наиболее важных средств разработчиков криптографических протоколов. Криптографическая контрольная сумма или MIC (message integrity checksum) служат для контроля целостности сообщений и аутентификации. Например, Secure SNMP и SNMPv2 вычисляют криптографическую контрольную сумму MD5 для совместного секретного блока данных и информации, которая должна быть аутентифицирована [Rivest92, GM93]. Это служит для того, чтобы аутентифицировать источник данных при этом предполагается, что эту сумму крайне трудно фальсифицировать. Она не указывает на то, что сами посланные данные корректны, а лишь на то, что они посланы именно данным отправителем. Криптографические контрольные суммы могут использоваться для получения относительно эффективной аутентификации, и особенно полезны при обмене ЭВМ-ЭВМ. Главная трудность реализации - передача ключей.

    4.4. Цифровые подписи (сигнатуры)

    Цифровая подпись представляет собой криптографический механизм, который является аналогом рукописной подписи. Она служит для аутентификации блока данных и подтверждает то, что она получена от отправителя. Цифровая подпись, использующая асимметричную криптографию (общедоступные ключи) может быть полезной для определения источника сообщения даже в случае, когда отправитель отрицает свое авторство. Цифровая подпись обеспечивает аутентификацию без конфиденциальности, так как текст самого сообщения не шифруется. Цифровая подпись использована в системе конфиденциальной почты PEM (Privacy Enhanced Mail) [Linn93, Kent93, Balenson93, Kaliski93].

    5. Аутентификация пользователя на ЭВМ

    Существует много различных подходов к проблеме аутентификации пользователя в удаленных ЭВМ. Имеется две угрозы при доступе к удаленной ЭВМ. Во-первых, злоумышленник может перехватить идентификатор и пароль пользователя и позднее воспользоваться ими при атаке "воспроизведения". Во-вторых, сама форма пароля позволяет хакеру попытаться его угадать.

    В настоящее время большинство систем используют открытый текст для передачи паролей по сетевым каналам, что сильно упрощает их перехват [Anderson84, Kantor91]. Такая система не обеспечивает адекватной защиты от атак воспроизведения, когда злоумышленник сумел заполучить идентификатор и пароль удаленного пользователя.

    5.1. Защита против пассивной атаки является необходимой

    Отсутствие, по крайней мере, не раскрывающей парольной системы, означает предоставление неограниченного доступа любому, кто имеет физический доступ к сети. Например, всякий кто имеет доступ к кабелю Ethernet<, может имитировать работу любого пользователя данного сегмента сети. Таким образом, когда кто-то имеет пароль, передаваемый по Ethernet открытым текстом, реализуется первичная система безопасности. Когда размер локальной системы невелик (а это справедливо не только для Ethernet, но и для FDDI или Token-Ring LAN), данная система может еще рассматриваться как приемлемая, но это совершенно не так для сетей Интернет [CERT94].

    Минимальной защитой против пассивных атак, таких как прослушивание сети, является применение не раскрывающей системы паролей. Такая система может функционировать на пассивном терминале или в качестве коммуникационной программы (напр., Crosstalk или PROCOMM), которая эмулирует пассивный терминал на персональной ЭВМ. Использование более строгой аутентификационной системы защитит против пассивных атак со стороны удаленных систем за счет ограничения использования простых терминалов. Разумно ожидать, что производители коммуникационных программ и не программируемых пользователем терминалов (таких как Х-терминалы) встроят систему не раскрываемых паролей или более строгие аутентификационные системы. Одним из преимуществ Kerberos является то, что при правильном использовании пароль пользователя никогда не покидает пределов рабочей станции. Вместо этого они используются для расшифровки билетов пользователя Kerberos.

    5.2. Защита периметра

    Защита периметра применяется все шире. В этих системах пользователь сначала осуществляет аутентификацию в определенном объекте сети, например, в ЭВМ "firewall", используя систему не раскрываемых паролей. Пользователь затем использует вторую систему для аутентификации в каждой ЭВМ или в группе ЭВМ, где он хотел бы получить доступ к определенным услугам.

    В защите периметра существует несколько недостатков, по этой причине эту систему следует рассматривать как временное решение. Сетевой шлюз не прозрачен на IP-уровне и по этой причине работа с каждым видом сервиса должна производиться независимо. Использование двойной аутентификации является трудно осуществимым или невозможным для связи ЭВМ-ЭВМ. Протоколы точка-точка, которые являются обычными для Интернет механизмов без установления связи, легко уязвимы. Защита периметра должна быть плотной и полной, так как в случае ее прорыва внутренняя защита оказывается слабой и легко преодолимой.

    Частой формой защиты периметра является передача приложений. Так как эти передачи являются протокольно зависимыми, IP-коннективность ЭВМ в пределах периметра с внешним миром оказывается нарушенной и часть преимуществ Интернет пропадает.

    Административное преимущество защиты периметра заключается в том, что число ЭВМ, которые могут быть подвергнуты атаке, достаточно мало. Эти машины могут быть тщательно проверены с точки зрения угроз безопасности. Но достаточно трудно или даже невозможно создать достаточно "герметичную" систему. Безопасность системы защиты периметра достаточно сложна, так как шлюз должен пропускать некоторые типы трафика, например, электронную почту. Другие сетевые услуги, такие как NTP (Network Time Protocol) и FTP могут также оказаться желательными [Mills92, PR85, Bishop]. Более того, шлюзовая система периметра должна быть способна пропускать весь трафик всего домен, заключенного в данный периметр.

    5.3. Защита от активных атак является крайне желательной

    В обозримом будущем потребуются достаточно мощные системы, способные противостоять активным атакам. Многие корпоративные сети, базирующиеся на широковещательной технологии, такой как Ethernet, вероятно нуждаются в такой методике. Чтобы защититься от активных атак, или обеспечить конфиденциальность, необходимо использовать протокол с шифрованием сессии, например, Kerberos, возможно использование аутентификационного механизма, который защищает от атаки воспроизведения. В системе Kerberos, пользователи получают коды доступа от сервера Kerberos и используют их для аутентификации, чтобы осуществить доступ к услугам других ЭВМ сети. Вычислительная мощность локальной рабочей станции может быть использована для дешифрования кодов доступа (используя ключ, извлеченный из пароля, введенного пользователем) и запоминания на время пока это требуется. Если протокол безопасности базируется на синхронизации часов, тогда может быть полезен протокол NTPv3, так как он распространяет временные метки для большого числа ЭВМ и является одним из немногих протоколов Интернет, которые содержат механизмы аутентификации [Bishop, Mills92].

    Другим подходом для доступа к сетевым ЭВМ является введение для всех внешних машин общего секретного кода Kerberos KDC. Это делает эти машины "серверами", а не рабочими станциями. Этот общий секретный код может быть затем использован для шифрования всех обменов между машинами, обеспечивая безопасную передачу аутентификационной информации KDC.

    Наконец, рабочие станции, которые удаленно доступны, могут использовать асимметричную криптографическую технологию для шифрования телекоммуникаций. Общедоступный ключ рабочей станции будет предоставлен всем клиентам. Пользователь может применить общедоступный ключ для шифрования пароля, а удаленная система дешифрует его и аутентифицирует пользователя без угрозы раскрытия пароля при транспортировке. Ограничением этой системы безопасности, ориентированной на рабочую станцию заключается в том, что она не аутентифицирует индивидуальных пользователей, а только индивидуальные рабочие станции. В некоторых средах, например, в многоуровневых правительственных системах безопасности необходима аутентификация пользователь-пользователь.

    6. Раздача ключей и управление

    Управление доступом для ключей является самой тяжелой проблемой, с которой приходится сталкиваться при обеспечении аутентификации в больших сетях Интернет. Протокол Нидхема-Шрёдера [NS78, NS87], который используется в системе Kerberos, базируется на централизованном сервере ключей. В больших корпоративных сетях требуется значительное число таких ключевых серверов, по крайней мере, один ключевой сервер на каждый административный домен. Существует также нужда в механизмах для отдельных ключевых серверов, необходимых для координирования генерации ключей сессий участников в различных административных доменах.

    Большинство алгоритмов шифрования с использованием общедоступных ключей требуют достаточно больших вычислительных мощностей и по этой причине они неидеальны для шифрования пакетов в сети. Однако асимметричное свойство делает их очень полезными в начале сессии для получения симметричных ключей сессии. На практике, коммерческий сектор, вероятно, использует асимметричный алгоритм для цифровых подписей и пересылки ключей, но не для массового шифрования данных. Для целей пересылки ключей можно использовать алгоритмы RSA и Диффи-Хелмана [DH76]. Преимуществом асимметричной методики является отсутствие необходимости иметь центральный сервер для хранения и рассылки ключей. Система PEM использует цифровые подписи для аутентификации общедоступных ключей пользователей [Kent93]. Результатом этой операции является сертификат, который содержит общедоступный ключ партнера. Сертификаты ключей могут рассылаться различными способами. В одном из вариантов рассылка ключей встраивается в существующие службы каталогов. Это может быть сделано, например, путем расширения возможностей DNS и включения ключа ЭВМ в ресурсную запись нового типа.

    Для мультикастных сессий, управление рассылкой ключей сложнее, так как число обменов, необходимых для широко используемых методик пропорционально числу участников.

    7. Аутентификация сетевых услуг

    Кроме необходимости аутентификации пользователей и ЭВМ друг другу, многие сетевые услуги сами нуждаются в аутентификации.

    Наиболее общий случай в настоящее время - это отсутствие поддержки в протоколе какой-либо аутентификации. Bellovin и другие документировали многие случаи, когда существующие протоколы могут использоваться для атаки удаленной ЭВМ, так как там не существует встроенной процедуры аутентификации [Bellovin89].

    Некоторые протоколы предоставляют возможность передачи незащищенных паролей совместно с протокольной информацией. Исходные протоколы SNMP использовали этот метод, многие маршрутные протоколы продолжают его использовать и сейчас [Moy91, LR91, CFSD88]. Этот метод полезен, так как несколько повышает безопасность передачи.

    Существует много протоколов, которые нуждаются в поддержке более строгих аутентификационных механизмов. Например, известно, что протокол SNMP нуждается в существенном усилении аутентификации. Это вызвало разработку протоколов Secure SNMP, которые поддерживают опционную аутентификацию, используя цифровую подпись и опционное шифрование с привлечением алгоритма DES. Цифровые подписи, используемые в Secure SNMP, базируются на добавлении криптографической контрольной суммы к SNMP-информации. Криптографическая контрольная сумма вычисляется с использованием алгоритма MD5 и секретного кода, используемого совместно обоими партнерами обмена.

    Технология цифровой подписи должна рассматриваться как необходимое средство при разработке новых технологий аутентификации (но не конфиденциальности). Цифровые подписи могут использовать ключи и методы как симметричной, так и асимметричной криптографии. Если доступна централизованная система распределения ключей, опционная поддержка цифровой подписи может быть обеспечена для большинства протоколов с минимальными издержками. Каждый протокол может столкнуться проблемой пересылки ключей и установки параметров обмена, и это приведет к усложнению использования техники цифровой подписи.

    Для случаев, когда требуется аутентификация и конфиденциальность для схемы коммуникации ЭВМ-ЭВМ, может быть применено шифрование, базирующееся на симметричной или асимметричной схеме, или даже на их комбинации. Использование асимметричной криптографии упрощает управление раздачей ключей. Каждая ЭВМ шифрует свою информацию перед отправкой, безопасность же внутри машины обеспечивается средствами операционной системы ЭВМ.

    В некоторых случаях, возможно включающих электронную почту, может оказаться желательным обеспечить безопасность в пределах приложения на уровне пользователь-пользователь, а не ЭВМ-ЭВМ. Безопасная почта PEM использует именно этот подход [Linn93, Kent93, Balenson93, Kaliski93].

    8. Будущие направления

    Просматривается тенденция внедрения все более строгих механизмов аутентификации. Следует ожидать введения не раскрывающей пароли аутентификации и более широкого использования механизмов с общедоступным ключом. Растет важность аутентификации сессий и процессов, проблема целостности и конфиденциальности сообщений при передаче по сетевым каналам. Так как коммуникации ЭВМ-ЭВМ становятся все более важными, протоколы связи человек-машина становятся менее существенными.

    Использование криптосистем с общедоступным ключом для аутентификации пользователь-ЭВМ упрощает многие аспекты, но хранение простых паролей, а также общедоступных и секретных ключей остается актуальной проблемой. Следует учитывать, что размер общедоступного ключа, используемого в настоящее время, по меньшей мере, составляет 500 бит. В будущем, вероятно, будут применяться еще более длинные ключи. Таким образом, пользователи могут хранить свои ключи в виде пригодном для электронного считывания. Использование ROM, такой как флоппи-диск или магнитная карточка может решить эту проблему, но тогда пользователь неизбежно доверяет свои ключи считывающему устройству. Применение смарт-карты, совмещающей память и программу, более предпочтительно. Такие приборы могут обеспечить аутентификацию без риска разглашения секретных кодов, которые они хранят. Они могут также взаимодействовать с пользователем, осуществляя простую аутентификацию при разблокировании карты. Применение криптосистем с общедоступным ключом при аутентификации ЭВМ-ЭВМ лишено проблем запоминания ключей, которые характерны для интерфейсов человек-машина. Многопользовательская ЭВМ может запоминать свои ключи в области памяти, защищенной от доступа пользователей.

    Если рассматривать существующие симметричные алгоритмы как одно-ключевые, а асимметричные, такие как RSA в качестве двухключевых систем, можно предположить появление в будущем N-ключевых методик (где N больше 2). Если бы такая N-ключевая технология существовала, она могла бы использоваться для реализации масштабируемых протоколов для рассылки ключей в случае мультикастинга. В настоящее время ведется разработка технологии CBT (Core Based Tree), предназначенной для решения подобной задачи [BFC93].

    Ссылки

    [Anderson84]

    Anderson, B., "TACACS User Identification Telnet Option", RFC 927, BBN, December 1984.

    [Balenson93]

    Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.

    [BFC93]

    Ballardie, A., Francis, P., and J. Crowcroft, "Core Based Trees (CBT) An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM93, ACM, San Franciso, CA, September 1993, pp. 85-95.

    [Bellovin89]

    Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989.

    [Bellovin92]

    Bellovin, S., "There Be Dragons", Proceedings of the 3rd Usenix UNIX Security Symposium, Baltimore, MD, September 1992.

    [Bellovin93]

    Bellovin, S., "Packets Found on an Internet", ACM Computer Communications Review, Vol. 23, No. 3, July 1993, pp. 26-31.

    [BM91]

    Bellovin S., and M. Merritt, "Limitations of the Kerberos Аутентификация System", ACM Computer Communications Review, October 1990.

    [Bishop]

    Bishop, M., "A Security Analysis of Version 2 of the Network Time Protocol NTP: A report to the Privacy & Security Research Group", Technical Report PCS-TR91-154, Department of Mathematics & Computer Science, Dartmouth College, Hanover, New Hampshire.

    [CB94]

    Cheswick W., and S. Bellovin, "Chapter 10: An Evening with Berferd", Firewalls & Internet Security, Addison-Wesley, Reading, Massachusetts, 1994. ISBN 0-201-63357-4.

    [CERT94]

    Computer Emergency Response Team, "Ongoing Network Monitoring Attacks", CERT Advisory CA-94:01, available by anonymous ftp from cert.sei.cmu.edu, 3 February 1994.

    [CFSD88]

    Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1067, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, Proteon, Inc., August 1988.

    [DH76]

    Diffie W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Volume IT-11, November 1976, pp. 644-654.

    [GM93]

    Galvin, J., and K. McCloghrie, "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993.

    [Haller94]

    Haller, N., "The S/Key One-time Password System", Proceedings of the Symposium on Network & Distributed Systems Security, Internet Society, San Diego, CA, February 1994.

    [Kaufman93]

    Kaufman, C., "Distributed Аутентификация Security Service (DASS)", RFC 1507, Digital Equipment Corporation, September 1993.

    [Kaliski93]

    Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993.

    [Kantor91]

    Kantor, B., "BSD Rlogin", RFC 1258, Univ. of Calif San Diego, September 1991.

    [Kent93]

    Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, IAB IRTF PSRG, IETF PEM, February 1993.

    [KN93]

    Kohl, J., and C. Neuman, "The Kerberos Network Аутентификация Service (V5)", RFC 1510, Digital Equipment Corporation, USC/Information Sciences Institute, September 1993.

    [Linn93]

    Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Аутентификация Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

    [Linn93a]

    Linn, J., "Common Аутентификация Technology Overview", RFC 1511, Geer Zolot Associate, September 1993.

    [LS92]

    Lloyd B., and W. Simpson, "PPP Аутентификация Protocols", RFC 1334, L&A, Daydreamer, October 1992.

    [LR91]

    Lougheed K., and Y. Rekhter, "A Border Gateway protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.

    [Mills92]

    Mills, D., "Network Time Protocol (Version 3) - Specification, Implementation, and Analysis", RFC 1305, UDEL, March 1992.

    [NBS77]

    National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, Government Printing Office, Washington, DC, 1977.

    [NS78]

    Needham, R., and M. Schroeder, "Using Encryption for Аутентификация in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, ёDecember 1978.

    [NS87]

    Needham, R., and M. Schroeder, " Аутентификация Revisited", ACM Operating Systems Review, Vol. 21, No. 1, 1987.

    [PR85]

    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

    [Moy91]

    Moy, J., "OSPF Routing Protocol, Version 2", RFC 1247, Proteon, Inc., July 1991.

    [RSA78]

    Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public Key Crypto-systems", Communications of the ACM, Vol. 21, No. 2, February 1978.

    [Rivest92]

    Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992.

    [Simpson93]

    Simpson, W., "The Point to Point Protocol", RFC 1548, Daydreamer, December 1993.

    [SNS88]

    Steiner, J., Neuman, C., and J. Schiller, "Kerberos: "An Аутентификация Service for Open Network Systems", USENIX Conference Proceedings, Dallas, Texas, February 1988.

    [Stoll90]

    Stoll, C., "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage", Pocket Books, New York, NY, 1990.

    [TA91]

    Tardo J., and K. Alagappan, "SPX: Global Аутентификация Using Public Key Certificates", Proceedings of the 1991 Symposium on Research in Security & Privacy, IEEE Computer Society, Los Amitos, California, 1991. pp.232-244.

    Previous: 6.4.8 Алгоритм шифрования SAFER    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования


    previous up down next index index
    Previous: 6.4.9 Аутентификация в Интернет    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.5 Протокол SSL. Безопасный уровень соединителей

    6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, http://www.cs.sunysb.edu/~zhaoming/np.html , http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/node14.html , а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации.

    Операция аутентификации может охватывать несколько процессов.

    1. Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.
    2. Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.
    3. Коммуникация, при которой источник информации и ее целостность может гарантироваться третей стороной.

    Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен и, таким образом, способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения.

    Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации. Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ).

    При схеме шифрования с одним ключом, предполагается, что секретный ключ известен обоим субъектам обмена (А и В) и серверу аутентификации. Инициатором обмена будем считать субъекта А. Сообщения, посылаемые от А к В, могут быть дешифрованы только В и субъект В должен быть уверен, что сообщение пришло именно от А. В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации (AS). AS знает секретные ключи субъектов А и В (KA и KB, соответственно).

    Обмен начинается с того, что субъект А генерирует свой идентификатор IA1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:

    A® AS:

    (A, B, IA1)

    (1)

    Здесь предполагается, что сообщение послано открытым текстом, но в принципе оно может быть и зашифровано с использованием ключа KA.

    A® AS:

    (A, B, IA1)KA

    (1.1)

    Получив это сообщение AS , извлекает из базы данных секретные ключи KA и KB, а также вычисляет новый ключ CK (ключ сессии), который будет использован для осуществления процедуры аутентификации. Этот новый ключ должен быть непредсказуемым, он используется только для одной операции аутентификации.

    Далее AS посылает субъекту А следующее сообщение:

    AS® A:

    (IA1, B, CK, {CK, A}KB)KA

    (1.2)

    Верхний индекс в данном выражении означает, что содержимое в скобках зашифровано с использованием ключа-индекса. КА и КВ - секретные ключи субъектов А и В, соответственно.

    Так как выражение (IA1, B, CK, {CK, A}KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора IA1 (это подтверждает то, что данное сообщение является откликом на сообщение А), и имени субъекта, с которым А намерен обмениваться данными (В). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х а не с В, сам того не подозревая. Заметим, что часть текста {CK, A}KB субъект А прочесть не может.

    Если все прошло нормально, субъект А посылает В следующее сообщение:

    A® B:

    {CK, A}KB

    (1.3)

    Нетрудно видеть, что содержимое {CK, A}KB является частью сообщения, полученного от AS. Дешифровать это послание может только субъект В, так как оно зашифровано его секретным ключом. После дешифровки В также становится владельцем ключа сессии CK. Наличие А в сообщении подтверждает факт, что код получен именно от данного субъекта. Все обмены между А и В далее будут выполняться с использованием ключа шифрования СK. Чтобы сделать схему симметричной и уменьшить вероятность атаки воспроизведения, В следует послать А свой идентификатор:

    B® A:

    {IB}CK

    (1.4)

    зашифрованный ключом СК. При этом ожидается отклик:

    A® B:

    {IB-1}CK

    (1.5)

    Таким образом, в данной версии протокола используется 5 сообщений. Злоумышленник не может имитировать такой обмен, так как не владеет ключом CK. Это число для регулярно взаимодействующих партнеров можно сократить до трех, убрав обмен сообщениями 1.1 и 1.2. При этом ключ СК будет использоваться многократно. Здесь желательно заменить обмены 1.3 и 1.4 на:

    A® B:

    {CK, A}KB, {IA2}CK

    (1.3a)

    B® A:

    {IA2 -1, IB}CK

    (1.4a)

    Теперь рассмотрим вариант протокола для случая асимметричного шифрования (двух ключевая схема).

    Предполагается, что субъекты А и В вычислили пары ключей (PKA-SKA) и (PKB-SKB), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, - к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В (PKB).

    A® AS:

    (A, B)

    (2.1)

    AS откликнется сообщением:

    AS® A:

    (PKB, B)SKAS

    (2.2)

    Сообщение зашифровано секретным ключом AS (SKAS). Открытый ключ AS (PKAS) предполагается А известным, что позволяет А успешно дешифровать данное сообщение. Здесь предполагается, что подмена ключей (SKAS-PKAS) злоумышленником-посредником невозможна.

    Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS). Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:

    A® B:

    {IA, A}PKB

    (2.3)

    Это сообщение может быть дешифровано только субъектом В. Смысл его заключается в том, что А уведомляет В о намерении установить с ним связь, и передает ему свой одноразовый идентификатор IA. Далее В запрашивает у AS открытый ключ А:

    B® AS:

    B, A

    (2.4)

    AS® B:

    {PKA, A}SKAS

    (2.5)

    После этого производится взаимная аутентификация субъектов, завершающая сессию, для чего посылаются сообщения:

    B® A:

    {IA, IB}PKA

    (2.6)

    A® B:

    { IB }PKB

    (2.7)

    Таким образом, в этом варианте аутентификация потребовала семи шагов, но 4 из них (2.1, 2.2, 2.4 и 2.5) могут быть устранены, если партнеры помнят общедоступные ключи друг друга. В этом случае схема становится эквивалентной приведенной выше версии с симметричным шифрованием.

    Так как открытые ключи общедоступны, во многих случая для обеспечения большей достоверности следует использовать шифрование типа:

    {{сообщение}SKA}SKB.

    В реальной жизни субъекты не всегда могут находиться в пределах зоны ответственности одного общего сервера аутентификации. По этой причине в общем случае каждый из субъектов может иметь свой сервер аутентификации (ASA и ASB). Так как и в этом варианте перед субъектом А стоит задача сформировать для В сообщение типа {CK, A}KB (шаг 1.3). В вычисление таких выражений будут вовлечены оба сервера, так как только ASA может шифровать объекты посредством ключа КА, и только ASB может воспользоваться ключом КВ. Не исключается необходимость обеспечения безопасного обмена между AS. Примерами такого обмена могут служить операции, завершающие сессию аутентификации:

    ASA® ASB:

    (CK, A, B, IA1)

    (1.11)

    ASB® ASA:

    (CK, A)KB, IA1, A

    (1.12)

    IA1 передается для того, чтобы сохранить состояние ASA между сообщениями 1.11 и 1.12.

    При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений.

    Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:

    A® AS:

    (A, {D}KA)

    (3.1)

    AS откликается, послав:

    AS® A:

    {A, D}KAS

    (3.2)

    Сообщение 3.2 зашифровано ключом AS и, следовательно, не может дешифровано А. Субъект А шлет документ субъекту В с блоком подписи, следующим за текстом. При получении В сначала дешифрует текст и вычисляет дайджест документа CD, затем посылает блок подписи в AS для дешифровки.

    B® AS:

    B, {A, D}KAS

    (3.3)

    Сервер дешифрует блок подписи и возвращает результат В:

    AS® B:

    {A, D}KB

    3.4)

    Если возвращенный дайджест D соответствует CD, тогда субъект, упомянутый в 3.4, является отправителем подписанного текста. Если соответствия нет, это означает, что на этапах 3.1 -3.4 произошло искажение блока подписи или самого текста.

    В случае варианта шифрования с общедоступными ключами схема электронной подписи упрощается. В этом варианте можно даже не формировать дайджест можно послать текст, зашифрованный сначала секретным ключом А, а затем с привлечением общедоступного ключа В.

    A® B:

    { (текст)SKA }PKB

     

    Субъект-получатель В дешифрует полученный текст сначала с помощью своего секретного ключа (SKB), а затем с привлечением общедоступного ключа А (PKA). При такой схеме А не сможет отказаться от того, что именно он послал текст, так как только он владеет секретным ключом SKA. Прочесть же текст может только субъект В, так как только он владеет секретным ключом SKB.

    В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см. http://dimacs.rutgers.edu/Workshops/Security/program2/dedecker/node4.html ).

    [1] Roger M. Needham and Michael D. Schroeder, Using Encryption for Authentication in Large Networks of Computers. Communication of the ACM, V.21, N12, December 1978.

    Previous: 6.4.9 Аутентификация в Интернет    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.5 Протокол SSL. Безопасный уровень соединителей


    previous up down next index index
    Previous: 6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.6 Безопасное ядро (SSH)

    6.5 Протокол SSL. Безопасный уровень соединителей
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. http://www.netscape.com/eng/security/SSL_2.html). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).

    Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения, такие как HTTP, FTP, TELNET и т.д. могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того как приложение примет или передаст первый байт данных. Все протокольные прикладные данные передаются зашифрованными с гарантией конфиденциальности.

    Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:

    • Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
    • Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.
    • Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

    6.5.1. Спецификация протокола записей SSL
    6.5.1.1. Формат заголовка записи SSL

    В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

    Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола).

    Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация):

    RECORLENGTH = ((byte[0] & 0x7F << 8)) | byte[1];

    Где byte[0] представляет собой первый полученный байт, а byte[1] - второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом:

    RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1];
    IS-ESCAPE = (byte[0] & 0x40) != 0;
    PADDING = byte[2];

    Заголовок рекорда определяет значение, называемое PADDING. Значение PADDING специфицирует число байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра, если применен блочный шифр.

    Отправитель "заполненного" рекорда добавляет заполнитель после имеющихся данных, а затем шифрует все это, благо длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема субполя PADDING.

    Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данные удаляется.

    6.5.1.2. Формат информационных записей SSL

    Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке):

    MAC-DATA[MAC-SIZE]
    ACTUAL-DATA[N]
    PADDING-DATA[PADDING]

    ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA - это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).

    Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

    MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]

    Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - "big endian").

    MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

    Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).

    SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.

    Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

    Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).

    Уровень рекордов SSL используется для всех коммуникаций SSL, включая сообщения диалога и информационный обмен. Уровень рекордов SSL применяется как клиентом, так и сервером.

    Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.

    Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO.

    6.5.2. Спецификация протокола диалога SSL
    6.5.2.1. Протокол диалога SSL

    Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.

    Фаза 1

    Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

    К этому моменту, как клиент, так и сервер имеют достаточно информации, чтобы знать, нужен ли новый мастерный ключ. Когда новый мастерный ключ не нужен, клиент и сервер немедленно переходят в фазу 2.

    Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

    Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

    Наконец, после того как мастерный ключ определен, сервер посылает клиенту сообщение SERVER-VERIFY. Этот заключительный шаг аутентифицирует сервер, так как только сервер, который имеет соответствующий общедоступный ключ, может знать мастерный ключ.

    Фаза 2

    Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

    Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.

    6.5.2.2. Типовой протокол обмена сообщениями

    В несколько упрощенном варианте диалог SSL представлен на рис. 6.5.1.

    Рис. 6.5.1. Алгоритм работы SSL

    Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что "нечто" зашифровано с помощью ключа "key".

    6.5.2.2.1. При отсутствии идентификатора сессии

    Client-hello

    C ® S:

    challenge, cipher_specs

    server-hello

    S ® C:

    connection-id,server_certificate,cipher_specs

    client-master-key

    C ® S:

    {master_key}server_public_key

    client-finish

    C ® S:

    {connection-id}client_write_key

    server-verify

    S ® C:

    {challenge}server_write_key

    server-finish

    S ® C:

    {new_session_id}server_write_key

    6.5.2.2.2. Идентификатор сессии найден клиентом и сервером

    сlient-hello

    C ® S:

    challenge, session_id, cipher_specs

    server-hello

    S ® C:

    connection-id, session_id_hit

    client-finish

    C ® S:

    {connection-id}client_write_key

    server-verify

    S ® C:

    {challenge}server_write_key

    server-finish

    S ® C:

    {session_id}server_write_key

    6.5.2.2.3. Использован идентификатор сессии и аутентификация клиента

    сlient-hello

    C ® S:

    challenge, session_id, cipher_specs

    server-hello

    S ® C:

    connection-id, session_id_hit

    client-finish

    C ® S:

    {connection-id}client_write_key

    server-verify

    S ® C:

    {challenge}server_write_key

    request-certificate

    S ® C:

    {auth_type,challenge'}server_write_key

    client-certificate

    C ® S:

    {cert_type,client_cert, response_data}client_write_key

    server-finish

    S ® C:

    {session_id}server_write_key

    В последнем обмене, response_data является функцией auth_type.

    6.5.2.3. Ошибки

    Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки:

    NO-CIPHER-ERROR

    Эта ошибка присылается клиентом серверу, когда он не может найти шифр или размер ключа, который поддерживается также и сервером. Эта ошибка неустранима.

    NO-CERTIFICATE-ERROR

    Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.

    BAD-CERTIFICATE-ERROR

    Такой отклик присылается, когда сертификат по какой-то причине считается принимающей стороной плохим. Плохой означает, что, либо некорректна подпись сертификата, либо некорректно его значение (например, имя в сертификате не соответствует ожидаемому). Эта ошибка устранима (только для аутентификации клиента).

    UNSUPPORTED-CERTIFICATE-TYPE-ERROR

    Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента).

    6.5.2.4. Сообщения протокола диалога SSL

    Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

    После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит, после того как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:

    char MSG-EXAMPLE
    char FIELD1
    char FIELD2
    char THING-MSB
    char THING-LSB
    char THING-DATA[(MSB<<8)|LSB];
    ...

    Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует порядку перечисления.

    Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

    Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах.

    6.5.2.5. Протокольные сообщения клиента

    Существует несколько сообщений, которые могут быть сформированы только клиентом. Эти сообщения ни при каких обстоятельствах не могут быть посланы сервером. Клиент, получив такое сообщение, закрывает соединение с сервером и присылает приложению уведомление об ошибке.

    CLIENT-HELLO (Фаза 1; посылается открыто)

    char MSG-CLIENT-HELLO
    char CLIENT-VERSION-MSB
    char CLIENT-VERSION-LSB
    char CIPHER-SPECS-LENGTH-MSB
    char CIPHER-SPECS-LENGTH-LSB
    char SESSION-ID-LENGTH-MSB
    char SESSION-ID-LENGTH-LSB
    char CHALLENGE-LENGTH-MSB
    char CHALLENGE-LENGTH-LSB
    char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
    char SESSION-ID-DATA[(MSB<<8)|LSB]
    char CHALLENGE-DATA[(MSB<<8)|LSB]

    Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.

    Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA.

    Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов).

    Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.

    Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем ³ 16 и £ 32.

    Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо.

    CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)

    char MSG-CLIENT-MASTER-KEY
    char CIPHER-KIND[3]
    char CLEAR-KEY-LENGTH-MSB
    char CLEAR-KEY-LENGTH-LSB
    char ENCRYPTED-KEY-LENGTH-MSB
    char ENCRYPTED-KEY-LENGTH-LSB
    char KEY-ARG-LENGTH-MSB
    char KEY-ARG-LENGTH-LSB
    char CLEAR-KEY-DATA[MSB<<8|LSB]
    char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
    char KEY-ARG-DATA[MSB<<8|LSB]

    Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается.

    Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.

    Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [5]. Информационная часть блока имеет следующий формат:

    char SECRET-KEY-DATA[SECRET-LENGTH]

    SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.

    Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.

    Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:

    SSL_CK_RC4_128_WITH_MD5
    SSL_CK_RC4_128_EXPORT40_WITH_MD5
    SSL_CK_RC2_128_CBC_WITH_MD5
    SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
    SSL_CK_IDEA_128_CBC_WITH_MD5
    KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
    KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
    CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
    CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]

    Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.

    Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID.

    Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).

    SSL_CK_DES_64_CBC_WITH_MD5
    KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
    CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
    CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]

    Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEY-ARG-DATA.

    SSL_CK_DES_192_EDE3_CBC_WITH_MD5

    KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
    KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
    KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]

    CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
    CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
    CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
    CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
    CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
    CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]

    Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).

    Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32).

    Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.

    Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт.

    Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.

    CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

    char MSG-CLIENT-CERTIFICATE
    char CERTIFICATE-TYPE
    char CERTIFICATE-LENGTH-MSB
    char CERTIFICATE-LENGTH-LSB
    char RESPONSE-LENGTH-MSB
    char RESPONSE-LENGTH-LSB
    char CERTIFICATE-DATA[MSB<<8|LSB]
    char RESPONSE-DATA[MSB<<8|LSB]

    Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATE-TYPE является одним из:

    SSL_X509_CERTIFICATE
    CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988) [3].

    RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.

    Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):

    • KEY-MATERIAL-0
    • KEY-MATERIAL-1 (только если определено типом шифра)
    • KEY-MATERIAL-2 (только если определено типом шифра)
    • CERTIFICATE-CHALLENGE-DATA (из сообщения REQUEST-CERTIFICATE)
    • Сертификат, подписанный сервером (из сообщения SERVER-HELLO).

    Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.

    Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.

    CLIENT-FINISHED (Фаза 2; посылается шифрованным)

    char MSG-CLIENT-FINISHED
    char CONNECTION-ID[N-1]

    Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.

    "N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка.

    Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY.

    6.5.2.6. Протокольные сообщения сервера

    Существует несколько сообщений, которые генерируются только серверами.

    SERVER-HELLO (Фаза 1; посылается открыто)

    char MSG-SERVER-HELLO
    char SESSION-ID-HIT
    char CERTIFICATE-TYPE
    char SERVER-VERSION-MSB
    char SERVER-VERSION-LSB
    char CERTIFICATE-LENGTH-MSB
    char CERTIFICATE-LENGTH-LSB
    char CIPHER-SPECS-LENGTH-MSB
    char CIPHER-SPECS-LENGTH-LSB
    char CONNECTION-ID-LENGTH-MSB
    char CONNECTION-ID-LENGTH-LSB
    char CERTIFICATE-DATA[MSB<<8|LSB]
    char CIPHER-SPECS-DATA[MSB<<8|LSB]
    char CONNECTION-ID-DATA[MSB<<8|LSB]

    Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль.

    Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE).

    Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY.

    Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID. SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY:

    SERVER-READ-KEY = CLIENT-WRITE-KEY
    SERVER-WRITE-KEY = CLIENT-READ-KEY

    Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY).

    CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.

    CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:

    char CIPHER-KIND-0
    char CIPHER-KIND-1
    char CIPHER-KIND-2
    Где CIPHER-KIND равен одному из:

    • SSL_CK_RC4_128_WITH_MD5
    • SSL_CK_RC4_128_EXPORT40_WITH_MD5
    • SSL_CK_RC2_128_CBC_WITH_MD5
    • SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
    • SSL_CK_IDEA_128_CBC_WITH_MD5
    • SSL_CK_DES_64_CBC_WITH_MD5
    • SSL_CK_DES_192_EDE3_CBC_WITH_MD5

    Этот список не является исчерпывающим и может быть расширен в будущем. Конфигурации этих средств безопасности стандартизованы (см. табл. 6.5.1).

    Таблица 6.5.1

    Набор

    Уровень безопасности

    Описание

    DES-CBC3-MD5

    Очень высокий

    Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии

    DES-CBC3-SHA

    Очень высокий

    Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии

    RC4-MD5

    Высокий

    RC4, хэш MD5, 128-битный ключ

    RC4-SHA

    Высокий

    RC4, хэш SHA, 128-битный ключ

    RC2-CBC-MD5

    Высокий

    RC2 в режиме CBC, хэш MD5, 128-битный ключ

    DES-CBC-MD5

    Средний

    DES в режиме CBC, хэш MD5, 56-битный ключ

    DES-CBC-SHA

    Средний

    DES в режиме CBC, хэш SHA, 56-битный ключ

    EXP-DES-CBC-SHA

    Низкий

    DES в режиме CBC, хэш SHA, 40-битный ключ

    EXP-RC4-MD5

    Низкий

    Экспортное качество RC4, хэш MD5, 40-битный ключ

    EXP-RC2-CBC-MD5

    Низкий

    Экспортное качество RC2, хэш MD5, 40-битный ключ

    NULL-MD5

    -

    Без шифрования, хэш MD5, только аутентификация

    NULL-SHA

    -

    Без шифрования, хэш SHA, только аутентификация

    Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.

    Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.

    Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).

    Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY.

    SERVER-VERIFY (Фаза 1; посылается шифрованным)

    char MSG-SERVER-VERIFY
    char CHALLENGE-DATA[N-1]

    Сервер посылает это сообщение после пары ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY), согласованных посредством идентификатора сессии или явно через спецификацию сообщения CLIENT-MASTER-KEY. Сообщение содержит зашифрованную копию данных CHALLENGE-DATA, посланных клиентом в сообщении CLIENT-HELLO.

    "N" равен числу байт в сообщении, которое было послано, таким образом, "N-1" соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка.

    Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, который соответствует общедоступному ключу, содержащемуся в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY). Наконец, только сервер, который выполнил корректно извлечение и дешифрование может правильно зашифровать CHALLENGE-DATA. Это, по существу, "доказывает", что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера.

    Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает.

    Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю) или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED.

    SERVER-FINISHED (Фаза 2; посылается зашифрованным)
    char MSG-SERVER-FINISHED
    char SESSION-ID-DATA[N-1]

    Сервер посылает это сообщение, когда он удовлетворен результатом диалога с клиентом по поводу безопасности и готов продолжить передачу/прием протокольных данных верхнего уровня. Кэши идентификаторов сессии должны содержать копию MASTER-KEY, посланного в сообщении CLIENT-MASTER-KEY, в качестве мастерного ключа, предназначенного для генерации всех последующих ключей сессии.

    Здесь "N" имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVER-VERIFY.

    REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным)

    char MSG-REQUEST-CERTIFICATE
    char AUTHENTICATION-TYPE
    char CERTIFICATE-CHALLENGE-DATA[N-2]

    Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной ³ 16 байт и £ 32 байтам), которую клиент использует для отклика на этот запрос.

    Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:

    • SSL_AT_MD5_WITH_RSA_ENCRYPTION

    Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE.

    Это сообщение может быть послано после сообщения SERVER-VERIFY и до сообщения SERVER-FINISHED.

    6.5.2.7. Протокольные сообщения Клиент/Сервер

    Эти сообщения генерируются как клиентом, так и сервером.

    ERROR (посылается открыто или зашифровано)

    char MSG-ERROR
    char ERROR-CODE-MSB
    char ERROR-CODE-LSB

    Это сообщение посылается, когда обнаружена ошибка. После посылки сообщения, отправитель закрывает соединение. Получатель регистрирует ошибку и затем также разрывает соединение.

    Это сообщение посылается открыто, если произошла ошибка при согласовании ключа сессии. После того как ключ сессии согласован, сообщения об ошибках шифруются также как и обычные сообщения.

    Приложение A. ASN.1 синтаксис сертификатов

    Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [1]):

    X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
    signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }

    CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,

    serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
    issuer Name, validity Validity, subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo }

    Version ::= INTEGER { v1988(0) }
    CertificateSerialNumber ::= INTEGER
    Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }

    SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
    subjectPublicKey BIT STRING }

    AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
    parameters ANY DEFINED BY ALGORITHM OPTIONAL }
    Для целей SSL наложены ограничения на некоторые значения полей X.509:

    • Поля X.509-Certificate::signatureAlgorithm и CertificateInfo::signature должны иметь идентичные значения.
    • Имя эмитента сертификата должно преобразовываться в имя, которое приемлемо для приложения, использующего SSL.

    Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется.

    Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.

    Приложение B. Идентификаторы объектов и типов атрибутов

    SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.

    B.1. Выбранные типы атрибутов

    commonName { attributeType 3 }

    Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата.

    countryName { attributeType 6 }

    Название страны.

    localityName { attributeType 7 }

    Название местоположения.

    stateOrProvinceName { attributeType 8 }

    Название штата или провинции.

    organizationName { attributeType 10 }

    Название организации.

    organizationalUnitName { attributeType 11 }

    Название подразделения.

    B.2. Идентификаторы объекта

    md2withRSAEncryption { ... pkcs(1) 1 2 }

    Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата.

    md5withRSAEncryption { ... pkcs(1) 1 4 }

    Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата.

    rc4 { ... rsadsi(113549) 3 4 }

    Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.

    Приложение C. Значения протокольных констант

    Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443.

    C.1. Коды версии протокола

    #define SSL_CLIENT_VERSION 0x0002
    #define SSL_SERVER_VERSION 0x0002

    C.2. Коды протокольных сообщений

    Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL.

    #define SSL_MT_ERROR 0
    #define SSL_MT_CLIENT_HELLO 1
    #define SSL_MT_CLIENT_MASTER_KEY 2
    #define SSL_MT_CLIENT_FINISHED 3
    #define SSL_MT_SERVER_HELLO 4
    #define SSL_MT_SERVER_VERIFY 5
    #define SSL_MT_SERVER_FINISHED 6
    #define SSL_MT_REQUEST_CERTIFICATE 7
    #define SSL_MT_CLIENT_CERTIFICATE 8

    C.3. Коды сообщений об ошибках

    Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR.

    #define SSL_PE_NO_CIPHER 0x0001
    #define SSL_PE_NO_CERTIFICATE 0x0002
    #define SSL_PE_BAD_CERTIFICATE 0x0004
    #define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006

    C.4. Значения вида шифра

    Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO.

    #define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
    #define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
    #define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
    #define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
    #define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
    #define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
    #define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0

    C.5. Коды типа сертификата

    Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE.

    #define SSL_CT_X509_CERTIFICATE 0x01

    C.6. Коды типов аутентификации

    Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE.

    #define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01

    C.7. Верхние/нижние ограничения

    Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров.

    #define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
    #define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
    #define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
    #define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767
    #define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383

    Приложение D: Атаки

    В данном разделе описываются различные атаки, которые могут быть предприняты против протокола SSL. Этот перечень не может считаться исчерпывающим. SSL показал устойчивость к этим атакам.

    D.1. Раскрытие шифров

    SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA [5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным.

    Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.

    D.2. Атака открытого текста

    Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются зашифрованными. Атакующий может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Раз база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее.

    Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.

    Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно время емкий процесс.

    Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае не экспортного варианта).

    Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера".

    D.3. Атака отклика

    Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента.

    SSL отбивает эту атаку, с помощью специального кода "nonce" (идентификатор соединения), который является уникальным. Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий, неподвластных злоумышленнику и, следовательно, он не может реагировать адекватно на запросы сервера.

    Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

    D.4. Человек посередине

    Атака посредника (человек посередине) предполагает участие в коммуникационной сессии трех субъектов: клиента, сервера и посредника-злоумышленника, находящегося между ними. Такое положение позволяет злоумышленнику перехватывать все сообщения, следующие в обоих направлениях, и при желании подменять их.

    "Посредник" прикидывается сервером для клиента и клиентом для сервера. В случае SSL такая атака невозможна из-за использования сервером сертификатов. Во время диалога об установлении безопасного соединения с сервером необходимо предоставить сертификат, который подписан сертификационным центром. В этом сертификате размещается общедоступный ключ сервера, его имя и имя эмитента сертификата. Клиент верифицирует подпись сертификата, а затем проверяет имя эмитента.

    Если посредник предоставляет поддельный сертификат, то он не пройдет проверку подписи, так как злоумышленник не может знать секретного ключа сервера.

    Приложение E: Термины

    Прикладной протокол
    Прикладным протоколом является протокол, работающий поверх TCP/IP. Например: HTTP, TELNET, FTP и SMTP.

    Массовый шифр
    Массовые шифры используются, когда нужно за ограниченное время зашифровать/дешифровать большой объем данных. Примерами могут служить RC2, RC4 и IDEA.

    Клиент
    Клиентом считается приложение субъекта, который инициирует соединение с сервером.

    CLIENT-READ-KEY Ключ сессии, который использует клиент для инициализации своего шифра чтения. Этот ключ имеет то же значение, что и SERVER-WRITE-KEY.

    CLIENT-WRITE-KEY
    Ключ сессии, который использует клиент для инициализации своего шифра записи. Этот ключ имеет то же значение, что и SERVER-READ-KEY.

    Мастерный ключ
    Мастерный ключ, который используется клиентом и сервером для формирования всех ключей сессий. CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY генерируются на основе MASTER-KEY.

    MD2

    MD2 [8] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Эта функция является предшественницей MD5 [7] [9].

    MD5

    MD5 [7] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Функция имеет свойства, которые делают ее полезной при обеспечении конфиденциальности, главное из этих свойств - невозможность обратимости.

    Nonce
    Случайный код, который используется для предотвращения атак воспроизведения. Один партнер генерирует случайный код (nonce) и посылает его другому партнеру. Получатель шифрует его с помощью секретного ключа и возвращает отправителю. Так как nonce является случайным числом, злоумышленник не может предугадать его значение, что делает невозможной атаку воспроизведения. Получатель разрывает соединение, если обнаружит неверно зашифрованный код nonce.

    Регистрируемый информационный обмен
    Когда два партнера обмениваются информацией, бывает иногда важно иметь запись обмена, чтобы ни один из участников не мог утверждать, что он ничего такого не посылал. Версия 2 протокола SSL не поддерживает такой режим обмена.

    Шифрование общедоступным ключом
    Шифрование общедоступным ключом представляет собой метод асимметричного шифрования. Система с общедоступным ключом использует два ключа: общедоступный и секретный, которые образуют нерасторжимую пару. Сообщения шифруются общедоступным ключом, а дешифруются секретным. И наоборот, сообщения, зашифрованные секретным ключом, могут быть дешифрованы общедоступным ключом. Шифрование общедоступным ключом требует больших вычислительных ресурсов и по этой причине мало пригодно для массового шифрования.

    Конфиденциальность
    Конфиденциальность - это возможность двух участников обмениваться данными с гарантией того, что эти данные не станут достоянием третьей стороны. Конфиденциальность часто обеспечивается с помощью шифрования потока данных.

    RC2, RC4
    Массовые шифры, изобретенные RSA. RC2 является блочным шифром, а RC4 - поточным.

    Сервер

    Сервером считается приложение субъекта, которое реагирует на запросы установления соединения клиентов. Сервер является пассивным объектом, ожидающим запросов от клиентов.

    Шифр сессии

    Шифр сессии является массовым шифром, который пригоден для шифрования или дешифрования произвольного объема данных. Шифры сессии используются в основном по причинам их высоких эксплуатационных характеристик (прежде всего, имеется в виду быстродействие). Шифры сессии, используемые этим протоколом, симметричны. Симметричные шифры предполагают применение одного и того же ключа, как для шифрования, так и дешифрования.

    Идентификатор сессии

    Идентификатор сессии является случайным числом, генерируемым клиентом, который идентифицирует таким способом себя серверу. Идентификатор сессии может рассматриваться как средство доступа обоих участников к записанному секретному ключу (в нашем случае к ключу сессии). Если оба партнера помнят идентификатор сессии, тогда считается, что секретный ключ известен и его не нужно согласовывать.

    Ключ сессии
    Ключ шифра сессии. В SSL существует четыре ключа, которые называются ключами сессии: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY.

    SERVER-READ-KEY
    Ключ сессии, который используется сервером для инициализации шифра чтения сервера. Этот ключ имеет то же значение что и CLIENT-WRITE-KEY.

    SERVER-WRITE-KEY
    Ключ сессии, который используется сервером для инициализации шифра записи сервера. Этот ключ имеет то же значение что и CLIENT-READ-KEY.

    Симметричный шифр
    Симметричный шифр используется как для шифрования, так и для дешифрования. Примерами симметричных шифров могут служить: IDEA, RC2, RC4.

    Ссылки

    [1]

    CCITT. Recommendation X.208: "Specification of Abstract Syntax Notation One (ASN.1). 1988.

    [2]

    CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

    [3]

    CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.

    [4]

    CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988.

    [5]

    RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.

    [6]

    RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993.

    [7]

    R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.

    [8]

    R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992.

    [9]

    B. Schneier. Applied Cryptography: Protocols, Algorithms, и Source Code in C, Published by John Wiley & Sons, Inc. 1994.

    [10]

    M. Abadi и R. Needham. Prudent engineering practice for cryptographic protocols. 1994.

    Патентное заявление

    Эта версия протокола SSL базируется на использовании патентованной технологии шифрования с общедоступным ключом, которая служит для аутентификации и шифрования/дешифрования. Процесс стандартизации в Интернет, определенный в RFC 1310, требует письменного заявления от владельца патента, что лицензия предоставляется пользователям на определенных, приемлемых условиях, прежде чем рекомендации будет одобрены в качестве предложения, проекта или стандарта Интернет.

    Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты:

    Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770
    Устройство и метод для криптографии с общедоступным ключом (Hellman-Merkle) No. 4,218,582
    Криптографическая коммуникационная система и метод (RSA) No. 4,405,829
    Устройство и метод экспоненциальной криптографии (Hellman-Pohlig) No. 4,424,414

    Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля.

    Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority).

    Previous: 6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.6 Безопасное ядро (SSH)


    previous up down next index index
    Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.7 Безопасность WEB-серверов

    6.6 Безопасное ядро (SSH)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены "посторонние" машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа "безопасное ядро" SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытого ключа так и симметричной схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата.

    Для формирования SSH-прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию -L:

    SSH -L5678:www.pod.potol.com:80 www.pod.potol.com

    Аргумент, следующий после флага опции -L имеет формат:

    <локальный порт>:<удаленная ЭВМ>:<удаленный порт>.

    Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure.

    Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.7 Безопасность WEB-серверов


    previous up down next index index
    Previous: 6.6 Безопасное ядро (SSH)    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.8 Протокол TLS версия 1.0

    6.7 Безопасность WEB-серверов
    Семенов Ю.А. (ГНЦ ИТЭФ)

    WEB-сервер достаточно сложная и потому уязвимая для атак программа. Причем угрозы могут исходить из самых неожиданных мест. Так в конце июня 1997 года было обнаружено, что Windows-95 (и NT) "повисает" (полный перечень причин повисания этой системы может занять целый том) при приходе на ее вход ICMP-пакета с длиной, которая не соответствует значению, указанному в его поле заголовка Длина.

    WEB-сервер, также как любая сеть должен иметь свою, желательно записанную на бумаге политику безопасности. Это должен быть достаточно простой документ типа приведенного ниже.

    Доступ к WEB-серверу имеет пять уровней:

    1. Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private.
    2. Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private.
    3. Разработчики WEB-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера.
    4. Администраторы узла (сервера). Имеют те же привилегии, что и разработчики, но могут также реконфигурировать сервер и определять категорию доступа.
    5. Системные администраторы. Имеют идентичные привилегии с администраторами сервера.

    Для получения доступа на уровне 3-5 необходимо письменное разрешение директора организации или его заместителя по информационным системам. Доступ уровня 2 автоматически получают все сотрудники организации или фирмы при авторизации. Администраторы могут аннулировать авторизацию по решению заместителя директора по информационным системам, а при чрезвычайных обстоятельствах самостоятельно, но с последующим уведомлением руководства. Работа с локальной консоли WEB-сервера разрешается только администраторам. Удаленная работа администраторам запрещена, они должны работать только с локального терминала. CGI-скрипты устанавливаются на сервер после их проверки и одобрения как минимум двумя членами группы администраторов. Скрипты, исходные тексты которых недоступны, устанавливаются только по решению заместителя директора по информационным системам.

    Информация из каталогов /private, которая считается конфиденциальной, доступна только с терминала самой ЭВМ.

    При работе с WEB-сервером не допускается доступ к базам данных или файлам, если для этого не имеется соответствующего разрешения.

    Описание политики безопасности должно включать указание периода формирования резервных копий содержимого сервера, описания допустимых сетевых услуг и время профилактических остановок. Включается сюда перечень видов обязательного мониторинга сервера и просмотра дневника посещений.

    Приведенный текст описания политики безопасности может варьироваться в широких пределах, он зависит от используемой ОС и набора сетевых утилит.

    Наиболее безопасной сетевой средой считается Macintosh OS. Это связано с тем, что она не включает в себя интерпретатора команд, не поддерживает скрипты и не предоставляет каких-либо дополнительных сетевых услуг, неавторизованный просмотр WEB-страниц на Макинтоше практически не возможен.

    Системы Windows NT и UNIX обладают сопоставимыми и достаточно высокими уровнями безопасности. Большое число сообщений о дефектах безопасности UNIX свидетельствует о его массовом использовании.

    Теперь рассмотрим, что нужно сделать, чтобы обеспечить максимально возможную безопасность WEB-cервера.

    • Выбрать наиболее безопасную ОС и сконфигурировать ее с учетом требования безопасности. Использовать все известные корректирующие программы, выпущенные разработчиком ОС.
    • Организовать мониторирование любой подозрительной активности на сервере (активность в ночное время, многократные попытки авторизации и т.д.).
    • Контролировать доступ к конфиденциальным документам. Доступ к таким документом должен быть разрешен только ограниченному числу пользователей. Доступ к таким частям сервера должен быть организован с использованием протокола SSL.
    • Тщательно разрабатывать и проверять используемые CGI-скрипты и аплеты.
    • Установить жесткие требования к доступу для выполнения различных операций, особенно для модификации содержимого и конфигурации сервера.
    • Защитить локальную сеть от WEB-сервера. Исключить возможность проникновения к жизненно важным ресурсам сети через WEB-сервер, например, с помощью Firewall.
    • Отслеживать вновь обнаруженные слабости используемой ОС и программного обеспечения сервера. Делайте это чаще, если вам не безразлична безопасность вашего сервера, не надейтесь, что все хакеры ленивее вас. Ссылки на различные серверы, где публикуется такая информация, можно найти в конце раздела 6.

    При работе с ОС Windows NT следует отключить доступ TCP/IP от услуг NETBIOS. Это может быть сделано с помощью Firewall, блокировкой доступа к портам 137 и 138 для UDP и TCP. Можно решить эту проблему отключения NETBIOS от TCP/IP драйвера переконфигурировав Windows NT.

    Если WEB-сервер нуждается в контроле доступа, то в настоящее время (в HTTP/1.1) имеется две возможности. Первая (basic) - предполагает традиционный ввод и передачу по сети имени клиента и пароля. Эта схема проста, но допускает перехват параметров доступа (а между клиентом и сервером может быть достаточно много промежуточных узлов). Вторая схема (digest) для пользователя выглядит аналогично, но вводимое имя и пароль не передаются по сети непосредственно. На их базе формируется дайджест MD5, который пересылается по сети и используется для идентификации клиента.

    Previous: 6.6 Безопасное ядро (SSH)    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.8 Протокол TLS версия 1.0


    previous up down next index index
    Previous: 6.7 Безопасность WEB-серверов    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.9 Квантовая криптография

    6.8 Протокол TLS версия 1.0
    Семенов Ю.А. (ГНЦ ИТЭФ)

    'The TLS Protocol Version 1.0'. T. Dierks, C. Allen. January 1999. RFC-2246.

    1. Введение

    Первоначальной целью протокола TLS (Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (напр., TCP [TCP]), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:

    • Соединение является конфиденциальным. Для шифрования данных используется симметричная криптография (напр., DES [DES], RC4 [RC4], и т.д.). Ключи для шифрования генерируются независимо для каждого соединения и базируются на секретном коде, получаемом с помощью другого протокола (такого как протокол диалога TLS). Протокол записей может использоваться и без шифрования.
    • Соединение является надежным. Процедура передачи сообщения включает в себя проверку целостности с помощью вычисления MAC. Для расчета >MAC используются хэш-функции (напр., SHA, MD5 и т.д.). Протокол записей может работать и без MAC, но в этом режиме он применяется только в случае, когда другой протокол использует протокол записей в качестве транспортного при выяснении параметров безопасности.

    Протокол записей TLS используется для инкапсуляции различных протоколов высокого уровня. Один из таких инкапсулируемых объектов, протокол диалога TLS, позволяет серверу и клиенту аутентифицировать друг друга и согласовать алгоритм шифрования и крипто-ключи до того как приложение передаст или примет первый байт информации. Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три базовых свойства:

    • Идентичность партнеров может быть выяснена с использованием асимметричной криптографии (напр., RSA [RSA], DSS [DSS] и т.д.). Эта аутентификация может быть сделана опционной, но она необходима, по крайней мере, для одного из партнеров.
    • Выявление общего секретного кода является безопасным: этот секретный код недоступен злоумышленнику, даже если он ухитрится подключиться к соединению.
    • Диалог надежен: атакующий не может модифицировать обсуждаемое соединение, без того чтобы быть обнаруженным партнерами обмена.

    Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы верхнего уровня могут размещаться поверх протокола TLS прозрачным образом. Стандарт TLS, однако, не специфицирует то, как протоколы увеличивают безопасность с помощью TLS; решение о том, как инициализировать TLS-диалог и как интерпретировать сертификаты аутентификации, оставляется на усмотрение разработчиков протоколов и программ, которые работают поверх TLS.

    2. Цели

    Целями протокола TLS в порядке приоритетности являются:

    1. Криптографическая безопасность. TLS должен использоваться для установления безопасного соединения между двумя партнерами.
    2. <
    3. Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга.
    4. Расширяемость. TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность.
    5. Относительная эффективность. Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине, протокол TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность.

    3. Цели данного документа

    Этот документ и сам протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0). Этот документ предназначен, прежде всего, для читателей, которые будут создавать протокольные приложения, и осуществлять их криптографический анализ. Спецификация была написана именно с такими намерениями и именно для этих двух групп разработчиков. Для этой цели многие правила и структуры данных, зависимые от алгоритма, включены в текст (а не в приложение), обеспечивая более легкий к ним доступ.

    4. Язык представления

    Представление данных в этом документе напоминает синтаксис языка Си и XDR [XDR], но эти параллели достаточно приблизительны и не имеют никакого отношения к самому протоколу TSL. эти представления применены лишь для целей упрощения восприятия материала.

    4.1. Базовый размер блока

    Базовым блоком данных считается один байт (т.e. 8 бит). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си) следующим образом:

    value = (байт[0] << 8*(n-1)) | (байт[1] << 8*(n-2)) | ... | байт[n-1];

    Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian).

    4.2. Разное

    Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "[[ ]]". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют 'непрозрачный' тип (opaque).

    4.3. Векторы

    Вектор (одномерный массив) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T', который является вектором фиксированной длины типа T, имеет вид T T'[n];

    Здесь T' занимает в информационном потоке n байт, где <n кратно размеру T. Длина вектора не включается в кодированный поток.

    В следующем примере Datum определен, как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum, состоящие из девяти байт.

    opaque Datum[3];

    /* три не интерпретируемые байта */

    Datum Data[9];

    /* 3 последовательных 3-байтовых вектора */

    Векторы переменной длины определяются путем спецификации субдиапазона легальных длин, используя нотацию . При кодировании реальная длина предшествует потоку байтов, образующих вектор. Длина имеет форму числа, занимающего столько байт, сколько нужно, чтобы специфицировать максимально возможную длину вектора (ceiling). Вектор переменной длины с действительным полем длины равным нулю является пустым вектором.

    T T';

    В следующем примере, обязательным является вектор, который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16, достаточных, чтобы представить значение 400 (смотри раздел 4.4). С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор. Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным).

    opaque mandatory<300..400>;

    /* поле длины имеет 2 байта, не может быть пустым */

    uint16 longer <0..800>;

    /* 0 - 400 16-битовое целое число без знака */

    4.4. Числа

    Базовый числовой тип данных представляет собой байт без знака (uint8). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе, как это описано в разделе 4.1,. Следующие числовые типы являются предопределенными.

    uint8 uint16[2];
    uint8 uint24[3];
    uint8 uint32[4];
    uint8 uint64[8];

    Все значения здесь и в дальнейшем записываются в 'сетевом порядке' (big-endian); uint32 представленное шестнадцатеричными байтами 01 02 03 04 эквивалентно десятичному значению 16909060.

    4.5. Нумерованный тип

    Еще одним типом данных является enum (enumerated). Поле типа enum предполагает, что величина декларирована при определении. Каждое определение дает новый тип. Только нумерованные элементы того же типа могут присваиваться и сравниваться. Каждому нумерованному элементу должно быть присвоено значение, как это показано в следующем примере. Так как нумерованные элементы неупорядочены, им может быть присвоено любое уникальное значение в любом порядке.

    enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

    Нумерованные элементы занимают в байтовом потоке столько места, сколько требует максимальное определенное порядковое значение. Следующее определение требует использования одного байта для поля типа Color (цвет).

    enum { red(3), blue(5), white(7) } Color;

    Можно опционно специфицировать значение без ассоциированной с ним метки, чтобы задать ширину без определения избыточного элемента. В следующем примере, Taste в потоке данных занимает два байта, но может предполагать значения 1, 2 или 4.

    enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

    Имена элементов нумерации собраны в пределах определенного типа. В первом примере, полная ссылка на второй элемент будет выглядеть как Color.blue. Такое описание не требуется, если объект присвоения (target) хорошо специфицирован.

    Color color = Color.blue;

    /* чрезмерная спецификация, допустимо */

    Color color = blue;

    /* правильно, тип задан неявно */

    Для нумерованных элементов, которые не преобразуются во внешнее представление, цифровая информация может быть опущена.

    enum { low, medium, high } Amount;

    4.6. Сконструированные типы

    Типы структуры могут быть сформированы для удобства из примитивных типов. Каждая спецификация декларирует новый, уникальный тип. Синтаксис определения весьма похож на используемый в Си.

    struct {

    T1 f1;

    T2 f2;

    ...

    Tn fn;} [[T]];

    Поля в структуре могут быть квалифицированы, используя имена типов, которые синтаксис подобный нумерованным элементам. Например, T.f2 относится ко второму полю предыдущей декларации. Структурные определения допускают вложения.

    4.6.1. Варианты

    Определенные структуры могут иметь варианты, базирующиеся на некотором знании того, что доступно в среде. Селектор должен иметь тип нумерованного элемента, который определяет возможные варианты структуры. Телу структуры варианта может быть присвоена метка для ссылок. Механизм, с помощью которого при работе выбирается вариант, языком презентации не определен.

    struct {

    T1 f1;

    T2 f2;

    ....

    Tn fn;

    select (E) {

    case e1: Te1;

    case e2: Te2;

    ....

    case en: Ten;

    } [[fv]];} [[Tv]];

    Например:

    enum { apple, orange } VariantTag;
    struct {

    uint16 number;

    opaque string<0..10>; /* переменная длина */

    } V1;

    struct {

    uint32 number;

    opaque string[10]; /* фиксированная длина */

    } V2;

    struct {

    select (VariantTag) {

    /* value of selector is implicit */

    case apple: V1;

    /* VariantBody, tag = apple */

    case orange: V2;

    /* VariantBody, tag = orange */

    } variant_body;

    /* optional label on variant */

    } VariantRecord;

    Структуры варианта могут быть подготовлены (сужены) путем спецификации значения селектора до спецификации типа. Например: orange VariantRecord является суженным типом для VariantRecord, содержащего variant_body типа V2.

    4.7. Криптографические атрибуты

    В TSL используются четыре криптографические операции: цифровая подпись, блочное и поточное шифрование и шифрование с помощью общедоступного ключа. Криптографические ключи соответствуют состоянию текущей сессии (смотри раздел 6.1).

    Алгоритм цифровой подписи включает в себя однопроходные хэш-функции, служащие для преобразования подписываемого текста. Элемент с цифровой подписью кодируется как непрозрачный вектор <0..216-1>, где длина специфицируется алгоритмом подписи и ключом.

    В подписи RSA, 36-байтовая структура двух хэшей (один SHA и один MD5) кодируется с помощью секретного ключа. Описание кодировки смотри в [PKCS1].

    В DSS, 20 байтов хэша SHA передаются непосредственно алгоритму цифровой подписи DSA (Digital Signing Algorithm) без дополнительного хэширования. В результате получаются числа r и s. Подпись DSS представляет собой непрозрачный вектор, содержимое которого представляет собой результат DER-кодирования:

    DssSigValue ::= SEQUENCE {

    r

    INTEGER,

    s

    INTEGER}

    При поточном шифровании, исходный текст сначала объединяется с псевдослучайным кодом идентичной длины (формируется специальным генератором) с помощью операции исключающее ИЛИ.

    При использовании блочного шифра, каждый блок исходного текста преобразуется в зашифрованный кодовый блок той же длины. Все блочные шифрования выполняются в режиме CBC (Cipher Block Chaining), и все зашифрованные блочные элементы будут иметь размер, кратный длине шифрового блока.

    При шифровании с использованием общедоступного ключа, алгоритм открытого ключа используется для шифрования данных так, чтобы их можно было дешифровать только с помощью секретного ключа, который образует пару с открытым ключом. Элемент, зашифрованный с помощью открытого ключа, выглядит как непрозрачный вектор <0..216-1>, где длина определяется алгоритмом подписи и ключом.

    В следующем примере:

    stream-ciphered struct {

    uint8 field1;

    uint8 field2;

    digitally-signed opaque hash[20];} UserType;

    Содержимое хэша передается алгоритму подписи, затем вся структура шифруется с привлечением поточного шифра. Длина этой структуры в байтах будет равна 2 байтам для поля field1 и field2, плюс два байта для длины подписи, плюс длина выходных данных алгоритма подписи. Это известно благодаря тому факту, что алгоритм и ключ для подписи известны до кодирования или декодирования этой структуры.

    4.8. Константы

    Типофицированные константы могут быть определены для целей спецификации путем декларации символа нужного типа и присвоения ему определенных значений. Не полностью специфицированные типы (непрозрачные элементы, векторы переменной длины, и структуры, которые содержат непрозрачные элементы) не могут стать объектами присвоения. Нельзя опускать ни одно поле многоэлементной структуры или вектора.

    Например,

    struct { uint8 f1; uint8 f2;} Example1;

    Example1 ex1 = {1, 4};

    /* assigns f1 = 1, f2 = 4 */

    5. HMAC и псевдослучайные функции

    Ряд операций на уровне записей и диалога требуют ключевого MAC; это дайджест определенных данных, защищенных секретным кодом. Фальсификация MAC невозможна без знания секретного кода. Конструкция, которая используется для этой операции, имеет название HMAC и описана в [HMAC].

    HMAC может использоваться с разными хэш-алгоритмами. TLS использует ее при диалоге с другими алгоритмами: MD5 и SHA-1, обозначая их как HMAC_MD5(secret, data) и HMAC_SHA(secret, data). Для других шифровых наборов и защищенных данных могут быть определены дополнительные хэш-алгоритмы, но в данной версии протокола для целей диалога жестко заданы MD5 и SHA-1.

    Кроме того, необходима схема расширения применения секретных кодов (secret) на блоки данных с целью генерации ключей и валидации. Такая псевдослучайная функция (PRF) использует в качестве входной информации секретный код, порождающий код (seed) и идентификационную метку (label). При этом формируется выходной массив произвольной длины.

    Для того чтобы сделать PRF максимально секретной, она использует два хэш-алгоритма так, чтобы гарантировать секретность при сохранении работоспособности хотя бы одного из них.

    Сначала, определена функция разложения данных, P_hash(secret, data), которая использует одну хэш функция для распространения секретного кода на произвольное число выходов:

    P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +

    HMAC_hash(secret, A(2) + seed) +

    HMAC_hash(secret, A(3) + seed) + ...

    где + обозначает объединение.
    A() определено как:

    A(0) = seed

    A(i) = HMAC_hash(secret, A(i-1))

    Для требуемого качества данных P_hash может итерироваться столько раз, сколько нужно. Например: если P_SHA-1 использовался для формирования 64 байт данных, его следует итерировать четыре раза (до A(4)), создавая 80 байт выходных данных; последние 16 байт последней итерации будут отброшены, оставляя 64 байта.

    PRF TLS создана путем расщепления секретного кода на две части и использования одной половины для генерации данных с помощью P_MD5, а другой половины - для формирования данных посредством P_SHA-1, выходные данных этих двух процедур объединяются затем с помощью операции исключающего ИЛИ.

    S1 и S2 являются двумя равными по длине половинами секретного кода. Их длина определяется путем округления результата деления исходного секретного кода на два. Таким образом, если исходный секретный код имеет длину в байтах, характеризуемую нечетным числом, то последний байт S1 будет тем же, что и первый байт S2.

    L_S = длина секретного кода в байтах;
    L_S1 = L_S2 = ceil(L_S / 2);

    PRF определяется как результат смешения двух псевдослучайных потоков с помощью операции исключающее ИЛИ.

    PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);

    Метка представляет собой ASCII-строку. Она должна быть включена в исходном виде без байта длины или завершающего нуля. Например: метка "slithy toves" будет представлена в виде:

    73 6C 69 74 68 79 20 74 6F 76 65 73

    Заметим, что, так как MD5 выдает на выход 16 байт, а SHA-1 - 20 байт, границы их внутренних итераций не будут выровнены; чтобы сформировать на выходе 80 байт P_MD5 осуществит итерации до A(5), в то время как P_SHA-1 - до A(4).

    6. Протокол записей TLS

    Протокол записей TLS является послойным. На каждом уровне, сообщения могут включать поля длины, описания и содержимого. Протокол записей берет сообщения, подлежащие пересылке, разбивает их на блоки, опционно сжимает данные, применяет MAC, шифрует и передает результат. Полученные данные дешифруются, верифицируются, декомпрессируются, восстанавливается их первоначальный вид, результат передается клиентам верхнего уровня.

    Четыре протокола описаны в данном документе: протокол диалога, протокол уведомления, протокол спецификации изменения шифра, и прикладной информационный протокол. Для того чтобы позволить расширение протокола TLS, разрешена поддержка протоколом дополнительных типов записей. Любые новые типы записей должны размещать значения типа немедленно за величинами ContentType четырех типов, описанных здесь (смотри Приложение A.2). Если реализация TLS получает рекорд нераспознаваемого типа, она должна его игнорировать. Любой протокол, предназначенный для использования поверх TLS, должен быть тщательно сконфигурирован, для того чтобы противостоять любым атакам. Заметим, что из-за того, что тип и длина записи не защищены шифрованием, следует принимать меры, чтобы минимизировать трафик анализа этих величин.

    6.1. Состояния соединений

    Состояние соединения TLS является операционной средой протокола записей TLS. Оно специфицирует алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов: секретный код MAC, а также ключи шифрования и IV соединения для направлений чтения и записи. Логически существует четыре состояния соединения: текущие состояния чтения и записи, и отложенные состояния чтения и записи. Все записи обрабатываются в текущих состояниях чтения или записи. Параметры безопасности для отложенных состояний могут быть установлены протоколом диалога TLS. Протокол диалога может селективно переводить любое отложенное состояние в текущее, при этом соответствующее текущее состояние становится отложенным. Не допускается формировать состояние, которое не инициализировано с учетом параметров безопасности текущего состояния. Исходное текущее состояние всегда специфицировано без компрессии, шифрования или MAC. Параметры безопасности для состояния чтения и записи соединения TLS задаются путем определения следующих величин:

    Конец соединения

    Клиент или сервер участник соединения.

    Алгоритм массового шифрования

    Алгоритм, используемый для массового шифрования. Эта спецификация включает размер ключа алгоритма, степень секретности ключа, является ли этот шифр блочным или поточным, размер блока и является ли шифр экспортным.

    Алгоритм MAC

    Алгоритм аутентификации сообщений. Эта спецификация включает размер хэша, который возвращается алгоритмом MAC.

    Алгоритм сжатия

    Алгоритм сжатия данных. Эта спецификация должна включать всю информацию, необходимую для выполнения компрессии.

    Секретный код сервера (master secret)

    48 байтовый секретный код, общий для обоих партеров в соединении.

    Случайный код клиента

    32 байтный код, предоставляемый клиентом.

    Случайный код сервера

    32 байтный код, предоставляемый сервером.

    Эти параметры определены в языке представления в виде:

    enum { server, client } ConnectionEnd;
    enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
    enum { stream, block } CipherType;
    enum { true, false } IsExportable;
    enum { null, md5, sha } MACAlgorithm;
    enum { null(0), (255) } CompressionMethod;

    /* Алгоритмы, специфицированные в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm могут быть добавлены. */

    struct {

    ConnectionEnd

    entity;

    BulkCipherAlgorithm

    bulk_cipher_algorithm;

    CipherType

    cipher_type;

    uint8

    key_size;

    uint8

    key_material_length;

    IsExportable

    is_exportable;

    MACAlgorithm

    mac_algorithm;

    uint8

    hash_size;

    CompressionMethod

    compression_algorithm;

    Opaque

    master_secret[48];

    opaque

    client_random[32];

    opaque

    server_random[32];} SecurityParameters;

    Уровень записей будет использовать параметры безопасности для формирования следующих шести объектов:

    Секретный код MAC записи клиента
    >Секретный код MAC записи сервера
    >Ключ записи клиента
    Ключ записи сервера
    IV записи клиента (только для блочного шифра)
    IV записи сервера (только для блочного шифра)

    Параметры записи клиента используются сервером при получении и обработке записей и наоборот. Алгоритм, использованный для генерирования этих объектов с помощью параметров безопасности, описан в разделе 6.3. Раз параметры безопасности определены и ключи сформированы, состояния соединения могут быть в любой момент реализованы путем перевода их в текущее состояние. Эти текущие состояния должны актуализоваться после обработки каждой записи. Каждое состояние соединения включает в себя следующие элементы:

    Состояние сжатия

    Текущее состояние алгоритма сжатия.

    Состояние шифра

    Текущее состояние алгоритма шифрования. Оно состоит из текущего ключа для данного соединения. Кроме того, для блочного шифра, работающего в режиме CBC (единственный режим, специфицированный в TLS), оно в исходный момент содержит IV для данного состояния соединения и должно актуализоваться, чтобы содержать текст последнего шифрованного или дешифрованного блока. Для поточных шифров, оно содержит всю необходимую информацию для продолжения шифрования или дешифрования данных.

    Секретный код MAC

    Секретный код MAC для данного соединения.

    Номер по порядку

    Каждое состояние соединения содержит номер по порядку, который поддерживается независимо для состояний чтения и записи. Номер по порядку должен быть установлен равным нулю, как только соединение переведено в активное состояние. Номера по порядку имеют тип uint64 и не может превышать 264-1. Номер по порядку инкрементируется после прихода каждой записи: в частности, первая запись, передаваемая через некоторое соединение, имеет порядковый номер 0.

    6.2. Уровень записей

    Уровень записей TLS получает не интерпретированные данные от верхних уровней в непустых блоках произвольного размера.

    6.2.1. Фрагментация

    Уровень записей фрагментирует информационные блоки и превращают их в записи TLSPlaintext, несущие данные в виде последовательностей длиной 214 байтов или меньше. Границы сообщения клиента на уровне записей не сохраняются (т.e., несколько сообщений клиента одного и того же ContentType могут быть объединены в одну запись TLSPlaintext, или одно сообщение может быть фрагментировано).

    struct { uint8 major, minor;} ProtocolVersion;

    enum

    { change_cipher_spec(20), alert(21), handshake(22),

    application_data(23), (255)

    } ContentType;

    struct { ContentType type;

    ProtocolVersion version;

    uint16 length;

    opaque fragment[TLSPlaintext.length];

    } TLSPlaintext;

    type

    Протокол верхнего уровня, использованный для обработки вложенного фрагмента .

    version

    Версия примененного протокола. В данном документе описывается TLS версии 1.0, который использует версию { 3, 1 }. Значение версии 3.1 является исторической: TLS версии 1.0 является минимальной модификацией протокола SSL 3.0, который несет значение версии 3.0. (Смотри приложение A.1).

    length

    Длина (в байтах) следующего TLSPlaintext.fragment. Длина не должна превосходить 214.

    Fragment

    Прикладные данные. Эти данные прозрачны и обрабатываются как независимые блоки, с которыми должен работать протокол верхнего уровня, который специфицирован полем тип.

    Данные различных типов содержимого уровня записей TLS могут перекрываться. Прикладные данные вообще имеют более низкий приоритет при передаче, чем другие типы содержимого.

    6.2.2. Сжатие и восстановление записи

    Все записи сжаты с использованием алгоритма сжатия, определенным состоянием текущей сессии. Всегда имеется активный алгоритм сжатия; однако в исходный момент он определен как CompressionMethod.null. Алгоритм сжатия преобразует структуру TLSPlaintext в структуру TLSCompressed. Функции сжатия инициализируются информацией по умолчанию при переходе соединения в активное состояние.

    Должно использоваться сжатие без потерь, а длина содержимого не может стать больше чем 1024 байт. Если функция восстановления встречает фрагмент TLSCompressed.fragment, длина которого окажется больше 214 байт, она должна выдать уведомление о фатальной ошибке преобразования.

    Struct

    { ContentType type;

    /* то же самое, что и TLSPlaintext.type */

    ProtocolVersion version;

    /* то же самое, что и TLSPlaintext.version */

    uint16 length;

    opaque fragment[TLSCompressed.length];

    } TLSCompressed;

    length

    Длина (в байтах) следующего TLSCompressed.fragment. Длина не должна превосходить 214 + 1024.

    Fragment

    Сжатая форма TLSPlaintext.fragment.

    Операция CompressionMethod.null является идентификационной; ни одно из полей не изменено.

    Функции декомпрессии (восстановления) отвечают за то, что внутренний буфер не будет переполнен при обработке сообщения.

    6.2.3. Защита поля данных записи

    Функции шифрования и MAC преобразуют структуру TLSCompressed в TLSCiphertext. Функции дешифрования выполняют обратную процедуру. MAC записи включает также номер по порядку, чтобы было можно детектировать лишние или повторные сообщения.

    Struct

    { ContentType type;

    ProtocolVersion version;

    uint16 length;

    select (CipherSpec.cipher_type) {

    case stream: GenericStreamCipher;

    case block: GenericBlockCipher; } fragment;

    } TLSCiphertext;

    type

    Поле тип идентично TLSCompressed.type.

    Version

    Поле версия идентично TLSCompressed.version.

    length

    Длина (в байтах) последующего TLSCiphertext.fragment. Длина не может превосходить 214 + 2048.

    Fragment

    Зашифрованная форма TLSCompressed.fragment, с MAC.

    6.2.3.1. Нуль или стандартный поточный шифр

    Поточные шифры (включая BulkCipherAlgorithm.null - смотри приложение A.6) преобразуют структуры TLSCompressed.fragment в (или из) структуры TLSCiphertext.fragment.

    stream-ciphered struct { opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];} GenericStreamCipher;

    MAC генерируется как:

    HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
    TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

    где "+" означает объединение (слияние).

    seq_num

    Номер по порядку для данной записи.

    hash

    Алгоритм хэширования, специфицированный в SecurityParameters.mac_algorithm.

    Заметим, что MAC вычисляется до шифрования. Поточный шифр преобразует весь блок, включая MAC. Для поточных шифров, которые не используют вектор синхронизации (такой как RC4), состояние шифра записи используется в последующих пакетах. Если CipherSuite равен TLS_NULL_WITH_NULL_NULL, шифрование представляет собой операцию идентичного преобразования (т.e., данные не шифруются, а размер MAC равен нулю, что говорит о том, что MAC не используется). TLSCiphertext.length равна TLSCompressed.length плюс CipherSpec.hash_size.

    6.2.3.2. Блочный шифр CBC

    Для блочных шифров (таких как RC2 или DES), функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в блоки структур TLSCiphertext.fragment или обратно.

    block-ciphered struct {

    opaque content[TLSCompressed.length];

    opaque MAC[CipherSpec.hash_size];

    uint8 padding[GenericBlockCipher.padding_length];

    uint8 padding_length;

    } GenericBlockCipher;

    MAC генерируется, как это описано в разделе 6.2.3.1.

    Padding

    Заполнитель, который добавлен, чтобы сделать длину исходного текста целой кратной длине блока блочного шифра. Заполнитель может иметь длину вплоть до 255 байт. Длины больше необходимой могут оказаться желательными, для того чтобы блокировать атаки на протокол, базирующийся на анализе длин сообщений. Каждый uint8 в векторе заполняющих данных должен быть заполнен значением длины.

    padding_length

    Длина заполнения должна быть такой, чтобы общий размер структуры GenericBlockCipher являлся кратным длине блока шифра. Диапазон легальных значений лежит в диапазоне 0-255, включительно. Эта длина специфицирует длину поля заполнителя, исключая само поле padding_length.

    Длина шифрованных данных (TLSCiphertext.length) на единицу больше чем сумма TLSCompressed.length, CipherSpec.hash_size и padding_length.

    Пример. Если длина блока равна 8 байт, длина содержимого (TLSCompressed.length) равна 61 байтов, а длина MAC равна 20 байтов, длина до заполнения составляет 82 байта. Таким образом, длина заполнения по модулю 8 должна быть равна 6, для того чтобы сделать полную длину четной, кратной 8 байтам (длина блока). Длина заполнения может быть 6, 14, 22 и т.д. до 254. Если бы длина заполнения была минимально необходимой (6), заполнитель имел бы 6 байтов, каждый из которых содержал число 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования были бы xx 06 06 06 06 06 06 06, где xx последний октет MAC.

    Для блочного шифра в режиме CBC (Cipher Block Chaining) вектор инициализации (IV) для первой записи генерируется с другими ключами и секретными кодами, когда параметры безопасности заданы. IV для последующих записей равен последнему блоку шифрованного текста предыдущей записи.

    6.3. Вычисление ключа

    Протокол записей требует алгоритма для генерации ключей, IV и секретных кодов MAC из параметров безопасности, поставляемых протоколом диалога.

    Мастерный секретный код (master secret) хэшируется в последовательность байтов, которая присваивается секретным кодам MAC, ключам и IV, требуемых текущим состоянием соединения (смотри приложение A.6). CipherSpecs требует чтобы клиент записал секретный код MAC, чтобы сервер записал секретный код MAC, клиент и сервер записали ключ и IV, которые сформированы из мастерного секретного кода в указанном порядке. Не использованные значения остаются пустыми.

    Для генерации ключей вычисляется

    key_block = PRF(SecurityParameters.master_secret, "key expansion",
    SecurityParameters.server_random + SecurityParameters.client_random);

    до тех пор пока не будет сформирован выход. Затем key_block позиционируется следующим образом:

    client_write_MAC_secret[SecurityParameters.hash_size]
    server_write_MAC_secret[SecurityParameters.hash_size]
    client_write_key[SecurityParameters.key_material_length]
    >server_write_key[SecurityParameters.key_material_length]
    client_write_IV[SecurityParameters.IV_size]
    server_write_IV[SecurityParameters.IV_size]

    Значения client_write_IV и server_write_IV генерируются только для не экспортных блочных шифров. Для экспортируемых блочных шифров, векторы инициализации генерируются позже, как это описано ниже. Любой лишний материал key_block отбрасывается.

    Спецификация шифра, которая определена в данном документе, требует 2 x 24 байтовых ключей, 2 x 20 байтовых секретных кодов MAC, и 2 x 8 байтов IV, для 104 байтов материала ключей.

    Алгоритмы экспортируемого шифрования (для которого CipherSpec.is_exportable равно 'истинно') требуют дополнительной обработки для получения ключей записи, как это показано ниже:

    final_client_write_key =
    PRF(SecurityParameters.client_write_key,

    "client write key",

    SecurityParameters.client_random +

    SecurityParameters.server_random);

    final_server_write_key =
    PRF(SecurityParameters.server_write_key,

    "server write key",

    SecurityParameters.client_random +

    SecurityParameters.server_random);

    Алгоритмы экспортируемого шифрования получают свои IV исключительно из случайных кодов сообщений hello:

    iv_block = PRF("", "IV block", SecurityParameters.client_random +

    SecurityParameters.server_random);

    Блок iv_block делится на два инициализационных векторов, как это делалось выше для key_block:

    client_write_IV[SecurityParameters.IV_size]
    server_write_IV[SecurityParameters.IV_size]

    Заметим, что PRF используется в этом случае без секретного кода: это означает, что секретный код имеет длину нуль байт и не вносит ничего в хэширование PRF.

    6.3.1. Пример генерации экспортного ключа

    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требует пяти случайных байт для каждого из двух ключей шифрования и 16 байт для каждого ключа MAC, что составляет 42 байта ключевого материала. Выход PRF запоминается в key_block. Блок key_block делится, а ключи записи запоминаются, так как это алгоритм экспортного шифрования.

    key_block

    = PRF(master_secret,

    "key expansion",

    server_random +

    client_random)[0..41]

    client_write_MAC_secret

    = key_block[0..15]

    server_write_MAC_secret

    = key_block[16..31]

    client_write_key

    = key_block[32..36]

    server_write_key

    = key_block[37..41]

    final_client_write_key

    = PRF(client_write_key,

    "client write key",

    client_random +

    server_random)[0..15]

    final_server_write_key

    = PRF(server_write_key,

    "server write key",

    client_random +

    server_random)[0..15]

    iv_block

    = PRF("", "IV block", client_random +

    server_random)[0..15]

    client_write_IV

    = iv_block[0..7]

    server_write_IV

    = iv_block[8..15]

    7. Протокол диалога TLS

    Протокол диалога TLS содержит набор из трех суб-протоколов, которые используются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках.

    Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:

    идентификатор сессии

    Произвольная последовательность байтов, выбранная сервером для идентификации состояния сессии (активная/ возобновляемая).

    сертификат партнера

    X509v3 [X509] сертификат партнера. Этот элемент состояния может быть равен нулю.

    метод сжатия

    Алгоритм, используемый для сжатия информации перед шифрованием.

    спецификация шифра

    Специфицирует алгоритм массового шифрования (такой как нуль, DES, и т.д.) и алгоритм MAC (такой как MD5 или SHA). Она определяет также криптографические атрибуты, такие как hash_size. (Смотри приложение A.6)

    мастерный секретный код

    48-байтовый секретный код, общий для сервера и клиента.

    'is resumable'

    Флаг, указывающий, может ли сессия использоваться для инициализации нового соединения.

    Эти объекты используются затем для определения параметров безопасности для уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления (resumption) протокола диалога.

    7.1. Протокол изменения спецификации шифра

    Протокол изменения спецификации шифра предназначен для оповещения об изменении стратегии шифрования. Протокол использует одно сообщение, которое зашифровано и архивировано в рамках текущего состояния соединения. Сообщение состоит из одного байта со значением 1.

    struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;

    Сообщение изменения спецификации шифра посылается как клиентом, так и сервером, для того чтобы уведомить партнера о том, что последующие записи будут защищены с помощью только что согласованных ключей и спецификации CipherSpec. Получение этого сообщения заставляет получателя на уровне записей немедленно скопировать состояние ожидания чтения в текущее состояние чтения. Сразу после посылки сообщения отправитель должен дать команду уровню записей преобразовать состояние ожидания записи в активное состояние записи. (Смотри раздел 6.1.) Сообщение изменения спецификации шифра посылается во время диалога после согласования набора параметров безопасности, но до посылки проверочного завершающего сообщения (смотри раздел 7.4.9).

    7.2. Протокол оповещения

    Одним из типов содержимого, поддерживаемого слоем записей TLS, является оповещение. Сообщения оповещения передают описание возникшей ситуации. Оповещения с аварийным уровнем вызывают немедленное прерывание соединения. В этом случае, другие соединения сессии могут оставаться в рабочем состоянии, но идентификатор сессии должен быть объявлен не действительным, блокируя установление новых соединений. Подобно другим сообщениям, оповещения шифруются и сжимаются, как это специфицировано состоянием текущего соединения.

    enum { warning(1), fatal(2), (255) } AlertLevel;

    enum { close_notify(0),

    unexpected_message(10),

    bad_record_mac(20),

    decryption_failed(21),

    record_overflow(22),

    decompression_failure(30),

    handshake_failure(40),

    bad_certificate(42),

    unsupported_certificate(43),

    certificate_revoked(44),

    certificate_expired(45),

    certificate_unknown(46),

    illegal_parameter(47),

    unknown_ca(48),

    access_denied(49),

    decode_error(50),

    decrypt_error(51),

    export_restriction(60),

    protocol_version(70),

    insufficient_security(71),

    internal_error(80),

    user_canceled(90),

    no_renegotiation(100),

    (255)} AlertDescription;
    struct { AlertLevel level; AlertDescription description;} Alert;

    7.2.1. Оповещения закрытия

    Клиент и сервер должны оба знать, что соединение завершается, для того чтобы избежать атаки усечения (truncation). Оба партнера могут запустить обмен сообщениями закрытия.

    close_notify

    Это сообщение обращает внимание получателя, что отправитель не будет посылать более каких-либо данных через это соединение. Сессия становится не возобновляемой (unresumable), если любое соединение разорвано без соответствующих сообщений close_notify с уровнем равным предупреждению.

    Оба партнера могут инициализировать закрытие, послав уведомление close_notify. Любые данные, полученные после оповещения о закрытии, игнорируются.

    Каждый из партнеров обязан послать уведомление close_notify, прежде чем разрывать соединение со стороны записи. Требуется, чтобы другой партнер реагировал своим уведомлением close_notify и закрывал соединение немедленно, аннулируя все не завершенные записи. Для инициатора закрытия не требуется ждать получения отклика close_notify, прежде чем закрыть соединение со стороны чтения. Если прикладной протокол, использующий TLS, гарантирует, что любые данные могут быть переданы через используемое TLS-соединение после его закрытия, реализация TLS должна получить уведомление-отклик close_notify до оповещения прикладного уровня о том, что соединение TLS завершает свою работу. Если прикладной протокол не передает никаких дополнительных данных, но лишь закрывает ниже лежащее транспортное соединение, тогда реализация может выбрать вариант закрытия транспорта, не дожидаясь отклика close_notify.

    Предполагается, что закрытие соединения надежно доставляет все данные, ждущие передачи, прежде чем транспортная система будет блокирована.

    7.2.2. Оповещения об ошибках

    Обработка ошибок в протоколе диалога TLS очень проста. Когда обнаруживается ошибка, обнаруживший партнер посылает сообщение другому партнеру. При передаче или получении сообщения о фатальной ошибке, оба партнера немедленно закрывают соединение. Серверы и клиенты должны забыть любые идентификаторы сессии, ключи и секретные коды, связанные с неудачным соединением. Определены следующие оповещения об ошибках:

    unexpected_message

    Получено не предусмотренное сообщение. Это оповещение является всегда фатальным и не должно встречаться при обменах между корректными реализациями.

    bad_record_mac

    Это оповещение присылается, если получена запись с неверным MAC. Это сообщение всегда вызывает фатальную ошибку.

    decryption_failed

    TLSCiphertext дешифрован не верно: либо текст не имел длину четную и кратную размеру блока или их значения (заполнители) при проверке оказались некорректными. Это сообщение всегда вызывает фатальную ошибку.

    record_overflow

    Получена запись TLSCiphertext, которая имеет длину больше 214+2048 байт, запись дешифрована TLSCompressed в запись с более чем 214+1024 байтов. Это сообщение всегда вызывает фатальную ошибку.

    decompression_failure

    Функция декомпрессии получила неприемлемые данные (напр., данные, которые после восстановления будут иметь слишком большой объем). Это сообщение вызывает фатальную ошибку.

    handshake_failure

    Получение сообщения оповещения handshake_failure указывает, что отправитель не мог согласовать приемлемый набор параметров безопасности из числа предлагаемых опций. Это фатальная ошибка.

    bad_certificate

    Сертификат был поврежден, содержал подписи, которые не прошли проверку и т.д..

    unsupported_certificate

    Сертификат имел не поддерживаемый тип.

    certificate_revoked

    Сертификат был отозван его подписантом.

    certificate_expired

    Сертификат имеет исчерпанный срок годности или не пригоден по другой причине.

    certificate_unknown

    Некоторая другая, не специфицированная причина при обработке сертификата, делающая его неприемлемым.

    illegal_parameter

    Поле при диалоге оказалось вне диапазона допустимых значений или не согласуется с другими полями. Это фатальная ошибка..

    unknown_ca

    Получена корректная сертификатная последовательность или ее часть, но сертификат не был воспринят из-за того, что CA-сертификат не может быть обнаружен или не согласуется с известным проверенным CA. Это сообщение всегда вызывает фатальную ошибку.

    access_denied

    Получен правильный сертификат, но при проверке доступа отправитель решил не продолжать согласование. Это сообщение всегда вызывает фатальную ошибку.

    decode_error

    Сообщение не может быть дешифровано из-за того, что некоторое поле выходит за пределы допустимого или сообщение имеет не верный размер. Это сообщение всегда вызывает фатальную ошибку.

    decrypt_error

    Диалог криптографической операции не прошел, это может включать неудачу проверки подписи, обмена ключами или контроль завершающего сообщения.

    export_restriction

    Согласование параметров вошло в противоречие с экспортными регламентациями. Например: попытка передать 1024 битов ephemeral RSA-ключа для метода диалога RSA_EXPORT. Это сообщение всегда вызывает фатальную ошибку.

    protocol_version

    Протокольная версия клиента распознана, но не поддерживается. (Например: старые версии протокола могут отвергаться по соображениям безопасности). Это сообщение всегда вызывает фатальную ошибку.

    insufficient_security

    Возвращается вместо handshake_failure, когда согласование не прошло в частности из-за того, что сервер требует более секретного шифра, чем может поддержать клиент. Это сообщение всегда вызывает фатальную ошибку.

    internal_error

    Внутренняя ошибка, не связанная с партнером, или требования протокола не допускают продолжения процедуры (например, ошибка при выделении памяти). Это сообщение всегда вызывает фатальную ошибку.

    user_canceled

    Этот диалог аннулирован по какой-то причине, не связанной с протокольной ошибкой. Если пользователь аннулирует операцию после завершения диалога, закрытие соединения путем посылки close_notify является более приемлемым. За этим оповещением должно следовать close_notify. Это сообщения является предупреждением.

    no_renegotiation

    Посылается клиентом в ответ на запрос hello или сервером - в ответ на hello клиента после стартового диалога. Любое из этих сообщений должно, в норме, вызывать повторное согласование параметров. Когда это не приемлемо, получатель должен реагировать посылкой этого уведомления (alert). В этой точке отправитель исходного запроса может решить, следует ли сохранять соединение. Случаем, когда это приемлемо, может оказаться ситуация, когда сервер запускает процесс, чтобы удовлетворить запросу. Процесс может получить параметры безопасности (длину ключа, аутентификацию и т.д.) при запуске, и может быть, трудно сообщить об изменении этих параметров в этой точке процесса. Это сообщение всегда является предупреждением.

    Для всех ошибок, где уровень оповещения не специфицирован явно, отправитель может сам определить, является ли ошибка фатальной. Если получено оповещение с уровнем предупреждения, получатель может сам решить, воспринимать ли ее как фатальную. Однако все сообщения, которые переданы с фатальным уровнем, должны рассматриваться как фатальные.

    7.3. Обзор протокола диалога

    Криптографические параметры состояния сессии формируются протоколом диалога TLS, который работает поверх уровня записей TLS. Когда клиент и сервер TLS впервые начинают взаимодействие, они согласуют версию протокола, выбирают криптографические алгоритмы, опционно аутентифицируют друг друга и используют методику с общедоступным ключом для формирования общего секретного кода. Протокол диалога TLS включает в себя следующие шаги:

    • Обмен сообщениями hello, чтобы согласовать алгоритмы, обмен случайными кодами, и проверка перезапуска сессии.
    • Обмен необходимыми криптографическими параметрами, чтобы позволить клиенту и серверу согласовать предмастерные секретные коды.
    • Обмен сертификатами и криптографической информацией, чтобы позволить клиенту и серверу аутентифицировать друг друга.
    • Генерация мастерного секретного кода из предмастерного и обмен случайными кодами.
    • Предоставление параметров безопасности уровню записей.
    • Разрешение клиенту и серверу проверить, что их партнер вычислил те же самые параметры безопасности и что диалог прошел без вмешательства хакера.

    Заметим, что верхние слои не должны слишком полагаться на TLS, всегда согласуя самые безопасные из возможных соединений между партнерами: существует много способов, с помощью которых злоумышленник, включившийся в разрыв соединения, может попытаться заставить партнеров принять наименее безопасный метод связи из числа поддерживаемых ими. Протокол был устроен так, чтобы минимизировать этот риск, но, тем не менее, существуют некоторые возможности атак. Например, хакер может блокировать доступ к порту, через который обеспечивается безопасное обслуживание, или попытаться заставить партнеров установить не аутентифицированное соединение. Фундаментальным правилом является то, что верхние уровни должны знать, каковы требования безопасности и никогда не передавать данные по каналам, которые менее безопасны, чем это предписано этими требованиями. Протокол TLS является безопасным, здесь любой шифровой набор предлагает свой уровень безопасности. Если вы согласуете использование 3DES с 1024-битовым RSA-ключом при связи с ЭВМ, чей сертификат вы проверили, вы можете быть уверены в безопасности. Однако вы никогда не должны посылать данные по каналу, где используется 40-битовая шифрование, если только вы не уверены, что данные не стоят того, чтобы кто-то тратил силы на их дешифрование.

    Эти цели достигаются протоколом диалога, который может быть суммирован следующим образом. Клиент посылает сообщение hello, на которое сервер должен также откликнуться сообщением hello, в противном случае возникает ситуация фатальной ошибки и соединение разрывается. Сообщения client hello и server hello используются для установления более безопасного взаимодействия клиента и сервера. Сообщения client hello server hello устанавливают следующие атрибуты: версия протокола, ID-сессии, шифровой набор и метод сжатия. Кроме того, партнеры генерируют и пересылают друг другу два случайных числа: ClientHello.random и ServerHello.random.

    Реальный обмен ключами использует до четырех сообщений: сертификат сервера, ключевой обмен сервера, сертификат клиента и ключевой обмен клиента. Новые методы ключевого обмена могут быть созданы с помощью спецификации формата для этих сообщений, чтобы позволить клиенту и серверу согласовать использование общего секретного кода. Этот секретный код должен быть достаточно длинным. Современные методы ключевого обмена пересылают коды длиной от 48 до 128 байт.

    Вслед за сообщениями hello, сервер, если он должен быть аутентифицирован, посылает свой сертификат. Кроме того, если необходимо, может быть послано сообщение ключевого обмена (например, если сервер не имеет сертификата, или если его сертификат служит только для подписи). Если сервер аутентифицирован, он может затребовать сертификат от клиента, если выбран соответствующий шифровой набор. После этого сервер пошлет сообщение hello done, указывающее, что фаза диалога hello завершена. Сервер ждет отклика клиента. Если сервер послал сообщение сертификатного запроса, клиент должен послать сообщение сертификата. Сообщение ключевого обмена клиента послано, и его содержимое зависит от алгоритма с общедоступным ключом, который выбрали клиент и сервер при обмене сообщениями hello.

    В этой точке клиентом посылается сообщение об изменении спецификации шифра, и клиент копирует записанную шифровую спецификацию в текущую спецификацию. После этого клиент немедленно посылает сообщение finished для новых алгоритмов, ключей и секретных кодов. В качестве отклика сервер пошлет свое сообщение об изменении шифровой спецификации, перенесет записанную шифровую спецификацию в текущую, и пошлет свое сообщение finished с использованием новой шифровой спецификации. В этой точке диалог завершается, а клиент и сервер могут начать обмен прикладными данными (смотри блок-схему обмена ниже на рис. .1).

    Клиент Сервер
    ClientHello -------->

    ServerHello

    Certificate*

    ServerKeyExchange*

    CertificateRequest*

    <-------- ServerHelloDone

    Certificate*
    ClientKeyExchange
    CertificateVerify*
    [ChangeCipherSpec]

    Finished -------->

    [ChangeCipherSpec]

    <-------- Finished
    Прикладные данные <-------> Прикладные данные

    Рис. .1. Обмен сообщениями в процессе диалога

    * отмечает опционные или зависящие от ситуации сообщения, которые посылаются не всегда.

    Когда клиент и сервер решают возобновить предыдущую сессию или задублировать существующую сессию (вместо согласования новых параметров безопасности), следует обмен следующими сообщениями:

    Клиент посылает ClientHello, используя ID-сессии, которая должна быть возобновлена. Сервер проверяет свой кэш сессий на соответствие. Если соответствие имеется, а сервер желает возобновить соединение со специфицированным состоянием сессии, он посылает ServerHello с тем же значением ID-сессии. В этой точке, как клиент, так и сервер должны послать сообщения об изменении шифровой спецификации, после чего перейти к завершающим сообщениям finished. Раз восстановление сессии завершилось, клиент и сервер могут начать обмен прикладными данными. Смотри диаграмму на рис. .2. Если соответствия с ID-сессии не найдено, сервер генерирует новый ID сессии, а клиент TLS и сервер осуществляют полный диалог.

    Клиент Сервер
    ClientHello -------->

    ServerHello

    [ChangeCipherSpec]

    <-------- Finished

    [ChangeCipherSpec]
    Finished ----------->
    Прикладные данные <-------> Прикладные данные

    Рис. .2. Обмен сообщениями для упрощенного диалога

    7.4. Протокол диалога

    Протокол диалога TLS представляет собой один из фиксированных клиентов высокого уровня протокола записей TLS. Этот протокол используется для согласования атрибутов безопасности сессии. Сообщения диалога передаются уровню записей TLS, где они инкапсулируются в одну или более структур TLSPlaintext, которые обрабатываются и передаются так, как это специфицировано текущим состоянием активной сессии.

    enum { hello_request(0), client_hello(1), server_hello(2),
    certificate(11), server_key_exchange (12),
    certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16),
    finished(20), (255)
    } HandshakeType;

    struct

    { HandshakeType msg_type;

    /* тип диалога */

    uint24 length;

    /* байтов в сообщении */

    select (HandshakeType) {

    case hello_request:

    HelloRequest;

    case client_hello:

    ClientHello;

    case server_hello:

    ServerHello;

    case certificate:

    Certificate;

    case server_key_exchange:

    ServerKeyExchange;

    case certificate_request:

    CertificateRequest;

    case server_hello_done:

    ServerHelloDone;

    case certificate_verify:

    CertificateVerify;

    case client_key_exchange:

    ClientKeyExchange;

    case finished:

    Finished; } body;

    } Handshake;

    Сообщения протокола диалога представлены ниже в порядке, в котором они должны быть посланы. Посылка сообщений диалога в неправильном порядке приведет к фатальной ошибке. Ненужные сообщения диалога могут быть опущены. Обратите внимание на одно исключение: сообщение сертификата используется в диалоге дважды (от клиента к серверу, а затем от сервера к клиенту), но оно описано лишь для первого случая его использования. Одно сообщение не привязано к этим правилам порядка обмена, это сообщение запроса Hello, которое может быть послано в любое время, но которое должно игнорироваться клиентом, если приходит в середине диалога.

    7.4.1. Сообщения Hello

    Сообщения фазы hello используются для выяснения возможностей клиента и сервера по повышению безопасности информационного обмена. Когда начинается новая сессия, состояние шифрования уровня записей, алгоритмы хэширования и сжатия инициализируются нулем. Текущее состояние соединения используется для сообщений согласования параметров.

    7.4.1.1. Запрос Hello

    Сообщение-запрос hello может быть послано сервером в любое время.

    Значение этого сообщения:

    Запрос Hello является простым уведомлением о том, что клиент должен начать согласование путем посылки сообщения client hello. Это сообщение будет проигнорировано клиентом, если он участвует в сессии согласования. Это сообщение может игнорироваться клиентом, если он не хочет заново согласовывать параметры сессии, или клиент может, если хочет, реагировать уведомлением no_renegotiation. Так как сообщения диалога предназначены для осуществления определенных действий над прикладными данными, ожидается, что согласование начнется до того, как будут получены новые записи от клиента. Если сервер посылает запрос hello, но не получает отклика client hello, он может разорвать соединение с фатальным уведомлением.

    После посылки запроса hello, серверы не должны повторять запрос до тех пор, пока диалог согласования не завершится.

    Структура этого сообщения:
    struct { } HelloRequest;

    Это сообщение не должно никогда включаться в хэши сообщений и использоваться в завершающих сообщениях (finished), а также в сообщении верификации сертификатов.

    7.4.1.2. Hello клиента

    Когда клиент инициализирует соединение с сервером, первым должно быть послано сообщение client hello. Клиент может также послать client hello в качестве отклика на запрос hello или по своей собственной инициативе, для того чтобы заново согласовать параметры безопасности существующего соединения.

    Сообщение hello клиента включает в себя случайную структуру, которая позднее используется протоколом.

    struct { uint32 gmt_unix_time; opaque random_bytes[28];} Random;

    gmt_unix_time

    Текущее время и дата согласно стандарта UNIX в 32-битовом формате (число секунд с момента полуночи 1-го января, 1970, GMT) согласно показаниям внутренних часов отправителя. Часы могут и не быть точно выверены на уровне протокола TLS. Прикладные протоколы могут накладывать дополнительные ограничения.

    random_bytes

    28 байт сформированных безопасным генератором случайных чисел.

    Сообщение client hello включает в себя идентификатор сессии переменной длины. Если это поле не пусто, его значение идентифицирует сессию, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может соответствовать какому-то предшествующему соединению, текущему соединению, или другому активному соединению. Вторая опция полезна, если клиент хочет изменить случайные структуры и получить текущие значения параметров соединения, в то время как третья опция делает возможным установить несколько независимых безопасных соединений без повторения всей процедуры протоколы диалога. Эти независимые соединения могут существовать последовательно или одновременно; SessionID становится действенным, когда диалог согласования завершается обменом сообщениями Finished, и сохраняется до тех пор, пока не состарится или из-за фатальной ошибки в соединении данной сессии. Действительное содержимое SessionID определяется сервером.

    opaque SessionID<0..32>;

    Так как SessionID передается без шифрования или MAC-защиты, серверы не должны помещать конфиденциальные данные в идентификаторы сессий, что могло бы привести к возрастанию уязвимости. Заметим, что содержимое диалога в целом, включая SessionID, защищено сообщениями Finished, пересылаемыми в конце диалога.

    Список CipherSuite, передаваемый от клиента серверу в сообщении client hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом в порядке их предпочтения (предпочтительный вариант - первый). Каждый CipherSuite определяет алгоритм пересылки ключей, алгоритм массового шифрования (включая длину секретного ключа) и алгоритм MAC. Сервер выберет шифровой набор или, если приемлемого варианта нет, пришлет уведомление об ошибке и прервет соединение.

    uint8 CipherSuite[2]; /* Cryptographic suite selector */

    Hello клиента включает в себя список алгоритмов сжатия, поддерживаемых клиентом, в порядке их предпочтения.

    enum { null(0), (255) } CompressionMethod;

    struct

    { ProtocolVersion client_version;

    Random random;

    SessionID session_id;

    CipherSuite cipher_suites<2..216-1>;

    CompressionMethod compression_methods<1..28-1>;

    } ClientHello;

    client_version

    Версия протокола TLS, которой хочет воспользоваться клиент во время сессии. Это должна быть последняя версия (с наибольшим кодом), поддерживаемая клиентом. Для данной спецификации значение версии равно 3.1 (Смотри приложение E об обратной совместимости).

    Random

    Псевдослучайная структура, генерируемая клиентом.

    session_id

    ID-сессия, которую клиент хочет использовать для данного соединения. Это поле должно быть пустым, если нет ни одного session_id или клиент хочет выработать новые параметры безопасности.

    cipher_suites

    Список криптографических опций, поддерживаемых клиентом в порядке предпочтения. Если поле session_id не пусто (запрос восстановления сессии), этот вектор должен включать по крайней мере cipher_suite данной сессии. Значения определены в приложении A.5.

    compression_methods

    Список методов сжатия, поддерживаемых клиентом в порядке их предпочтения. Если поле session_id не пусто (запрос восстановления сессии) он должен включать compression_method данной сессии. Этот вектор должен содержать, а все реализации должны поддерживать CompressionMethod.null. Таким образом, клиент и сервер всегда могут согласовать метод сжатия информации.

    После посылки сообщения client hello, клиент ждет сообщения server hello. Любое другое сообщение диалога, присланное сервером, за исключением запроса hello, рассматривается как фатальная ошибка.

    В интересах прямой совместимости, клиенту разрешено включать в сообщение client hello после методов сжатия дополнительные данные. Эти данные должны быть включены в хэши диалога, в противном случае они игнорируются. Это единственное сообщение диалога, для которого это допускается; для всех остальных сообщений, объем данных должен точно соответствовать описанию сообщения.

    7.4.1.3. Hello сервера

    Сервер посылает это сообщение в ответ на сообщение client hello, когда он может найти приемлемый набор алгоритмов. Если он не может сделать приемлемый выбор, он реагирует уведомлением об ошибке диалога.

    Структура этого сообщения:

    Struct

    { ProtocolVersion server_version;

    Random random;

    SessionID session_id;

    CipherSuite cipher_suite;

    CompressionMethod compression_method;

    } ServerHello;

    server_version

    Это поле будет содержать самое низкое значение, которое предлагается клиентом в client hello и наибольшее значение версии, поддерживаемое сервером. Значение версии данной спецификации равно 3.1 (по поводу обратной совместимости смотри Приложение E).

    Random

    Эта структура генерируется сервером и должна быть отличной от ClientHello.random.

    session_id

    Идентифицирует сессию, соответствующую данному соединению. Если ClientHello.session_id не пусто, сервер будет искать соответствие с содержимым своего кэша сессий. Если соответствие найдено и сервер хочет установить новое соединение, используя специфицированное состояние сессии, он откликнется тем же значением ID, что было прислано клиентом. Это индицирует возобновляемую сессию и диктует, что партнеры должны продолжить обмен сообщениями finished. В противном случае это поле будет содержать другое значение идентифицирующее новую сессию. Сервер может вернуть пустое поле session_id, чтобы индицировать, что сессия не будет кэшироваться и, следовательно, не может быть возобновлена. Если сессия возобновлена, она должна использовать тот же шифровой набор, который был согласован ранее.

    cipher_suite

    Шифровой набор, выбранный сервером из списка в ClientHello.cipher_suites. Для возобновленных сессий это поле несет в себе значение, взятое из состояния возобновляемой сессии.

    compression_method

    Алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для возобновляемых сессий это поле содержит значение из состояния возобновляемой сессии.

    7.4.2. Сертификат сервера

    Сервер должен послать сертификат, всякий раз, когда согласованный метод обмена ключами не является анонимным. За этим сообщением всегда непосредственно следует сообщение server hello.

    Тип сертификата должен соответствовать выбранному алгоритму обмена ключами шифров, обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключами. Если не специфицировано обратного, алгоритм подписи для сертификата должен быть тем же, что и алгоритм для ключа сертификата. Если не специфицировано обратного, общедоступный ключ может иметь любую длину.

    Алгоритм обмена ключами

    Тип сертификата ключа

    RSA

    Общедоступный ключ RSA; сертификат должен допускать использование ключа для шифрования.

    RSA_EXPORT

    Общедоступный ключ RSA с длиной больше чем 512 бит, который может быть использован для подписи, или ключ длиной 512 бит или короче, который может быть использован для шифрования или подписи.

    DHE_DSS

    Общедоступный ключ DSS.

    DHE_DSS_EXPORT

    Общедоступный ключ DSS.

    DHE_RSA

    Общедоступный ключ RSA, который может использоваться для подписи.

    DHE_RSA_EXPORT

    Общедоступный ключ RSA, который может использоваться для подписи.

    DH_DSS

    Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть DSS.

    DH_RSA

    Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть RSA.

    Все сертификатные профайлы, ключи и криптографические форматы определены рабочей группой IETF PKIX [PKIX]. Когда присутствует расширение использования ключа, бит digitalSignature должен быть установлен для ключа выбранного для подписи, как это описано выше, а бит keyEncipherment должен присутствовать, чтобы разрешить шифрование, как это описано выше. Бит keyAgreement должен быть установлен для сертификатов Diffie-Hellman.

    Так как CipherSuites, который специфицирует методы нового ключевого обмена, заданы для протокола TLS, они используют формат сертификата и необходимые ключевые данные.

    Структура этого сообщения:
    opaque ASN.1Cert<1..224-1>;
    struct { ASN.1Cert certificate_list<0..224-1>; } Certificate;

    certificate_list

    Это последовательность (цепочка) сертификатов X.509v3. Сертификат отправителя должен быть записан в списке первым. Каждый следующий сертификат должен непосредственно сертифицировать предшествующий сертификат. Так как верификация сертификата требует, чтобы корневые ключи распределялись независимо, самоподписывающий сертификат, который специфицирует корневой источник сертификата, может быть опционно удален из цепочки, в предположении, что партнер должен уже иметь его, чтобы проверить его в любом случае.

    Тот же тип сообщения и структура будут использоваться для отклика клиента на сообщение запроса сертификата. Заметим, что клиент может не посылать сертификата, если он не имеет подходящего, чтобы послать его серверу в ответ на его аутентификационный запрос.

    7.4.3. Сообщение ключевого обмена сервера

    Это сообщение будет послано немедленно после сообщения сертификата сервера (или сообщения server hello, если это анонимное согласование параметров).

    Сообщение ключевого обмена сервера посылается сервером только когда сообщение сертификата сервера (если послано) не содержит достаточно данных, чтобы позволить клиенту осуществлять обмен предмастерными секретными кодами (premaster secret). Это верно для следующих методов обмена ключами:

    RSA_EXPORT (если открытый ключ в сертификате длиннее, чем 512 бит)
    DHE_DSS
    DHE_DSS_EXPORT
    DHE_RSA
    DHE_RSA_EXPORT
    DH_anon

    Нелегально посылать сообщение ключевого обмена сервера для следующих методов пересылки ключей:

    RSA
    RSA_EXPORT (когда открытый ключ в сертификате сервера короче чем или равен 512 бит)
    DH_DSS
    DH_RSA

    Это сообщение передает криптографическую информацию, чтобы позволить клиенту оперировать с premaster секретным кодом: либо общедоступный ключ RSA, чтобы зашифровать предмастерный секретный код, либо общедоступный ключ Diffie-Hellman, с помощью которого клиент может завершить обмен ключами.

    В качестве дополнительных определены наборы CipherSuites TLS, которые включают в себя новые алгоритмы обмена ключами. Сервер пошлет сообщение обмена ключами тогда и только тогда, когда тип сертификата, ассоциированный с алгоритмов обмена ключами, не предоставил достаточно информации клиенту, чтобы осуществить пересылку предмастерного секретного кода.

    Согласно настоящему закону США об экспорте, модули RSA больше 512 бит не могут использоваться для ключевого обмена в программах, экспортируемых из США. Более длинные ключи RSA, зашифрованные в сертификатах, могут быть использованы для подписи более коротких ключей RSA в случае метода ключевого обмена RSA_EXPORT.

    Структура этого сообщения:
    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
    struct { opaque rsa_modulus<1..2^16-1>; opaque rsa_exponent<1..2^16-1>;} ServerRSAParams;

    rsa_modulus

    Модуль временного RSA-ключа сервера.

    rsa_exponent

    Общедоступный показатель временного RSA-ключа сервера.

    struct { opaque dh_p<1..2^16-1>;

    opaque dh_g<1..2^16

    1>;

    opaque dh_Ys<1..2^16

    1>;} ServerDHParams; /* Временные DH параметры */

    dh_p

    Простой модуль, используемый для операции Diffie-Hellman.

    dh_g

    Генератор, используемый для операции Diffie-Hellman.

    dh_Ys

    Общедоступное значение (gX mod p) метода Diffie-Hellman для сервера.

    struct { select (KeyExchangeAlgorithm) {

    case diffie_hellman:

    ServerDHParams params;

    Signature signed_params;

    case rsa:

    ServerRSAParams params;

    Signature signed_params; };

    } ServerKeyExchange;

    Params

    Параметры ключевого обмена сервера.

    signed_params

    Для не анонимных ключевых обменов, хэш соответствующих значений параметров с подписью, согласованной с примененным хэшем.

    md5_hash

    MD5(ClientHello.random + ServerHello.random + ServerParams);

    sha_hash

    SHA(ClientHello.random + ServerHello.random + ServerParams);

    enum { anonymous, rsa, dsa } SignatureAlgorithm;

    select (SignatureAlgorithm)

    { case anonymous: struct { };

    case rsa:

    digitally-signed struct

    {

    opaque md5_hash[16];

    opaque sha_hash[20];

    };

    case dsa:

    digitally-signed struct {

    opaque sha_hash[20];

    };

    } Signature;

    7.4.4. Запрос сертификата

    Не анонимный сервер может опционно запросить сертификат от клиента, если это возможно для выбранного шифрового набора. За этим сообщением, если оно послано, непосредственно следует сообщение ключевого обмена сервера (Server Key Exchange) (в противном случае, сообщение сертификата сервера).

    Структура этого сообщения:
    enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
    (255)} ClientCertificateType;
    opaque DistinguishedName<1..216-1>;
    struct { ClientCertificateType certificate_types<1..28-1>;
    DistinguishedName certificate_authorities<3..216-1>;
    } CertificateRequest;

    certificate_types

    Это поле представляет собой список типов запрошенных сертификатов, расположенных в порядке предпочтения сервера.

    certificate_authorities

    Список имен приемлемых провайдеров сертификатов. Эти имена могут специфицировать уникальное имя корневого или подчиненного CA. Таким образом, это сообщение может быть использовано как для описания известных корней и желательного пространства авторизации.

    DistinguishedName получается из [X509]. Считается фатальной ошибкой (оповещение handshake_failure), если анонимный сервер запрашивает идентификацию клиента.

    7.4.5. Hello done сервера

    Сообщение сервера hello done посылается сервером, чтобы индицировать конец hello сервера и связанных с ним сообщений. После отправки этого сообщения сервер ждет отклика клиента.

    Это сообщение означает, что сервер завершил подготовку для ключевого обмена, и клиент может приступить к процедуре пересылки ключей.

    По получении сообщения сервера hello done клиент должен проверить, что сервер предоставил корректный сертификат, если это требуется, и что параметры, присланные сервером приемлемы.

    Структура этого сообщения: struct { } ServerHelloDone;

    7.4.6. Сертификат клиента

    Это первое сообщение, которое может послать клиент после получения сообщения от сервера hello done. Это сообщение посылается только в случае запроса присылки сертификата со стороны сервера. Если приемлемого сертификата нет, клиент должен послать пустое сообщение сертификата. Если сервером для продолжения диалога требуется аутентификация клиента, он может откликнуться, послав уведомление о фатальной ошибке. Сертификаты клиента посылаются с использованием структуры сертификата, определенной в разделе 7.4.2.

    Когда используется метод ключевого обмена, базирующийся на статическом методе Diffie-Hellman (DH_DSS или DH_RSA), если требуется аутентификация клиента, группа Diffie-Hellman и генератор закодированные в сертификате клиента должны соответствовать параметрам Diffie-Hellman'а, специфицированным сервером, если параметры клиента планируется использовать для ключевого обмена.

    7.4.7. Сообщение обмена ключами клиента

    Это сообщение посылается клиентом всегда. За ним непосредственно следует сообщение сертификата клиента, если оно посылается. В противном случае оно будет первым сообщением, посылаемым клиентом после получения сообщения сервера hello done.

    С помощью этого сообщения устанавливается предмастерный секретный код, либо путем прямой передачи его, зашифровав с применением RSA, либо с помощью передачи параметров Diffie-Hellman, которые позволят каждой из сторон согласовать применение одного и того же предмастерного секретного кода. Когда в качестве метода передачи ключей использован DH_RSA или DH_DSS, запрашивается сертификация клиента, и клиент может откликаться посылкой сертификата, который содержит общедоступный ключ Diffie-Hellman, чьи параметры (группа и генератор) соответствуют, специфицированным в сертификате сервера. Это сообщение не содержит никаких других данных.

    Структура этого сообщения:

    Выбор сообщений зависит от выбранного метода ключевого обмена. Смотри раздел 7.4.3, где дано определение KeyExchangeAlgorithm.

    struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;
    case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys;
    } ClientKeyExchange;

    7.4.7.1. Сообщение зашифрованного RSA предмастерного секретного кода

    Если для согласования ключей и аутентификации применен алгоритм RSA, клиент генерирует 48-байтовый предмастерный секретный код, шифрует его с помощью общедоступного ключа из сертификата сервера или временного RSA-ключа, переданного в сообщении ключевого обмена сервера, и посылает результат в сообщении зашифрованного предмастерного секретного кода (encrypted premaster secret). Эта структура является вариантом сообщения ключевого обмена клиента.

    Структура этого сообщения:
    struct { ProtocolVersion client_version; opaque random[46];} PreMasterSecret;

    client_version

    Последняя (новейшая) версия, поддерживаемая клиентом. Она используется для детектирования атак связанных с понижением номера версии. По получении предмастерного секретного кода сервер должен проверить, что данное значение согласуется с величиной, переданной клиентом в сообщении hello.

    random

    46 байт псевдослучайного кода.

    struct { public-key-encrypted PreMasterSecret pre_master_secret;} EncryptedPreMasterSecret;

    Атака, рассмотренная Даниэлем Блайбенбахером (Daniel Bleichenbacher) [BLEI], может быть предпринята против TLS-сервера, который использует PKCS#1, закодированный с помощью RSA.

    Наилучший способ избежать уязвимости от этой атаки является обработка некорректно форматированных сообщений точно также как и корректно сформатированные RSA-блоки. Таким образом, когда сервер получает некорректно сформатированный RSA-блок, он должен сформировать случайное 48-байтовое число и использовать его в дальнейшем в качестве предмастерного секретного кода. Таким образом, сервер будет действовать идентично вне зависимости оттого, является ли полученный RSA-блок корректным.

    pre_master_secret

    Это случайное число генерируется клиентом и используется для формирования мастерного секретного кода, как это специфицировано в разделе 8.1.

    7.4.7.2. Общедоступный Diffie-Hellman-ключ клиента

    Эта структура передает общедоступную величину (Yc) Diffie-Hellman-алгоритма для клиента, если она не была уже включена в сертификат клиента. Шифрование, используемое для Yc, определяется нумерованным параметром PublicValueEncoding. Эта структура является вариантом сообщения ключевого обмена клиента.

    Структура этого сообщения:
    enum { implicit, explicit } PublicValueEncoding;

    implicit

    Если сертификат клиента уже содержит подходящий ключ алгоритма Diffie-Hellman, тогда Yc является неявным и не должно пересылаться снова. В этом случае будет послано сообщение ключевого обмена клиента (Client Key Exchange), но оно будет пустым.

    explicit

    Yc должно быть послано.

    struct { select (PublicValueEncoding) {
    case implicit: struct { };
    case explicit: opaque dh_Yc<1..2^16-1>; } dh_public;
    } ClientDiffieHellmanPublic;

    dh_Yc

    Общедоступный Diffie-Hellman-ключ клиента (Yc).

    7.4.8. Верификация сертификата

    Это сообщение используется для осуществления в явной форме верификации сертификата клиента. Оно посылается вслед за сертификатом клиента, который имеет возможность подписи (т.e. все сертификаты кроме тех, которые содержат фиксированные параметры Diffie-Hellman). При посылке это сообщение следует немедленно за сообщением ключевого обмена клиента.

    Структура этого сообщения имеет вид:
    struct { Signature signature; } CertificateVerify;

    Тип подписи определен в 7.4.3.

    CertificateVerify.signature.md5_hash MD5(handshake_messages);
    Certificate.signature.sha_hash SHA(handshake_messages);

    Здесь handshake_messages относятся ко всем сообщениям диалога, посланным или полученным, начиная с hello клиента, и вплоть до (но исключая) данное сообщение, содержащее поля типа и длины сообщений диалога. Это представляет собой соединение всех структур диалога, как это определено в 7.4.

    7.4.9. Сообщение Finished

    Сообщение finished всегда посылается немедленно после сообщения изменения шифровой спецификации, чтобы верифицировать процессы ключевого обмена и аутентификации. Существенно, чтобы сообщение об изменении шрифтовой спецификации было получено между другими сообщениями диалога и сообщением Finished.

    Сообщение finished является первым, защищенным с использованием только что согласованных алгоритмов, ключей и секретных кодов. Получатели сообщений finished должны верифицировать корректность содержимого. Раз партнер послал свое сообщение Finished и получил корректное сообщение от другой стороны, он может начать посылать и получать через данное соединение прикладные данные.

    struct { opaque verify_data[12];} Finished;

    verify_data

    PRF(master_secret, finished_label, MD5(handshake_messages) + SHA1(handshake_messages)) [0..11];

    finished_label

    Для сообщений Finished, посланных клиентом, это строка "client finished". Для сообщений Finished, посланных сервером, это строка "server finished".

    handshake_messages

    Все данные от сообщений диалога до этого сообщение (но не включительно). Это единственные данные, видимые на уровне диалога, они не включают заголовки уровня записей. Это соединение всех структур диалога, определенных в 7.4.

    Если в соответствующей точке диалога за сообщением finished не следует сообщение об изменении шифровой спецификации, это считается фатальной ошибкой.

    Хэши, содержащиеся в сообщениях finished, посланных серверам, включает в себя Sender.server; а посланные клиентом содержат Sender.client. Значение handshake_messages включает все сообщения диалога, начиная с hello клиента и вплоть до (но не включая) это сообщение finished. Здесь могут быть отличия от handshake_messages из раздела 7.4.8, так как сюда может входить сообщение верификации сертификата. Следует также иметь в виду, что, handshake_messages для сообщения finished, посланного клиентом, будет отличаться от посланного сервером, так как второе, включает первое.

    Сообщения об изменении шифровой спецификации, уведомления и любые другие типы записей не являются сообщениями диалога и не включаются в вычисления хэшей. В хэши диалога не включаются также сообщения запроса Hello Request.

    8. Криптографические вычисления

    Для того чтобы начать защиту соединения, протоколу записей TLS необходима спецификация набора алгоритмов, мастерный секретный код и случайные коды клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются cipher_suite, выбранным сервером и указанным в сообщении server hello. Алгоритм сжатия согласуется в сообщениях hello, а случайные коды пересылаются в сообщениях hello. Все что остается - это вычислить мастерный секретный код.

    8.1. Вычисление мастерного секретного кода

    Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret.

    master_secret = PRF(pre_master_secret, "master secret",
    ClientHello.random + ServerHello.random) [0..47];

    Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена.

    8.1.1. RSA

    Когда для аутентификации сервера и ключевого обмена используется RSA, 48- байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше.

    Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2.

    8.1.2. Diffie-Hellman

    Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше.

    Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.

    В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

    Сообщения прикладных данных вырабатываются уровнем записей, фрагментируются, сжимаются и шифруются на основе параметров состояния соединения. Сообщения рассматриваются как прозрачные данные уровня записей.

    A. Значения протокольных констант

    A.1. Уровень записей
    struct { uint8 major, minor; } ProtocolVersion;
    ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
    enum { change_cipher_spec(20), alert(21), handshake(22),
    application_data(23), (255) } ContentType;
    struct { ContentType type; ProtocolVersion version; uint16 length;
    opaque fragment[TLSPlaintext.length];
    } TLSPlaintext;
    struct { ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSCompressed.length];
    } TLSCompressed;
    struct { ContentType type; ProtocolVersion version; uint16 length;
    select (CipherSpec.cipher_type) { case stream: GenericStreamCipher;
    case block: GenericBlockCipher; } fragment;
    } TLSCiphertext;
    stream-ciphered struct { opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size]; } GenericStreamCipher;
    block-ciphered struct { opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
    uint8 padding[GenericBlockCipher.padding_length];
    uint8 padding_length;
    } GenericBlockCipher;

    A.2. Сообщение об изменении спецификации шифра

    struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;

    A.3. Сообщения уведомления (Alert)

    enum { warning(1), fatal(2), (255) } AlertLevel;
    enum { close_notify(0),

    unexpected_message(10),

    bad_record_mac(20),

    decryption_failed(21),

    record_overflow(22),

    decompression_failure(30),

    handshake_failure(40),

    bad_certificate(42),

    unsupported_certificate(43),

    certificate_revoked(44),

    certificate_expired(45),

    certificate_unknown(46),

    illegal_parameter(47),

    unknown_ca(48),

    access_denied(49),

    decode_error(50),

    decrypt_error(51),

    export_restriction(60),

    protocol_version(70),

    insufficient_security(71),

    internal_error(80),

    user_canceled(90),

    no_renegotiation(100),

    (255) } AlertDescription;

    struct { AlertLevel level; AlertDescription description; } Alert;

    A.4. Протокол диалога

    enum { hello_request(0), client_hello(1), server_hello(2),

    certificate(11), server_key_exchange (12),

    certificate_request(13), server_hello_done(14),

    certificate_verify(15), client_key_exchange(16),

    finished(20), (255)

    } HandshakeType;
    struct { HandshakeType msg_type; uint24 length;

    select (HandshakeType)

    {

    case hello_request:

    HelloRequest;

    case client_hello:

    ClientHello;

    case server_hello:

    ServerHello;

    case certificate:

    Certificate;

    case server_key_exchange:

    ServerKeyExchange;

    case certificate_request:

    CertificateRequest;

    case server_hello_done:

    ServerHelloDone;

    case certificate_verify:

    CertificateVerify;

    case client_key_exchange:

    ClientKeyExchange;

    case finished:

    Finished; } body;

    } Handshake;

    A.4.1. Сообщения Hello

    struct { } HelloRequest;
    struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random;
    opaque SessionID<0..32>;
    uint8 CipherSuite[2];
    enum { null(0), (255) } CompressionMethod;
    struct { ProtocolVersion client_version; Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..216-1>;
    CompressionMethod compression_methods<1..28-1>;
    } ClientHello;
    struct { ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
    } ServerHello;

    A.4.2. Аутентификация сервера и сообщения обмена ключами

    opaque ASN.1Cert<224-1>;
    struct { ASN.1Cert certificate_list<1..224-1>;} Certificate;
    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
    struct { opaque RSA_modulus<1..216-1>; opaque RSA_exponent<1..216-1>;
    } ServerRSAParams;
    struct { opaque DH_p<1..216-1>; opaque DH_g<1..216-1>;
    opaque DH_Ys<1..216-1>; ServerDHParams;
    struct { select (KeyExchangeAlgorithm) {
    case diffie_hellman:
    ServerDHParams params;
    Signature signed_params;
    case rsa:
    ServerRSAParams params;
    Signature signed_params; };
    } ServerKeyExchange;
    enum { anonymous, rsa, dsa } SignatureAlgorithm;
    select (SignatureAlgorithm)
    { case anonymous: struct { };
    case rsa:
    digitally-signed struct {
    opaque md5_hash[16];
    opaque sha_hash[20]; };
    case dsa:
    digitally-signed struct {
    opaque sha_hash[20]; };
    } Signature;
    enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255)} ClientCertificateType;
    opaque DistinguishedName<1..216-1>;
    struct { ClientCertificateType certificate_types<1..28-1>;
    DistinguishedName certificate_authorities<3..216-1>;
    } CertificateRequest;
    struct { } ServerHelloDone;

    A.4.3. Аутентификация клиента и сообщения обмена ключами

    struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;
    case diffie_hellman: DiffieHellmanClientPublicValue; } exchange_keys;
    } ClientKeyExchange;
    struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret;
    struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;
    enum { implicit, explicit } PublicValueEncoding;
    struct { select (PublicValueEncoding) { case implicit: struct {};
    case explicit: opaque DH_Yc<1..216-1>; } dh_public;
    } ClientDiffieHellmanPublic;
    struct { Signature signature; } CertificateVerify;

    A.4.4. Завершающее сообщение диалога

    struct { opaque verify_data[12]; } Finished;

    A.5. Коды CipherSuite

    Следующие значения определены кодами CipherSuite, используемыми в сообщениях client hello и server hello. CipherSuite определяет шифровую спецификацию, поддерживаемую в TLS версии 1.0.

    TLS_NULL_WITH_NULL_NULL специфицировано и является исходным состоянием TLS-соединения во время начала диалога в канале, эта спецификация не согласуется, так как она предоставляет услуги незащищенного соединения.

    CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };

    Следующие определения CipherSuite требуют, чтобы сервер предоставлял RSA-сертификат, который можно использовать для ключевого обмена. Сервер может потребовать присылки сертификата RSA или DSS, пригодного для цифровой подписи.

    CipherSuite TLS_RSA_WITH_NULL_MD5

    = { 0x00,0x01 };

    CipherSuite TLS_RSA_WITH_NULL_SHA

    = { 0x00,0x02 };

    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5

    = { 0x00,0x03 };

    CipherSuite TLS_RSA_WITH_RC4_128_MD5

    = { 0x00,0x04 };

    CipherSuite TLS_RSA_WITH_RC4_128_SHA

    = { 0x00,0x05 };

    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

    = { 0x00,0x06 };

    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA

    = { 0x00,0x07 };

    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x08 };

    CipherSuite TLS_RSA_WITH_DES_CBC_SHA

    = { 0x00,0x09 };

    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x0A };

    Следующие определения CipherSuite используются для аутентифицированного сервером (и опционно клиентом) алгоритма Diffie-Hellman. DH обозначает шифровой набор, в котором сертификат сервера содержит параметры алгоритма Diffie-Hellman, подписанные провайдером сертификата CA (certificate authority). DHE обозначает временный Diffie-Hellman, где параметры Diffie-Hellman подписаны с помощью DSS- или RSA-сертификата, который подписан посредством CA. Используемый алгоритм подписи специфицирован согласно параметрам DH или DHE. Сервер может запросить от клиента сертификат RSA или DSS, пригодный для подписи, чтобы аутентифицировать клиента. Он может запросить также сертификат Diffie-Hellman. Любой сертификат Diffie-Hellman, предоставленный клиентом должен использовать параметры (группа и генератор), описанные сервером.

    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x0B };

    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA

    = { 0x00,0x0C };

    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x0D };

    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x0E };

    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA

    = { 0x00,0x0F };

    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x10 };

    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x11 };

    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA

    = { 0x00,0x12 };

    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x13 };

    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x14 };

    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA

    = { 0x00,0x15 };

    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x16 };

    Следующие шифровые наборы используются для полностью анонимного обмена с применением алгоритма Diffie-Hellman, в котором ни один из партнеров не аутентифицирован. Заметим, что этот режим уязвим для атак 'посредника' (man-in-the-middle) и по этой причине неприемлем.

    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

    = { 0x00,0x17 };

    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5

    = { 0x00,0x18 };

    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

    = { 0x00,0x19 };

    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA

    = { 0x00,0x1A };

    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

    = { 0x00,0x1B };

    Все шифровые наборы, чей первый байт равен 0xFF, рассматриваются частными и могут быть использованы для определения локальных/экспериментальных алгоритмов.

    Дополнительные шрифтовые наборы могут быть зарегистрированы путем публикации документа RFC, который специфицирует этот набор, включая необходимую протокольную информацию TLS, кодировку сообщений, получение предмастерных секретных кодов, симметричного шифрования, MAC-вычисления и ссылки на описания используемых алгоритмов. Редакционная комиссия RFC по своему разумению может опубликовать и неполное описание шифрового набора, если сочтет, что данное описание представляет определенный интерес.

    Коды шифровых наборов { 0x00, 0x1C } и { 0x00, 0x1D } зарезервированы, чтобы избежать конфликта с наборами, базирующимися на Fortezza в SSL 3.

    A.6. Параметры безопасности

    Эти параметры безопасности определены протоколом диалога TLS и передаются уровню записи TLS, для того чтобы инициализировать состояние соединения. SecurityParameters включают в себя:

    enum { null(0), (255) } CompressionMethod;
    enum { server, client } ConnectionEnd;
    enum { null, rc4, rc2, des, 3des, des40, idea }
    BulkCipherAlgorithm;
    enum { stream, block } CipherType;
    enum { true, false } IsExportable; enum { null, md5, sha } MACAlgorithm;

    /* Алгоритмы специфицированы в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm и могут быть добавлены. */

    struct { ConnectionEnd entity;
    BulkCipherAlgorithm bulk_cipher_algorithm;
    CipherType cipher_type;
    uint8 key_size;
    uint8 key_material_length;
    IsExportable is_exportable;
    MACAlgorithm mac_algorithm;
    uint8 hash_size;
    CompressionMethod compression_algorithm;
    opaque master_secret[48];
    opaque client_random[32];
    opaque server_random[32];
    } SecurityParameters;

    B. Словарь

    Протокол приложения

    Протокол приложения является протоколом, который функционирует поверх транспортного уровня (напр., TCP/IP). Среди примеров можно назвать HTTP, TELNET, FTP и SMTP.

    Асимметричный шифр

    Смотри криптографию с общедоступным ключом

    Аутентификация

    Аутентификация - это механизм, который предоставляет возможность одному партнеру идентифицировать другого партнера

    Блочный шифр

    Блочный шифр - это алгоритм, который работает с фиксированными группами битов открытого текста, называемых блоками. 64 бита - обычный размер блока

    Массовый шифр

    Алгоритм симметричного шифрования, используемый для кодирования больших объемов данных.

    Цепочный блок-шифр (CBC)

    CBC является режимом, в котором каждый блок исходного текста закодированного блочным шифром сначала объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или в случае первого блока, с вектором инициализации). При дешифровании каждый блок сначала дешифруется, а затем объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или IV).

    Сертификат

    В качестве части протокола X.509, сертификаты выдаются проверенным провайдером (Certificate Authority) и обеспечивают строгую связь между идентичностью партнера, содержат некоторые другие атрибуты, а также общедоступный ключ

    Клиент

    Субъект, который инициирует TLS-соединение с сервером. Различие между сервером и клиентом заключается в том, что сервер обычно является аутентифицированным, в то время как клиент может быть аутентифицирован только опционно.

    Ключ записи клиента

    Ключ, используемый клиентом для шифрования записываемых данных.

    Секретный код MAC записи клиента

    Секретные данные, используемые для аутентификации информации, которую пишет клиент.

    Соединение

    Соединение - это транспортная среда (согласно определению модели OSI), которая предоставляет приемлемый тип услуг. Для TLS, такие соединения служат для установления канала между партнерами. Соединения прозрачны. Каждое соединение сопряжено с одной сессией.

    Стандарт шифрования данных DES (Data Encryption Standard)

    DES является широко используемым алгоритмом симметричного шифрования. DES представляет собой блочный шифр с 56 битным ключом и размером блока в 8 байтов. Заметим, что в TLS, для целей генерации ключей, DES рассматривается как имеющий 8-байтовую длину ключа (64 бита), но при этом обеспечивает безопасность на уровне 56 бит. (Младший бит каждого ключевого байта устанавливается с учетом формирования определенной четности каждого ключевого байта). DES может также работать в режиме, где используется три независимых ключа и три шифрования для каждого блока данных; при этом ключ имеет длину 168 бит (24 байта в методе генерации ключей TLS) и обеспечивает безопасность, соответствующую 112 битам. [DES], [3DES]

    Стандарт цифровой подписи DSS (Digital Signature Standard)

    Стандарт цифровой подписи, включая алгоритм цифровой подписи DSA, одобренный национальным институтом стандартов и технологии США, определенный в NIST FIPS PUB 186, "Digital Signature Standard," май, 1994. [DSS]

    Цифровая подпись

    Цифровые подписи используют криптографию с общедоступным ключом и однопроходные хэш-функции, для того чтобы аутентифицировать подписанные данные и гарантировать их целостность.

    Диалог

    Начальное согласование между клиентом и сервером, которое позволяет определить параметры транзакции.

    Вектор инициализации (IV)

    Когда используется блочный шифр в режиме CBC, перед шифрованием вектор инициализации объединяется с первым блоком исходного текста с помощью операции исключающее ИЛИ.

    IDEA

    64-битовый блочный шифр, разработанный Xuejia Lai и James Massey. [IDEA]

    Код аутентификации сообщения (MAC)

    Код аутентификации сообщения представляет собой однопроходный хэш, вычисленный для сообщения и некоторых секретных данных. Его трудно взломать без знания секретных данных. Его целью является определение того, было ли сообщение модифицировано при транспортировке.

    Мастерный секретный код

    Безопасные секретные данные, используемые для генерации ключей шифрования, секретных кодов MAC и IV.

    MD5

    MD5 представляет собой безопасную хэш-функцию, которая преобразует поток данных произвольного размера в дайджест фиксированного размера (16 байт). [MD5]

    Криптография с общедоступным ключом

    Класс криптографических методов, использующих двух-ключевой шифр. Сообщения, зашифрованные с помощью общедоступного ключа, могут быть дешифрованы посредством ассоциированного с ним секретного ключа. Сообщения, подписанные с помощью секретного ключа могут быть верифицированы посредством общедоступного ключа.

    Однопроходная хэш-функция

    Однопроходное преобразование, которое конвертирует произвольное количество данных в хэш фиксированной длины. С вычислительной точки зрения трудно осуществить обратное преобразование. MD5 и SHA представляют собой примеры однопроходных хэш-функций.

    RC2

    Блочный шифр, разработанный Ron Rivest в компании RSA Data Security, Inc. [RSADSI] и описанный в [RC2].

    RC4

    Поточный шифр, лицензированный компанией RSA Data Security [RSADSI]. Совместимый шифр описан в [RC4].

    RSA

    Очень широко используемый алгоритм шифрования с общедоступным ключом, который может быть использован для шифрования или цифровой подписи. [RSA]

    salt

    Несекретные случайные данные, используемые для того, чтобы сделать передаваемые ключи шифрования более устойчивыми против атак.

    Сервер

    Сервер - это субъект, который реагирует на запросы клиента по установлению соединения.

    Сессия

    Сессия TLS - это ассоциация клиента и сервера. Сессия создается с помощью протокола диалога. Сессия определяет набор криптографических параметров, которые могут использоваться несколькими соединениями. Сессия служит для того, чтобы избежать издержек, связанных с согласованием параметров безопасности каждого соединения.

    Идентификатор сессии

    Идентификатор сессии представляет собой код, генерируемый сервером для того, чтобы идентифицировать конкретную сессию.

    Ключ записи сервера

    Ключ, используемый сервером для записи шифрованных данных.

    Секретный код MAC записи сервера

    Секретные данные, используемые для аутентификации информации, записанной сервером.

    SHA (Secure Hash Algorithm)

    Алгоритм SHA описан в FIPS PUB 180-1. Он формирует дайджест размером 20-байт. Заметим, что все ссылки на SHA в действительности содержат модифицированный алгоритм SHA-1. [SHA]

    SSL (Secure Socket Layer)

    Протокол Netscape SSL [SSL3]. TLS базируется на версии SSL 3.0

    Поточный шифр

    Алгоритм шифрования, который преобразует ключ в поток криптографически устойчивых данных, которые объединяются с исходным текстом с помощью операции исключающее ИЛИ

    Симметричный шифр

    Смотри массовый шифр.

    Безопасность транспортного уровня TLS (Transport Layer Security)

    Данный протокол; а также рабочая группа Transport Layer Security комиссии Internet Engineering Task Force (IETF).

    C. Определения CipherSuite

    CipherSuite

    Is key Exportable Exchange

    Шифр

    Хэш

    TLS_NULL_WITH_NULL_NULL

    * NULL

    NULL

    NULL

    TLS_RSA_WITH_NULL_MD5

    * RSA

    NULL

    MD5

    TLS_RSA_WITH_NULL_SHA

    * RSA

    NULL

    SHA

    TLS_RSA_EXPORT_WITH_RC4_40_MD5

    * RSA_EXPORT

    RC4_40

    MD5

    TLS_RSA_WITH_RC4_128_MD5

    RSA

    RC4_128

    MD5

    TLS_RSA_WITH_RC4_128_SHA

    RSA

    RC4_128

    SHA

    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

    * RSA_EXPORT

    RC2_CBC_40

    MD5

    TLS_RSA_WITH_IDEA_CBC_SHA

    RSA

    IDEA_CBC

    SHA

    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

    * RSA_EXPORT

    DES40_CBC

    SHA

    TLS_RSA_WITH_DES_CBC_SHA

    RSA

    DES_CBC

    SHA

    TLS_RSA_WITH_3DES_EDE_CBC_SHA

    RSA

    3DES_EDE_CBC

    SHA

    TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

    * DH_DSS_EXPORT

    DES40_CBC

    SHA

    TLS_DH_DSS_WITH_DES_CBC_SHA

    DH_DSS

    DES_CBC

    SHA

    TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

    DH_DSS

    3DES_EDE_CBC

    SHA

    TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

    * DH_RSA_EXPORT

    DES40_CBC

    SHA

    TLS_DH_RSA_WITH_DES_CBC_SHA

    DH_RSA

    DES_CBC

    SHA

    TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

    DH_RSA

    3DES_EDE_CBC

    SHA

    TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

    * DHE_DSS_EXPORT

    DES40_CBC

    SHA

    TLS_DHE_DSS_WITH_DES_CBC_SHA

    DHE_DSS

    DES_CBC

    SHA

    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

    DHE_DSS

    3DES_EDE_CBC

    SHA

    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

    * DHE_RSA_EXPORT

    DES40_CBC

    SHA

    TLS_DHE_RSA_WITH_DES_CBC_SHA

    DHE_RSA

    DES_CBC

    SHA

    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

    DHE_RSA

    3DES_EDE_CBC

    SHA

    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

    * DH_anon_EXPORT

    RC4_40

    MD5

    TLS_DH_anon_WITH_RC4_128_MD5

    DH_anon

    RC4_128

    MD5

    TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

    DH_anon

    DES40_CBC

    SHA

    TLS_DH_anon_WITH_DES_CBC_SHA

    DH_anon

    DES_CBC

    SHA

    TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

    DH_anon

    3DES_EDE_CBC

    SHA

    * Указывает, что IsExportable = истинно

    Алгоритм ключевого обмена

    Описание

    Ограничение на размер ключа

    DHE_DSS

    Ephemeral DH with DSS signatures

    None

    DHE_DSS_EXPORT

    Ephemeral DH with DSS signatures

    DH = 512 bits

    DHE_RSA

    Ephemeral DH with RSA signatures

    None

    DHE_RSA_EXPORT

    Ephemeral DH with RSA signatures

    DH = 512 bits, RSA = none

    DH_anon

    Anonymous DH, no signatures

    None

    DH_anon_EXPORT

    Anonymous DH, no signatures

    DH = 512 bits

    DH_DSS

    DH with DSS-based certificates

    None

    DH_DSS_EXPORT

    DH with DSS-based certificates

    DH = 512 bits

    DH_RSA

    DH with RSA-based certificates

    None

    DH_RSA_EXPORT

    DH with RSA-based certificates

    DH = 512 bits, RSA = none

    NULL

    Отсутствие ключевого обмена

    N/A

    RSA

    Ключевой обмен RSA

    None

    RSA_EXPORT

    Ключевой обмен RSA

    RSA = 512 бит

    Ограничение на размер ключа характеризуют максимальную длину ключевого общедоступного кода, который может быть легально использован в экспортируемом шифровом наборе.

    Шифр

    Тип

    <Ключевой
    материал
    Расширенный
    ключевой материал

    Эффективное
    число бит в ключе

    Размер IV

    Размер
    блока

    NULL *

    Поток

    0

    0

    0

    0

    N/A

    IDEA_CBC

    Блок

    16

    16

    128

    8

    8

    RC2_CBC_40 *

    Блок

    5

    16

    40

    8

    8

    RC4_40 *

    Поток

    5

    16

    40

    0

    N/A

    RC4_128

    Поток

    16

    16

    128

    0

    N/A

    DES40_CBC *

    Блок

    5

    8

    40

    8

    8

    DES_CBC

    Блок

    8

    8

    56

    8

    8

    3DES_EDE_CBC

    Блок

    24

    24

    168

    8

    8

    * Указывает IsExportable = 'истинно'.

    Тип

    Указывает является ли шифр поточным или блочным, работающим в режиме CBC.

    Key Material

    Число байтов из key_block, которые используются для генерации ключей записи.

    Expanded Key Material

    Число байтов действительно передаваемых алгоритму шифрования

    Эффективные биты ключа

    Сколько энтропийного материала, содержащегося в материале ключа, передается программам шифрования.

    Размер IV

    Сколько данных нужно сгенерировать для вектора инициализации (initialization vector). Нуль - для поточных шифров; число, равное размеру блока для блочных шифров.

    Размер блока

    Количество данных, которые блочный шифр преобразует за один раз; блочный шифр, работающий в режиме CBC, может переработать блок с размером четным кратным величине его блока.

    Хэш-функция

    Размер хэша

    Размер заполнителя

    NULL

    0

    0

    MD5

    16

    48

    SHA

    20

    40

    D. Замечания о реализации

    D.1. Временные ключи RSA

    Экспортные ограничения США устанавливает верхний предел длины ключей RSA равный 512 битам, но не вводят ограничений на размер RSA ключей, используемых для цифровых подписей. Часто нужны сертификаты длиннее 512 бит, так как 512-битные RSA ключи не достаточно безопасны для особо важных транзакций или для приложений требующих долговременной безопасности. Некоторые сертификаты предназначены исключительно для цифровых подписей и не могут использоваться для ключевого обмена.

    Когда общедоступный ключ в сертификате не может быть использован для шифрования, сервер подписывает временный RSA-ключ, который затем пересылается. В экспортируемых приложениях, временный RSA-ключ должен иметь максимально возможную длину (т.e., 512 бит). Так как 512-битовые RSA-ключи имеют относительно низкую безопасность, они должны часто заменяться. Для обычных коммерческих применений предлагается, чтобы ключи заменялись ежедневно или после каждых 500 транзакций, или даже чаще, если это возможно. Заметим, что, так как допускается многократное использование временного ключа, он должен каждый раз при использовании подписываться.

    Генерация ключа RSA является трудоемким процессом. Во многих случаях, процессу формирования ключа может быть приписан низкий фоновый приоритет. Как только сформирован новый ключ, старый временный ключ может быть заменен.

    D.2. Генерация псевдослучайных чисел и стартовые коды (Seeding)

    TLS требует наличия криптографически безопасного генератора псевдослучайных чисел (PRNG). Должны быть приняты меры для формирования стартовых кодов такого PRNG. Доступны генераторы PRNG, базирующиеся на безопасных хэш операциях, например, MD5 и/или SHA, но они не могут предоставить большую безопасность, чем та, которая определяется размером псевдослучайного генерируемого числа. (Например: генератор, базирующийся на MD5 обычно гарантирует безопасность на уровне 128 бит.)

    Чтобы оценить необходимую длину порождающего кода, следует добавить несколько битов непредсказуемой информации к каждому байту порождающего кода. Например: времена нажатия клавиш, полученные от стандартного 18.2 кГц PC таймера, может бать 1-2 безопасных бита, но в любом случае размер этого кода должен быть не менее 16 бит. В качестве порождающего кода для 128-битового генератора PRNG может потребоваться приблизительно 100 таких таймерных кодов.

    Функции порождающих кодов в RSAREF и в версиях BSAFE до 3.0 не имеют порядковой зависимости. Например: если предоставлены 1000 бит порождающего кода, по одному за раз в результате 1000 обращений к этой функции, PRNG окажется в состоянии, которое зависит только от числа 0 или 1 в порождающем коде (т.e., имеется 1001 возможных конечных состояний). Приложения, использующие BSAFE или RSAREF должны предпринимать дополнительные меры для обеспечения нужных порождающих кодов. Это может быть осуществлено путем накопления битов порождающего кода в буфере и обработки их как целое. Нужно только учитывать, что такие меры могут создать автокорреляции кодов.

    D.3. Сертификаты и аутентификация

    За верификацию целостности сертификата отвечает приложение, оно должно также поддерживать аннулирование сообщений, содержащих сертификат. Сертификаты должны всегда верифицироваться, чтобы гарантировать корректность подписи (СА). Выбор и добавление доверительных провайдеров сертификатов (СА) следует делать осмотрительно. Пользователи должны иметь возможность просмотреть информацию о сертификате и корневом провайдере сертификатов (CA).

    D.4. Шифровые наборы

    TLS поддерживает широкий диапазон размеров ключей и уровней безопасности, включая те, которые предоставляют минимальную или никакой безопасности. Корректная реализация не будет поддерживать много шифровых наборов. Например: 40-битовое шифрование легко ломается, поэтому приложения, требующие надежной безопасности, не должны разрешать применение 40-битовых ключей. Аналогично, анонимный алгоритм Diffie-Hellman не надежен, так как уязвим для атак 'посредников' (man-in-the-middle). Приложения должны накладывать также ограничения на минимальный и максимальный размер ключей. Например: сертификатные цепочки, содержащие 512-битные ключи RSA или подписи не могут считаться удовлетворительными для задач, требующих высокой безопасности.

    E. Совместимость с SSL

    По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.

    TLS версии 1.0 и SSL 3.0 очень схожи. Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии (TLS 1.0). Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.

    Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.

    Всякий раз, когда клиент уже знает верхний протокол, известный серверу (например, когда возобновляется сессия), он должен инициировать соединение в рамках этого протокола.

    Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.

    Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий.

    Следующие шифровые спецификации являются переходными от SSL версии 2.0. Они предполагают использования RSA для ключевого обмена и аутентификации.

    V2CipherSpec TLS_RC4_128_WITH_MD5

    = { 0x01,0x00,0x80 };

    V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5

    = { 0x02,0x00,0x80 };

    V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5

    = { 0x03,0x00,0x80 };

    V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5

    = { 0x04,0x00,0x80 };

    V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5

    = { 0x05,0x00,0x80 };

    V2CipherSpec TLS_DES_64_CBC_WITH_MD5

    = { 0x06,0x00,0x40 };

    V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5

    = { 0x07,0x00,0xC0 };

    Шифровые спецификации совместимые с TLS могут быть включены в сообщения client hello версии 2.0, используя описанный ниже синтаксис. Любой элемент V2CipherSpec с первым байтом равным нулю будет игнорироваться серверами версии 2.0. Клиенты, посылающие любую из перечисленных выше спецификаций V2CipherSpecs должны также включать и TLS-эквивалент (смотри приложение A.5):

    V2CipherSpec (see TLS name) = { 0x00, CipherSuite };

    E.1. Hello клиента версия 2

    Сообщение client hello версии 2.0 представлены ниже. Истинные определения предполагаются совпадающими со спецификацией SSL версии 2.0.

    uint8 V2CipherSpec[3];
    struct { uint8 msg_type;
    Version version;
    uint16 cipher_spec_length;
    uint16 session_id_length;
    uint16 challenge_length;
    V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
    opaque session_id[V2ClientHello.session_id_length];
    Random challenge;
    } V2ClientHello;

    msg_type

    Это поле, в сочетании с полем версии, идентифицирует сообщение client hello версии 2. Значение поля должно быть равно единице (1).

    Version

    Высшее значение версии протокола, поддерживаемое клиентом (равно ProtocolVersion.version, смотри приложение A.1).

    cipher_spec_length

    Это поле равно полной длине поля cipher_specs. Оно не может быть равно нулю и должно быть кратным длине V2CipherSpec (3).

    session_id_length

    Это поле должно иметь значение нуль или 16. Если равно нулю, клиент формирует новую сессию. Если равно 16, поле session_id будет содержать 16 байт идентификации сессии.

    challenge_length

    Длина в байтах обращения клиента к серверу, чтобы аутентифицировать себя. Это значение должно равняться 32.

    cipher_specs

    Это список всех CipherSpecs, которые клиент хочет и может использовать. Здесь должна быть по крайней мере одна спецификация CipherSpec, приемлемая для сервера.

    session_id

    Если длина этого поля не равна нулю, оно будет содержать идентификатор сессии, которую клиент хочет возобновить.

    Challenge

    Обращение клиента к серверу с целью идентификации самого себя. Его значение представляет собой псевдослучайное число произвольной длины. Сервер TLS проверяет обращение клиента, чтобы получить данные ClientHello.random (дополненные лидирующими нулями, если это нужно), как это специфицировано в данном протоколе. Если длина обращения больше чем 32 байта, то используются только последние 32 байта. Допускается (но не обязательно) для сервера V3 отклонять V2 ClientHello, которые имеют меньше 16 байтов обращения клиента.

    Запросы возобновления TLS-сессии должны использовать сообщение TLS client hello.

    E.2. Избежание атак понижения версии посредником (man-in-the-middle)

    Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.

    Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт (менее значимые) заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.

    F. Анализбезопасности

    Протокол TLS создан для того, чтобы установить безопасное соединение между клиентом и сервером через канал не гарантирующий безопасность. В данном документе делаются несколько традиционных предположений, включая то, что атакующие имеют достаточно большие вычислительные ресурсы и не могут получить секретную информацию из источников, помимо протокольных. Предполагается, что атакующий может перехватить, модифицировать, уничтожать и подменить сообщения, посланные по коммуникационному каналу.

    F.1. Протокол диалога

    Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов.

    F.1.1. Аутентификация и обмен ключами

    TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.

    Общей целью процесса ключевого обмена является формирование pre_master_secret, известного партнерами обмена, но неизвестного хакерам. Код pre_master_secret будет использован для генерации master_secret (смотри раздел 8.1). Код master_secret необходим, чтобы сформировать сообщения верификации сертификата, шифровальных ключей, секретных кодов MAC финального сообщения (смотри разделы 7.4.8, 7.4.9 и 6.3). Путем посылки корректного финального сообщения (finished) партнеры подтверждают то, что они знают правильное значение pre_master_secret.

    F.1.1.1. Анонимный обмен ключами

    Полностью анонимные сессии могут быть реализованы с помощью ключевого обмена на основе алгоритмов RSA или Diffie-Hellman. При анонимном RSA, клиент шифрует pre_master_secret с помощью не сертифицированного общедоступного ключа сервера, полученного из его сообщения ключевого обмена. Результат посылается в сообщении ключевого обмена клиента. Так как злоумышленники не знают секретного ключа сервера, практически не реально для них дешифровать pre_master_secret. Заметим, что анонимные шифровые RSA-наборы в данном документе не определены.

    В случае алгоритма Diffie-Hellman, общедоступные параметры сервера содержатся в его сообщении ключевого обмена, а параметры клиента посылаются в его сообщении ключевого обмена. Злоумышленники, которые не знают секретных ключей, не способны выполнить вычисления согласно алгоритму Diffie-Hellman и получить правильный результат (т.e. pre_master_secret).

    Полностью анонимные соединения предоставляют защиту только против пассивных видов атак. Если только не используется надежно защищенный канал, позволяющий проверку того, что финальное сообщение не подменено злоумышленником, в ситуациях, где возможна активная атака 'посредника' (man-in-the-middle) необходима аутентификация сервера.

    F.1.1.2. Обмен ключами по схеме RSA с аутентификацией

    В случае RSA, ключевой обмен и аутентификация сервера совмещаются. Общедоступный ключ может содержаться в сертификате сервера или быть временным RSA-ключом, посланным в сообщении ключевого обмена сервера. Когда используются временные RSA-ключи, они подписываются сертификатом сервера RSA или DSS. Подпись включает текущее значение ClientHello.random, поэтому старые подписи и временные ключи не могут быть повторно использованы. Серверы могут использовать одиночный временный RSA-ключ для нескольких сессий.

    Опция временного ключа RSA полезна, если серверы нуждаются в больших сертификатах, но вынуждены соглашаться с правительственными регламентациями для размеров ключей при ключевом обмене.

    После проверки сертификата сервера, клиент шифрует pre_master_secret с помощью общедоступного ключа сервера. В случае успешной дешифровки pre_master_secret и выработки корректного финального сообщения, сервер демонстрирует, что он знает секретный ключ, соответствующий его сертификату.

    Когда RSA используется для ключевого обмена, клиенты аутентифицируются, используя сообщение верификации сертификата (смотри раздел 7.4.8). Клиент подписывает значение, полученное из master_secret и все предыдущие сообщения диалога. Эти сообщения диалога включают сертификат сервера, который связывает подпись с сервером, и ServerHello.random, связывающий подпись с текущим процессом диалога.

    F.1.1.3. Обмен ключами по схеме Diffie-Hellman с аутентификацией

    Когда используется пересылка ключей по схеме Diffie-Hellman, сервер может либо предоставить сертификат, содержащий фиксированные параметры Diffie-Hellman, либо использовать сообщение ключевого обмена сервера, чтобы послать набор временных параметров, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random до формирования подписи, чтобы гарантировать, что злоумышленник не сможет воспользоваться старыми параметрами. В любом случае клиент может проверить сертификат или подпись, чтобы убедиться в том, что параметры принадлежат серверу.

    Если клиент имеет сертификат, содержащий фиксированные параметры Diffie-Hellman, его сертификат содержит информацию, необходимую для ключевого обмена. Заметим, что в этом случае клиент и сервер получат один и тот же результат (т.e., pre_master_secret) каждый раз, когда они обмениваются информацией. Чтобы предотвратить пребывание в памяти pre_master_secret дольше, чем это требуется, этот код должен быть, как можно быстрее преобразован в master_secret. Параметры клиента Diffie-Hellman должны быть совместимыми с теми, что поставляются сервером для ключевого обмена.

    Если клиент имеет стандартный сертификат DSS или RSA или он не аутентифицирован, тогда клиент посылает набор временных параметров серверу в сообщении ключевого обмена клиента, затем опционно использует сообщение верификации сертификата, чтобы аутентифицировать себя.

    F.1.2. Атаки понижения версии

    Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если (и только если) два TLS-совместимых партнера используют диалог в SSL 2.0.

    Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является красивым, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.

    F.1.3. Регистрация атак против протокола диалога

    Атакующий может попытаться повлиять на диалоговый обмен, чтобы заставить партнеров выбрать другой алгоритм шифрования, отличный от того, который бы они выбрали сами. Так как многие реализации будут поддерживать 40-битовое экспортное шифрование, а некоторые могут даже поддерживать отсутствие шифрования или алгоритмы MAC, возможность такой атаки должна всегда учитываться.

    Для этой атаки злоумышленник должен активно изменить одно или более сообщений диалога. Если это произойдет, клиент и сервер вычислят разные значения для хэшей сообщения диалога. В результате, партнеры не воспримут друг от друга финальные сообщения. Без master_secret, злоумышленник не может восстановить финальные сообщения, таким образом, факт атаки будет раскрыт.

    F.1.4. Возобновляемые сессии

    Когда соединение установлено путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хэшируются вместе с master_secret сессии. Если установлено, что код master_secret не поврежден и что хэш-операции, использованные для получения ключей и секретных кодов MAC также безопасны, то соединение можно считать безопасным и независимым от предыдущих соединений. Атакующие не могут использовать известные ключи шифрования или секретные коды MAC, для того, чтобы скомпрометировать master_secret без нарушения исполнения операций хэширования.

    Сессии не могут возобновляться, если только клиент и сервер не хотят этого. Если любой из партнеров подозревает, что сессия скомпрометирована, или что сертификаты не действительны, он должен потребовать полного диалога. Для верхнего предела времени жизни идентификатора сессии предлагается значение 24 часа, так как атакующий, получивший значение master_secret может подменить скомпрометированного партнера пока сохраняется старое значение ID-сессии. Приложения, которые могут работать в относительно небезопасной среде не должны записывать ID-сессии в постоянную память.

    F.1.5. MD5 и SHA

    TLS использует хэш-функции весьма консервативно. Где возможно, как MD5, так и SHA используются вместе для того, чтобы не катастрофические дефекты в одном алгоритме не приводили к разрушения всего протокола.

    F.2. Защита прикладных данных

    Код master_secret кэшируется с помощью ClientHello.random и ServerHello.random, чтобы получить уникальные ключи для шифрования данных и секретные коды MAC для каждого соединения. Исходящие данные перед посылкой защищаются с помощью MAC. Для того чтобы исключить атаки, связанные с модификаций или воспроизведения сообщений, из секретного кода MAC вычисляется MAC, номер по порядку, длина сообщения, содержимое сообщения и две фиксированные символьные строки. Поле типа сообщения необходимо, чтобы гарантировать то, что сообщения, предназначенные для одного клиента слоя записи TLS, не будут переадресованы другому. Номер по порядку гарантирует, что попытки уничтожить или поменять порядок сообщений будут детектированы. Так как номера по порядку имеют 64 бита, они не могут быть переполнены. Сообщения от одного партнера не могут быть вставлены в выходные сообщения другого, так как они используют независимые секретные коды MAC. Аналогично, ключи записи сервера и клиента независимы, так что ключи поточных шифров используются только раз.

    Если атакующий расколол ключ шифрования, все сообщения, зашифрованные этим ключом, могут быть прочитаны. Аналогично, раскрытие ключа MAC может сделать возможной атаку, сопряженную с модификацией передаваемых сообщений. Так как MAC зашифрован, атаки модификации сообщений требуют также взлома и алгоритма шифрования.

    Секретные коды MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования.

    G. Патентное заявление

    Следует иметь в виду, что применение ряда алгоритмов ограничено действующими патентами. К их числу относятся, например, SSL (патент США No. 5,657,390; Netscape). Существуют ограничения на коммерческое использование алгоритма RSA (RSA Data Security, Inc.). Политика компании Netscape в этой области достаточно либеральна.

    Ссылки

    [3DES]

    W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.

    [BLEI]

    Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1--12, 1998.

    [DES]

    ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983.

    [DH1]

    W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84.

    [DSS]

    NIST FIPS PUB 186, "Digital Signature Standard," National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994.

    [FTP]

    Postel J., and J. Reynolds, "File Transfer Protocol", STD-9, RFC-959, October 1985.

    [HTTP]

    Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996.

    [HMAC]

    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC-2104, February 1997.

    [IDEA]

    X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

    [MD2]

    Kaliski, B., "The MD2 Message Digest Algorithm", RFC-1319, April 1992.

    [MD5]

    Rivest, R., "The MD5 Message Digest Algorithm", RFC-1321, April 1992.

    [PKCS1]

    RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 1.5, November 1993.

    [PKCS6]

    RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard," version 1.5, November 1993.

    [PKCS7]

    RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard," version 1.5, November 1993.

    [PKIX]

    Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC-2459, January 1999.

    [RC2]

    Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, January 1998.

    [RC4]

    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress.

    [RSA]

    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

    [RSADSI]

    Contact RSA Data Security, Inc., Tel: 415-595-8782

    [SCH]

    B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994.

    [SHA]

    NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994.

    [SSL2]

    Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.

    [SSL3]

    A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.

    [TCP]

    Postel, J., "Transmission Control Protocol," STD-7, RFC 793, September 1981.

    [TEL]

    Postel J., and J. Reynolds, "Telnet Protocol Specifications", STD-8, RFC-854, May 1993.

    [TEL]

    Postel J., and J. Reynolds, "Telnet Option Specifications", STD-8, RFC-855, May 1993.

    [X509]

    CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.

    [XDR]

    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995.

    Архивы по рассматриваемой тематике смотри на сервере:

    http://www.imc.org/ietf-tls/mail-archive/

    Previous: 6.7 Безопасность WEB-серверов    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.9 Квантовая криптография


    previous up down next index index
    Previous: 6.8 Протокол TLS версия 1.0    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.10 Идентификатор доступа к сети

    6.9 Квантовая криптография
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Базовой задачей криптографии является шифрование данных и аутентификация отправителя. Это легко выполнить, если как отправитель, так и получатель имеют псевдослучайные последовательности бит, называемые ключами. Перед началом обмена каждый из участников должен получить ключ, причем эту процедуру следует выполнить с наивысшим уровнем конфиденциальности, так чтобы никакая третья сторона не могла получить доступ даже к части этой информации. Задача безопасной пересылки ключей может быть решена с помощью квантовой рассылки ключей QKD (Quantum Key Distribution). Надежность метода зиждется на нерушимости законов квантовой механики. Злоумышленник не может отвести часть сигнала с передающей линии, так как нельзя поделить электромагнитный квант на части. Любая попытка злоумышленника вмешаться в процесс передачи вызовет непомерно высокий уровень ошибок. Степень надежности в данной методике выше, чем в случае применения алгоритмов с парными ключами (например, RSA). Здесь ключ может генерироваться во время передачи по совершенно открытому оптическому каналу. Скорость передачи данных при этой технике не высока, но для передачи ключа она и не нужна. По существу квантовая криптография может заменить алгоритм Диффи-Хелмана, который в настоящее время часто используется для пересылки секретных ключей шифрования по каналам связи.

    Первый протокол квантовой криптографии (BB84) был предложен и опубликован в 1984 году Беннетом и Брассардом. Позднее идея была развита Экертом в 1991 году. В основе метода квантовой криптографии лежит наблюдение квантовых состояний фотонов. Отправитель задает эти состояния, а получатель их регистрирует. Здесь используется квантовый принцип неопределенности, когда две квантовые величины не могут быть измерены одновременно с требуемой точностью. Так поляризация фотонов может быть ортогональной диагональной или циркулярной. Измерение одного вида поляризации рэндомизует другую составляющую. Таким образом, если отправитель и получатель не договорились между собой, какой вид поляризации брать за основу, получатель может разрушить посланный отправителем сигнал, не получив никакой полезной информации.

    Отправитель кодирует отправляемые данные, задавая определенные квантовые состояния, получатель регистрирует эти состояния. Затем получатель и отправитель совместно обсуждают результаты наблюдений. В конечном итоге со сколь угодно высокой достоверностью можно быть уверенным, что переданная и принятая кодовые последовательности тождественны. Обсуждение результатов касается ошибок, внесенных шумами или злоумышленником, и ни в малейшей мере не раскрывает содержимого переданного сообщения. Может обсуждаться четность сообщения, но не отдельные биты. При передаче данных контролируется поляризация фотонов. Поляризация может быть ортогональной (горизонтальной или вертикальной), циркулярной (левой или правой) и диагональной (45 или 1350).

    В качестве источника света может использоваться светоизлучающий диод или лазер. Свет фильтруется, поляризуется и формируется в виде коротких импульсов малой интенсивности. Поляризация каждого импульса модулируется отправителем произвольным образом в соответствии с одним из четырех перечисленных состояний (горизонтальная, вертикальная, лево- или право-циркулярная).

    Получатель измеряет поляризацию фотонов, используя произвольную последовательность базовых состояний (ортогональная или циркулярная). Получатель открыто сообщает отправителю, какую последовательность базовых состояний он использовал. Отправитель открыто уведомляет получателя о том, какие базовые состояния использованы корректно. Все измерения, выполненные при неверных базовых состояниях, отбрасываются. Измерения интерпретируются согласно двоичной схеме: лево-циркулярная поляризация или горизонтальная - 0, право-циркулярная или вертикальная - 1. Реализация протокола осложняется присутствием шума, который может вызвать ошибки. Вносимые ошибки могут быть обнаружены и устранены с помощью подсчета четности, при этом один бит из каждого блока отбрасывается. Беннет в 1991 году предложил следующий протокол.

    1. Отправитель и получатель договариваются о произвольной перестановке битов в строках, чтобы сделать положения ошибок случайными.
    2. Строки делятся на блоки размера k (k выбирается так, чтобы вероятность ошибки в блоке была мала).
    3. Для каждого блока отправитель и получатель вычисляют и открыто оповещают друг друга о полученных результатах. Последний бит каждого блока удаляется.
    4. Для каждого блока, где четность оказалась разной, получатель и отправитель производят итерационный поиск и исправление неверных битов.
    5. Чтобы исключить кратные ошибки, которые могут быть не замечены, операции пунктов 1-4 повторяются для большего значения k.
    6. Для того чтобы определить, остались или нет необнаруженные ошибки, получатель и отправитель повторяют псевдослучайные проверки:
    • Получатель и отправитель открыто объявляют о случайном перемешивании позиций половины бит в их строках.
    • Получатель и отправитель открыто сравнивают четности. Если строки отличаются, четности должны не совпадать с вероятностью 1/2.
    • Если имеет место отличие, получатель и отправитель, использует двоичный поиск и удаление неверных битов.
    1. Если отличий нет, после m итераций получатель и отправитель получают идентичные строки с вероятностью ошибки 2-m.

    Схема реализация однонаправленного канала с квантовым шифрованием показана на рис. .1. Передающая сторона находится слева, а принимающая - справа. Ячейки Покеля служат для импульсной вариации поляризации потока квантов передатчиком и для анализа импульсов поляризации приемником. Передатчик может формировать одно из четырех состояний поляризации (0, 45, 90 и 135 градусов). Собственно передаваемые данные поступают в виде управляющих сигналов на эти ячейки. В качестве канала передачи данных может использоваться оптическое волокно. В качестве первичного источника света можно использовать и лазер.


    Рис. .1. Практическая схема реализации идеи квантовой криптографии

    На принимающей стороне после ячейки Покеля ставится кальцитовая призма, которая расщепляет пучок на два фотодетектора (ФЭУ), измеряющие две ортогональные составляющие поляризации. При формировании передаваемых импульсов квантов приходится решать проблему их интенсивности. Если квантов в импульсе 1000, есть вероятность того, что 100 квантов по пути будет отведено злоумышленником на свой приемник. Анализируя позднее открытые переговоры между передающей и принимающей стороной, он может получить нужную ему информацию. В идеале число квантов в импульсе должно быть около одного. Здесь любая попытка отвода части квантов злоумышленником приведет к существенному росту числа ошибок у принимающей стороны. В этом случае принятые данные должны быть отброшены и попытка передачи повторена. Но, делая канал более устойчивым к перехвату, мы в этом случае сталкиваемся с проблемой "темнового" шума (выдача сигнала в отсутствии фотонов на входе) приемника (ведь мы вынуждены повышать его чувствительность). Для того чтобы обеспечить надежную транспортировку данных логическому нулю и единице могут соответствовать определенные последовательности состояний, допускающие коррекцию одинарных и даже кратных ошибок.

    Дальнейшего улучшения надежности криптосистемы можно достичь, используя эффект EPR (Binstein-Podolsky-Rosen). Эффект EPR возникает, когда сферически симметричный атом излучает два фотона в противоположных направлениях в сторону двух наблюдателей. Фотоны излучаются с неопределенной поляризацией, но в силу симметрии их поляризации всегда противоположны. Важной особенностью этого эффекта является то, что поляризация фотонов становится известной только после измерения. На основе EPR Экерт предложил крипто-схему, которая гарантирует безопасность пересылки и хранения ключа. Отправитель генерирует некоторое количество EPR фотонных пар. Один фотон из каждой пары он оставляет для себя, второй посылает своему партнеру. При этом, если эффективность регистрации близка к единице, при получении отправителем значения поляризации 1, его партнер зарегистрирует значение 0 и наоборот. Ясно, что таким образом партнеры всякий раз, когда требуется, могут получить идентичные псевдослучайные кодовые последовательности. Практически реализация данной схемы проблематична из-за низкой эффективности регистрации и измерения поляризации одиночного фотона.

    Неэффективность регистрации является платой за секретность. Следует учитывать, что при работе в однофотонном режиме возникают чисто квантовые эффекты. При горизонтальной поляризации (H) и использовании вертикального поляризатора (V) результат очевиден - фотон не будет зарегистрирован. При 450 поляризации фотона и вертикальном поляризаторе (V) вероятность регистрации 50%. Именно это обстоятельство и используется в квантовой криптографии. Результаты анализа при передаче двоичных разрядов представлены в таблице .1. Здесь предполагается, что для передатчика логическому нулю соответствует поляризация V, а единице - +450, для принимающей стороны логическому нулю соответствует поляризация -450, а единице - Н.

    Передаваемый бит

    1

    0

    1

    0

    Поляризация передачи

    +450

    V

    +450

    V

    Поляризация приема

    -450

    -450

    H

    H

    Биты кода на приеме

    0

    0

    1

    1

    Результат приема

    -

    -

    +

    -

    Понятно, что в первой и четвертой колонке поляризации передачи и приеме ортогональны и результат детектирования будет отсутствовать. В колонках 2 и 3 коды двоичных разрядов совпадают и поляризации не ортогональны. По этой причине с вероятностью 50% может быть позитивный результат в любом из этих случаев (и даже в обоих). В таблице предполагается, что успешное детектирование фотона происходит для случая колонки 3. Именно этот бит становится первым битом общего секретного ключа передатчика и приемника.

    Однофотонные состояния поляризации более удобны для передачи данных на большие расстояния по оптическим кабелям. Такого рода схема показана на рис. .2 (алгоритм В92; R. J. Hughes, G. G. Luther, G. L. Morgan, C. G. Peterson and C. Simmons, "Quantum cryptography over optical fibers", Uni. of California, Physics Division, LANL, Los Alamos, NM 87545, USA).


    Рис. .2. Реализация алгоритма B92

    В алгоритме В92 приемник и передатчик создают систему, базирующуюся на интерферометрах Маха-Цендера. Отправитель определяет углы фазового сдвига, соответствующие логическому нулю и единице (F A=p/2), а приемник задает свои фазовые сдвиги для логического нуля (F B=3p/2) и единицы (F B=p). В данном контексте изменение фазы 2p соответствует изменению длины пути на одну длину волны используемого излучения.

    Хотя фотоны ведут себя при детектировании как частицы, они распространяются как волны. Вероятность того, что фотон, посланный отправителем, будет детектирован получателем равна

    PD = cos2{(F A - F B)/2}

    [1]

    и характеризует интерференцию амплитуд волн, распространяющихся по верхнему и нижнему путям (см. рис. .2). Вероятность регистрации будет варьироваться от 1 (при нулевой разности фаз) до нуля. Здесь предполагается, что отправитель и получатель используют фазовые сдвиги (F A, F B) = (0, 3 p/2) для нулевых бит и (F A, F B) = (p/2, p) для единичных битов (для алгоритма ВВ84 используются другие предположения).

    Для регистрации одиночных фотонов, помимо ФЭУ, могут использоваться твердотельные лавинные фотодиоды (германиевые и InGaAs). Для понижения уровня шума их следует охлаждать. Эффективность регистрации одиночных фотонов лежит в диапазоне 10-40%. При этом следует учитывать также довольно высокое поглощение света оптическим волокном (~0,3-3ДБ/км). Схема интерферометра с двумя волокнами достаточно нестабильна из-за разных свойств транспортных волокон и может успешно работать только при малых расстояниях. Лучших характеристик можно достичь, мультиплексируя оба пути фотонов в одно волокно [7] (см. рис. .3).


    Рис. .3. Интерферометр с одним транспортным волокном

    В этом варианте отправитель и получатель имеют идентичные неравноплечие интерферометры Маха-Цендера (красным цветом отмечены зеркала). Разность фаз длинного и короткого путей DT много больше времени когерентности светового источника. По этой причине интерференции в пределах малых интерферометров не происходит (Б). Но на выходе интерферометра получателя она возможна (В). Вероятность того, что фотонные амплитуды сложатся (центральный пик выходного сигнала интерферометра В) равна

    P = (1/8)[1 + cos(FA - FB)]

    [2]

    Следует заметить, что эта амплитуда сигнала в четыре раза меньше чем в случае, показанном на рис .2. Разветвители пучка (полупрозрачные зеркала) могут быть заменены на оптоволоконные объединители (coupler). Практические измерения для транспортного кабеля длиной 14 км показали эффективность генерации бита ключа на уровне 2,2 10-3 при частоте ошибок (BER) около 1,2%.

    Библиография

    1. Charles H. Bennett, Francois Bessette, Gilles Brassard, Louis Salvail, and John Smolin, "Experimental Quantum Cryptography", J. of Cryptography 5, 1992, An excellent description of a protocol for quantum key distribution, along with a description of the first working system.
    2. Charles H. Bennett, Gilles Brassard, and Artur Ekert, Quantum Cryptography, Scientific American, July, 1992 (www.scitec.auckland.ac.nz/king/Preprints/book/quantcos/aq/ qcrypt.html).
    3. www.cyberbeach.net/~jdwyer/quantum_crypto/quantum2.html
    4. www.cs.dartmoth.edu/jford/crypto.html
    5. A.K. Ekert, " Quantum Cryptography Based on Bell's Theorem", Phys. Rev. lett. 67, 661 (1991).
    6. Toby Howard, Quantum Cryptography, 1997, www.cs.man.ac.uk/aig/staff/toby /writing/PCW/qcrypt.html
    7. C.H. Bennet, " Quantum Cryptography Using Any Two Non-Orthogonal States", Phys. Rev. lett. 68, 3121 (1992).
    8. J. D. Franson and H.Ilves, "Quantum Cryptography Using Optical Fibers", Appl. Optics 33, 2949 (1994)
    9. R. J. Hughes et al., "Quantum Cryptography Over 14 km of Installed Optical Fiber", Los Alamos report LA-UR-95-2836, invited paper to appear in Proceeding of "Seventh Rochester Conference on Coherence and Quantum Optics", Rochester, NY, June 1995.
    10. С. H. Bennet et al., "Generalized Privacy Amplification", IEEE Trans. Inf. Theory 41, 1915 (1995)

    Previous: 6.8 Протокол TLS версия 1.0    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.10 Идентификатор доступа к сети


    previous up down next index index
    Previous: 6.9 Квантовая криптография    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 7 Программирование для сетей (новые идеи, принципы и возможности)

    6.10 Идентификатор доступа к сети
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Региональные Интернет сервис-провайдеры (ISP), работающие в пределах определенной области или провинции, стремятся объединить свои усилия с другими региональными провайдерами, для того чтобы обеспечить доступ к Интернет через телефонную сеть в пределах как можно большего пространства. Национальные ISP хотят совмещать свои операции с одним или более ISP в других странах, предлагая телефонный доступ к сети в пределах группы стран или даже континента.

    Бизнесмены хотели бы предложить своим служащим пакет услуг Интернет на глобальной основе. Эти услуги могут включать помимо традиционного доступа к Интернет, также безопасный доступ к корпоративным сетям через виртуальные частные сети (VPN), используя туннельные протоколы, такие как PPTP, L2F, L2TP и IPSEC в туннельном режиме.

    Для того чтобы улучшить взаимодействие роуминга и сервиса туннелирования, желательно иметь стандартизованный метод идентификации пользователей. Ниже предлагается синтаксис для идентификаторов доступа к сети NAI (Network Access Identifier). Примеры приложений, которые используют NAI, и описания семантики можно найти в [1].

    Здесь используются следующие определения:

    Идентификатор доступа к сети NAI

    Идентификатор доступа к сети (NAI) является идентификатором пользователя, представленным клиентом в ходе PPP-аутентификации. При роуминге целью NAI служит идентификация пользователя, а также содействие маршрутизации запроса аутентификации. Заметьте, что NAI не должен быть обязательно идентичным его электронному адресу или userID, выдаваемому на прикладном уровне для аутентификации.

    Сервер доступа к сети

    Сервер доступа к сети NAS (Network Access Server) представляет собой прибор, куда клиент "звонит" чтобы получить доступ к сети. В терминологии PPTP это называется концентратором доступа PPTP (PAC), а в терминологии L2TP, он называется концентратором доступа L2TP (LAC).

    Объем роуминга

    Объем роуминга можно определить, как способность использовать любого из имеющихся ISP, формально поддерживая только одну взаимосвязь покупатель-продавец.

    Туннельная услуга

    Туннельной услугой является любой сетевой сервис, допускаемый протоколами туннелирования, такими как PPTP, L2F, L2TP и IPSEC в туннельном режиме. Примером туннельной услуги может служить безопасный доступ к корпоративной сети через частные виртуальные сети (VPN).

    Как описано в [1], существует много услуг, использующих телефонный доступ, а число провайдеров, предлагающих такие услуги (в том числе для подвижных пользователей) стремительно растет.

    Для того чтобы обеспечить большой объем роуминга, одним из требований является способность идентифицировать "домашний" аутентификационный сервер пользователя. Эта функция в сети выполняется с помощью идентификатора NAI, посылаемого пользователем серверу NAS в процессе первичной PPP-аутентификации. Ожидается, что NAS будет использовать NAI как часть процесса открытия нового туннеля, с целью определения конечной точки этого туннеля.

    Идентификатор доступа к сети имеет форму user@realm (но это не обязательно почтовый адрес). Заметьте, что в то время как пользовательская часть NAI согласуется с BNF, описанной в [5], BNF строки описания области допускает использования в качестве первого символа цифры, что не разрешено BNF, описанной в [4]. Это изменение было сделано с учетом сложившейся в последнее время практикой, FQDN, такое как 3com.com вполне приемлемо.

    Заметьте, что хозяева NAS могут быть вынуждены модифицировать свое оборудование, чтобы обеспечить поддержку рассмотренного формата NAI. Оборудование, работающее с NAI должно работать с длиной кодов, по крайней мере, в 72 октета.

    Формальное определение NAI

    Грамматика для NAI представленная ниже, описана в ABNF, как это представлено в [7]. Грамматика для имен пользователей взята из [5], а грамматика имен областей является модифицированной версией [4].

    nai

    = username / ( username "@" realm )

    username

    = dot-string

    realm

    = realm "." label

    label

    = let-dig * (ldh-str)

    ldh-str

    = *( Alpha / Digit / "-" ) let-dig

    dot-string

    = string / ( dot-string "." string )

    string

    = char / ( string char )

    char

    = c / ( "\" x )

    let-dig

    = Alpha / Digit

    Alpha

    = %x41-5A / %x61-7A ; A-Z / a-z

    Digit

    = %x30-39 ;0-9

    c

    = < any one of the 128 ASCII characters, but not any special or SP >

    x

    = %x00-7F ; all 127 ASCII characters, no exception

    SP

    = %x20 ; Space character

    special

    = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" / %x22 / Ctl

    Ctl

    = %x00-1F / %x7F ; the control characters (ASCII codes 0 through 31 inclusive and 127)

    Примеры правильных идентификаторов сетевого доступа:

    fred@3com.com
    fred@foo-9.com
    fred_smith@big-co.com
    fred=?#$&*+-/^smith@bigco.com
    fred@bigco.com
    nancy@eng.bigu.edu
    eng!nancy@bigu.edu
    eng%nancy@bigu.edu

    Примеры неправильных идентификаторов сетевого доступа:

    fred@foo
    fred@foo_9.com
    @howard.edu
    fred@bigco.com@smallco.com
    eng:nancy@bigu.edu
    eng;nancy@bigu.edu
    @bigu.edu

    В данном разделе определено новое пространство имен, которое должно администрироваться (NAI-имена областей). Для того чтобы избежать создания каких-либо новых административных процедур, администрирование именных областей NAI возлагается на DNS.

    Имена областей NAI должны быть уникальными и право их использование для целей роуминга оформляется согласно механизму, применяемому для имен доменов FQDN (fully qualified domain name). При намерении использовать имя области NAI нужно сначала послать запрос по поводу возможности применения соответствующего FQDN.

    Заметьте, что использование FQDN в качестве имени области не предполагает обращения к DNS для локализации сервера аутентификации. В настоящее время аутентификационные серверы размещаются обычно в пределах домена, а маршрутизация этой процедуры базируется на локальных конфигурационных файлах. Реализации, описанные в [1], не используют DNS для поиска аутентификационного сервера в пределах домена, хотя это и можно сделать, используя запись SRV в DNS, что описано в [6]. Аналогично, существующие реализации не используют динамические протоколы маршрутизации или глобальную рассылку маршрутной информации.

    Ссылки

    [1]

    Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC-2194, September 1997.

    [2]

    Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC-2138, April 1997.

    [3]

    Rigney C., "RADIUS Accounting", RFC-2139, April 1997.

    [4]

    Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC-1035, November 1987.

    [5]

    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC-821, August 1982.

    [6]

    Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.

    [7]

    Crocker, D. and P. Overrell, "Augmented BNF for Syntax Specifications: ABNF", RFC-2234, November 1997.

    [8]

    Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC-2401, November 1998.

    [9]

    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC-2119, March 1997.

    Previous: 6.9 Квантовая криптография    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 7 Программирование для сетей (новые идеи, принципы и возможности)


    previous up down next index index
    Previous: 5.5 Конфигурирование сетевых систем    UP: 5 Диагностика локальных сетей и Интернет
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.1 Технические средства сетевой безопасности

    6 Сетевая безопасность
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Номер раздела Название раздела Объем в страницах Объем в кбайт
    6 Сетевая безопасность

    20

    219

    6.1 Технические средства сетевой безопасности

    3

    21

    6.2 Виртуальные локальные сети VLAN, Интранет

    4

    26

    6.3 Система Firewall

    2

    69

    6.4 Системы шифрования

    4

    38

    6.5 Протокол SSL. Безопасный уровень соединителей

    21

    37

    6.6 Безопасное ядро (SSH)

    2

    9

    6.7 Безопасность WEB-серверов

    2

    10

    6.8 Протокол TLS версия 1.0

    49

    250

    6.9 Квантовая криптография

    6

    54

    6.10 Идентификатор доступа к сети

    32

    11

    Совсем недавно персональная ЭВМ стоила в России дороже автомашины, сегодня же десятки (а может быть и сотни) тысяч ЭВМ работают дома, развлекая и зарабатывая деньги своим хозяевам. Сети ЭВМ из достояния научных центров постепенно стали обязательным атрибутом процветающих торговых фирм, банков, милиции, таможни, налоговые службы и т.д. Если раньше главной проблемой было создание сети и обеспечение доступа к Интернет, то сегодня по мере увеличения размеров сети проблема безопасности выходит на лидирующие позиции. Безопасность - комплексное понятие, это и ограничение нежелательного доступа, и сохранность информации, и живучесть самой сети. Актуальность проблемы подтверждает количество RFC-документов, опубликованных за последнее время [1-14, 18] по данной тематике (см. библиографию в конце данного раздела). Эту статью следует рассматривать как обзор возможных угроз и способов защиты. В основном это касается обычных сетей, не содержащих конфиденциальную или тем более секретную информацию. Но многие соображения, приводимые здесь, носят достаточно универсальный характер.

    Существуют юридические аспекты сетевой безопасности, организационные и программно-технические. Здесь будут рассмотрены два последних, тем более что следование букве закона не относится к числу главных добродетелей программистов. Рассмотрим сначала факторы, влияющие на надежность сети. Источниками ненадежности сети могут быть:

    • стихийные явления, к которым можно отнести отказы оборудования или питания, а также некомпетентность обслуживающего персонала;
    • несанкционированные действия операторов удаленных ЭВМ.

    Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли, и спросить не с кого. Начинать надо с того, что в вашей власти, а это, прежде всего, правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (uninterruptable power supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использовании специального интерфейса и соответствующего программного обеспечения, работающего согласно протоколу SNMP. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

    С использованием нанотехнологии фирма IBM разработала запоминающее устройство с плотностью записи данных 1 Терабит на квадратный дюйм. Это позволяет записать 25 миллионов страниц или 25 DVD дисков на площади одной почтовой марки. Система использует тысячи сверх тонких иголок из кремния, которые служат для формирования миниатюрных углублений в тонкой синтетической пленке. Вершины иголок имеют размер нескольких атомов (диаметр ≤ 10нм). Технология допускает перезапись.Внедрение этой технологии на какое-то время решит проблему.

    Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа exabyte емкостью 2.5-20 Гбайт достаточно широко используются, но относительно высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи для них не слишком высока). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более.

    К сожалению, помимо объективных причин на надежность и устойчивость работы сети влияет и субъективный фактор. Это, прежде всего некомпетентный персонал, различные компьютерные вирусы и хакеры. Скрытая безработица среди высоко квалифицированных программистов способствует распространению хакерства в России. Практическое отсутствие сетевых вирусов связано с ограниченностью сетей в России и со сложностью их написания, но этот барьер будет скоро преодолен и к этому следует готовиться уже сегодня. Еще в декабре 1994 года я получил предупреждение о распространении сетевых вирусов (good times и xxx-1) по Интернет:

    "there are two virus infected messages circulated in the internet.
    one is called "good times" and the other "xxx-1".
    do not read !! do not download !!! delete right away !!!!"

    (Не читайте!! Не загружайте!!! Немедленно уничтожайте!!!!)

    Или еще один более свежий пример

    "if you receive an email titled "it takes guts to say jesus" do not open it. it will erase everything on your hard drive. this information was announced yesterday morning from ibm; aol states that this is a very dangerous virus, much worse than "melissa," and that there is no remedy for it at this time."

    ЭВМ, подключенная к сети, потенциально всегда уязвима. Есть сообщения о вирусе cascade в сетях Novell, созданы вирусы, переносимые с помощью электронной почты (например, вирусы, базирующиеся на макросах WinWord), и т.д. Последние наиболее опасны, так как, проглядывая какое-то очередное сообщение, содержащее приложение (attachment), клиент может и не предполагать, какую угрозу это таит. Макро-вирус может выполнять функцию "троянского коня". Тривиальным и одновременно крайне полезным советом является рекомендация стирать, не читая, сообщения, содержащие исполняемое приложение, даже если это сообщение получено от вашего хорошего знакомого (это может быть рассылка, выполняемая мактро-вирусом, через его адресную книгу). Если есть сомнения, позвоните вашему знакомому, или пошлите ему mail, прежде чем читать подозрительное послание.

    Троянский конь. К этой категории относят две разновидности объектов. Один из них - программа, засылаемая в атакуемый узел, которая осуществляет перехват всего ввод с терминала, записывает эти данные в файл и позднее пересылает этот файл "хозяину этого коня". Другой объект является пассивным, выглядит безопасным и привлекательным. Например, находится в каталоге FTP-депозитария games и выглядит как игра. Легковерный клиент может скопировать такой файл и попытаться его запустить. Результатом может стать уничтожение содержимого жесткого диска.

    Кролики. Это программы, которые быстро размножаются в памяти или на диске, поглощая ресурсы ЭВМ, что может привести к повисанию или разрушению операционной системы. Сами по себе эти программы, как правило, не несут в себе разрушительных функций.

    Черви. Программы, напоминающие "кроликов", но способные перемещаться по сети Интернет от одного узла к другому (узлы должны иметь идентичную операционную среду).

    Макро вирусы. Вирусы, базирующие на макросах таких систем, как excel или winword. Опасность таких вирусов заключается в том, что они могут разноситься электронной почтой, когда соответствующие файлы подсоединены к почтовому сообщению. Попытка просмотра текста excel или winword приводит к заражению ЭВМ этим вирусом. После чего такая машина может стать сама разносчиком вируса. Из-за простоты заражения этот тип вируса в настоящее время наиболее опасен. Кроме того, он может иметь все свойства "троянского коня", что усугубляет опасность.

    Все перечисленные программы создавались людьми специально для нанесения вреда, их мотивации предмет изучения психологов и социологов. Но есть потенциально опасные объекты, специально не создаваемые для нанесения вреда. Это, прежде всего, программы, разработанные не профессионалами и не лишенные ошибок. Следует иметь в виду, что любая ошибка в программе опасна сама по себе, но она может стать объектом атаки хакера. По этой причине бездумное использование не сертифицированных программ несет в себе достаточно высокий уровень риска.

    Существуют и другие угрозы, например, так называемая "Молдавская связь". Суть этой уловки, использованной впервые одним из провайдеров в Молдове, заключается в том, что в каком-то депозитарии или web-странице приводится ссылка на некоторый привлекательный объект, например набор эротических картинок. Но для их просмотра предлагается скопировать себе специальную программу. При запуске оговоренной программы канал связи с местным провайдером разрывается и устанавливается связь через модем с другим удаленным провайдером. Это особенно опасно для людей, подключенных к Интернет через модем, так как может стоить им многие сотни долларов за пользование междугородним телефоном.

    Многие современные просмотрщики файлов (viewer) и вставные программы (plug-in), предоставляя определенные удобства, несут в себе ощутимые угрозы безопасности. Мало того, что они являются достаточно часто разносчиками вирусов, некоторые из них снабжены интерпретаторами команд. Такие интерпретаторы встраиваются, например, для создания справочной системы, но хакер может ввести туда свои, нужные только ему команды. А некоторые команды могут, скажем, разметить ваш диск. Подводя итоги, можно сказать, что всякая программа, имеющая макро процессор, потенциально опасна. По этой же причине следует избегать применения редактора emacs (UNIX) в качестве внешнего просмотрщика. Опасна и любая программа, способная запустить внешнее приложение. Примером такой программы можно назвать microsoft powerpoint, которая допускает во время презентации запуск любого приложения. Конфигурируя свою систему windows, не желательно объявлять powerpoint в качестве просмотрщика. И чем меньше программ просмотрщиков в системе, тем лучше для ее здоровья.

    Современные WEB-серверы довольно широко используют java-аплеты. При этом должны строго выполняться определенные правила.

    • Аплеты не могут читаться с или писаться на локальный диск.
    • Аплеты не должны иметь доступа к локальным внешним физическим устройствам.
    • Аплеты не должны иметь доступа к конфигурационной информации системы, включая ту, которая позволила бы им узнать с какой ОС они имеют дело.
    • Аплеты не должны исполнять системных команд или запускать внешние программы.
    • Аплеты не должны устанавливать сетевые соединения с машинами, кроме той, с которой они загружены.

    Если все эти условия выполняются, аплеты совершенно безопасны, но контролировать это желательно.

    При создании протоколов Интернет в начале 80-х годов авторы мало думали о безопасности. Предполагалось, что пользоваться сетью будут исключительно ответственные и добропорядочные люди. Но людям, к сожалению, свойственно преувеличивать свои положительные качества. Реальность оказалась не столь позитивна. Сказалась и любовь получать что-то бесплатно и врожденный разрушительный потенциал. Некоторые приемы хакеров описаны в разделе, посвященном протоколу TCP. Рассмотрим, что может произойти, если будет получен TCP-сегмент с битами SYN и FIN, равными 1. При получении такого сегмента TCP осуществляет переход в состояние close_wait. Если до этого не было установлено соединений, переход в это состояние не должен производиться, но большинство реализаций выполняют его. Такой переход крайне не желателен, так как в этом состоянии не работает таймер и система останется в нем вечно.

    Другой вид атак протокола TCP называется "syn flooding". Здесь используется трехшаговый диалог при установлении соединения (SYN -> syn+ack -> ack; см. описание протокола TCP в разделе 4.4.3). Когда ЭВМ-1 получает запрос syn от ЭВМ-2, она должна подождать в частично открытом состоянии, по крайней мере, 75 секунд. Это позволяет успешно устанавливать связь даже в условиях очень больших сетевых задержек. Проблема заключается в том, что многие реализации способны отслеживать ограниченное число соединений (по умолчания 5). ЭВМ-злоумышленник может воспользоваться ограниченностью очереди и послать атакуемой ЭВМ большое число SYN-запросов, не отвечая на присылаемые SYN+ACK. В результате очередь будет быстро переполнена и прием запросов на соединение прекратится до тех пор, пока очередь не будет обслужена или очищена по таймауту. Данный метод пригоден для отключения ЭВМ от сети, во всяком случае, на 75 сек. Этот вид атаки часто является частью процедуры проникновения, когда нужно заблокировать ЭВМ от получения нежелательных откликов.

    Существует разновидность атаки, когда хакер посылает данные в пакетах с адресом отправителя, отличным от его собственного (при этом трудно установить адрес, откуда такая атака предпринимается). Здесь имеются некоторые проблемы для атакующей стороны. ЭВМ-адресат посылает все отклики по указанному адресу отправителя, кроме того, хакеру нужно как-то выяснить порядковый номер сегмента, записываемый в каждый пересылаемый пакет. При установлении соединения оконечный сегмент, содержащий ACK, должен нести ISN (initial sequence number; cм. описание транспортного протокола TCP раздел 4.4.3) удаленной ЭВМ. Этот сегмент посылается ЭВМ, чей адрес указан в первоначальном запросе SYN. Хакер должен выяснить ISN каким-то иным способом (этому может помочь служба netstat). Так как ISN 32-разрядное число случайно угадать его совсем не просто. Но в большинстве систем (например, unix bsd) ISN берется из некоторого счетчика, содержимое которого увеличивается на 128 каждую секунду и на 64 после каждого нового соединения. Например:

    x -> s: syn(ISNx)
    s -> x: syn(ISNs), ack(ISNx) (получено искомое текущее значение кода ISNs)

    Таким образом, установив однажды соединение с нужной ЭВМ (s), некоторое время спустя можно с высокой вероятностью угадать значение ISN, послав несколько пакетов с разными значениями ISN. При завершении процедуры посылается сегмент SYN+ACK, который будет отвергнут, так как машина получатель не инициализировала связь. В пакете отклике будет установлен флаг RST и соединение окажется абортированным. Чтобы этого не произошло, хакер может предпринять атаку типа syn-flooding, что приведет к игнорированию SYN+ACK. В результате соединение будет установлено и хакер, празднуя победу, может продолжить свое черное дело, например, он может исполнить какую-либо r-команду на атакуемой ЭВМ. Если даже изменять ISN каждые 4 микросекунды, проблему угадывания разрешить не удастся. Радикальным решением может стать лишь псевдослучайная генерация ISN-кодов (при этом случайным образом должны задаваться не менее 16 бит). Решить проблему поможет шифрование соответствующей части содержимого пакета. Рассмотрим здесь еще несколько таких атак.

    Один из известных методов базируется на IP-опции "маршрутизации отправителя" (source routing). ЭВМ инициатор обмена может специфицировать маршрут, которым получатель должен воспользоваться при пересылке отклика. Маршрут может быть специфицирован так, чтобы он проходил через узел, контролируемый хакером. Эта, достаточно простая методика атаки, в настоящее время неэффективна, так как большинство маршрутизаторов сконфигурированы так, чтобы отфильтровывать пакеты с маршрутизацией отправителя.

    Интересные возможности предоставляет вариант, когда хакер вставляет свою машину на пути обмена двух других узлов (hijacking). Обычные методы атак (типа spoofing) могут не привести к успеху из-за необходимости идентификации (пароль!). В данном методе хакер позволяет завершиться установлению связи и аутентификации и только после этого перехватывает контроль над виртуальным каналом. Этот способ использует механизм "десинхронизации" tcp-соединения. Когда порядковый номер полученного пакета не совпадает с ожидаемым значением, соединение называется десинхронизованным. Полученный пакет в зависимости от его номера будет выброшен или буферизован (если он находится в пределах окна). Таким образом, если узлы, участвующие в обмене сильно десинхронизованы, приходящие к ним пакеты будут отбрасываться. Хакер в этом случае может вводить пакеты с корректными порядковыми номерами. Разумеется, это совсем просто, если машина хакера является транзитной, что позволяет ей "портить" или удалять нормальные пакеты и подменять их своими. Атака же возможна и в случае, когда машина хакера находится где угодно. В этом случае "отброшенные" пакеты могут вызвать посылку ACK, которые содержат ожидаемое значение порядкового номера пакета, но и они будут отвергнуты из-за неверного их номера и т.д.. При реализации этой схемы пересылается большое число "лишних" пакетов ACK. Количество их будет сколь угодно велико, по этой причине данная ситуация называется "штормом ACK'. Обмен уведомлениями (ACK) о неверных ISN будет продолжаться до тех пор, пока один из таких пакетов не будет потерян. Механизм обмена IP-дейтограммами устроен так, что вероятность потери тем выше, чем больше пакетов передается, т.е. процесс саморегулируется. Тем не менее, высокая интенсивность потока сегментов ACK может говорить об атаке. В норме процент сегментов ACK от общего потока TCP составляет 30-45%. Иллюстрацией данного метода нападения может служить рис. 6.1.

    Рис. 6.1

    Десинхронизация может быть осуществлена при установлении соединения. Хакер в этом случае обрывает процесс трехшагового диалога. После того как ЭВМ Б пошлет SYN+ACK ЭВМ А, ЭВМ хакера пошлет пакет от Б к А, который с помощью бита RST оповещает о закрытии соединения. После этого затевается новый трехшаговый диалог с целью установления соединения с А, но уже с другими кодами порядковых номеров. Схема алгоритма атаки показана на рис. 6.2 (Сравните с рис. 4.4.3.3 и 4.4.3.4).

    ЭВМ Б проигнорирует сообщения от А, так как они имеют неправильные (навязанные хакером) номера, а ЭВМ А проигнорирует сообщения от Б, так как ожидает, что они будут пронумерованы по-новому. Теперь хакер знает, какие номера нужны А и Б (непосредственно же А и Б взаимодействовать не могут, так как не знают правильных номеров) и может перехватывать, модифицировать или посылать сообщения по своему усмотрению как А, так и Б.

    Но десинхронизация может быть реализована и в ходе сессии. Если послать флаг RST в середине сессии, соединение будет закрыто, о чем будет оповещено приложение и пользователь. Для того чтобы вызвать десинхронизацию в середине сессии, не закрывая соединения, достаточно поменять порядковые номера в сообщениях. Протокол telnet имеет механизм, который позволяет решить такую задачу. В рамках протокола можно посылать команды nop ("Ничего не делать", согласитесь - хорошие команды!). Эти команды не производят никакого эффекта, но увеличивают ожидаемое значение порядкового номера сегмента. Послав некоторое количество таких команд, ЭВМ хакера вызовет десинхронизацию. Теперь только хакер знает правильные значения порядковых номеров пакетов и может начать свою подрывную работу.

    Одним из наиболее эффективных методов обнаружения таких атак помимо процента сегментов ACK является сравнение потоков ACK для сервера и клиента. Полной гарантией безопасности в такой ситуации может стать только шифрование на прикладном уровне, например по схеме kerberos. В случае использования почты хороший результат может дать электронная подпись (например, PGP).

    Атака на раннем этапе установления соединения может осуществляться следующим образом. Соединение при этом разрушается и вместо него формируется новое с другим значением ISN. Хакер прослушивает виртуальный канал и ждет сообщения SYN+ACK от сервера клиенту (вторая фаза установления соединения). При получении такого сообщения хакер посылает серверу RST-кадр, а затем SYN-пакет с теми же параметрами (TCP-порт), но с другим значением ISN (далее и на рис 6.2 этот кадр обозначается a_ack_0; префикс А указывает на принадлежность атакующей машине хакера). Сервер, получив RST, закроет прежнее соединение и, получив SYN, сформирует новое для того же порта, но с новым значением ISN. После чего пошлет клиенту кадр SYN+ACK. Детектировав это пакет хакер посылает серверу кадр ACK. При этом сервер переходит в состояние established. Клиент перешел в это состояние при получении от сервера первого кадра SYN+ACK. На рис. 6.2 не показан обмен пакетами ACK, вызванными получением некорректных значений ISN. Как сервер так и клиент находятся в несинхронизованном состоянии established. Обмен здесь полностью контролируется атакующей ЭВМ

    Рис. 6.2. Алгоритм атаки с использованием десинхронизации. Префикс А указывает на то, что сегмент послан атакующей ЭВМ; С - клиентом; s - сервером. Отправка атакующих кадров выделена малиновым цветом.

    Определенные услуги хакеру может оказать внутренний протокол маршрутизации rip. Этот протокол служит для рассылки информации о маршрутах в локальной сети и не требует контроля доступа, что всегда благоприятствует злоумышленникам. Хакер может разослать маршрутную информацию, которая убедит окружающие узлы в том, что наикратчайший путь во внешний мир проходит через ЭВМ хакера Х. Тогда все пакеты, адресованные за пределы локальной сети, будут сначала попадать в ЭВМ Х.

    Протокол управляющих сообщений ICMP носит вспомогательный характер (вспомним популярную утилиту ping, использующую этот протокол). Пакеты ICMP также не требуют проверки доступа (именно благодаря этому протокол пригоден для работы в масштабах Интернет). По одной этой причине протокол привлекателен для хакеров. Известны случаи, когда с его помощью люди с разных континентов бесплатно обменивались сообщениями. Пригоден протокол и для блокировки обслуживания. Для блокировки обслуживания используются icmp-сообщения "time exceeded" (превышено время) или "destination unreachable" (адресат недоступен). Первое сообщение означает, что предел указанный в поле TTL заголовка пакета превышен. Такое может произойти из-за зацикливания пакетов или, когда адресат расположен очень далеко. Сообщение "destination unreachable" имеет несколько значений. Но все они означают, что нет способа благополучно доставить пакет адресату. Оба сообщения вынуждают адресата немедленно прервать соединение. Для реализации своих коварных планов хакеру достаточно послать одно из этих сообщений одному или обоим участникам обмена.

    Протокол ICMP может использоваться и для перехвата пакетов. ICMP-сообщение "redirect" обычно используется внешними портами (gateway) сети в случаях, когда какая-то ЭВМ по ошибке полагает, что адресат находится вне локальной сети и направляет пакеты, адресованные ему, через внешний порт. Хакер может послать ICMP-сообщение "redirect" и вынудить другую ЭВМ посылать пакеты через узел, указанный хакером. У данного метода (также как и предыдущего с использованием RIP) имеется определенное ограничение - хакер и жертва должны находиться в пределах общей локальной сети.

    Ещё одним объектом атак может стать DNS (domain name service) локальной сети. Например, администратор узла durak.dura.com может принять решение разрешить только местные соединения. Это может быть специфицировано с помощью записи "allow *.dura.com", а не обязательно через указание IP-адресов. Тем более, что в сети может использоваться большое число блоков IP-адресов. Когда соединение установлено ЭВМ durak обращается к DNS для того, чтобы преобразовать IP-адрес отправителя в имя, которое затем служит для проверки условия, заданного администратором. Если хакер имеет доступ к местному DNS-серверу, он может заставить DNSоткликаться на его IP-адрес любым именем ЭВМ или домена. Зная об установленных администратором ограничениях, хакер может сделать так, что на запрос с его IP-адресом DNS будет откликаться именем "trustme.dura.com" (что удовлетворяет установленному ограничению). Такая атака может быть легко предотвращена путем повторного DNS-запроса с именем ЭВМ, присланным при первом запросе. Если IP-адрес, полученный при втором запросе, не совпадет с использованным в качестве параметра в первом, это означает, что DNS подверглась атаке.

    Для атаки DNS извне достаточно узнать номер используемого UDP порта и ISN. О способах определения ISN говорилось выше. Задача упрощается в тех случаях, когда начальным значением ISN является нуль. Номер же используемого в данный момент UDP-порта при определенном везении можно найти путем подбора, ведь здесь нет никакой аутентификации или ограничений на число попыток. DNS один из самых привлекательных объектов для атак, так как через посредство AXFR-запросов можно получить информацию об узлах, которые используют определенные версии ОС с известными слабостями, упрощающими вторжение.

    Точкой уязвимости могут быть загружаемые через сеть рабочие станции или Х-терминалы. Процедура загрузки предполагает использование протоколов RARP, TFTP и BOOTP. Все они практически не имеют сколько-нибудь серьезной защиты. Наиболее уязвим протокол RARP. Здесь желательно позаботиться о том, чтобы номер порта udp выбирался ЭВМ, осуществляющей загрузку случайным образом. В противном случае хакер может легко перехватит процедуру обмена и загрузить нужную ему конфигурацию программного обеспечения, обеспечив себе широкие ворота для проникновения. bootp предлагает дополнительные возможности защиты в виде 4-байтного случайного кода идентификатора процедуры (transaction ID). Это заметно мешает хакеру прервать процедуру и инициировать новую сессию загрузки (rebooting). Должны быть предприняты все меры, чтобы начатая процедура загрузки была своевременно завершена. Пребывание системы в промежуточном состоянии заметно облегчает разнообразные атаки.

    Некоторые другие виды атак описаны в разделе, посвященном протоколу http. Многие из перечисленных выше проблем решаются при использовании прокси серверов типа firewall .

    Но даже Firewall не может предотвратить атак со стороны хакеров, работающих внутри локальной сети. Здесь к их услугам огромный арсенал. Это, прежде всего, использование сетевого интерфейса для приема всех пакетов, следующих по сегменту (6-ой режим работы интерфейса), а также программные продукты типа tcpdump или Etherfind. Такой режим легко позволяет перехватывать незашифрованные пароли, определять используемые номера портов или ISN. К счастью такой комфорт для хакера предоставляется в пределах его логического сегмента, что стимулирует, кроме всего прочего, использование мостов, переключателей и локальных маршрутизаторов, которые ограничивают зону, где хакер может осуществлять перехваты. По этой же причине рекомендуется авторизованным администраторам работать с консоли, а не удаленного терминала. Следует иметь в виду, что обнаружить такого "шалуна" не так просто, ведь он может во многих случаях указывать в посылаемых пакетах не свой IP- и MAC-адрес.

    Еще одним инструментом взлома может оказаться протокол ARP. Хакер может послать большое число широковещательных запросов, содержащих несуществующий IP-адрес. ЭВМ при получении такого запроса должна его обработать и может попытаться его переадресовать какому-то серверу. Всё это уже само по себе нежелательно, так как порождает большой паразитный трафик. Помимо этого хакер может попытаться послать широковещательный отклик, сообщая свой MAC-адрес в качестве адреса места назначения. Это может при определенных условиях предоставить возможность перехвата трафика между ЭВМ, пославшей первичный запрос, и истинным узлом назначения. Таким образом, постоянный мониторинг широковещательных запросов следует считать одной из составных частей системы безопасности локальной сети (см. также Robert T. Morris, A Weakness in the 4.2bsd Unix TCP/IP Software, Computer Science Technical Report N 117, at&t Bell laboratories), тем более что такой мониторинг не пораждает дополнительного трафика.

    Определенную пользу с точки зрения безопасности может принести программы типа wrapper , которая позволяет отфильтровать нежелательные запросы и решить проблему аутентификации. Новые возможности в этой сфере предоставит новая версия протокола IPv6. Некоторые проблемы могут быть решены путем шифрования содержимого пакетов.

    Применение сетей расширяется со скоростью 20% в месяц. Внешний трафик мультинациональных организаций увеличивается со скоростью 30% в год, а только за 1996 год сетевые воры украли ценной информации на сумму более 10 млн. долларов США (www.cuviello.com/_potrfolio/_semaphore).

    Число зарегистрированных попыток нелегального проникновения в информационные системы растет экспоненциально, достигнув темпа прироста 60% в год. Но нужно принимать во внимание, что существенная часть таких попыток остается незамеченной или незарегистрированной. Адекватны этому и темпы роста расходов крупных фирм на средства и системы информационной безопасности.

    Следует, впрочем иметь в виду, что чем лучше сеть (или ЭВМ) защищена от хакеров, тем менее удобно в ней работать. Поэтому администратор сети всегда должен выбирать меньшее из зол, нельзя же делать лечение более опасным, чем сама болезнь.

    Хакер, пытающийся нелегально проникнуть в ЭВМ, обычно начинает с использования процедуры Finger, чтобы определить имена реальных пользователей сети или ЭВМ (имя одного пользователя обычно известно - это root). Администратор сети-жертвы может заблокировать работу Finger. Но именно этот протокол наряду с SMTP используется системами Whois, X.500 и FRED при поиске людей в сети Интернет. Заблокировав Finger, администратор усложняет общение с внешними сетями.

    Есть все же правила, следовать которым должен любой администратор. Среди них жесткое требование к выбору паролей и регулярной их смене является наиважнейшим. Известно, что 80% всех проблем, связанных с нелегальным проникновением в сеть, вызваны плохими паролями.

    Пароль должен содержать не менее 5-7 символов. Желательно, чтобы он включал в себя строчные и прописные символы, а также цифры. Любые имена, фамилии, общеизвестные географические названия, названия улиц, номер страхового полиса, кредитной карточки, домашний номер телефона (записанные обычным образом или задом на перед), последовательности клавишей типа qwerty или абвгд и т.д. совершенно непригодны в качестве паролей, так как их подбор, например, с помощью программы satan занимает не более 5 минут. Наиболее важные части системы могут быть защищены двойным паролем, но даже это не дает полной гарантии. Во-первых, имеется возможность перехвата ваших пакетов (например, с помощью программы tcpdump или ее аналога), когда вы вводите свой пароль с удаленного терминала. Во-вторых, существуют программы типа "троянского коня", которые, будучи засланы в многопользовательскую систему, перехватывают весь ввод с терминалов, записывают их в виртуальные файлы и спустя какое-то время пересылаются "хозяину коня". На этом арсенал орудий взлома не исчерпывается. Одним словом, если у вас имеется информация, доступ к которой не желателен, не храните ее в ЭВМ, подключенной к Интернет (или любой другой аналогичной сети). Следует иметь в виду, что "шалуны" могут быть и среди ваших коллег или друзей. Никогда ни при каких обстоятельствах не следует передавать свой пароль кому бы то ни было. Если это в вашей власти, помогите просящему получить к ЭВМ легальный доступ, но не передавайте пароль. В моей практике был случай, когда один программист из ИТЭФ передал свой пароль своему другу. Этот друг ради баловства через узел ИТЭФ заслал троянского коня в амстердамский телекоммуникационный узел. Факт засылки стал известен (для обнаружения используется программный пакет cops) и администратор сети прислал нам в институт оповещение об этом досадном инциденте. Были приняты административные меры к человеку, передавшему свой пароль (он был лишен определенных привилегий и доступа к ряду ЭВМ). Вряд ли какой-либо администратор мечтает о славе пособника сетевым террористам.

    Безопасность сети определяется ее администратором. Именно он должен позаботиться о распределении ответственности между пользователями и администраторами ЭВМ и субсетей, именно он определяет конфигурацию программного обеспечения узла, вырабатывает меры на случай вторжения или повреждения системы. Администратор сети формулирует требования к сетевым паролям и контролирует их выполнение, определяет время жизни паролей (рекомендуемое время замены паролей равно 3-6 месяцам, новый пароль должен радикально отличаться от старого).

    В тех случаях, когда ЭВМ помимо терминальных входов имеет доступ через модемы, используются, кроме того, так называемые "телефонные пароли" (dialup passwords). В этом случае во время процедуры logon помимо имени-идентификатора и пароля вводится также и телефонный пароль. Этот пароль является общим для всех пользователей на данной машине. Управляет этой процедурой исполняемый файл /etc/dpasswd. Программа имеет ряд опций. Сами пароли хранятся в закодированном виде в файле /etc/d_passwd. Если идентификация пользователя по названным выше трем параметром не увенчалась успехом, пользователю будет предложено повторить процедуру без указания того, какой из параметров введен неверно.

    Для того чтобы контролировать, кто, когда и сколько времени провел в вашей ЭВМ, имеется файл-дневник (log-файл), где производятся соответствующие записи (например, /etc/wtmp). В таблице 6.1 размещены ссылки на различные log-файлы.

    Таблица 6.1.

    Каталог и имя файла

    Описание

    /etc/bootplog

    Предназначен для документирования выполнения операций загрузки bootp

    /usr/adm/errlog

    Регистратор ошибок на жестком диске

    /usr/adm/messages

    Имя информационного файла syslog

    /usr/adm/sulog

    Журнал записи входов в систему суперпользователя (root)

    /usr/lib/cron/log

    Журнал регистрации исполнения команд cron (кто, что, когда). Могут записываться и сообщения об ошибках.

    /usr/spool/mqueue/syslog

    Журнал записи операций sendmail и сообщений об ошибках.

    Одной из мер безопасности в локальной сети может быть кодировка всех пакетов, посылаемых с удаленных терминалов. Для реализации этого надо модифицировать все сетевое программное обеспечение или оснастить сеть специальными аппаратными средствами. Принимая во внимание, что в России используется на 99% зарубежное сетевое программное обеспечение, а денег на специальное оборудование безопасности обычно не предусмотрено в бюджете, этот путь представляется пока не самым удобным. Шифрование предполагает две процедуры - собственно кодирование информации с использованием секретного ключа и пересылка секретного ключа. Для передачи секретных ключей, паролей доступа (если их нужно пересылать) и идентификации партнеров, участвующих в обмене (а это иногда крайне важно, достаточно вспомнить посылку ложной телеграммы графом Монте-Кристо) используется схема с открытым и секретным ключами или алгоритм Диффи-Хелмана.

    Схема с шифрованием проще реализовать для корпоративных сетей, т.е. для сетей принадлежащих одной фирме или отрасли (см. также раздел 6.5 и 6.6 ). Аналогичная схема может успешно использоваться между партнерами, которые заранее согласовали метод и ключи шифрования. Шифровка-дешифровка может проводиться аппаратным или программным образом для текстов или даже самих пересылаемых пакетов. Здесь предполагается наличие механизма пересылки ключей, подтверждения их получения и т.д. Шифрование не заменяет другие меры безопасности, так как несанкционированное вторжение может привести к потере или повреждению файлов, а в особо тяжелых случаях к разрушению всей операционной системы. В unix имеется две команды для шифрования - DES (data encryption standard) и crypt. Последняя команда базируется на старом методе кодирования, использованном в немецкой шифровальной машине enigma времен второй мировой войны. Обе программы имеют сходный формат применения и требуют ключ, который представляет собой последовательность символов, аналогичную паролю. Для указания ключа служит опция -k. Опция -e задает режим шифрования, -d - дешифрования. Так как программа crypt обеспечивает заметно меньшую защиту, чем DES, можно сначала архивировать файл, например, с помощью программы tar. На системах шифрования базируются некоторые почтовые системы, например, PGP (pretty good privacy) или PEM. Современные системы электронных подписей и конфиденциальной электронной почты основаны обычно на открытом и секретном ключах, эта технология (шифрование открытым ключом) базируется на криптографическом алгоритме Rivest-Shamir-Adelman'а (RSA). Эти ключи формируются попарно и являются математически связанными. Первый может пересылаться по обычным (открытым) каналам связи и используется для шифрования отправителем, а второй (секретный) - не пересылается и служит только для дешифрования получателем. Следует учитывать, что применение шифрования в России регулируется специальными законами.

    Желательно, чтобы любые два объекта в сети общались друг с другом с использованием индивидуального набора ключей. Если в сети имеется n объектов, то необходимое число ключей равно [(n-1)*n]/2 (для n=100 это число равно 4950). Скрытое и эффективное хранение такого числа ключей само по себе уже может представлять проблему (а если n равно 1000!).

    К сожалению, алгоритм RSA работает довольно медленно, по этой причине для шифрования больших объемов информации используются алгоритмы только с одним ключом (секретным), например, технология DES, которая способна гарантировать приемлемое быстродействие для шифрования и дешифрования в реальном масштабе времени. Секретный ключ DES пересылается с использованием техники шифрования RSA. RSA техника удобна для взаимной идентификации узлов до начала информационного обмена и для программ автоматического управления генерацией и распределением ключей дешифровки в сетях с большим числом объектов.

    Существуют и аппаратные средства шифрования и контроля доступа, как отечественные, так и зарубежные (например, RG xxx комплекты фирмы racal или оборудование компании semaphore). Использование аппаратных средств может сохранить пропускную способность сети при введении шифрования/дешифрования неизменной. Особо эффективными для блокировки нелегального доступа могут быть специальные кодовые карточки, которые можно использовать и в случае удаленного доступа через коммутируемую телефонную сеть.

    Интернет - открытая система, поэтому любые системы защиты плохо сочетаются с идеологией этой сети. Но Интернет может реально обеспечить любой уровень защиты уже сегодня. Рассмотрим одну из наиболее распространенных схем защиты (рис. 6.3).

    Рис. 6.3.

    Сначала формируется традиционный TCP-канал (для Telnet, FTP или SMTP). Этот канал используется для обмена командами. Далее управление передается блоку безопасности, который формирует отдельный канал для обмена шифрованной информацией (например, Kerberos). Перед началом обмена блок выясняет наличие аналогичного блока у партнера. Практически такая схема может быть реализована с использованием алгоритма Нидхама-Шрёдера (Needham-Schroeder). Здесь каждая ЭВМ использует общий ключ с сервером аутентификации. При необходимости установить соединение ЭВМ получает ключ от сервера и пересылает его адресату соединения (возможно в зашифрованном виде). Схема может работать с секретными и общедоступными ключами. Атака здесь затруднена не только из-за применения шифрования но и благодаря наличию дополнительного агента, участвующего в процессе соединения (сервера аутентификации). Функции такого сервера может взять на себя DNS. Конечно, не следует исключать возможности атаки на сервер аутентификации (например, с помощью подбора ISN).

    Многие процедуры в Интернет не требуют для своего выполнения пароля, именно это обстоятельство создает еще одно окно уязвимости для сетей. Но и в случаях аутентификации с использованием пароля проблемы остаются. Если пароль передается в незашифрованном виде, он может быть легко перехвачен. Определенный интерес здесь может представлять и применение системы одноразовых паролей (например, skey). Суть этой технологии заключается в том, что после конфигурирования системы для очередной процедуры идентификации клиентом и сервером генерируется новый пароль. Перехват самого пароля в этом случае теряет смысл, так как воспользоваться им уже не возможно, а восстановить алгоритм формирования паролей даже по результатам достаточно большого числа перехватов практически не реально. Некоторые сетевые запросы (например, в HTTP) могут нести в себе пароли. Помимо перехвата таких сообщений имеется возможность использования их для подбора пароля, так как здесь часто нет ограничений на число попыток. Распознавание "свой-чужой" можно организовать непосредственно на пакетном уровне. Такая возможность предусмотрена в протоколе SNMP (поле community). Но возможно создание специального программного обеспечения, где все без исключения пакеты будут идентифицироваться. Для этого предусмотрены специальные коды для поля тип протокола (сети Ethernet). Например, для передачи шифрованных пакетов: UDP IP - 11; TCP/IP - 06; DEC LAT - 6004 и XNS - 0600. В последнее время широкое распространение получают индивидуальные сертификаты пользователя (см., например, www.verisign.com). Такие сертификаты эквивалентны высоконадежной электронной подписи идентифицирующей отправителя сообщения.

    Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах, что сделает подключение к ним более затруднительным, или, там где это целесообразно, использовать оптоволоконные кабели. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоения хакером "чужого" MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня.

    Как же можно определить, подверглась ли ваша ЭВМ атаке или нет? (Последующие рекомендации относятся к ОС UNIX).

    Начинать надо с просмотра log-файла (см. ниже описание утилиты last). Но следует иметь в виду, что отсутствие подозрительных записей в этом файле не является гарантией безопасности. Хакер может без труда отредактировать этот файл.

    Следующим шагом должен стать поиск любых спрятанных файлов. При этом нужно позаботиться о наличии копии всех рабочих системных и пользовательских файлов. Хакер может оставить каталоги с необычными именами типа ".", ".   " (три точки + три пробела), ".xxx", ".mail", которые неопытный пользователь может принять за системные. Целесообразно контролировать неизменность базовых системных файлов, таких как logon, telnet и др., так как хакер, видоизменив их, может предоставить себе свободный доступ в систему. Полезно контролировать дату действующей версии таких программ. Далее следует просмотреть файл /etc/inetd.conf на предмет внесения в него каких-либо модификаций. Не рекомендуется разрешать в этом файле услуги типа: systat - порт 11; tftp - порт 69 и link - порт 87. Прежде всего следует искать строки, которые могут исполнять программы ядра (например, /bin/sh или bin/csh). Нужно проверить также все программы, на которые имеются ссылки в файле /etc/inetd.conf, так как хакер может заменить их и встроить в них программы типа троянского коня. Надо внимательно изучить содержимое файла /etc/hosts.equiv, /etc/hosts.lpd (эти файлы не должны допускать запись кому угодно) на наличие в них нелокальных имен ЭВМ, а также все файлы ~/.rhost в особенности ~root, ~uucp, ~ftp и другие программы, допускающие запись извне.

    В случае обнаружения несанкционированного вторжения следует исследовать и другие ЭВМ, подключенные к сети. Нужно просмотреть файл /etc/passwd и выявить изменения, внесенные в него за последнее время. Особое внимание должно быть уделено авторизации новых пользователей.

    Если ваша машина использует услуги UUCP, проверьте файл L.cmds. Он должен содержать только те команды, которые вам действительно нужны. Этот файл должен принадлежать root (а не uucp). Не следует оставлять без внимание содержимое файлов /etc/ttytab, /etc/ttys, а также /users/lib/aliases и любые другие файлы, определяющие конфигурацию системы. Везде, где возможно, нужно установить соответствующий уровень доступа к каталогам.

    Определенного успеха в деле повышения защиты сети можно добиться, используя ограничения допуска. Маршрутизаторы и ЭВМ, имеющие контроль доступа, сверяют адрес отправителя запроса со списком доступа. Если адрес содержится в разрешительном списке, доступ реализуется, в противном случае запрос отвергается. Такие возможности предусмотрены в маршрутизаторах фирмы CISCO, имеются они и в некоторых сетевых пакетах UNIX (например, пакет wrapper). Этот пакет осуществляет мониторинг всех интернетовских и обычных сетевых запросов. Программа wrapper доступна по адресу: FTP:cert.sei.cmu.edu/pub/network_tools/tcp_wrapper.shar. Файл содержит исходный текст на языке Си и Makefile для генерации демона wrapper, который имеет имя tcpd.

    В указанном выше депозитарии в каталоге info можно найти документ DOD 5200.28-std "Trusted Computer System Evaluation Criteria", представляющий собой стандарт, который регламентирует общие принципы сетевой безопасности.

    Целесообразно мониторировать доступ к fingerd, ftpd, tftpd, rshd, rlogind, rexecd и telnetd. Если вы строите защищенную систему, следует использовать статические таблицы маршрутизации. Должна быть заблокирована возможность добавления маршрутов по умолчанию в процессе загрузки системы. Регулярно просматривайте маршрутные таблицы с помощью команды netstat -nr.

    При выборе программного обеспечения для защищаемой сети следует тщательно изучить его особенности, ведь авторы программ могут оставить "люки" (недокументированные обходы системы защиты) или предусмотреть универсальный ключ дешифровки сообщений. Абсолютных систем защиты не существует и вряд ли такие системы появятся в будущем. Но можно создать защиту, стоимость взлома которой не окупится. Именно к этому и следует стремиться (люди любопытны, но достаточно ленивы).

    Помимо Finger, хорошую службу хакеру может сослужить программа TFTP (ведь она не требует пароля), если с помощью ее доступен файл /etc/passwd, где в закодированном виде хранятся все пароли. Заполучив этот файл, хакер сможет заняться подбором паролей на своей ЭВМ, благо для этой цели имеется немало программ. Желательно вообще закрыть доступ пользователей к TFTP, закомментировав, например, соответствующую запись в файле inetd.conf. Полезно также удалить systat и link. В новейших версиях ОС пароли хранятся в "теневых" файлах, недоступных для обычных пользователей.

    Для проверки добротности паролей администратор сети может воспользоваться программами npasswd, passwd+ или SATAN. Программа npasswd проверяет соответствие паролей определенным требованиям перед их запоминанием в соответствующем файле. Среди параметров, контролируемых npasswd, содержится минимальное число символов в пароле, список нелегальных кодов (например, последовательности повторяющихся символов типа "wwww"). Программа контролирует отсутствие в пароле персональной информации, доступной с помощью Finger, проверяет наличие в пароле цифр и букв верхнего и нижнего регистров, а также общеупотребительных слов из словаря. Программа доступна по адресу: FTP://ftp.cc.utexas.edu/pub/npasswd.tar.Z. (см. также [14-16] в конце этой главы).

    Программа passwd+ выполняет аналогичные функции, но предоставляет более гибкий набор средств тестирования паролей. passwd+ имеет специальный язык, позволяющий реконфигурировать систему контроля паролей. Конфигурация записывается в файл /etc/password.test (UNIX).

    Программа SATAN (работает с ОС UNIX, в настоящее время доступна версия 1.1.1) была создана для подбора ("вскрытия") паролей, но в умелых руках она может стать эффективным средством выбора надежных паролей и выявления непригодных. При использовании системы SATAN или других аналогичных программных продуктов нужно проявлять особую осторожность. Такие системы имеют встроенную систему защиты, но перехват, например, ключа сессии, может открыть доступ хакеру ко многим паролям пользователей. Эти программы для запуска требуют, как правило, системных привилегий.

    Защищенность сети зависит от конфигурации программного обеспечения. Для ОС UNIX определенную угрозу предоставляют так называемые r-команды. Эти команды используют файлы /etc/hosts.equiv и .hosts. Следует проверить эти файлы и /etc/hosts.ltd на наличие символа (+). Нужно помнить, что файл .hosts имеется в каталоге каждого пользователя. Если в вашей сети используется UUCP, удалите все неиспользуемые команды из файла L.cmds, выполните команды chown root L.cmds, chown uucp L.sys и chmod 600 L.sys. Эти меры сделают вашу систему более устойчивой против нежелательных вторжений. Корректная конфигурация NFS и sendmail сделает систему еще безопаснее. Дальнейшей безопасности будет способствовать сокращение списка системных (secure) терминалов (файлы /etc/ttys и /etc/ttytab).

    Но само по себе этого недостаточно - администраторы должны постоянно контролировать ситуацию. Для этого рекомендуется регулярно выполнять команды who и ps, которые сообщают список активных пользователей и процессов. Команды ps -aux для BSD и ps -ef для System 5 выведут на экран список пользователей, которые инициировали активные процессы. Вы можете также воспользоваться командой ls -lR, чтобы просмотреть принадлежность и уровни доступности файлов в каталоге. Хакеры часто оставляют на диске файлы, чтобы облегчить себе в будущем доступ или обеспечить системные привилегии. Для контроля ситуации следует время от времени выполнять команду ls -a | grep '^\.', которая ищет файлы, начинающиеся с символа точка. Хакеры часто полагают, что пользователь воспримет файлы типа .mail или .xxxx как системные, и не будет беспокоиться. Если вами найдены файлы, вызывающие подозрения, следует немедленно проконсультироваться с администратором сети.

    Объектом самого пристального внимания должны быть файлы /etc/inetd.conf, /etc/hosts.equiv, /etc/hosts.ltd, /etc/passwd и .rhosts. Доступ к ним должен быть ограничен, их копии полезно хранить в недоступном месте. Полезно также записать в отдельный файл основные параметры ваших рабочих файлов, это позволит вам заметить факт их модификации. Чтобы обнаружить "сюрпризы", оставленные непрошеными визитерами, можно воспользоваться командой find / -user root -perm -4000 -print, которая ищет файлы, принадлежащие root и устанавливающие уровень привилегий -4000. Команда Find может использоваться для проверки уровня доступа к жизненно важным файлам (-perm -2 или -perm -2000), a также файлов без определенного хозяина (-nouser -o -nogroup). Последние файлы должны быть удалены.

    Странная активность в системе в необычное время суток, в необычные дни или с неизвестного удаленного терминала должна вызывать пристальное внимание. Для контроля активности в ЭВМ (UNIX) служит команда last. Эта команда отображает содержимое файла /usr/adm/wtmp, где содержится информация о том кто, когда и откуда заходил в систему. Ниже приведен небольшой фрагмент результата работы команды last.

    Имя пользователя

    Терминал

    Имя домена

    Дата входа

    Время входа

    ftp

    ftp

    svalla.smart.net

    Sat Mar 30

    02:57

    semenov

    ttyp3

    flta.Helsinki.FI

    Fri Mar 29

    11:51

    ftp

    ftp

    osilab.nstu.nsk.

    Fri Mar 29

    08:21

    ftp

    ftp

    fsite.dialup.ru

    Thu Mar 28

    16:11

    ftp

    ftp

    ix-cha-nc9-55.ix

    Thu Mar 28

    04:59

    ftp

    ftp

    pmax.dymaxion.ns

    Thu Mar 28

    03:24

    ftp

    ftp

    slip-tsr.srcc.ms

    Tue Mar 26

    6:11

    FTP

    FTP

    pmax.dymaxion.ns

    Sun Mar 24

    05:34

    bobyshev

    ttyp2

    131.169.1.233

    Mon Nov 27

    09: 57

    FTP

    FTP

    ftp01.blue.aol.c

    Mon Nov 27

    03:20

    FTP

    FTP

    foley.ripco.com

    Mon Nov 27

    01:03

    Записи располагаются от настоящего к прошлому, что видно из предлагаемого отрывка. В колонке <Имя пользователя> и <терминал> в случае "анонимного FTP" помещается метка FTP. Так как обычно результат работы команды last занимает десятки страниц, бывает полезно воспользоваться командой grep, чтобы просмотреть отдельные фрагменты файла /usr/adm/wtmp, отвечающие определенным критериям. Например:

    last | grep '03:'(поиск входов в систему межу 3 и 4 часами утра)

    FTP

    FTP

    pmax.dymaxion.ns

    Thu Mar 28

    03:24

    FTP

    FTP

    jwilson.ott.hook

    Thu Mar 14

    03:31

    FTP

    FTP

    assign29.utw.com

    Sun Feb 25

    03:40

    FTP

    FTP

    fh_ppp32.monmout

    Thu Jan 25

    03:07

    FTP

    FTP

    tpafl3-6.gate.ne

    Wed Jan 24

    03:52

    FTP

    FTP

    ttyC1.pandemoniu

    Sat Dec 30

    03:07

    FTP

    FTP

    student.uq.edu.a

    Sat Dec 9

    03:17

    FTP

    FTP

    s189_81.resnet.u

    Wed Dec 6

    03:37

    FTP

    FTP

    golden.ripco.com

    Wed Nov 29

    03:25

    FTP

    FTP

    hobbes.jct.ac.il

    Wed Nov 1

    03:43

    ........................................

    Пользователю не важно, по какой причине он не получил своевременно важное сообщение, или почему реакция сети вдруг стала равной нескольким секундам. А такие вещи могут происходить из-за установки неоптимальных параметров сети (TTL, MTU, window и т.д.), в результате перегрузки сетевого сегмента (что может произойти, если один из пользователей разорвет кабельный сегмент) или из-за потока широковещательных запросов. Дестабилизация сети может происходить по причине зацикливания пакетов или осцилляций маршрутов. Зацикливание пакета возможно при установке маршрутов по умолчанию типа A -> B и B -> A, когда в системе появляется пакет с ошибочным адресом. Возможно это и при установке параметра вариация > 1 во внутреннем протоколе маршрутизации IGRP. Осцилляции маршрутов свойственны системам с динамическими протоколами маршрутизации при неверной установке таймеров. Источником потока широковещательных запросов может стать IP-мост, по обе стороны которого появились идентичные IP-адреса, или неисправное оборудование (например, сетевой принтер). Администратор должен отслеживать ситуацию и при возникновении нештатного ее состояния, с помощью диагностической программы выявить и устранить причину.

    Вы можете быть защищены системой Firewall, использовать шифрование при обменах и т.д., но, если ваш персональный компьютер время от времени доступен для посторонних - он совершенно не защищен. Злоумышленник, вооруженный бутабильной дискетой, может стартовать ЭВМ и, обойдя, таким образом, необходимость ввести пароль, скопирует или сотрет нужные ему файлы. Несколько улучшит ситуацию конфигурация, которая требует ввода пароля на фазе загрузки системы (SYSKEY; Microsoft), а также запирание корпуса ЭВМ и порта флоппи-диска (если это предусмотрено). Если у злоумышленника достаточно времени, он может просто снять с вашей машины жесткий диск, поставить его на свою машину, и сделать все, что ему нужно. Так что какой-то гарантией безопасности может служить лишь надежный запор на помещении, где находится ваша ЭВМ.

    Для мониторирования безопасности ЭВМ создан специальный набор программ COPS (Computer Oracle Password and Security). COPS контролирует доступ к файлам, каталогам и оборудованию, содержимое файлов /etc/passwd, /etc/group, /etc/hosts.equiv и .hosts, а также регистрирует изменения состояния SUID. После завершения всех проверок результат посылается в виде почтового сообщения системному администратору. Программы COPS доступны по адресу:

    cert.sei.cmu.edu/pub/cops.tar.Z

    Существует несколько подписных листов и депозитариев, аккумулирующих и распространяющих информацию по сетевой безопасности:

    1. CERT (Computer Emergency Response Team) cert@cert.sei.cmu.edu. Депозитарий статей по данной тематике расположен по адресу: FTP://cert.cei.cms.edu /pub/cert_advisories .
    2. cert-advisory-request@cert.org
    3. DDN Security Bulletins nic@nic.ddn.mil. Адрес FTP-сервера: nic.ddn.mil /scc/.
    4. Risks Forum risks-request@csl.src.com.
    5. Безопасность в UNIX. bugtraq-request@fc.net (сообщение в теле e-mail: subscribe bugtraq). Там же имеется архив: http://www.geek-girl.com/bugtraq/archieves.html.
    6. То же для LINUX: linux-alert-request@RedHat.com (в поле subject: subscribe). Там же есть архив: http://www.redhat.com/linux-info/security/linux-alert/
    7. Безопасность Windows NT listserv@rc.on.ca (для подписка следует послать сообщение "SUB NTBUGTRAQ ваше имя" (имя, а не ваш почтовый адрес!). Там же имеется депозитарий http://ntbugtraq.rc.on.ca/archieves/ntbugtraq.html
    8. VIRUS-L (информация о компьютерных вирусах на PC) listserv%lehiibm1.bitnet @mitvma.mit.edu. В теле сообщения следует поместить:

    SUB VIRUS-L <ваше полное имя>.

    Немало полезной информации по проблематике сетевой безопасности можно найти в группе новостей comp.security.announce и в анонимных депозитариях:

    nic.merit.edu, pyrite.rutgers.edu, sparkyfs.erg.sri.com, ftp.win.tue.nl, info.cert.org, ftp.ucar.edu, ftp.ee.lbl.gov и т.д. (последние два адреса относятся к диагностическим сетевым программам).

    Антивирусные программы можно найти во многих анонимных депозитариях, там же обычно есть разделы и по сетевой безопасности, например, www.ynet.com, http://www.esat.kuleuven.ac.be (система SESAME) или ftp://ftp.compapp.dcu.ie/pub/sesame и т.д. В таблице 6.2 приведены ссылки на серверы, посвященные проблематике безопасности и смежным областям.

    Таблица 6.2. URL серверов по проблематике безопасности

    Адрес

    Тематика

    http://cgi.netscape.com/newsref/std/cookie_spec.html

    Спецификация Netscape Cookie

    http://www.eff.org

    Electronic Frontier Foundation

    http://www.epic.org

    Electronic Privacy Information Center

    http://www.cdt.org

    Center for Democracy and Technology

    http://www.w3.org/pub/WWW/Security/Dsig/Overview.html

    Обзор по электронным подписям

    http://www.iitf.nist.gov/ipc/ipc-pub.html

    Доклад IETF по проблемам конфиденциальности

    http://www.w3.org/Privacy/

    Информация по проекту Р3 (конфиденциальность)

    http://www.w3.org/Submission/1997/6/Overview.html

    Предложение по открытому стандарту по профайлам

    http://www.truste.org/

    Проект TRUSTe

    http://www.w3.org/pub/WWW/PICS/

    Базовая страница PICS

    http://www.rsac.org/

    Страница RSAC

    http://www.safesurf.com

    SafeSurf

    http://www.c2.net
    http://www.stronghold.ukweb.com/

    SSL

    http://www.microsoft.com/security/guidesent.htm
    http://www.microsoft.com/ntserversupport/
    ftp://ftp.microsoft.com/bussys/winnt-public/fixes/usa/nt4/

    Рекомендации по безопасной установке и конфигурированию Windows NT

    ftp://ftp.microsoft.com/bussys/winnt-public/fixes/usa/nt4/

    Служба быстрого реагирования для системы Windows NT

    http://www.mcafee.com/

    Антивирусная программа McAfee

    http://www.symantec.com/

    -"- Symantec

    http://www.datawatch.com/virex.shtml/

    -"- Virex

    http://www.av.ibm.com/

    IBM AntiVirus

    http://www.drsolomon.com/

    Dr. Solomon's Anti-Virus

    http://www.vtw.org/

    Наблюдательный совет по телекоммуникациям

    http://www.microsys.com/pics/software.htm
    http://www.n2h2.com/pics/proxy_servers.html

    Тексты фильтрующих программ PICS

    http://www.rsa.com/rsa/S-MIME/

    Программное обеспечение безопасной почты S-MIME

    http://www.verisign.com/

    Страница VeriSign. Индивидуальные сертификаты.

    http://www.perl.com/CPAN/modules/by-module/

    Модуль MD5 на языке PERL

    http://www.ee.washington.edu/computing/iebug/

    Описание того, как пароли могут быть перехвачены в NT

    http://www.security.org.il/msnetbreak/

    То же для Windows-95

    http://www.efsl.com/security/ntie/

    "Дыры" в Firewall

    http://www.nwnetworks.com/ietf.html/

    Неофициальный сервер по безопасности MS Internet Explorer

    http://www.microsoft.com/security/

    Советы по безопасности компании Microsoft

    http://home.netscape.com/info/security-doc.html/

    Безопасность Netscape

    http://www.entrust.com/
    http://www.cybertrust.gte.com/
    http://www.xcert.com/
    http://www.thawte.com/
    http://eurosign.com/
    http://www.cost.se/
    http://www.surgeons.co.za/certificate.html/
    http://www.compusource.co.za/
    http://www.keywitness.ca/

    Сертификация

    http://internet.junkbuster.com/
    http://www.intermute.com/
    http://www.anonymizer.com/

    Анонимные прокси-серверы

    http://www.w3.org/pub/WWW/PICS/
    http://www.microsys.com/pics/software.htm/
    http://www.n2h2.com/pics/proxy_servers.html/
    http://www.rsac.org/

    Фильтрующие программы PICS

    http://hpcc995.external.hp.com/gsy/security/virvault/

    HP WEB-сервер по вопросам безопасности

    ftp://crvax.sri.com/risks/

    Форум, где обсуждаются риски для вычислительных и сетевых систем

    http://sweetbay.will.uiuc.edu/cgi%2B%2B/

    Библиотека C++ CGI

    http://www.boutell.com/cgic/

    CGI библиотека для C

    http://www.genome.wi.mit.edu/ftp/pub/software/WWW/

    Perl-модули CGI

    http://www.webcompare.com/

    Сравнение различных WEB-серверов

    http://hopf.math.nwu.edu/docs/security.html/

    Безопасность WEB

    http://www.iss.net/ www.ntsecurity.com/
    http://www.lanwan.fi/turva/nt/ntscan.html/
    ftp://coast.cs.purdue.edu/pub/tools/unix/iss/

    Программа сканирования безопасности (коммерческая)
    Тоже, но общедоступная

    ftp://ftp.win.tue.nl/pub/security/satan.tar.Z/
    http://www.cs.purdue.edu/coast/satan.html/

    Программа проверки безопасности SATAN

    ftp://net.tamu.edu/pub/security/TAMU/
    ftp://ftp.cert.org/pub/tools/cops/

    Проверка конфигурации системы

    ftp://prep.ai.mit.edu/pub/gnu/

    Проверка не поврежденности сообщений (MD5)

    ftp://ftp.sunsite.unc.edu/pub/Linux/system/Admin/shadow-960129.tar.gz/

    Увод файла паролей в "тень"

    http://www.uu.se/Software/Analysers/
    http://www.tuckinfo.com/
    http://www.netgen.com/
    http://www.ics.icu.edu/pub/websoft/wwwstat/
    http://www.statlab.cam.ac.uk/~sret1/analog/
    http://ntsoftdist.com/sentry.htm/
    http://www.serverware.com/
    http://www.marketwave.com/
    http://www.webtrends.com/
    http://www.boutell.com/wusage/
    http://www.go-iis.com/
    ftp://sierra.stanford.edu/pub/sources/swatch-2.1tar.gz/

    Анализаторы Log-файлов
     
     
     
     
    NT

    http://info.webcrawler.com/mak/projects/robots.html/

    Страница роботов

    http://www.osf.org/tech/dce/
    http://octavia.anu.edu.au/~marcus/DCE-WEB/papers/Conf_94.html/

    DCE и WEB

    ftp://thumper.bellcore.com.pub/nmh/skey/

    Одноразовые ключи

    ftp://ftp.win.tue.nl/pub/security/

    Сетевой доступ в UNIX (wrapper)

    ftp://ftp.psy.uq.oz.au/pub/Crypto/

    Telnet, базирующийся на протоколе SSL

    http://www.cs.hut.fi/ssh/
    http://www.datafellows.com/f-secure/

    Безопасное ядро UNIX (SSH)
    то же для Windows и Macintosh

    ftp://ftp.ee.cornell.edu/pub/file/

    Программа для определения содержимого файла

    Библиография по проблематике сетевой безопасности

    1

    RFC-1108

    U.S. Department of Defense Security Options for the Internet Protocol, S. Kent, 1991

    2

    RFC-1244

    Site Security Handbook, P.Holbrook, J.Reynolds, 1991.

    3

    RFC-1281

    Guidelines for the Secure Operations of the Internet, R.Pethia, S.Crocket and B.Frazer, 1991.

    4

    RFC-1507

    DASS - Distributed Authentication Security Service, C. Kaufman, 1993

    5

    RFC-1508

    Generic Security Service Application Program Interface, J. Linn, 1993

    6

    RFC-1510

    The Kerberos Network Authentication Service (V5), J. Kohl, B. Numan, 1993

    7

    RFC-1535

    A Security Problem and Proposed Correction With Widely Deployed DNS Software, E. Gavron, 1993

    8

    RFC-1675

    Security Concerns for IPng, S. Bellovin, 1994

    9

    RFC-1750

    Randomness Recommendations for Security, D. Eastlake, S. Crocker, J. Schiller, 1994

    10

    RFC-1824

    The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange, (E.I.S.S.-Report 1995/4), H. Danisch, 1995

    11

    RFC-1825

    Security Architecture for the Internet Protocol, R. Atkinson, 1995

    12

    RFC-1827

    IP Encapsulating Security Payload (ESP), R. Atkinson, 1995

    13

    RFC-1847

    Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, J. Galvin, S. Crocker, N. Freed, 199

    14

    RFC-1858

    Security Considerations for IP Fragment Filtering, G. Ziemba, D. Reed, P. Traina, 1995

    15

     

    TCP/IP Network Administration, Craig Hunt, O'Reilly & Associates, Inc., 1993

    16

     

    Practical UNIX Security, Simpson Garfinkel and Gene Spafford, O'Reilly & Associates, 1991

    17

    Computer Security Basics, Deborah Russell and G.T.Gangemi, O'Reilly & Assocates, 1991

    18

    RFC-1579

    Firewall-Friendly FTP, S. Bellovin, AT&T Bell Laboratories, February 1994

    Безопасность вещь относительная. Для того чтобы конкретизировать обсуждаемый предмет, введены четыре уровня безопасности, обозначенные латинскими буквами A-D. Каждый из уровней поделен на субуровни, обозначаемые соотвествующей буквой и цифрой (например, А1, А2, А3 или D1, D2 и т.д.). Уровню D1 соответствует DOS, где пользователь имеет доступ ко всем системным ресурсам и программам. Владельцем файлов является текущий пользователь. С-уровень предлагает большую безопасность, чем D-уровень. На С-уровне пользователь должен быть идентифицирован, прежде чем он получит доступ к своим файлам. Стандартная система UNIX с канонической схемой доступа (login/password) относится к уровню безопасности С1. Уровень С2 включает возможность блокировать для пользователя исполнение некоторых команд, если не выполняются определенные условия. При этом пользователь не может также контролировать определенные операции, которые имеют место. Многие современные UNIX-системы, в частности SCO-UNIX, могут обеспечивать безопасность на уровне С2. В-уровень дает еще большие гарантии безопасности, запрещая пользователю изменять условия доступа для файлов. Очень не многие операционные системы и практически ни одна коммерчески доступная система не обеспечивают такого уровня безопасности. Но при выборе уровня безопасности следует учитывать, что повышение надежности неизбежно уменьшает удобство пользования системой, так что обычно приходится идти на определенный компромисс.

    Previous: 5.5 Конфигурирование сетевых систем    UP: 5 Диагностика локальных сетей и Интернет
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.1 Технические средства сетевой безопасности


    previous up down next index index
    Previous: 6 Сетевая безопасность    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.2 Виртуальные локальные сети VLAN, Интранет

    6.1 Технические средства сетевой безопасности
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли и спросить не с кого. Начинать надо с того, что в вашей власти, а это прежде всего правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (Uninterruptable Power Supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При снижении напряжения сети переменного тока ниже определенного уровня UPS (около 208v) отключает потребителя от сети и осуществляет питание ЭВМ от ~220v, получаемого от аккумулятора самого UPS. Учитывая нестабильность напряжения сети в России, можно считать полезным применение активных стабилизаторов на входе UPS.

    При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использование специального интерфейса и соответствующего программного обеспечения, работающего согласно протокола SNMP(см. рис. 6.1.1).

    Рис. 6.1.1. Схема подключения UPS.

    При исчезновении первичного напряжения ~220V спустя некоторое время UPS выдает сигнал shutdown вычислительной машине. Современный UPS может мониторировать не только напряжение питание, но температуру окружающей среды, своевременно осуществляя спасение жизненно важных файлов до наступления чрезмерного перегрева системы. При этом значение напряжения питания и температуры можно считывать с использованием протокола SNMP. Некоторые продвинутые системы автономного питания допускают подключение агентов SNMP непосредственно к локальной сети, что открывает дополнительные возможности дистанционного управления и мониторинга.

    Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

    Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах или трубах, что сделает подключение к ним более затруднительным. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоение хакером "чужого" MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня.

    Активные разработки в последнее время ведутся в области систем идентификации, базирующихся на распознавания отпечатков пальцев, ладони, подписи или голоса. Для этих целей используются новейшие достижения в области быстрых Фурье-преобразований, нейронных сетей и пр. В качестве вводных устройств используются оптические сканеры, а также резистивные экраны. Для ввода подписи служат специальные планшеты , а также изощренные методы сравнения и установления идентичности.

    Так как современные системы шифрования предполагают использование довольно трудоемких вычислений, которые заметно замедляют процесс, разрабатываются специальные микросхемы.

    Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа Exabyte емкостью 2.5-10Гбайт еще достаточно широко используются, высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи на них оставляет желать лучшего). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более .

    В последнее время широкое распространение получают панели касания, способные распознавать людей по отпечатку пальца или ладони (см. http://elce.quarta.msk.ru/UCC/t_scrb_e.htm). Сходные устройства используются для непосредственного ввода подписи клиента (устройство типа планшет, иногда совмещаемое с дисплеем) и сверки ее с имеющимся образцом.

    Previous: 6 Сетевая безопасность    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.2 Виртуальные локальные сети VLAN, Интранет


    previous up down next index index
    Previous: 6.4.4 Безопасная почта PGP    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
        Next: 6.4.6 Алгоритм Диффи-Хелмана

    6.4.5 Алгоритм Эль Гамаля
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Алгоритм Эль-Гамаля может использоваться для формирования электронной подписи или для шифрования данных. Он базируется на трудности вычисления дискретного логарифма. Для генерации пары ключей сначала берется простое число p и два случайных числа g и x, каждое из которых меньше p. Затем вычисляется:

    y = gx mod p

    Общедоступными ключами являются y, g и p, а секретным ключом является х. Для подписи сообщения M выбирается случайное число k, которое является простым по отношению к p-1. После этого вычисляется a = gk mod p. Далее из уравнения M = (xa + kb) mod (p-1) находим b. Электронной подписью для сообщения M будет служить пара a и b. Случайное число k следует хранить в секрете. Для верификации подписи необходимо проверить равенство:

    yaab mod p = gM mod p.

    Пара a и b представляют собой зашифрованный текст. Следует заметить, что зашифрованный текст имеет размер в два раза больше исходного. Для дешифрования производится вычисление:

    M = b/ax mod p

    Previous: 6.4.4 Безопасная почта PGP    UP: 6 Сетевая безопасность
    Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 6.4.6 Алгоритм Диффи-Хелмана


    previous up down next index index
    Previous: 7.1 Winsock (для UNIX, Windows-95 и -NT)    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 8 Заключение
        Next: 8 Заключение

    7.2 Сетевые драйверы
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Читатели, знакомые с телекоммуникационными протоколами, могут заинтересоваться тем, как писать прикладные программы для работы с пакетами. Прикладная программа взаимодействует с драйвером сетевого интерфейса. Ethernet-интерфейс, как и всякий другой, содержит несколько статусных управляющих регистров (CSR) и один или несколько регистров данных. Запись (чтение) в эти регистры выполняется в IBM/PC с помощью команд IN (OUT). Каждому регистру ставится в соответствие определенный номер порта. Блок номеров портов задается с помощью переключателей на интерфейсе или в процессе постановки пакетного драйвера. В последнем случае в AUTOEXEC-файле должна присутствовать строка, например (для DOS):

    NE2000 0x60 0x5 0x300, (если ваша ЭВМ снабжена интерфейсом типа NE2000).

    Здесь предполагается, что интерфейс будет использовать номер прерывания 0x60, аппаратное прерывание 0x5 и блок портов, начиная с шестнадцатеричного адреса 0x300 (io_addr). Следует иметь в виду, что разные интерфейсы могут иметь разное число CSR-регистров и отличные от приведенных ниже функции (NE2100). Интерфейс характеризуется тремя целыми числами: класс (8 бит), тип (16 бит) и номер. Класс говорит о том, для какой из сетевых сред предназначен данный прибор (PPP, DIX Ethernet, IEEE 802.3, IEEE 802.5, Pronet-10, Appletalk и т.д.). Тип описывает конкретную реализацию интерфейса (NE2000, NI5210, 3C501 и т.д.). Тип 0xffff соответствует всем интерфейсам данного класса. В случае, когда ЭВМ оснащена более чем одним интерфейсом идентичного типа, для их идентификации используется номер. На рис. 7.2.1 показана структура управляющего (CSR) регистра сетевого интерфейса. В таблице 7.2.1 приведен перечень основных классов с примерами определенных типов интерфейсов.

    Рис. 7.2.1.А Структура CSR-регистра интерфейса (CSR0)

    Init

    инициализация (initialize);

    Strt

    старт;

    Stop

    стоп;

    Tdnd

    запрос передачи (transmit demand);

    Txon

    включение передачи;

    Rxon

    включение приема;

    Inea

    разрешение прерываний (interrupt enable);

    Intr

    прерывание;

    Idon

    инициализация выполнена (стирание записью 1);

    Tint

    прерывание при передаче (стирание записью 1);

    Rint

    прерывание при чтении (стирание записью 1);

    Merr

    ошибка при тайм-ауте на шине (стирание записью 1);

    Miss

    нет буфера для приема (стирание записью 1);

    Cerr

    ошибка из-за столкновения (стирание записью 1);

    Labl

    тайм-аут при передаче (стирание записью 1);

    Err

    ошибка типа Babl, Cerr, Miss, Merr (только для чтения).

    CSR1 (доступ разрешен при CSR0[stop] = 1)

    Рис. 7.2.1.Б. CSR1

    CSR2 (доступ разрешен при CSR0[stop] = 1)

    Рис. 7.2.1В. CSR2

    Bcon

    0 = <0:7> перестановка байтов адресов

    Acon

    0 = ale, 1 = /as

    Bswp

    0 = /bm1, bm0, /hold;

    csr3 (доступ разрешен при CSR0[stop] = 1)

    Рис. 7.2.1.Г. CSR3

    Таблица 7.2.1.

    Сетевая среда

    Класс

    Фирма, интерфейс

    Тип интерфейса

    dec/intel/Xerox

    1

    3com 3C500/3C501

    1

    "Bluebook" ethernet

    3com 3C505

    2

    Interlan NI5010

    3

    Micom-Interlan NP600

    6

    Ungermann-bass PC-nic

    8

    Univation NC-516

    9

    TRW PC-2000

    10

    Interlan NI5210

    11

    3com 3C503

    12

    3com 3C523

    13

    Western digital WD8003

    14

    Spider systems S4

    15

    Torus frame level

    16

    10net communications

    17

    Gateway PC-bus

    18

    Gateway at-bus

    19

    Gateway MCA-bus

    20

    IMC PCnic

    21

    1

    IMC PCnic II

    22

    Micromatic research

    25

    Clarkson "multiplexor"

    26

    D-link 16-bit

    28

    D-link ps/2

    29

    Research machines 16

    31

    Research machines MCA

    32

    Interlan NI9210

    34

    Interlan NI6510

    35

    Novell NE2000

    36

    Allied telesis pc/xt/at

    38

    Allied telesis NEC PC-98

    39

    Ungermann-bass NIC/PS2

    41

    Tiara lancard/E AT

    42

    Tiara Lancard/E MC

    43

    Tiara Lancard/E TP

    44

    AT&T Starlan NAU

    47

    AT&T Starlan-10 NAU

    48

    AT&T Ethernet NAU

    49

    Pronet-10

    2

    Proteon P1300

    1

    Proteon P1800

    2

    IEEE 802.5/pronet-4
    IBM Token Ring интерфейс

    3

    Proteon P1340

    2

    Proteon P1344

    3

    Gateway PC-bus

    4

    Gateway AT-bus

    5

    Gateway MCA-bus

    6

    Omninet

    4

     

     

    Appletalk

    5

     

     

    Последовательный интерфейс

    6

    Clarkson 8250-slip

    1

    Clarkson "multiplexor"

    2

    Starlan

    7

     

     

    Arcnet

    8

    Datapoint RIM

    1

    AX.25

    9

     

     

    KISS

    10

     

     

    IEEE 802.3 w/802.2 HDRS

    11

     

     

    FDDI W/802.2 HDRS

    12

     

     

    Internet X.25

    13

    Western Digital

    1

    N.T. Lanstar (encap. dix)

    14

    NT Lanstar/8

    1

    NT Lanstar/mc

    2

    SLFP

    15

     

     

    Netrom

    16

     

     

    Nclass

    17

     

     

    Любой пакетный драйвер имеет блок исходных данных (MS-DOS), напр.:

    EADDR_LEN

    equ 6

     

    ; длина физического адреса

    init_block

    struc

     

     

    init_mode

    dw

    0

     

    init_addr

    db

    eaddr_len dup(?)

    ; ethernet-адрес

    init_filter

    db

    8 dup(0)

    ; Логический адресный фильтр (multicast filter).

    init_receive

    dw

    ?,?

    ; Указатель входного кольцевого буфера

    init_transmit

    dw

    ?,?

    ; Указатель выходного кольцевого буфера.

    init_block

    ends

     

     

    Структура переменных init_mode (смещение = 0) имеет вид

    Рис. 7.2.2. Структура переменных init_mode

    Drx

    запрет приема;

    Dtx

    запрет передачи;

    Loop

    цикл;

    Dtcr

    запрет передачи crc;

    Coll

    столкновение;

    Drty

    запрет повторов;

    Intl

    внутренний цикл;

    Prom

    режим приема всех пакетов (promiscuous mode).

    Кольцевой входной буфер имеет следующую структуру:

    rcv_msg_dscp

    struc

    rd_addr

    dw ?

    ; Младшая часть адреса входного буфера

    rd_stat

    dw ?

    ; Статусная часть + старшая часть адреса

    rd_bcnt

    dw ?

    ; Размер буфера в байтах

    rd_mcnt

    dw ?

    ; Длина сообщения в байтах

    rcv_msg_dscp

    ends

    Структура переменных rd_stat имеет вид

    Рис. 7.2.3. Структура переменных rd_stat

    Enp

    конец пакета;

    Stp

    начало пакета;

    Buff

    ошибка в буфере;

    CRC

    CRC-ошибка;

    Oflo

    переполнение буфера;

    Fram

    ошибка при записи в буфер;

    Err

    наличие ошибки;

    Own

    0 = полное заполнение.

    Выходной буфер имеет сходную структуру.

    Я не буду описывать здесь то, как следует писать системные драйверы (Исчерпывающую информацию по написанию таких драйверов читатель может найти в книге "Написание драйверов для MS-DOS" Р.Лея и "Уэйт Груп", Москва "Мир", 1995), тем более что существует достаточное их количество в депозитариях общего доступа (Например, анонимное FTP по адресам ftp.funet.fi, ftp.switch.ch или oak.oakland.edu, депозитарий SimTel ). Приведенное выше описание регистров интерфейса не является единственно возможным (см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi. Структура драйверов варьируется для разных операционных систем. Для системных программистов полезно иметь возможность настраивать драйвер или непосредственно интерфейс на определенный режим, например, на прием всех пакетов, проходящих по кабельному сегменту. Последнее может представлять интерес в диагностических целях, так как вслед за пакетным драйвером загружается Etherdrv, Winsock или winpkt и т.д., блокирующие режим приема всех пакетов (mode=6). Ниже приведен пример описания основных параметров драйвера:

    BLUEBOOK

    equ

    1

     

    IEEE8023

    equ

    11

     

    ADDR_LEN

    equ

    6

    ; размер Ethernet-адреса

    MAX_M_CAST

    equ

    8

    ; максимальное число мультикаст-адресов.


    Public

    int_no,

    io_addr

     

    int_no

    db

    2,0,0,0

    ; должно иметь 4 байта для get_number.

    io_addr

    dw

    0300h,0

    ; I/O адрес карты (переключатели)


    public

    driver_class

    driver_type,

    driver_name,

    driver_function,

    parameter_list

    driver_class

    db

    BLUEBOOK, IEEE8023, 0

    ; из спецификации интерфейса

    driver_type

    dw

    54

    ; из спецификации интерфейса

    driver_name

    db

    'NE2000',0

    ; имя драйвера.

    driver_function

    db

    2

     

    parameter_list

    label

    byte

     

     

    db

    1

    ;

     

    db

    9

    ;

     

    db

    14

    ; длина списка параметров в байтах

     

    db

    ADDR_LEN

    ; длина адреса MAC-уровня в байтах

     

    dw

    GIANT

    ; MTU, включая MAC-заголовок

     

    dw

    MAX_M_CAST * ADDR_LEN

     

    ; размер буфера для мультикаст-адресов

     

    dw

    0

    ;(# принимаемых подряд пакетов с; размером MTU) - 1

     

    dw

    0

    ; (# посылаемых подряд пакетов) - 1

    int_num

    dw

    0

    ; Номер прерывания

    Работа с пакетным драйвером в MS-DOS

    Существует множество пакетных драйверов. Можно обнаружить несколько модификаций для одного и того же типа интерфейса. Эти драйверы могут быть ориентированы на работу в разных программных средах (Novell, UNIX, MS-DOS и т.д.) и иметь разные возможности. Для MS-DOS сложился неофициальный стандарт, который позволяет использовать драйвер для самых разных приложений. Драйвер может использовать минимум возможностей интерфейса (базовый уровень), реализовать более широкий набор функций (мультикастинг, сбор статистики и т.д.) или поддерживать практически все, на что способен данный прибор. В последнем случае он занимает больше места в памяти. Описания операций с пакетными драйверами, приведенные ниже, выполнены в нотации ассемблера IBM/PC. При написании программы следует помнить, что порядок байтов в Ethernet противоположен тому, который используется в вашей IBM/PC.

    Пакетные драйверы используют программные прерывания в интервале 0x60 - 0x80. Следует сразу заметить, что не все прерывания из этого списка свободны и при конфигурировании системы следует проявлять осмотрительность. Для того чтобы избежать конфликтов с другими внешними устройствами, предусматривается возможность реконфигурации прерываний. Предполагается, что программа обработки прерываний начинается с команды безусловной передачи управления (JMP), за которой следует текстовая строка "PKT DRVR". Именно эта строка служит указателем при поиске адреса пакетного прерывания. Практически все драйверы могут работать с различными протоколами (TCP/IP, OSI и др.). Решить задачу мультиплексирования на связном уровне помогает процедура access_type, которая обеспечивает доступ для пакетов определенного типа.

    Все функции реализуются с помощью обращения к драйверу с набором определенных параметров. При этом значение регистра AH определяет тип запроса. Каждому типу используемого сетевого протокола, с которым работает интерфейс, ставится в соответствие целочисленный указатель (handle), получаемый с помощью процедуры access_type. Выполнимость драйвером тех или иных операций может быть выяснена с помощью запроса driver_info.

    При работе с драйвером следует проявлять осторожность и спасать нужные вам регистры. Следует также помнить, что порядок байтов в PC и в некоторых сетях, включая Ethernet, не совпадает. Описание основных запросов, посылаемых пакетному драйверу:

    1. Получение информации о типе и функциональных возможностях драйвера

    driver_info AH == 1,
    AL == 255 (код запроса)

    public

    _driver_info

    _driver_info

    proc near

     

     

    mov AX, 1FFH

    ; ah=1, al=255

     

    call int_pkt

    ; обращение к драйверу

     

    jnc lv

     

     

    mov AX, seg _PARAM.ER_CODE

     

     

    mov DS, AX

     

     

    mov _PARAM.ER_CODE, 272

    ; Устанавливаем код "Нет инф. о драйвере"

    lv:

    ret

    _driver_info

    endp


    int_pkt:

     

    ; Подпрограмма обращения к драйверу

     

    push ds

     

     

    push es

     

     

    pushf

     

     

    cli

     

     

    call _param.Handler

    ; адрес _param.Handler должен быть определен раньше

     

    pop es

     

     

    pop ds

     

     

    ret

     

    Целочисленный указатель (handle) должен быть занесен в регистр BX (для старых драйверов). В случае ошибки устанавливается флаг carry, а код ошибки заносится в регистр DH. Сообщение BAD_HANDLE (неверный указатель) возможно только для старых драйверов. При благополучном исполнении флаг carry равен нулю, а в регистры будет занесены следующие параметры:

    BX

    версия;

    CH

    класс;

    CL

    номер;

    DX

    тип;

    DS:SI

    указывают на строку имени драйвера;

    AL

    функциональные возможности.

    AL = 1

    гарантируется выполнение базовых функций;

    = 2

    обеспечено выполнение базового и расширенного набора функций;

    = 5

    выполняется базовый и экстра-набор функций;

    = 6

    выполним полный набор функций;

    = 255

    драйвер не установлен.

    Ниже приведен пример программы, реализующей некоторые из описанных запросов.

    .MODEL

    small

     

    PUBLIC

    _INFACE

     

    VERSION

    EQU

    1

    EXTRN

    _PARAM:BYTE

     

    EXTRN

    _Q:BYTE

     

    .DATA

    INCLUDE

    DEF.ASM

    ; Определения некоторых констант

    P_LIST

    STRUC

     

    LINTN

    DB

    32 dup(0)

    ; Список активных номеров прерываний

    HANDLES

    DW

    ?

     

    HANDLEP

    DW

    ?

     

    ER_CODE

    DW

    ?

     

    ERNUM

    DW

    ?

    ; Код ошибки

    HANDLER

    DD

    ?

     

    MODE

    DW

    ?

    ; Текущий режим приема пакетов

    MLIST

    DB

    0,0,0,0,0,0

    ; Список допустимых режимов; 1 => имеется

    PKT_IN

    DW

    ?,?

    ; Диагностический массив

    pkt_out

    DW

    ?,?

     

    byte_in

    DW

    ?,?

     

    byt_out

    DW

    ?,?

     

    err_in

    DW

    ?,?

     

    err_out

    DW

    ?,?

     

    pk_drop

    DW

    ?,?

     

    L1

    DW

    0

    ; Версия драйвера

    L2

    DW

    0

    ; класс/номер

    L3

    DW

    0

    ; Тип

    L4

    DW

    0

    ; Функция

    _NAME

    DB

    0,0,0,0,0,0,0,0,0,0

    ; Имя интерфейса

    ETHER_ADR

    DB

    ADDR_LEN dup(-1)

    ; Ethernet-адрес

    S_ADR

    DB

    EADDR_LEN+5 dup(-1)

    ; Ethernet-адрес получателя

    D_ADR

    DB

    EADDR_LEN+5 dup(-1)

    ; Ethernet-адрес отправителя

    P_LIST

    ENDS

    QUEUE

    STRUC

    Leng

    DW

    15000,?

    ; Длина очереди

    Tail

    DW

    ?

    ; Смещение последнего элемента очереди

    Head

    DW

    ?

    ; Смещение первого элемента очереди

    _end

    DW

    ?

    ; Указатель на конец очереди

    p_len

    DW

    ?

    ; Длина пакета

    P_start

    DW

    ?

    ; Указатель на текущий пакет = Q_head - Q_begin +2

    NEW

    DB

    0

    ; Флаг нового пакета

    Line

    DB

    ?

    ; Строка экрана

    Npacks

    DD

    0

    ; Счетчик принятых пакетов

    B

    DW

    ?

    ; смещение Q_beg

    Point

    DW

    380 dup(?)

     

    Beg

    DB

    31000 dup(?)

    ; Пакетный буфер

    QUEUE

    ENDS

     

    ether_bdcst

    DB

    EADDR_LEN dup(-1)

    ; Широковещательный адрес Ethernet, заполненный -1.

    ether_addr

    DB

    EADDR_LEN dup(-1)

     

    bogus_type

    DB

    0,0;

     

    signature

    DB

    'PKT DRVR',0

    ; Сигнатура пакетного драйвера

    signature_len

    equ

    $-signature

     

    SAFE

    DW

    ?

     

    DFLAG

    DB

    0

     

    .CODE

     

    PUBLIC

    _INFACE

    _INFACE

    PROC

    NEAR


     

    CLD

     

     

    MOV DFLAG, 0

    ; Очистка флага драйвера

     

    MOV _PARAM.ER_CODE, 0

    ; Очистка флага ошибки

     

    PUSH BP

    ; Спасение регистров

     

    MOV BP, SP

     

     

    PUSH SI

     

     

    PUSH DI

     

     

    PUSH ES

     

     

    PUSH DS

     


     

    MOV CX, 32

     

     

    MOV AL, 60H

    ; Установка начального номера прерывания

     

    LEA SI, _PARAM.LINTN

    ; Формирование указателя на список номеров прерывания

    CHECK:

    PUSH AX

     

     

    PUSH CX

     

     

    PUSH SI

     

     

    CALL CHK_INT

     

     

    POP SI

     

     

    POP CX

     

     

    MOV byte ptr [SI], 0 ;

     

     

    JNE NO_SIGNATURE

     

     

    INC DFLAG

    ; Установка флага <Это драйвер>

     

    MOV BYTE PTR [SI], 1

    ; Установка флага наличия

    NO_SIGNATURE:

     

    POP AX

     

     

    INC AL

    ; Следующий номер прерывания

     

    INC SI

    ; Актуализация указателя

     

    LOOP CHECK

     


     

    CMP DFLAG, 0

    ; Драйвер присутствует?

     

    JNE HAVE_SIGNATURE

     

     

    MOV _PARAM.ER_CODE, 271

    ; Установка флага <No signature>

     

    JMP OKAY

     

    INT_PKT:

     

    PUSH ES

     

    pushf

     

    cli

     

    call _PARAM.HANDLER

     

    POP ES

     

    RET


    CHK_INT:

    PUSH ES

    ; AL = номер прерывания

     

    PUSH DI

     


     

    MOV AH, 35H

    ; Получение вектора прерывания

     

    INT 21H

    ; ES:BX=seg:offs драйвера


     

    MOV _PARAM.HANDLER.OFFS,BX

    ; Записываем адрес драйвера

     

    MOV _PARAM.HANDLER.SEGM, ES

     

     

    LEA DI, 3[BX]

    ; Устанавливаем смещение сигнатуры драйвера

     

    MOV SI, OFFSET SIGNATURE

    ; Проверка сигнатуры драйвера

     

    MOV CX, SIGNATURE_LEN

    ; Присутствует ли здесь драйвер?

     

    REPE CMPSB ; DS:[SI] - ES:[DI]

     


     

    POP DI

     

    POP ES

     

    RET


    HAVE_SIGNATURE:

     

    MOV CX, 32

    ; Установка начального значения счетчика

     

    LEA SI, _PARAM.LINTN

    ; Устанавливаем указатель списка

     

    MOV AL, 60H

    ; Задаем начальный номер прерывания

    CHOICE:

    CMP BYTE PTR [SI], 0

     

     

    JNE SETDRV

     

     

    INC AL

     

     

    LOOP CHOICE

     


    SETDRV:

    MOV AH, 35H

     

     

    INT 21H

     

     

    MOV _PARAM.HANDLER.OFFS,BX

    ; Определяем адрес драйвера

     

    MOV _PARAM.HANDLER.SEGM, ES

     


     

    PUSH DS

     

     

    POP ES

     

     

    MOV CX, EADDR_LEN

     

     

    MOV SI, OFFSET ETHER_ADDR

     

     

    MOV DI, OFFSET ETHER_BDCST

     

     

    REPE CMPSB

     

     

    JE GET_MODE

    ; Адрес не определен


     

    MOV AH, 25

    ; Записываем ethernet-адрес

     

    MOV DI, offset ETHER_ADDR

     

     

    MOV CX, EADDR_LEN

     

     

    call int_pkt

     

     

    MOV _PARAM.ER_CODE, DX

    ; Устанавливаем код ошибки

     

    JMP OKAY

     

    GET_MODE:

     

    MOV SAFE, DS

    ; Спасаем DS

     

    PUSH DS

     

     

    MOV AH, 2

    ; Открываем доступ пакетам

     

    MOV AL, 1

    ; Класс интерфейса

     

    MOV BX, -1

    ; Тип интерфейса

     

    MOV DL, 0

    ; Номер интерфейса

     

    MOV CX, 2

    ; Используем длину type = 2

     

    MOV SI, OFFSET BOGUS_TYPE

     

     

    PUSH CS

    ; ES:DI -> Receiver.

     

    POP ES

     

     

    MOV DI, OFFSET RECEIVER

     

     

    call INT_PKT

     

     

    JNC $_$

     

     

    MOV _PARAM.ER_CODE, DX

    ; Устанавливаем код ошибки

    $_$:

    MOV _PARAM.HANDLES, AX

    ; Записываем указатель-Handle


     

    MOV AH, 6

    ; Определяем ethernet-адрес интерфейса

     

    PUSH DS

     

     

    POP ES

     

     

    MOV DI, offset _PARAM.ETHER_ADR

     

     

    MOV CX, EADDR_LEN

     

     

    MOV BX, _PARAM.HANDLES

     

     

    call int_pkt

     

     

    JNC NOBAD

     

     

    MOV _PARAM.ER_CODE, 273

    ; Ошибка при определении Ethernet-адреса

     

    POP DS

     

     

    JMP OKAY

     

    NOBAD:

     

    MOV AX, 1FFH

    ; Запрашиваем информацию о драйвере

     

    MOV BX, _PARAM.HANDLES

    ; Устанавливаем указатель

     

    call INT_PKT

     

     

    JNC N_BAD

     

     

    MOV _PARAM.ER_CODE, 272

    ; Ошибка при получении информации о драйвере

     

    POP DS

     

     

    JMP OKAY

     


    N_BAD:

    PUSH DS

     

    PUSH SS

    &nsp;

    POP DS

     

    MOV ES, SAFE


     

    MOV _PARAM.L1, BX

    ; Версия драйвера

     

    MOV _PARAM.L2, CX

    ; номер/класс

     

    MOV _PARAM.L3, DX

    ; Тип

     

    MOV _PARAM.L4, AX

    ; Функциональность

     

    LEA BX, _PARAM._NAME

     

     

    POP DS

     

     

    MOV CX, 8

     

    ZFIND:

    CMP byte ptr [SI], 0

     

     

    MOV AL, byte ptr [SI]

     

     

    MOV byte ptr ES:[BX], AL

     

     

    JE ZERO_

     

     

    INC SI

     

     

    INC BX

     

     

    LOOP ZFIND

     

    ZERO_:

    POP DS

     

     

    MOV AH, 21

    ; Запрашиваем код режима приема пакетов

     

    MOV BX, _PARAM.HANDLES

     

     

    call INT_PKT

     

     

    MOV _PARAM.MODE, AX

    ; Записываем код режима

    .........................

    OKAY:

    POP DS

     

    POP ES

     

    POP DI

     

    POP SI

     

    MOV SP, BP

     

    POP BP

     

    RET


    RECEIVER:

    ; Подпрограмма RECEIVER, вызываемая при получении пакета

     

    OR AX, AX

    ; Первый или второй вызов?

     

    JNE RECV

     

     

    MOV AX, seg _Q.beg

    ; Указатель буфера ES:DI

     

    MOV ES, AX

     

     

    MOV DI, offset _Q.beg

     


    RECV:

    RETF

    2. Организация доступа для пакетов данного типа
    access_type(if_class, if_type, if_number, type, typelen, receiver)
    AH ==2 (код запроса)

    Запрос access_type инициализирует доступ для пакетов определенного типа (type). Аргумент typelen - длина спецификации типа в байтах, для PC/TCP равна 5 (наименьшее значение - 2, для IP и ARP). Аргумент receiver является указателем на подпрограмму, которая вызывается при приеме пакета. Получая пакет, драйвер дважды обращается к этой программе. Первый раз (при AX==0) это делается с целью получения адреса буфера, куда должен быть положен пакет. Прикладная программа в этом случае должна выдать указатель буфера в регистры ES:DI. Если прикладной процесс не имеет свободного буфера,то возвращается значение 0:0. Пакет выбрасывается и повторное обращение к программе receiver отменяется. Форма реализации запроса аналогична приведенному для driver_info:

    Int

    if_class; AL

    ; класс интерфейса

    Int

    if_type; BX

    ; тип интерфейса

    Int

    if_number; DL

    ; номер интерфейса

    Char

    far *type; DS:SI

     

    Unsigned

    typelen; CX

     

    Int

    (far *receiver); ES:DI

     


    access:

    mov ah, 2

     

     

    mov al, ch

    ; установка класса; здесь предполагается, что содержимое регистров соответствует тому, что получено в результате обращения к driver_info

     

    mov bx, dx

    ; устанавливаем параметр type

     

    mov dl, cl

    ; устанавливаем параметр number, при одном интерфейсе number=0

     

    xor cx, cx

    ; длина type равна нулю

     

    push cs

    ; устанавливаем сегментный регистр receiver

     

    pop es

     

     

    mov di, offset RECEIVER

    ; вызов подпрограммы receiver

     

    call int_pkt

    ; обращение к пакетному драйверу

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    2

    NO_CLASS не найдено интерфейса указанного класса;

    3

    NO_TYPE не найдено интерфейса указанного типа;

    4

    NO_NUMBER не найдено интерфейса с указанным номером;

    5

    BAD_TYPE специфицирован неправильный тип пакета;

    9

    NO_SPACE недостаточно места в памяти;

    10

    TYPE_INUSE было обращение к данному типу и он пока занят.

    При успешном выполнении запроса флаг carry=0, а в регистр AX занесен указатель (handle).

    Обращение к приемнику (receiver):

    (*receiver)(handle, flag, len [, buffer])

    int handle;

    BX

    ; указатель

    int flag;

    AX

    ; флаг вызова(0/1)

    unsigned len;

    CX

    ; целое без знака - длина пакета

    if AX == 1,

    char far *buffer;

    DS:SI

    ; адрес буфера

    Если параметр typelen равен нулю, прикладной процесс готов получать все пакеты. Очень важно, чтобы при первом обращении к receiver (AX==0) CX (длина пакета) была указана правильно, что позволит выделить нужное место в памяти. CX должна включать в себя длину MAC-заголовка и размер самого сообщения без контрольной суммы (CRC). Повторный вызов (AX==1) программы receiver указывает на то,что пакет записан в буфер и прикладная программа может с ним работать. Адрес буфера будет указан в регистрах DS:SI.

    3. Завершение доступа пакетов данного типа release_type

    int release_type(handle) AH == 3;
    код запроса int handle;
    BX ; указатель определяет тип пакетов

    _release_type proc near

     

    push bp

    ; спасение регистров

     

    push ds

     

     

    push es

     

     

    mov ah, 3

    ; задаем код запроса

     

    mov bx, _param.handle

    ; заносим указатель

     

    pushf

     

     

    cli

     

     

    call _param.handler

    ; обращение к драйверу

     

    mov _param.er_CODE, dx

    ; занесение кода ошибки

     

    pop es

    ; восстановление регистров

     

    pop ds

     

     

    pop bp

     

     

    ret

     

     

    _release_type

    endp

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможная ошибка: BAD_HANDLE (не верный указатель). При успешном выполнении запроса флаг carry=0. Эта операция прерывает доступ пакетов, соответствующих указателю, полученному с помощью запроса access_type. Старый указатель после выполнения этого запроса не действителен.

    4. Процедура посылки пакета send_packet(buffer, length)

    AH == 4 (код запроса)
    char far *buffer; DS:SI (адрес буфера)
    unsigned length; CX (длина пакета в байтах)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 12 CANT_SEND. send_packet отправляет пакет с числом байт, равным CX. Пакет должен в исходный момент лежать, начиная с адреса DS:SI. Прикладная программа должна сформировать все необходимые заголовки. Информация, нужная для осуществления демультиплексирования пакетов (MAC или LLC), также должна быть записана в пакет, так как при этом запросе не сообщается значение указателя (handle).

    5. Завершение работы драйвера terminate(handle)

    AH == 5 (код запроса)
    int handle; BX (указатель)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    1 BAD_HANDLE;
    7 CANT_TERMINATE.

    Завершает работу драйвера, соответствующего указателю, который приведен в качестве параметра запроса. Если возможно, драйвер будет выгружен и занимаемая им память освобождена.

    6. Получение физического адреса интерфейса get_address(handle,buf,len)

    AH == 6 (код запроса)
    int handle; BX (указатель)
    char far *buf; ES:DI (адрес буфера)
    int len; CX (длина адреса в байтах)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    1 BAD_HANDLE;
    9 NO_SPACE. При успешном выполнении запроса флаг carry=0, а в регистр CX занесена длина адреса.

    Копирует текущее значение сетевого (физического) адреса интерфейса в буфер. Если получено сообщение NO_SPACE, это означает, что выделенного места (len=CX) для копирования адреса не хватило.

    7. Возвращение интерфейса в исходное состояние reset_interface(handle)

    AH == 7 (код запроса)
    int handle; BX (указатель)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    1 BAD_HANDLE;
    15 CANT_RESET.

    Возвращает интерфейс в исходное состояние, прерывая все процессы. Местное значение физического сетевого адреса, если оно было изменено, восстанавливается из ROM, прием переключается в режим 3, а список мультикастинг-адресов обнуляется. При работе с несколькими указателями (handle) возможны серьезные неприятности, по этому выполнение запроса блокируется и присылается сообщение CANT_RESET.

    8. Запрос установки режима приема пакетов set_rcv_mode(handle,mode)

    AH == 20 (код запроса) int handle;
    BX (входные параметры - указатель) int mode;
    CX (код режима приема пакетов)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    1 BAD_HANDLE;
    8 BAD_MODE.

    Устанавливает режим приема пакетов. Режим 3 используется по умолчанию. Возможны (но не для всех интерфейсов) следующие режимы:

    Режим

    Значение

    1

    выключение приема пакетов;

    2

    прием пакетов, адресованных только данному интерфейсу;

    3

    режим 2 плюс бродкастинг-пакеты;

    4

    режим 3 плюс некоторые мультикастинг-пакеты;

    5

    режим 3 плюс все мультикастинг-пакеты;

    6

    все пакеты.

    9. Считывание действующего режима приема пакетов get_rcv_mode(handle)

    AH == 21 (код запроса)

    int handle; BX (входной параметр - указатель)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в регистр AX заносится код режима приема пакетов.

    10. Занесение списка мультикастинг-адресов в интерфейс set_multicast_list(addrlst,len)

    AH == 22 (код запроса)
    char far *addrlst; ES:DI (адрес буфера, где лежат адреса)
    int len; CX (длина списка адресов)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    6 NO_MULTICAST;
    9 NO_SPACE;
    14 BAD_ADDRESS.

    Список адресов представляет собой счетную последовательность, начинающуюся с байта числа адресов в списке. На список адресов указывает комбинация регистров ES:DI. Сообщение NO_SPACE присылается, если указатель адреса отсутствует, или число адресов превосходит аппаратные возможности интерфейса. Прежде чем заносить список, полезно сначала ознакомиться с имеющимся уже списком, выполнив запрос get_multicast_list. При получении сообщения NO_SPACE рекомендуется попытаться установить режим приема 3 с помощью запроса set_rcv_mode.

    11. Получение рабочего списка мультикастинг-адресов

    get_multicast_list

    AH == 23 (код запроса)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    6 NO_MULTICAST;
    9 NO_SPACE.

    При успешном выпонении запроса флаг carry=0, в регистр CX заносится длина списка адресов, а регистры ES:DI указывают на начало счетной оследовательности, где запрошенный список лежит. Прикладная программа не должна модифицировать этот список.

    12. Получение статистических данных об ошибках и трафике через данный интерфейсget_statistics(handle)

    AH == 24 (код запроса)
    int handle; BX (указатель)
    char far *statistics; DS:SI (адрес буфера, куда записываются статистические данные)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в массиве, начиная с адреса DS:SI, лежит запрошенная информация.

    struct statistics {

    unsigned long packets_in;

    ( Число принятых пакетов для всех указателей)

    unsigned long packets_out;

    ( Число посланных пакетов)

    unsigned long bytes_in;

    ( Число принятых байтов, включая MAC заголовки)

    unsigned long bytes_out;

    ( Число посланных байтов)

    unsigned long errors_in;

    ( Полное число ошибок при приеме)

    unsigned long errors_out;

    ( Число ошибок при посылке пакетов)

    unsigned long packets_lost;

    ( Число потерянных пакетов из-за отсутствия свободного буфера или других ресурсов)

    };

    Статистические данные имеют вид целых 32-разрядных чисел в формате IBM/PC.

    13. Смена физического адреса интерфейса

    set_address(addr, len) AH == 25
    char far *addr; ES:DI (адрес буфера, где лежит новое значение адреса)
    int len; CX (длина адреса в байтах)

    В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:

    13 CANT_SET;
    14 BAD_ADDRESS.

    При благоприятном выполнении запроса флаг carry=0, а значение регистра CX сохраняется.

    Запрос используется в случае, когда необходим специфический физический адрес интерфейса (например, в случае DECNET). При наличии более одного указателя (handle) драйвер откажется исполнить данный запрос и пришлет сообщение CANT_SET.

    Этим не исчерпывается перечень возможных запросов, существует некоторое количество операций, относящихся к экстра-набору функций (код функциональности 5 или 6, смотри описание запроса driver_info).

    Previous: 7.1 Winsock (для UNIX, Windows-95 и -NT)    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 8 Заключение    Next: 8 Заключение


    previous up down next index index
    Previous: 6.10 Идентификатор доступа к сети    UP: 6 Сетевая безопасность
    Down: 8 Заключение
        Next: 7.1 Winsock (для UNIX, Windows-95 и -NT)

    7 Программирование для сетей (новые идеи, принципы и возможности)
    Семенов Ю.А. (ГНЦ ИТЭФ)

     

    Volk und Knecht und Uberwinder
    Sie gestehn zu jeder Zeit
    Höchtest Glück der Erdenkinder
    Sie nur die Persönlichkeit

     

    В. Гёте

    Программирование - искусство индивидуальное, но сетевое программирование имеет много специфических особенностей, требующих выполнения определенных правил. Оно в значительной мере напоминает написание программ реального времени, так как здесь также приходится иметь дело с постоянно изменяющимися обстоятельствами. Заметные отличия возникают из-за работы в разных операционных системах (DOS, UNIX, Windows, OS/2). Существуют задачи, которые даже сегодня лучше реализовать в ОС DOS. К таким задачам следует отнести хронометраж некоторых сетевых операций (к сожалению многозадачные и многопользовательские системы довольно часто вносят ошибки в результаты временных измерений с использованием внутренних машинных часов). Кроме того, в рамках, например, ICMP.DLL нельзя послать очередной пакет до тех пор, пока не истечет таймаут или не будет получен отклик. Это также создает некоторые трудности. Да и библиотека RAWSOCK не у каждого под рукой. Если задача может быть решена в рамках Windows, ничего другого и не нужно (при всех бесчисленных недостатках эта среда наиболее дружественна к пользователю). В крайнем случае, можно без особого труда перенести ваше приложение в Windows NT или OS/2. Если же вы разрабатываете нечто для многопользовательской среды, стоит подумать о работе под ОС UNIX. Новейшие пакеты для работы с соединителями (socket) заметно облегчают работу программисту. Современные соединители (см. http: //www.stardust.com/wsresource/winsock2/ws2ident.html) способны настраиваться на протокольный набор (это не обязательно TCP/IP) и на конкретный протокол. Библиотеки допускают работу как IPv4 так и с IPv6, необходимо лишь корректно задать параметры. Идеология соединителей, пришедшая из UNIX, и унификация библиотек для работы с ними заметно облегчают перенос программ из одной ОС в другую. Сегодня программист, даже не вникая в особенности протокола, за счет использования стандартных библиотек может создать программу любого приложения. Современная среда программирования, особенно в Windows, позволяет сформировать и удобный интерфейс для работы с разрабатываемым приложением. Новейшие версии библиотек для работы с соединителями позволяют запускать и управлять несколькими процессами ввода/вывода одновременно.

    Следует иметь в виду, что, например, в системе UNIX все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (telnet, FTP, finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов.

    Практически любая утилита использует в качестве параметра имя какого-либо узла или ЭВМ. По этой причине исполнение программы начинается с посылки запроса серверу имен (DNS). После получения нужного IP-адреса посылается ARP-запрос. Далее формируется соединитель и посылается запрос, который зависит от типа реализуемого приложения.

    В следующих двух статьях рассмотрено программирование для DOS (непосредственная работа с драйвером сетевого интерфейса) и программирование для Windows. Программирование для UNIX во многом сходно с программированием для Windows, так как здесь используется сходная библиотека для работы с соединителями.

    Previous: 6.10 Идентификатор доступа к сети    UP: 6 Сетевая безопасность
    Down: 8 Заключение    Next: 7.1 Winsock (для UNIX, Windows-95 и -NT)


    previous up down next index index
    Previous: 7 Программирование для сетей (новые идеи, принципы и возможности)    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 8 Заключение
        Next: 7.2 Сетевые драйверы

    7.1 Winsock (для UNIX, Windows-95 и -NT)
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Какие бы замечательные идеи в области телекоммуникаций, распределенных баз знаний или поисковых систем вам не пришли в голову, реализовать их на практике можно, лишь написав соответствующую программу. Основные операционные среды (Unix, Windows 95, NT или 2000) базируются в настоящее время на идеологии соединителей (socket). Эта технология была разработана в университете г. Беркли (США) для системы Unix, поэтому соединители иногда называют соединителями Беркли (berkeley sockets). Соединители реализуют механизм взаимодействия не только партнеров по телекоммуникациям, но и процессов в ЭВМ вообще (см. [15]). Вопросы сетевого программирования под MS DOS рассмотрены в [24].

    Работа с соединителями содержит ряд этапов: соединитель создается, настраивается на заданный режим работы, используется для организации обмена и, наконец, ликвидируется. Технология соединителей поддерживает работу с любыми стеками протоколов, совмещенные процедуры ввода/вывода, использование большого числа сервис-провайдеров (серверов услуг), возможность группирования соединителей, что позволяет реализовать их приоритетное обслуживание, и многое другое. Набор операторов, поддерживающих интерфейс сервис провайдера, образует отдельную динамическую библиотеку.

    Для общей синхронизации работы сервис-провайдеров и приложений в winsock введено понятие объектов событий. Объекты событий служат в частности для организации работы совмещенных по времени процессов информационного обмена. Здесь уместно замечание об использовании стандартных номеров портов. В много задачных, многопользовательских системах стандартные номера портов используются при инициализации процесса. Так как допускается несколько идентичных соединений (например, несколько одновременных сессий FTP) между клиентом и сервером, стандартными номерами портов здесь не обойтись. Ведь psips сервера могут соотвествовать несколько pcipc клиента.

    В системах, ориентированных на соединение, пара комбинаций IP-адресов и номеров портов однозначно определяет канал связи между двумя процессами в ЭВМ. Такая комбинация называется соединителем (socket). Номера портов могут и совпадать, так как относятся к разным машинам, но IP-адреса должны быть обязательно разными. Впервые идея соединителя была использована в системе 4.3 BSD Unix для организации сетевого ввода/вывода. В Unix внешнее устройство и файл с точки зрения системного программиста эквивалентны. Сетевые процедуры несколько сложнее и не укладываются в такую простую схему. Из этой простой схемы выпадают, прежде всего, операции, при которых сервер пассивно ожидает обращения особенно для операций обмена не ориентированных на соединение. Соединитель является пограничным понятием между протоколами телекоммуникаций и операционной системой ЭВМ. Соединители играют важную роль при написании прикладных программ (API).

    Соединитель отправителя = IP-адрес отправителя + номер порта отправителя
    Соединитель адресата = IP-адрес адресата + номер порта адресата

    Межкомпьютерные коммуникации не сводятся к знакомству с соседским депозитарием, к выполнению операций Telnet, FTP и т.д. Одной из важнейших задач является удаленный контроль за процессами в больших рассредоточенных системах, когда обмен информацией активизируется не человеком, а ЭВМ. Примерами таких задач могут служить управление современными высокотехнологичными производствами, сбор метео- или другой геофизической информации в реальном масштабе времени, эксперименты в области физики высоких энергий, где для контроля установки и сбора экспериментальных данных используются десятки (а иногда и сотни) вычислительных машин, которые обмениваются диагностической информацией и данными. Именно для решения таких задач и применяются идеи соединителей (sockets), "труб" и т.д.. Понятие соединителя в прикладных программах это не просто комбинация IP-адресов и номеров портов, это указатель на структуру данных, где хранятся параметры виртуального канала. Прежде чем воспользоваться соединителем, его нужно сформировать. Оператор формирования соединителя имеет вид:

    s=socket(INT AF, INT type, INT protocol);

    где все параметры целочисленные, AF (address_family) - характеризует набор протоколов, соответствующий данному соединителю (это может быть набор Internet, Unix, Appletalk и т.д.). Для Интернет AF может принимать только значение PF_INET, для Unix - PF_UNIX. Аргумент type определяет тип коммуникаций (SOCK_STREAM, SOCK_RAW, и SOCK_DGRAM). Аргумент protocol задает код конкретного протокола из указанного набора (заданного AF), который будет реализован в данном соединении. Протоколы обозначаются символьными константами с префиксом IPPROTO_ (например, IPPROTO_TCP или IPPROTO_UDP). Допускается значение protocol=0 (протокол не указан), в этом случае используется значение по умолчанию для данного вида соединений. Значения AF и type можно обычно найти в файле <sys/socket.h>. Возвращаемый параметр S представляет собой дескриптор соединителя. Параметр SOCK_STREAM говорит о том, что вы намерены создать надежный двунаправленный канал обмена, ориентированный на соединение (TCP для Интернет). Связь c другим процессом в этом случае устанавливается оператором connect. После установления соединения данные могут посылаться оператором send или получаться посредством оператора recv. Параметр SOCK_DGRAM характеризует канал, не ориентированный на соединение, с пакетами фиксированного размера (например, UDP в случае AF= PF_INET). Такой канал позволяет использовать операторы sendto и recvfrom. Параметр SOCK_RAW определяет третий режим, при котором возможно использование протоколов нижнего уровня, например ICMP. Таким образом, формирование соединителя - это создание описывающей его структуры данных.

    Если операция socket завершилась успешно, s равно дескриптору соединителя, в противном случае s=INVALID_SOCKET (-1). С помощью оператора WSAGetLastError можно получить код ошибки, проясняющий причину отрицательного результата.

    Дескриптор соединителя указывает на элемент таблицы дескрипторов, соответствующий данному соединителю. Оператор socket отводит место в этой таблице. Элемент такой таблицы имеет вид:

    Код семейства протоколов;
    Код типа сервиса;
    Локальный IP-адрес;
    Удаленный ipIPадрес;
    Номер локального порта;
    Номер удаленного порта;

    IP-адрес определяет интерфейс ЭВМ, а номер порта в данном случае характеризуют сетевую процедуру.

    Так как в Unix возможно формирование соединителя без IP-адресов, а для практической работы они нужны, имеется оператор bind, который позволяет присвоить определенный адрес заданному соединителю:

    r=bind(s, const struct socketaddr far*name, int namelen),

    где s - целочисленный код дескриптора, параметр name (идентификатор локального адреса) обычно (для Интернет) содержит три величины: IP-адрес ЭВМ, код протокольного набора, номер порта, который определяет характер приложения. Структура адресной информации имеет вид:

    struct sockaddr {
    u_short sa_family;
    char sa_data[14];
    };

    Параметр namlen определяет длину второго параметра. В рамках этой идеологии легко реализовать систему клиент-сервер. IP-адрес может быть сделан равным INADDR_ANY (или =0), если ЭВМ имеет несколько интерфейсов. При номере порта равным нулю, windows socket присвоит порту уникальный номер в диапазоне 1024-5000. Приложение может выполнить операцию getsockname после bind, чтобы определить присвоенный адрес. Оператор bind выполняется до операций connect или listen. При корректном выполнении оператор bind возвращает код 0 (r=0), в противном случае SOCKET_ERROR=-1. Команда bind выдается для записи собственного номера порта. Сервер генерирует команду bind, чтобы подготовить определенный вид связи (например, FTP), и пассивно ожидает запроса connect со стороны клиента:

    R=connect(s, const struct socketaddr FAR*name, int namelen),

    где s - дескриптор соединителя, name - идентификатор адреса места назначения (указатель на структуру данных), а namelen - длина этого адреса. Таким образом, оператор connect сообщает ip-адрес и номер порта удаленной ЭВМ. Если адресное поле структуры name содержит нули, оператор connect вернет ошибку WSAEADDRNOTAVAIL (или SOCKET_ERROR=-1). Установка в режим ожидания осуществляется командой listen, которая организует очередь запросов:

    R=listen(s, int backlog),

    где backlog - задает максимальный размер очереди для приходящих запросов соединения (то есть сколько запросов может быть принято на обслуживание без потерь, обычно этот параметр равен 5). При переполнении очереди будет послано сообщение об ошибке. Следует иметь в виду, что клиент, ориентированный на соединение, также должен прослушивать порт протокола, ожидая появления дейтограмм-откликов. Ожидающий соединитель посылает каждому отправителю сообщение-отклик, подтверждающее получение запроса на соединение. Оператор listen подготавливает соединитель к обработке потока запросов, система должна быть достаточно быстродействующей. Запросы из очереди извлекаются оператором accept:

    R=accept(s, struct sockaddr FAR*addr, int FAR*addrlen),

    где s - дескриптор соединителя, который прослушивает соединение (тот же, что и в listen), addr - опционный указатель на структуру, которая содержит адрес, addrlen - код длины адреса. Оператор accept позволяет серверу принять запрос от клиента. Когда входная очередь сформирована, программа реализует процедуру accept и переходит в режим ожидания запросов. Программа извлекает первый элемент очереди, создает новый соединитель со свойствами, идентичными s, и при успешном выполнении возвращает дескриптор нового соединителя. При возникновении ошибки возвращается код INVALID_SOCKET. По окончании обработки запроса сервер вновь вызывает accept, который возвращает ему дескриптор соединителя очередного запроса, если таковой имеется. Если очередь пуста, accept блокирует программу до получения связи. Существуют серверы с параллельной и последовательной обработкой запросов. Параллельный обработчик запросов не ждет завершения обработки предшествующего запроса и вызывает оператор accept немедленно. В системе Unix используются обычно параллельные обработчики запросов.

    Схема взаимодействия различных операторов winsock в рамках идеологии клиент/сервер для случая процедур, ориентированных на соединение, показана на рисунке 7.1. Стрелками обозначены направления посылки сетевых сообщений.

    Следует иметь в виду, что программе клиента (выделена рамкой) не нужно знать номер порта, по этой причине она не обращается к процедуре bind, а для установления связи сразу вызывает оператор connect. Современные распределенные информационные системы, WWW-серверы, поисковые системы и т.д. эффективно используют механизмы формирования соединителей и многие процедуры, описанные в данном разделе. Из литературы [24] известно, что для многих видов услуг в Интернет выделены строго определенные номера портов. Доступ же к этим услугам должен быть обеспечен достаточно большому числу пользователей. С клиентской стороны при этом используются номера портов со значениями из диапазона 1024-5000. Для каждого нового клиентского запроса в ЭВМ-сервере, как правило, открывается новый процесс.

    Рис. 7.1.Схема взаимодействия операторов winsock для процедур, ориентированных на соединение

    Лишь при успешной реализации всех перечисленных операций может начаться обмен данными. Для пересылки данных могут использоваться команды write, read, send, recv. Команды write и read имеют форму вызова:

    R=write(s, buf, len) или R=read(s, buf, len),

    где s - дескриптор соединителя, buf - имя массива, подлежащего пересылке (или предназначенного для приема), len - длина этого массива. Оператор writev отличается от write тем, что данные могут не лежать в виде непрерывного массива:

    R=writev(s, io_vect, vectlen) или R=readv(s, io_vect, vectlen),

    где s - дескриптор соединителя, io_vect - вектор-указатель на список указателей, vectlen - длина списка указателей. Команда выполняется медленнее, чем write или read. Список указателей имеет формат (рис. 7.2):

    Рис. 7.2 Формат списка указателей для функций readv и writev

    Команды send(s, msg_buf, buflen, flags) и recv имеют аналогичный формат, но среди параметров обращения содержат переменную flags, которая служит для целей диагностики и управления передачей данных (например, пересылка информации с высоким приоритетом (MSG_OOB - Message Out Of Band), что используется, в частности, при передаче звуковых сообщений). При работе с операторами send или recv надо быть уверенным, что принимающая сторона знает, что ей следует делать с этими приоритетными сообщениями. Другой возможный флаг, определяемый константой MSG_PEEK, позволяет анализировать запросы из входной очереди транспортного уровня. Обычно после считывания данных из входной очереди, они уничтожаются. Когда MSG_PEEK=1, данные из входной очереди не стираются. Этот флаг используется, например, программой FTP. При успешном выполнении команды будет возвращено число переданных байтов, в противном случае -1.

    Все перечисленные выше операторы рассчитаны на использование в рамках протоколов, ориентированных на установление соединения (TCP), где не требуется указание адреса места назначения. В протоколах типа UDP (не ориентированных на соединение) для передачи информации используются операторы sendto, recvfrom или sendmsg:

    R=sendto(s, msg_buf, buflen, flags, adr_struc, adr_struc_len)
    или recvfrom(s, msg_buf, buflen, flags, adr_struc, adr_struc_len),

    где s - дескриптор соединителя, msg_buf - указатель на буфер, где лежит сообщение, buflen - длина этого буфера (длина сообщения), adr_struc - адресная структура, содержащая исчерпывающую информацию об адресате, adr_struc_len - длина этой структуры. Оператор recvfrom принимает все данные, приходящие на его порт. Приняв дейтограмму, recvfrom записывает также адрес, откуда эта дейтограмма получена. Сервер может посылать по этому адресу дейтограмму-отклик. Вызов оператора sendmsg имеет форму:

    R=sendmsg(s, msg_struc, flags) [или recvmsg(s, msg_struc, flags)],

    где s - дескриптор соединителя, msg_struc - информационная структура, формат которой показан ниже на рисунке 7.3. Применение структур делает программирование пересылки сообщений более гибким. Следует учитывать, что для обменов, не ориентированных на соединение, соединитель как бы состоит лишь из одной половины (IP-адрес и номер порта). "Соединители", созданные для обмена (UDP) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных "соединителей" и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).

    Рис. 7.3. Формат информационной структуры msg_struc

    Взаимодействие операторов winsock для систем, не ориентированных на соединение, показано на рисунке 7.4. Здесь также как и в случае, ориентированном на соединение, сервер вызывает socket и bind, после чего обращается к процедуре recvfrom (вместо read или recv). Программа-клиент в данной схеме обращается к оператору bind и совсем не использует оператор connect (ведь предварительного соединения не нужно). Для передачи запросов и приема откликов здесь служат операторы sendto и recvfrom, соответственно.

    Рис. 7.4. Схема взаимодействия операторов winsock для процедур, не ориентированных на соединение

    Помимо уже описанных операторов для работы с соединителями (sockets) имеется еще один - select, довольно часто используемый серверами. Оператор select позволяет процессу отслеживать состояние одного или нескольких соединителей. Для каждого соединителя вызывающая программа может запросить информацию о статусе read, write или error. Форма обращения имеет вид:

    R=select(num_of_socks, read_socks, write_socks, error_socks, max_time),

    где num_of_socks - число контролируемых соединителей (в некоторых реализациях не используется и является необязательным, по умолчанию это число не должно превышать 64). В версии Беркли read_socks, write_socks и error_socks представляют собой побитовые маски, определяющие тип соединителя. Параметр read_socks представляет собой указатель на структуру, описывающую набор соединителей, состояние которых контролируется на возможность чтения (версия winsock). Если соединитель находится в состоянии listen, он будет помечен как "готов для чтения", при условии, что запрос на соединение уже получен. Это предполагает выполнение оператора accept без блокировки. Для других соединителей "готовность к чтению" подразумевает наличие в очереди запросов чтения. Для соединителей типа SOCK_STREAM это означает, что виртуальный соединитель, соответствующий данному соединителю закрылся, и операторы recv или recvfrom будут выполнены без блокировки. Если виртуальное соединение закрыто корректно, оператор recv вернет код 0, в противном случае (например, принудительное закрытие) будет возвращен код WSAECONNRESET. Параметр write_socks - указатель на набор соединителей, состояние которых контролируется на возможность записи. Если соединитель находится в процессе выполнения процедуры connect, "способность к записи" означает, что установление связи завершено. Для других соединителей это значит, что операции send или sendto будут выполнены без блокировки. Параметр error_socks - это указатель на набор соединителей, контролируемых на ошибки. В некоторых реализациях этот аргумент идентифицирует список соединителей, помеченных как приоритетные. Соединитель помечается как приоритетный, если опция SO_OOBINLINE=FALSE. На случай ошибки оператор select отмечает соединитель, где это произошло. select работает лишь с теми соединителями, которые были выделены с помощью масок. При успешном выполнении оператор возвращает число соединителей, готовых к операциям ввода/вывода и модифицирует коды масок в соответствии с состоянием соединителей. Прикладная программа может использовать результаты вызова оператора select, анализируя полученные коды масок. Аргумент max_time определяет максимальное время, выделенное select для завершения своей работы. Для уточнения типа ошибки, возникшей при исполнении операции select, можно воспользоваться процедурой WSAGetLastError.

    Другим важным оператором является closesocket(s), который закрывает канал соединителя с одной из сторон. Все описанные выше операторы (кроме socket, bind и listen) блокируют работу программы до своего завершения. Практически любая операция, непосредственно связанная с выполнением процедур ввода/вывода, может блокировать выполнение других прикладных функций winsock.

    Для обслуживания прикладных процессов (например, WWW-сервера, работа с распределенными базами данных и пр.) разработано много других сервисных программ (WINSOCK.DLL), перечень которых представлен в таблице 7.1.

    Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)

    Имя команды

    Назначение

    getdomainname

    Возвращает имя домена

    gethostbyname

    Возвращает IP-адрес для заданного сетевого имени.

    gethostname

    Возвращает имя ЭВМ (обычно имя ее домена).

    gethostadr

    Возвращает IP-адрес ЭВМ.

    getnetaddr

    Возвращает адрес сети.

    getnetname

    Возвращает имя сети.

    getpeername

    Возвращает имя партнера, подключенного к соединителю.

    getportbyname

    Возвращает имя и код протокола для указанного имени (например, ICMP, UDP или TCP)

    getportbynumber

    Возвращает имя протокола для указанного его кода

    getservbyname

    Извлекает из базы данных название протокола и номер порта для указанного имени сетевой услуги

    getservbyport

    Возвращает имя сетевой услуги для заданного номера порта

    getsockname

    Возвращает местный адрес соединителя.

    getsockopt

    Запрашивает информацию о соединителе.

    htonl

    Преобразует порядок байтов 32-разрядного кода из машинного в сетевой.

    htons

    Преобразует порядок байтов 16-разрядного кода из машинного в сетевой.

    inet_addr

    Преобразует символьную строку IP-адреса из десятично-точечного формата в 32-разрядный код с сетевым порядком байтов.

    inet_ntoa

    Преобразует IP-адрес в десятично-точечный формат.

    ioctlsocket

    Управляет параметрами соединителя, связанными с обработкой операций ввода/вывода.

    ntohl

    Преобразует порядок байтов 32-разрядного кода из сетевого в машинный.

    ntohs

    Преобразует порядок байтов 16-разрядных кодов из сетевого в машинный.

    ethostname

    Устанавливает имя ЭВМ.

    setsockopt

    Устанавливает опции соединителя.

    shutdown

    Закрывает один из концов дуплексного канала для местной ЭВМ.

    socketpair

    Генерирует пару соединителей.

    Большинство перечисленных команд имеют развитую систему диагностики, кроме того, во многих реализациях Unix имеется много других полезных команд, описание которых вы можете найти в инструкциях по использованию системы Unix. Рассмотрим некоторые из них.

    Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы). Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM.

    Программа setsockopt(s, int level, int optname, const char far* optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2):

    Таблица 7.2. Опции соединителей для оператора setsockopt.

    Опция

    Тип

    Назначение

    SO_BROADCAST

    булев

    Позволяет передачу широковещательных сообщений

    SO_DEBUG

    булев

    Осуществляет запись отладочных данных.

    SO_DONTLINGER

    булев

    Разрешает закрытие без ожидания при наличии не отосланной информации. Эта опция эквивалентна SO_LINGER с l_onoff=0.

    SO_DONTROUTE

    булев

    Запрет маршрутизации - отправка непосредственно интерфейсу.

    SO_KEEPALIVE

    булев

    Посылка сообщения keepalive ("еще жив")

    SO_LINGER

    структура

    Задержка закрытия в случае наличия не отосланной информации.

    SO_OOBINLINE

    булев

    Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных

    SO_RCVBUF

    целый

    Определяет размер входного буфера

    SO_REUSEADDR

    булев

    Позволяет соединителю использовать адрес, который уже задействован

    SO_SNDBUF

    целый

    Определяет размер выходного буфера

    TCP_NODELAY

    булев

    Запрещает использование алгоритма Нагля (TCP).

    Программа getsockopt(s, int level, int optname, char far* optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций.

    В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2).

    Таблица 7.3. Опции соединителей для оператора getsockopt

    Опция

    Тип

    Назначение

    SO_ACCEPTCONN

    булев

    Соединитель в режиме listen

    SO_BROADCAST

    булев

    Разрешена передача широковещательных сообщений

    SO_DEBUG

    булев

    Отладочный режим разрешен

    SO_DONTLINGER

    булев

    Если равен TRUE, SO_LINGER-опция запрещена

    SO_DONTROUTE

    булев

    Запрет маршрутизации.

    SO_ERROR

    целое

    Выдает статус ошибок

    SO_KEEPALIVE

    булев

    Сообщение keepalive ("еще жив") послано

    SO_LINGER

    структура

    Возвращает текущие значения опции SO_LINGER

    SO_OOBINLINE

    булев

    Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных

    SO_RCVBUF

    целый

    Сообщает размер входного буфера

    SO_REUSEADDR

    булев

    Соединителю разрешено использовать адрес, который уже задействован

    SO_SNDBUF

    целый

    Сообщает размер выходного буфера

    SO_TYPE

    целый

    Тип соединителя (например, SOCK_STREAM)

    TCP_NODELAY

    булев

    Использование алгоритма Нагля запрещено (tcp).

    Таблица 7.4. Основные операторы winsock

    Имя оператора

    Назначение

    WSAAsyncGetHostByAddr

    Аналог оператора gethostbyaddr

    WSAAsyncGetHostByAddr

    Аналог оператора gethostbyaddr

    WSAAsyncGetHostByName

    Аналог оператора gethostbyname

    WSAAsyncGetProtoByName

    Аналог оператора getprotobyname

    WSAAsyncGetProtoByNumber

    Аналог оператора getprotobynumber

    WSAAsyncGetServByName

    Аналог оператора getservbyname

    WSAAsyncGetServByPort

    Аналог оператора getservbyport

    WSAAsyncSelect

    Функциональный аналог оператора select

    WSACancelAsyncRequest

    Прерывает выполнение операторов типа WSAAsyncget*by*

    WSACancelBlockingCall

    Прерывает выполнение блокирующего оператора приложения (API)

    WSACleanup

    Сообщает Windows sockets о завершении работы программы с DLL

    WSAGetLastError

    Выдает сообщение о последней ошибке

    WSAIsBlocking

    Определяет, является ли Winsock DLL блокирующей

    WSASetBlockingHook

    Устанавливает перехват блокирующего вызова

    WSASet LastError

    Фиксирует тип ошибки для последующего вызова WSALastError

    WSAStartup

    Инициализирует следующий уровень Winsock

    WSAUNhookBlockingHook

    Восстанавливает прежнюю блокировку.

    Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку.

    Таблица 7.5. Асинхронные операторы

    WSAAccept*

    Расширенная версия accept, которая позволяет условное подключение и формирование групп соединителей.

    WSACloseEvent

    Уничтожает объект события.

    WSAConnect*

    Расширенная версия connect, которая позволяет обмениваться данными о соединении и QoS-информацией.

    WSACreateEvent

    Создает объект события.

    WSADuplicateSocket

    Создает новый дескриптор соединителя для случая использования его несколькими процессами.

    WSAEnumNetworkEvents

    Выявляет сетевые события.

    WSAEnumProtocols

    Выдает информацию о каждом доступном протоколе.

    WSAEventSelect

    Связывает сетевое событие с объектом события.

    WSAGetOverlappedResult

    Сообщает состояние выполнения совместной операции обмена.

    WSAGetQOSByName

    Выдает параметры qos для заданного имени сетевой услуги.

    WSAHtonl

    Расширенная версия htonl

    WSAHtons

    Расширенная версия htons

    WSAIoctl*

    Версия ioctlsocket, пригодная для совмещения процедур ввода/вывода

    WSAJoinLeaf*

    Подключает периферийный узел к многоточечной сессии.

    WSANtohl

    Расширенная версия ntohl

    WSANtohs

    Расширенная версия ntohs

    WSARecv*

    Расширенная версия recv, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров.

    WSARecvDisconnect

    Завершает работу соединителя и выдает информацию о завершении, если соединитель был ориентирован на работу в связанном состоянии.

    WSARecvFrom*

    Расширенная версия recvfrom, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров

    WSAResetEvent

    Обнуляет объект события.

    WSASend*

    Расширенная версия send, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.

    WSASendDisconnect

    Инициализирует процедуру закрытия соединения и опционно посылает сообщение disconnect.

    WSASendTo*

    Расширенная версия sendto, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.

    WSASetEvent

    Устанавливает объект события.

    WSASocket

    Расширенная версия socket, которая использует структуру WSAPROTOCOL_INFO в качестве входной информации и позволяет создать соединители, работающие одновременно. Позволяет также формировать группы соединителей.

    WSAWaitForMultipleEvents

    Присылается, если любой или все специфицированные объекты находятся в сигнальном состоянии или когда истекает время таймаута.

    * Программа может вызвать блокировку при работе с блокирующим соединителем.

    При написании программ на персональной ЭВМ, например, на С++ или ассемблере существует возможность выбора модели памяти: small, medium, compact, large или huge. Эти модели отличаются друг от друга числом сегментов (по 64 Кбайт) памяти, выделяемой для программы и данных. Модель small предполагает, что все указатели имеют тип near, если явно не указано обратное (не записан модификатор FAR). Модель large считает по умолчанию все указатели дальними, если явно не присутствует модификатор near. В модели huge длина блока данных может превышать размер одного сегмента. С особенностями этих моделей рекомендуется ознакомиться по описаниям конкретных трансляторов. Используя те или иные модели при создании сетевых программ, нужно учитывать проблемы, которые могут возникнуть при переносе вашей программы из одной операционной среды в другую. ОС Unix, Windows NT и Windows 97 не поддерживают каких-либо моделей памяти и их система адресации скорее совместима с моделью large. Но при переносе программы из одной среды в другую об этой проблеме лучше не забывать и перед началом отладки полезно изучить особенности адресации.

    При программировании под Windows 3.1 нужно учитывать то, что для доступа к процессору (ЦПУ) необходимо, чтобы программа, захватившая его раньше, прекратила свою работу и освободила ЦПУ. Этого не требуется в среде Unix, Windows 95 или Windows NT. Различие этих операционных сред особенно заметно при выполнении блокирующих процедур, рассмотренных выше, например операции сетевого ввода/вывода. Блокирующие процедуры являются потенциальным источником "повисания" программ, например, оператор recv может вечно ждать отклика, в то время как удаленный сервер будет ждать сообщения от программы, выполняющей recv. По этой причине создание не блокирующих соединителей представляется привлекательным. Такие соединители формируются путем вызова стандартного оператора socket с последующим обращением к процедуре, изменяющей режим работы соединителя (по умолчанию создается блокирующий соединитель). После этого при вызове блокирующего оператора, например, recv при условии, что соединитель не имеет запрашиваемых данных, система возвратит флаг ошибки. Таким образом, при работе с неблокирующим соединителем, операционная система проверяет возможность немедленного выполнения процедуры, и возвращает сигнал ошибки, если это не возможно. Все операторы winsock являются асинхронными и неблокирующими. Асинхронные операции при невозможности выполнить требуемую операцию не выдают сообщения об ошибке, за тем, чтобы процедура была выполнена так как нужно, в этом случае следит операционная система. По завершении асинхронной операции ОС Windows посылает сообщение тому окну, из которого эта операция была вызвана. Но и операторы, работающие с неблокирующими соединителями Беркли, также являются неблокирующими. В то же время все операции ввода и вывода в Unix являются синхронными.

    Хотя оператор WSAAsyncSelect считается аналогом select, между ними имеется существенное отличие. WSAAsyncSelect - единственный оператор, использующий дескриптор соединителя в качестве параметра. Если select контролирует состояние нескольких соединителей, для того чтобы достичь того же результата с помощью wsaasyncselect надо реализовать столько вызовов, сколько соединителей мы хотим мониторировать. Форма обращения к WSAAsyncSelect имеет вид:

    WSAAsyncSelect(SOCKETs, HWND hWnd, unsigned int wMsg, long lEvent),

    где s - дескриптор соединителя, состояние которого мы хотим контролировать, аргумент, hWnd - дескриптор окна-получателя сообщения; wMsg - определяет тип посылаемого сообщения (эти два параметра являются стандартными для всех функций Windows); lEvent - битовая маска, определяющая тип событий, которые нас интересуют. Возможные значения параметра lEvent приведены в таблице 7.6.

    Таблица 7.6. Возможные значения параметра lEvent оператора WSAAsyncSelect

    Значение

    Назначение

    FD_READ

    Готовность к чтению

    FD_WRITE

    Готовность к записи

    FD_OOB

    Поступление Out_Of_Band данных

    SD_ACCEPT

    Контроль установки входного соединения

    FD_CONNECT

    Контроль реализованных соединений

    FD_CLOSE

    Контроль закрытия соединения

    При необходимости контроля комбинации вышеперечисленных состояний эти маски могут объединяться по ИЛИ. Как только состояние соединителя станет соответствовать выбранной маске, Windows пошлет прикладной программе соответствующее сообщение. Это сообщение содержит дескриптор окна, откуда осуществлен вызов процедуры WSAAsyncSelect, идентификатор сообщения, а также 16-битовый и 32- битовый параметры этого сообщения. Первый из них представляет собой дескриптор соединителя, где это событие произошло. Младшие 16 бит второго параметра являются кодом события, а старшие предназначены для записи кода ошибок, если они произошли.

    Как уже было отмечено, обращение к WSAAsyncSelect переводит соединитель в неблокирующее состояние. При необходимости реализовать, например, процедуру recv, следует обратиться с начала к WSAAsyncSelect, запросив Windows информировать вас о готовности чтения (lEvent=FD_READ). После этого обработчик сообщений windows при получении соответствующего сигнала предоставит возможность прикладной программе перейти к выполнению операции recv. Так как соединитель уже получил данные, блокировки не произойдет и программа их немедленно получит.

    Особое внимание блокирующим операциям должно быть уделено в Windows 3.1, поскольку блокировка остановит не только выполнение задачи, вызвавшей эту операцию, но и все другие приложения (ЭВМ станет неуправляемой на время блокировки). Здесь блокирующие процедуры должны быть запрещены, вместо этого при необходимости вызова такой процедуры windows реализует цикл по проверке состояния соединителя (очереди сообщений). Остальные приложения могут при этом продолжить свою работу, а при получении благоприятного сообщения Windows разрешает выполнение блокирующей процедуры, так как она уже не может вызвать блокировки. Осложнения могли бы возникнуть, если обработчик сообщений Windows получит сигнал, который приведет к вызову другой блокирующей процедуры. Сегодня в Windows действует правило, запрещающее такие вызовы из прикладных программ как блокирующие, так и неблокирующие. То есть, на время выполнения блокирующей процедуры все обращения к сетевому интерфейсу запрещены.

    Имеется несколько операторов Winsock, предназначенных для работы с блокирующими процедурами (смотри таблицу 7.7):

    Таблица 7.7.

    WSACancelBlockingCall

    прерывание блокирующей процедуры (без аргументов);

    WSAIsBlocking

    определение блокирующей операции (без аргументов);

    WSASetBlockingHook

    перехват блокирующего вызова, организация цикла ожидания;

    WSAUNhookBlockingHook

    восстановление прежней блокировки.

    При необходимости прервать блокирующую операцию можно вызвать процедуру WSACancelBlockingCall, прикладная программа получит при этом сообщение об ошибке (WSAEINTR). Оператор WSAIsBlocking возвращает значение TRUE, если в данный момент реализуется блокирующая операция. Последние два оператора из четырех названных служат для построения пользовательских обработчиков сообщений.

    Аппарат соединителей предполагает возникновение и исчезновение вычислительных и управляющих процессов. Новый процесс может наследовать "старые" соединители. В этом случае может возникнуть необходимость выяснить, адрес партнера, с которым взаимодействует данный соединитель. Эту задачу можно решить с помощью команды getpeername(s, destaddr, addrlen), где destaddr - указатель на структуру типа (рис. 7.5):

    Рис. 7.5. Указатель на структуру типа для команды getpeername

    AF - идентифицирует семейство протоколов (для TCP/IP=2), для которого порожден данный соединитель, вся структура занимает 16 октетов. addrlen - указатель на переменную, куда будет записана длина адреса. Соединитель может быть выключен командой close(s), где s идентификатор соединителя, который надлежит закрыть. Если пользователь не хочет более посылать или получать данные, он может выдать команду shutdown(s, how), где параметр how может принимать значения: 0 - блокируется прием данных; 1 - блокируется передача данных; 3 - блокируются любые обмены.

    Каждое соединение должно иметь свой неповторимый код ISN (Initial Sequence Number). Этот код посылается клиентом серверу с помощью сегмента SYN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (ESTABLISHED, CLOSED, LISTEN, SYN_SENT, SYN_RCVD и т.д.), переход между которыми строго регламентирован (смотри раздел 4.4.3).

    При написании диагностических и управляющих программ под Windows 95 или NT можно использовать простые соединители (Sock_Raw) или библиотеку ICMP.DLL (эта динамическая библиотека не является частью Win32 API). Библиотека ICMP.DLL содержит в частности процедуру ICMPSendEcho, которая посылает запросы эхо по указанному адресу и возвращает отклик в пределах указанного временного интервала. В качестве аргументов запрос ICMPSendEcho использует ICMP-дескриптор, который получается в результате запроса IcmpCreateFile.

    HANDLE WINAPI IcmpCreateFile(VOID);
    /* Оператор создает ICMP-дескриптор; при ошибке возвращает INVALID_HANDLE_VALUE */
    BOOL WINAPI IcmpCloseHandle(HANDLE IcmpHandle);
    /* Оператор ликвидирует ICMP-дескриптор; при возникновении ошибки возвращает значение FALSE */

    Обращение к процедуре посылки ICMP запроса эхо имеет формат:
    DWORD WINAPI IcmpSendEcho(
    HANDLE IcmpHandle,
    /* дескриптор, полученный в результате запроса IcmpCreateFile */

    u_long DestAddress,

    /* IP адрес точки зондирования */

    LPVOID RequestData,
    /* указатель на буфер, где лежат данные, подлежащие посылке */

    WORD RequestSize,

    /* длина этого буфера */

    LPIPINFO RequestOptns,

    /* указатель на структуру ICMP-опций */

    LPVOID ReplyBuffer,
    /* указатель на буфер для приема пакета-отклика */

    DWORD ReplySize,

    /* размер буфера для пакета-отклика */

    DWORD Timeout

    /* время ожидания отклика в миллисекундах */

    );

    struct icmp_echo_reply {

    /* Структура ICMP-отклика */

    u_long Address;

    /* адрес отправителя */

    u_long Status;

    /* код IP-статуса */

    u_long RTTime;

    /* RTT в миллисекундах */

    u_short DataSize;

    /* длина пакета-отклика */

    u_short Reserved;

    /* зарезервировано на будущее */

    void FAR *Data;

    /* буфер отклика */

    struct ip_option_information Options;

    /* опции отклика */

    }; ICMPECHO, *PICMPECHO, FAR *LPICMPECHO;

    struct ip_option_information {

    /* Структура опций протокола ICMP */

    u_char TTL;

    /* Time To Live (используется процедурой traceroute) */

    u_char Tos;

    /* Type Of Service (тип сервиса; обычно 0) */

    u_char Flags;

    /* Флаги IP-заголовка (обычно 0) */

    u_char OptionsSize;

    /* Размер буфера опций (обычно 0, max=40) */

    u_char FAR *OptionsData;

    /* Буфер опций */

    } IPINFO, *PIPINFO, FAR *LPIPINFO;

    Приложение может использовать WSAEnumProtocols для определения того, какой транспортный протокол (стек протоколов) поддерживается, и попутно можно получить дополнительную информацию, которая содержится в структуре WSAPROTOCOL_INFO.

    В то время как в WinSock 1.1 имеется только одно семейство адресов AF_INET, включающее в себя ограниченное число известных типов соединителей и идентификаторов протоколов, в WinSock 2 это ограничение снято. Информация по WinSock 2 доступна по адресу:

    www.stardust.com/winsock/ws_specs.htm

    В настоящее время WinSock допускает совмещение по времени нескольких операций ввода/вывода. Такого рода операции возможны только для соединителей, созданных оператором WSASocket с флагом WSA_FLAG_OVERLAPPED=1 (Win32).

    Запросы получения и отправки информации возвращают отклик немедленно. Если получен нуль, это означает, что операция ввода/вывода завершилась успешно, если же получен флаг SOCKET_ERROR с кодом ошибки WSA_IO_PENDING, указывает на успешное начало операции, последующие сообщения позволят судить о дальнейшем выполнении операции.

    Допуская возможность нескольких операций ввода/вывода одновременно, нужно обеспечить соответствие между этими процессами и сообщениями об их завершении. В Winsock эта проблема решена с помощью введения объектов события (event objects), по аналогии с Win32. Эти объекты создаются, уничтожаются, устанавливаются в определенное состояние и т.д. Приложение может использовать оператор WSACreateEvent для создания дескриптора (указателя) объекта события, который передается в качестве обязательного параметра для совмещаемых во времени процедур посылки и получения данных (WSASend, WSASendTo, WSARecv, WSARecvFrom). Каждому оператору создания объекта WSACreateEvent должен соответствовать оператор WSACloseEvent, ликвидирующий его. Объекты события используются также оператором WSAEventSelect для того, чтобы связать FD_XXX сетевое события с объектами события.

    В 32-разрядной среде операторы для работы с объектами события WSACreateEvent, WSACloseEvent, WSAResetEvent, WSASetEvent, WSAGetOverlappedResult и WSAWaitForMultipleEvents строго соответствуют операторам Win32.

    Приложение может установить режим ожидания с блокировкой для одного или нескольких объектов события, используя оператор WSAWaitForMultipleEvents. Для этих целей можно применить и WaitForMultipleObjects. Если при ожидании предпочтительнее отсутствие блокировки, можно воспользоваться оператором WSAGetOverlappedResult, чтобы проконтролировать завершение заданного процесса.

    Операторы запуска совмещаемых по времени процессов ввода/вывода WSASend, WSASendTo, WSARecv, WSARecvFrom используют в качестве опционного указателя lpCompletionRoutine, который позволяет по завершении процесса обмена передать управление определенной приложением программе.

    В версии WinSock 2 введено понятие группы соединителей, которое позволяет приложению сообщить сервис провайдеру, что данный набор соединителей имеет определенные идентичные свойства (атрибуты). К числу этих свойств относятся относительные приоритеты отдельных соединителей в пределах группы, а также спецификация качества услуг (QOS).

    Приложения, реализующие мультимедийные потоки данных, нуждаются в организации специфических взаимоотношений между наборами соединителей. Как минимум это может включать подсказку сервис провайдеру о приоритетности потоков информации. Например, при проведении видеоконференций звуковое сопровождение должно иметь более высокий приоритет, чем видеоинформация. Кроме того, существуют сервис провайдеры, которые могут обеспечить запрашиваемое качество обслуживание (код QOS).

    WSASocket и WSAAccept представляют собой два новых оператора, используемых для создания соединителей и групп, а также для включения соединителя в определенную группу. Идентификатор группы соединителя можно узнать с помощью оператора getsockopt с опцией SO_GROUP_ID. Установка и проверка относительного приоритета соединителей в группе осуществляется соответственно операторами getsockopt и setsockopt с опцией SO_GROUP_PRIORITY. Опции соединителей приведены в таблице 7.8.

    Таблица 7.8. Опции соединителей

    Опция

    Тип

    Назначение

    Значение по умолчанию

    SO_GROUP_ID

    GROUP

    Идентификатор группы, к которой принадлежит соединитель.

    NULL

    SO_GROUP_PRIORITY

    int

    Относительный приоритет соединителей, принадлежащих к группе.

    0

    SO_MAX_MSG_SIZE

    int

    Максимальный размер сообщения для соединителей, ориентированных на сообщения. Не имеет смысла для соединителей типа stream.

    Зависит от реализации

    SO_PROTOCOL_INFO

    struct WSAPROTOCOL_INFO

    Описание протокольной информации.

    Зависит от протокола

    PVD_CONFIG

    char FAR *

    Информационная структура, содержащая данные о сервис провайдере.

    Зависит от реализации

    Сводная таблица кодов операций для процедуры ioctl приведена ниже (таблица 7.9). Оператор WSAIoctl поддерживает также все операции, специфицированные для процедуры iocltsocket.

    Таблица 7.9. Коды операций

    Код операции

    Input Type

    Output Type

    Значение

    SIO_ASSOCIATE_HANDLE

    зависит от API

    не использ.

    Связывает соединитель с заданным дескриптором интерфейса-партнера.

    SIO_ENABLE_CIRCULAR_QUEUEING

    не использ.

    не использ.

    Разрешает организацию кольцевой очереди.

    SIO_FIND_ROUTE

    struct sockaddr

    не использ.

    Запрос маршрута до заданного адреса.

    SIO_FLUSH

    не использ.

    не использ.

    Аннулирует текущее содержимое очереди на отправку.

    SIO_GET_BROADCAST_ADDRESS

    не использ.

    struct sockaddr

    Определяет протокольно-зависимый широковещательный адрес для использования в sendto/WSASendTo

    SIO_GET_QOS

    не использ.

    QOS

    Определяет текущую спецификацию соединителя.

    SIO_GET_GROUP_QOS

    не использ.

    QOS

    Определяет спецификацию группы, к которой принадлежит соединитель

    SIO_MULTIPOINT_LOOKBACK

    BOOL

    не использ.

    Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем локальной ЭВМ.

    SIO_MULTICAST_SCOPE

    int

    не использ.

    Определяет режим, в котором будут осуществляться мультикастинг-обмены.

    SIO_SET_QOS

    QOS

    не использ.

    Устанавливает новую спецификацию для соединителя.

    SIO_SET_GROUP_QOS

    QOS

    не использ.

    Устанавливает новую спецификацию группы, к которой принадлежит соединитель.

    SIO_TRANSLATE_HANDLE

    int

    зависит от API

    Возвращает дескриптор для соединителя s, который соответствует контексту интерфейса-партнера.

    Оператор WSAAccept устанавливает условное соединение и имеет следующую структуру параметров.

    WSAAccept (

    IN

    SOCKET

    s ,

    OUT

    struct sockaddr FAR

    addr,

    IN OUT

    LPINT

    addrlen,

    IN

    LPCONDITIONPROC

    lpfnCondition,

    IN

    DWORD

    dwCallbackData

    );

    s

    дескриптор соединителя, который находится в режиме listen.

    addr

    опционный указатель на буфер (структуру), где должен храниться адрес подключаемого объекта, формат адреса определяется типом протокола, заданным при создании соединителя.

    addrlen

    Опционный указатель на целую переменную, которая определяет длину аргумента addr.

    lpfnCondition

    Адрес опционной условной процедуры, которая на основе полученной информации, создает группу или подключает соединитель к уже существующей группе.

    dwCallbackData

    Параметр, возвращаемый приложению. Этот параметр не интерпретируется WinSock.

    IN и OUT указывают на то, является ли данный параметр входным или выходные.

    Программа извлекает очередную заявку на соединение из очереди соединителя s и проверяет с помощью специфицированной программы выполнение условий соединения. Если условия выполнены, возвращается флаг CF_ACCEPT, программа создает новый соединитель и осуществляет подключение его к группе в соответствии с параметром g, выработанным программой проверки условий. Вновь созданный соединитель имеет те же параметры, что и s, включая те, что задаются операторами контроля WSAAsyncSelect или WSAEventSelect. Если программа проверки условия вернула флаг CF_REJECT, запрос на соединение аннулируется. При невозможности принять решение немедленно, программа проверки условия должна вернуть флаг CF_DEFER, при этом никаких действий не предпринимается. Когда приложение будет готово обслужить запрос на соединение, оно снова запустит процедуру WSAAccept и пришлет либо CF_ACCEPT, либо CF_REJECT в качестве результата проверки условий.

    Для соединителей, которые остаются в блокирующем режиме, когда в очереди нет запросов на соединение, WSAAccept блокирует вызывающую программу до появления заявки на соединение. Для соединителей неблокирующего типа, когда очередь пуста, оператор WSAAccept вернет флаг ошибки.

    При завершении процедуры в addrlen будет записана реальная длина адреса в байтах. Если addr и (или) addrlen равны нулю, это означает, что нет никакой информации об адресе удаленного адресата. В противном случае эти параметры несут в себе реальную информацию не зависимо от результатов проверки условий. Прототип программы проверки условий имеет формат:

    int CALLBACK
    ConditionFunc(

    IN

    LPWSABUF

    lpCallerId ,

    IN

    LPWSABUF

    lpCallerData ,

    IN OUT

    LPQOS

    lpSQOS ,

    IN OUT

    LPQOS

    lpGQOS,

    IN

    LPWSABUF

    lpCalleeId ,

    OUT

    LPWSABUF

    lpCalleeData ,

    OUT

    GROUP FAR *

    g

    IN

    DWORD

    dwCallbackData

    );

    ConditionFunc представляет собой указатель имени программы, которая служит для проверки условий. В 16-битной версии Windows, эта программа выполняется в рамках той же сессии, что и WSAAccept, поэтому вызов каких-либо иных WinSock операторов кроме WSAIsBlocking и WSACancelBlockingCall не возможен. Программа проверки условий должна находиться в DLL или прикладном модуле. Для определения адреса программы проверки условий следует пользоваться оператором MakeProcInstance.

    Переменные lpCallerId и lpCallerData являются параметрами, которые содержат адрес партнера и любую пользовательскую информацию, которая была прислана вместе с запросом на соединение.

    lpSQOS представляет собой указатель на текущую спецификацию QOS соединителя s (по одной для каждого из концов виртуального канала), за которой следуют дополнительные параметры, заданные провайдером. Нулевое значение lpSQOS указывает на то, что вызывающая сторона не задала значения QOS.

    lpGQOS - указатель на спецификацию QOS группы соединителей, созданной запрашивающей стороной (для каждого из направлений обмена), за которой следуют дополнительные параметры, заданные провайдером.

    lpCalleeId представляет собой локальный адрес вызывающей стороны.

    lpCalleeData используется программой проверки условий для записи результатов ее работы.

    lpCalleeData первоначально содержит размер буфера, предназначенного для сервис провайдера. Положение буфера определяется указателем lpCalleeData->buf. Программа проверки условий должна скопировать lpCalleeData->len байт в lpCalleeData->buf, а затем провести актуализацию lpCalleeData->len, с тем чтобы сообщить действительное число переданных байтов.

    В таблице 7.10 представлен перечень кодов-сообщений об ошибках вместе с их эквивалентами для Berkley-соединителей.

    Таблица 7.10. Краткое описание сообщений об ошибках

    WinSock-код

    Berkeley-эквивалент

    Код ошибки

    Значение

    WSAEINTR

    EINTR

    10004

    Как в стандартном C

    WSAEBADF

    EBADF

    10009

    Как в стандартном C

    WSAEACCES

    EACCES

    10013

    Как в стандартном C

    WSAEFAULT

    EFAULT

    10014

    Как в стандартном C

    WSAEINVAL

    EINVAL

    10022

    Как в стандартном C

    WSAEMFILE

    EMFILE

    10024

    Как в стандартном C

    WSAEWOULDBLOCK

    EWOULDBLOCK

    10035

    Как в BSD

    WSAEINPROGRESS

    EINPROGRESS

    10036

    Эта ошибка возникает, если какая-либо процедура WinSock вызвана во время исполнения блокирующей операции.

    WSAEALREADY

    EALREADY

    10037

    Как в BSD

    WSAENOTSOCK

    ENOTSOCK

    10038

    Как в BSD

    WSAEDESTADDRREQ

    EDESTADDRREQ

    10039

    Как в BSD

    WSAEMSGSIZE

    EMSGSIZE

    10040

    Как в BSD

    WSAEPROTOTYPE

    EPROTOTYPE

    10041

    Как в BSD

    WSAENOPROTOOPT

    ENOPROTOOPT

    10042

    Как в BSD

    WSAEPROTONOSUPPORT

    EPROTONOSUPPORT

    10043

    Как в BSD

    WSAESOCKTNOSUPPORT

    ESOCKTNOSUPPORT

    10044

    Как в BSD

    WSAEOPNOTSUPP

    EOPNOTSUPP

    10045

    Как в BSD

    WSAEPFNOSUPPORT

    EPFNOSUPPORT

    10046

    Как в BSD

    WSAEAFNOSUPPORT

    EAFNOSUPPORT

    10047

    Как в BSD

    WSAEADDRINUSE

    EADDRINUSE

    10048

    Как в BSD

    WSAEADDRNOTAVAIL

    EADDRNOTAVAIL

    10049

    Как в BSD

    WSAENETDOWN

    ENETDOWN

    10050

    Как в BSD. Ошибка возникает в любое время, когда приложение WinSock обнаруживает ошибку на нижележащем уровне.

    WSAENETUNREACH

    ENETUNREACH

    10051

    Как в BSD

    WSAENETRESET

    ENETRESET

    10052

    Как в BSD

    WSAECONNABORTED

    ECONNABORTED

    10053

    Как в BSD

    WSAECONNRESET

    ECONNRESET

    10054

    Как в BSD

    WSAENOBUFS

    ENOBUFS

    10055

    Как в BSD

    WSAEISCONN

    EISCONN

    10056

    Как в BSD

    WSAENOTCONN

    ENOTCONN

    10057

    Как в BSD

    WSAESHUTDOWN

    ESHUTDOWN

    10058

    Как в BSD

    WSAETOOMANYREFS

    ETOOMANYREFS

    10059

    Как в BSD

    WSAETIMEDOUT

    ETIMEDOUT

    10060

    Как в BSD

    WSAECONNREFUSED

    ECONNREFUSED

    10061

    Как в BSD

    WSAELOOP

    ELOOP

    10062

    Как в BSD

    WSAENAMETOOLONG

    ENAMETOOLONG

    10063

    Как в BSD

    WSAEHOSTDOWN

    EHOSTDOWN

    10064

    Как в BSD

    WSAEHOSTUNREACH

    EHOSTUNREACH

    10065

    Как в BSD

    WSASYSNOTREADY

     

    10091

    Выдается WSAStartup, указывает, что сетевая субсистема использоваться не может.

    WSAVERNOTSUPPORTED

     

    10092

    Выдается WSAStartup, указывая на то, что WinSock DLL не может поддерживать это приложение.

    WSANOTINITIALISED

     

    10093

    Выдается любой процедурой кроме WSAStartup, указывая на то, что успешное исполнение WSAStartup не было осуществлено.

    WSAEDISCON

     

    10094

    Выдается recv, WSARecv, чтобы отметить начало разрыва связи удаленным партнером

    WSA_OPERATION_ABORTED

     

    TBD

    Совмещенные по времени процедуры прерваны из-за закрытия соединения, или выполнения команды SIO_FLUSH в WSAIoctl

    WSAHOST_NOT_FOUND

    HOST_NOT_FOUND

    11001

    Как в BSD

    WSATRY_AGAIN

    TRY_AGAIN

    11002

    Как в BSD

    WSANO_RECOVERY

    NO_RECOVERY

    11003

    Как в BSD

    WSANO_DATA

    NO_DATA

    11004

    Как в BSD

    • Современные версии WinSock обеспечивают протокольно-независимый доступ ко всем ресурсам сети, включая такие стандартные приложения, как DNS, SAP, X.500 и т.д.
    • Позволяют реализовать несколько сессий ввода/вывода одновременно.
    • Поддерживают любые стандартные уровни сервиса (QOS - Quality of service). Осуществляют объединение соединителей по группам в соответствии с их параметрами.
    • Допускается многопротокольная широковещательная или мультикастинг-адресация.
    • Предусматривается совместное использование соединителей несколькими процессами, условное создание соединителей и объединение их в группы.

    Введено понятие WOSA-интерфейса (Windows Open Service Architecture), который обеспечивает связь между прикладной программой и сетевыми процедурами ОС. Этот интерфейс заметно упрощает программирование при работе с пакетами.

    Каждая процедура, распознаваемая WOSA, имеет в свою очередь несколько интерфейсов, ориентированных на конкретных сервис-провайдеров. Применение этих средств реализуется через DLL.

    WinSock, следуя модели WOSA, обеспечивает прикладной интерфейс для сетевого программирования (API - Application Programming Interface), который организует доступ к транспортным услугам и серверу имен сервис-провайдера (SPI - Service Provider Interfaces). SPI ориентирован на использование в рамках 32-битовой модели Microsoft Windows, включая Windows NT и Windows 95.

    Транспортные сервис-провайдеры (например, TCP/IP или IPX/SPX) и именные серверы (DNS) в WinSock представляют собой динамические библиотеки (DLL) с одной точкой входа для процедур инициализации WSPStartup или NSPStartup (обратите внимание на то, что здесь под сервис-провайдером подразумевается система, способная предоставить определенный вид услуг). Все остальные процедуры сервис-провайдера сделаны доступными для WinSock DLL через диспетчерскую таблицу. Динамическая библиотека сервис-провайдера загружаются в память WinSock DLL только по мере необходимости и выгружаются, когда они более не нужны. Динамическая библиотека сервис-провайдера имеет обычно расширение .WSP или .NSP. Процедуры WinSock SPI имеют префиксы:

    WSP

    WinSock Service Provider

    для транспортных услуг сервис-провайдера;

    WPU

    WinSock Provider Upcall

    для входа в WinSock DLL сервис-провайдера;

    WSC

    WinSock Configuration

    для входа в WinSock DLL инсталляционных приложений;

    NSP

    Name Space Provider

    для работы с сервером имен.

    Сервис-провайдеры WinSock при работе со строками используют UNICODE. WinSock DLL выполняют необходимые преобразования при работе с приложениями, использующими ANSI или UNICODE.

    Конкретный сервис-провайдер может поддерживать один или более протоколов. Так TCP/IP-провайдер должен как минимум поддерживать TCP- и UDP-протоколы, в то время как IPX/SPX-провайдер - IPX, SPX и SPX II. Каждый поддерживаемый протокол описывается в структуре WSAPROTOCOL_INFO, а набор таких структур представляет собой каталог используемых протоколов (более детальную информацию по данной тематике можно найти по адресу: www.stardust.com/winsock/ws_specs.htm).

    Одной из главных задач WinSock DLL является выполнение функции регулировщика информационных потоков между приложениями и сервис-провайдерами. Каждый сервис-провайдер взаимодействует только с WinSock DLL. WinSock DLL заботится об объединении потоков событий от разных сервис-провайдеров и направлении их приложению. Эта библиотека берет на себя функции арбитража и синхронизации. Взаимоотношения между сервис-провайдерами (даже если они поддерживают разные протоколы) улаживаются также WinSock DLL.

    Работа WinSock DLL базируется на параметрах соединителей, которые задаются при формировании (socket и WSASocket), именно эта информация определяет, какой из сервис провайдеров будет задействован. Для выбора сервис провайдера используется процедура WSPSocket. В случае процедуры socket, WinSock DLL находит запись в структуре WSAPROTOCOL_INFO, которая соответствует входным параметрам (идентификатор стека протоколов, тип соединителя, протокол).

    Сервис-провайдеры используют сетевые протоколы низкого уровня. WinSock DLL осуществляет управление на среднем уровне, обеспечивая связь транспортных протоколов с приложениями.

    Транспортный SPI WinSock аналогичен WinSock API с точки зрения базовых процедур с соединителями. Так процедурам connect и WSAConnect ставится в соответствие WSPConnect; accept и WSAAccept - WSPAccept, а socket и WSASocket - WSPSocket.

    Так как WinSock DLL не поставляется теперь разработчиками стека протоколов, расширение функциональных возможностей представляет определенную проблему. Для преодоления этих трудностей новейшие версии WinSock используют процедуру WSAIoctl, чтобы помочь сервис-провайдерам на практике реализовать какие-либо функциональные новшества.

    Для введения расширенных возможностей приложение должно запросить указатель на точку входа в соответствующую программу. Это делается с помощью процедуры WSAIoctl, используя команду SIO_GET_EXTENSION_FUNCTION_POINTER. При этом входной буфер процедуры WSAIoctl содержит идентификатор запрашиваемой функции, в выходной буфер будет занесен указатель на нужную программу.

    Идентификаторы, присвоенные новым функциям, должны быть уникальными глобальными идентификаторами (GUID - Global Unique IDentifiers), которые присваиваются им поставщиками сервис-провайдеров.

    Для того чтобы транспортный протокол стал доступен через WinSock, он должен быть правильно инсталлирован и зарегистрирован в WinSock. Когда транспортный сервис-провайдер инсталлирован с помощью программы поставщика, соответствующая информация должна быть введена в конфигурационную базу данных, чтобы дать WinSock DLL необходимые данные для взаимодействия с сервис-провайдером.

    В WinSock DLL содержится процедура WSCInstallProvider для инсталляции программ поставщиков и процедура выгрузки этих программ WSCDeinstallProvider.

    Структура WSAPROTOCOL_INFO поставляется для каждого протокола и указывает на то, является ли этот протокол базовым, слоевым или стеком. Величина поля ProtocolChain.ChainLen интерпретируется как:

    0

    протокол слоя

    1

    базовый протокол (или стек, если стек состоит из одного протокола)

    >1

    стек протоколов.

    Инсталляция стека протоколов возможна лишь после загрузки всех составных частей (слоевых и базовых протоколов). Структура WSAPROTOCOL_INFO для стека протоколов использует поле ProtocolChain для описания длины стека и идентификации каждой из составных частей. Отдельные протоколы, входящие в стек последовательно перечислены в массиве ProtocolChain.ChainEntries, нулевой элемент списка соответствует первому протоколу слоя.

    SDK (System Development Kit) для WinSock включает в себя инструментальную WinSock и отладочную DLL.

    При разработке протокольно-независимых приложений для систем клиент-сервер нужно зарегистрировать имя сервера в банке имен, только это может сделать его доступным извне. Программа-клиент может функционировать лишь при условии, если она способна найти необходимую ей процедуру в поле имен и получить доступ к соответствующему транспортному протоколу и адресной информации. Для тех кто работает с протоколами TCP/IP это может в начале вызвать определенные трудности, которые компенсируются возможностями создания программ, пригодных для широкого класса самых разнообразных протоколов (например, Novell). Под работой с полем имен здесь подразумевается возможность установления соответствия между протоколом и адресным атрибутом сетевой услуги, которой присвоено какое-то имя. Примерами таких полей имен могут служить уже используемые системы DNS (Domain Name System), NDS (Netware Directory Services), X.500 и др. Поля имен могут быть динамическими, статическими и постоянными.

    Динамические поля имен служат для краткосрочной регистрации сетевой услуги. Часто они базируются на широковещательной системе определения доступности той или иной услуги. Примерами таких систем являются SAP в среде Netware и NBP в среде Appletalk.

    Статические поля имен формируются при первоначальном создании сервера имен и в дальнейшем могут изменяться лишь администратором сети. Традиционная система DNS относится именно к этой разновидности. Программа может воспользоваться таким банком имен, но не может произвести туда запись.

    Постоянное поле имен сходно с динамическим - запись туда происходит в реальном масштабе времени, но после регистрации имя записывается в постоянную память и остается там до тех пор, пока не придет запрос на ликвидацию этой записи. Примерами такой системы могут служить X.500 и NDS.

    Некоторые поля имен организованы иерархически, X.500 и NDS, например, позволяют неограниченное число уровней вложения. Программные интерфейсы, предназначенные для посылки запросов в именные базы данных, сильно варьируются в зависимости от разновидности используемого поля имен. Сервер имен представляет собой резидентную программу, которая обеспечивает интерфейс между WinSock SPI и некоторой существующей базой данных имен.

    Используемые услуги в WinSock группируются в классы услуг и в пределах класса имя услуги должно быть уникально. Примерами классов услуг могут служить FTP и SQL. Каждому классу присваивается имя и идентификатор (ID). Имя класса может не быть уникальным, но идентификатор обязан быть неповторимым. В качестве идентификаторов классов услуг в Winsock используются GUID (Globally Unique Identifiers). Для генерации GUID имеется специальная программа (UUIDGEN.EXE), которой может воспользоваться разработчик новых классов услуг.

    DNS в Internet не имеет развитой системы для записи информации о классах услуг. Для TCP/IP-класса услуг GUID присвоен раз и навсегда.

    WinSock DLL может маршрутизовать прикладные операции в пространстве имен и переадресовывать их соответствующим серверам имен.

    Процедуры установки классов услуг, регистрации и обслуживания запросов осуществляются непосредственно через интерфейс API - SPI. Процедура WSAGetServiceClassNameByServiceClassId не имеет аналога среди операторов SPI, так как эта процедура WinSock DLL осуществляет обращение к NSPGetServiceClassInfo.

    Переключение сервера имен из активного состояния в пассивное и обратно осуществляется с помощью процедуры WSCEnableNSProvider. В активном состоянии могут находиться несколько серверов имен одновременно. Инициализация сервис провайдеров выполняется с помощью процедуры WSPStartup (см. аналогично WSAStartup). Каждой процедуре WSPStartup должна соответствовать процедура WSPCleanup.

    Процедура WSPSocket имеет параметр flags, который позволяет контролировать атрибуты соединителя. Флаг WSA_FLAG_OVERLAPPED указывает на то, что данный соединитель будет использоваться в режиме совмещения процессов ввода/вывода.

    Существуют атрибуты, ответственные за использование соединителя для работы в многоточечном и/или мультикастинг режимах. Только соединители, созданные для работы в многоточечном режиме, пригодны для запуска многоточечных сессий с помощью WSPJoinLeaf.

    Соединитель, созданный для работы в блокирующем режиме, может быть преобразован в неблокирующий с помощью процедур WSPAsyncSelect, WSPEventSelect или WSPIoctl. Перевод соединителя в блокирующий режим производится посредством процедур WSPIoctl, если WSPAsyncSelect неактивен, или WSPEventSelect, если активен.

    Процедура WSPCloseSocket ликвидирует дескриптор соединителя и все процессы, использующие этот соединитель, будут прерваны.

    Понятие блокировки для среды Windows было фундаментальным. В WinSock 1.1, блокирующие процедуры WinSock были проблемой, так как они парализовали взаимодействие приложения и надстройки Windows, а применение псевдо-блокирующей техники не всегда давало удовлетворительный эффект. В ОС типа Windows 95 или Windows NT блокирующие процедуры уже не могут вызвать каких-либо проблем, более того, они уже представляются привлекательными. Интерфейс WinSock 2 API уже не поддерживает более псевдоблокировку, но для обеспечения совместимости с WinSock 1.1 он эмулирует этот механизм.

    В среде Win16, где настоящее блокирование не поддерживается ОС, блокирующие процедуры, которые не могут быть закончены немедленно, обслуживаются с использованием псевдоблокировки. Сервис-провайдер инициализирует процедуру, после чего входит в цикл, внутри которого осуществляет доставку любых сообщений Windows и проверяет завершение процедуры. Если процедура завершилась, или если вызван оператор WSPCancelBlockingCall, происходит выход из цикла, а блокирующая процедура завершается с соответствующим результатом.

    Эта схема вполне приемлема для простых приложений. Но она неприемлема для приложений, где должны реализоваться сложные схемы доставки сообщений, например, для модели MDI (Multiple Document Interface). Для таких приложений псевдоблокировка должна быть реализована в самом приложении. Сервис-провайдер в этом случае должен вызывать именно этот цикл. Для этого он должен получить указатель на него, обратившись к WPUQueryBlockingCallback.

    Сервис-провайдер WinSock не может исходить из предположения, что псевдоблокировка, используемая приложением, обеспечит обработку сообщений. Если приложение не приспособлено для решения таких задач, оно откликнется флагом FALSE. Если сервис-провайдер требует обработки сообщений для своих внутренних нужд, он может вызвать процедуру PeekMessage до передачи управления циклу псевдоблокировки в приложении.

    Сервис-провайдер WinSock использует псевдоблокировку лишь при выполнении определенных условий:

    1. Программа определена как блокирующая,
    2. Соответствующий соединитель работает в блокирующем режиме,
    3. Запрос не может быть выполнен немедленно.

    Если условия не выполнены, уход в цикл псевдоблокировки осуществлен не будет.

    Если во время цикла псевдоблокировки получено сообщение Windows, существует опасность того, что будет предпринята попытка вызова еще одной процедуры WinSock. Из-за трудностей управления этим процессом WinSock 1.1 запрещает такие вызовы. Любая попытка осуществить вложенный вызов процедур WinSock вызовет ошибку WSAEINPROGRESS. Для WinSock 1.1 это ограничение справедливо как для блокирующих, так и для неблокирующих процедур. Имеется два исключения из этого правила. Это процедура, которая позволяет приложению проверить, находится ли система в цикле псевдоблокировки (WSAIsBlocking), и процедура ухода из этого цикла (WSPCancelBlockingCall).

    WinSock 2 DLL имеет средства для формирования объектов событий, как для приложения, так и для сервис-провайдера, хотя на практике объекты событий создаются в основном приложениями. Для формирования объектов событий в WinSock имеется оператор WPUCreateEvent. Дескриптор объекта события имеет смысл лишь в контексте программы, его сформировавшей. В среде Win32 работа с объектами событий выполняется самой операционной системой.

    Объекты событий в WinSock представляют собой простые конструкции, которые могут создаваться и уничтожаться, они могут устанавливаться и сбрасываться. Клиент создает объект события и передает его дескриптор в качестве параметра таким процедурам как WSPSend и WSPEventSelect. Когда оговоренные условия выполнены, сервис-провайдер использует дескриптор для того, чтобы установить объект события с помощью оператора WPUSetEvent. При этом клиент WinSock SPI может находиться в состоянии блокировки-ожидания или в режиме запроса, ожидая, когда объект события будет установлен. Клиент может сбросить объект события в нуль, снова его установить и использовать снова.

    Субъект (приложение или сервис-провайдер), создавший объект события, ответственен и за его ликвидацию. Сервис-провайдер может это сделать с помощью WPUCloseEvent.

    Одной из главных задач сервис-провайдера является сообщение приложению о том, что произошло соответствующее сетевое событие. Список сетевых событий включает в себя:

    FD_CONNECT

    Канал до удаленной ЭВМ или для мультикастинг-сессии сформирован

    FD_ACCEPT

    Удаленная ЭВМ выставила запрос на соединение;

    FD_READ

    Получены данные и их можно считать;

    FD_WRITE

    В буферах сервис-провайдера появилось свободное место и можно послать очередную порцию информации;

    FD_OOB

    Для чтения доступна высокоприоритетная информация;

    FD_CLOSE

    Удаленная ЭВМ закрывает канал;

    FD_QOS

    Произошло изменение оговоренного значения QOS (качества услуг);

    FD_GROOUP_QOS

    Произошло изменение оговоренного значения QOS для данной группы соединителей.

    Стандартный BSD-интерфейс соединителей имеет только одно средство получить информацию о сетевых событиях - оператор select. Этот метод не может дать информацию о событиях FD_QOS и FD_GROUP_QOS.

    В Windows Sockets 1.1 используется асинхронный механизм получения информации о сетевых событиях. Для регистрации интересующих событий можно использовать процедуру WSPAsyncSelect. Когда нужное сетевое событие произойдет, соответствующему окну будет послано сообщение, заданное клиентом. Сервис-провайдер использует для тех же целей процедуру WPUPostMessage. В среде Win32 этот метод получения данных о событиях нельзя считать эффективным.

    WSPEventSelect ведет себя практически также как WSPAsyncSelect за исключением того, что вместо посылки сообщения Windows при сетевом событии типа FD_XXX, устанавливается соответствующий объект события.

    Факт прихода сетевого события FD_XXX сервис-провайдером запоминается. Вызов процедуры WSPEnumNetworkEvents вызывает копирование текущего содержимого памяти сетевых событий в буфер клиента, а основная память событий очищается.

    Сервис-провайдеры (ISDN или ATM) могут использовать групповые значения QOS при формировании виртуального канала и повышения эффективности своей работы. Пакеты для соединителей в пределах группы мультиплексируются обычным образом.

    Операторы WSPSocket и WSPAccept предназначены для формирования соединителей и подключения новых соединителей, к той или иной группе. Однажды включенный в группу соединитель остается в ней до своего закрытия. Группа прекращает свое существование, лишь когда последний соединитель группы будет закрыт. Идентификатор группы соединителей может быть получен с помощью оператора WSPGetSockOpt с опцией SO_GROUP_ID. Узнать об относительном приоритете соединителя в группе можно, воспользовавшись процедурой WSPGet/SetSockOpt с опцией SO_GROUP_PRIORITY.

    Групповое значение QOS можно задать при выполнении WSPConnect, или WSPIoctl с SIO_SET_GROUP_QOS, если специфицированный соединитель является "учредителем" группы. Оператор WSPIoctl с SIO_GET_GROUP_QOS может использоваться для получения группового значения QOS заданного соединителя.

    Для провайдеров, поддерживающих группирование соединителей, минимально необходимы следующие функции:

    1. Создание новых групп и присвоение им уникальных идентификаторов.
    2. Возможность включения соединителя в одну из существующих групп.
    3. Учет провайдером значения QOS порождающего соединителя при формировании списка параметров нового соединителя, включаемого в группу.

    Существуют группы двух видов. Одни включают в себя соединители, ориентированные на соединение, они могут быть подключены только к определенному адресу ЭВМ, остальные группы относятся к другому виду. Провайдер не может включить в группу соединитель, который не удовлетворяет этому условию. Провайдер не может также выполнить соединение, если адресат не соответствует адресу места назначения группы соединителей. Групповой адрес места назначения определяется, когда выполняется процедура connect для первого из соединителей группы.

    Единственный индивидуальный параметр соединителя в группе - его внутренний уровень приоритета. Провайдер должен уметь считывать значение приоритета, но он может полностью игнорировать этот параметр. В настоящее время не существует каких-либо механизмов для сопоставления приоритетов соединителей, принадлежащих к разным группам, или соединителей вне групп. Поддержка провайдеров групп не означает непременную поддержку различного качества услуг (QOS, см. RFC-1363).

    Поддержание работы с приоритетами соединителей в пределах группы является рекомендательным требованием. Схема приоритетов WinSock 2 имеет смысл лишь для мультиплексирования данных при соединении точка-точка, например, в случае телефонной связи или любых других вариантах, реализующих коммутацию каналов.

    Характер информационного обмена описывается спецификацией потока (flow specs), для каждого соединителя используется две такие спецификации, по одной для каждого из направлений обмена. Запрос на соединение реализуется через процедуры WSPConnect или WSPIoctl с кодом команды SIO_SET_QOS/SIO_SET_GROUP_QOS. Спецификация потока параметрически задает уровень сервиса (QOS) и определяет механизм адаптации приложения к сетевым условиям.

    В WinSock 2 спецификация потока содержит следующие характеристики QOS:

    1. Описание источника информационного потока, которое характеризует способ, используемый приложением, для введения потока данных в сеть. Эта спецификация выполняется в терминах модели пакетов символов (token bucket) и включает частоту символов, их размер, частоту пакетов символов и их размер, а также максимальное значение информационного потока.
    2. Задержка (latency) - приемлемые верхние пределы задержки и ее вариации.
    3. Гарантированный уровень обслуживания. Предполагается, что провайдер, который не способен обеспечить требуемый уровень сервиса (QOS), не сможет быть подключен.
    4. Цена (параметр зарезервирован на будущее).
    5. Параметры, специфические для провайдера (спецификация потока может быть расширена, чтобы имелась возможность описать некоторые особенности провайдера).

    Для протоколов, ориентированных на соединение более удобно для приложения оговаривать QOS при формировании соединения. Это делается путем запроса WSPConnect, направленного сервис-провайдеру. Если QOS было задано с помощью WSPIoctl, его значение может быть переписано при выполнении процедуры WSPConnect.

    Бессвязные соединители могут также использовать WSPConnect с целью установления определенного уровня QOS для канала связи с партнером

    После каждой попытки установить связь провайдер производит коррекцию спецификации потока для того, чтобы наилучшим образом отразить реальную ситуацию в сети. Предполагается, что клиенты могут использовать текущую сетевую информацию для того, чтобы оптимально реализовать возможности сети.

    Но после того как информация о состоянии сети получена, условия могут измениться, партнеры могут согласовать другой уровень QOS, так что приложение должно быть готово ко всему. Для информирования клиента о возможных изменениях условий в Winsock используется механизм сетевых событий (FD_QOS и FD_GROUP_QOS). Сервис-провайдер должен генерировать события типа FD_QOS/FD_GROUP_QOS, если уровень сервиса изменился значительно. Клиент должен использовать WSPIoctl с кодами команд SIO_GET_QOS и/или SIO_GET_GROUP_QOS, чтобы получить соответствующую спецификацию потока и выяснить, изменился ли уровень сервиса (QOS). Структура QOS должна актуализоваться вне зависимости от типа события FD_QOS/FD_GROUP_QOS. Если новый уровень сервиса неприемлем, клиент может попытаться приспособиться к новым условиям или закрыть соединение. При повторной попытке согласовать уровень QOS успешный выход из процедуры WSPIoctl указывает, что новое значение QOS приемлемо. Структура QOS в WinSock 2 описана в файле Winsock2.h и представлена ниже.

    typedef enum
    {
    BestEffortService,
    ControlledLoadService,
    PredictiveService,
    GuaranteedService
    } GUARANTEE;
    typedef struct _flowspec
    {

    int32

    TokenRate;

    /* В байтах/сек */

    int32

    TokenBucketSize;

    /* В байтах */

    int32

    PeakBandwidth;

    /* В байтах/сек */

    int32

    Latency;

    /* В микросекундах */

    int32

    DelayVariation;

    /* В микросекундах */

    GUARANTEE LevelOfGuarantee;

    int32

    CostOfCall;

    /* Зарезервировано для будущего использования, должно быть = 0 */

    int32

    NetworkAvailability

    /* только для чтения:
    1, если есть доступ,
    0, если нет */

    } FLOWSPEC, FAR * LPFLOWSPEC;
    typedef struct _QualityOfService
    {

    FLOWSPEC

    SendingFlowspec;

    /* Спецификация потока для данных */

     

     

    /* Посылка */

    FLOWSPEC

    ReceivingFlowspec;

    /* Спецификация потока для данных */

     

     

    /* Прием */

    WSABUF

    ProviderSpecific;

    /* Дополнительный провайдер */

     

     

    /* Специфические параметры */

    } QOS, FAR * LPQOS;

    Определения:

    LevelOfGuarantee

    Согласуемый уровень сервиса. Определены четыре уровня: гарантированный, предсказуемый, контролируемая загрузка и лучшее, что возможно. Предсказуемый уровень сервиса может дать наилучший результат при использовании определенного ресурса сети, в то время как гарантированный уровень соответствует необходимому уровню услуг конкретного приложения. Провайдеры могут предоставлять один, оба или ни одного их этих двух видов услуг.

    GuaranteedService

    Провайдер, поддерживающий гарантированный уровень сервиса, использует алгоритм очередей, в котором поток изолируется от влияния других потоков, и гарантирует, на сколько возможно, пропускную способность. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать "лишнюю" часть потока. Если поток находится в пределах допустимого, то гарантируется и задержка отклика. Этот вид сервиса предусмотрен для приложений реального времени.

    PredictiveService

    Провайдер, поддерживающий предсказуемый уровень сервиса, гарантирует пропускную способность, по крайней мере равную TokenRate, на время соединения. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать "лишнюю" часть потока. Значение задержки не гарантируется. Этот вид сервиса предназначен для приложений, способных адаптироваться к вариациям качества услуг, например, передача видео изображения.

    ControlledLoadService

    Этот уровень сервиса предполагает, что система сетевых устройств, которыми пользуется приложение, обеспечит условия работы, близкие к тем, которые достижимы при незагруженных каналах, для используемой транспортной среды. Приложения, использующие этот уровень сервиса, могут ожидать что:
    1. Большая часть передаваемых пакетов будет успешно доставлена (процент потерь определяется частотой ошибок транспортной среды).
    2. Задержка доставки не будет заметно превышать минимальное время распространения сигнала в используемой транспортной среде.

    BestEffortService

    Провайдеры, поддерживающие уровень сервиса "лучшее что возможно", рассматривают спецификацию потока, как руководство к действию. И пытаются сделать все возможное, чтобы поддержать запрашиваемый уровень сервиса (без каких-либо твердых гарантий).

    TokenRate/TokenBucketSize

    Модель "блоков символов" (Token bucket model) используется для задания верхнего предела скорости обмена. Величина value -1 в этом случае означает, что не существует никаких ограничений на скорость обмена. Значение TokenRate (частота символов) выражается в байтах в сек, а TokenBucketSize в байтах. Блок имеет определенный объем (TokenBucketSize), который заполняется с определенной скоростью (TokenRate). Если в блоке достаточно места, приложение может посылать данные, что приводит к уменьшению свободного места. Если же свободного места нет, приложение должно прервать обмен и ждать. Если приложение в течение определенного времени слало данные со скоростью меньше чем TokenRate, оно может затем на некоторое время превысить эту скорость.

    PeakBandwidth

    Значение этого поля (выражается в байтах в сек) ограничивает максимальную скорость пересылки пакетов приложением. Промежуточные системы могут использовать эту величину для оптимизации использования имеющихся ресурсов.

    Latency

    Характеризует максимально приемлемую задержку между посылкой бита отправителем и его получением адресатом (в миллисекундах).

    DelayVariation

    Значение этого поля в миллисекундах характеризует разницу между максимальной и минимальной задержкой доставки пакетов. Этот параметр используется приложением для расчета объема входного буфера.

    CostOfCall

    Зарезервировано на будущее и должно равняться нулю.

    NetworkAvailability

    Это поле, доступное провайдерам только в режиме чтения, используется для сообщения приложению о доступности транспортной среды (например, знакомая многим ситуация потери спутника антенной).

    Приложения, которые не склонны иметь дело с QOS-структурой непосредственно, могут воспользоваться именами известных видов сервиса и получить нужные данные с помощью запроса WSPGetQOSByName.

    Прежде чем использовать соединитель, надо связать его с локальным адресом. Это выполняется с помощью процедуры WSPBind, или WSPConnect.

    Сервер сначала создает соединитель, связывает его с известным локальным адресом (что позволяет клиенту найти его) и переводит соединитель в режим ожидания посредством WSPListen, готовя его к приему запросов на соединение. Одновременно система подготавливает структуру для формирования очереди запросов. Сервис-провайдер заносит поступающие запросы в очередь, где они ожидают обработки. Запросы могут быть удалены клиентом из очереди по таймауту.

    Если использован соединитель блокирующего типа, сервер может немедленно вызвать процедуру WSPAccept, которая вызовет блокировку на время ожидания запроса на соединение. В качестве альтернативы сервер может использовать один из механизмов обработки сетевых событий, описанный ранее. В зависимости от выбранного механизма провайдер или пошлет сообщение Windows или даст знать о приходе запроса на соединение через объект события.

    Клиент со своей стороны создаст соответствующий соединитель, запустит процедуру подключения и пошлет запрос WSPConnect, указав известный адрес сервера. Если соединитель является блокирующим, WSPConnect вызовет блокировку до тех пор пока сервер не получит и не обработает запрос на соединение или пока не произойдет таймаут. Клиент должен использовать механизм сетевых событий для отслеживания процесса соединения.

    Когда сервер запускает процедуру WSPAccept, сервис-провайдер инициализирует программу проверки условий, поставляемую приложением. В качестве параметров обращения используется информация, полученная вместе с запросом на соединение (берется из очереди запросов). Эта информация включат в себя адрес подключаемой ЭВМ, данные о пользователе и характеристику QOS, если таковая имеется. На основе полученной информации сервер определяет, принять данный запрос или нет.

    Если сервер принял запрос, он должен сформировать новый соединитель с теми же атрибутами что и соединитель ожидавший прихода запроса. Исходный соединитель остается в режиме ожидания последующих запросов.

    Для получения локального адреса сопряженными соединителями используется запрос WSPGetSockName. Это особенно полезно, когда послан запрос WSPConnect без предварительного вызова процедуры WSPBind.

    Как было сказано ранее, процедура WSPAccept позволяет воспользоваться поставляемой клиентом программой проверки условий, которая осуществляет условную обработку запросов на соединения, ожидающие обслуживания. Принятие решения осуществляется на основе информации, поступающей вместе с запросом (идентификатор источника запроса, QOS и т.д.). Если программа проверки условий возвращает флаг CF_ACCEPT, формируется новый соединитель с теми же свойствами, что и исходный. Если программа проверки вернет флаг CF_REJECT, запрос на соединение будет отвергнут. При возвращении флага CF_DEFER принятие решения откладывается, а запрос на соединение остается в очереди. Клиент должен будет осуществить вызов WSPAccept еще раз.

    Некоторые протоколы позволяют переслать информацию в процессе установления связи. Если такая информация получена, она помещается в буфер провайдера, а WinSock SPI получает указатель на этот буфер и длину записи. Если клиент WinSock SPI желает послать некоторую информацию в ответ, он может скопировать ее в буфер, предоставляемый сервис-провайдером.

    Разрыв соединения может быть выполнен несколькими способами. Для инициализации прерывания связи можно, например, применить процедуру WSPShutdown (с параметром how равным SD_SEND или SD_BOTH), и WSPSendDisconnect. Процедура WSPCloseSocket может быть применена и для аварийного прерывания соединения.

    Сервис провайдер сообщает о разрыве соединения по инициативе удаленного партнера с помощью сетевого события FD_CLOSE. При реализации процедуры разрыва соединения возможен обмен определенной информацией, если это предусмотрено используемым протоколом.

    Инициатор разрыва связи может вызвать WSPSendDisconnect, чтобы сообщить, что данных больше посылаться не будет и можно ликвидировать соединение. При этом может быть послана некоторая служебная информация, предусмотренная протоколом обмена. Для чтения этой информации партнер может воспользоваться оператором WSPRecvDisconnect. По завершении этого обмена обе стороны вызывают процедуры WSPCloseSocket.

    Следует различать процедуры прерывания (shutdown) связи и ее разрыва (close). Прерывание связи сопряжено с определенным диалогом между партнерами, после чего связь "замораживается", но дескриптор связи сохраняется. Существует два типа прерывания связи: аварийное (аппаратное) и нормальное. При нормальном прерывании любые данные, которые стояли в очереди, пересылаются до завершения процесса прерывания. При аварийном же прерывании непосланная информация теряется.

    В Windows Sockets, как процедура WSPShutdown, так и WSPSendDisconnect могут использоваться для инициализации прерывания связи. В то время как запрос WSPCloseSocket служит для ликвидации дескрипторов соединителей и освобождения связанных с ними ресурсов.

    Путем установки определенных значений для опций соединителей SO_LINGER и SO_DONTLINGER можно получит следующие варианты реализации процедуры WSPCloseSocket.

    • Процедура аварийного прерывания соединения, которая возвращается из WSPCloseSocket немедленно.
    • Нормальное прерывание соединения (graceful shutdown); задержка исполнения до завершения исполнения процедуры или до истечения заданного времени. Если таймаут наступает до завершения процедуры прерывания соединения, запускается процесс аварийного разрыва соединения.
    • Нормальное прерывание соединения с немедленным возвратом и завершением процедуры прерывания в фоновом режиме. Этот алгоритм реализуется по умолчанию. Приложение при этом не знает, когда и как завершается процесс прерывания соединения.

    Для соединителей, соответствующих протоколам неориентированных на соединение, работа, выполняемая оператором WSPConnect, связана главным образом с установлением адреса места назначения по умолчанию, что позволит в дальнейшем использовать соединитель в операциях обмена, ориентированных на соединение (WSPSend and WSPRecv). Любые дейтограммы, полученные от отправителя с адресом, отличным от специфицированного, будут проигнорированы.

    Место назначения по умолчанию может быть изменено с помощью повторного вызова WSPConnect. Любая дейтограмма из входной очереди будет отброшена, если новый адрес отличается от адреса, заданного в предыдущем WSPConnect.

    Если новый адрес равен нулю, соединитель будет отсоединен, так как удаленный адрес не определен, в результате операторы WSPSend и WSPRecv возвратят флаг ошибки WSAENOTCONN, в то же время WSPSendTo и WSPRecvFrom могут использоваться по-прежнему. Существует три базовых способа выполнения операций ввода/вывода:

    1. Блокирующий ввод/вывод,
    2. Неблокирующий ввод/вывод с асинхронными сетевыми событиями,
    3. Совмещенный ввод/вывод.

    Первый вариант является режимом по умолчанию, неблокирующий вариант может использоваться на любом соединителе, который поставлен в соответствующий режим. Третья разновидность обмена реализуется только на соединителях, которые при формировании были объявлены совмещенными. Процедуры посылки WSPSend и WSPSendTo и приема WSPRecv и WSPRecvFrom реализуют все три указанных режима обмена. Сервис-провайдеры определяют метод обмена на основе режима работы соединителя, атрибутов и входных параметров.

    Простейшим режимом обмена в WinSock 2 является блокирующий ввод/вывод. Этот режим устанавливается по умолчанию. Любая операция ввода/вывода на блокирующем соединителе вернет управление системе только по завершении процедуры. Таким образом, в ходе любой сессии может выполняться только одна операция ввода/вывода. Это простой режим, но отнюдь не самый эффективный.

    Если соединитель находится в неблокирующем состоянии, любая операция обмена должна либо завершаться немедленно, либо возвращать флаг ошибки WSAEWOULDBLOCK, указывая, что операция не может быть завершена корректно. Необходим механизм для определения, когда следует попытаться выполнить операцию еще раз. Для решения этой проблемы определен список сетевых событий, наступление которых может контролироваться с помощью процедур WSPSelect, WSPAsyncSelect или WSPEventSelect.

    В WinSock 2 впервые разрешено совмещение нескольких процедур ввода/вывода и потребована поддержка этого режима всеми сервис-провайдерами. Этот режим возможен только для соединителей, сформированных с помощью WSPSocket с флагом WSA_FLAG_OVERLAPPED.

    Для приема данных клиент может воспользоваться процедурами WSPRecv или WSPRecvFrom, чтобы указать буферы, куда будут записываться данные. Если один или более буферов подготовлены приложением до начала обмена, информация будет заноситься непосредственно в буферы пользователя и многоступенчатое копирование будет исключено. Если буферов заранее приложением не подготовлено, информация заносится сервис-провайдером во внутренний буфер и система ждет запроса, чтобы перенести данные в буфер приложения. Исключением из этого правила является случай, когда приложение использует WSPSetSockOpt для установления нулевого размера входного буфера. В этом варианте данные принимаются лишь при наличии указателей на буфер приложения. При посылке информации клиенты для выдачи указателей на буфер данных используют WSPSend или WSPSendTo.

    В совмещенном режиме процедуры посылки и получения данных завершаются немедленно. Полученный по возврату нуль, указывает на то, что процедура завершилась успешно. То есть, сформирован соответствующий объект события или программа завершения установлена в очередь с помощью WPUQueueApc. Возврат флага SOCKET_ERROR, сопряженного с кодом ошибки WSA_IO_PENDING, указывает, что совмещенная операция успешно начата и будет позднее сообщено, когда выходной буфер будет свободен или входной буфер будет заполнен. Любые другие коды ошибок говорят о сбое.

    Совмещаться могут как операции ввода, так и вывода. Следует иметь в виду, что если было послано несколько блоков данных друг за другом, сообщения о завершении операций по их пересылке могут прийти в другом порядке. Тоже может произойти и при приеме данных.

    Сервис-провайдеры имеют два способа сообщать о завершении совмещенных по времени операций: установка объекта события, заданного программой-клиентом, или запуск заданной клиентом программы завершения. В обоих случаях каждой из совмещенных операций ставится в соответствие структура WSAOVERLAPPED. Память для размещения этой структуры выделяется клиентом и используется им для указания того, какой из объектов следует установить при завершении процесса обмена. Структура WSAOVERLAPPED может использоваться сервис-провайдером для хранения дескриптора соответствующей совмещенной процедуры. Для извлечения нужной информации из указанной структуры можно воспользоваться оператором WSPGetOverlappedResult.

    Если параметр lpCompletionRoutine совмещенной операции не равен нулю, то сервис-провайдер может вызвать программу завершения, специфицированную клиентом. WinSock DLL предлагает асинхронную процедуру вызова (APC) программ завершения обмена.

    Для реализации той или иной функции в рамках сессии сервис-провайдер вызывает сначала процедуру WPUQueueApc. Сервис-провайдер должен позаботиться о том, чтобы процесс, соответствующий выбранному контексту, был активным до вызова функции WPUQueueApc.

    WPUQueueApc берет в качестве входных параметров указатель на структуру WSATHREADID, указатель на процедуру APC и 32-разрядный контекстный код. Сервис-провайдеры всегда получают указатель на соответствующую структуру WSATHREADID через параметр lpThreadId. Провайдер должен запомнить структуру WSATHREADID и выдать указатель на ее копию в качестве параметра оператора WPUQueueApc.

    Так как механизм APC работает только с одним 32-разрядным контекстным кодом, процедура APC не может быть сама программой завершения, заданной клиентом. Сервис-провайдер должен выдать указатель на свою собственную процедуру APC, которая, используя контекстный код, обеспечивает доступ к необходимой информации для совмещенной операции обмена и вызывает заданную клиентом программу завершения.

    Сервис-провайдер должен позволить клиентам WinSock 2 вызов процедур чтения или записи во время выполнения процедуры завершения обмена и гарантировать, что для данного соединителя не будет допущено вложение операций завершения.

    Структура WSAOVERLAPPED создает коммуникационную среду между запуском совмещенной операции обмена и последующим ее завершением. Структура WSAOVERLAPPED совместима со структурой OVERLAPPED для Win32:

    typedef struct _WSAOVERLAPPED {

    DWORD

    Internal;

    // Зарезервировано

    DWORD

    InternalHigh;

    // Зарезервировано

    DWORD

    Offset;

    // Зарезервировано

    DWORD

    OffsetHigh;

    // Зарезервировано

    WSAEVENT

    hEvent;

     

    } WSAOVERLAPPED, LPWSAOVERLAPPED;

    Internal и InternalHigh

    Резервное поле, которое используется объектом, вовлеченным в совмещенные операции ввода/вывода. Для IFS-провайдеров это поле используется базовой операционной системой (IFS - Installable File System - инсталлируемая файловая система).

    Offset и OffsetHigh

    Поле зарезервировано для сервис-провайдеров.

    hEvent

    Если совмещенные операции ввода/вывода запущены в отсутствии программ завершения (lpCompletionRoutine равно NULL), тогда это поле должно содержать дескриптор (указатель) объекта WSAEVENT. В противном случае (lpCompletionRoutine не равно NULL) клиент может использовать это поле как сочтет нужным.

    Приоритетные данные могут доставляться пользователю независимо от обычной информации. Для коммуникационных протоколов, где предусмотрена пометка данных как срочные (например, TCP, позволяющий доставку срочной информации в общем потоке данных) система извлекает приоритетную информацию из общего потока и запоминает отдельно.

    Пользователь может определить, имеется ли приоритетная непрочитанная информация, используя процедуру WSPIoctl(SIOCATMARK). Для протоколов, где положение приоритетной информации в общем потоке имеет смысл, сервис-провайдер обеспечивает указатели, определяющие это положение. Для таких протоколов допускается обработка приоритетных данных в общем информационном потоке. Это достигается путем установки опции соединителя SO_OOBINLINE (OOB - Out-Of-Band). Для других протоколов, где блоки приоритетных данных независимы от общего информационного потока, попытка установить опцию SO_OOBINLINE вызовет ошибку. Приложение может использовать команду SIOCATMARK WSPIoctl для определения наличия непрочитанных блоков приоритетной информации. При запрещении SO_OOBINLINE (disabled - значение по умолчанию):

    Сервис-провайдер WinSock сообщает клиенту о FD_OOB событиях, если клиент зарегистрирован для этого с помощью процедуры WSPAsyncSelect, точно таким же образом FD_READ используется для сообщения о присутствии обычных данных. Таким образом, FD_OOB посылается, когда поступает приоритетная информация, а также когда данные прочитаны с использованием флага MSG_OOB, в условиях присутствия приоритетных данных, подлежащих чтению. Сообщение FD_READ для приоритетных данных не посылается.

    Сервис-провайдер WinSock возвращает соответствующий набор exceptfds при выполнении процедуры WSPSelect, если приоритетные данные присутствуют в очереди соединителя.

    Клиент может вызвать WSPRecv с MSG_OOB для чтения блока приоритетных данных.

    Клиент может вызвать процедуру WSPRecv без MSG_OOB для чтения потока обычной информации. Блок приоритетных данных не может появиться в потоке обычных данных. Если приоритетные данные остаются после запроса WSPRecv, сервис-провайдер дает сообщение клиенту с помощью флага FD_OOB или через exceptfds при использовании запроса B>WSPSelect.

    Для протоколов, где приоритетные данные находятся в потоке обычных данных, одного запроса WSPRecv недостаточно. Один вызов WSPRecv вернет обычные данные до маркера, и потребуется второй запрос WSPRecv для чтения данных после маркера.

    При разрешении SO_OOBINLINE (enabled):

    Сообщение FD_OOB не посылается для приоритетных данных, а процедуры WSPSelect и WSPAsyncSelect рассматривают эти данные как обычные, о типе информации можно судить по readfds соединителя или по сообщению FD_READ, соответственно.

    Клиент не может осуществлять вызов WSPRecv с флагом MSG_OOB для чтения блока приоритетных данных - в противном случае будет получен код ошибки WSAEINVAL.

    • Клиент может вызвать WSPRecv без флага MSG_OOB. Любая приоритетная информация будет доставлена в потоке обычных данных. Приоритетные данные не будут никогда перемешаны с обычными данными, необходимо три запроса чтения для получения приоритетной информации. Первый запрос возвращает обычные данные, предшествующие приоритетным, второй - возвращает приоритетные данные, третий возвращает нормальные данные, следующие за приоритетными.

    Программа WSPAsyncSelect прекрасно приспособлена для выявления приоритетных данных, когда SO_OOBINLINE находится в состоянии выключено.

    Использование соединителя несколькими процессами одновременно организовано следующим образом. Базовый процесс для получения специальной структуры WSAPROTOCOL_INFO вызывает WSPDuplicateSocket. Эта процедура для передачи структуры другому процессу использует межпроцессный механизм коммуникаций (IPC). Последний процесс использует структуру WSAPROTOCOL_INFO при обращении к WSPSocket. Дескриптор соединителя, полученный в результате этой операции, будет дополнительным дескриптором исходного соединителя, который с этого момента может использоваться двумя процессами.

    Такой механизм разработан для того, чтобы удовлетворить как требованиям однопроцессной версии Windows 3.1, так и многопроцессным вариантам Windows 95 и NT. Следует иметь в виду, что совместное использование соединителей несколькими процессами возможно и без использования WSPDuplicateSocket, так как дескриптор соединителя доступен для всех процессов.

    Когда формируется дескриптор нового соединителя IFS-провайдер должен вызвать WPUModifyIFSHandle, а не-IFS-провайдер должен вызвать WPUCreateSocketHandle (IFS - Installable File System).

    Так как реально дублируются дескрипторы, а не сами соединители, все параметры соединения оказываются абсолютно идентичными.

    Контроль состояния используемых совместно соединителей осуществляется посредством WSPAsyncSelect и WSPEventSelect. Вызов одного из указанных запросов с одним из дескрипторов соединителя в качестве параметра, аннулирует любую предшествующую регистрацию событий для указанного соединителя, вне зависимости от того, какой из дескрипторов использован для новой регистрации. Таким образом, нельзя для процесса A иметь FD_READ-события, а для процесса B получать FD_WRITE-события.

    Процесс может вызвать WSPCloseSocket для дублирующего соединителя и старый дескриптор будет ликвидирован, в то время как сам соединитель, ему соответствующий, останется открытым вплоть до выполнения процедуры WSPCloseSocket.

    Два или более дескрипторов могут соответствовать одному и тому же соединителю и использоваться независимо для операций ввода/вывода. Однако, интерфейс WinSock не осуществляет какого-либо контроля за доступом, задача координации совместного использования соединителя является объектом ответственности самих процессов.

    Для простоты в дальнейшем термин "многоточечный" будет означать широковещательный или мультикастинг.

    В настоящее время многоточечные приложения (напр., IP-мультикастинг, ST-II, T.120, ATM UNI, и т.д.) значительно различаются по способу подключения узла к многоточечной сессии. Для декларации различных многоточечных атрибутов протокола в WinSock 2 используется структура WSAPROTOCOL_INFO. Просматривая эти атрибуты, программист может узнать, какие соглашения должны быть реализованы.

    В плоскости управления существует два типа различных сессий: rooted и non-rooted (корневые и некорневые). В случае корневого управления существует участник, называемый c_root, который отличается от всех остальных членов многоточечной сессии, которые называются c_leaf (периферийные члены группы). Участник сессии c_root должен оставаться в списке участников на протяжении всей многоточечной сессии, так как без его участия сессия будет прервана. c_root обычно инициирует многоточечную сессию путем установления связей с участниками типа c_leaf. c_root может вводить членов в группу, но c_leaf может подключиться к c_root позднее.

    Для некорневой плоскости управления, все участники многоточечной сессии являются периферийными узлами и не существует какого-то выделенного узла. Каждый c_leaf должен подключиться к многоточечной сессии, которая либо существует всегда (как в случае IP-мультикастинг адреса), или создана за счет какого-то внешнего механизма. При другом подходе c_root по-прежнему существует, но принадлежит сети в целом (не является одним из участников сессии). Так как корневой узел существует, некорневая управляющая плоскость может рассматриваться как неявно корневая. Примерами такого рода неявно корневых схем являются система IP-мультикастинга многоточечные блоки управления (Multipoint Control Unit - MCU) в H.320-видеоконференциях и т.д.

    В плоскости данных существует два стиля передачи информации: rooted и non-rooted (корневой и некорневой). В корневой плоскости данных существует выделенный участник, называемый d_root. Обмен данными происходит исключительно между d_root и остальными участниками многоточечной сессии, которые называются d_leaf. Трафик может быть однонаправленным или двунаправленным. Данные, посланные d_root, будут доставлены всем d_leaf, в то время как данные, отправленные d_leafs попадут только в d_root. В случае корневой плоскости данных не существует потока данных между периферийными узлами группы (d_leaf).

    В некорневой плоскости данных, все участники эквивалентны и любая информация, посланная участником, будет доставлена всем членам группы (сессии). Аналогично каждый узел d_leaf может получать данные ото всех остальных узлов группы, а также от любых узлов, не участвующих в данной сессии.

    В структуре WSAPROTOCOL_INFO имеется три поля атрибутов для выделения различных схем, используемых в плоскостях управления и данных:

    1. XP1_SUPPORT_MULTIPOINT = 1 указывает на то, что этот протокол поддерживает многоточечные коммуникации, а последующие два поля имеют смысл.
    2. XP1_MULTIPOINT_CONTROL_PLANE определяет, является ли плоскость управления корневой ( = 1) или не корневой ( = 0).
    3. XP1_MULTIPOINT_DATA_PLANE указывает, является ли плоскость данных корневой ( = 1) или некорневой ( = 0).

    В определенные моменты соединители, включенные в многоточечную сессию, могут по своему поведению отличаться от соединителей типа точка-точка. Так соединитель вида d_leaf в корневой плоскости данных может только посылать информацию участнику d_root. Это вызывает необходимость для клиента быть способным заявить об этом на стадии формирования соединителя. Делается это с помощью четырех многоточечных атрибутных флагов, которым присваивается определенное значение через параметр dwFlags в WSPSocket:

    SA_FLAG_MULTIPOINT_C_ROOT служит для создания соединителя, работающего как c_root. Это разрешено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости управления.

    WSA_FLAG_MULTIPOINT_C_LEAF предназначен для генерации соединителя, работающего как c_leaf. Это возможно, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.

    WSA_FLAG_MULTIPOINT_D_ROOT предполагает формирование соединителя, работающего как d_root. Это позволено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости данных.

    WSA_FLAG_MULTIPOINT_D_LEAF служит для создания соединителя, работающего как d_leaf. Это допускается, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.

    Когда создается многоточечный соединитель, один из двух флагов плоскости управления и один из двух флагов плоскости данных должны быть заданы в параметре dwFlags WSPSocket. Таким образом, при создании многоточечного соединителя могут быть реализованы четыре возможности: c_root/d_root, c_root/d_leaf, c_leaf/d_root, или c_leaf /d_leaf.

    Когда d_leaf-соединители используются в некорневой плоскости данных, обычно желательно управлять системой так, чтобы отправляемый трафик попадал назад в тот же соединитель. Команда SIO_MULTIPOINT_LOOP для WSPIoctl используется для разрешения или запрещения зацикливания многоточечного трафика.

    При использовании мультикастинга обычно необходимо специфицировать способ реализации сессии. Среди параметров сессии важную роль играет число вовлеченных сетевых сегментов. Для регулирования этого числа используется команда SIO_MULTICAST_SCOPE WSPIoctl. Нулевое значение числа сетевых сегментов означает, что мультикастинг пакеты не покинут пределы ЭВМ и могут попадать только во внутренние соединители. Значение единица (число по умолчанию) указывает, что мультикастинг-пакеты не могут выйти за пределы маршрутизатора локальной сети. Большие величины позволят распространение сообщений, проходящих соответствующее число маршрутизаторов. Этот код идентичен параметру времени жизни (TTL) в IP-мультикастинге.

    Многоточечный соединитель часто характеризуется его ролью в плоскости данных и управления. Следует иметь в виду, что один и тот же соединитель может иметь совершенно разную роль в разных плоскостях.

    В схемах для корневой плоскости периферийные узлы добавляются в многоточечную группу одним из двух способов. В первом методе, корень использует WSPJoinLeaf для инициализации соединения с периферийным узлом и приглашает его быть участником сессии. Со стороны периферийного узла приложение должно создать c_leaf-соединитель и использовать WSPListen для установки его в режим ожидания (listen). Периферийный узел получит сообщение FD_ACCEPT, которое означает приглашение присоединиться к многоточечной сессии, и может объявить о своем желании подключиться путем вызова WSPAccept. Корневое приложения получит сообщение FD_CONNECT, когда операция подключения к группе завершена.

    Во втором методе роли меняются. Корневой клиент создает соединитель c_root и переходит в режим ожидания (listen). Периферийный узел, желающий присоединиться к сессии, создает соединитель c_leaf и запускает WSPJoinLeaf, чтобы инициализировать соединение и доступ. Корневой клиент получает FD_ACCEPT, когда приходит запрос доступа, и принимает периферийный узел в группу посредством запроса WSPAccept. Периферийный узел получает FD_CONNECT, когда он принят в группу. Для случая IP-мультикастинга это эквивалентно опции соединителя IP_ADD_MEMBERSHIP. Читателей, знакомых с использованием несвязного UDP-протокола в IP-мультикастинге, может смутить семантика, ориентированная на соединение, присутствующая здесь. В частности указание на то, что используется запрос WSPJoinLeaf для соединителя UDP и ожидание сообщения FD_CONNECT могут вызвать недоразумение. Существуют уже, однако, прецеденты использования такой семантики для протоколов, не ориентированных на соединение. Разрешено и иногда полезно, например, использовать процедуру WSPConnect для UDP-соединителей. Общим результатом применения семантики, ориентированной на соединение для несвязных соединителей, является ограничение на то, как эти соединители могут использоваться. UDP-соединитель, используемый в WSPJoinLeaf, будет иметь определенные ограничения, а ожидание сообщения FD_CONNECT (которое в этом случае указывает на посылку соответствующего IGMP-сообщения) является одним из таких ограничений. Существует три случая, когда клиент может использовать WSPJoinLeaf:

    1. При работе в качестве многоточечного сервера (root), приглашая новый периферийный узел принять участие в сессии.
    2. При работе в качестве периферийного узла, выполняя запрос подключения к корневой многоточечной сессии.
    3. При работе в качестве периферийного узла, запрашивая подключение к некорневой многоточечной сессии (например, IP-мультикастинг).

    Как было упомянуто ранее, WSPJoinLeaf используется для присоединения периферийного узла к многоточечной сессии. WSPJoinLeaf имеет те же параметры и семантику, что и WSPConnect за исключением того, что он возвращает дескриптор соединителя (как и WSPAccept), и имеет дополнительный параметр dwFlags. Параметр dwFlags показывает, будет ли соединитель работать только в режиме чтения, только в режиме записи или в обоих режимах. Только многоточечный соединитель может использоваться в качестве входного параметра s этой процедуры. Если многоточечный соединитель находится в неблокирующем состоянии, полученный дескриптор соединителя нельзя будет использовать до тех пор, пока не будет получено FD_CONNECT. Корневое приложение в многоточечной сессии может вызвать WSPJoinLeaf один или более раз для того, чтобы добавить новые узлы к текущей многоточечной сессии.

    Параметры дескриптора соединителя, присланного WSPJoinLeaf, варьируются в зависимости от того, является ли дескриптор c_root или c_leaf. Для c_root соединителя, параметр name означает имя определенного периферийного узла, который должен быть добавлен, а возвращенный дескриптор соединителя является c_leaf и соответствует вновь добавленному периферийному узлу. Некоторые многоточечные приложения могут позволять этому соединителю "постороннее" общение с корневым сервером.

    При вызове WSPJoinLeaf для соединителя c_leaf, параметр name содержит адрес корневого приложения (для схемы корневого управления) или существующей многоточечной сессии (некорневая схема управления), и возвращенный дескриптор соединителя является тождественным по отношению ко входному дескриптору соединителя. В корневой схеме управления, корневой клиент должен поставить свой c_root соединитель в режим ожидания с помощью WSPListen. При запросе периферийного узла о присоединении к группе присылается стандартное сообщение FD_ACCEPT. Корневой клиент использует для подключения нового периферийного узла обычную процедуру WSPAccept. Запрос WSPAccept присылает дескриптор соединителя c_leaf, точно также как и WSPJoinLeaf.

    Многоточечный корневой клиент является ответственным за прерывание сессии. Такое приложение может использовать WSPShutdown или WSPClosesocket для соединителя c_root, чтобы прислать всем членам группы соединителей c_leaf сообщение FD_CLOSE.

    Рассмотрим семантическое отличие многоточечных и обычных соединителей . В плоскости управления имеется существенное семантическое отличие между соединителями c_root и обычными соединителями точка-точка:

    1. Cоединитель c_root может использоваться в процедуре WSPJoinLeaf для подключения новых периферийных узлов;
    2. Постановка соединителя c_root socket в режим ожидания (путем вызова WSPListen) не препятствует тому, чтобы соединитель c_root использовался оператором WSPJoinLeaf для добавления в список участников нового периферийного узла или для посылки или получения информации;
    3. Закрытие соединителя c_root вызовет отправку всем сопряженным соединителям c_leaf сообщения FD_CLOSE.

    Не существует какого-либо семантического различия между соединителем c_leaf и традиционным соединителем в плоскости управления, за исключением того, что соединитель c_leaf может использоваться процедурой WSPJoinLeaf, а использование соединителя c_leaf в WSPListen указывает на то, что должны восприниматься только запросы многоточечного соединения.

    В плоскости данных семантическое отличие между соединителями d_root и традиционными соединителями заключается в следующем:

    1. Данные, посланные на соединитель d_root, будут доставлены всем членам группы узлов, участвующих в многоточечном обмене;
    2. Данные, полученные соединителем d_root, могут поступить от любого участника многоточечного обмена.

    Соединитель d_leaf в корневой плоскости данных не имеет каких-либо семантических отличий от традиционных соединителей, однако, в некорневой плоскости данных информация, посланная на соединитель d_leaf, поступит ко всем периферийным узлам группы. Данные могут передаваться любым участником многоточечной сессии. Информация о том, находится ли соединитель d_leaf в корневой или некорневой плоскости данных, хранится в структуре соединителя WSAPROTOCOL_INFO.

    Сводные данные по опциям Winsock 2 вместе с их значениями по умолчанию приведены в таблице 7.11 (см. также описания WSPGetSockOpt и WSPSetSockOpt). Сервис-провайдеры Windows должны распознавать все эти опции.

    Таблица 7.11. Опции Winsock 2.

    Опция

    Тип

    Назначение

    Значение по умолчанию

    SO_ACCEPTCONN

    BOOL

    Соединитель в режиме WSPListen.

    FALSE, если WSPListen не была выполнена

    SO_BROADCAST

    BOOL

    Соединитель сконфигурирован для передачи широковещательных сообщений.

    FALSE

    SO_DEBUG

    BOOL

    Разрешен отладочный режим.

    FALSE

    SO_DONTLINGER

    BOOL

    Если истинно, опция SO_LINGER запрещена.

    TRUE

    SO_DONTROUTE

    BOOL

    Маршрутизация запрещена.

    FALSE

    SO_ERROR

    int

    Возвращает статус ошибки и осуществляет сброс.

    0

    SO_GROUP_ID

    GROUP

    Идентификатор группы, к которой принадлежит соединитель.

    NULL

    SO_GROUP_
    PRIORITY

    int

    Относительный приоритет для соединителей членов группы.

    0

    SO_KEEPALIVE

    BOOL

    Послано сообщение "еще жив".

    FALSE

    SO_LINGER

    struct linger

    Возвращается текущее значение опции LINGER.

    l_onoff = 0

    SO_MAX_MSG_SIZE

    int

    Максимальный размер сообщения для соединителей, ориентированных на обмен сообщениями. Не имеет смысла для соединителей, ориентированных на потоки данных.

    Зависит от реализации

    SO_OOBINLINE

    BOOL

    Приоритетная информация получена в потоке обычных данных.

    FALSE

    SO_PROTOCOL_INFO

    struct WSAPROTOCOL_INFO

    Описание протокола для заданного соединителя.

    Зависит от протокола

    SO_RCVBUF

    int

    Размер буфера для приема.

    Зависит от реализации

    SO_REUSEADDR

    BOOL

    Адрес, к которому подключен соединитель, может быть использован другими.

    FALSE

    SO_SNDBUF

    int

    Размер буфера для отправки

    Зависит от реализации

    SO_TYPE

    int

    Тип соединителя (т.е. SOCK_STREAM).

    Как было при создании socket

    PVD_CONFIG

    char FAR *

    Структурный объект, содержащий информацию о конфигурации сервис-провайдера.

    Зависит от реализации

    TCP_NODELAY

    BOOL

    Запрещает алгоритм Нагля.

    Зависит от реализации

    В таблице 7.12 приведен список ioctl-кодов команд для соединителей.

    Таблица 7.12. ioctl-коды команд для соединителей (Winsock 2)

    Код операции

    Тип входа

    Тип выхода

    Значение

    FIONBIO

    unsigned long

    Не использ.

    Разрешает или запрещает неблокирующий режим соединителя.

    FIONREAD

    Не используется

    unsigned long

    Определяет объем информации, который может быть считан с соединителя автоматически.

    SIOCATMARK

    Не использ.

    BOOL

    Определяет, будут ли считаны все приоритетные данные.

    SIO_ASSOCIATE_HANDLE

    Зависит от API

    Не использ.

    Связывает соединитель с заданным дескриптором интерфейса-партнера.

    SIO_ENABLE_CIRCULAR_QUEUEING

    Не использ.

    Не использ.

    Разрешает организацию циклической очереди.

    SIO_FIND_ROUTE

    struct sockaddr

    Не использ.

    Запрашивает маршрут до указанного адреса.

    SIO_FLUSH

    Не использ.

    Не использ.

    Аннулирует содержимое выходной очереди.

    SIO_GET_BROADCAST_ADDRESS

    Не использ.

    struct sockaddr

    Возвращает протокольно-зависимый адрес, предназначенный для использования с WSPSendTo

    SIO_GET_QOS

    Не использ.

    QOS

    Возвращает текущую спецификацию QOS для соединителя.

    SIO_GET_GROUP_QOS

    Не использ.

    QOS

    Возвращает текущую спецификацию QOS для группы, к которой принадлежит соединитель.

    SIO_MULTIPOINT_LOOKBACK

    BOOL

    Не использ.

    Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем на локальной ЭВМ.

    SIO_MULTICAST_SCOPE

    int

    Не использ.

    Определяет режим мультикастинг-обмена.

    SIO_SET_QOS

    QOS

    Не использ.

    Устанавливает новую спецификацию качества сервиса для соединителя.

    SIO_SET_GROUP_QOS

    QOS

    Не использ.

    Устанавливает новую спецификацию для группы, к которой принадлежит соединитель.

    SIO_TRANSLATE_HANDLE

    int

    Зависит от API

    Возвращает соответствующий дескриптор соединителя s, который верен для контекста интерфейса.

    В таблице 7.13 представлены основные характеристики базовых SPI (Service Provider Interfaces) процедур передачи данных для Winsock 2.

    Таблица 7.13. Базовые SPI процедуры передачи данных Winsock 2

    WSPAccept

    Входное соединение подтверждается и создается соединитель. Исходный соединитель возвращается в режим ожидания (listening). Эта процедура позволяет условное создание соединителей и их включение в группу.

    WSPAsyncSelect

    Выполняет WSPSelect в асинхронном режиме.

    WSPBind

    Присваивает локальное имя безымянному соединителю.

    WSPCancelBlockingCall

    Аннулирует блокирующую процедуру WinSock.

    WSPCloseSocket

    Удаляет соединитель из справочной таблицы.

    WSPConnect

    Инициализирует соединение для специфицированного соединителя. Эта процедура позволяет обмениваться данными о соединении и QOS.

    WSPDuplicateSocket

    Возвращает структуру WSAPROTOCOL_INFO, которая может быть использована для формирования нового дескриптора соединителя, используемого несколькими процессами.

    WSPEnumNetworkEvents

    Выявляет факт появления сетевых событий.

    WSPEventSelect

    Связывает сетевые события с объектами события.

    WSPGetOverlappedResult

    Сообщает состояние завершения процесса при совмещении операций ввода/вывода.

    WSPGetPeerName

    Возвращает имя партнера, подключенного к заданному соединителю.

    WSPGetSockName

    Возвращает локальный адрес, к которому подключен заданный соединитель.

    WSPGetSockOpt

    Возвращает опцию заданного соединителя.

    WSPGetQOSByName

    Сообщает параметры QOS на основе названия известной сетевой услуги.

    WSPIoctl

    Обеспечивает управление соединителем.

    WSPJoinLeaf

    Подключает периферийный узел к многоточечному обмену.

    WSPListen

    Организует процесс ожидания (Listen) на заданном соединителе.

    WSPRecv

    Получает данные от подключенного или неподключенного соединителя. Эта процедура реализует прием рассеянных данных или массивов для соединителей, работающих в режиме совмещения операций ввода/вывода, и использует flags в качестве параметра IN OUT.

    WSPRecvDisconnect

    Завершает операции приема для соединителя и возвращает информацию об отключении для соединителей, ориентированных на соединение.

    WSPRecvFrom

    Принимает данные от подключенного или неподключенного соединителя. Эта процедура позволяет работать с рассеянными данными в совмещенном режиме ввода/вывода, и использует flags в качестве параметра IN OUT.

    WSPSelect

    Выполняет синхронное мультиплексирование.

    WSPSend

    Посылает данные подключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещении операций ввода/вывода.

    WSPSendDisconnect

    Запускает процесс отключения соединителя и опционно посылает уведомление об отсоединении.

    WSPSendTo

    Посылает данные в подключенному или неподключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещенных операциях ввода/вывода.

    WSPSetSockOpt

    Запоминает опции, соответствующие определенному соединителю.

    WSPShutdown

    Прерывает частично дуплексное соединение.

    WSPSocket

    Процедура формирования соединителя, которая использует в качестве входной структуру WSAPROTOCOL_INFO и позволяет использовать созданный соединитель для совмещенных операций. Позволяет создавать группы соединителей.

    WSPStartup

    Инициализирует сервис-провайдера WinSock.

    WPUCloseEvent

    Ликвидирует дескриптор объекта события

    WPUCloseSocketHandle

    Ликвидирует дескриптор соединителя, сформированный WinSock DLL

    WPUCreateEvent

    Формирует новый объект события

    WPUCreateSocketHandle

    Создает новый дескриптор соединителя для не-IFS провайдеров

    WPUGetProviderPath

    Присылает путь к DLL для специфицированного провайдера

    WPUModifyIFSHandle

    Присылает модифицированный дескриптор IFS из WinSock DLL

    WPUPostMessage

    Выполняет стандартную процедуру PostMessage так, чтобы обеспечить обратную совместимость

    WPUQueryBlockingCallback

    Присылает указатель на вход в цикл псевдоблокировки

    WPUQuerySocketHandleContext

    Присылает значение контекста соединителя (только для провайдеров, не поддерживающих IFS)

    WPUQueueApc

    Ставит пользователя в очередь APC для указанной сессии

    WPUSetEvent

    Устанавливает объект события

    WSCDeinstallProvider

    Отмена регистрации сервис-провайдера

    WSCEnumProtocols

    Получение информации о доступных транспортных протоколах

    WSCInstallProvider

    Регистрация нового сервис-провайдера

    Previous: 7 Программирование для сетей (новые идеи, принципы и возможности)    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 8 Заключение    Next: 7.2 Сетевые драйверы


    previous up down next index index
    Previous: 8 Заключение    UP: 8 Заключение
    Down: 9 Литература
        Next: 9 Литература

    8.1 Вопросы по данному курсу
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Программу для проверки знаний по курсам этого сервера читатель может найти по адресу: saturn.itep.ru (knowtest). Список вопросов там почти в два раза длиннее.

    1. В чем смысл 7-уровневой модели ISO?
      1. Просто 7 круглое число.
      2. Необходимо для стандартизации оборудования на каждом из уровней.
      3. Связано с обеспечением идентичности форматов данных и протоколов на соответствующих уровнях для передатчика и приемника.
      4. Соответствует числу дней в неделе и помогает унифицировать запись даты.
    2. Как осуществляется синхронизация в региональных сетях Интернет?
      1. Выполняется привязка к точному эталону времени.
      2. Производится разводка синхронизующих сигналов для всех узлов от общего источника.
      3. Производится синхронизация от локальных часов
      4. Выполняется привязка к сигналам, которые служат для передачи данных
    3. Зачем нужна преамбула в пакетах Ethernet?
      1. Туда записывается характеристика последующего пакета
      2. Служит для синхронизации приемника
      3. Позволяет выделить начало пакета
      4. Служит для прерывания приема в случае, когда не зарегистрирован конец предшествующего пакета
    4. Чему равно число мод N в оптическом волокне диаметром d, с числовой апертурой А для длины волны l?
      1. N = (2p 2dA)/l
      2. N = (2p 2d2A2)/l 2
      3. N = 2p 2dAl 2
      4. N = (2p 2d2A2)/l 4
    5. Почему интеграл любого достаточно длинного фрагмента передаваемого кода должен быть равен нулю?
      1. Иначе напряжение на входе приемника может меняться произвольным образом, что в конце концов приведет к пробою во входных цепях.
      2. Позволяет стабилизировать порог выделения логического нуля и логической единицы из-за наличия на входе трансформаторов или конденсаторов
      3. Это необходимо, чтобы отделить передаваемый сигнал от входного при использовании одной скрученной пары
      4. Это помогает улучшить отношение сигнал-шум.
    6. Что такое числовая апертура волокна А?
      1. А = SQRT(n1 2 - n2 2)
      2. А = SQRT(n1 2 + n2 2)
      3. А = SQRT(n1 - n2)
      4. А = arcsin(n1/n2)
    7. Чему равно усиление G антенны с площадью А для длины волны l?
      1. G = 4pA/l 4
      2. G = 4pAl 2
      3. G = 4pA/l 2
      4. G = 4pAl 4
    8. Чему равен угол излучения антенны радиусом R для длины волны l?
      1. T = 0,61l/R2
      2. T = 0,61l 2/R2
      3. T = 0,61l 2/R4
      4. T = 0,61l/R
    9. Где по частоте применение радиоканалов ограничивается поглощением волн в атмосфере?
      1. 2,5 ГГц
      2. 20 ГГц
      3. 30 ГГц
      4. 100 ГГц
    10. Чему равен максимальный размер сети 10Мбит/с Ethernet, если не использовать маршрутизаторы, бриджи или переключатели?
      1. 2,5 км
      2. 500м
      3. 2км
      4. 200 м
    11. Что общего между сетями X.25, ISDN, Frame Relay и ATM?
      1. Формат контрольной суммы
      2. Набор кодов управляющих команд
      3. Формат стартового и оконечного разделителей пакетов
      4. Метод формирования виртуального канала
    12. Какой зависимостью уровня сигнала характеризуются городские сотовые сети?
      1. Амплитуда сигнала обратно пропорциональна расстоянию (сказываются отражения от стен зданий)
      2. Амплитуда сигнала обратно пропорциональна квадрату расстояния
      3. Уровень сигнала обратно пропорционален третьей степени расстояния
      4. Уровень сигнала обратно пропорционален четвертой степени расстояния
    13. Зачем используется многоуровневое кодирование сигнала?
      1. В этом случае одному перепаду соответствует несколько бит кода
      2. Это упрощает кодирующее оборудование
      3. Это позволяет проверить корректность процедуры кодирования
      4. Это улучшает отношение сигнал-шум
    14. Зачем нужна эквилизация при формировании телекоммуникационного канала?
      1. Эквилизация - это выравнивание условий передачи всех частот в пределах полосы пропускания
      2. Эквилизация - это выравнивание порогов чувствительности приемника и передатчика
      3. Эквилизация - это эхоподавление для всего спектра частот полосы пропускания
      4. Эквилизация - это выравнивание отношения сигнал-шум для всего рабочего спектра частот
    15. Что такое межсимвольная интерференция?
      1. Это влияние определенных кодовых последовательностей на распознавание кодов, следующих за ними
      2. Это ошибки, происходящие из-за наложения кодов символов
      3. Это метод сжатия информации
      4. Это искажение кодов за счет расплывания волновых пакетов
    16. Что ограничивает число уровней при кодировании входного сигнала?
      1. Возможности современной твердотельной технологии
      2. Разрядность используемых АЦП
      3. Ухудшение отношения сигнал-шум
      4. Может возникнуть ситуация, когда выходное и входное устройство настроены на разное число уровней
    17. В чем отличие PPP и SLIP?
      1. Это два названия одного и того же протокола
      2. Один из них рассчитан на последовательную, а другой - на параллельную передачу данных
      3. Один использует CRC, а другой нет
      4. PPP может работать с разными вложенными пакетами
    18. Как заполняется память моста MAC-типа?
      1. Это делает администратор, занося адреса объектов, подключенных к каждому порту
      2. Мост исследует сетевое окружение и записывает результаты в память
      3. Он использует информацию, содержащуюся в приходящих пакетах
      4. Пользователи регистрируются в мосту сами при подключении.
    19. Если ЭВМ <А> может связаться с ЭВМ <В> через обычный MAC-мост Б1, а ЭВМ <В> может связаться с <А> через такой же мост Б2, что от этого можно ожидать? Как это факт можно диагностировать?
      1. Можно ожидать ускорения обмена между машинами и улучшения надежности, так как имеются два независимых канала связи
      2. Все будет так, как если бы был один канал, так как обмен может идти только через один из каналов
      3. Такая сеть работать не может
      4. Для нормальной работы сети мосты должны поддерживать алгоритм "расширяющееся дерево"
    20. Как осуществляется синхронизация станций в сетях CAN?
      1. От стандартного эталона времени
      2. Синхронизация вообще не нужна
      3. Синхронизация осуществляется между передаваемыми порциями данных
      4. Так как здесь используется схема доступа CSMA, то и синхронизация происходит, как в Ethernet посредством преамбулы.
    21. В процессе преобразования звука в код используются m и A-преобразования. Зачем они нужны и в чем их отличие?
      1. Это методы логарифмического преобразования, которые нужны для того, чтобы кривая преобразования прошла через начало координат
      2. А-преобразование является линейным и служит для изменения масштаба преобразуемых величин
      3. В Европе используется А-преобразование, а в США m
      4. m-преобразование позволяет обеспечить лучшую точность
    22. Для чего используется дифференциальный метод в процессе преобразования аналогового сигнала в цифровую последовательность кодов?
      1. Дифференциальный метод улучшает отношение сигнал шум
      2. Дифференциальный метод позволяет получить большую точность преобразования
      3. Дифференциальный метод позволяет использовать корреляцию последовательных значений уровня сигнала
      4. Дифференциальный метод позволяет исключить влияние вариации потенциала земли на результат преобразования
    23. Что определяет минимальный размер пакета в сети Ethernet?
      1. Размер заголовка + длина контрольной суммы
      2. Минимальный размер равен заголовку + CRC + один байт
      3. Минимальный размер зависит от типа пакета (IEEE 802.3, Ethernet II или SNAP)
      4. Минимальный размер пакета равен 64 байтам
    24. Механизм коллапса в CSMA/CD?
      1. Происходит просто при переполнении буферов
      2. Из-за синхронизации передачи при большом числе столкновений
      3. Из-за ограничения пропускной способности кабелей и сетевого оборудования
      4. Реализуется, когда загрузка сегмента сети становится равной 10Мбит/c
    25. Оцените пропускную способность телевизионного кабеля (российского; полоса ~60 MГц) в Мбит/c
      1. Пропускная способность составляет 60 Мбит/c
      2. Пропускная способность составляет 600 Мбит/c
      3. Пропускная способность составляет 6000 Мбит/c
      4. Пропускная способность составляет 12000 Мбит/c
    26. Принципы работы виртуальных сетей на MAC-уровне
      1. Виртуальные сети на МАС-уровне - это модель, используемая для описания работы обычной сети, например Ethernet
      2. Виртуальные сети на МАС-уровне работают точно так же, как и на IP-уровне
      3. При использовании технологии виртуальных сетей отдельные каналы переключателя невозможно использовать
      4. В случае виртуальных сетей на МАС-уровне каналы переключаются так, что пакеты из заданных каналов могут попасть только в строго определенные каналы.
    27. Почему оборудование для работы с мультимодовыми волокнами дешевле?
      1. Это определяется конъюнктурой, сложившейся на рынке
      2. Утверждение не верно, мультимодовое волокно предъявляет более жесткие требования к оборудованию
      3. Одномодовое волокно имеет меньшую входную и выходную апертуру
      4. В случае одномодового волокна оборудование должно выделять определенную моду световой волны.
    28. Почему в Fast Ethernet может быть один повторитель первого класса и 2 - второго?
      1. Повторитель первого класса имеет большую задержку
      2. Это жестко определено действующим стандартом
      3. Повторители второго класса имеют большую полосу пропускания
      4. В случае использования повторителя первого класса никакие другие повторители просто не нужны
    29. Зачем нужны модемы (почему не передается непосредственно цифровой сигнал)?
      1. Модем нужен, чтобы улучшить отношение сигнал-шум
      2. Модем применяется для того, чтобы сделать канал более безопасным (усложнить перехват данных)
      3. Модем нужен для преобразования аналогового сигнала в цифровой
      4. Модем нужен для преобразования аналогового сигнала в цифровой и обратно
    30. Для чего используются микромодемы?
      1. Микромодемы используются, когда требуется минимизировать размер модема
      2. Когда расстояние между приемником и получателем не допускает использование обычного модема
      3. Когда расстояние мало, но нужно произвести изоляцию приемника и получателя по "земле"
      4. Когда для передачи данных используется шина "MicroChannel"
    31. Как модем осуществляет настройку на канал? Какие параметры при этом определяются?
      1. Настройка производится при инсталляции
      2. Настройка производится по-разному в зависимости от модели модема
      3. Производится автоматическое согласование возможностей модемов на обоих концах канала
      4. Минимизируется отношение сигнал шум
    32. Что будет, если оконечная сигнатура не будет обнаружена сетевым интерфейсом?
      1. Сеть прекратит работу и потребуется вмешательство администратора
      2. Будет послан сигнал Jabber и сеть продолжит свою работу
      3. Оконечная сигнатура будет выработана самим принимающим интерфейсом
      4. Ситуация будет воспринята и обработана как случай столкновения
    33. Особенности доступа к сети CAN?
      1. Схема доступа полностью идентична Ethernet
      2. Используется схема маркерного доступа
      3. Применяется схема CSMA с анализом приоритета доступа
      4. Используется схема доступа с фиксированной вероятностью начала передачи
    34. Особенности сетей DQDB
      1. Эти сети пригодны для организации конвейерной обработки в многопроцессорной системе
      2. Это сети с двойной очередью и двойной шиной, схема с маркерным доступом
      3. Сети DQDB имеют кольцевую структуру и предназначены для управления в реальном масштабе времени
      4. Сети DQDB обеспечивают двойное качество и двойную полосу пропускания
    35. Чем отличается сеть HIPPI от всех остальных сетей?
      1. Эти сети используют параллельную схему передачи данных
      2. Здесь используется особо скоростная последовательная схема обмена
      3. Эта сеть обеспечивает необычно большую длину кабельных сегментов
      4. В HIPPI применена нестандартная схема доступа к сетевой среде
    36. VOCODER (Почему символьное отображения фразы всегда короче закодированного и сжатого его звукового образа?)
      1. Символы используют оптимально короткие коды
      2. При символьном отображении применяются более эффективные алгоритмы сжатия
      3. При сжатии кодированного звука блоки данных имеют ограниченную длину, так как длинные блоки привели бы к слишком большим задержкам. А для коротких блоков нельзя достичь хорошего сжатия.
      4. При символьном отображении отсутствуют индивидуальные особенности речи говорящего
    37. Что такое эффект маскирования?
      1. Влияние масок в процессе преобразования звука в код
      2. Маскирующий эффект ограниченной полосы пропускания канала
      3. Эффект связан с понижением чувствительности уха при частотах выше некоторой составляющей частоты высокой амплитуды
      4. Эффект, аналогичный эхоподавлению, но для случая передачи звуковой информации
    38. На чем базируется преимущество оптоволокна над медным кабелем?
      1. Оптоволокно при равном сечении прочнее
      2. Оптоволокно обеспечивает лучшее отношение сигнал-шум
      3. Оптоволокно обеспечивает меньшее ослабление сигнала на километр
      4. Отоволокно исключает влияние разностей потенциалов земель между передатчиком и приемником
    39. В чем суть алгоритма "расширяющееся дерево"?
      1. Это алгоритм, обеспечивающий оптимальную маршрутизацию в сетях Интернет
      2. Это алгоритм, который решает проблему циклических маршрутов в локальной сети
      3. Алгоритм помогает подключать новых членов в мультикастинг-группу
      4. Алгоритм используется при рассылке мультимедийных данных
    40. Чем наложенная сеть отличается от физической?
      1. Наложенная сеть дешевле физической и по этой причине используется чаще
      2. Физическая сеть работает поверх наложенной, что обеспечивает большую надежность
      3. Наложенная сеть может обеспечить большую пропускную способность, что и обеспечивает ее привлекательность
      4. Наложенная сеть работает поверх физической
    41. Как может быть потерян пакет в локальной сети (согласно принципам SNMP-статистики)?
      1. Пакет теряется при столкновении
      2. Пакет теряется при переполнении буфера
      3. Пакет теряется, если его получение не подтверждено
      4. Пакет не может быть потерян в локальной сети никогда
    42. Что такое блокировка при работе с socket?
      1. Блокировка связана с тем, что пока выполняется одна процедура и процессор занят, другая процедура ждет своей очереди
      2. Блокировка связана с ситуацией вызова процедуры ACCEPT в отсутствии запросов в очереди
      3. Блокировка сопряжена с ожиданием завершения процедуры ввода/вывода
      4. Блокировка вызывается ожиданием формирования socket
    43. Пригодны ли сокеты для работы в протоколах, отличных от TCP/IP?
      1. Нет, сокеты применимы только в рамках стека протоколов TCP/IP
      2. Работа сокетов наcтраивается заданием определенных конфигурационных параметров
      3. Сокеты могут использоваться с любыми телекоммуникационными протоколами
      4. Сокеты применимы не только в TCP/IP
    44. В чем проблема использования идеологии UNIX при сетевом обмене без установления связи?
      1. UNIX при работе с socket не использует IP-адреса и нужно позаботиться об установлении соответствия между сокетом и IP-адресом
      2. В UNIX любая процедура ввода/вывода рассматривает файл и внешнее устройство неотличимыми друг от друга
      3. В UNIX любая процедура ввода/вывода предполагает, известными отправителя и получателя до начала обмена
      4. В UNIX нет таймеров и по этой причине возникают проблемы при обрывах связи
    45. Какие параметры обязательно задаются при конфигурировании сети?
      1. IP-адрес ЭВМ
      2. IP-адрес ЭВМ + маска субсети + IP-адрес маршрутизатора + IP-адрес DNS + IP-адрес сервера времени
      3. Ничего задавать не нужно, если работает система plug&play
      4. IP-адрес ЭВМ + маска субсети + IP-адрес маршрутизатора + IP-адрес DNS
    46. Алгоритм вычисления CRC
      1. Последовательность бит пакета делится на образующий полином, результат деления и является CRC
      2. Коды, составляющие пакет, последовательно складываются. Если возникает флаг переноса, добавляется 1 к младшему биту
      3. Коды пакета складываются по модулю 2 (исключающее ИЛИ)
      4. Последовательность бит пакета делится на образующий полином, инвертированный остаток от деления и является CRC
    47. Как можно измерить вероятность потери пакета в сети?
      1. С использованием протокола SNMP
      2. С помощью протокола ICMP
      3. C помощью протокола Finger
      4. Путем применения 6-го режима работы сетевого интерфейса
    48. Методы измерения потоков в работающей сети
      1. Путем подсчета числа пакетов, идущих по кабельному сегменту
      2. По числу столкновений в сегменте сети
      3. Посредством протокола SNMP
      4. С помощью маршрутизатора
    49. Почему базовая скорость канала ISDN равна 64 кбит в сек?
      1. Это связано с полосой пропускания коммутируемого телефонного канала
      2. Это число выбрано как 2 в 6-ой степени (могло быть выбрано и другое число)
      3. Эта полоса пропускания удобна для формирования иерархии пропускных способностей цифровых каналов (например, SDH)
      4. Эта полоса пропускания обеспечивает ровно 4 стандартных телефонных канала
    50. Что происходит при сжатии информации?
      1. Удаляются повторяющиеся нули, пробелы и знаки TAB
      2. Удаляются вообще все повторяющиеся подряд символы
      3. Производится преобразование исходного кодового текст путем циклических сдвигов
      4. Заменяются одни кодовые последовательности на другие
    51. Можно ли превзойти по эффективности алгоритм сжатия Хафмана?
      1. Нельзя;
      2. Практически невозможно;
      3. Легко и это практически всегда делается
      4. Это возможно лишь в некоторых случаях
    52. Как детектируются ошибки
      1. Для детектирования ошибок используется кратность 8 длины Ethernet-пакета
      2. Для детектирования ошибок используется CRC-суммирование на TCP-уровне
      3. Для детектирования ошибок используется суммирование по модулю 1 на UDP-уровне
      4. Для детектирования ошибок используются коды Хэмминга
    53. Методы коррекции ошибок
      1. Для исправления ошибок используется CRC-контрольные суммы
      2. Для исправления ошибок используется продольный и поперечный контроль по четности
      3. Для исправления ошибок используется методика контрольного суммирования по модулю 2
      4. Для исправления ошибок используются коды Хэмминга
    54. Как формируется виртуальный канал в X.25 или ISDN?
      1. С использованием протокола ARP
      2. С использованием протокола SNMP
      3. На основе протокола X.3
      4. С помощью процедуры SETUP
    55. В чем X.25 и ISDN уступают Интернет и почему?
      1. Интернет более универсален;
      2. Он обеспечивает больший спектр услуг;
      3. В Интернет можно получить большее быстродействие
      4. Интернет обеспечивает большую надежность.
    56. Можно ли дистанционно определить неработающий канал повторителя?
      1. Можно, если повторитель снабжен SNMP-поддержкой
      2. Нельзя, так как повторитель является пассивным сетевым прибором и не откликается на PING
      3. Можно в любом случае, если к данному каналу подключена работающая ЭВМ
      4. Это можно реализовать, применив режим 6 сетевого интерфейса
    57. Метод маркерного доступа (чем лучше и чем хуже Ethernet?)
      1. Ethernet удобнее для задач реального времени, так как может обеспечить большую пропускную способность
      2. Ethernet привлекательнее, так как не накладывает ограничений на топологию сети
      3. Маркерный доступ лучше, так как не ограничивает предельного размера локальной сети
      4. Маркерный доступ лучше для решения задач управления в реальном масштабе времени, так как здесь имеется механизм приоритетного доступа
    58. Зачем в каналах телефонной сети используются трансформаторы?
      1. Для организации питания телефонного оборудования от сети переменного тока
      2. Для отделения звукового сигнала от постоянного напряжения, передаваемого по телефонному кабелю
      3. Для изоляции по переменному току с целью обеспечения безопасности пользователя
      4. Для улучшения отношения сигнал-шум
    59. Пришел пакет в интерфейс ISDN, к которому подключен телефон, факс и ЭВМ. Как интерфейс определит, какому из приборов его передать?
      1. По тому, с каким из этих устройств была установлена связь на фазе выполнения SETUP
      2. По адресу места назначения, как в TCP/IP
      3. По значению поля SAPI и TEI
      4. По значению поля тип оборудования
    60. Как задается адрес TEI в ISDN?
      1. Администратором при инсталляции системы
      2. Автоматически интерфейсом NE1
      3. Автоматически интерфейсом NE2
      4. Часть адресов задается пользователем, а часть автоматически
    61. Почему в Ethernet сегодня чаще используются скрученные пары, а не коаксиальный кабель?
      1. Скрученная пара дешевле;
      2. Ее проще монтировать;
      3. Это диктуется фирмами-производителями оборудования;
      4. Пара обеспечивает большую безопасность.
    62. Как в последовательном канале выявляется начало и конец пакета?
      1. По времени;
      2. По изменению полярности сигнала;
      3. По специальной сигнатуре;
      4. По концу предыдущего пакета определяется начало следующего.
    63. Как лучше разместить сервер и почему (буквой К обозначен концентратор)?

      1. Лучше первый метод (верхний вариант)
      2. Второй
      3. Оба эквивалентны
      4. Это зависит от типа используемого оборудования и от типа среды (скрученная пара, коаксиальный кабель или оптоволокно)
    64. Тот же вопрос для случая, когда вместо сервера стоит переключатель

      1. Лучше первый метод
      2. Второй
      3. Оба эквивалентны
      4. Это зависит от типа используемого оборудования и от типа среды (скрученная пара, коаксиальный кабель или оптоволокно)
    65. В чем проблемы передачи звука по каналам Интернет (канал имеет пропускную способность 32 кбит/c)?
      1. Ограничение полосы, что приводит к потерям пакетов;
      2. Нелинейные искажения из-за вариации времени передачи;
      3. Малая управляемость;
      4. Конкуренция сессий, что приводит к потере фрагментов.
    66. Аудио или видео канал должны иметь высший приоритет при передаче данных?
      1. Видео, так как он является более информационно емким
      2. Аудио
      3. Каналы должны иметь равный приоритет, так как в равной мере важны
      4. Это зависит от общей пропускной способности канала
    67. В чем отличие PDH и SDH?
      1. PDH используется для асинхронной передачи, а SDH для синхронной
      2. PDH ориентирован на работу с сетями ISDN, а SDH с Интернет
      3. PDH американский стандарт передачи данных, а SDH - европейский
      4. PDH при извлечении блока данных требуется полная разборка контейнеров, а в SDH - нет
    68. Что определяет максимальное число повторителей в Ethernet (<4)?
      1. Это записано в стандарте и по этой причине нужно выполнять эту регламентацию
      2. Это диктуется требованиями ограничения задержки в субсети
      3. При большом числе повторителей неизбежны искажения сигналов
      4. При большем числе повторителей увеличится сверх меры суммарная загрузка субсети
    69. Можно ли построить фрагмент сети Ethernet, в котором не будет столкновений?
      1. Невозможно
      2. Сейчас трудно из-за ограничений современных технологий
      3. Можно
      4. Это зависит от версии используемого протокола
    70. Как получается 100Мбит/с в сетях 100BASET4?
      1. Используется 3 скрученные пары для передачи в одном направлении
      2. Используется 4 скрученные пары для передачи в одном направлении
      3. Используется 2 скрученные пары, как и в случае 100base-TX
      4. Для решения задачи используется специальный троичный код
    71. Что ограничивает длину кольца в FDDI?
      1. Тип используемого оптического волокна
      2. Тип используемого оборудования
      3. Это зависит от того, DAS или SAS узлы используются
      4. Это зависит от длины волны используемого излучения
    72. Cколько маркеров может находиться одновременно в сети FDDI?
      1. Один
      2. Два
      3. Четыре
      4. Это зависит от длины кольца
    73. Почему Ethernet мало приемлем для задач реального времени?
      1. Нет Ethernet-интерфейсов для подключения измерительного оборудования
      2. Не гарантирована задержка реакции сети на событие
      3. Слишком большая величина RTT
      4. Слишком малое значение MTU
    74. Как можно уменьшить число широковещательных пакетов в сетях Windows-95 и NT?
      1. С помощью разделения сети на субсети с помощью переключателей
      2. Введя NT-сервер
      3. Запретив рассылку широковещательных запросов на фазе конфигурации рабочей станции
      4. Поделив сеть на субсети с помощью маршрутизаторов
    75. Что нужно согласовывать при построении канала из Европы в США?
      1. Не нужно ничего согласовывать, так как применены международные стандарты
      2. Нужно согласовывать скорости передачи
      3. Нужно согласовывать кодировку, так как там используются разные схемы логарифмического преобразования
      4. Нужно использовать специальные шлюзы, так как стандарты совершенно не имеют ничего общего
    76. Чем определяется максимальный размер пакета в Ethernet? Почему нельзя увеличивать размер пакета беспредельно?
      1. Слишком длинный пакет блокировал бы сетевой сегмент на слишком долгое время
      2. Слишком длинные пакеты приводили бы к переполнению буфера сетевого интерфейса
      3. Максимальная длина пакета определяется величиной TTL
      4. Максимальная длина пакета задается значением BER
    77. В чем заключается функция процедуры BIND?
      1. Она устанавливает соответствие между созданным сокетом и IP-адресом
      2. Она устанавливает связь между двумя сокетами
      3. Она организует структуру очереди запросов для конкретного сокета и переводит систему в режим ожидания
      4. Процедура BIND используется только в случае подготовки обмена с установлением соединения
    78. Что ограничивает пропускную способность локальной сети?
      1. Величина TTL
      2. Значение MTU
      3. Значение window
      4. Величина времени жизни ARP-кэша
    79. Какой длины поле CRC используется в сети ATM?
      1. 1 байт
      2. 2 байта
      3. 4 байта
      4. 10 бит
    80. В какой сети предусмотрено выравнивание информационных потоков передатчика и приемника при перегрузке на физическом уровне?
      1. Интернет
      2. ISDN
      3. Ethernet
      4. Frame Relay
    81. Можно ли построить сеть FDDI с длиной 100 км и числом станций 1000?
      1. Можно
      2. Нельзя, так как это запрещено протоколом
      3. Это зависит от типа используемого кабеля
      4. Это зависит от фирмы изготовителя оборудования
    82. Что такое эхоподавление?
      1. Это метод компенсации отражений из-за рассогласования кабелей
      2. Это метод подавления отражений от стен при передаче звукового сигнала
      3. Это способ подавления наводок со стороны соседних проводов при передаче сигнала по многопроводным кабелям
      4. Это метод исключения влияния передачи на прием при работе с одной скрученной парой
    83. Что больше NEXT или FEXT?
      1. Все зависит от типа используемого кабеля
      2. NEXT > FEXT
      3. FEXT > NEXT
      4. Обычно они равны
    84. Зависимость NEXT от частоты передаваемого сигнала
      1. NEXT пропорционально f (частоте)
      2. NEXT пропорционально f 1.5
      3. NEXT пропорционально f 2
      4. NEXT пропорционально logf
    85. Зависимость пропускной способности канала I от ширины полосы пропускания F
      1. I = F log2(1+S/N)
      2. I = F ln(1+S/N)
      3. I = F lg(1+S/N)
      4. I = (S/N)log2F
    86. Как осуществляется синхронизация передатчика и приемника в Ethernet, нужна ли такая синхронизация?
      1. Такая синхронизация не нужна, так как размеры сети не велики
      2. Для синхронизации используется преамбула кадра
      3. Для синхронизации используется стартовый разграничитель кадра
      4. Для целей синхронизации используются все пакеты, которые следуют по сетевому сегменту
    87. Почему оптоволоконные сети часто имеют кольцевую топологию?
      1. Это определяется международным стандартом
      2. Кольцо используется только при реализации схемы маркерного доступа
      3. Это связано с тем, что по волокну можно передавать сигнал только в одном направлении
      4. Кольцевая схема позволяет обеспечить меньшую вероятность ошибки при передаче
    88. Чем отличаются каналы Е1 от Т1?
      1. Е1 - европейское название канала, а Т1 -американское
      2. Е1 имеет большую пропускную способность, чем Т1
      3. Т1 имеет большую пропускную способность, чем Е1
      4. Это два разных названия одного и того же канала
    89. Что такое расстояние Хэмминга?
      1. Это расстояние между узлами Интернет, выраженное в числе канальных сегментов между ними
      2. Это разница длин кодов
      3. Это номер бита, начиная с которого, два кода отличаются друг от друга
      4. Это число бит, которыми отличаются коды равной длины друг от друга
    90. В чем отличие полудуплексного от полнодуплексного каналов в случае сети Ethernet?
      1. Первый требует одну скрученную пару (или оптическое волокно), а второй - две
      2. Первый тип канала обеспечивает почти вдвое меньшую пропускную способность
      3. Во втором типе канала не возможны столкновения
      4. Эти два вида каналов эквивалентны, и в равной мере могут использоваться в сети Ethernet
    91. Что ограничивает теорема Найквиста-Котельникова?
      1. Теорема ограничивает пропускную способность канала в зависимости от уровня шумов
      2. Теорема регламентирует минимальную частоту стробирования в зависимости от спектра входного сигнала
      3. Теорема ограничивает предельно допустимое значение отношения сигнал-шум
      4. Теорема ограничивает предельное значение ослабления сигнала при заданном отношении сигнал-шум
    92. В чем особенности протокола NetBIOS?
      1. Протокола NetBIOS облегчает маршрутизацию в рамках локальной сети
      2. Протокола NetBIOS имеет собственную систему DNS
      3. Символьные имена в протоколе NetBIOS распределяются динамически
      4. Протокол NetBIOS упрощает построение корпоративных сетей с далеко отстоящими субсетями
    93. Для чего используются адаптивные уровни ATM?
      1. Для устранения разброса задержек, выявления ячеек, доставленных не по адресу
      2. Для оптимальной адаптации к требованиям прикладной задачи
      3. Для решения задачи укладки ячеек в виртуальные контейнеры
      4. Для устранения сегментации пакетов и их восстановления, для мониторирования ошибок в управляющей информации
    94. Основные особенности протокола Frame Relay?
      1. Эта сеть может лучше противостоять перегрузкам, чем ISDN или Интернет
      2. Эта сеть обеспечивает меньшие задержки, большую эффективность и пропускную способность, чем ISDN
      3. Эта сеть ориентирована на межсетевые коммуникации
      4. Эта сеть гарантирует пользователю определенную квоту пропускной способности
    95. Особенности структуры и использования виртуальных контейнеров SDH?
      1. Виртуальные контейнеры SDH имеют большие размеры, чем PDH
      2. Более мелкие контейнеры должны занимать предопределенные позиции в более крупных контейнерах, что облегчает разборку их получателем
      3. Иерархия контейнеров требует кратности размеров влагаемых модулей
      4. Более мелкие контейнеры могут размещаться произвольным (плавающим) образом в больших виртуальных контейнерах
    96. Кто уничтожает пакеты в сети FDDI (уничтожаются ли они вообще)?
      1. Пакеты не уничтожаются, а используются повторно
      2. Пакеты уничтожаются специально выделенным узлом (генератором маркеров и уборщиком мусора)
      3. Пакеты уничтожаются получателем
      4. Пакеты уничтожаются отправителем
    97. При каких условиях будет работать такая локальная сеть?

      1. Такая сеть будет работать при любых условиях
      2. Такая сеть может работать, если переключатели SW1 и SW2 правильно сконфигурированы
      3. Такая сеть может работать, если убрать мост BR2
      4. Такая сеть может работать, если сетевые приборы поддерживают протокол "расширяющееся дерево"
    98. Вопросы по курсу "Протоколы и ресурсы Интернет"

      1. Какие запросы должен послать клиент, перед тем как будет установлена связь в рамках протокола TCP?
        1. Запросы DNS и ARP
        2. Всегда можно сразу послать запрос на установление связи
        3. Один запрос ARP
        4. Запросы DNS и 2*ARP
      2. За счет чего можно идентифицировать отправителя сообщения?
        1. Отправителя всегда можно идентифицировать по его IP-адресу, записанному в дейтограмме
        2. Отправитель может быть идентифицирован на фазе авторизации
        3. Отправитель идентифицируется с помощью электронной подписи
        4. Отправитель идентифицируется с помощью его сертификата
      3. Для чего используется регистр CSR?
        1. Этот регистр используется для определения номера порта
        2. Этот регистр определяет направление обмена данными
        3. Регистр задает величину задержки при обработке прерывания в сетевом интерфейсе
        4. Регистр контролирует состояние сетевого интерфейса
      4. Для чего в Интернет введено понятие AS?
        1. AS введено для упорядочения регистрации узлов в Интернет
        2. AS используются для улучшения работы системы DNS-серверов
        3. Без AS не может работать протокол BGP
        4. AS введены для сокращения объема маршрутных таблиц
      5. Какие параметры нужны для конфигурирования драйвера сетевой карты?
        1. Никакие параметры задавать не нужно, все всегда определяется автоматически операционной системой
        2. Задается адрес входной точки драйвера сетевой карты
        3. При конфигурировании драйвера сетевой карты используется значение аппаратного прерывания, логический номер прерывания и блок портов
        4. Задается имя драйвера сетевой карты
      6. Какие задачи решает протокол RTCP?
        1. Этот протокол выполняет для RTP те же функции, что и TCP для обычных процедур в Интернет
        2. RTCP обеспечивает обратную связь для контроля качества при рассылке данных
        3. RTCP служит для передачи управляющей информации
        4. RTCP резервирует сетевые ресурсы для RTP
      7. За счет чего обеспечивается безопасность транзакций в протоколе SET?
        1. Исключительно за счет сертификатов отправителей
        2. За счет электронных подписей отправителей сообщений и шифрования
        3. Главным образом за счет подтверждений корректности операций со стороны партнеров
        4. За счет аутентификации
      8. Почему протокол SSL не может заменить протокол SET?
        1. Эти протоколы не совместимы
        2. SSL не может гарантировать секретности передачи номера кредитной карточки
        3. SSL слишком медленен и не пригоден для интерактивной работы
        4. Методы аутентификации SSL не согласуются с требованиями, налагаемыми на финансовые транзакции
      9. В чем отличие протоколов DVMRP и PIM?
        1. PIM более современный протокол маршрутизации и превосходит DVMRP по всем параметрам
        2. PIM предназначен для работы с рассеянными группами, а DVMRP - c компактными
        3. DVMRP предназначен для резервирования сетевых ресурсов, а PIM - для маршрутизации
        4. DVMRP служит для подключения клиентов к группе, а PIM для целей мониторинга
      10. В чем отличие процедур Ping и Traceroute?
        1. Ping базируется на протоколе ICMP, а Traceroute на определенной опции непосредственно IP-протокола
        2. Это две утилиты базируются на одном и том же протоколе и имеют практически идентичные функции
        3. Эти утилиты базируются на протоколе ICMP, но Ping проверяет доступность узла, а traceroute - маршрут до него
        4. Ping посылает больше пакетов, чем traceroute
      11. Как работает протокол NTP?
        1. NTP служит для получения меток времени от внутренних часов ЭВМ
        2. NTP служит для поддержания первичных эталонов времени
        3. NTP предназначен для калибровки внутренних часов с использованием первичных эталонов
        4. NTP нужен для решения проблем синхронизации и калибровки часов в сети
      12. В чем отличие POP-3 от IMAP?
        1. IMAP просто новая версия POP-3
        2. IMAP обеспечивает более высокий уровень безопасности
        3. IMAP обеспечивает большую скорость пересылки
        4. IMAP предлагает более гибкую систему почтовых ящиков
      13. Какие алгоритмы использует PGP?
        1. В PGP применен алгоритм шифрования DES
        2. В PGP применен алгоритм шифрования RSA
        3. В PGP применена электронная подпись и алгоритм шифрования IDEA
        4. В PGP применен алгоритм шифрования SAFER
      14. Как формируются ключи в алгоритме RSA?
        1. Для получения ключей использован алгоритм Эль-Гамаля (y=gx mod p)
        2. Для получения ключей использован алгоритм Диффи-Хелмана (A = gx mod n
        3. Для шифрования здесь используется формула F(M) = Md mod n
        4. Для получения ключей используется методика вычисления целочисленного логарифма
      15. В чем отличие IPv6 от IPv4 кроме длины адресов?
        1. В IPv6 разрешена мультикастинг-адресация, а в IPv4 - нет.
        2. В IPv6 разрешена эникастинг-адресация
        3. В IPv6 протокол IGMP заменен на ICMP
        4. Для совместимости с IPv4 все функции IPv6 такие же, как и сейчас
      16. Что такое эникастинг-адресация?
        1. Эникастинг-адресация заменила в IPv6 широковещательную адресацию
        2. Эникастинг-адресация является модификацией уникастинг-адресации
        3. Эникастинг-адресация предполагает посылку мультикастинг запроса, при этом адресоваться будет узел, откликнувшийся первым
        4. Эникастинг-адресация это название мультикастинг-адресации в IPv6
      17. Зачем нужна сетевая маска?
        1. Это нужно для организации субсетей
        2. Это необходимо для обеспечения дополнительных мер безопасности
        3. Этим достигается уменьшение количества широковещательных пакетов
        4. Маска используется при шифровании передаваемых данных
      18. Может ли поле версия в пакете IP находится в другом месте и почему?
        1. Это поле может находиться где угодно, лишь бы был известен формат пакета
        2. Поле версия находится всегда в конце пакета, так как это однозначно определяет его положение
        3. Поле версия нужно лишь в случае, когда применяется принудительная маршрутизация, тип опции и определяет положение поля
        4. Поле версия может находиться только в начале пакета
      19. Зачем используется псевдо-заголовок в пакетах UDP?
        1. Псевдозаголовок используется для определенных опций протокола UDP
        2. Псевдозаголовок используется при вычислении контрольной суммы, чтобы контролировать корректность доставки UDP-дейтограмм
        3. Применение псевдозаголовка необязательно (опционно)
        4. Псевдозаголовок служит для уточнения функции дейтограммы
      20. Стандартный номер порта для TCP один, как обеспечивается многопользовательский доступ, ведь сокет в этом случае тоже вроде бы один, а совместное его использование в TCP запрещено?
        1. Для решения проблемы каждый раз берется новый номер порта
        2. Разделение осуществляется по номеру порта и IP-адресу клиента, активизирующего канал
        3. Запросы обслуживаются по очереди
        4. Многопользовательское обслуживание предусмотрено самим протоколом TCP
      21. Как работает иерархия серверов DNS?
        1. Вышестоящие DNS-серверы заранее снабжают исчерпывающей информацией локальный сервер
        2. Локальный DNS, запрашивает вышестоящие DNS, при отсутствии информации. Получив нужные данные, он хранит их и использует при последующих запросах
        3. Если нужной информации не найдено, локальный DNS посылает широковещательный IP-запрос
        4. Если нужной информации не найдено, посылается запрос в IN-addr.ARPA
      22. Как по IP-адресу можно определить имя объекта?
        1. Для этого посылается запрос локальному DNS
        2. Для этого посылается запрос серверу IN-ADDR.ARPA
        3. Для этого посылается запрос в национальный DNS
        4. Этот запрос удовлетворяется региональным или локальным сервером DNS
      23. Причины самопроизвольного размножения DNS запросов
        1. Это может быть вызвано неверной маршрутизацией запросов
        2. Это может быть спровоцировано ошибками в конфигурационных файлах выше стоящих DNS-серверов
        3. Это может быть сопряжено с мультикастинг-запросами
        4. Это может быть вызвано неверным содержанием конфигурационного файла DNS
      24. Причины зацикливания пакетов в локальной сети
        1. В силу особенностей протокола Ethernet это невозможно
        2. Это возможно из-за наличия циклических путей через MAC-мосты и переключатели
        3. Это возможно в случае использования протокола IGRP при значении вариации > 1
        4. Это возможно при использовании протокола RIP
      25. Причины зацикливания пакетов в региональной сети
        1. Наличие циклического пути
        2. Использование маршрутов по умолчанию
        3. Неверный выбор параметров внешнего протокола маршрутизации
        4. Осцилляция маршрутов
      26. Почему время установления маршрута для протокола RIP обычно больше, чем для OSPF или IGRP?
        1. На самом деле установление маршрута в RIP быстрее (алгоритм проще)
        2. Это происходит из-за больших постоянных времени заложенных в протоколе RIP
        3. Сказывается специфика метрики, используемой в протоколах
        4. Установление маршрута в RIP занимает несколько циклов обновления пока метрика не достигнет значения 15
      27. Всегда ли в маршрутизаторе используется только одна маршрутная таблица?
        1. Всегда одна
        2. Число маршрутных таблиц равно числу значений QOS
        3. Число маршрутных таблиц зависит от выбранного значения TTL
        4. Число таблиц определяет сетевой администратор при инсталляции
      28. Сколько протоколов маршрутизации при пересылке в режиме уникастинга может активно поддерживать маршрутизатор?
        1. Один
        2. Два
        3. Три
        4. Сколько угодно, зависит от модели маршрутизатора
      29. Если удвоить максимально возможное значение метрики RIP, переходные процессы установления маршрута:
        1. Удлинятся
        2. Не изменятся
        3. Станут короче
        4. Это зависит от четности метрики
      30. Чем отличается RIP от RIP-II? (в чем преимущества одного перед другим?)
        1. В RIP-II переходные процессы установления маршрута происходят быстрее
        2. RIP-II поддерживает использование субсетей, а RIP нет
        3. В RIP-II возможен больший диапазон значений метрики
        4. RIP-II может работать с адресами IPv6
      31. Что общего и в чем отличия протоколов OSPF и IGRP?
        1. Это несопоставимые протоколы
        2. OSPF использует всю маршрутную информацию о всей сети, а IGRP - только информацию от ближайших соседей
        3. OSPF может распараллеливать потоки данных, а IGRP нет
        4. В OSPF метрика задается администратором, а в IGRP вычисляется независимо
      32. Как задается метрика в протоколах маршрутизации RIP, OSPF, IGRP.
        1. Все эти протоколы используют маршрутизацию, базирующуюся на векторе расстояния
        2. В этих протоколах метрика задается администратором сети
        3. В протоколах OSPF и IGRP метрика вычисляется на основе измерений свойств каналов, а в RIP определяется числом шагов до адресата
        4. В протоколе OSPF метрику задает администратор, а в IGRP она вычисляется маршрутизатором
      33. Причины осцилляции маршрутов и способы их устранения
        1. Осцилляции маршрутов возможны при наличии циклических маршрутов из-за образования обратной связи
        2. Осцилляции маршрутов возможны только при использовании маршрутов по умолчанию
        3. Причиной осцилляции является медленное распространение информации об изменениях маршрутов
        4. Осцилляции маршрутов возможны при использовании определенных типов маршрутизаторов
      34. Что может являться причиной того, что пакет от точки А к точке Б движется по одному маршруту, а обратно - по другому?
        1. Применен IP-туннель
        2. Не верно задана метрика маршрутов
        3. Ошибочно сконфигурирован DNS-сервер
        4. Не верно описана маршрутная политика
      35. Какую информацию может вернуть ARP-запрос в различных ситуациях?
        1. ARP-запрос всегда возвращает MAC-адрес, соответствующий IP-адресу
        2. Результат зависит от конфигурации DNS-сервера
        3. При определенных условиях может быть возвращен MAC-адрес Gateway
        4. При определенных условиях может быть возвращен адрес DNS-сервера
      36. Методы атак против протокола TCP
        1. Атака возможна только в случае, если атакующая машина находится на пути от клиента к серверу
        2. Возможна атака за счет сбоя ISN-нумерации пакетов
        3. Возможна атака с помощью фальсификации CRC
        4. Атаки на TCP-уровне невозможны. Если бы это было не так, стали бы возможны атаки практически на любые процедуры Интернет, ведь практически все они базируются на протоколе TCP
      37. Атаки против протокола HTTP
        1. Возможна атака сразу после перехода сервера на технологию IPv6
        2. Возможна атака с помощью имитации хакером работы в качестве сервера
        3. Возможна атака с помощью создания ложного DNS
        4. Возможна атака путем искусcтвенного понижения уровня аутентификации
      38. Сопоставить протоколы UDP и TCP
        1. UDP устаревший протокол и он везде, где только возможно, должен быть заменен TCP, который обеспечивает гарантированную доставку
        2. UDP имеет меньшую избыточность по заголовку и по этой причине должен применяться везде, где только возможно
        3. Каждый из этих протоколов имеет строго очерченную область применения (UDP - загрузка Х-терминалов, SNMP и т.д., а TCP - FTP, HTTP и пр.)
        4. UDP используется в локальных сетях и для мультимедиа, а TCP (в основном в региональных) для информационного обмена, где требуется высокая надежность доставки
      39. В чем принципиальное отличие традиционных протоколов маршрутизации и мультикастинговых?
        1. В традиционном методе маршрут прокладывается от отправителя к получателю, а при мультикатинге наоборот.
        2. Никакого отличия нет, уникастные и мультикастные пакеты маршрутизируются одинаково c использованием стандартных протоколов
        3. Маршрут оптимизируется для группы участников мультикастинга
        4. Для решения задач мультикастинга используются специальные маршрутизаторы и поэтому здесь нечего сравнивать.
      40. Почему в IPv6 выбрана длина адреса в 4 длиннее, чем в IPv4?
        1. Это сделано для того, чтобы раз и навсегда решить проблему дефицита IP-адресов
        2. Это сделано, чтобы разрешить эникастинг
        3. Это сделано для расширения возможного списка предоставляемых услуг
        4. Это сделано для того, чтобы облегчить переход от IPv4 к IPv6 и упростить маршрутизацию
      41. Почему для мультимедиа используется протокол UDP, а не TCP?
        1. Это связано с меньшими издержками протокола UDP (компактнее заголовок дейтограммы)
        2. Техника применения TCP для этих целей пока не разработана
        3. Для протокола UDP легче реализовать маршрутизацию
        4. Повторная пересылка пакетов в TCP не приемлема для целей мультимедиа
      42. Обосновать особенности протоколов маршрутизации, использующих вектор расстояния.
        1. Медленные переходные процессы установления маршрута при изменении обстановки
        2. Быстрые переходные процессы установления маршрута при изменении обстановки
        3. Ограниченное максимальное значение метрики
        4. Возможность зацикливания пакетов
      43. Зачем нужен протокол RARP?
        1. Для организации мультимедийного обмена
        2. Для определения имени бездисковых рабочих станций
        3. Для определения IP-адреса бездисковых рабочих станций
        4. Для загрузки бездисковых рабочих станций
      44. Для чего служит протокол BOOTP?
        1. Для организации видеоконференций
        2. Для загрузки Х-терминалов
        3. Для инициализации локальной субсети
        4. Для управления подключением к мультикастинг-группам
      45. Зачем нужен протокол RTP, какие дополнительные преимущества он предоставляет приложению?
        1. Этот протокол обеспечивает надежную доставку мультимедийных данных
        2. В RTP имеется система задания приоритетов, что позволяет эффективно резервировать ресурсы для мультимедийной сессии
        3. RTP несет в себе временные метки и за счет этого достигается лучшее качество воспроизведения звука и изображения
        4. В RTP предусмотрены удобные средства для облегчения маршрутизации мультимедийных данных
      46. Причины возникновения циклов сообщений в RSVP.
        1. Первопричиной циклов могут стать сообщения PATH
        2. Вызвать зацикливание может сообщение ResvErr
        3. Привести к зацикливанию может посылка сообщения RESV
        4. Вызвать зацикливание может сообщение PathErr
      47. Что такое валидатор?
        1. Валидатор представляет собой характеристику документа, обеспечивающую его безошибочную доставку
        2. Валидатор используется для определения того, разрешен ли данному пользователю доступ к данному документу
        3. Валидатор служит для контроля модификации документов
        4. Валидатор используется в протоколе RSVP для уведомления успешного резервирования ресурса
      48. Как реализуется механизм резервирования ресурсов и QOS в TCP/IP?
        1. Рассылаются сообщения администраторам сети, с тем, чтобы они учли ваши требования
        2. Используются соответствующие опции протокола IP
        3. Используются соответствующие опции протокола ICMP
        4. Используются служебные биты заголовка пакетов TCP
      49. Как работает протокол POP-3?
        1. Как обычный почтовый протокол
        2. POP-3 просто один из графических интерфейсов для работы с первичным почтовым сервером
        3. В результате диалога POP-3 забирает сообщения из почтового ящика пользователя и предоставляет их адресату
        4. POP-3 почтовый протокол, который призван в перспективе заменить SMTP
      50. В чем отличие почтовых систем, базирующихся на UUCP и SMTP?
        1. UUCP использует в качестве транспортного протокол UDP, а SMTP - TCP
        2. UUCP работает на ЭВМ с UNIX, а SMTP - на любых машинах
        3. UUCP является более современной версией SMTP
        4. SMTP - почтовый протокол Интернет, а UUCP команда UNIX
      51. Зачем придумали MIME?
        1. Этот протокол разработан исключительно для передачи мультимедийных данных
        2. Этот протокол служит для расширения возможности SMTP при работе с различными наборами символов
        3. Этот протокол используется для передачи новостей
        4. Этот протокол имеет целью расширение возможностей протокола HTTP
      52. Если один из узлов поддерживает MIME, а другой нет, как они об этом узнают и как будут взаимодействовать?
        1. Для решения проблемы должны быть посланы запросы к серверу DNS (чтение ресурсных записей)
        2. Все должно быть оговорено на фазе конфигурирования рабочей станции
        3. Поддержка MIME определяется по соответствующему полю в заголовке пакета, инициализирующего соединение по порту 25
        4. Используется стандартная последовательность команд протокола SMTP
      53. Как работает протокол HTTP, какая программа сложнее - сервера или клиента и почему?
        1. Сложнее программа сервера, ведь он обслуживает большое число запросов одновременно
        2. Сложнее программа клиента, именно она выполняет львиную долю работы
        3. Эти две программы идентичны и функционально могут меняться местами
        4. Программа сервера сложнее, так как ей приходится адаптировать форматы данных по запросу клиента (графики, звука и пр.) перед их передачей
      54. Почему протокол HTTP одержал победу над протоколом GOPHER?
        1. Это произошло потому, что HTTP предоставляет более удобный графический интерфейс
        2. HTTP запоминает маршрут поиска и позволяет продолжить его позднее с прерванного места, а GOPHER - нет
        3. HTTP позволяет осуществлять поиск вдоль дерева ссылок, а GOPHER - нет
        4. HTTP позволяет создавать прокси-сервера
      55. Можно ли передавать произвольную пользовательскую информацию с помощью протокола ICMP?
        1. Можно, для этого только нужно написать специальную программу
        2. Нельзя, так как протокол предназначен исключительно для диагностических целей.
        3. Нельзя, так как в случае необходимости фрагментации, выполнить ее будет нельзя (она реализуется только для пакетов UDP и TCP)
        4. Нельзя, так как ICMP имеет слишком низкий приоритет при прохождении маршрутизаторов
      56. В локальной сети машины передают информацию со скоростью 10 Мбит/с (или даже 100 Мбит/с), внешний канал сети имеет полосу в 1Мбит/с. Как эти скорости обмена согласуются на протокольном уровне?
        1. Эта проблема решается заданием соответствующих параметров в Gateway/маршрутизаторе
        2. Для согласования применяется протокол SNMP
        3. Согласование осуществляется с использованием протокола ICMP
        4. Проблема решается с помощью задания соответствующих флагов в пакетах TCP и параметров этого протокола
      57. Почему для непосредственной передачи данных не используется IP-протокол (зачем-то используют TCP или UDP, а ведь это увеличивает протокольные издержки и снижает пропускную способность)?
        1. Это задано 7-уровневой моделью и по этой причине надо выполнять данные регламентации
        2. Это нужно, чтобы обеспечить каналы с установлением и без установления связи
        3. Это имеет исключительно исторические причины
        4. Это сделано для обеспечения работы IP-протокола с мультимедийными данными
      58. Как осуществляется управление внешним протоколом маршрутизации BGP-4?
        1. Задаются параметры при конфигурации системы
        2. Используется протокол SNMP и база данных MIB
        3. Управление осуществляется по специально выделенному последовательному каналу
        4. Для решения задачи управления используется описание маршрутной политики и соответствующие базы данных RIB
      59. Какими маршрутами управляет протокол BGP-4?
        1. Исходящими из LAN в Интернет
        2. Завершающимися в LAN
        3. Транзитными, идущими через LAN
        4. Любыми выше перечисленными маршрутами
      60. Если существуют два соседних маршрутизатора, один из них поддерживает протокол BGP-3, а другой - BGP-4, как они будут взаимодействовать друг с другом?
        1. Будет выбран BGP-3
        2. Будет выбран BGP-4
        3. Будет выбран какой-то другой протокол, например OSPF, если они оба его поддерживают
        4. Будут поменяны параметры BGP-4, так чтобы он мог работать с партнером, поддерживающим BGP-3
      61. Почему маршрутизатор работает как правило быстрее, чем программа с аналогичной функцией в быстродействующей ЭВМ?
        1. Программа в маршрутизаторе лучше оптимизирована
        2. В маршрутизаторе применяется очень быстродействующий процессор
        3. В маршрутизаторе часть процедур выполняется на аппаратном уровне
        4. В маршрутизаторе используется более быстродействующая память
      62. В чем преимущества и недостатки подключение внешних клиентов к локальной сети через последовательный канал и бридж (напр., радиобридж) при условии равной пропускной способности?
        1. Последовательный канал предоставляет удобные средства управления пропускной способностью, а бридж - нет.
        2. Бридж предпочтительнее, так как он исключает паразитный транзитный трафик (например, мультикастинг)
        3. Это два совершенно идентичные во всех отношениях решения
        4. Последовательный канал предпочтительнее, когда подключается коммерческий клиент, так как легче измерить трафик
      63. Как работает протокол Finger?
        1. Finger устанавливает связь с объектом, после чего посылает пакет с форматом заголовка Finger, содержащим запрос
        2. Finger получает нужную информацию, исполняя процедуру EXPN на ЭВМ адресата запроса
        3. Finger базируется на процедуре REXEC
        4. Finger обеспечивает интерфейс для удаленной программы пользователя RUIP
      64. В чем может быть причина того, что после инсталляции сети ваши почтовые сообщения уходят, а посылаемые вам сообщения пропадают?
        1. Неверно прописан IP-адрес вашего mail-сервера
        2. Ошибка в конфигурации DNS
        3. Ваш локальный почтовый сервер не известен региональному серверу
        4. Неправильно сконфигурирован маршрутизатор или Gateway
      65. Откуда DNS узнает адреса других серверов имен?
        1. Из своих конфигурационных файлов
        2. Из откликов на свои широковещательные запросы
        3. Из информации других DNS, рассылаемой периодически
        4. Из данных, введенных администратором при инсталляции
      66. В чем отличие протоколов FTP от Telnet (с точки зрения алгоритма их работы)?
        1. FTP использует Telnet для формирования командного канала
        2. FTP не имеет ничего общего с Telnet, так как этот протокол служит для пересылки файлов, а telnet - для удаленного доступа
        3. FTP и Telnet используют разные транспортные протоколы
        4. В этих протоколах используются разные схемы контрольного суммирования
      67. Зачем нужен протокол TFTP (ведь он представляет собой потенциальную угрозу сетевой безопасности)?
        1. Это устаревший протокол, который не используется в настоящее время
        2. Этот протокол служит лишь для тестирования каналов и локальной сети
        3. Протокол используется для пересылки картинок WEB-броузерами
        4. Этот протокол используется для загрузки Х-терминалов и для получения файлов-приложений при отправке электронной почты
      68. Что делает поисковая система, когда не поступает запросов поиска информации?
        1. Через какое-то время отключается и впадает в "спячку", откуда она выходит при поступлении первого запроса
        2. Система занимается индексированием файлов
        3. Система ищет новые серверы
        4. Система перепроверяет корректность имеющихся у нее данных
      69. Что такое анонимное FTP?
        1. Это FTP, когда клиент не хочет, чтобы он был идентифицирован файл-сервером
        2. Это режим файлового обмена, когда клиент организует обмен между двумя узами, отличными от его собственного
        3. Это FTP, когда имя клиента равно anonymous
        4. Это обмен, когда клиент не задает имени пересылаемого файла
      70. Как можно устранить повторные ссылки на один и тот же документ в перечне, предлагаемом в качестве результата работы поисковой системы?
        1. Надо каждый документ, помещаемый в депозитарий любого сервера снабдить уникальным идентификатором
        2. Надо повторить запрос, видоизменив его так, чтобы повторных ссылок не было
        3. Надо послать запрос поисковой системе, чтобы она убрала повторные ссылки из своего индекса
        4. Можно запустить программу фильтрации для совокупности полученных ссылок
      71. Можно ли отправить почтовое сообщение, не имея акаунтинга ни на одном из почтовых серверов?
        1. Это невозможно
        2. Это можно реализовать с помощью одной из опций протокола ICMP
        3. Это возможно через HTTP и порт 80
        4. Это можно сделать, используя процедуру telnet и порт 25
      72. В чем назначение протокола ICMP в условиях сильно загруженного виртуального канала?
        1. Протокол служит для сообщений о потере пакетов
        2. Протокол используется для измерения RTT и оптимизации параметров пересылки
        3. Протокол служит для контроля процента потерь пакетов и оптимального выбора маршрута передачи (выбор в случае примерно равных метрик маршрутов)
        4. Протокол используется для понижения средней частоты посылки пакетов
      73. Уязвимые точки почтового протокола SMTP
        1. Возможность отправки сообщения без акаунтинга и почтового ящика на каком-либо почтовом сервере
        2. Возможность получения частной информации с помощью команд VRFY и EXPN
        3. Нельзя шифровать передаваемые сообщения
        4. Не гарантируется доставка сообщения
      74. Как влияет размер окна (например, в TCP или ISDN) на пропускную способность канала?
        1. Чем шире окно, тем выше пропускная способность
        2. Чем шире окно, тем меньше пропускная способность
        3. Влияние размера окна проявляется по-разному в различных протоколах
        4. Всегда существует оптимальный размер окна
      75. Почему спутниковый и наземный канал с идентичными быстродействиями обеспечат разную пропускную способность при работе с TCP?
        1. Спутниковый канал обеспечит большую пропускную способность из-за лучшего отношения сигнал-шум
        2. Спутниковый канал имеет меньшую пропускную способность из-за большого RTT и ограничений по window
        3. Эти оба варианта эквивалентны, так как использует один и тот же стек протоколов
        4. Спутниковый канал лучше адаптируется к изменениям условий и по этому в среднем обеспечивает большую широкополосность
      76. Что такое алгоритм медленного старта?
        1. Он определяет процедуру формирования виртуального канала в протоколе TCP
        2. Это алгоритм определяет процедуру вычисления значений таймаутов
        3. Это алгоритм определяет установление правильного значения window после потри пакета
        4. Он задает процедуры прерывания при возникновении оговоренного сетевого события
      77. Почему пропускная способность канала при работе с TCP и 5% потерь пакетов может упасть вдвое?
        1. Это зависит от используемого маршрутизатора
        2. Это происходит при использовании фрагментации пакетов
        3. Это происходит при больших значениях RTT
        4. Это связано с процедурой "медленного старта" и повторными пересылками
      78. Почему протокол TCP обычно не используется для передачи мультимедийных данных?
        1. TCP не используется для этих целей из-за дороговизны
        2. Из-за требований реального времени TCP создает чрезмерные издержки благодаря большому размеру заголовков
        3. TCP не приемлемо из-за возможности "медленного старта"
        4. Это бессмысленно, так как задержанная доставка ничего хорошего не даст
      79. Методы улучшения эксплуатационных характеристик протокола TCP
        1. Правильно выбрать значение TTL
        2. Оптимизировать алгоритм вычисления RTT и его дисперсии
        3. Заменить TCP на XTP или другой аналогичный протокол
        4. Использование группового подтверждения
      80. Для чего нужно TTL при передаче мультимедийных данных?
        1. Нужно, чтобы правильно задать значения тайм-аутов
        2. TTL используется при конфигурации протоколов маршрутизации (напр. PIM)
        3. TTL здесь нужно, чтобы ограничить зону распространения мультимедийных данных
        4. TTL нужно для того, чтобы блокировать зацикливание пакетов при адресных ошибках
      81. Для чего используется TTL?
        1. Для задания масштаба RTT
        2. Для определения времени хранения почтовых сообщений в буфере
        3. Для определения времени жизни информации в DNS-кэше
        4. Для ограничения зоны распространения мультикастинг-информации
      82. Для чего используется прокси-ARP?
        1. Это версия ARP, используемая с прокси-серверами
        2. Используется для выявления IP-адреса для бездисковых рабочих станций (Х-терминалов)
        3. Версия протокола для разрешения адресных проблем при мультикастинге
        4. Это версия протокола ARP для построения корпоративных сетей содержащих разбросанные субсети
      83. Как будут взаимодействовать две рядом стоящие машины (общий сетевой сегмент), если у них IP-адреса из разных блоков С-класса?
        1. Непосредственно. Пошлют ARP-запросы, получат соответствующие MAC-адреса друг друга и начнут обмен
        2. Схема взаимодействия зависит от значений сетевых масок
        3. Схема взаимодействия зависит от содержимого ARP-кэша
        4. Будут вести обмен через ближайший Gateway
      84. Как влияет значение и точность измерения RTT и его дисперсии на эффективную работу канала?
        1. Чем больше RTT, тем лучше
        2. Никак не влияет
        3. Чем точнее измерения этих параметров, тем выше пропускная способность
        4. Чем меньше RTT, тем больше пропускная способность
      85. Может ли использоваться протокол SNMP для контроля потока с одного конкретного IP-адреса на другой? Можно ли организовать аналогичный контроль с учетом номера порта?
        1. Нет, нельзя
        2. Можно, если использовать маршрутизатор
        3. Можно, если использовать модель переключателя, поддерживающую SNMP и подключенного к сегменту, где среди прочих стоит исследуемая станция
        4. Можно, если переключатель, к которому среди прочих подключена данная ЭВМ, поддерживает VLAN
      86. Зачем в пакетах SNMP используется поле community?
        1. Для объединения фрагментов MIB в единое целое
        2. Поле community предназначено для формирование пользователей, запрашивающих идентичную информацию, в группы
        3. Поле community используется для выбора определенной версии MIB
        4. Поле выполняет функцию пароля
      87. Как обновляется содержимое прокси-сервера?
        1. Обновление содержимого происходит при каждом запросе клиента
        2. Обновление осуществляется при несовпадение валидаторов записи в кэше и объекта исходного сервера
        3. Обновление происходит при запросе объекта, который отсутствует в кэше
        4. Обновление записи происходит при истечение ее срока годности
      88. Что такое метод в HTTP?
        1. Метод определяет способ установления связи между клиентом и прокси или между прокси и исходным сервером
        2. Метод - это процедура GET реализуемая по требованию клиента
        3. Метод определяет схему обновления содержимого прокси-сервера
        4. Метод определяет процедуру, выполняемую для выбранного ресурса
      89. Почему использование IP-туннеля может породить асимметричность путей пакета и отклика на этот пакет?
        1. Асимметричность путей может возникнуть из-за разной маршрутной политики маршрутизаторов, находящихся в начале и в конце туннеля
        2. При правильной конфигурации туннеля асимметричности путей не возникнет
        3. Асимметричность пути туда и обратно невозможна, так как этому воспрепятствуют маршрутизаторы
        4. Асимметричность путей возможна, так как маршрут задается адресом места назначения, а этот адрес разный на пути к адресату и на пути к концу туннеля
      90. Базовые методы обеспечения безопасности WWW-серверов
        1. Шифрование адреса места назначения
        2. Шифрование имени сервера
        3. Применение протокола SSH
        4. Применение сертификатов для идентификации пользователя и протокола SSL
      91. В чем отличие протоколов безопасности SSH, SET и SSL?
        1. Протоколы SSH, SET и SSL служат для целей обеспечения безопасности при удаленном доступе для разных операционных сред
        2. Протокол SET служит для организации торговли в Интернет, SSH для безопасного удаленного доступа, а SSL - для безопасного доступа к WWW
        3. SSH допускает использование сертификатов, а остальные нет
        4. SET позволяет однозначно идентифицировать отправителя, а SSL и SSH - нет
      92. В чем заключаются принципы маршрутной политики?
        1. Маршрутная политика определяет региональные принципы взаимодействия системы маршрутизаторов
        2. Маршрутная политика определяет взаимосогласованные подходы администраторов автономных систем к проблемам маршрутизации
        3. Маршрутная политика - синоним маршрутизации
        4. Маршрутная политика определяет, какую маршрутную информацию маршрутизатор воспринимает, какую рассылает, как на основании имеющихся данных формируются маршрутные таблицы
      93. Могут ли локальные сети разных, удаленных друг от друга организаций принадлежать одной автономной системе?
        1. Нет, не могут
        2. Могут, если имеют общую администрацию
        3. Могут, если имеют одного сервис провайдера
        4. Могут, если проводят идентичную маршрутную политику
      94. Как система узнает, что клиент покинул группу (IGMP)?
        1. Клиент уведомляет непосредственно отправителя информации перед выходом из группы
        2. Клиент уведомляет локальный Gateway перед выходом из группы
        3. Клиент сообщает всем членам группы о выходе
        4. Клиент просто не подтверждает свое членство в группе
      95. Как реализуется функция IGMP в рамках протокола IPv6?
        1. IGMP входит в стек TCP/IP и его функции в IPv6 остаются неизменными
        2. В IPv6 его функции выполняет протокол SNMP
        3. В IPv6 его функции выполняет протокол ICMP
        4. В IPv6 его функции выполняет протокол RSVP
      96. Какие утилиты используются при поиске людей и узлов, на каких протоколах они базируются?
        1. Этой цели служит протокол NNTP
        2. Этой цели служит протокол Finger
        3. Этой цели служит протокол DNS
        4. Этой цели служит протокол SMTP
      97. В чем особенности работы службы новостей?
        1. Протокол NNTP аналогичен другим протоколам стека TCP/IP, имеет свой формат пакетов и прочие атрибуты
        2. Протокол работает с использованием сообщений-откликов
        3. Протокол работает с использованием протокола UDP
        4. Система новостей базируется на протоколе SMTP
      98. Как определяется степень соответствия документа запросу (релевантность) в системах информационного поиска?
        1. Это делается по значению идентификатора документа, присваиваемому ему в процессе индексации
        2. Это делается по числу ключевых слов из запроса, присутствующих в документе
        3. Это делается в соответствии с величиной W = log(N/n)+1, где N - число документов, а n - число документов, где встречается данное ключевое слово
        4. Это делается в соответствии с величиной (Nзн 2)/Nс, где Nзн - число ключевых слов в документе, а Nс - полное число слов
      99. Как работают подписные листы (LISTSERV)? (принцип работы, возможности, предоставляемые пользователю)
        1. Подписные листы служат для получения информации по заданной тематике, система работает так же, как система рассылки новостей
        2. Подписные листы формируются администратором и позволяют рассылать сообщения всем, кому хочет администратор
        3. Подписной лист может иметь встроенную базу данных для хранения текстов и программ
        4. Подписные листы формируются самими участниками
      100. В чем отличие X-Windows от Windows-NT?
        1. Windows-NT - операционная система, а X-Windows система клиент-сервер
        2. X-Windows работает под UNIX, а Windows-NT - нет
        3. Отличия относятся исключительно к сфере приложений
        4. Windows-NT обеспечивает несравненно лучшую сетевую безопасность

    Previous: 8 Заключение    UP: 8 Заключение
    Down: 9 Литература    Next: 9 Литература


    previous up down next index index
    Previous: 7.2 Сетевые драйверы    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 9 Литература
        Next: 8.1 Вопросы по данному курсу

    8 Заключение
    Семенов Ю.А. (ГНЦ ИТЭФ)

    Автор признателен читателю, который прочел эти тексты до конца. Надеюсь, что это было не самое скучное и бесполезное занятие. Я являюсь свидетелем и участником развития Интернет в России с самого его начала и это внушает самые оптимистические надежды. В стране, где главным жизненным увлечением заметной части населения является воровство (во всяком случае для той ее части, которая имеет возможность и определенные способности), появление дорогостоящей общенациональной сети при полном отсутствии поддержки со стороны правительства (по крайней мере на начальном этапе) можно считать чудом двадцатого века. Причины этого явления еще предстоит понять и объяснить.

    Существующая система Internet неидеальна, в ней не мало недостатков больших и малых. Наиболее серьезные трудности связаны с проблемой маршрутизации, не существует механизма выравнивания загрузки каналов в рамках внешних протоколов, механизмы управления не всегда удобны и безопасны, диагностика не совершенна. Система адресации Internet архаична и уже готов новый стандарт (расширение разрядности адресов до 128), многие сервисные услуги неудобны, например, не производится предупреждения об отключении связи при пассивности пользователя, telnet не имеет возможностей непосредственного копирования удаленных файлов, поисковые системы не всегда позволяют найти то, что нужно, если эта информация имеется и т.д. и пр. Но именно это должно привлечь новых молодых людей (возможно и из России), которые усовершенствуют систему. Ничто не идеально в этом мире, ведь совершенство означает прекращение развития и, следовательно, неизбежную гибель. Internet жив, возможно его идеи поменяют жизнь людей не меньше, чем это сделало радио или телевидение. Ведь именно Интернету мы обязаны появлением электронных журналов, всемирных дискуссионных клубов по интересам, глобальных баз данных, IP-телефонии, видеоконференций и прочих удивительных вещей, именно электронная почта помогла распространять правдивую информацию в незабвенные августовские дни 1991 года. Таким образом, телекоммуникационные сети могут стать гарантом демократии, можно блокировать телевидение и прессу, но чтобы остановить электронную почту, нужно выключить телефонную сеть по всей стране.

    Попробую сделать некоторые конкретные прогнозы в этой области на будущее. Меня на это подталкивает стоящая у меня дома на полке книга "Космическая эра. Прогнозы на 2001 год" (Москва, "Мир", 1970), которая является переводом книги "Space Ege in Fiscal Year 2001", 1966. В этой книге дан прогноз развития науки и технологии до 2001-го года. Прогнозы этой книги в области космоса оказались чересчур оптимистичными (обитаемые станции на Луне, полеты человека к Марсу, коммерция в космосе и т.д.). Удивительно, что во время написания этой книги люди уже разрабатывали и испытывали технологии, которые легли в основу Интернет. Привожу цитату из этой книги:

    "Устройства графической и буквенно-цифровой индикации будут использоваться не только как средство взаимодействия человека с машиной, но, по-видимому, с помощью таких быстродействующих устройств можно будет также осуществлять и связь между людьми".

    За более чем 34 года сделан совершенно точный прогноз относительно цифровых телекоммуникаций. Полагаю, прогресс в этой области даже превзошел то, что себе представляли авторы этой книги. Я не решаюсь сделать столь далекие предсказания (это написано в 1998 году и я не намерен изменять что-либо в будущем).

    1. К 2002 году появятся первые гибриды ЭВМ и телевизора, а к 2005 эти приборы станут массовыми.
    2. В 2010 году в России во многих городах будут созданы общегородские сети кабельного цифрового телевидения с доступом к Интернет из любого дома, будут заложены основы общенациональной сети. Традиционная подписка на газеты и журналы будет заменена подпиской на отдельные статьи по вашему выбору (зачем оплачивать то, что вам не интересно, печатать и перевозить никому ненужную бумагу, да и сохранение лесов неплохой аргумент для этого) с возможностью чтения на экране телевизора и распечаткой при необходимости на принтере.

    3. К 2010 году будут созданы электронные книги - переносные устройства для чтения текстов, записанных на CD, с возможностью звукового, а со временем и полномасштабного мультимедийного воспроизведения. Будет возможен и сетевой доступ к библиотекам.

    4. К 2020 году будет создана всемирная информационная сеть, базирующаяся на широкополосных оптоволоконных каналах (телевидение, новости в аудио и видео форматах, полный информационный сервис). Россия здесь задержится на 5-10 лет из-за нынешнего провала в сфере образования.

    5. К 2010 телефонные магнитные карты будут снабжены индивидуальными характеристиками голоса клиента, которые будут передаваться принимающей стороне при вызове. Процессор в телефонном аппарате будет преобразовывать голос в символьную последовательность (в текст). Это позволит передавать по каналу только текст, индивидуальность голосу будет придаваться на принимающей стороне при синтезе, что сократит на порядок требования к полосе канала.

    Время покажет, был ли я пессимистом или оптимистом. В том, что все это будет, я уверен, могу ошибаться только в сроках. Предпосылками для этого должны стать снижение цен на отоволоконные кабели, принтеры и терминальное оборудование, разработки дешевых специализированных интегральных схем, часть из которых уже имеется, другие разрабатываются сегодня; аппаратные устройства сжатия информации и много другое. Создание широкой информационной сети с доступом в каждый дом породит немало новых проблем. Это прежде всего обеспечение защиты частной информации, предотвращение вторжения в личную жизнь. Огромную работу здесь предстоит выполнить программистам. Это и разработка более эффективных алгоритмов сжатия данных, шифрования/дешифрования информации, новых протоколов передачи, удобных пользовательских интерфейсов, более совершенных распределенных баз данных и поисковых систем. Буду счастлив, если среди людей, кто внесет свой вклад в это общее дело, окажутся и читатели этой книги. В следующем веке сети предоставят много новых рабочих мест для граждан планеты Земля. Желаю гражданам всемирного государства Интернет новых успехов и приятных приключений.

    Previous: 7.2 Сетевые драйверы    UP: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Down: 9 Литература    Next: 8.1 Вопросы по данному курсу


    previous up down next index index
    Previous: 8.1 Вопросы по данному курсу    UP: 8 Заключение
    Down: 10 Приложения
        Next: 10 Приложения

    9 Литература
    Семенов Ю.А. (ГНЦ ИТЭФ)

    literat

    1.

    Ю. В. Прохоров, Ю. А. Розанов. Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы. Наука, Глав. Ред. Физмат литературы, М. 1967, серия "Справочная математическая библиотека".

    2.

    Guide to Network Resource Tools. EARN Association, Sept. 15, 1993, V2.0. (ISBN 2- 910286-03-7).

    3.

    Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Englewood Cliffs, N.J. 07632, 1988

    4.

    Uyless Black, TCP/IP and Related Protocols, McGraw-Hill, Inc, New York. 1992

    5.

    Feinler, E., et al, DDN Protocol Handbook, DDN Network Information Center, SRI International, Ravenswood Avenue, Menlow Park, California, USA, 1985

    6.

    Spider Systems, Ltd., "Packets and Protocols", Stanwell Street, Edinburgh, UK. EH6 5NG, 1990.

    7.

    Tony Bates, et al, "Representation of IP Routing Polices in a Routing Registry" (RIPE-181.txt, October 1994)

    8.

    A. N. Bobyshev, S. I. Burov, M. Ernst, A. I. Kravtsov, A. O. Saphonov, Yu. A. Semenov "ITEPNET to Internet communication", ITEP III92.

    9.

    Robert J. T. Morris "Neural Network Control of Communications Systems" IEEE Transactions on Neural Networks, Vol. 5, No. 4, July 1944.

    10.

    Paul J. Fortier, Handbook of LAN Technology. 2-nd Edition, McGraw-Hill, 1992

    11.

    W.Richard Stevens "TCP/IP Illustrated", Addison-Wesley Publishing Company, 1994.

    12.

    Matthew Flint Arnett, Mike Coulombe, et al. Inside TCP/IP, Second Edition, New Riders Publishing, 1995

    13.

    Лаура Ф. Чаппелл и Дэн Е. Хейкс. Анализатор локальных сетей NetWare (Руководство Novell), Москва, Изд. "ЛОРИ", 1995.

    14.

    А. В. Фролов и Г. В. Фролов, Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS, Москва, "Диалог-МИФИ", 1993

    15.

    К. Джамса, К. Коуп, Программирование для INTERNET в среде Windows, Санкт-Петербург, "ПИТЕР", 1996.

    16.

    ISDN How to get a high-speed connection to the Internet, Charles Summers, Bryant Dunetz, "John Wiley @ Sons, Inc."

    17.

    ISDN Explained, Worldwide Network and Applications Technology, 2 edition, John M. Griffiths, John Wiley & sons.

    18.

    ISDN. Цифровая сеть с интеграцией служб. Понятия, методы, системы. П. Боккер, Москва, Радио и связь, 1991.

    19.

    С. Вильховченко, Модем 96. Выбор, настройка и использование. Москва, ABF, 1995.

    20.

    Справочник "Протоколы информационно-вычислительных сетей". Под ред. И. А. Мизина и А. П. Кулешова, Радио и связь, Москва 1990.

    21.

    Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Englewood Cliffs, N.J. 07632, 1988

    22.

    Craig Hunt, TCP/IP Network Administration, O'Reilly Associates, Inc., Sebastopol, USA, 1992

    23.

    А. В. Фролов и Г.В. Фролов, Модемы и факс-модемы. Программирование для MS-DOS и Windows. Москва, "Диалог-МИФИ", 1995.

    24.

    Семенов Ю. А. "Протоколы и ресурсы INTERNET" "Радио и связь", Москва, 1996

    25.

    Семенов Ю. А. "Сети Интернет. Архитектура и протоколы", СИРИНЪ, 1998.

    26.

    А. Н. Назаров, М.В. Симонов, "ATM-технология высокоскоростных сетей" ЭКО-ТРЕНДЗ, Москва 1998.

    27.

    Н. Н. Слепов, "Синхронные цифровые сети SDH" ЭКО-ТРЕНДЗ, Москва 1998.

    28.

    "Интернет. Всемирная компьютерная сеть. Практическое пособие и путеводитель". Москва 1995, изд. "Синтез".

    29.

    "World Wide Web. Всемирная Информационная паутина в сети Интернет". Практическое руководство. МГУ, 1995.

    30.

    Эд Крол "Все об INTERNET" BNV, Киев 1995.

    31.

    Пол Гилстер "Навигатор INTERNET. Путеводитель для человека с компьютером и модемом", Москва 1995.

    32.

    С. Клименко, В. Уразметов "Internet. Среда обитания информационного общества". РФФИ, Информационные системы в науке.

    33.

    Лаем Куин, Ричард Рассел, Fast Ethernet, bhv, Киев, 1998.

    34.

    Тимоти Паркер, Освой самостоятельно TCP/IP. Бином, Москва 1997.

    35.

    Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. "ЛОРИ", Москва, 1998

    36.

    Дж. Гауэр, Оптические системы связи. Москва, "Радио и связь", 1989.

    37.

    Стивен Спейнаур и Валери Куэрсиа. Справочник WEB-мастера, BHV, Киев, 1997.

    38.

    Lincoln D. Stein, Web Security: a step-by-step reference guide, Addison-Wesley, 1997

    39.

    К.Шеннон, Работы по теории информации и кибернетике, Москва,"Изд. иностранной литературы", 1963

    40.

    В.Е.Котов, Сети Петри,"Наука", Москва, Глав. ред. физ-мат. лит., 1984

    41.

    Лайза Хендерсон, Том Дженкинс, Frame Relay межсетевые взаимодействия, Москва, "Горячая линия - Телеком", 2000

    Previous: 8.1 Вопросы по данному курсу    UP: 8 Заключение
    Down: 10 Приложения    Next: 10 Приложения


    ht://Dig WWW Site Search


    This search will allow you to search the contents of all the publicly available WWW documents at this site.

    Match: Format: Sort by:
    Search: