SMDS (Switched Multimegabit Data Service — коммутируемый мультимегабитный сервис передачи данных) представляет собой технологию передачи данных, разработанную в Bellcore. SMDS можно рассматривать как частный случай MAN-технологии IEEE 802.6 DQDB (Distributed Queue Dual Bus – распределенная двойная шина с очередью), которая была разработана для высокоскоростной передачи данных без организации соединений на основе коммутации пакетов по сетям общего пользования. В настоящее время SMDS обеспечивает доступ к сетям со скоростью до DS-3 (44,726 Мбит/с) и планируется увеличение скорости передачи до 155,520 Мбит/с (OC-3c). SMDS принимает до 9188 октетов из высокоскоростных пользовательских потоков, делит принятые данные на ячейки размером 53 октета, которые передаются через сеть сервис-провайдера. На приемной стороне осуществляется сборка (reassembling) пакетов из принятых ячеек.

Доступ пользователей к сети SMDS контролируется на сетевом уровне (уровень 3) с помощью протокола SIP. Протокол SIP на сетевом уровне принимает и передает кадры с информацией протоколов вышележащих уровней. На канальном уровне протокол SIP (стандарт IEEE 802.6 DQDB) управляет доступом к физической среде передачи. Уровень 1 протокола SIP включает в себя PLCP и передающую систему.

На рисунке показано положение стека протоколов SMDS в эталонной модели OSI:

Положение стека протоколов SMDS в эталонной модели OSI

SIP, уровень 3

Модули данных SIP SDU, содержащие 9188 октетов, передаются с вышележащих уровней протоколу SIP сетевого уровня для последующей передачи через сеть. Протокол сетевого уровня SIP формирует пакеты L3 PDU, включающие заголовок и трейлер, как показано на рисунках. Пакеты L3 PDU передаются протоколу SIP канального уровня, который сегментирует их в ячейки размером 53 октета – L2 PDU. Ячейки L2 PDU затем передаются PLCP для последующей передачи через физическую среду.

Формат L3 PDU показан на рисунке.

Заголовок	Информация	PAD	X + CRC32	Трейлер
36	 9188	0-3	0, 4	4	Байты

Формат SIP PDU для сетевого уровня

Формат заголовка сетевого уровня показан на рисунке.

Биты
0		6	8		12	13		15
Резерв				BEtag
BAsize
Адрес получателя (8 байтов)
Адрес отправителя (8 байтов)
X+HLPI (6 битов)			PL	X + QoS		CIB	HEL
X + Bridging
HE (12 байтов)

Формат заголовка сетевого уровня

На следующем рисунке показан формат трейлера сетевого уровня.

Резерв	BEtag	BAsize
1 байт	1 байт	2 байта

Трейлер сетевого уровня

Ниже приведено описание полей L3 PDU.

Резерв

Зарезервированное поле размером 1 октет, которое CPE и SS заполняют нулями.

BEtag

Поле размером 1 октет, содержащее тег начала/завершения. Тег представляет собой двоичное число в диапазоне 0-255, используемое для установки соответствия между первым сегментом (содержащим заголовок) и последним сегментом (содержащим трейлер) пакета L3 PDU.

BAsize

Это поле имеет размер 2 октета и содержит значение длины L3 PDU в октетах от начала поля «Адрес получателя« до конца поля CRC32 (если оно присутствует).

Адрес получателя

Поле, содержащее адрес получателя PDU (8 октетов). Поле адреса получателя делится на два подполя:

4 старших бита указывают тип адреса — индивидуальный (1100) или групповой (1110).

Оставшиеся 60 битов задают адрес SMDS.

Адрес отправителя

Это поле содержит адрес отправителя пакета (8 октетов) и так же состоит из двух частей (см. Адрес отправителя).

HLPI

Идентификатор протокола вышележащего уровня – Higher Layer Protocol Identifier — представляет собой шестибитовое поле, используемое для выравнивания форматов протокола SIP и DQDB.

PL

Размер поля PAD (заполнение) — двухбитовое поле, указывающее количество октетов в поле PAD. Поле PAD используется для выравнивания L3 PDU по 32-битовым границам.

QoS

Качество обслуживания – Quality of Service — четырехбитовое поле, используемое для выравнивания форматов протокола SIP и DQDB.

CIB

Бит индикации CRC32, указывающий на наличие (1) или отсутствие (0) поля контрольной суммы CRC32.

HEL

Длина расширения заголовка. Трехбитовое поле, которое указывает количество 32-битовых слов в поле расширения заголовка.

Bridging

2-октетное поле, используемое для выравнивания форматов протокола SIP и DQDB.

HE

Расширение заголовка — Header Extension — 12-октетное поле, которое содержит версию протокола, а также дополнительную (по выбору оператора) информацию, представленную в виде набора перечисленных ниже субполей:

Длина элемента: однооктетное поле, содержащее общий размер (в октетах) полей Длина элемента, Тип элемента и Значение элемента.

Тип элемента: однооктетное поле, содержащее двоичное значение, которое определяет тип информации в поле Значение элемента.

Значение элемента: поле переменной длины, интерпретация которого определяется значением поля Тип элемента.

HE PAD: поле переменной длины (0 — 9 октетов), которое используется для выравнивания длины поля HE (расширение заголовка) до 12 байтов.

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

Поле переменной длины (до 9188 октетов), содержащее пользовательскую информацию.

PAD

Поле выравнивания имеет переменную длину (1 — 3 октета) и используется для выравнивания общей длины L3 PDU по 32-битовой границе. Все октеты данного поля имеют нулевое значение.

CRC32

Двухоктетное поле, содержащее контрольную сумму, которая служит для обнаружения ошибок в PDU. При подсчете контрольной суммы учитываются поля от Адреса получателя до CRC32 (включая последнее).

SIP, уровень 2

После того, как процесс формирования L3 PDU завершен, сформированный пакет передается на канальный уровень для формирования одного или нескольких пакетов L2 PDU. SIP канального уровня генерирует 53-октетные ячейки, которые передаются через PLCP и физическую среду. L2 PDU содержит пятиоктетный заголовок и 44 октета данных (элемент сегментации) и двухоктетный трейлер. Формат ячейки показан на рисунке.

 

Биты
	2		4		6		8
Контроль доступа
Управляющая сетевая информация (32 бита)
Тип сегмента		Порядковый номер
Идентификатор сообщения
Элемент пакета (352 бита или 44 байта)
Длина содержимого
Контрольная сумма содержимого

 

Формат SIP PDU канального уровня

Ниже приведено описание полей L2 PDU.

Контроль доступа

8-битовое поле, задающее тип содержимого поля Контроль доступа PDU канального уровня — информация (1) или пустое поле (0).

Управляющая сетевая информация

Четырехоктетное поле, задающее тип содержимого поля Управляющая сетевая информация — информация (FFFFF022H) или пустое поле (0).

Тип сегмента

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

00 COM (Continuation of Massage — продолжение сообщения)

01 EOM (End of Message — конец сообщения)

10 BOM (Beginning of Message — начало сообщения)

11 SSM (Single Segment Message — односегментное сообщение).

Порядковый номер

Четырехбитовое поле, используемое отправителем и получателем ячеек для соблюдения порядка ячеек при обратной сборке пакета L3 PDU.

Идентификатор сообщения

Десятибитовое значение, позволяющее ассоциировать различные ячейки с одним пакетом L3 PDU.

Элемент пакета

44-октетное поле, содержащее сегмент (часть) пакета L3 PDU.

Длина содержимого

Шестибитовое поле, показывающее, какие из 44 октетов сегмента содержат реальные данные. Для сегментов типа BOM и COM это поле всегда содержит значение 44, для сегментов EOM — кратное 4 значение в диапазоне от 4 до 44, а для сегментов SSM — от 28 до 44 (так же кратное 4).

Контрольная сумма содержимого

Десятибитовое поле контрольной суммы, при вычислении которой учитываются поля Тип сегмента, Порядковый номер, Идентификатор сообщения, Элемент пакета, Длина содержимого и Контрольная сумма содержимого.

После завершения формирования ячеек L2 PDU последние передаются PLCP и физическому уровню SIP.

SIP, уровень 1

SIP на физическом уровне используется для передачи сформированных уровнем 2 ячеек L2 PDU. Функции передачи информации делятся на два подуровня – верхний подуровень PLCP и нижний подуровень системы передачи. Уровень PLCP обеспечивает взаимодействие с SIP канального уровня и поддерживает передачу данных и управляющей информации. Подуровень системы передачи определяет формат и скорость передачи данных в физическую среду. Чаше всего для реализации физического уровня SIP используются технологии и стандарты DS-1 и DS-3.

 

Пример декодирования пакета SMDS

Стек протоколов PPP (Point-to-Point Protocol) кроме протокола PPP включает перечисленные ниже протоколы:

• MLP — Multilink PPP

• PPP-BPDU — PPP Bridge Protocol Data Unit

• PPPoE — PPP over Ethernet

• BAP — Bandwidth Allocation Protocol

• BSD — UNIX Compress Command source

• CHAP — Challenge Handshake Authentication Protocol

• DESE — DES Encryption Algorithm

• EAP — Extensible Authentication Protocol

• LCP — Link Control Protocol

• LEX — LAN Extension Interface Protocol

• LQR — Link Quality Report

• PAP — Password Authentication Protocol

Управляющие протоколы PPP

• ATCP — AppleTalk Control Protocol

• BACP — Bandwidth Allocation Control Protocol

• BCP — Bridging Control Protocol

• BVCP — PPP Banyan Vines Control Protocol

• CCP — Compression Control Protocol

• DNCP — PPP DECnet Phase IV Control Protocol

• ECP — Encryption Control Protocol

• IPCP — IP Control Protocol

• IPv6CP — IPv6 Control Protocol

• IPXCP — IPX Control Protocol

• LEXCP — LAN Extension Interface Control Protocol

• NBFCP — PPP NetBIOS Frames Control Protocol

• OSINLCP — OSI Network Layer Control Protocol

• SDCP — Serial Data Control Protocol

• SNACP — SNA PPP Control Protocol

  На рисунке показано расположение протоколов стека PPP в эталонной модели OSI.

Положение стека протоколов PPP в эталонной модели OSI

PPP

RFC1548

RFC1661

RFC1662

Протокол PPP (Point-to-Point Protocol) предназначен для организации простых каналов, которые позволяют передавать пакеты между узлами одного уровня (peer). Эти каналы обеспечивают полнодуплексную связь (передача в обоих направлениях одновременно). Предполагается, что порядок следования пакетов при доставке через каналы PPP не нарушается. PPP обеспечивает простое решение для соединения различных хостов, мостов и маршрутизаторов.

Структура заголовков PPP показана на рисунке.

Адрес	Управление	Протокол	Информация	FCS
1 байт	1 байт	2 байта	переменный	2 байта

Структура заголовка PPP

Адрес

Широковещательный адрес HDLC. PPP не использует индивидуальных адресов для станций. Поле адреса в заголовке пакетов PPP всегда должно иметь значение FF

Управление

Команда HDLC для ненумерованной информации (Unnumbered Information или UI) с нулевым значением бита Poll/Final. Кадры, содержащие в этом поле любое другое значение, будут отбрасываться.

Протокол

Идентификатор протокола, инкапсулированного в информационном поле кадра.

Информация

Данные протоколов вышележащих уровней.

FCS

Контрольная сумма кадра. Протокол PPP проверяет значение контрольной суммы после доставки пакета.

MLP (Multilink PPP)

RFC1717

RFC1990

Поддержка мультиканального режима Multilink основана на опции согласования параметров PCP, позволяющей станции сообщить станции-партнеру о возможности объединения нескольких физических каналов передачи данных в один логический канал. Одного «пакета» физических каналов достаточно практически для любых условий связи между парой станций.

Согласование параметров выполняется на начальной фазе согласования опций LCP. Система показывает своему партнеру того же уровня (peer) намерение использовать мультиканальный режим путем передачи мультиканальной опции на начальной фазе согласования параметров LCP. Согласование параметров показывает следующие возможности:

1. Система, предлагающая мультиканальный режим, может объединять несколько физических каналов в одно логическое соединение.
2. Система способна принимать фрагментированные PDU вышележащих уровней с использованием мультиканального заголовка и собирать фрагменты в исходный модуль данных PDU.
3. Система может принимать PDU размером N октетов, где N задается как часть опций согласования даже в тех случаях, когда N превышает значение MRU (максимальный размер принимаемого пакета) для одного физического канала.

При использовании протокола Multilink PPP пакеты сначала инкапсулируются (но не кадрируются) в соответствии с обычными процедурами PPP — большие пакеты разбиваются на фрагменты меньших размеров, приемлемых для физических каналов. Перед каждой секцией пакета вставляется новый PPP заголовок, содержащий идентификатор протокола Multilink PPP и заголовок Multilink.. Таким образом, первый фрагмент мультиканального пакета PPP будет содержать два заголовка — заголовок фрагмента и заголовок пакета.

Фрагменты Multilink PPP инкапсулируются с использованием идентификатора протокола 0x00 — 0x3d. Вслед за идентификатором протокола размещается четырехбайтовый заголовок, содержащий порядковый номер, и 2 однобайтовых поля, показывающие первый и последний фрагмент пакета. После согласования дополнительных опций PPP LCP четырехбайтовый заголовок может быть заменен двухбайтовым заголовком, после которого размещаются 12 последовательных нулей. Поля Адрес/Управление и Идентификатор протокола сохраняют свое назначение.

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

Заголовок PPP	Адрес 0xff								Управление 0x03
	PID (H) 0x00								PID (L) 0x3d
Заголовок MP	B	E	O	O	O	O	O	O	Порядковый номер
	Порядковый номер (L)
	Фрагмент данных . . ,
PPP FCS	FCS

Фрагмент Multilink PPP с длинным порядковым номером

На следующем рисунке показан формат фрагмента с коротким порядковым номером.

Заголовок PPP	Адрес 0xff					Управление 0x03
	PID (H) 0x00					PID (L) 0x3d
Заголовок MP	B	E	O	O	Порядковый номер
	Фрагмент данных . . ,
PPP FCS	FCS

Фрагмент Multilink PPP с коротким порядковым номером

PID

Идентификатор протокола.

B

Флаг начального (первого) фрагмента. Нулевое значение этого поля указывает, что фрагмент не является первым фрагментом пакета PPP, а 1 указывает первый фрагмент. Таким образом, для последовательности фрагментов этот бит устанавливается только в заголовке первого фрагмента.

E

Флаг конечного (последнего) фрагмента. Нулевое значение этого поля указывает, что фрагмент не является последним фрагментом пакета PPP, а 1 указывает последний фрагмент. Это поле имеет нулевое значение для всех фрагментов пакета PPP, кроме последнего.

Порядковый номер

24-х или 12-битовый номер фрагмента. Фрагменты нумеруются по порядку с увеличением номера на 1. По умолчанию используются 24-битовые (длинные) номера, но при согласовании опций конфигурации LCP можно договориться об использовании 12-битовых (коротких) номеров.

O

Зарезервированные поля между флагом последнего фрагмента и порядковым номером. Эти поля в настоящее время не используются и должны иметь нулевые значения. В пакетах с длинным порядковым номером используется 6 полей O, в пакетах с коротким номером — 2.

FCS

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

PPP-BPDU

RFC 1638

Существуют два основных типа мостов — мосты, используемые для непосредственного соединения ЛВС (локальные мосты — Local Bridge), и удаленные мосты (Remote Bridge), позволяющие соединять ЛВС по каналам WAN (например, по выделенной линии с использованием модемов). Протокол PPP-BPDU (Bridge Protocol Data Unit) используется для подключения удаленных мостов.

Формат пакетов PPP-BPDU показан на рисунке.

4				8	16	32
F	I	Z	O	Заполн.	Тип MAC	Старшая часть идентификатора ЛВС
Младшая часть идентификатора ЛВС						Байт заполнения	Управл. кадром
MAC-адрес получателя
MAC-адрес получателя						MAC-адрес отправителя
MAC-адрес отправителя
Данные LLC

Структура пакета LLC

F

Флаг LAN FCS, который устанавливается при наличии контрольной суммы.

I

Флаг LAN ID, который устанавливается при наличии поля идентификатора ЛВС.

Z

Флаг Z, устанавливаемый при дополнении коротких кадров нулями в соответствии со спецификацией IEEE 802.3.

O

Резервный флаг, который должен иметь нулевое значение.

Заполнение

В любом пакете PPP могут содержаться байты заполнения в поле Optional Data Link Layer Padding (необязательное заполнение канального уровня).

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

Тип MAC

Это поле может принимать следующие значения:

1 Bridge-Identification (идентификация моста)

2 Line-Identification (идентификация линии)

3 MAC-Support (поддержка MAC)

4 Tinygram-Compression (компрессия Tinygram)

5 LAN-Identification (идентификация ЛВС)

6 MAC-Address (MAC-адрес)

7 Spanning-Tree-Protocol (протокол Spanning Tree).

Идентификатор ЛВС

Необязательное 32-битовое поле, идентифицирующее сообщество ЛВС (Community of LAN), заинтересованных в получении данного кадра. Если флаг LAN ID (идентификатор ЛВС) не установлен, это поле отсутствует, делая PDU на 4 октета короче.

Управление кадром

В ЛВС 802.4, 802.5 и FDDI перед MAC-адресом получателя имеется несколько октетов, один из которых защищен FCS. Поле «Тип MAC» задает содержимое поля управления кадром. Для выравнивания по 32-битовой границе используется октет заполнения.

MAC-адрес получателя

Адрес получателя в соответствии со спецификацией IEEE. Порядок битов адреса определяется значением поля «Тип MAC.»

MAC-адрес отправителя

Адрес отправителя в соответствии со спецификацией IEEE. Порядок битов адреса определяется значением поля «Тип MAC.»

Данные LLC

Данные уровня управления логическим каналом (LLC) составляют остальную часть кадра MAC и (если они присутствуют) учитываются при расчете контрольной суммы LAN FCS.

PPPoE

RFC 2516

PPPoE представляет собой метод передачи PPP в сетях Ethernet. Этот метод обеспечивает возможность соединить сеть хостов с концентратором удаленного доступа через простой мост. При использовании такой модели каждый хост использует свой стек PPP и пользователю предоставляется привычный интерфейс. Управление доступом, учет использования сервиса и тип обслуживания можно задавать отдельно для каждого пользователя или (в более редких случаях) для всего сайта.

Для обеспечения парных (точка-точка) соединений через сеть Ethernet, каждая сессия PPP должна знать Ethernet-адрес удаленной станции того же уровня. Кроме того, для каждой сессии нужен уникальный идентификатор. Протокол PPPoE включает механизм обнаружения (discovery protocol), который решает эти задачи.

PPPoE имеет две различных стадии — обнаружение и сеанс PPP. Когда хост намеревается инициировать сеанс PPPoE, он должен сначала провести обнаружение для определения MAC-адреса Ethernet партнера, а потом организовать PPPoE SESSION_ID. В протоколе PPP используются между узлами одного уровня (peer), а процесс обнаружения использует модель «клиент-сервер». В процессе обнаружения хост (клиент) находит концентратор доступа (сервер). В зависимости от топологии сети может использоваться один или несколько концентраторов доступа, с которыми может работать каждый хост. При успешном завершении этапа обнаружения хост и выбранный концентратор доступа имеют информацию, требуемую для организации соединения «точка-точка» через сеть Ethernet.

Этап обнаружения продолжается до тех пор, пока не будет организована сессия PPP. После организации сеанса PPP хост и концентратор доступа должны предоставить свои ресурсы для виртуального интерфейса PPP.

Поле EtherType в кадрах Ethernet имеет значение 0x8863 на этапе обнаружения и 0x8864 — на этапе сеанса PPP.

Формат данных Ethernet для PPPoE показан на рисунке.

4	8	16
Версия	Тип	Код
Идентификатор сессии
Размер
Содержимое (payload)

Формат содержимого Ethernet для PPPoE

Версия

Задает номер версии и имеет значение 0x1 для текущей версии PPPoE (RFC 2516).

Тип

Имеет значение 0x1 для текущей версии PPPoE (RFC 2516).

Код

Значение кода зависит от переданного пакета:

Пакет	Код
Этап обнаружения
Active Discovery Initiation (PADI)	0x09
Active Discovery Offer (PADO)	0x07
Active Discovery Request (PADR)	0x19
Active Discovery Session-confirmation (PADS)	0x65
Active Discovery Terminate (PADT)	0xa7
Этап сеанса PPP	0x00

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

Беззнаковое целое число, которое вместе с адресами отправителя и получателя идентифицирует сеанс PPP. Значение 0xffff зарезервировано для использования в будущем.

Размер

Размер поля содержимого пакета PPPoE без учета заголовков Ethernet и PPPoE.

BAP

RFC 2125 http://www.ietf.org/rfc/rfc2125.txt

Протокол выделения полосы BAP (Bandwidth Allocation Protocol) можно использовать для управления числом каналов в мультиканальном потоке. BAP определяет дейтаграммы для координации процессов добавления или отключения отдельных каналов мультиканального потока. Эти же дейтаграммы используются для задания узла, ответственного за различные решения, связанные с управление полосой мультиканального потока.

Формат пакетов BAP показан на рисунке.

Тип	Размер	Данные
1 байт	1 байт	Переменный размер

Формат пакетов BAP

Тип

Однооктетное поле, показывающее тип дейтаграммы BAP. В приведенном ниже списке показаны возможные значения кодов в шестнадцатеричном формате.

1 Call-Request (запрос соединения)

2 Call-Response (отклик на запрос соединения)

3 Callback-Request (запрос обратного соединения)

4 Callback-Response (отклик на запрос обратного соединения)

5 Link-Drop-Query-Request (запрос сброса канала)

6 Link-Drop-Query-Response (отклик на запрос сброса канала)

7 Call-Status-Indication (индикация состояния соединения)

8. Call-Status-Response (запрос состояния соединения)

Размер

Однооктетное поле, показывающее размер опций BAP с учетом полей типа, размера и данных.

Данные

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

BSD

RFC 1977 http://www.ietf.org/rfc/rfc1977.txt

BSD представляет собой бесплатный и широко распространенный механизм компрессии данных UNIX. Основные особенности BSD перечислены ниже.

• Динамическая очистка таблиц в тех случаях, когда эффективность компрессии снижается.
• Автоматическое отключение компрессии в тех случаях, когда сжатые данные по размеру не меньше исходных.
• Динамический выбор размера кода в предопределенных пределах.
• Многолетняя практика использования протокола в сетях, на модемных линиях и других каналах «точка-точка.»
• Эффективная ширина кода, требующая менее 64К памяти на приемной и передающей стороне.

До того, как какой-либо пакет BSD Compress будет передан, протокол PPP должен дойти до фазы сетевого уровня, а протокол управления CCP должен дойти до стадии открытия. В информационное поле пакетов PPP с полем протокола, имеющим значение 0xFD или 0xFB инкапсулируется единственная дейтаграмма BSD Compress. 0xFD используется вместе MLP для независимой компрессии на каждом физическом канале мультиканального потока. Максимальный размер дейтаграммы BSD Compress, передаваемой через канал PPP совпадает с максимальным размером информационного поля пакета инкапсулированного в PPP. Сжатие возможно только для пакетов с номерами от 0x0000 до 0x3FFF, исключая номера 0xFD и 0xFB. Остальные пакеты PPP передаются без сжатия. Пакеты управления достаточно редки и должны передаваться без компрессии.

CHAP

RFC 1334 http://www.ietf.org/rfc/rfc1334.txt

Протокол аутентификации CHAP (Challenge Handshake Authentication Protocol) используется для периодической проверки узлов одного уровня, использующих трехстороннюю процедуру согласования (handshake). Процедура проверки выполняется при организации соединения и может повторяться в любой момент в процессе использования канала.

В информационное поле пакетов PPP с полем протокола 0xc223 инкапсулируется единственный пакет CHAP. Структура пакетов CHAP показана на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов CHAP

Код

Код идентифицирует тип пакета CHAP и может принимать одно из перечисленных ниже значений:

1 Challenge (вызов, проверка)

2 Response (отклик)

3 Success (успех)

4 Failure (отказ)

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

Дополнительная идентификация в зависимости от типа пакета.

Размер

Размер пакета CHAP с учетом всех полей.

Данные

Поле, содержащее данные в формате, определяемом полем кода. Формат данных для пакетов Challenge и Response показан ниже.

Размер значения	Значение	Имя
1 байт		1 байт

 

Структура поля данных для пакетов CHAP Challenge и Response

Размер значения

Это поле определяет размер поля значения.

Значение

Значение Challenge представляет собой поток октетов, который должен изменяться при каждом повторении вызова.

Значение Response представляет собой результат расчета на основе потока октетов, содержащего Идентификатор, «Секрет» и значение Challenge.

Имя

Идентификатор системы, передающей пакет.

Для пакетов Success и Failure поле данных имеет переменную длину, а содержащаяся в нем информация зависит от реализации протокола.

DESE

RFC 1969 http://www.ietf.org/rfc/rfc1969.txt

Алгоритм DES (Data Encryption Standard) Encryption является хорошо известной, понятной и широко распространенной реализацией алгоритма шифрования, предназначенной для эффективного шифрования на аппаратном уровне. DESE представляет опцию ECP, показывающую что предлагается использовать шифрование DES для коммуникационного канала.

Формат пакетов DESE показан на рисунке.

8	16	24	32
Адрес	Управление	0 0 0 0	Идентификатор протокола
Номер сегмента (старшая часть)	Номер сегмента (младшая часть)	Cyphertext (переменный размер)

Формат пакетов DESE

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

Поле идентификатора протокола может иметь значение 0x53 или 0x55. Значение 0x55 говорит о том, что поле Cyphertext содержит заголовки для MLP и требует, чтобы протокол Individual Link Encryption Control Protocol находился в открытом состоянии. Нули перед полем идентификатора протокола могут отсутствовать, если опция PFC (PPP Protocol Field Compression) согласована.

Номер сегмента

Порядковые номера сегментов представляют собой 16-битовые числа, присваиваемые программой шифрования по порядку, начиная с нуля (для первого пакета, переданного после того, как ECP достигнет открытого состояния).

Cyphertext

Генерация шифрованных данных описана в стандарте DESE.

EAP

RFC 2284 ftp://ftp.isi.edu/in-notes/rfc2284.txt

RFC 2716 ftp://ftp.isi.edu/in-notes/rfc2716.txt

Расширенный протокол аутентификации EAP (Extensible Authentication Protocol) представляет собой расширение PPP, обеспечивающее поддержку дополнительных методов аутентификации в PPP.

Формат заголовка пакетов EAP показан на рисунке.

Код	Идентификатор	Размер	Тип	Данные
1 байт	1 байт	2 байта	1 байт	Переменный размер

Формат заголовка EAP

Код

Десятичное значение, задающее тип пакета EAP:

1 Request

2 Responce

3 Success

4 Failure

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

Дополнение к соответствующим откликам

Размер

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

Тип

Задает тип EAP. Поддерживаются следующие типы:

KEA validate

KEA public

GTC

OTP

MD5

NQK

Notification

Identify.

LCP

RFC 1570 http://www.ietf.org/rfc/rfc1570.txt

RFC 1661 http://www.ietf.org/rfc/rfc1661.txt

Для обеспечения возможности адаптации к различным средам протокол PPP использует специальный протокол управления каналом LCP (Link Control Protocol) для организации, настройки и проверки каналов связи. LCP служит для автоматического согласования опций инкапсуляции, размера пакетов, обнаружения возвратных (looped-back) каналов и других ошибок, а также для разрыва соединений. К дополнительным возможностям этого протокола относятся аутентификация участников соединения и проверка корректности работы канала с обнаружением сбоев.

Формат пакетов LCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов LCP

Код

Однооктетное поле, определяющее тип пакета 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 Link-Quality Report

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

Десятичное значение, дополняющее соответствующий запрос или отклик

Размер

Размер всех полей пакета LCP.

Данные

Поле переменной длины, которое может содержать одну или несколько опций. Формат конфигурационных опций LCP показан на рисунке.

 

Тип

Размер

Данные

 

Структура поля данных LCP

Тип

Однобайтовый идентификатор типа опций конфигурации.

Размер

Размер всех полей конфигурационных опций (тип, длина, данные).

Данные

Значение поля «Данные».

Декодирование протокола LCP

LEX

RFC 1841 http://www.ietf.org/rfc/rfc1841.txt

Интерфейс расширения ЛВС представляет собой аппаратный модуль, устанавливаемый на удаленных сайтах (например, дома или в филиале), подключенных к ЛВС через WAN-канал и центральный маршрутизатор. Для поддержки такой архитектуры были разработаны протоколы PPP NCP (Network Control Protocol) и PPP-LEX (LAN extension interface protocol). Назначением протокола LEX является инкапсуляция пакетов управления интерфейсом расширения ЛВС и пакетов данных. Последовательно передаваемые пакеты могут содержать данные или управляющую информацию. Пакеты управления описываются протоколом LEXCP.

Формат кадров показан PPP-LEX на приведенном ниже рисунке. Кадры MAC передаются с исключением поля FCS (контрольная сумма). Интерфейсные модули расширения ЛВС рассчитывают значение FCS для пакетов, передаваемых в локальную сеть, и вырезают значение FCS из пакетов, передаваемых маршрутизатору.

4				8		16	24	32
Флаг HDLC
Адрес						Управление	Тип протокола
F	I	Z	O		Заполн.	Тип MAC	MAC-адрес получателя
MAC-адрес получателя
MAC-адрес отправителя
MAC-адрес отправителя							Размер/тип
Данные LLC
HDLC CRC							Флаг HDLC

Структура пакетов данных PPP-LEX

Флаг HDLC

Ограничитель кадра HDLC.

Адрес

Поле адреса содержит широковещательный адрес 0xFF.

Управление

Поле управления содержит ненумерованную информацию (0x03).

Тип протокола

Идентификатор типа протокола, выделенный IETF (0x0041 — данные).

F

Этот флаг устанавливается при наличии поля LAN FCS. Пакеты данных PPP-LEX не содержат контрольной суммы LAN FCS и это поле всегда равно 0.

I

Флаг наличия поля LAN ID. Поскольку пакеты данных PPP-LEX не содержат идентификатора ЛВС, это поле всегда имеет нулевое значение.

Z

Этот флаг показывает, что нужно использовать заполнение IEEE 802.3.

O

Зарезервированное поле (0).

Заполнение

Любой кадр PPP может содержать байты заполнения в поле Optional Data Link Layer Padding. Значение данного поля говорит принимающей системе, какое количество октетов заполнения должно быть отброшено. Протокол расширения ЛВС не поддерживает заполнения и должно быть равно 0.

Тип MAC

Это поле может содержать значения типов MAC, перечисленные в последнем варианте Assigned Numbers RFC (в настоящее время — RFC). В соответствии с RFC 1841 это поле содержит идентификатор IEEE 802.3/Ethernet с канонической адресацией.

MAC-адрес получателя

6-октетное поле, содержащее MAC-адрес получателя в соответствии со спецификацией IEEE. Порядок битов адреса определяется полем Тип MAC.

MAC-адрес отправителя

6-октетное поле, содержащее MAC-адрес отправителя в соответствии со спецификацией IEEE. Порядок битов адреса определяется полем Тип MAC.

Размер/тип

Тип протокола Ethernet или размер пакета для кадров IEEE 802.3.

Данные LLC

Остальная часть кадра MAC, защищенная контрольной суммой LAN FCS.

HDLC CRC

16-битовая контрольная сумма.

LQR

RFC 1333 http://www.ietf.org/rfc/rfc1333.txt

Протокол LQR (Link Quality Report — отчет о качестве канала) описывает механизмы мониторинга каналов PPP. Пакеты могут отбрасываться или повреждаться в результате шумов в линии, сбоев оборудования, переполнения буферов и т.п. — зачастую важно определить, когда и при каких условиях повреждаются пакеты данных. Маршрутизаторы могут временно отдавать предпочтение другому маршруту или может быть реализовано переключение на альтернативный канал. Для решения связанных с такими ситуациями вопросов требуется механизм мониторинга качества каналов.

В информационное поле кадров канального уровня PPP с полем протокола c025 инкапсулируется один пакет LQR. Структура пакетов LQR показана на рисунке.

8	16	24	32
Магическое число
Last out LQRs
Last out Packets
Last out octets
Peer in LQRs
Peer in packets
Peer in discards
Peer in errors
Peer in octets
Peer out LQRs
Peer out packets
Peer out octets
Save in LQRs
Save in packets
Save in discards
Save in errors
Save in octets

Структура пакета LQR

Магическое число

Вспомогательное поле для детектирующих каналов при наличии условий возврата (looped-back condition)

Last out LQRs

Значение этого поля копируется из последнего Peer Out LQR на передаче.

Last out Packets

Значение этого поля копируется из последнего Peer Out Packets на передаче.

Last out octets

Значение этого поля копируется из последнего Peer Out Octets на передаче.

Peer in LQRs

Значение этого поля копируется из последнего Save in LQRs на передаче. Если поле Peer in LQRs имеет нулевое значение, поля Last Out не определены, а поля Peer In содержат изначальные значения.

Peer in packets

Значение этого поля копируется из последнего Save in packets на передаче.

Peer in discards

Значение этого поля копируется из последнего Save in discards на передаче.

Peer in errors

Значение этого поля копируется из последнего Save in errors на передаче.

Peer in octets

Значение этого поля копируется из последнего Save in octets на передаче.

Peer out LQRs

Значение этого поля копируется из Out LQRs на передаче. Это число должно включать LQR.

Peer out packets

Значение этого поля копируется из текущего MIB ifOutUniPackets и ifOutNUniPackets на передаче. Это число должно включать LQR.

Peer out octets

Значение этого поля копируется из текущего MIB ifOutOctets на передаче. Это число должно включать LQR.

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

Save in LQRs

Значение этого поля копируется из In LQRs на приеме. Это число должно включать LQR.

Save in packets

Значение этого поля копируется из текущего MIB ifInUniPackets и ifInNUniPackets на приеме. Это число должно включать LQR.

Save in discards

Значение этого поля копируется из ifInDiscards на приеме. Это число должно включать LQR.

Save in errors

Значение этого поля копируется из ifInErrors на приеме. Это число должно включать LQR.

Save in octets

Значение этого поля копируется из InGoodOctets на приеме. Это число должно включать LQR.

PAP

RFC 1334 http://www.ietf.org/rfc/rfc1334.txt

Протокол PAP (Password Authentication Protocol — аутентификация по паролю) обеспечивает узлам одного уровня простой способ идентификации друг друга путем двухстороннего согласования (handshake).

Пакеты PAP инкапсулируются в информационное поле кадров канального уровня PPP с полем протокола c023. Структура пакетов PAP показана на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов PAP

Код

Однооктетное поле, определяющее тип пакета PAP.

1 Authenticate-Request

2 Authenticate-Ack

3 Authenticate-Nak

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета PAP.

Данные

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

Формат запросов аутентификации (Authenticate-Request) показан на рисунке.

Размер Peer-ID	Peer-ID	Размер пароля	Пароль
1 байт	Переменный размер	1 байт	Переменный размер

Структура запросов аутентификации (Authenticate-Request)

Размер Peer-ID

Размер поля Peer-ID в октетах.

Peer-ID

Указывает имя узла для аутентификации.

Размер пароля

Указывает размер пароля в октетах.

Пароль

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

Формат пакетов Authenticate -Ack и Authenticate-Nak показан на следующем рисунке

Размер сообщения	Сообщение
1 байт	Переменный размер

Структура пакетов Authenticate -Ack и Authenticate-Nak

Размер сообщения

Размер поля Сообщение.

Сообщение

Содержание сообщения зависит от реализации.

ATCP

RFC 1378 http://www.ietf.org/rfc/rfc1378.txt

Протокол ATCP (AppleTalk Control Protocol) отвечает за настройку параметров AppleTalk на обеих сторонах соединения «точка-точка». ATCP использует такой же механизм обмена пакетами, как в протоколе управления каналом LCP. Обмен ATCP-пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Полученные до этого момента пакеты ATCP отбрасываются.

Формат заголовка пакетов ATCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов ATCP

Код

Однооктетное поле, определяющее тип пакета ATCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета ATCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций ATCP показан на рисунке.

Тип

Размер

Данные

 

Конфигурационные опции ATCP

Тип

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

1 AppleTalk-Address

2 Routing-Protocol

3 Supress-Broadcasts

4 AT-Compression Protocol

6 Server-Information

7. Zone-Information

8. Default-Router Address

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

BACP

RFC 2125 http://www.ietf.org/rfc/rfc2125.txt

Протокол управления полосой BACP (Bandwidth Allocation Control Protocol) связан с протоколом BAP, который можно использовать для управления мультиканальными потоками на основе множества физических соединений. BAP определяет дейтаграммы, используемые для добавления и удаления отдельных каналов, а также для определения стороны, отвечающей за принятие решений о полосы для мультиканального потока. Протокол BACP определяет параметры управления протоколом BAP.

Формат пакетов BACP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов BACP

Код

Однооктетное поле, определяющее тип пакета BACP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета BACP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций BACP показан на рисунке.

Тип

Размер

Данные

 

Конфигурационные опции BACP

Тип

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

1 Favored-Peer

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

 

BCP

RFC 1638 http://www.ietf.org/rfc/rfc1638.txt

Протокол управления мостами BCP (Bridge Control Protocol) отвечает за настройку конфигурационных параметров протокола мостов на обеих сторонах соединения «точка-точка». BCP использует такой же механизм обмена пакетами, как в протоколе управления каналом LCP. Обмен BCP-пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Полученные до этого момента пакеты BCP отбрасываются.

Формат пакетов BCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов BCP

Код

Однооктетное поле, определяющее тип пакета BCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета BCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций BCP показан на рисунке.

Тип

Размер

Данные

 

Конфигурационные опции BCP

Тип

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

1. Bridge-Identification

2. Line-Identification

3. MAC-Support

4. Tinygram-Compression

5. LAN-Identification

6. MAC-Address

7. Spanning-Tree-Protocol

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

BVCP

RFC 1763 http://www.ietf.org/rfc/rfc1763.txt

Протокол BVCP (PPP Banyan VINES Control Protocol) отвечает за настройку, разрешение и запрещение протокольных модулей VINES на обеих сторонах соединения «точка-точка». BVCP использует такой же механизм обмена пакетами, как в протоколе управления каналом LCP.

Формат пакетов BVCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов BVCP

Код

Однооктетное поле, определяющее тип пакета BVCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета BVCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций BVCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции BVCP

Тип

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

1. BV-NS-RTP-Link-Type

2. BV-FRP (протокол фрагментации)

3. BV-RTP

4. BV-Suppress-Broadcast

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

CCP

RFC 1962 http://www.ietf.org/rfc/rfc1962.txt

Протокол управления компрессией CCP (Compression Control Protocol) отвечает за настройку алгоритма компрессии данных на обеих сторонах канала «точка-точка». Этот протокол используется также для сигнализации о сбоях при компрессии или декомпрессии. CCP использует такой же механизм обмена пакетами, как в протоколе управления каналом LCP. Обмен CCP -пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Полученные до этого момента пакеты CCP отбрасываются.

Формат пакетов CCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов CCP

Код

Однооктетное поле, определяющее тип пакета CCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета CCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций CCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции BVCP

Тип

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

0 OUI

1 Predictor Type 1

2 Predictor Type 2

3 Puddle Jumper

16 Hewlett-Packard-PPC

17 Stac Electronics LZS

18 Microsoft PPC

19 Gandalf FZA

20 V.42bis Compression

21 BSD LZW Compression

23 LZS-DCP

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

DNCP

RFC 1376 http://www.ietf.org/rfc/rfc1376.txt

Протокол управления PPP DECnet Phase IV отвечает за организацию и настройку протокола маршрутизации DNA Phase IV через PPP. Этот протокол применим только к сообщениям маршрутизации Digital DNA Phase IV и не может использоваться с другими протоколами DNA Phase IV (MOP, LAT и т.д.).

Формат пакетов DNCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов DNCP

Код

Однооктетное поле, определяющее тип пакета DNCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета DNCP.

Данные

Поле данных пакетов DNCP не содержит конфигурационных опций. Длина этого поля может быть равна 0.

ECP

RFC 1968 http://www.ietf.org/rfc/rfc1968.txt

Протокол управления шифрованием (Encryption Control Protocol или ECP) отвечает за настройку и разрешение алгоритма шифрования данных на обеих сторонах канала «точка-точка». ECP использует такой же механизм обмена пакетами, как протокол LCP (Link Control Protocol). Обмен ECP-пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Полученные до этого момента пакеты ECP отбрасываются.

Формат заголовка пакетов ECP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов ECP

Код

Однооктетное поле, определяющее тип пакета ECP. В случае приема пакета с неизвестным значением кода генерируется пакет Code-Reject.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

14 Reset-Request

15 Reset-Ack

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета ECP.

IPv6CP

RFC 2023 http://www.ietf.org/rfc/rfc2023.txt

Протокол управления PPP IPv6CP отвечает за настройку, разрешение и запрещение протокольных модулей IPv6 на обеих сторонах соединений «точка-точка».

Формат пакетов IPv6CP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов IPv6CP

Код

Однооктетное поле, определяющее тип пакета IPv6CP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета IPv6CP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций IPv6CP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции IPv6CP

Тип

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

1 Interface Token

2 IPv6-Compression-Protocol

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

 

Распределение трафика по кодам IPv6CP

IPCP

RFC 1332 http://www.ietf.org/rfc/rfc1332.txt

Протокол управления IP (IP Control Protocol или IPCP) отвечает за настройку протокольных параметров IP на обеих сторонах соединений «точка-точка».

Формат пакетов IPCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов IPCP

Код

Однооктетное поле, определяющее тип пакета IPCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета IPCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций IPCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции IPCP

Тип

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

1 IP Address (использование этого кода не рекомендуется, лучше использовать код 3)

2 IP Compression Protocol

3 IP Address (способ согласования IP-адреса, который будет использоваться на локальной стороне канала).

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

IPXCP

RFC 1552 http://www.ietf.org/rfc/rfc1552.txt

Для организации связи по каналу «точка-точка» каждая из сторон соединения PPP должна сначала передать пакеты LCP для настройки и тестирования канала данных. После организации канала и согласования дополнительных параметров, требуемых протоколом LCP, протокол PPP может передавать пакеты для выбора и настройки протокола сетевого уровня IPX. После того, как протокол IPXCP достигнет открытого состояния (Opened state), дейтаграммы IPX можно будет передавать через канал.

Формат пакетов IPXCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов IPXCP

Код

Однооктетное поле, определяющее тип пакета IPXCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета IPXCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций IPXCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции IPXCP

Тип

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

1. IPX Network number

2. IPX Node number

3. IPX Compression Protocol

1. IPX Routing Protocol

2. IPX Router name

3. IPX Configuration complete.

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

LEXCP

RFC 1841 http://www.ietf.org/rfc/rfc1841.txt

Интерфейсные модули расширения ЛВС представляют собой устройства, установленные на удаленных сайтах (дома или в филиалах) и подключенные к маршрутизатору центрального сайта через WAN-каналы. Для поддержки такой архитектуры были разработаны протокол PPP NCP (Network Control Protocol — протокол управления сетью) и протокол PPP-LEX (LAN extension interface protocol). Основными функциями протокола LEX является инкапсуляция пакетов управления интерфейсом расширения ЛВС и пакетов данных. Последовательно передаваемые пакеты могут содержать данные или управляющую информацию. Пакеты данных описываются протоколом LEX.

Существует два типа пакетов LEXCP:

• пакеты стартовых опций;
• пакеты опций удаленных команд.

Пакет стартовых опций является первым пакетом LEX NCP, который интерфейсный модуль расширения ЛВС посылает центральному маршрутизатору после того, как LCP достигнет открытого состояния. Этот обязательный пакет настраивает протокол для интерфейса расширения ЛВС и переводит в открытое состояние LEX NCP.

Формат пакетов LEXCP показан на рисунке.

Адрес	Управление	Тип протокола
Код	Идентификатор	Размер
Опции
1 байт	1 байт	2 байта

Заголовок протокола PPP + LEX

 

Тип опции	Размер опции	Данные
1 байт	1 байт	2 байта

Стартовые опции LEX

 

Тип опции	Флаги опции	Размер опции	Данные
1 байт	1 байт	2 байта

Опции удаленных команд LEX

Адрес

Адрес всех станций — однооктетное поле, содержащее двоичную последовательность 11111111 (0xFF). Протокол PPP не использует для станций индивидуальных адресов. Адрес всех станций (широковещательный) должен распознаваться и приниматься всеми станциями.

Управление

Команда ненумерованной информации (UI) с нулевым значением бита P/F — однооктетное поле, содержащее специфическое для PPP значение 00000011 (0x03).

Тип протокола

Выделенное IETF значение идентификатора протокола. Для пакетов управления значение этого поля составляет 0x8041.

Код

Идентифицирует тип пакета LLC, передаваемого интерфейсом расширения ЛВС. Корректные значения идентификаторов перечислены ниже:

Стартовые опции:

0x01 Configure-Request

0x02 Configure-Ack

0x03 Configure-Nak

0x04 Configure-Rej

Опции удаленных команд:

0x40 LEX_RCMD_REQUEST

0x41 LEX_RCMD_ACK

0x42 LEX_RCMD_NAK

0x43 LEX_RCMD_REJ

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

Случайное число, позволяющее идентифицировать запрос или отклик. Рекомендуется использовать для идентификатора ненулевые значения. В будущих версиях 0 может использоваться для обозначения незапрошенных сообщений от интерфейса расширения ЛВС. Допустимые значения этого поля лежат в диапазоне от 0x01 до 0xFF.

Размер

Размер пакета в октетах с учетом полей Код, Идентификатор, Размер и Опции.

Тип опции

Идентифицирует стартовую опцию или опцию удаленной команды. Возможные значения идентификаторов перечислены ниже.

Стартовые опции:

0x01 MAC Type

0x03 MAC Address

0x05 LAN Extension

Опции удаленных команд:

0x01 Filter Protocol Type

0x02 Filter MAC Address

0x03 Set priority

0x04 Disable LAN Extension Ethernet Interface

0x05 Enable LAN Extension Ethernet Interface

0x06 Reboot LAN Extension Ethernet Unit

0x07 Request Statistics

0x08 Download Request

0x09 Download Data

0x0A Download Status

0x0B Inventory Request

Размер опции

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

Данные

Данные, относящиеся к значению, указанному в поле типа опции. Ниже приведены варианты данных для стартовых опций.

Тип опции	Данные
0x01 MAC Type	Современное значение типа MAC (в настоящее время 0x001 для IEEE 802.3/Ethernet с канонической адресацией).
0x03 MAC Address	Актуальный MAC-адрес в каноническом формате IEEE 802.3
0x05 LAN Extension	Программная информация об интерфейсе расширения ЛВС. В настоящее время — 0x01.

Флаги опции

Задают опции удаленной команды, указывая конкретные действия, которые нужно выполнить (используется только в пакетах опций удаленных команд).

NBFCP

RFC 2097 http://www.ietf.org/rfc/rfc2097.txt

Протокол NBFCP (PPP NetBIOS Frames Control Protocol — протокол управления кадрами NetBIOS) отвечает за организацию и настройку протокола NBF для соединений PPP. Протокол применим только для оконечных систем, подключенных к системам того же ранга или локальным сетям.

Формат кадров NBFCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов NBFCP

Код

Однооктетное поле, определяющее тип пакета NBFCP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета NBFCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Длина этого поля может быть равна 0. Формат конфигурационных опций NBFCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции NBFCP

Тип

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

1. Name-Protection.

2. Peer-Information.

3. Multicast-Filtering.

4. IEEE-MAC-Address-Required.

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

 

Распределение трафика по кодам NBFCP

OSINLCP

RFC 1377 http://www.ietf.org/rfc/rfc1377.txt

Протокол OSINLCP (OSI Network Layer Control Protocol — протокол управления сетевого уровня OSI) отвечает за настройку, разрешение и запрещение протокольных модулей OSI на обеих сторонах соединений «точка-точка». OSINLCP использует такой же механизм обмена пакетами, как протокол LCP (Link Control Protocol). Обмен OSINLCP-пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня.

Формат кадров OSINLCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов OSINLCP

Код

Однооктетное поле, определяющее тип пакета OSINLCP. При получении пакетов с неизвестным кодом передается пакет Code Reject.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета OSINLCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции.

SDCP

RFC 1963 http://www.ietf.org/rfc/rfc1963.txt

Протокол SDCP (PPP Serial Data Control Protocol — протокол управления последовательной передачей) отвечает за настройку, разрешение и запрещение протокола SDTP (Serial Data Transport Protocol последовательный транспортный протокол) на обеих сторонах соединений «точка-точка». OSINLCP использует такой же механизм обмена пакетами, как протокол LCP (Link Control Protocol). Обмен SDCP-пакетами невозможен до тех пор, пока PPP не достигнет фазы протокола сетевого уровня.

Формат кадров OSINLCP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов SDCP

Код

Однооктетное поле, определяющее тип пакета SDCP. При получении пакетов с неизвестным кодом передается пакет Code Reject.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета SDCP.

Данные

Поле данных переменной длины может содержать конфигурационные опции. Формат конфигурационных опций SDCP показан на рисунке.

 

Тип

Размер

Данные

 

Конфигурационные опции SDCP

Тип

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

1. Packet-Format.

2. Header-Type.

3. Length-Field-Present.

4. Multi-Port.

5. Transport-Mode.

6. Maximum-Frame-Size.

7. Allow-Add-Frames.

8. FCS-Type.

9. Flow-Expiration-Time.

Размер

Размер всех полей конфигурационных опций (тип, размер, данные).

Данные

Значение поля данных.

SNACP

RFC 2043 http://www.ietf.org/rfc/rfc2043.txt

Протокол SNACP (SNA PPP Control Protocol — протокол управления SNA) отвечает за настройку, разрешение и запрещение протокола на обеих сторонах соединений «точка-точка». Отметим, что реально существует два протокола управления SNA — один протокол для LLC 802.2 и другой — для SNA без LLC 802.2. Эти протоколы согласуются независимо один от другого. Для организации соединения через канал «точка-точка» каждая из сторон канала PPP должна сначала передать пакеты LCP для организации и проверки соединения. После организации соединения и согласования его параметров в соответствии с требованиями LCP протокол PPP может передавать пакеты SNACP для выбора и настройки протокола сетевого уровня SNA. После того, как SNACP достигнет открытого состояния, через канал можно будет передавать дейтаграммы SNA.

Формат пакетов SNACP показан на рисунке.

Код	Идентификатор	Размер	Данные
1 байт	1 байт	2 байта	Переменный размер

Структура пакетов SNACP

Код

Однооктетное поле, определяющее тип пакета SNACP.

1 Configure-Request

2 Configure-Ack

3 Configure-Nak

4 Configure-Reject

5 Terminate-Request

6 Terminate-Ack

7 Code-Reject

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

Десятичное значение, идентифицирующее соответствующий запрос или отклик.

Размер

Размер всех полей пакета SNACP.

Данные

Значение поля данных.

Стек протоколов Novell NetWare создан под влиянием архитектуры XNS (Xerox Network System). Протоколы Novell обеспечивают поддержку большинства существующих операционных систем для настольных компьютеров, включая DOS, Windows, Macintosh, OS/2 и UNIX. Кроме того, Novell обеспечивает эффективную поддержку локальных сетей и распределенных сетей на базе асинхронных соединений. Стек Novell включает следующие протоколы:

IPX:	Internetwork Packet Exchange
BCAST:	Broadcast
BMP:	Burst Mode Protocol
DIAG:	Diagnostic Responder
NCP:	NetWare Core Protocol
NDS:	NetWare Directory Service
NLSP:	NetWare Link Service Protocol
NovellNetBIOS
RIPX:	Routing Information Protocol
SAP:	Service Advertising Protocol
SER:	Serialization
SPX:	Sequenced Packet Exchange
WDOG:	Watchdog

На рисунке показано расположение стека протоколов Novell в эталонной модели OSI.

 

Положение стека протоколов Novell в эталонной модели OSI

IPX

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол IPX (Internetwork Packet Exchange — межсетевой обмен пакетами) разработан компанией Novell на основе протокола IDP (Internet Datagram Protocol – межсетевой протокол обмена дейтаграммами) фирмы Xerox. IPX относится к числу протоколов без организации соединений (connectionless) и обеспечивает доставку пакетов через Internet, а также поддерживает адресацию и маршрутизацию рабочих станций и серверов NetWare.

Структура пакетов IPX показана на рисунке.

Биты
0							15
Контрольная сумма								 Заголовок IPX 
Длина пакета
Транспортный контроль				Тип пакета
Сеть получателя (4 байта)
Узел-получатель (6 байтов)
Сокет-получатель
Сеть отправителя (4 байта)
Узел-отправитель (4 байта)
Сокет-отправитель
Данные (содержат информацию RIP, SAP, SPX, NCP и т. д.)

Структура пакета IPX

Контрольная сумма

В поле контрольной суммы содержится значение FFFFH

Длина пакета

Размер дейтаграммы IPX в октетах.

Транспортный контроль

Данное поле используется маршрутизаторами, работающими с протоколом IPX. Перед передачей пакета протокол IPX устанавливает для этого поля нулевое значение.

Тип пакета

Это указывает тип информации, содержащейся в пакете:

0 Hello или SAP.

1 RIP.

2 Эхо-пакет.

3 Пакет, содержащий информацию об ошибке.

4 NetWare 386 или SAP.

5 Протокол SPX (Sequenced Packet Protocol).

16-31 Экспериментальные протоколы.

17 NetWare 286.

Номер сети.

Номер сети является 32-битовым числом, которое задает сетевой администратор. При локальном использовании сети (отсутствуют соединения с другими сетями IPX) для этого поля можно задать нулевое значение.

Номер узла.

Номером узла является 48-битное число, идентичное аппаратному адресу сетевого адаптера. Для широковещательных сообщений используется номер узла FFFF FFFF FFFF. Адрес 0000 0000 0000 в NetWare версий 3.x и 4.x используется для сервера.

Номер сокета

16-битовое поле, служащее для идентификации пакетов вышележащих уровней:

0451H NCP.

0452H SAP.

0453H RIP.

0455H NetBIOS.

0456H Диагностика.

0x457 Пакет проверки серийных номеров (SER).

4000-6000H Номера сокетов, используемые для файл-серверов и сетевых соединений.

BCAST

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол Broadcast (BCAST — широковещание) обеспечивает извещение пользователей о приеме для них сообщений по сети.

Формат пакетов протокола BCAST показан на рисунке.

Биты
			8				16
Номер соединения				Символ подписи

Структура пакета BCAST

Номер соединения

Номер соединения выдается сетевой станции во время входа в сеть (login).

Символ подписи

Значение данного поля равно 0x21 (символ ASCII «!») и обозначает ожидание широковещательного сообщения (Broadcast Message Waiting).

BMP (Burst)

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол BMP (Burst Mode Protocol – протокол группового режима) реально использует пакеты протокола NCP (тип запроса – 7777H). Протокол BMP обеспечивает поддержку нескольких откликов на один запрос чтения или записи файла. Пакетный режим повышает эффективность взаимодействия между сервером и клиентами, позволяя рабочим станциям получить (передать) от сервера до 64 кбайт данных по единственному запросу на чтение или запись. При описании протокола BMP будем использовать для термина burst (взрыв, пакет) русский термин «группа» во избежание путаницы с термином «пакет».

Формат пакетов BMP показан на рисунке.

 

Биты
			16		24		32
Тип запроса				Флаги потока		Тип потока
Идентификатор отправителя в соединении
Идентификатор получателя в соединении
Порядковый номер пакета
Задержка передачи
Порядковый номер группы				Порядковый номер подтверждения
Общая длина группы
Смещение в группе
Длина пакета				Количество элементов в списке
Список пропущенных фрагментов
Код функции
Дескриптор файла
Начальное смещение
Количество байтов для записи

 

Структура пакета BMP

Тип запроса

Это поле идентично полю Request Type (тип запроса) в пакетах NCP и всегда имеет значение 7777H (пакет группового режима).

Флаги потока

Поддерживаемые флаги.

Тип потока

Биты управления групповым режимом.

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

Идентификатор соединения для рабочей станции-отправителя.

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

Идентификатор соединения для рабочей станции-получателя.

Порядковый номер пакета

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

Задержка передачи

Промежуток времени между передачей последовательных пакетов.

Порядковый номер группы

Порядковый номер передаваемой группы.

Порядковый номер подтверждения

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

Общая длина группы

Размер передаваемой группы в октетах.

Смещение в группе

Положение пакета в группе.

Длина пакета

Размер данных группы в октетах.

Количество элементов в списке

Количество элементов в списке отсутствующих фрагментов.

Список пропущенных фрагментов

Перечень фрагментов данных, которые еще не были получены.

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

Код функции

Функция чтения/записи.

Начальное смещение

Смещение для начала записи (чтения).

Количество байтов для записи

Количество байтов для записи (чтения).

Пример декодирования пакета BMP.

DIAG

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол диагностики (Diagnostic Responder или DIAG) является удобным инструментом анализа локальных сетей NetWare. Протокол DIAG можно использовать для тестирования соединений, проверки конфигурации или сбора информации.

Структура запросов протокола DIAG показана на рисунке.

Число исключенных адресов (1 байт)

Исключенный адрес 0 (6 байтов)

. . .

Исключенный адрес 79 (6 байтов)

Структура запроса DIAG

Число исключенных адресов

Значение этого поля показывает количество рабочих станций, которым запрос не был передан. Нулевое значение счетчика говорит о передаче запроса всем станциям и станции должны ответить на этот запрос. Максимальное значение для этого поля равно 80 (исключены адреса 0 — 79).

На следующем рисунке показана структура откликов на запросы протокола DIAG.

Биты
			8				16
Старший байт версии				Младший байт версии
Диагностический сокет SPX
Счетчик компонент
Тип компоненты 0 (переменная длина)

Структура ответа DIAG

Версия

Версия программы диагностики по протоколу DIAG, поддерживаемая отвечающей станцией.

Диагностический сокет SPX

Номер сокета SPX, которому могут быть адресованы все диагностические отклики.

Счетчик компонент

Количество компонент, содержащихся в пакете отклика.

Тип компоненты

Это поле содержит информацию об одной из компонент или активном процессе на отвечающей станции.

Основные типы:

0 = IPX/SPX.

1 = Драйверы маршрутизации.

2 = Драйверы LAN.

3 = Оболочки.

4 = VAP.

Расширенные типы:

5 = Маршрутизатор.

6 = Файловый сервер/маршрутизатор.

7 = Невыделенный IPX/SPX.

За полем расширенного типа следуют дополнительные поля.

Число локальных сетей (1 байт)

Дополнительное поле в DIAG

Число локальных сетей

Количество ЛВС, с которыми работать данная компонента.

Для каждой локальной сети в пакет включается следующая информация:

Тип локальной сети (1 байт)

Адрес сети (4 байта)

Адрес узла (6 байт)

Формат для локальных сетей

Тип локальной сети

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

Адрес сети

4-байтовый адрес, выделенный сети, которая указана в поле «Тип локальной сети».

Адрес узла

6-байтовый адрес узла, используемый вместе с адресом сети.

Пример декодирования пакета DIAG.

NCP

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол NCP (NetWare Core Protocol — протокол ядра NetWare) используется для управления доступом к основным ресурсам сервера NetWare. Для получения доступа к ресурсам NCP вызывает процедуры протокола NetWare NFSP (File Sharing Protocol – протокол разделения файлов). Протокол NFSP обслуживает запросы к файловым и принтерным ресурсам NetWare.

Формат заголовка запроса NCP показан на следующем рисунке. Поле тип запроса имеет длину 2 байта. Все остальные поля имеют длину 1 байт.

 

Тип запроса

Порядковый номер

Младшая часть номера соединения

Номер задания

Старшая часть номера соединения

Код запроса

Данные (переменная длина)

 

Формат заголовка запроса NCP

Тип запроса

Идентифицирует тип пакета:

1111H Запрос на выделение слота.

2222H Запрос к файловому серверу.

3333H Ответ файл-сервера.

5555H Запрос на освобождение слота.

7777H Пакет группового режима (BMP).

9999H Подтверждение приема.

Символ H означает шестнадцатеричное число.

Порядковый номер

Число, используемое сервером и рабочей станцией для идентификации пакетов.

Младшая часть номера соединения

Младшая часть идентификатора соединения, выделенного рабочей станции.

Номер задания

Поле используется для идентификации операционной системы, используемой заданием (например, DOS).

Старшая часть номера соединения

Младшая часть идентификатора соединения, выделенного рабочей станции. Это поле применяется только в версии NetWare на 1000 пользователей. Для всех других версий значение этого поля равно нулю.

Код запроса

Идентифицирует код функции указанного запроса.

Для заголовка пакетов NCP Reply (отклик) используется структура, аналогичная структуре заголовка запросов. Различаются лишь последние два байта, следующие за полем «Старшая часть номера соединения». На следующем рисунке показаны эти байты.

 

Код завершения

Статус соединения

 

Последние 2 байта заголовка откликов NCP

Код завершения

Нулевое значение кода завершения показывает, что запрос был обработан без ошибок. Любое другое значение говорит об ошибке при обработке запроса.

Статус соединения

При вводе с консоли сервера команды DOWN четвертый бит байта состояния будет установлен в 1.

NDS

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

NDS (NetWare Directory Service – служба каталогов NetWare) является глобально распределенной сетевой базой данных, используемой вместо принятой в ранних версиях NetWare базы bindery. В сети, поддерживающей сервис NDS, для получения доступа ко всем сетевым ресурсам достаточно один раз зарегистрироваться в сети (не требуется регистрации на каждом сервере).

Формат пакетов NDS показан на рисунке.

 

Биты
	8		16		24		32
Дескриптор фрагментирования
Максимальный размер фрагмента
Размер сообщения
Флаг фрагментации
Внутренняя команда

 

Структура пакетов NDS

Дескриптор фрагментации

Дескриптор фрагментированного запроса или отклика.

Максимальный размер фрагмента

Максимальное число байтов данных, которые могут быть переданы в ответ.

Размер сообщения

Реальный размер передаваемого сообщения.

Флаг фрагментации

Это поле всегда имеет нулевое значение.

Внутренняя команда

Номер команды NDS, которая должна быть выполнена.

NLSP

Novell publication NetWare Link Services Protocol Specification rev 1.0

NLSP^tm (NetWare Link Service Protocol — протокол канального сервиса NetWare) является протоколом маршрутизации на основе состояния каналов (link state) для сетей IPX. Этот протокол обеспечивает требуемый обмен информацией между маршрутизаторами в больших сетях IPX. Протокол IPX используется на сетевом уровне Novell NetWare.

Формат заголовка NLSP показан на рисунке.

 

Биты
		8		16		24		32
Идентификатор протокола			Длина		Младший байт версии		Резерв
NR	R	Тип пакета	Старший байт версии		Зарезервировано
Длина пакета

 

Структура заголовка NLSP

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

Указывает на уровень маршрутизации NLSP.

Длина

Размер фиксированной части заголовка в байтах.

Младший байт версии

Это поле равно 1.

NR

Это поле имеет значение 1 для серверов multi-homed non-routing (несколько сетевых адаптеров без поддержки маршрутизации между ними).

R

Зарезервированное поле размером 2 бита.

Тип пакета

Типа пакета.

Старший байт версии

Это поле равно 1.

Длина пакета

Полный размер пакета (в байтах) с учетом фиксированной части заголовка NLSP.

NovelNetBIOS

Этот протокол был разработан компанией Novell на основе протокола NetBIOS.

В пакетах протокола NovelNetBIOS поле типа потока данных имеет фиксированный размер (1 байт), а остальные поля имеют переменную длину.

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

1. Найти имя.
2. Имя опознано.
3. Проверить имя.
4. Имя используется.
5. Отменить регистрацию имени.
6. Данные сессии.
7. Завершение сеанса.
8. Подтверждение конца сессии.
9. Запрос состояния.
10. Ответ на запрос о состоянии.
11. Направленная дейтаграмма.

RIPX

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол маршрутной информации RIPX (Routing Information Protocol) используется для сбора, поддержки и обмена корректной информацией о маршрутах между шлюзами в Internet. Следует отличать описываемый здесь протокол от протокола RIP в стеке TCP/IP.

Формат пакета RIPX показан на рисунке.

 

Биты
							16
Операция
Номер сети (4 байта)
Количество интервалов
Количество тактов
. . .

 

Формат пакета RIPX

Операция

Указывает тип пакета.

1. Запрос RIP.
2. Отклик RIP.

Номер сети

32-битовый адрес сети.

Количество интервалов

Количество маршрутизаторов, через которые будет передан пакет для достижения указанной сети. Для маршрутов, которые стали недоступны, маршрутизаторы передают в широковещательном режиме пакеты «going dowm», содержащие в этом поле значение 16.

Количество тактов

Мера времени, необходимого пакету для достижения указанной сети (1 такт = 1/18,21 с).

SER

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Для обеспечения корректности лицензирования серверных программ в сети NetWare каждый сервер передает в широковещательном режиме специальные пакеты (Serialization). Эти пакеты содержат серийный номер серверных программ и позволяют зафиксировать наличие в сети двух или более копий одного комплекта программ.

Пакеты проверки содержат только одно 6-байтовое поле данных.

SAP

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Прежде, чем станция-клиент сможет установить соединение с сервером, она должна узнать об имеющихся в сети серверах. Для обеспечения станций требуемой информацией служит протокол SAP (Service Advertising Protocol — протокол анонсирования сервиса). Протокол SAP обеспечивает распространение информации обо всех серверах, присутствующих в сети предприятия. В качестве таких серверов могут выступать файловые серверы, сервера печати и доступа, а также серверы иных типов.

Структура откликов SAP показана на рисунке.

 

Операция (2 байта)

Тип сервиса (2 байта)

Имя сервера (48 байтов)

Адрес сети (4 байта)

Адрес узла (6 байтов)

Адрес сокета (2 байта)

Интервалы (2 байта)

. . .

 

Структура отклика SAP

Число серверов, информация о которых может содержаться в одном отклике SAP, достигает 7.

Операция

Это поле задает выполняемую пакетом операцию.

1. Общий запрос о наличии сервиса.
2. Отклик на общий ответ о предлагаемом сервисе.
3. Запрос ближайшего сервиса
4. Отклик на запрос ближайшего сервиса.

Тип сервиса

Поле типа сервиса может принимать несколько значений:

01H Пользователь.

04H Файловый сервер.

07H Сервер печати.

21H Шлюз NAS SNA.

23H NACS.

27H Шлюз TCP/IP.

98H Сервер доступа NetWare.

107H NetWare 386 SROREXP Spec.

137H Очередь печати NetWare 386.

Символ H означает шестнадцатеричное число.

Имя сервера

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

Адрес сети

32-битовый номер сети для сервера.

Адрес узла

48- битовый адрес сервера.

Адрес сокета

16- битовый номер сокета на сервере.

Интервалы

Число маршрутизаторов, через которые будет передан пакет для достижения указанной сети. Если маршрут по каким-либо причинам перестал быть доступным, поле счетчика интервалов содержит значение 16.

Структура заголовка запроса SAP показана на рисунке.

 

Операция (2 байта)

Тип сервиса (2 байта)

 

Структура запроса SAP

SPX

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол SPX (Sequenced Packet Exchange – последовательный обмен пакетами) был разработан компанией Novell на основе протокола SPP (Sequenced Packet Protocol — протокол последовательной передачи пакетов) фирмы Xerox. Протокол работает на транспортном уровне и обеспечивает доставку пакетов для приложений вышележащих уровней.

В июле 1991 года компания Novell начала разработку следующей версии протокола SPX — SPX II. Основными улучшениями в SPX II по сравнению с SPX является поддержка пакетов большего размера и возможность использования протоколов с поддержкой окон.

Структура пакетов SPX показана на рисунке.

 

Биты
			8				16
Флаги управления соединением				Тип потока данных
Идентификатор отправителя
Идентификатор получателя
Порядковый номер
Число подтвержденных пакетов
Число неподтвержденных пакетов
0 — 543 байтов данных

 

Структура пакета SPX

Флаг управления соединением

Соединение SPX использует 4 флага, которые управляют двунаправленным потоком данных. Единичное значение флага означает поддержку соответствующей функции.

Бит 4 Eom — конец сообщения.

Бит 5 Att: — бит “внимание”, не используемый в SPX.

Бит 6 Ack: — требуется подтверждение приема данных.

Бит 7 Sys: Транспортный контроль.

Тип потока данных

Это поле указывает тип содержащихся в пакете данных:

0-253 Игнорируется протоколом SPX.

254 Окончание соединения

255 Подтверждение окончания соединения.

Идентификатор отправителя

16-битовое число, выделяемое протоколом SPX для идентификации соединения.

Идентификатор получателя

Число, используемое для идентификации получателя в соединении SPX.

Порядковый номер

16-битовое число, показывающее порядковый номер пакета SPX.

Число подтвержденных пакетов

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

Число неподтвержденных пакетов

16-битовое число, показывающее количество переданных, но не подтвержденных пакетов.

Протокол SPX II использует аналогичную структуру заголовка пакетов с двумя отличиями.

Флаг управления соединением

Бит 2 Согласование размера.

Бит 3 Тип SPX II.

Тип потока данных

252 Запрос на обычное разъединение.

253 Подтверждение обычного разъединения.

Кроме того, в конце заголовка присутствует дополнительное двухбайтовое поле Extended Acknowledgment (расширенное подтверждение).

WDOG

«Novell’s Guide to NetWare LAN Analysis» by Laura A. Chappell and Dan E. Hakes, Novell Press, 1994.

Протокол WDOG (Watchdog – сторожевая собака) обеспечивает постоянную проверку соединений активных рабочих станций и уведомляет операционную систему NetWare, если соединение может быть закрыто в результате продолжительного бездействия.

Структура пакета WDOG показана на рисунке.

 

Биты
			8				16
Номер соединения				Символ подписи

 

Структура пакета WDOG

Номер соединения

Выдается станции при регистрации в сети.

Символ подписи

Поле подписи содержит значение 0x3F (символ ASCII «?») или 0x59 (ASCII «Y»).

ATM имеет много преимуществ при использовании в качестве магистральной технологии локальных сетей (в частности, эффективное масштабирование и высокая пропускная способность магистралей). Для обеспечения возможности использования традиционных технологий ЛВС совместно с магистралями ATM были разработаны стандарты, позволяющие обеспечить поддержку протоколов ЛВС в сетях ATM. Эмуляция ЛВС (LAN Emulation или LANE) является одним из таких методов и позволяет использовать сети ATM для передачи пакетов Ethernet или Token Ring. Эмуляция ЛВС реализуется в оборудовании ATM и обеспечивает две основных возможности:

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

Назначение протокола LANE (LAN Emulation — эмуляция ЛВС) состоит в эмуляции протоколов ЛВС Ethernet 802.3 или Token Ring 802.5 на базе сетей ATM. Протокол LANE, прежде всего, определяет сервисные интерфейсы для протоколов вышележащих уровней, идентичные существующему сервису ЛВС. Данные передаются через сеть ATM с инкапсуляцией приемлемый формат MAC-уровня ЛВС. Таким образом, протоколы LANE представляют сеть ATM для традиционных сетевых приложений как обычную ЛВС (стандарт ATM Forum LANE v1.0), которая лишь работает значительно быстрее.

 

Протоколы ЛВС, передаваемые с помощью LANE.

Компоненты LANE

Протокол LANE включает несколько компонент, используемых для реализации различных функций — клиент LEC (LAN Emulation Client), сервер эмуляции ЛВС (LAN Emulation Server — LES), конфигурационный сервер LECS (LAN Emulation Configuration Server) и сервер широковещания (Broadcast and Unknown Server — BUS). Каждая из компонент LANE описана ниже.

LEC-клиент

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

LES — сервер эмуляции ЛВС

Сервер LES выполняет функции регистрации (позволяет станциям регистрировать свои адреса MAC и ATM) и преобразования (обработка запросов ARP для преобразования адресов MAC — ATM) адресов. Каждая эмулируемая ЛВС может содержать только один сервер LES. Однако физическая ЛВС может работать с несколькими LANE одновременно, при этом каждая эмулируемая сеть будет иметь свой сервер LES.

LECS — конфигурационный сервер LANE

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

BUS — сервер широковещания

Сервер BUS поддерживает работу с широковещательными и групповыми (broadcast и multicast) пакетами. Кадры передаются с участием серверов BUS в двух случаях:

• если информация должна быть передана всем станциям — широковещание.
• Если LEC-клиент послал серверу LES запрос ARP и хочет передать данные, не дожидаясь ответа на этот запрос. В таком случае LEC передает информацию серверу BUS, который рассылает пакеты по всей сети.

Каждая эмулируемая ЛВС может включать только один сервер BUS. Однако физическая ЛВС может работать одновременно с несколькими LANE, при этом каждая эмулируемая ЛВС содержит свой сервер BUS.

Расположение компонент сервиса LANE

Спецификации ATM Forum задают три отдельных логических компоненты эмуляции ЛВС (LES, LECS и BUS), однако в спецификациях не указан способ физической реализации этих типов сервиса — они могут находиться в одной сети или в разных. Принятие решений о месте расположения этих компонент отдано на откуп производителями оборудования.

Многие производители объединяют LES, LECS и BUS в одном физическом устройстве. Существуют два популярных варианта подобной реализации:

1. Все типы сервиса реализованы в коммутаторах.

2. Сервис реализуется на отдельной станции, которая подключается ко всем коммутаторам.

Передача данных через ELAN

Существует несколько стадий организации соединения через эмулируемую ЛВС. В данном разделе эти стадии описаны с точки зрения LEC-клиента.

Для организации транзитных соединений LANE использует сигнальные протоколы. Каждый клиент LEC имеет уникальный (в масштабе сети) адрес ATM в одном из форматов, поддерживаемых сигнальной спецификацией ATM Forum UNI 3.0. Для организации соединения в сетях ATM используются сообщения SETUP, содержащие элемент B-LLI (Broadband Low-Layer Information — информация нижележащего уровня), которые используются для идентификации соединений LANE.

Поле идентификатора протокола в элементе B-LLI имеет формат ISO/IEC TR/9577. Поддерживается несколько типов идентификатора протокола:

• Управляющее соединения.
• Передача данных 802.3.
• Передача данных 802.5
• Передача группового трафика 802.3.

• Передача группового трафика 802.5.

Инициализация

На этапе инициализации LEC-клиент должен определить тип эмулируемой ЛВС, к которой он подключается, и адреса серверов LECS и LES.

Для определения ATM-адреса LECS-сервера клиент LEC выполняет следующие операции:

3. Предпринимается попытка получить адрес сервера LECS от коммутатора с использованием протокола ILMI. При получении адреса LEC пытается установить соединение по этому адресу.
4. В случае неудачи используются хорошо известные (well-known) адреса ATM и предпринимается попытка организации SVC.
5. При неудаче LEC-клиент пытается организовать PVC с VPI = 0 и VCI = 17.

6. Если и в этом случае не удается организовать соединение, LEC пытается связаться с сервером LES.

Настройка конфигурации

После организации соединения между LEC и LECS начинается сеанс начального обмена информацией.

• LEC сообщает ATM-адрес, адрес MAC и запрашивает тип ЛВС и размер кадров.

• LECS возвращает клиенту LEC адрес сервера LES, а также тип ЛВС и принятый размер кадров.

Соединение

На этом этапе LEC пытается подключиться к эмулируемой ЛВС, выполняя следующие операции:

• Организация прямого двухстороннего виртуального соединения VCC с сервером LES, используемое для управления.
• Передача запроса на соединение (Join Request), содержащего запрос адреса ATM, информацию о ЛВС и посреднике (proxy), а также (в качестве необязательного параметра) MAC адрес.
• Перед получением запроса на соединение возможна организация Control Distribute VCC.

На этапе организации соединения могут возникать ошибки или соединение не будет организовано в результате тайм-аута.

На рисунке показан пример декодирования на этапе подключения к ELAN:

 

Декодирование на этапе подключения к ELAN

Регистрация и инициализация сервера BUS

Сервер BUS обслуживает широковещательные сообщения, которые LEC-клиенты рассылают другим клиентам LANE. Для решения этих задач сервер должен знать обо всех станциях ATM, принадлежащих к ELAN. Это реализуется путем регистрации каждого клиента LEC на сервере BUS при подключении к эмулируемой ЛВС. Таким образом, клиент LEC должен выполнить следующие операции:

• Регистрация всех MAC-адресов.
• Установить соответствие между MAC-адресом 0xFFFFFFFFFFFF (широковещательный адрес) и ATM-адресом сервера BUS.
• Организовать однонаправленное соединение VCC для передачи данных серверу BUS, которое будет использоваться для передачи широковещательных пакетов.
• Установить однонаправленное соединение VCC по запросу сервера BUS для рассылки последним широковещательных сообщений.

Передача данных

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

• Просмотр внутренней таблицы адресов (кэш) на предмет соответствия MAC-адреса и адреса ATM.
• При отсутствии записи в кэше передается запрос серверу LES.
• До получения ответа от LES клиент может передавать данные с использованием сервера широковещания BUS.
• При получении отклика от LES организуется прямое соединение с использованием сигнального протокола. Информация о соответствии адресов MAC и ATM добавляется в кэш.

• После завершения передачи данных соединение разрывается.

Стек протоколов LANE

Протоколы эмуляции ЛВС реализованы для всех устройствах, включаемых в ELAN (рабочие станции, коммутаторы, сетевые адаптеры, маршрутизаторы и т. д.) На рисунке схематически показано взаимодействие протоколов стека эмуляции ЛВС.

Стек протоколов эмуляции ЛВС

Конечные точки соединений (серверы и рабочие станции) используют традиционные приложения ЛВС через драйверы NDIS/ODI (в приведенном примере). На нижележащих уровнях ситуация становится иной — на сервере используется эмуляция ЛВС с использованием AAL5, а рабочие станции используют Ethernet. Приложения вышележащих уровней остаются неизменными — они просто не знают об использовании ATM на нижележащих уровнях. Мост поддерживает обе технологии — порт Ethernet подключен к традиционной ЛВС, а порт ATM — к современной сети ATM. Коммутатор работает в обычном режиме ATM и имеет дело только с ячейками и виртуальными соединениями.

Формат пакетов LANE

Пакеты данных

Эмуляция ЛВС поддерживает два формата пакетов данных — для Ethernet и Token Ring. Кадры данных LANE сохраняют при передаче всю информацию, содержащуюся в исходных кадрах 802.3 или 802.5, добавляя двухбайтовый идентификатор LEC (идентификатор отправителя — LEC ID), который уникален для каждого клиента LEC. Формат кадров, используемых для передачи трафика Ethernet, показан на рисунке.

Биты								Октет
			16				32
Заголовок LE (LEC ID)				MAC-адрес получателя				0
MAC-адрес получателя								4
MAC-адрес отправителя								8
MAC-адрес отправителя				Тип/длина				12
Данные								16-n

Формат кадра Ethernet IEEE 802.3

На следующем рисунке показан формат кадров, используемых для передачи трафика Token Ring.

Биты								Октет
			16				32
Заголовок LE (LEC ID)				Заполнение AC		FC		0
MAC-адрес получателя								4
MAC-адрес получателя				MAC-адрес отправителя				8
MAC-адрес отправителя								12
Поле маршрутной информации								16-46
Данные								46-n

Формат кадра Token Ring IEEE 802.5

Поддержка кадров 802.3 и 802.5 в неизменном состоянии обусловлена тем, что они могут потребоваться для некоторых узлов сети. Например, мост ATM — Ethernet принимает эмулируемые со стороны ATM, «вырезает» первые 2 байта, а затем эти кадры его в порт Ethernet.

Управляющие кадры

На рисунке показан формат всех управляющих кадров LANE, за исключением кадров READY_IND и READY_QUERY.

Биты								Октет
			16				32
Маркер = FF00				Протокол = 01		Версия = 01		0
Код операции				Состояние				4
Идентификатор транзакции								8
Идентификатор запрашивающего LEC				Флаги				12
MAC-адрес отправителя								16
MAC-адрес получателя								24
ATM-адрес отправителя								32
Тип ЛВС		Макс. размер кадра		Количество TLVS		Размер имени ELAN		52
ATM-адрес получателя								56
Имя ELAN								76
Начало TLVS								108

Формат управляющих кадров LANE

Код операции

Это поле определяет тип пакета управления и может принимать следующие значения:

0001 LE_CONFIGURE_REQUEST (запрос настройки LE).

0101 LE_CONFIGURE_RESPONSE (отклик для настройки LE).

0002 LE_JOIN_REQUEST (запрос на подключение LE).

0102 LE_JOIN_RESPONSE (отклик на запрос подключения LE).

0003 READY_QUERY (запрос готовности)

0103 READY_IND (индикатор готовности).

0004 LE_REGISTER_REQUEST (запрос регистрации LE).

0104 LE_REGISTER_RESPONSE (отклик на запрос регистрации LE).

0005 LE_UNREGISTER_REQUEST (запрос отмены регистрации LE).

0105 LE_UNREGISTER_RESPONSES (отклик на запрос отмены регистрации LE).

0006 LE_ARP_REQUEST (запрос ARP).

0106 LE_ARP_RESPONSE (отклик ARP).

0007 LE_FLUSH_REQUEST.

0107 LE_FLUSH_RESPONSE.

0008 LE_NARP_REQUEST.

0108 Не определен.

0009 LE_TOPOLOGY_REQUEST (запрос топологии LE).

0109 Не определен.

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

Значение, помещаемое в кадр отправителем и возвращаемое без изменения получателем кадра. Этот идентификатор устройству, посылающему запросы, различать отклики на разные запросы.

Идентификатор запрашивающего LEC

Идентификатор клиента LEC, посылающего запрос (0000 если идентификатор неизвестен).

Флаги

Биты флагов:

0001 для LE_ARP_RESPONSE используется удаленный адрес.

0080 для LE_ARP_RESPONSE используется флаг proxy (Proxy Flag).

0100 для LE_TOPOLOGY_REQUEST используется информация об изменении топологии.

Значения остальных флагов зависят от значения, содержащегося в поле кода операции.

LUNI 2.0

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

				Октет
LLC-X’’AA’’	LLC-X’’AA’’	LLC-X’’03’’	OUI-X’’00’’	0
OUI-X’’A0’’	OUI-X’’3E’’	Тип кадра		4
Идентификатор ELAN				8

Дополнительные поля кадров данных и управления.

Стандарт LINU 2.0 для кадров управления определяет три дополнительных флага:

0002 для LE_CONFIG_REQUEST и LE_JOIN_REQUEST используются возможности версии 2.

0004 для LE_JOIN_REQUEST используется селективная групповая адресация (selective multicast).

0008 для LE_JOIN_RESPONSE необходимо использовать версию 2.

Стандарт LINU 2.0 определяет также два дополнительных значения для поля код операции:

000A LE_VERIFY_REQUEST (запрос на проверку LE).

010A LE_VERIFY_RESPONSE (отклик на запрос проверки).

 

Канальный уровень (Data Link Layer) определяет методы форматирования данных для передачи и методы контроля доступа в сеть. Комитет IEEE 802 предложил разделить этот уровень на два подуровня – управление доступом к среде (MAC или medium access control) и управление логическим каналом (LLC или logical link control).

В этом разделе рассмотрены следующие протоколы канального уровня:

• Ethernet;
• Token Ring;
• FDDI;
• LLC;
• SNAP;
• CIF;
• GARP (Generic Attribute Registration Protocol) – базовый протокол регистрации ресурсов);
• GMRP (GARP Multicast Registration Protocol);
• GVRP (GARP VLAN Registration Protocol);
• VLAN.

FDDI, Token Ring и Ethernet могут рассматриваться как физические интерфейсы или логические протоколы, инкапсулированные в протоколы WAN или ATM.

На приведенном ниже рисунке показано представление протоколов ЛВС в модели OSI.

 

Протоколы ЛВС в модели OSI

Ethernet

ANSI/IEEE 802.3 1933-00

Широко используемый для построения компьютерных сетей стандарт Ethernet был разработан компаниями DEC, Intel и Xerox. В сетях Ethernet используется шинная топология с контролем доступа к среде по методу CMSA/CD. Термины Ethernet и стандарт IEEE 802.3 часто используются как синонимы.

Структура заголовка Ethernet показана на рисунке.

 

Получатель	Отправитель	Длина	Данные + заполнение	FCS
6 байтов	6 байтов	2 байта	46 – 1500 байтов	4 байта

 

Структура заголовка Ethernet

Адрес получателя

Поле адреса получателя имеет следующую структуру:

 

I/G

U/L

Биты адреса

 

Структура адреса получателя

I/G Персональный (I) или групповой (G) адрес:

0 персональный адрес DSAP;

1 групповой адрес DSAP.

U/L Универсальный (U) или локальный (L) адрес:

0 универсальный адрес DSAP;

1 локальный адрес DSAP.

Адрес отправителя

Поле адреса отправителя имеет следующую структуру:

 

0

U/L

Биты адреса

 

Структура адреса отправителя

0 Первый бит адреса отправителя всегда имеет нулевое значение.

U/L Универсальный (U) или локальный (L) адрес:

0 универсальный адрес SSAP;

1 локальный адрес SSAP.

Длина/тип

Для протокола Ethernet это поле содержит идентификатор типа Ethernet (используемый отправителем протокол сетевого уровня — значение, превышающее 0x0600).

Для протокола 802.3 значение этого поля (46 – 1500) показывает длину поля данных, представляющего собой инкапсуляцию протокола LLC (заголовок LLC показывает тип вложенного протокола).

Данные + биты заполнения

Протокол LLC.

FCS

Контрольная сумма кадра.

Token Ring

IEEE 802.5 1995-00

Token Ring представляет собой протокол ЛВС, в которых все станции соединены в (логическое) кольцо и каждая станция может принимать данные только от своего ближайшего соседа. Разрешение на передачу определяется специальным маркером (token), передаваемым по кольцу.

Структура заголовка Token Ring показана на рисунке.

 

SDEL	1 байт
Управление доступом	1 байт
Управление кадром	1 байт
Адрес получателя	6 байтов
Адрес отправителя	6 байтов
Сведения о маршрутизации	0 – 30 байтов
Данные (LLC или MAC)	Переменная длина
FCS	4 байта
EDEL	1 байт
Состояние кадра	1 байт

 

Структура заголовка Token Ring

SDEL / EDEL

Начальный (SDEL) или конечный (EDEL) указатель. Оба типа полей используют преднамеренные нарушения манчестерского кодирования, которые позволяют отличить поля SDEL и EDEL в потоке другой информации.

Управление доступом

Поле управления доступом имеет следующий формат:

 

P

P

P

T

M

R

R

R

 

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

PPP Биты приоритета:

000 низший приоритет;

111 высший приоритет.

T Бит маркера:

0 маркер;

1 кадр.

M Счетчик мониторинга:

0 исходное значение;

1 изменено для активного монитора.

R Биты резервирования:

000 резервирование низшего приоритета;

111 резервирование высшего приоритета;

Управление кадром

Формат поля управления кадром показан на рисунке:

 

2 бита	1 бит	1 бит	4 бита
Тип кадра	0	0	Индикатор

 

Структура поля управления

Поле, обозначающее тип кадра может принимать следующие значения:

00 MAC-кадр;

01 кадр LLC;

10 тип кадра не определен;

11. тип кадра не определен.

Следующие два бита всегда имеют нулевые значения.

Индикатор показывает кадры, для которых адаптер использует специальные средства буферизации и обработки:

0000 экспресс-буфер;

0010 предостережение (beacon);

0011 маркер претензий (claim token);

0100 чистка кольца;

0101 присутствует активный монитор;

0110 присутствует неактивный (standby) монитор.

Адрес получателя

Поле адреса получателя имеет следующую структуру:

 

I/G

U/L

Биты адреса

 

Структура адреса получателя

I/G Персональный (I) или групповой (G) адрес:

0 персональный адрес DSAP;

1 групповой адрес DSAP.

U/L Универсальный (U) или локальный (L) адрес:

0 универсальный адрес DSAP;

1 локальный адрес DSAP.

Адрес отправителя

Поле адреса отправителя имеет следующую структуру:

 

RII

U/L

Биты адреса

 

Структура адреса получателя

RII Индикатор маршрутной информации:

0 маршрутная информация отсутствует;

1 маршрутная информация присутствует.

I/G Персональный (I) или групповой (G) адрес:

0 персональный адрес SSAP;

1 групповой адрес SSAP.

Сведения о маршрутизации

Поле маршрутной информации имеет следующую структуру:

 

<-	Поле RI							->
<-	Поля RC			->	<-	Поля RD		->
RT	LTH	D	LF	r	RD1	RD2	…	RDn
3	5	1	6	1	16	16		16	биты
<-	Размер задается полем LTH							->

Структура поля маршрутной информации

RC Управление маршрутизацией.

RDn Дескриптор маршрута.

RT Тип маршрутизации.

LTH Длина.

D Бит направления.

LF Самый большой кадр.

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

Данные

Информационное поле (данные) может содержать данные уровня LLC или MAC. Структура поля показана на рисунке:

Основной вектор		Субвектор 1				Субвектор n
VL	VI	SVL	SVI	SVV	…	SVL	SVI	SVV
2	2	1	1	n	…	1	1	n	биты

Структура информационного поля

VL

Длина основного вектора в октетах (байтах).

VI

Идентификатор основного вектора. Поле VI имеет следующий формат:

4	8	16	биты
Класс получателя	Класс отправителя	Код основного вектора

Идентификатор основного вектора

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

Поля класса отправителя и получателя обеспечивают корректную маршрутизацию в станции кольца:

0 станция кольца;

4 сервер конфигурационных отчетов;

5 сервер параметров кольца;

6 монитор ошибок в кольце.

Код основного вектора

Код основного вектора определяет тип этого вектора:

0x00 отклик;

0x02 предостережение (beacon);

0x03 заявка маркера (claim token);

0x04 очистка кольца;

0x05 присутствует активный монитор;

0x06 присутствует неактивный (standby) монитор;

0x07 проверка дублирования адресов;

0x08 проверка среды ответвления (lobe media test);

0x09 передача вперед;

0x0B удаление станции кольца;

0x0C изменение параметров;

0x0D инициализация станции кольца;

0x0E запрос адреса станции;

0x0F запрос состояния станции;

0x10 запрос присоединения станции;

0x20 запрос инициализации;

0x22 отчет с адресом станции;

0x23 отчет о состоянии станции;

0x24 отчет о подключении станции;

0x25 отчет о новом активном мониторе;

0x26 отчет об изменении SUA;

0x27 отчет о незавершенном уведомлении соседа;

0x28 отчет об ошибке активного монитора;

0x29 отчет об ошибке.

SVL

Длина субвектора в октетах (байтах).

SVI

Код субвектора определяет тип этого вектора:

0x00 тип предостережения (beacon);

0x02 NAUN (Next Address. Upstream Neighbor) – адрес соседней станции, от которой приходят кадры;

0x03 локальный номер кольца;

0x04 присвоение физического номера (местоположение);

0x05 значение таймера ошибок;

0x06 разрешенный приоритет доступа;

0x07 разрешенный приоритет доступа;

0x08 разрешенная среда;

0x09 корреляция;

0x0A SA последнего AMP или SMP;

0x0B физическое местоположение (physical drop number);

0x20 код отклика;

0x21 зарезервирован;

0x22 идентификатор экземпляра;

0x23 номер версии станции кольца;

0x26 возврат данных (wrap);

0x27 пересылка кадра;

0x28 идентификатор станции;

0x29 состояние станции кольца;

0x2A код состояния передачи;

0x2B групповой адрес (адреса);

0x2C функциональный адрес (адреса);

0x2D счетчик изолированных ошибок;

0x2E счетчик неизолированных ошибок;

0x2F идентификатор запроса функции;

0x30 код ошибки;

SVV

Значение субвектора (информационное поле переменной длины).

FCS

Контрольная сумма кадра.

Состояние кадра

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

Декодирование Token Ring

FDDI

FDDI (Fiber Distributed Data Interface) представляет собой технологию передачи данных со скоростью 100 Мбит/с по двойному кольцу (из деревьев). Стандарт FDDI предложен Американским институтом стандартизации (ANSI).

Структура заголовка FDDI показана на рисунке.

Управление кадром	Адрес получателя	Адрес отправителя	Маршрутная информация	Данные	FCS
1	3	3	0 — 15		2	биты

Структура заголовка FDDI.

Управление кадром

Поле управления кадром имеет следующую структуру:

C

L

F

F

Z

Z

Z

Z

биты

Структура поля управления кадром FDDI.

C Бит класса:

0 асинхронный кадр;

1 синхронный кадр.

L Бит длины адреса:

0 16 битов (не используется никогда);

1 48 битов (используется всегда).

FF Биты формата.

ZZZZ Биты управления

Ниже приведены различные варианты битов управления (CLFF ZZZZ — ZZZZ):

0x00 0000 пустой (void) кадр;

1000 0000 стандартный маркер (Non-restricted token);

1100 0000 служебный маркер (Restricted token);

0L00 0001 — 1111 кадр управления станцией;

1L00 1111 SMT-кадр адресации следующей станции;

1L00 0001 — 1111 MAC-кадр;

1L00 0010 MAC beacon frame.

1L00 0011 MAC-кадр заявки.

CL01 r000 — r111 кадр LLC;

0L01 rPPP информационный кадр LLC (асинхронный, PPP = приоритет кадра);

0L01 rrrr информационный кадр LLC (синхронный, r = зарезервировано);

CL10 r000 — r111 зарезервировано для производителей;

CL11 rrrr зарезервировано для будущих стандартов.

Адрес получателя

Поле адреса получателя имеет следующую структуру:

 

I/G

U/L

Биты адреса

 

Структура адреса получателя

I/G Персональный (I) или групповой (G) адрес:

0 персональный адрес DSAP;

1 групповой адрес DSAP.

U/L Универсальный (U) или локальный (L) адрес:

0 универсальный адрес DSAP;

1 локальный адрес DSAP.

Адрес отправителя

Поле адреса отправителя имеет следующую структуру:

 

I/G

RII

Биты адреса

 

Структура адреса получателя

I/G Персональный (I) или групповой (G) адрес:

0 персональный адрес SSAP;

1 групповой адрес SSAP.

RII Индикатор маршрутной информации:

0 маршрутная информация отсутствует;

1 маршрутная информация присутствует.

Маршрутная информация

Структура поля маршрутной информации показана на рисунке.

	Поле RI							
	Поле RC					Поле RD		
RT	LTH	D	LF	r	RD1	RD2	…	RDn
3	5	1	6	1	16	16		16	биты
	Размер задается полем LTH							

Структура поля маршрутной информации

RC Управление маршрутизацией (16 битов).

RDn Дескриптор маршрута.

RT Тип маршрутизации.

LTH Длина.

D Бит направления.

LF Самый большой кадр.

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

Данные (информация)

Информационное поле может содержать протокол LLC, MAC или SMT.

FCS

Контрольная сумма кадра.

LLC

ISO 8802-2 1989-12

RFC 2364, http://www.cis.ohio-state.edu/htbin/rfc/rfc2364.html

Протокол IEEE 802.2 LLC (управление логическим каналом) обеспечивает канальный механизм для протоколов вышележащих уровней. Сервис LLC типа I обеспечивает поддержку каналов передачи данных без организации соединений (connectionless mode), а сервис типа II обеспечивает на канальном уровне сервис на основе организации соединений (connection-oriented).

Структура заголовка LLC показана на рисунке.

 

DSAP	SSAP	Управление	Информация LLC
1 байт	1 байт	1 или 2 байта

 

Структура заголовка LLC

DSAP

Структура поля DSAP (destination service access point – точка доступа к сервису у получателя) показана на рисунке.

 

I/G	Биты адреса

 

Структура поля LLC DSAP

I/G Персональный или групповой адрес:

0 персональный адрес DSAP;

1 групповой адрес DSAP.

SSAP

Структура поля SSAP (source service access point – точка доступа к сервису у отправителя) показана на рисунке.

 

C/R	Биты адреса

 

Структура поля LLC SSAP

C/R Команда (C) или отклик (R):

0 команда;

1 отклик на команду.

Управление

Поле управления показывает тип запрашиваемого сервиса LLC. Структура поля управления показана на рисунке.

	1				8	9	16	биты
Информация	0	N (S)				P/F	N (R)
Управление	1	0	SS	XXXX		P/F	N (R)
Дополнительные	1	1	MM	P/F	MMM

Структура поля управления LLC

N (S) Порядковый номер при передаче.

N (R) Порядковый номер при приеме.

P/F Биты опроса (P) / завершения (F). Передача команды / отклика LLC PDU.

S Биты функций управления:

00 RR (готовность к приему);

01 REJ (отказ – reject);

10 RNR (отсутствие готовности к приему).

X Зарезервировано и должно иметь нулевое значение.

M Биты модификатора функций

Информация LLC

Данные уровня LLC или вышележащие протоколы.

SNAP

RFC 1042, http://www.cis.ohio-state.edu/htbin/rfc/rfc1042.html

Протокол SNAP (SubNetwork Access Protokol – протокол доступа к подсети) используется для инкапсуляции дейтаграмм IP и запросов ARP в сетях IEEE 802. Дейтаграммы IP передаются в сетях IEEE 802 инкапсулированными в 802.2 LLC и канальный уровень SNAP, а также в физические уровни 802.3, 802.4 и 802.5. Заголовок SNAP следует после заголовка LLC и содержит код организации, показывающий, что следующие 16 битов содержат код EtherType (тип Ethernet).

Структура заголовка SNAP показана на рисунках.

 

DSAP	SSAP	Управление
1 байт	1 байт	1 байт

 

Структура заголовка LLC

 

Код организации	EtherType
3 байта	2 байта

 

Структура заголовка SNAP

В присутствии SNAP поля DSAP и SSAP заголовка LLC содержат значения 170 (десятичное число), а поле «Управление» содержит значение 3 (unnumbered information – дополнительная информация).

Код организации

Это поле имеет нулевое значение.

EtherType

Обозначает протокол, инкапсулированный в кадры IEEE 802 (IP = 2048, ARP = 2054 и т. д.).

CIF

ATM Forum Cells in Frames. Version 1.0 21.10.10.1996 1.0

Протокол CIF (Cells In Frames – ячейки в кадрах) описывает механизм передачи ячеек ATM через сегменты сетевых сред и интерфейсные платы, соответствующие спецификациям Ethernet версии 2, IEEE 802.5 Token Ring или IEEE 802.3. Ячейки ATM можно передавать через различные среды, включая оптические кабели и радиочастотные каналы. Технология ATM не связана напрямую с каким-либо физическим уровнем. Протокол CIF определяет новый псевдофизический уровень, который может использоваться для передачи трафика ATM. Этот протокол не является просто механизмом трансляции ячеек в кадры (и обратно) или простой инкапсуляцией. CIF обеспечивает передачу ячеек ATM в кадрах традиционных ЛВС. Протокол CIF определяет взаимодействие между оконечными программами и устройствами с CIF-подключеним (CIF-AD), обеспечивающее возможность поддержки сервиса ATM (включая множество классов обслуживания) с использованием сетевых адаптеров ЛВС (LAN NIC) так же, как это осуществляется при использовании адаптеров ATM (ATM NIC). CIF описывает работу протоколов уровня ATM в существующих ЛВС на основе кадров с обеспечением прозрачности для приложений, использующих ATM API. При передаче по сети Ethernet кадры CIF используют стандартные заголовки и трейлеры Ethernet. Кадры CIF инкапсулируются в Token Ring и LLC за счет использования заголовков SNAP.

Формат заголовка показан на рисунке.

 

1	8			9	11	16		биты
P	Формат CIF			P	FF	Флаги формата
P	Флаги формата			GFC			VPI
VPI		VCI
VCI		PT	C	HEC

 

Структура заголовка CIF

P

Бит четности (Even Parity) для октета (байта).

Формат CIF

Идентификатор формата CIF. Определены только три типа форматов – форматы 0 и 1 используются для сигнализации CIF, формат 2 принят по умолчанию для передачи пользовательского трафика. Форматы 112-127 зарезервированы для экспериментов и выпущенных до принятия стандарта реализаций CIF.

FF

Независимые флаги формата CIF. Эти биты содержат флаги, не зависящие от типа формата CIF. Поля независимых флагов CIF зарезервированы для использования в будущем. Значения флагов установлены в 0 и при получении игнорируются.

Флаги формата

Флаги CIF, зависящие от типа формата CIF.

GFC

Базовое управление потоком (Generic Flow Control). Структура и семантика октетов 3-7 в заголовке CIF совпадают со структурой и семантикой соответствующих полей в заголовке ячеек ATM UNI. Эти октеты называют «шаблоном заголовка ячеек CIF» (CIF cell header template).

VPI

Virtual Path Identifier – идентификатор виртуального пути.

VCI

Virtual Channel Identifier — идентификатор виртуального канала.

PT

Payload Type – тип обслуживания.

C

Cell Loss Priority – приоритет потери ячеек.

HEC

Header Error Check – контроль ошибок в заголовке. Отправитель кадра ЛВС всегда рассчитывает контрольную сумму заголовка и помещает ее в поле HEC. Получатель может использовать для обнаружения ошибок использовать контрольную сумму кадра (LAN CRC) без контроля значения HEC или проверять наличие ошибок на основании HEC.

GARP

IEEE 802.1P: http://standards.ieee.org/catalog/IEEE802.1.html

Протокол GARP (Generic Attribute Registration Protocol – базовый протокол регистрации атрибутов) обеспечивает возможность рассылки атрибутов, служащую подписчикам в приложениях GARP для регистрации и исключения (de-register) значений атрибутов у других участников GARP в ЛВС на базе мостов (Bridged LAN). Участник (подписчик) GARP на базе моста или пользовательской станции содержит прикладную компоненту (application component) GARP и информационную декларацию GARP (GARP Information Declaration или GID), связанные с каждым портом моста. Распространение информации между участниками GARP для одного приложения на базе моста осуществляется за счет компоненты распространения информации GARP (GARP Information Propagation или GIP). Обмен протокольными данными между участниками GARP осуществляется на базе сервиса LLC типа 1, с использованием групповых адресов MAC и формата PDU, определенного для приложений GARP.

Формат GARP PDU показан на рисунках.

 

2 байта
Идентификатор протокола	Сообщение

 

Структура заголовка GARP PDU

 

 

1 байт
Тип атрибута	Атрибут 1	…	Атрибут n	Маркер завершения

 

Структура сообщения GARP

 

 

1 байт	1 байт	1 байт
Длина атрибута	Событие атрибута	Значение атрибута

 

Структура атрибута GARP

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

Идентификатор протокола указывает на протокол GARP.

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

Десятичное значение, используемое в запросах и откликах.

Тип атрибута

Определяет атрибут и может принимать два значения:

1 атрибут группы;

2 атрибут запроса сервиса.

Длина атрибута

Размер атрибута.

Событие атрибута

Связанное с атрибутом событие. Это поле может принимать следующие значения:

0 оставить все (Leave_all);

1 оператор Join_Empty;

2 оператор Join_In;

3 оператор Leave_Empty;

4 оператор Leave_In;

5 пустой оператор

Значение атрибута

Значение этого поля устанавливается в соответствии со спецификацией для типа атрибута.

Маркер завершения

Маркер завершения имеет нулевое значение.

GMRP

IEEE 802.1P: http://standards.ieee.org/catalog/IEEE802.1.html

Протокол GMRP (GARP Multicast Registration Protocol – протокол групповой регистрации GARP) обеспечивает механизм, позволяющий мостам и конечным станциям динамически регистрировать принадлежность к группе в мостах MAC, подключенных к тому же сегменту ЛВС, и обеспечивающий всем мостам в сети Bridged LAN возможность поддерживать расширенный сервис фильтрации кадров. Работа протокола GMRP основана на сервисе, обеспечиваемом протоколом GARP.

Пакеты GMRP имеют такой же формат, как пакеты протокола GARP. Однако поле атрибутов имеет другое назначение, специфическое для протокола GMRP. Поле атрибутов может принимать значения:

1 тип атрибута группы;

2 тип атрибута запроса сервиса.

GVRP

IEEE 802.1P: http://standards.ieee.org/catalog/IEEE802.1.html

Протокол GVRP (GARP VLAN Registration Protocol – протокол регистрации GARP VLAN) определяет приложения GARP, обеспечивающие сервис регистрации VLAN. Этот протокол использует значения GID и GIP, обеспечивающие общее описание состояния машины и общие сведения о механизмах распространения, определенных для использования в приложениях на базе GARP.

Формат пакетов GVRP совпадает с форматом GARP, отличаясь лишь назначением поля типа атрибута. Это поле принимает значение 1 для группового атрибута VID (VID Group Attribute Type).

VLAN

IEEE 802.1P: http://standards.ieee.org/catalog/IEEE802.1.html

Виртуальная ЛВС (VLAN) представляет собой логическую группу сегментов ЛВС, не зависящую от физического местоположения и организованную на основе общего набора критериев. VLAN отмечает кадры для того, чтобы можно было на основе этих меток (тегов) определить принадлежность кадров к VLAN. Значение поля VID в заголовке тега (Tag Header) идентифицирует VLAN. Это дополнительное поле тегов появляется в протоколах Ethernet и SNAP.

Кадры Ethernet

Формат кадров Ethernet с заголовком тега (Tag Header) показан на рисунке.

 

Биты								Октеты
8	7	6	5	4	3	2	1
ETPID								1 2
TCI								3 4
Длина/тип
E-RIF								7-n

 

Формат кадра Ethernet с теговым заголовком.

ETPID

Идентификатор тегового протокола Ethernet (Ethernet-coded Tag protocol Identifier). Это поле имеет значение 81-00

TCI

Информация для управления тегом (Tag control Information). Поле TCI имеет следующую структуру:

 

Биты								Октеты
8	7	6	5	4	3	2	1
Приоритет пользователя			CFI	VID				1
VID								2

 

Структура поля TCI.

Приоритет пользователя

Трехбитовое значение приоритета пользователя от 0 до 7.

CFI

Канонический идентификатор формата (Canonical Format Indicator). При установке этого бита присутствует поле E-RIF и бит NCFI определяет канонический или неканонический формат адресов MAC, передаваемых в этом кадре. Когда этот бит сброшен (0), поле E-RIF не используется и вся адресная информация MAC-уровня, содержащаяся в кадре, имеет канонический формат.

VID

Идентификатор VLAN (VLAN Identifier) – уникальный номер виртуальной сети, которой принадлежит данный кадр.

0 нулевое значение VLAN ID показывает что заголовок тега содержит только информацию о приоритете пользователя и не включает идентификатор виртуальной сети (VLAN ID);

1 используется принятое по умолчанию значение PVID для классификации кадров при прохождении их через порт моста;

FFF зарезервированное значение.

Все остальные значения идентификатора могут использоваться в качестве уникальных номеров VLAN.

E-RIF

Вложенный формат RIF (Embedded RIF format). Это поле используется только при установке флага CFI в поле TCI и содержится в кадре сразу же после поля типа/длины (Length/Type). Поле E-RIF содержит две компоненты – 2-октетное поле контроля маршрута (Route Control или RC) и необязательное поле описания маршрутов (Route Descriptors), размер которого составляет от 0 до 28 октетов. Общий размер поля E-RIF составляет 2 — 30 октетов.

Поле RC имеет следующий формат:

 

Биты								Октеты
8	7	6	5	4	3	2	1
RT			LTH					1
D	LF						NCFI	2

 

Структура поля RC.

RT

Тип маршрутизации.

LTH

Длина.

D

Бит направления.

LF

Размер самого большого кадра.

NCFI

Индикатор неканонического формата (Non-canonical format indicator). При сброшенном флаге (0) все MAC-адреса в кадре используют неканонический формат. При установке этого флага (1) все MAC-адреса в кадре имеют канонический формат.

Кадры SNAP 802.5

Формат тегового заголовка с кодированием SNAP для 802.5 показан на следующем рисунке.

 

Биты								Октеты
8	7	6	5	4	3	2	1
Заголовок SNAP (AA-AA-03)								1 — 3
SNAP PID (00-00-00)								4 – 6
Идентификатор тегового протокола (81-00)								7 — 8
TCI								9 — 10

 

Формат тегового заголовка кадра 802.5 с кодированием SNAP.

Значения полей заголовка и идентификатора SNAP, а также идентификатора тегового протокола приведены на рисунке. Поле TCI было рассмотрено при описании теговых заголовков кадров Ethernet.

Кадры SNAP FDDI

Формат тегового заголовка с кодированием SNAP для FDDI показан на следующем рисунке.

 

Биты								Октеты
8	7	6	5	4	3	2	1
Заголовок SNAP (AA-AA-03)								1 — 3
SNAP PID (00-00-00)								4 – 6
Идентификатор тегового протокола (81-00)								7 — 8
TCI								9 — 10
E-RIF								11, 12

 

Формат тегового заголовка кадра FDDI с кодированием SNAP.

Значения полей заголовка и идентификатора SNAP, а также идентификатора тегового протокола приведены на рисунке. Поля TCI и E-RIF (размер последнего поля составляет 2 – 30 октетов) были рассмотрены при описании теговых заголовков кадров Ethernet.

 

Определенные IEEE протоколы ISO (International Standards Organization – Международный комитет по стандартизации) представляют собой полный набор (стек) протоколов для всех семи уровней эталонной модели OSI (Open System Interconnection – взаимодействие открытых систем). Стек протоколов ISO включает в себя:

IS-IS Взаимодействие промежуточных систем (Intermediate System to Intermediate System).

ES-IS Взаимодействие оконечной и промежуточной системы (End-System to Intermediate System).

ISO-IP Протокол межсетевого взаимодействия (Internetworking Protocol).

ISO-TP Транспортный протокол (Transport Protocol).

ISO-SP Сеансовый протокол (Session Protocol).

PP Протокол представления (Presentation Protocol).

CCITT X.400 Протокол обработки почтовых сообщений CCITT (Consultative Committee Protocol).

Приведенный ниже рисунок показывает положение протоколов ISO в эталонной сетевой модели OSI:

Положение стека протоколов ISO в эталонной модели OSI

IS-IS

ISO 10589 http://www.iso.ch/cate/d18673.html

Протокол IS-IS (Intermediate System to Intermediate System – взаимодействие промежуточных систем) работает на сетевом уровне эталонной модели OSI. Этот протокол позволяет промежуточным системам внутри области маршрутизации (routing domain) обмениваться конфигурационной и маршрутной информацией для упрощения реализации функций маршрутизации и трансляции (relaying) на сетевом уровне. Протокол IS-IS предназначен для использования совместно с протоколами ES-IS (ISO 9542) и CLNS (ISO 8473).

Формат заголовка IS-IS, общий для всех PDU, показан на рисунке:

Биты								Октет
8	7	6	5	4	3	2	1
Дискриминатор протокола внутридоменной маршрутизации								1
Индикатор длины								2
Идентификатор версии/протокола								3
Размер идентификатора								4
R	R	R	Тип PDU					5
Версия								6
Зарезервирован								7
Максимальная область адресов								8

Структура заголовка IS-IS

Дискриминатор протокола внутридоменной маршрутизации

Идентификатор протокола сетевого уровня, присвоенный данному протоколу (десятичное значение 83).

Индикатор длины

Размер фиксированной части заголовка в октетах (байтах).

Идентификатор версии/протокола

Это поле всегда равно 1.

Размер идентификатора

Длина поля идентификатора адресов NSAP и NET, используемого в данной области маршрутизации.

R

Зарезервированные биты.

Тип PDU

Тип протокольного модуля данных (PDU). Биты 6 – 8 зарезервированы.

Версия

Это поле всегда равно 1.

Максимальная область адресов

Число адресов, поддерживаемое для данной промежуточной системы.

 

Декодирование IS-IS

ES-IS

ISO 9542 http://www.iso.ch/cate/d17285.html

Протокол ES-IS (End System to Intermediate System – взаимодействие оконечных систем с промежуточными) обеспечивает распространение маршрутной информации между хостами ISO.

ISO-IP

IETF RFC1069 http://www.cis.ohio-state.edu/htbin/rfc/rfc1069.html

IETF RFC1575 http://www.cis.ohio-state.edu/htbin/rfc/rfc1575.html

ISO 8473 http://www.iso.ch/cate/d20790.html

Документы ISO IS 8473 и IS 8348 определяют протокол межсетевого взаимодействия ISO-IP (ISO Internetworking Protocol), называемый также CLNP, который поддерживает средства сигнализации ошибок, помогающий управлять маршрутизацией. Протокол ISO-IP предназначен для обеспечения взаимодействия открытых систем. Этот протокол используется на сетевом уровне и обеспечивает сетевой сервис без организации соединений (connectionless-mode).

Каждый модуль данных PDU содержит перечисленные ниже поля в, расположенные соответствии с приведенным порядком.

1. Фиксированная часть.
2. Адресная часть.
3. Сегментационная часть (необязательная).
4. Опции (необязательная часть).
5. Данные (необязательная часть).

Модули PDU протокола ISO-IP имеют следующий формат:

 

Биты
8	7	6	5	4	3	2	1	Октет
Идентификатор протокола сетевого уровня								1	
Индикатор длины								2
Идентификатор версии/протокола								3	Фикс.
Время жизни								4	часть
SP	MS	E/R	Тип					5
Длина сегмента								6 – 7
Контрольная сумма								8 — 9	
Длина адреса получателя								10	
Адрес получателя (переменная длина)									Адрес
Индикатор длины адреса отправителя (1 байт)
Адрес отправителя (переменная длина)									
Идентификатор модуля данных (2 байта)									
Смещение сегмента (2 байта)									Сегм.
Общая длина (2 байта)									
Опции									Опции
Данные									Данные

 

Формат ISO-IP PDU

Фиксированная часть

Фиксированная часть ISO-IP PDU содержит следующие поля:

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

Значение 1000 0001 идентифицирует протокол сетевого уровня CLNP, значение 0000 0000 указывает на неактивное подмножество протоколов сетевого уровня.

Индикатор длины

Длина заголовка в октетах (байтах).

Идентификатор версии/протокола

Значение 0000 0001 идентифицирует стандарт ISO 8473.

Время жизни

Остающееся время жизни PDU выраженное числом полусекунд (500 мсек).

SP

Флаг сегментации. Значение 1 говорит о возможности сегментации. Флаг сегментации устанавливается отправителем PDU и не может быть изменен никаким из сетевых устройств в течение времени жизни исходного PDU или порожденных от него PDU.

MS

Флаг наличия других сегментов. Значение 1 говорит об использовании сегментации и о том, что последний октет NSDU не содержится в данном PDU.

E/R

Флаг отчетов об ошибках. Значение 1 говорит о необходимости генерации PDU с отчетом об ошибках в соответствии со стандартом.

Тип

Это поле указывает тип протокольного модуля данных (PDU) – DT или ER

Длина сегмента

Размер PDU в октетах (байтах) с учетом заголовка и данных.

Контрольная сумма

Значение контрольной суммы, рассчитанное для всего заголовка PDU. Нулевое значение говорит о том, что контрольная сумма игнорируется.

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

Адресная часть PDU содержит следующие поля.

Получатель

Адрес точки доступа к сервису в сети получателя.

Отправитель

Адрес точки доступа к сервису в сети отправителя.

Сегментация

При разрешенной сегментации (SP = 1) кадры ISO-SP содержат три дополнительных поля, описанных ниже.

Идентификатор модуля данных

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

Смещение сегмента

Смещение сегмента в исходном модуле данных.

Общая длина

Общая длина исходного модуля данных до его сегментации.

Опции кадра

В кадрах ISO-IP может присутствовать ряд описанных ниже опций.

Маршрутизация от источника (Source routing)

Задает путь через сеть путем указания набора адресов, через которые должен передаваться кадр. В кадрах с маршрутизацией от источника присутствуют перечисленные ниже параметры:

Тип маршрутизации — полная или частичная.

NextNET Название следующего сетевого объекта (network entity) в обрабатываемом списке маршрутов.

Запись маршрута

Заставляет каждый узел, через который прошел кадр, записывать свое имя объекта (network entity title) в кадр. В кадрах с опцией маршрутных записей присутствуют следующие поля:

Тип маршрутизации — полная или частичная.

#NETs — число имен сетевых объектов, присутствующих в настоящий момент в списке маршрутизации.

Приоритет

Запрашиваемый для кадра уровень приоритета – от 0 (низший) до 14 (высший).

Заполнение (Padding)

Число байтов заполнения (pad byte), использованных для выравнивания размера кадра.

Безопасность

Код и параметры безопасности, включающие несколько значений, которые обеспечивают различный уровень безопасности:

1 конкретный адрес отправителя;

2 конкретный адрес получателя;

3 уникальность в глобальном масштабе.

Качество обслуживания (QoS)

Качество обслуживания задается как параметр соединения. Для задания качества сервиса (QoS) могут использоваться несколько значений:

1 конкретный адрес отправителя;

2 конкретный адрес получателя;

3 уникальность в глобальном масштабе.

Сообщения об ошибках

Для кадров ISO-IP поддерживаются следующие сообщения об ошибках:

Сообщение	Описание ошибки
{not specified}	Неизвестная ошибка.
{protocol error}	Ошибка протокольной процедуры.
{bad checksum}	Ошибка в контрольной сумме.
{too congested}	Кадр отброшен в результате насыщения.
{bad PDU header}	Синтаксическая ошибка в заголовке PDU.
{fragment needed}	Сегментация требуется, но не разрешена.
{incomplete PDU}	Принят неполный модуль данных PDU.
{duplicate option}	Опция уже реализована.
{dest unreachable}	Недоступен IP-адрес получателя.
{destinat unknown}	Неизвестен IP-адрес получателя.
{unknown SR error}	Неизвестная ошибка маршрутизации от источника.
{SR syntax error}	Синтаксическая ошибка в поле маршрутизации от источника.
{bad SR address}	Неизвестный адрес в поле маршрутизации от источника.
{bad SR path}	Недоступный путь при маршрутизации от источника.
{TTL expired}	В процессе передачи истекло время жизни кадра.
{reasmbly expired}	При сборке истекло время жизни кадра.
{bad option}	Заданная опция не поддерживается.
{bad protocol ver}	Заданная версия протокола не поддерживается.
{bad security opt}	Заданная опция безопасности не поддерживается.
{bad SR option}	Заданная опция маршрутизации не поддерживается.
{bad RR option}	Опция записи маршрута не поддерживается.
{reassmbly failed}	Сбой при сборке пакета в результате интерференции.

ISO-TP

ISO 8073

ITU X.224 http://www.itu.ch/itudoc/itu-t/rec/x/x200-499/x224_36579.html

Стандарт ISO 8073 (ISO-TP) описывает транспортный протокол TP. Этот протокол обеспечивает простой и достаточно общий способ поддержки различных типов сетевого сервиса с возможностью добавления новых расширений. Протокол хорошо структурирован на несколько классов, позволяющих снизить затраты на реализацию и обеспечивающих должную интероперабельность.

Формат заголовка ISO-TP показан на рисунке.

LI

Фиксированная часть

Переменная часть

Структура заголовка ISO-TP

Поле LI является индикатором длины и указывает размер заголовка пакета (в байтах). Фиксированная часть пакета имеет следующий формат:

Тип PDU	DST-REF	SRC-REF	Переменная часть
1 байт	2 байта	2 байта	1 байт

Структура постоянной части ISO-TP PDU.

Типы PDU перечислены выше. Значения полей DST-REF, SRC-REF и последнего байта зависят от типа PDU. Более точные описания всех полей для различных типов PDU вы сможете найти в стандарте ISO TP.

ISO-SP

ISO/IEC 8327-1 09-1996

ITU X.225 http://www.itu.ch/itudoc/itu-t/rec/x/x200-499/x225_32038.html

Протокол ISO-SP описывает процедуры передачи данных и управляющей информации между объектами одного уровня в сессии.

Модули данных сеансового протокола передаются с использованием услуг транспортного уровня (Transport Data Transfer Service). Модули данных TSDU (Transport Service Data Unit) состоят из модулей данных сеансового уровня SPDU (Session protocol data units). В каждом TSDU может содержаться до 4 SPDU в зависимости от используемого метода соединения (базовый или расширенный) и типа SPDU.

Каждый модуль данных SPDU содержит один или несколько октетов (байтов). Структура SPDU показана на рисунке.

SI

LI

Поле параметров

Пользовательские данные

Структура SPDU.

SI

Индикатор SPDU, указывающий тип SPDU.

LI

Индикатор длины, показывающий размер поля параметров.

Поле параметров

В поле параметров содержатся модули PGI и PI, определенные для SPDU.

Структуры PGI и PI показаны на рисунках.

PGI

LI

Поле параметров

Поле параметров — структура PGI

PI

LI

Поле параметров

Поле параметров — структура PI

PGI Идентификатор группы параметров.

PI Идентификатор параметра, указывающий тип информации, представленной в поле параметров.

Поле параметров В модулях PGI поле параметров содержит одно значение параметра или несколько модулей PI; в модулях PI поле параметров может содержать только значение параметра.

Пользовательские данные

Это поле содержит части сегментированных SPDU.

ISO-PP

ISO IS 8823

ITU X.226 http://www.itu.ch/itudoc/itu-t/rec/x/x200-499/x226_25241.html

Документ IS 8823 определяет протокол представления ISO (Presentation Protocol или PP), обеспечивающий согласование контекста и управление в открытых системах.

Кадры

Кадры PP могут содержать одну из перечисленных ниже команд:

[Connect Presentation] Запрос соединения на уровне представления.

[Connect Presentation Accept] Подтверждение соединения на уровне представления.

Параметры

Кадры PP могут содержать следующий параметр:

X.410 Mode {1984 X.400}

Кадр базируется на рекомендациях CCITT X.410. Обычно это означает, что приложение является системой обработки сообщений (Message Handling System) CCITT 1984 X.400.

ASCE

ITU-T Recommendation X.227 http://www.itu.ch/itudoc/itu-t/rec/x/x200-499/x226_25241.html

Протокол ASCE (Application Control Service Element – элемент управления сервисом на уровне приложений) обеспечивает организацию и завершение приложений-ассоциаций. Протокол ASCE включает также два дополнительных функциональных модуля. Один из этих модулей поддерживает обмен информацией в процессе аутентификации при создании ассоциаций. Второй модуль поддерживает согласование контекста приложений при организации ассоциаций. Услуги ASCE применимы к широкому классу прикладных коммуникационных процессов.

CCITT X.400

Международный комитет по телеграфной и телефонной связи (CCITT) разработал этот стандарт для передачи сообщений электронной почты между компьютерами. Рекомендации CCITT X.400 — X.430 определяют протокол прикладного уровня и небольшую часть протокола уровня представления. Протокол CCITT X.400 использует услуги и протокол сеансового уровня ISO, описанные в документах IS 8326 и IS 8327, соответственно.

Стандарт CCITT X.400 описывает функции агента передачи сообщений (MTA), отвечающего за передачу сообщений электронной почты между компьютерами. MTA использует протокол P1 для передачи модулей данных MPDU (message protocol data units). Агенты MTA обмениваются двумя типами MPDU — User и Service. Пользовательские MPDU содержат сообщения, а сервисные MPDU используются для поддержки информации о передаче сообщений. Сервисные MPDU также делятся на два типа — Delivery Report и Probe.

Кадры X.400 могут быть следующих типов:

[User MPDU Message] Нормальное почтовое сообщение (mail handling system или MHS).

[DeliveryReport MPDU] Передается для выяснения состояния предыдущего сообщения.

[Probe MPDU] Передается для проверки доставки сообщения.

Каждый кадр CCITT X.400 содержит следующий параметр:

Протокол P1.

ITU SR-NWT-001953 1991-06, ETS 300 102-1 1990-12, AT&T 801-802-100 1989-05

Стандарты ISDN (Integrated Services Digital Network – цифровая сеть с интеграцией услуг) описывают работу цифровых линий связи, поддерживающих передачу голоса, видео или данных с высокой скоростью через стандартные коммуникационные линии. ISDN обеспечивает единый интерфейс доступа к цифровой сети передачи данных для устройств, выполняющих широкий набор задач, с сохранением полной прозрачности сети для пользователей. Учитывая большой объем информации, передаваемой через сети ISDN, можно говорить что технология ISDN произвела революцию в деловых коммуникационных приложениях.

ISDN может использовать не только обычные телефонные сети, но также сети коммутации пакетов, телексные сети, сети CATV и т. д.

Приложения ISDN

В данной главе описаны следующие протоколы:

LAPD — Link Access Protocol — Channel D (протокол доступа к линии – канал D);

ISDN — Integrated Services Digital Network (цифровая сеть с интеграцией услуг).

LAPD

ITU Q.921 (Blue Book)

LAPD (Link Access Protocol – Channel D или протокол доступа к линии – канал D) является протоколом канального уровня, описанным в стандарте CCITT Q.920/921. LAPD работает в асинхронном сбалансированном режиме (Asynchronous Balanced Mode или ABM). В данном случае термин «сбалансированный» означает отсутствие в соединениях ведущих и ведомых устройств. Каждая станция имеет возможность инициировать организацию соединения и управление этим соединением, обеспечивать исправление ошибок, а также передавать пакеты данных в любой момент времени. Для протокола LAPD понятия DTE и DCE являются эквивалентными.

На рисунке показан формат пакетов LAPD.

Флаг

Адрес

Управление

Информация

FCS

Флаг

Структура пакета LAPD

Флаг

Поле флага всегда имеет значение 0x7E и используется для разделения пакетов. Для того чтобы исключить появление такой же последовательности битов в пакетах, на передающей и принимающей стороне используется метод Bit Stuffing (вставка битов).

Адрес

Первые два байта после флага содержат поле адреса. Формат этого поля показан на рисунке.

Биты
8	7	6	5	4	3	2	1
SAPI						C/R	EA1
TEI							EA2

Поле адреса LAPD

EA1 Первый бит расширения адреса (всегда равен 0).

C/R Флаг Command/Response (команда/отклик). Пакеты, передаваемые пользователем с C/R=0, содержат команды, так же, как пакеты, передаваемые пользователю со стороны сети при C/R=1. Во всех остальных случаях пакеты содержат отклик на команды.

SAPI Идентификатор точки доступа к сервису (Service Access Point Identifier), который может принимать следующие значения:

0 Процедуры вызова/контроля.

1 Пакетный режим передачи с использованием процедур вызова/контроля I.451.

16 Передача пакетов в соответствии с X.25, уровень 3.

63 Процедуры управления уровня 2.

EA2 Второй бит расширения адреса (всегда равен 1).

TEI Идентификатор конечной точки (терминала), который может принимать следующие значения:

0-63 Используется пользовательским оборудованием без автоматического назначения TEI.

64-126 Используется пользовательским оборудованием с автоматическим назначением TEI.

127 Используется для широковещательный соединений со всеми терминальными устройствами.

Контроль

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

FCS

Контрольная сумма (Frame Check Sequence – FCS), позволяющая обнаруживать ошибки при передаче данных. Контрольная сумма вычисляется отправителем пакета с использованием алгоритма, принимающего во внимание каждый бит передаваемого пакета. На приемной стороне пакета заново вычисляет контрольную сумму по тому же алгоритму и сравнивает полученный результат со значением, содержащимся в пакете.

Размер окна

LAPD поддерживает расширенный размер окна (по модулю 128), с возможностью передачи от 8 до 128 неподтвержденных кадров. Расширенный размер окна передачи обычно используется для спутниковых каналов, где задержка подтверждения пакетов может существенно превышать время передачи самих пакетов. Тип пакета, инициализирующего соединение, определяет модуль для сессии. При использовании окна расширенного размера к имени базового типа пакета добавляется суффикс “E” (SABME вместо SABM).

Типы пакета

Протокол LAPD поддерживает несколько типов управляющих кадров (Supervisory Frame):

RR Подтверждение приема информационного пакета и индикация готовности к получению последующей информации.

REJ Запрос повторной передачи всех пакетов, начиная с указанного в пакете порядкового номера.

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

LAPD поддерживает несколько типов ненумерованных пакетов (Unnumbered Frame):

DISC Запрос на разрыв соединения.

UA Кадр подтверждения приема.

DM Ответ на запрос DISC, указывающий на режим разрыва соединения.

FRMR Отбрасывание пакета.

SABM Пакет, инициализирующий асинхронный сбалансированный режим.

SABME SABM в режиме расширенного окна.

UI Ненумерованная информация.

XID Обмен информацией.

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

Info Информационный пакет.

 

Пример декодирования пакетов ISDN

Международные варианты ISDN

За разработку стандартов ISDN отвечает CCITT (в настоящее время ITU-T). Первой публикацией группы, ответственной за разработку стандарта ISDN был набор рекомендаций ISDN 1984 года (Red Book — Красная Книга). Еще до выпуска Красной книги в разных регионах были разработаны местные и национальные версии ISDN. По этой причине рекомендации CCITT определяют только общие для всех стран стандарты ISDN, в дополнение к национальным стандартам.

Возможность использования специфических информационных элементов для отдельных стран обеспечивается за счет набора кодов (Codeset).

Ниже приведено описание большинства существующих национальных и региональных вариантов ISDN.

Национальный вариант ISDN-1 (Bellcore)

SR-NWT-001953 1991-06

Этот вариант используется компанией Bellcore в США. В рамках данного стандарта поддерживаются четыре специфических типа сообщений и не используются однобайтовые информационные элементы. В дополнение к элементам Codeset 0 данный вариант также поддерживает четыре информационных элемента Codeset 5 и пять информационных элементов Codeset 6.

Национальный вариант ISDN-2 (Bellcore)

SR-NWT-002361 1992-12

Основным различием между ISDN-1 и ISDN-2 является загрузка параметров с использованием компонент (субэлементы информационных элементов (Extended Facility). Компоненты используются для передачи информационных параметров между пользовательским оборудованием ISDN (например, ISDN-телефоном) и ISDN-коммутатором.

Другим отличием стандарта ISDN-2 являются дополнительные типы сообщений – SEGMENT, FACILITY и REGISTER, а также дополнительные информационные элементы – Segmented Message (сегментированное сообщение) и Extended Facility (расширенные возможности). Кроме того, изменены значения некоторых полей в пакетах и добавлено несколько дополнительных значений полей.

5ESS (AT&T)

AT&T 801-802-100 1989-05

Этот вариант ISDN используется компанией AT&T в США. 5ESS является наиболее распространенной реализацией ISDN и поддерживает 19 специфических типов сообщений. 5ESS не содержит элементов Codeset 5, но поддерживает 18 информационных элементов Codeset 6 и расширенный управляющий информационный элемент.

Euro ISDN (ETSI)

ETS 300 102-1 1990-12

Этот вариант ISDN адаптирован всеми европейскими странами. В настоящий момент Euro ISDN поддерживает однооктетные типы сообщений и пять информационных элементов размером в один октет. В протоколе не используются элементы Codeset 5 и Codeset 6, но каждая страна вправе определять собственные информационные элементы.

VN3, VN4 (Франция)

DGPT: CSE P 22-30 A 1994-08

Данный вариант стандарта используется преимущественно во Франции. Декодирование VN3 и некоторые сообщения об ошибках переведены на французский язык. Данный протокол является подмножеством стандарта CCITT и поддерживает только однооктетные типы сообщений. Более новый стандарт VN4 не полностью совместим с VN3, однако более точно соответствует рекомендациям CCITT. В Как и VN3, новый стандарт содержит некоторое количество переводов. VN4 поддерживает однооктетные типы сообщений, пять однооктетных информационных элементов и два элемента Codeset 6.

1 TR6 (Германия)

1 TR 6 1990-08

Этот вариант стандарта распространен прежде всего в Германии. Протокол является подмножеством стандарта CCITT с незначительными изменениями. В протоколе частично используется английский язык, частично — немецкий.

ISDN 30 [DASS-2] (Англия)

BTNR 190 1992-07

Этот вариант протокола используется компанией British Telecom в дополнение к стандарту ETSI (см. выше). На уровнях 2 и 3 этот стандарт не соответствует структуре CCITT. Пакеты имеют заголовок размером в один октет, за которым может следовать информация. Большая часть информации кодируется с использованием IA5 и, следовательно, может декодироваться как ASCII.

Австралия

AP IX-123-E

Этот протокол ранее использовался в Австралии, но сейчас вытесняется более новым австралийским вариантом ISDN. Протокол является подмножеством стандарта CCITT и поддерживает только однооктетные типы сообщений и однооктетные информационные элементы. В протоколе используются только элементы Codeset 5.

TS014 Австралия

TS014 (Austel) 1995

Это новый стандарт ISDN PRI для Австралии, разработанный компанией Austel. Стандарт очень близок к ETSI.

NTT-Japan (Япония)

INS-NET Interface and Services 1993-03

Сервис ISDN в Японии поддерживается компанией NTT и известен как INS-Net. Основными характеристиками INS-Net являются:

Поддержка интерфейса пользователь-сеть, соответствующего рекомендациям Голубой книги (Blue Book) CCITT.

Поддержка интерфейсов BRI и PRI.

Поддержка пакетного режима с использованием Case B.

Поддержка в сети сигнализации SS 7 ISDN User Part.

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

ARINC 746

ARINC Characteristic 746-4 1996-04

Сегодня многие авиакомпании обеспечивают в своих самолетах телефонный сервис для пассажиров. Бортовые телефоны подключаются к сети T1 и соединения организуются через спутниковые каналы. Используемый протокол сигнализации основан на стандарте Q.931, однако имеет отличия от последнего и известен как ARINC 746. Лидирующими компаниями в данной области являются GTE и AT&T. При анализе протокола ARINC с использованием анализатора протоколов в качестве варианта LAPD должно быть установлено значение ARINC.

ARINC 746 Приложение 11 (Attachment 11)

ARINC Characteristic 746-4 1996-04

Приложение 11 стандарта ARINC (Aeronautical Radio, INC.) описывает передачу сообщений сетевого уровня (уровень 3), необходимых для управления оборудованием и поддержки управления процедурами организации соединения между бортовым телефонным оборудованием (Cabin Telecommunications Unit или CTU) и системой SATCOM, North American Telephone System (NATS) или Terrestrial Flight Telephone System (TFTS). Механизм, описанный в Приложении 11, разработан на основе рекомендаций CCITT Q.930, Q.931 и Q.932 (управление вызовами), а также на основе стандартов ISO/OSI DIS 9595 и DIS 9596 (управление оборудованием). Описываемые сообщения сетевого уровня должны передаваться в поле данных пакета канального уровня.

ARINC 746 Attachment 17

ARINC Characteristic 746-4 1996-04

Приложение 17 к стандарту ARINC (Aeronautical Radio, INC.) определяет систему доступа пассажиров и экипажа самолетов к сервису, предлагаемому CTU и интеллектуальным оборудованием самолета. Распределительная часть CDS передает сигнализацию и телефонные каналы от пользовательской телефонной гарнитуры в коммуникационные модули кресел. Каждая зона в самолете имеет устройство, которое управляет и обслуживает кресла в пределах данной зоны.

Northen Telecom – DMS 100

NIS S208-6 Issue 1.1 1992-08

Этот вариант представляет собой реализацию National ISDN-1, разработанную компанией Northen Telecom. Стандарт обеспечивает интерфейс пользователь-сеть на уровне ISDN BRI между коммутатором Northern Telecom ISDN DMS-100 и терминальным оборудованием, разработанным для BRI DSL. Стандарт DMS 100 базируется на спецификации CCITT ISDN-1, рекомендациях Q-серии, ISDN Basic Interface Call Control Switching (управление коммутацией соединений для базового интерфейса ISDN) и требованиях к сигнализации и дополнительной поддержке Bellcore.

DPNSS1

BTNR 188 1995-01

DPNSS1 (Digital Private Network Signaling System № 1 — система сигнализации частных цифровых сетей №1) является сигнальной системой на базе общего канала, используемой в Великобритании. Данная система позволяет расширить возможности, обычно доступные только в пределах одной телефонной станции PBX, на все станции PBX в частной сети. Основным назначением этой системы является передача информации между PBX в частных сетях с использованием временного интервала (time slot) 16 цифрового тракта 2048 Кбит/с (E1) или временного интервала 24 в системах 1544 Кбит/с (T1). Отметим, что при анализе данного протокола поле LAPD должно иметь значение DPNSS1.

Swiss Telecom (Швеция)

PTT 840.73.2 1995-06

Вариант ISDN, используемый в Швеции компанией Swiss Telecom PTT, называется SwissNet. Протокол DSS1 для SwissNet полностью базируется на ETS. Незначительные поправки к последнему состоят лишь в определении различных опций стандарта и игнорировании некоторых требований. Шведский вариант использует также некоторые специфические условия (например, совместимость между пользовательским оборудованием и станциями сети SwissNet различных реализаций).

QSIG

ISO/IEC 11572 1995

QSIG является мощной, интеллектуальной современной сигнальной системой, предназначенной для обмена сообщениями между частными станциями PABX. Стандарты QSIG определяют систему сигнализации на уровне Q, предназначенную, прежде всего, для общего канала (например, интерфейс G.703). Однако, QSIG будет работать при любом методе подключения оборудования PINX. Стек протоколов QSIG идентичен по структуре стеку DSSI (оба стека соответствуют модели ISO). Оба протокола имеют идентичные уровни 1 и 2 (LAPD), однако на третьем уровне протоколы QSIG и DSS1 различаются.

Структура кадров ISDN

На рисунке показана общая структура кадров ISDN.

Биты
8	7	6	5	4	3	2	1
Дискриминатор протокола
0	0	0	0	Длина поля «Ссылка на вызов»
Флаг	Ссылка на вызов
0	Тип сообщения
Другие информационные элементы

Структура кадра ISDN

Дискриминатор протокола

Протокол, используемый для оставшейся часть уровня.

Длина поля «Ссылка на вызов»

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

Флаг

Нулевое значение для сообщений, передаваемых стороной, выделяющей значения ссылки на вызов, 1 — в остальных случаях.

Ссылка на вызов

Значение, присваиваемое в указанном сеансе связи между устройством, инициировавшим вызов и коммутатором ISDN. Данное значение используется устройствами для идентификации соединения.

Тип сообщения

Тип сообщения определяет назначение последнего. Поле типа может занимать один или два (для специфических сообщений) октета. В двухоктетных сообщения первый октет содержит восемь нулей. Полный перечень типов сообщений приведен ниже в параграфе «Типы сообщений ISDN».

Информационные элементы ISDN

В ISDN существует два типа информационных элементов — элементы размером один октет и элементы переменной длины.

Однооктетные информационные элементы

Структура однооктетного информационного элемента приведена на рисунке.

8	7	6	5	4	3	2	1
1	Идентификатор информационного элемента				Информационный элемент

Структура однооктетного элемента

Список существующих типов однооктетных информационных элементов приведен ниже.

1	000 —-	Зарезервировано
1	001 —-	Сдвиг
1	010 0000	Больше данных
1	010 0001	Посылка завершена
1	011 —-	Уровень перегрузки
1	101 —-	Индикатор повторения

Информационные элементы переменной длины

Ниже приведена структура информационного элемента переменной длины.

Биты
8	7	6	5	4	3	2	1
0	Идентификатор информационного элемента
Длина информационных элементов
Информационные элементы (более одного байта)

Информационный элемент переменной длины.

Идентификатор информационного элемента служит уникальным обозначением данного элемента только внутри данного Codeset. Размер информационного элемента сообщает получателю о количестве следующих за этим полем байтов информационного элемента. Ниже приведен список существующих информационных элементов переменной длины.

0	0000000	Сегментированное сообщение
0	0000100	Поддержка однонаправленного режима
0	0001000	Причина
0	0010100	Идентификация вызова
0	0010100	Состояние вызова
0	0011000	Идентификация канала
0	0011100	Возможности
0	0011110	Индикатор состояния процесса (progress)
0	0100000	Специфические возможности сети
0	0100111	Индикатор уведомления
0	0101000	Отображение
0	0101001	Дата/время
0	0101100	Поддержка клавишного поля
0	0110100	Сигнал
0	0110110	Переключение рычага (трубки)
0	0111000	Активизация режима (feature)
0	0111001	Индикация режима (feature)
0	1000000	Скорость передачи информации
0	1000010	Транзитная задержка сквозной передачи
0	1000011	Выбор и индикация транзитной задержки
0	1000100	Двоичные параметры пакетного уровня
0	1000101	Размер окна для пакетного уровня
0	1000110	Размер пакета
0	1101100	Номер вызывающего абонента
0	1101101	Подадрес вызывающего абонента
0	1110000	Номер вызываемого абонента
0	1110001	Субадрес вызываемого абонента
0	1110100	Номер перенаправления
0	1111000	Выбор транзитной сети
0	1111001	Индикатор перезапуска
0	1111100	Совместимость с нижележащим уровнем
0	1111101	Совместимость с вышележащим уровнем
0	1111110	Пользователь-пользователь
0	1111111	Отмена использования расширения
Другие значения		Зарезервированы

Типы сообщений ISDN

Ниже приведены возможные типы сообщений ISDN.

Организация соединения

000 00001	Предупреждение
000 00010	Обработка вызова
000 00011	В процессе
000 00101	Установка (соединения)
000 00111	Соединение
000 01101	Подтверждение установки (соединения)
000 01111	Подтверждение соединения

Фаза передачи информации

001 00000	Пользовательская информация
001 00001	Отказ от временной приостановки
001 00010	Отказ от возобновления передачи данных
001 00100	Остановить
001 00101	Временно приостановить
001 00110	Возобновить
001 01000	Подтверждение остановки
001 01101	Подтверждение временной остановки
001 01110	Подтверждение возобновления
001 10000	Отказ от остановки
001 10001	Восстановление
001 10011	Подтверждение восстановления
001 10111	Отказ от восстановления

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

010 00101	Разъединение
010 00110	Рестарт
010 01101	Освободить
010 01110	Подтверждение рестарта
010 11010	Завершение освобождения

Разное

011 00000	Сегмент
011 00010	Возможность (осуществления какой-либо функции)
011 00100	Регистрация
011 01110	Уведомление
011 10101	Запрос состояния
011 11001	Управление насыщением
011 11011	Информация
011 11101	Состояние

Терминология ISDN

BRI

Базовый интерфейс (Basic Rate Interface) является одним из двух видов сервиса, предоставляемых ISDN в настоящее время. Канал BRI состоит из двух B-каналов и одного канала типа D (2B + D). B-каналы работают на скорости 64 Кбит/с, а канал D поддерживает скорость 16 Кбит/с. Интерфейс BRI используется в основном для настольных приложений (например, организация доступа в Internet для небольшой компании).

C/R

Команда/отклик (Command/Response). Флаг C/R занимает один бит в поле адреса и позволяет идентифицировать пакет как команду или отклик на переданную ранее команду.

Codeset

Существует три основных набора кодов (Codeset). В каждом кодовом наборе раздел информационных элементов определяется в соответствии со связанным вариантом протокола.

Codeset 0 кодовый набор, используемый по умолчанию, содержит набор информационных элементов, соответствующий рекомендациям CCITT.

Codeset 5 специфический для страны кодовый набор.

Codeset 6 специфический для сети кодовый набор.

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

Для изменения кодового наборов могут использоваться два метода:

Shift (Сдвиг)	Обеспечивает временное переключение на другой кодовый набор и называется также неблокируемым сдвигом. Переключение кодового набора распространяется только на следующий информационный элемент.
Shift Lock (Блокируемый сдвиг)	Обеспечивает постоянное изменение кодового набора, пока не будет дана команда отмены. С помощью этого метода возможно перейти только к кодовому набору с большим номером.

CPE

Пользовательское оборудование (Customer Premises Equipment или CPE) включает оборудование ISDN, размещаемое у пользователя и применяемое для подключения к сети ISDN. Такими устройствами могут быть телефон, компьютер, телекс, телефакс и так далее. Исключением являются устройства с интерфейсом NT1 в трактовке FCC и CCITT. Правила FCC рассматривают модули NT1 как оборудование CPE, поскольку NT1 устанавливается у пользователя, однако CCITT считает NT1 частью сети. Следовательно, граница между пользователем и сетью определяется в зависимости от принятого варианта.

Каналы ISDN – B, D и H

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

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

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

H-канал выполняет те же самые функции, что и D-канал, однако работает при скорости, превышающей DS-0 (64 Кбит/с).

Устройства ISDN

Устройства, служащие для соединения CPE и сети. Кроме факсов, телефонов, компьютеров могут использоваться следующие устройства:

TA Терминальный адаптер (Terminal Adapter). TA используется для подключения не-ISDN устройств к сети ISDN.

LE Local Exchange (локальная станция). Используется в телефонной станции (Central Office — CO). LE работает с протоколом ISDN и является частью сети.

LT Local Termination — LT (Локальное окончание). Используется для обозначения LE, служащих для работы с Local Loop (абонентский шлейф).

ET Exchange Termination (завершение станции). Используется для обозначения LE, отвечающих за функции коммутации.

NT Network Termination — NT (оборудование завершения сети). Существует два вида NT, выполняющих различные функции:

• NT1 – служит для завершения соединений между пользователем и LE. NT1 отвечает за работу, мониторинг, подачу питания и мультиплексирование каналов.
• NT2 – любое устройство, применяемое пользователем для коммутации, мультиплексирования и концентрации: локальная сеть, компьютер, терминальный контроллер и т. д. Оборудование NT2 не устанавливается для домашнего пользования ISDN.

TE Terminal Equipment — TE (терминальное оборудование). Любое пользовательское устройство (например, телефон или факсимильный аппарат). Существует два типа TE:

• TE1 – оборудование, совместимое с ISDN.

• TE1 – оборудование, не совместимое с ISDN.

Опорные точки ISDN

Опорные точки (reference point) ISDN определяют точки связи между различными устройствами. Предполагается, что с разных сторон опорной точки могут использоваться различные протоколы. Основные опорные точки перечислены ниже:

R связь между оборудованием TE, не совместимым с ISDN, и TA.

S связь между TE или TA и оборудованием NT.

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

U Узловая точка между оборудованием NT и LE. Эта точка может определяться как граница сети в случае использования определения FCC для терминала сети.

На рисунке показаны функциональные узлы ISDN и опорные точки.

LAPD

Link Access Protocol – Channel D (протокол доступа к линии – Канал D) представляет собой протокол канального уровня, работающий с битовыми потоками (бит-ориентированный протокол). Основной задачей этого протокола является безошибочная передача последовательности битов на физическом уровне (уровень 1).

PRI

ISDN PRI (Primary Rate Interface — основной интерфейс) является одним из двух видов сервиса, предоставляемых в современных сетях ISDN. Реализация PRI зависит от принятого стандарта и может отличаться в разных странах. В Северной Америке PRI поддерживает 23 B-канала и один канал D (23B + D), а в Европе — 30 каналов типа B и один D-канал (30B + D).

В Америке каналы B и D работают со скоростью 64Кбит/с. Следовательно, если D-канал в некоторых случаях не используется в качестве канала управления, он может служить как дополнительный B-канал. PRI 23B + D работает с заданной CCITT скоростью 1544 Кб/с.

Европейский вариант PRI содержит 30 каналов B и один D-канал (30B + D). Так же как и в американском стандарте, все каналы работают на скорости 64Кбит/с. PRI 30B + D работает с заданной CCITT скоростью 2048 Кбит/с.

SAPI

Идентификатор точки доступа к сервису (Service access point identifier — SAPI) — первая часть адреса каждого пакета.

TEI

Идентификатор оконечного терминала (Terminal End Point Identifier) — вторая часть адреса каждого пакета.

В настоящее время многие маршрутизаторы поддерживают возможность установки интерфейсов ATM. Однако для того, чтобы полностью использовать полосу пропускания, предоставляемую каналом ATM 155 Мбит/с, IP-маршрутизатор должен иметь возможность передавать в линию до 100000 пакетов в секунду. Это превышает возможности большинства маршрутизаторов. Дело в том, что маршрутизатор должен принимать решения о маршрутизации каждого отдельного пакета IP, поскольку протокол IP относится к числу протоколов connectionless (Без организации соединений).

Для решения этой проблемы компания Ipsilon разработала так называемый коммутатор IP, работающий по принципу сквозной (Cut Through) маршрутизации, позволяющей увеличить производительность маршрутизации IP в 5 раз по сравнению с обычными маршрутизаторами. Такой эффект достигается за счет детектирования нескольких классов потоков IP в ходе процесса маршрутизации. Под потоком понимается последовательность пакетов, имеющих одинаковые адреса отправителя и получателя, а также использующих однотипные протоколы вышележащих уровней (TCP, UDP), одинаковый тип сервиса (TOS) и другие характеристики (определяется заголовком IP-пакета).

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

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

Сигнализация между двумя коммутаторами IP осуществляется на базе двух протоколов — IFMP (Ipsilon Flow Management Protocol — протокол управления потоком компании Ipsilon) и GSMP (General Switch Management Protocol — общий протокол управления коммутатором).

IFMP

RFC 1953 1996-05 http://www.cis.ohio-state.edu/htbin/rfc/rfc1953.html

Протокол IFMP (Ipsilon Flow Management Protocol — протокол управления потоком Ipsilon) служит для передачи соседнему узлу информации о необходимости добавления меток канального уровня к указанному потоку IP для маршрутизации этого потока через коммутатор IP. Использование меток обеспечивает для потока более эффективный и быстрый доступ к маршрутной информации и позволяет коммутировать поток, а не маршрутизировать его.

IFMP состоит из двух разделов: Adjacency Protocol (протокол соседства) и Redirection Protocol (протокола переадресации). Сообщения IFMP инкапсулируются в пакеты IPv4 и передаются по адресу limited broadcast (пакет ограниченного широковещания) –255.255.255.255. Поле протокола в заголовке пакета IP содержит десятичное значение 101, идентифицирующее сообщение IFMP.

Структура заголовка IFMP показана на рисунке.

Версия (1)

OP-код (1)

Контрольная сумма

Структура заголовка IFMP

Версия

Номер версии протокола IFMP. Текущая версия — 1.

OP-код

Назначение сообщения.

Для IFMP Adjacency Protocol определено четыре значения Op-кода.

0 SYN.

1 SYNACK.

2 RSTACK.

3 ACK.

Для IFMP Redirection Protocol определены пять кодов.

4 REDIRECT.

5 RECLAIM.

6 RECLAIM ACK.

7 LABEL RANGE.

8 ERROR.

Контрольная сумма

Значение контрольной суммы (CRC).

GSMP

RFC 1987 1996-08 http://www.cis.ohio-state.edu/htbin/rfc/rfc1987.html

Протокол GSMP (General Switch Management Protocol) используется в качестве протокола общего назначения для управления коммутаторами ATM. GSMP позволяет управлять организацией и разрывом соединений через коммутатор, добавлять и удалять узлы в групповые соединения (point-multipoint), управлять портами коммутатора, запрашивать сведения о конфигурации и статистику.

Пакеты GSMP имеют переменную длину и инкапсулируются в AAL5 с заголовком LLC/SNAP 0x00-00-00-88-0C для идентификации сообщений GSMP. Структура заголовка GSMP показана на рисунке.

Версия (1)

Тип сообщения (1)

Результат (1)

Код (1)

Структура заголовка GSMP

Версия

Номер версии протокола GSMP. Текущая версия — 1.

Тип сообщения

Тип сообщения GSMP. Существует пять классов сообщений, каждый из которых поддерживает множество типов сообщений, — Connection Management (управление соединением), Port Management (управление портом), Statistics (статистика), Configuration (конфигурация) и Events (события).

Результат

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

Код

Дополнительная информация, содержащая результат запроса (отклик). Чаще всего это поле служит для передачи кодов ошибок. В запросе поле кода не используется и должно иметь нулевое значение.

ATM Forum ILMI specification 4.0 1996-0

IETF RFC 115, May 1990; RFC 1213, March 1991; RFC 1151, May 1990 ATM Forum UNI 3.0; «Managing Internetworks with SNMP», by Mark A. Miller, M&T Books, 1990

Каждое оконечное устройство ATM в соответствии с протоколом SNMP (Simple Network Management Protocol — простой протокол управления сетью) и ATM UNI MIB (Management Information Base — информационная база данных управления) должно поддерживать информацию о конфигурации и состоянии виртуальных путей и каналов, доступных через интерфейс UNI. Помимо управления, данная информация может использоваться при выполнении диагностических процедур UNI.

Протокол ILMI (Interim Local Management Interface – временный интерфейс локального управления) поддерживает двунаправленный обмен управляющей информацией между системами, использующими для связи протокол UME (UNI Management Entities — объекты управления UNI). Оба объекта UME должны поддерживать идентичные MIB, даже если семантика некоторых объектов MIB интерпретируется по-разному. Протокол ILMI используется в различных типах оборудования, (коммутаторы верхних уровней, рабочие станции, компьютеры с интерфейсом ATM, сетевые коммутаторы ATM и др.).

Имена MIB

Ниже приведен список имен, используемых в MIB.

enterprises

353 atmForum

1 atmForumAdmin

2 atmfTransmissionTypes

1 atmfUnknownType

2 atmfSonetSTS3c

3 atmfDs3

4 atmf4B5B

5 atmf8B10B

3 atmfMediaTypes

1 atmfMediaUnknownType

2 atmfMediaCoaxCable

3 atmfMediaSingleMode

4 atmfMediaMultiMode

5 atmfMediaStp

6 atmfMediaUtp

4 atmTrafficDescrTypes

1 atmfNoDescriptor

2 atmfPeakRate

3 atmfNoClpNoScr

4 atmfClpNoTaggingNoScr

5 atmfClpTaggingNoScr

6 atmfNoClpScr

7 atmfClpNoTaggingScr

8 atmfClpTaggingScr

5 atmfSrvcRegTypes

1 atmfSrvcRegLecs

2 atmForumUni

1 atmfPhysicalGroup

1 atmfPortTable

1 atmfPortEntry

1 atmfPortIndex

2 atmfPortAddress

3 atmfPortTransmissionType

4 atmfPortMediaType

5 atmfPortOperStatus

6 atmfPortSpecific

2 atmfAtmLayerGroup

1 atmfAtmLayerTable

1 atmfAtmLayerEntry

1 atmfAtmLayerIndex

2 atmfAtmLayerMaxVPCs

3 atmfAtmLayerMaxVCCs

4 atmfAtmLayerConfiguredVPCs

5 atmfAtmLayerConfiguredVCCs

6 atmfAtmLayerMaxVpiBits

7 atmfAtmLayerMaxVciBits

8 atmfAtmLayerUniType

3 atmfAtmStatsGroup

1 atmfAtmStatsTable

1 atmfAtmStatsEntry

1 atmfAtmStatsIndex

2 atmfAtmStatsReceivedCells

3 atmfAtmStatsDroppedReceivedCells

4 atmfAtmStatsTransmittedCells

4 atmfVpcGroup

1 atmVpcTable

1 atmVpcEntry

1 atmVpcPortIndex

2 atmfVpcVpi

3 atmfVpcOperStatus

4 atmfVpcTransmitTrafficDescriptorType

5 atmfVpcTransmitTrafficDescriptorParam1

6 atmfVpcTransmitTrafficDescriptorParam2

7 atmfVpcTransmitTrafficDescriptorParam3

8 atmfVpcTransmitTrafficDescriptorParam4

9 atmfVpcTransmitTrafficDescriptorParam5

10 atmfVpcReceiveTrafficDescriptorType

11 atmfVpcReceiveTrafficDescriptorParam1

12 atmfVpcReceiveTrafficDescriptorParam2

13 atmfVpcReceiveTrafficDescriptorParam3

14 atmfVpcReceiveTrafficDescriptorParam4

15 atmfVpcReceiveTrafficDescriptorParam5

16 atmfVpcQoSCategory

17 atmfVpcTransmitQoSClass

18 atmfVpcReceiveQoSClass

5 atmfVccGroup

1 atmfVccTable

1 atmfVccEntry

1 atmVccPortIndex

2 atmfVccVpi

3 atmfVccVci

4 atmfVccOperStatus

5 atmfVccTransmitTrafficDescriptorType

6 atmfVccTransmitTrafficDescriptorParam1

7 atmfVccTransmitTrafficDescriptorParam2

8 atmfVccTransmitTrafficDescriptorParam3

9 atmfVccTransmitTrafficDescriptorParam4

10 atmfVccTransmitTrafficDescriptorParam5

11 atmfVccReceiveTrafficDescriptorType

12 atmfVccReceiveTrafficDescriptorParam1

13 atmfVccReceiveTrafficDescriptorParam2

14 atmfVccReceiveTrafficDescriptorParam3

15 atmfVccReceiveTrafficDescriptorParam4

16 atmfVccReceiveTrafficDescriptorParam5

17 atmfVccQoSCategory

18 atmfVccTransmitQoSClass

19 atmfVccReceiveQoSClass

8 atmfSrvcRegistryGroup

1 atmfSrvcRegTable

1 atmfSrvcRegEntry

1 atmfSrvcRegPort

1 atmfSrvcRegServiceID

1 atmfSrvcRegATMAddress

1 atmfSrvcRegAddressIndex

SNMP

RFC 1157: http://www.cis.ohio-state.edu/htbin/rfc/rfc1157.html

ILMI использует протокол SNMP, разработанный в качестве простого средства управления сетевыми устройствами с четкой структурой. Сообщения протокола SNMP делятся на две части — идентификатор версии с именем сообщества (community name), затем данные (PDU).

Идентификатор версии и имя сообщества иногда называют заголовком аутентификации (authentication header). Идентификатор версии обеспечивает использование одной версии протокола SNMP в управляющих станциях и агентах (управляемое устройство). Сообщения между станцией управления и агентом, содержащие другой номер версии, отбрасываются без дальнейшей обработки. Имя сообщества удостоверяет права управляющей станции на доступ к агенту. Имя сообщества совместно с IP-адресом станции управления сохраняются в community-профайле агента. Если имена сообществ различаются для агента и станции управления, агент посылает станции управления сообщение об ошибке аутентификации (authentication failure trap message).

GetRequest и GetResponse.

Станция управления использует пакеты GetRequest для получения значений одного или нескольких объектов MIB от агента. При отсутствии ошибок агент генерирует пакет GetResponse в ответ на полученный запрос. В обоих типах пакетов присутствует поле Request Index, которое служит для установки соответствия между запросами и откликами на них. Кроме того, в обоих типах сообщений используются поля Error Status (оно имеет значение noError) и Error Index (0). В рассмотренном процессе возможно возникновение четырех типов ошибок:

1. Если запрашиваемая переменная не имеет точного соответствия с существующими объектами, агент возвращает сообщение GetResponse с Error Status=NoSuchName и полем Error Index, значение которого совпадает с индексом переменной в запросе.
2. Если переменная имеет совокупный (aggregate) тип, ответ формируется таким же образом (см. пункт 1).
3. Если размер пакета GetResponse превышает локальные ограничения, агент возвращает сообщение GetResponse идентичной формы с Error Status = tooBig и Error Index = 0.
4. Если значение запрошенной переменной не может быть возвращено по иным причинам, агент возвращает сообщение GetResponse с Error Status = genErr и полем Error Index, содержащим значение индекса переменной в запросе.

На приведенном ниже рисунке содержится пример декодирования пакета GetRequest:

 

Пример декодирования пакета GetRequest.

GetNextRequest

Пакет типа GetNextRequest используется для получения от агента значения одного или нескольких объектов. При отсутствии ошибок агент генерирует сообщение GetResponse, для которого значение Request Index совпадает с аналогичным полем полученного запроса GetNextRequest. Поле Variable Bindings содержит имя и значение лексического потомка для объекта, идентификатор которого (OID — object identifier) указан в запросе GetNextRequest. Основная разница между пакетами GetRequest и GetNextRequest заключается в том, что по запросам GetNextRequest возвращается значение следующего объекта в MIB агента. В процессе обработки запросов возможны три типа ошибок:

1. Если поле Variable Bindings содержит переменную, которая не соответствует ни одному имени объекта в MIB, агент возвращает сообщение GetResponse с Error Status = noSuchName и полем Error Index, содержащим значение переменной в запросе.
2. Если размер пакета GetNextResponse выходит за пределы локальных ограничений, агент возвращает сообщение GetResponse идентичной формы с Error Status = tooBig и Error Status = 0.

3. Если значение лексического потомка запрашиваемой переменной по каким-либо причинам не может быть получено, агент возвращает сообщение GetResponse с Error Status = genErr и полем Error Index, содержащим значение индекса переменной в запросе.

SetRequest

Сообщения SetRequest служат для задания значений объектов MIB, хранящихся в агенте. Когда агент получает пакет SetRequest, он устанавливает для заданного объекта значение, содержащееся в сообщении. При отсутствии ошибок агент возвращает сообщение GetResponse идентичной формы, устанавливая в поле типа пакета значение 2. В рассматриваемом процессе возможно четыре типа ошибок:

1. В том случае, если переменная не может быть использована для присвоения значений объект MIB, агент возвращает сообщение GetResponse с Error Status = NoSuchName (или ReadOnly) и полем Error Index, содержащим значение индекса переменной в запросе.
2. Если переменная по типу, длине или значению не соответствует синтаксису ASN.1, агент возвращает сообщение GetResponse с полями Error Status и Error Index, содержащими значение badValue.
3. Если размер пакета SetResponse превышает локальные ограничения, агент возвращает сообщение GetResponse идентичной формы, с Error Status = tooBig и Error Status = 0.

4. Если значение переменной не может быть обработано по каким-либо иным причинам, агент возвращает сообщение GetResponse с Error Status = genErr и полем Error Index, содержащим значение индекса переменной в запросе.

Trap

Последний тип сообщений протокола SNMP — это прерывания (Trap). Сообщения этого типа имеют формат, отличный от формата остальных четырех типов, и содержат следующие поля:

• Поле Enterprise (Предприятие) идентифицирует организацию, для которой были определены регистрационные полномочия.

• Прерывания общего типа (Generic Trap Type) обеспечивают более детальную информацию о событии. Для этого поля существует семь уникальных значений: coldStart («холодная» перезагрузка), warmStart («теплая» перезагрузка), linkDown (разрыв соединения), LinkUp (организация соединения), authentication Failure (ошибка аутентификации), egpNeighborLoss (потеря соседа в EGP) и enterpriseSpecific (фирменное значение для предприятия).
• Поле Specific Trap Type идентифицирует конкретное прерывание.

• Поле timestamp — содержит временную метку, содержащую значение времени, прошедшего с момента инициализации агента до генерации данного прерывания.

• Значения переменных.

На рисунке показан пример декодирования прерываний.

Пример декодирования пакета Trap

SMI

Общее описание

SMI (Structure of Management Information — структура управляющей информации) является стандартом, служащим для определения правил идентификации объектов управления (management objects). SMI организует, именует и описывает информацию для обеспечения логического доступа к ней. В соответствии с требованиями SMI каждый объект управления должен иметь имя, синтаксис и способ кодирования (представления). Имя или OID является уникальным идентификатором объекта. Синтаксис определяет тип данных (например, целое число или строка октетов). Тип представления описывает способ преобразования сведений об управляемом объекте в последовательную форму для передачи между машинами.

SMI определяет синтаксис обмена информацией и ее логической группировки, а также механизм именования (идентификации) объектов управления. Последний используется для идентификации каждого управляемого объекта. Возможно расширение SMI за счет включения баз данных MIB. Доступ к управляемым объектам осуществляется через MIB. Объекты MIB определяются в соответствии с ASN.1 (Abstract Syntax Notation One). Каждый тип объекта (object type) имеет имя, синтаксис и способ представления. Имя является уникальным и служит идентификатором объекта (OBJECT IDENTIFIER), который назначается администратором. Синтаксис определяет абстрактную структуру данных, соответствующую типу объекта. Примерами структуры объектов могут быть целое число (INTEGER) или строка октетов (OCTET STRING). Способ представления типа объектов описывает представление экземпляров данного типа.

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

Идентификатор объекта (object identifier) — это последовательность целых чисел, образованная пересечением глобального дерева MIB по вертикали. Дерево состоит из корня (root), с которым связаны ветвями (edge) маркированные (нумерованные) узлы. Каждый узел может служить корнем дочернего дерева (такой узел можно назвать субдеревом). Узлы субдерева, в свою очередь, могут порождать новые субдеревья и т.д. Количество уровней глобального дерева не ограничено.

У корневого узла нет номера, но он имеет по крайней мере три дочерних узла, напрямую связанных с корнем. Один из этих узлов администрируется организацией Международным комитетом по стандартизации (International Organization for Standartization — ISO) и обозначается iso (1), второй — управляется Международным телекоммуникационным союзом (International Telegraph and Telephone Consultative Committee или CCITT — современное название UTU-T) и обозначается ccitt (0), третий узел администрируется совместно ISO и CCITT и обозначается joint-iso-ccitt (2). Для узла iso (1) Международный комитет по стандартизации определил одно поддерево, используемое другими национальными и международными организациями, org (3). Из дочерних узлов этого узла два были выделены Американскому институту стандартов и технологий (US National Institute of Standards and Technology — NIST). Затем один из этих узлов — dod (6) — был передан NIST министерству обороны США (DoD), а последнее организовало дочерний узел для Internet. Этот узел администрируется организацией IAB (Internet Activities Boards) следующим образом:

internet Идентификатор объекта::= {iso org(3) dod (6) 1} -> 1.3.6.1

В этом субдереве присутствуют четыре узла:

directory Идентификатор объекта::= { internet 1 }

mgmt Идентификатор объекта::= { internet 2 }

experimental Идентификатор объекта::= { internet 3 }

private Идентификатор объекта::= { internet 4 }

Субдерево private(4) используется для идентификации объектов, определяемых в одностороннем порядке. Администрирование субдерева private(4) передано IAB в IANA (Internet к Internet Assigned Numbers Authority). Изначально это дерево имеет по крайней мере один дочерний узел:

enterprises Идентификатор объекта::= { private 1 }

Субдерево enterprises(1) передается организациям, производящим сетевое оборудование для использования в их продукции.

Некоторые организации разрабатывают собственные субдеревья для использования в своей продукции. Примером такого дерева может служить ATM UNI MIB. Производители оборудования могут определять собственные расширения ATM UNI MIB для поддержки дополнительных (фирменных) возможностей выпускаемой продукции. Объекты MIB определяются с использованием стандарта ASN.1, разработанного SMI. Синтаксис типа объекта задает абстрактную структуру данных, соответствующую типу определяемого объекта. Для формализации таких определений служит язык ASN.1. SMI в целях упрощения ограничивает перечень используемых конструкций ASN.1.

На рисунке показана в качестве примера структура ATM UNI ILMI MIB.

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

Ограничения протокола

В приведенном ниже списке перечислены некоторые ограничения для протокола SNMP:

• Сообщения ATM должны форматироваться в соответствии с SNMP версии 1, но не версии 2.
• Все сообщения SNMP должны использовать имя сообщества ILMI.
• Во всех прерываниях SNMP поле адреса агента должно содержать IP-адрес 0.0.0.0.
• Поддерживаемые типы пакетов Trap — coldStart и enterpriseSpecific.
• Во всех пакетах Trap SNMP поле timestamp (временная метка) содержит значение объекта MIB sysUpTime на момент генерации прерывания. Во всех стандартных прерываниях Trap поле enterprise содержит значение объекта sysObjectID.

• Размер сообщения не может превышать 484 октетов.

Протокол Network Basic I/O System (NetBIOS) в версии TCP/UDP был разработан для локальных сетей IBM PC с целью обеспечения обмена данными между станциями, имеющими символьные имена.

Протокол SMB (Server Message Block — блок серверных сообщений) является протоколом уровня представления (presentation layer) компании Microsoft, обеспечивающим функции разделения файлов и принтеров для LAN Manager, VINES и других сетевых опреационных систем. Протокол IBM NetBIOS поддерживает использование сетевых имен и соединений на транспортном уровне для протоколов вышележащих уровней (таких, как SMB). Стек протоколов IBM включает в себя следующие компоненты:

• NetBIOS: Network Basic I/O System (базовая сетевая система ввода/вывода).
• SMB: Server Message Block (блок серверных сообщений).
• SNA: Systems Network Architecture (системная архитекура сети).

• HPR-APPN: High Performance Routing – Advanced Peer to Peer Network (высокопроизводительная маршрутизация –одноранговая сеть с расширенными возможностями).

• NHDR: Networl Layer Header (заголовок сетевого уровня).

• THDR: RTP Transport header (транспортный заголовок RTP).

• DLSw: Data Link Switching (коммутация канального уровня).

Приведенный ниже рисунок иллюстрирует положение стека протоколов IBM в эталонной модели OSI:

Положение стека протоколов IBM в эталонной модели OSI

NetBIOS

IBM Local Area Network Technical Reference 1990 4th edition.

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

Формат заголовка NetBIOS показан на рисунке:

Длина

XxEFFF

Команда

Дополн. данные 1

Дополн. данные 2

Коррелятор передача/ отклик

Имя/ номер получателя

Имя/ номер отправителя

Структура заголовка NetBIOS

Длина

Размер заголовка пакета NetBIOS

XxEFFF

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

Команда

Код команды протокола, задающий функциональный тип пакета.

Данные 1

Один байт необязательных данных для указанной команды

Данные 2

Два байта необязательных данных для указанной команды.

Коррелятор передача/отклик

Используется для связывания полученного ответа (отклика) с ранее отправленным запросом. Коррелятор передачи — это значение, возвращаемое в отклике на данный запрос. Коррелятор отклика — это значение, ожидаемое при получении отклика на сообщение.

Имя/номер получателя

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

Имя/номер отправителя

В пакетах, не принадлежащих какой-либо сессии, это поле содержит 16-символьное имя. В пакетах сессии это поле содержит В кадрах сессий это поле содержит однобайтовый номер сессии отправителя.

SMB

ftp://ftp.microsoft.com/developr/drg/CIFS

File Sharing Protocol 1987, SMB File Sharing Protocol Extensions, 1998, SMB File Sharing Protocol 1996.

Протокол SMB (Server Message Block — блок серверных сообщений) является протоколом уровня представления компании Microsoft, обеспечивающим функции разделения файлов и принтеров для LAN Manager, VINES и других сетевых опреационных систем. IBM NetBIOS поддерживает использование сетевых имен и соединений на транспортном уровне для протоколов вышележащих уровней (таких, как SMB).

SMB служит для совместного использования в сети файлов, принтеров, последовательных портов и коммуникационных абстракций (например, именованные каналы и почтовые слоты между компьютерами). Этот протокол относится к числу протоколов клиент-сервер типа запрос-ответ. Клиенты подключаются к серверу, используя протокол TCP/IP. После этого они могут посылать серверу команды (SMB), позволяющие получать доступ к файлам и другим сетевым ресурсам.

Существует множество вариантов протокола SMB. Первым вариантом был Core Protocol (Основной Протокол), известный как PC Network Program 1.0 (Сетевая программа для ПК версии 1.0). Этот протокол обеспечивал базовый набор операций, включающий:

• Подключение и отключение разделяемых файлов и принтеров.
• Открытие и закрытие файлов.
• Открытие и закрытие файлов печати.
• Операции чтнеия и записи файлов.
• Создание и удаление файлов и каталогов.
• Поиск в каталогах.
• Чтение и установка файловых атрибутов.

• Блокировка и разблокировка групп последовательных байтов в файле.

Существует несколько различных версий и подверсий данного протокола. Частные реализации протокола рассматриваются как диалекты (dialect). Когда две машины впервые организуют контакт через сеть, они договариваются о том, какой диалект будет использоваться. Различные диалекты могут включать как новые сообщения, так и изменения в полях и семантике существующих в других диалектах сообщений. Каждый сервер создает набор ресурсов, доступных сетевым клиентам. Разделяемыми ресурсами могут быть деревья каталогов, именованные каналы, принтеры и т. д. С точки зрения клиента сервер не поддерживает какого-либо сервиса, зависящего от других серверов; клиент рассматривает сервер как единственного поставщика используемых ресурсов.

Протокол SMB требует от сервера аутентификации пользователей до предоставления им доступа к ресурсам. Каждый сервер проверяет полномочия своих пользователей. Клиент должен передать сведения для аутентификации информацию перед тем, как сервер предоставит ему доступ к ресурсам.

Общий формат заголовка показан на следующем рисунке:

Биты
8	16	24	32
COM	RCLS	REH	ERR
ERR	REB/Флаг	Зарезервировано
Зарезервировано
Зарезервировано
Зарезервировано
Идентификатор дерева (Tree ID)		Идентификатор процесса (Process ID)
Идентификатор пользователя (User ID)		Мультиплексный идентификатор (Multiplex ID)
WCT	VWV
BCC		BUF

Структура кадра SMB

COM

Команды протокола. Ниже приведен список команд, которые могут использоваться в кадрах SMB.

Команда	Описание
[bad command]	Неправильная команда SMB.
[bind (UNIX)]	Получить адрес файла в файловой системе.
[cancel forward]	Отменить опознавание имени сервером.
[change/check dir]	Изменить каталог или проверить маршрут
[change group]	Изменить принадлежность пользователя к группе
[change password]	Изменить пароль пользователя.
[close file]	Закрыть файл и очистить буферы.
[close spoolfile]	Закрыть буфер файла печати.
[consumer logon]	Войти с аттестацией «потребитель».
[copy file]	Копировать файл по заданному маршруту.
[copy new path]	Копировать файл по новому маршруту.
[create & bind]	Создать файл и дать ему адрес в файловой системе.
[create directory]	Создать новый каталог.
[create file]	Создать новый или открыть существующий файл.
[delete dir]	Удалить указанный каталог.
[delete file]	Удалить указанный файл.
[echo]	Запрос эхо от сервера.
[find & close]	Найти файл и закрыть каталог (UNIX).
[find & close /2]	Найти файл и закрыть каталог (OS/2).
[find first file]	Найти первый соответствующий файл (OS/2).
[find unique]	Искать каталог для указанного файла.
[flush file]	Записать все файловые буферы на диск.
[fork to PID]	Предоставить те же права доступа новому процессу.
[forward name]	Заставить сервер принять сообщение для указанного имени.
[get access right]	Получить права доступа для определенного файла.
[get exp attribs]	Получить расширенные атрибуты файла (OS/2).
[get unix attribs]	Получить расширенные атрибуты файла (UNIX).
[get file attribs]	Получить расширенные атрибуты указанного файла.
[get file queue]	Получить список очереди на печать.
[get group info]	Получить связь с логической группой.
[get machine name]	Выяснить имя машины для блока сообщений.
[get pathname]	Выяснить маршрут для заданного дескриптора (handle).
[get resources]	Выяснить готовность ресурсов сервера.
[get server info]	Получить информацию о размере и количестве свободного пространства на диске сервера.
[get user info]	Выяснить связь пользователя с логической группой.
[IOCTL]	Инициализировать управление вводом/выводом (I/O control) для устройств DOS-OS/2.
[IOCTL next]	Инициализировать следующее управление вводом/выводом для устройств DOS-OS/2.
[IOCTL (UNIX)]	Управление вводом/выводом для устройств UNIX-Xenix.
[link file]	Создать дополнительный маршрут к файлу.
[lock and read]	Блокировать и читать диапазон байтов.
[lock bytes]	Блокировать указанный диапазон байтов..
[lock/unlock & X]	Блокировать/разблокировать байты и выполнить следующую команду.
[logoff & execute]	Закончить сеанс (Log off) и выполнить следующую команду.
[mail announce]	Выяснить доступность серверных узлов.
[mailslot message]	Сообщение транзакции почтового слота.
[make/bind dir]	Создать каталог и получить адрес в файловой системе.
[make temp file]	Создать временный файл данных.
[make new file]	Создать новый файл, если он не существует.
[make node]	Создать файл для использования в качестве устройства.
[move file]	Переместить файл в указанный каталог (OS/2).
[move new path]	Переместить файл в указанный каталог (UNIX/Xenix).
[multi-block data]	Послать данные для многоблочного сообщения.
[multi-block end]	Прервать многоблочное сообщение.
[multi-block hdr]	Послать заголовок многоблочного сообщения.
[named pipe call]	Открыть, записать, прочитать или закрыть именованный канал.
[named pipe wait]	Ждать готовности именованного канала к работе.
[named pipe peek]	Посмотреть данные именованного канала.
[named pipe query]	Запросить режим указателя именованного канала.
[named pipe set]	Установить режим указателя именованного канала.
[named pipe attr]	Запросить атрибуты именованного канала.
[named pipe R/W]	Транзакция чтения/записи для именованного канала.
[named pipe read]	Чтение именованного канала в режиме необработанных данных (raw).
[named pipe write]	Запись в именованный канал в режиме необработанных данных (raw)
[negotiate protoc]	Согласование версии протокола SMB.
[newfile & bind]	Создать новый файл и получить его адрес в файловой системе.
[notify close]	Закрыть дескриптор, используемый для мониторинга изменений в файле.
[open file]	Открыть указанный файл.
[open & execute]	Открыть указанный файл и выполнить следующую команду.
[open spoolfile]	Открыть указанный буферный файл печати.
[process exit]	Прервать пользовательский процесс.
[read & execute]	Читать файл и выполнить следующую команду.
[read and hide]	Читать каталог, игнорируя скрытые файлы.
[read block mplex]	Читать блок данных на мультиплексируемом соединении.
[read block raw]	Читать блок данных на уникальном соединении.
[read block sec/r]	Читать блок повторного отклика.
[read check]	Проверить доступность файла.
[read from file]	Читать из указанного файла.
[read w/options]	Читать из файла с указанными опциями.
[rename file]	Присвоить указанному файлу новое имя.
[reserve resourcs]	Зарезервировать ресурсы на сервере.
[search dir]	Искать каталог с указанными атрибутами.
[seek]	Установить указатель файла для дескриптора.
[send broadcast]	Послать один блок ширковещательным сообщением.
[session setup]	Войти в систему с аутентификацией, основанной на типе «потребитель».
[set exp attrib]	Установить расширенные атрибуты файла (OS/2).
[set unix attribs]	Установить расширенные атрибуты файла (UNIX/Xenix).
[set file attribs]	Установить нормальные атрибуты файла.
[single block msg]	Послать сообщение из одного блока.
[transaction next]	Следующая транзакция имени.
[tree & execute]	Создать виртуальное соединение и выполнить следующую команду.
[tree connect]	Создать виртуальное соединение.
[tree disconect]	Отключить виртуальное соединение.
[unbind]	Отменить связывание (bindings) адресов файловой системы.
[unlock bytes]	Освободить заблокированную область байтов.
[write & close]	Записать и закрыть указанный файловый дескриптор.
[write & execute]	Записать в файл и выполнить следующую команду.
[write & unlock]	Записать и разблокировать область байтов.
[write block raw]	Записать блок данных на уникальном соединении.
[write block mplx]	Записать блок данных на мультиплексируемом соединении.
[write block sec]	Записать блок вторичного запроса.
[write complete]	Прервать запись последовательности блоков.
[write spoolfile]	Записать в указанный буфер печати.
[write to file]	Записать в указанный дескриптор файла.
[X2 open file]	Открыть файл.
[X2 find first]	Найти первый файл.
[X2 find next]	Найти следующий файл.
[X2 query FS]	Получить информацию о файловой системе.
[X2 set FS info]	Установить информацию о файловой системе.
[X2 query path]	Получить информацию о маршруте.
[X2 set path]	Установить информацию о маршруте
[X2 query file]	Получить информацию о файле.
[X2 set info]	Установить информацию о файле
[X2 FS control]	Управляющая информация файловой системы.
[X2 IOCTL]	Управление устройствами ввода/вывода.
[X2 notify]	Мониторинг изменений в файле.
[X2 notify next]	Следующий мониторинг файла.
[X2 make dir]	Создать каталог.

RCLS

Класс ошибки (Error Class). Второе поле заголовка SMB содержит класс ошибки и ее код для каждого кадра (например, E=1/22, где 1 — это класс ошибки, 22 — код). Код ошибки идентифицирует источник ошибки, как показано в таблице:

Класс ошибки	Имя	Источник ошибки
0		Ошибок нет
1	ERRDOS	Операционная система сервера
2	ERRSRV	Сетевой файловый менеджер сервера
3	ERRHRD	Система или устройство
4	ERRXOS	Расширенная операционная система
225-227	ERRRMX	Операционная система RMX
255	ERRCMD	Неправильная команда SMB

REH

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

ERR

Сообщение об ошибке. Ниже приведен перечень сообщений об ошибках протокола SMB:

Сообщение	Описание ошибки
{Access denied}	Невозможно обслужить запрос
{Access list full}	Список управления доступом полон.
{Bad attrib mode}	Указаны неправильные атрибуты.
{Bad disk request}	Неправильная дисковая команда.
{Bad drive spec}	Неправильно указан накопитель.
{Bad environment}	Некорректное окружение.
{Bad EXE file}	Неправильный формат исполняемого файла.
{Bad file access}	Некорректный доступ к файлу «только дял чтения».
{Bad file ID}	Некорректный дескриптор файла.
{Bad filespec}	Некорректный маршрут.
{Bad format}	Неправильный формат.
{Bad function}	Функция не поддерживается.
{Bad I/O data}	Некорректные данные на устройстве ввода/вывода сервера.
{Bad math argument}	Некорректный математический аргумент.
{Bad media type}	Неизвестный тип среды (media).
{Bad memory block}	Неправильный адрес блока памяти.
{Bad open mode}	Некорректный режим открытия.
{Bad permissions}	Указанные права доступа неверны.
{Bad print FID}	Некорректный идентификатор файла печати.
{Bad print request}	Неправильный запрос на устройство печати.
{Bad reqst length}	Некорректная длина структруры запроса.
{Bad semaphore}	Некорректный идентификатор семафора.
{Bad SMB command}	Неправильная команда SMB.
{Bad Tree ID}	Некорректный идентификатор дерева.
{Bad User ID}	Неправильный идентификатор пользователя.
{Bad user/passwrd}	Неправильный пароль или имя пользователя.
{Bad wait done}	Установки ожидания для процесса, не поддерживающего режим ожидания.
{Continue in MPX}	Продолжение в режиме мультиплексирования блоков.
{Can’t delete dir}	Невозможно удалить текущий каталог.
{Can’t init net}	Сеть не может быть инициализированна.
{Can’t mount dev}	Устройство не может быть смонтированно.
{Can’t RAW, do MPX}	Невозможно использование необработанных блоков, следует применять мультиплексирование.
{Can’t ren to vol}	Ошибка при попытке переименования тома.
{Can’t support RAW}	Невозможна поддержка доступа к необработанным блокам.
{Can’t write dir}	Ошибка при попытке записи в каталог.
{Command not recvd}	Исходная команда не получена.
{CRC data error}	Ошибка CRC для устройства.
{Dev out of space}	На устройстве закончилось свободное пространство.
{Device is remote}	Ссылка на удаленное устройство.
{Dir not found}	Каталог не найден.
{Disk write error}	Ошибка записи на диск.
{Disk read error}	Ошибка чтения с диска.
{Disk seek error}	Ошибка поиска на диске.
{Drive not ready}	Устройство не готово.
{Dup filename}	Файл с таким именем уже существует.
{EOF on printer}	В дампе принтерной очереди обнаружен признак завершения файла.
{Err buffered}	Сообщение об ошибке буферизовано.
{Err logged}	Сообщение об ошибке помещено в файл протокола.
{Err displayed}	Сообщение об ошибке показано.
{File not found}	Указанный файл не найден.
{File too big}	Превышен максимальный размер файла.
{Gen disk failure}	Дисковая ошибка общего типа.
{Insuf acc rights}	Недостаточные права доступа.
{Invalid name}	Указано неверное имя для доступа к дереву.
{Invalid pipe}	Неверно указан канал.
{Lock conflict}	Конфликт блокировок.
{Memory blks lost}	Поврежден блок управления памятью.
{More data coming}	Невозможно завершить — продолжают поступать данные.
{Need block device}	Файл используется вместо блочного устройства (block device).
{Need data file}	Необходимо указать файл данных.
{No FCBs available}	Нехватка блоков управления файлами.
{No more files}	Болеше не найдено соответствующих файлов.
{No proc to pipe}	Нет процессов, доступных для канала.
{No read process}	Запсиь в канал без процессов чтения.
{No resources}	Нехватка ресурсов сервера.
{No room f/message}	Нет мест для буферизации сообщений.
{Not a directory}	Необходимо указать каталог.
{Not receiving}	Нет полученных сообщений.
{No semaphores}	Семафор не доступен.
{OK}	Команда SMB завершена успешно.
{Out of disk space}	В очереди печати закончилось дисковое пространство.
{Out of handles}	Слишком много открытых файлов.
{Out of memory}	Недостаток памяти на сервере.
{Out of paper}	В принтере закончилась бумага.
{Pipe is busy}	Канальный процесс занят — требуется ждать.
{Pipe is closing}	Уничтожение канального процесса.
{Print Q full}	Таблица очереди файлов печати заполнена.
{Proc table full}	Таблица процессов на сервере заполнена.
{Rem I/O error}	Удаленная ошибка ввода/вывода.
{Sector not found}	Сектор не найден.
{Seek on pipe}	Для канала был запущен поиск.
{Server error}	Общая ошибка сервера.
{Server paused}	Сервер приостановлен.
{Share buffer out}	Переполнение разделяемого буфера.
{Share conflict}	Конфликт разделения доступа с существующим файлом.
{Syntax error}	Синтаксическая ошибка в имени маршрута.
{Sys call intruptd}	Прерванный системный вызов.
{Table overflow}	Переполнение внутренней таблицы.
{Terminal needed}	Требуется терминальное устройство (terminal device).
{Timed out}	Операция вышла за пределы предосталенного времени.
{Too many links}	Слишком много соединений.
{Too many names}	Слишком много имен удаленных пользователей.
{Too many UIDs}	Превышен предел для идентификатора пользователя.
{Unit unknown}	Неизвестная единица.
{Unknown error}	Неуказанная ошибка.
{Unknwn process}	Нет такого процесса.
{Write protected}	Запись на дискету, защищенную от записи.
{Wrong diskette}	Некорректная дискета в устройстве.

REB/Флаг

Резервное поле Core Protocol. Для протоколов более поздних версий это поле служит в качестве флага.

Идентификатор дерева (Tree ID)

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

Идентификатор дерева (Tree ID)

Идентифицирует процесс потребителя в виртуальном соединении.

Идентификатор пользователя (User ID)

Используется сервером для проверки прав пользователя на доступ к файлу в том случае, если используется защита файлов на основе информации о пользователе.

Идентификатор мультиплексирования (Multiplex ID)

Зарезервировано для мультиплексирования нескольких сообщений на одном виртуальном устройстве (VC). Ответное сообщение всегда будет содержать значение этого поля. На виртуальном канале в каждый момент времени может присутствовать только один запрос, на который еще не получен ответ.

WCT

Число слов параметров.

VWV

Переменное число слов параметров.

BCC

Число последующих байтов данных.

BUF

Переменное число байтов данных.

SDLC

IBM SNA Formats GA27-3136-10 1989-06.

Протокол SDLC (Synchronous Data Link Control – управление синхронным каналом данных) был разработан фирмой IBM для использования в качестве протокола канального уровня в сетях иерархии SNA. Данные SNA помещаются в информационное поле пакетов SDLC. Ниже приведен формат стандартного пакета SDLC:

<———- Заголовок 			<————- Трейлер 
Флаг	Адрес	Управление	Информация	FCS	Флаг

Формат кадра SDLC

Флаг

Значение флага всегда равно 0x7E. Флаги используются для разделения пакетов. Чтобы исключить появление такой же последовательности битов внутри самого пакета, передатчик и приемник используют метод заполнения (Bit Stuffing).

Адрес

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

Управление

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

Каждый кадр содержит однобитовое поле опрос/завершение (Poll/Final). В протоколе SDLC этот бит указывает «говорящую» сторону и обеспечивает управление процессом следующей передачи (кто будет «говорить» и когда). Когда ведущая станция заканчивает передачу серии кадров, она устанавливает бит в состояние Poll, передавая управление вторичной станции. Когда вторичная станция заканчивает передачу серии кадров, она устанавливает бит в состояние Final, возвращая управление ведущей станции.

Режимы работы

В протоколе SDLC существуют понятия ведущей (primary) и вторичных (secondary) станций, первая является инициатором связи, а остальные только отвечают на запросы ведущей станции. Тип станций задается при организации сессии. В ходе сессии ведущая станция передает команды, а вторичные станция — отклики на эти команды.

Протокол SDLC работает в NRM (Normal Response Mode — нормальный отклик). Этот режим относится к типу «ведущий-ведомый» (master-slave) — в каждый момент времени только одна станция может передавать пакеты (когда ей это разрешено). Работа в таком режиме обеспечивается использованием кадров SNRM(E). Ведущая станция инициализирует сессию и передает команды. Вторичные станция передают отклики на полученные запросы. Для любой передачи кадров такой системе используется опрос (polling).

FCS

Контрольная сумма (Frame Check Sequence – FCS) позволяет проверять целостность принятых данных. Это поле вычисляется сначала отправителем пакета на базе алгоритма, учитывающего все биты передаваемого кадра. При получении кадра на приемной стороне контрольная сумма вычисляется заново и сравнивается со значением, содержащимся в полученном пакете.

Размер окна

SDLC поддерживает использование окон расширенного размера (по модулю 128), т. е. количество переданных и неподтвержденных пакетов данных может составлять от 8 до 128. Расширенный размер окна передачи обычно используется при спутниковой связи, где задержка подтверждений приема может быть значительно больше, чем время передачи самих кадров данных.Тип кадра инициализации соединения определяет модуль для сессии — в случае использования расширенного окна к имени базового типа пакета добавляется “E” (SNRM превращается в SNRME).

Типы пакетов

Протокол SDLC использует управляющие кадры (Supervisory Frame) нескольких типов:

RR Подтверждение приема информационного кадра и индикация готовности к приему последующей информации.

REJ Запрос повторной передачи всех кадров, начиная с указанного в данном кадре порядкового номера.

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

Ниже перечислены типы ненумерованных кадров (Unnumbered Frame), используемых в протоколе SDLC:

DISC Запрос разрыва соединения.

UA Кадр подтверждения приема данных.

DM Отклик на кадр DISC, указывающий на разрыв соединения.

FRMR Сброс кадра

CFGR Конфигурация

TEST Передается от ведущей станции к вторичной и обратно.

BCN Бакен (beacon)

SNRM Кадр, инициирующий режим нормального отклика. Поддержка отношений ведущий/ведомый.

SNRME SNRM в расширенном режиме.

RD Запрос на отключение

RIM Запрос вторичной станции на инициализацию после отключения.

SIM Установка режима инициализации.

UP Ненумерованный опрос.

UI Ненумерованная информация. Передача состояния информации или данных.

XID Идентификация команды обмена.

Протокол SDLC использует только один тип информационных кадров:

Infor Информационный кадр.

 

Распределение кадров SDLC по типам.

QLLC

QLLC представляет собой стандарт, разработанный для соединения ЛВС SNA через распределенные сети (WAN) с коммутацией пакетов X.25. Перед передачей кадров в сеть заголовок и трейлер кадров SDLC отсекаются и вместо них помещаются аналогичные поля протокола LAPB.

Этот стандарт также определяет дополнительные байты управления, позволяющие восстанавливать исходные кадры SDLC на приемной стороне. Информация SNA передается через сети в кадрах данных X.25 .

На рисунке показано расположение данных SNA и управляющих кадров QLLC в пакете данных X.25.

Кадры данных SNA и управления QLLC различаются по значению бита Q в заголовке пакетов X.25.

Типы кадров QLLC

QRR готовность к приему;

QDISC разрыв соединения;

QUA ненумерованное подтверждение;

QDM режим отключения;

QFRMR отбрасывание кадра;

QTEST тест;

QRD запрос на разрыв соединения;

QXID идентификация обмена;

QSM установка режима.

SNA

Протокол SNA (System Network Architecture — системная сетевая архитектура) был разработан компанией IBM в 1974 году для объединения разнотипной продукции компании в единую среду распределенной обработки. SNA была одной из первых коммуникационных архитектур на базе многоуровневой модели и послужила прототипом при создании эталонной модели OSI.

SNA представляет собой иерархическую сетевую архитектуру, содержащую группу машин, которые называются узлами сети. Определены четыре типа узлов — Type 1 (терминалы), Type 2 (контроллеры и машины, управляемые терминалами), Type 4 (периферийные процессоры и машины, выполняющие часть работы центрального процессора) и Type 5 (основной хост).

Каждый узел сети имеет по крайней мере один модуль NAU (Network Adressable Unit — сетевой модуль адресации). NAU позволяют процессам использовать сеть, предоставляя для этого адреса. После получения адреса процесс может взаимодействовать с другими процессами в системе через модули NAU.

Различаются три типа модулей NAU — LU (Logical Unit — логическое устройство), PU (Physical Unit — физическое устройство) и SSCP (System Service Control Point — точка управления системны сервисом). Обычно для каждого узла типа 5 используется один модуль SSCP; для узлов других типов эти модули не применяются.

SNA различает пять типов сессий — SSCP-SSCP, SSCP-PU, SSCP-LU, LU-LU и PU-PU.

Модули SSCP (PU типа 5) обычно реализуются в мэйнфреймах IBM, использующих каналы для подключения внешних устройств (контроллеры дисковых и ленточных накопителей, коммуникационные устройства). В таких случаях обычно используется высокая скорость (до 17 Мбит/с) обмена данными.

Коммуникационные контроллеры (FEP, периферийный процессор, PU типа 4) служат для подключения низкоскоростных каналов SDLC. SSCP, FEP и каналы SDLC образуют магистраль (backbone) SNA. С помощью SDLC к модулям FEP можно также подключать ЛВС Token Ring или каналы X.25, а также другие устройства SNA (например, кластерные контроллеры или станции RJE). Существуют устройства PU типов 2 и 2.1, используемые для управления логическими устройствами LU, являющимися оконечными точками сети SNA (например, сетевые терминалы серии 3270).

Формат кадров SNA показан на рисунке.

Заголовок передачи (TH)

Заголовок запроса/отклика (RH)

Модуль данных запроса/отклика (RU)

Формат заголовка SNA

Заголовок передачи

Поле TH содержит идентификатор формата (Format Identifier или FID), указывающий тип коммуникационного сеанса и используемое для него оборудование.

FID2 является форматом, используемым для связи между узлами T4 или T5 и соседними с ними узлами T2.1. Формат FID3 используется на соединениях с оборудованием PU T1 (типа контроллеров AS/400), а FID4 применяется для соединений между устройствами PU T4.

TH содержит также поле отображения (MPF), показывающее тип содержимого кадра — полный кадр SNA, содержащий TH, RH и RU, или просто сегмент. Когда кадр SNA слишком велик для передачи в один прием, он делится на несколько сегментов. Первый сегмент включает поле TH (это поле указывает на первый сегмент) и RH в начале поля RU. Остальные сегменты содержат поле TH, отличающееся от одноименного поля первого сегмента значением MPF, и остальную часть RU.

Заголовок запроса/отклика

Поле RH обозначает категорию кадра SNA, формат RU, наличие цепочки запросов и другие параметры кадров SNA.

Модуль данных запроса/отклика

Поле RU содержит «пользовательские данные», которые одно устройство LU передает другому, или специальный кадр SNA. Поле в заголовке RH служит для обозначения различий между классами кадров SNA. Существуют три категории специальных кадров SNA — NS (данные системы управления), DFC (управление потоком данных и SC (управление сеансом).

SNA TH0 и TH1

SNA TH0 и TH1 соответствуют заголовкам FID 0 и FID 1. Формат пакетов показан на рисунке.

4	6	7	8	Биты
FID	MPF	EFI
DAF (2 байта)
OAF (2 байта)
SNF (2 байта)
DCF (2 байта)

Структура пакетов SNA TH0 и TH1

FID

Идентификация формата кадра: 0 — FID 0, 1 — FID 1.

MPF

Поле отображения:

0 средний сегмент BIU

1 последний сегмент BIU

2 первый сегмент BIU

3. целый модуль данных BIU

EFI

Флаг управления потоком:

0 нормальный поток;

1 поток с диспетчеризацией.

DAF

Адрес получателя, задающий сетевой модуль адресации NAU.

OAF

Адрес отправителя, задающий сетевой модуль адресации NAU.

SNF

Поле порядкового номера модуля данных BIU.

DCF

Поле счетчика данных, содержащее двоичное значение числа байтов в BIU, если сегмент BIU связан с заголовком передачи.

Значение 5250 в кадрах с полем RH можно видеть на приведенном ниже примере содержимого буфера захвата.

 

5250 в поле RH кадров SNA

SNA TH5

SNA TH5 представляет собой заголовок FID 5. Формат заголовка показан на рисунке.

4	6	7	8	Биты
FID5 0101	MPF	R	EFI
Зарезервировано
SNF (2 байта)
SA (2 байта)

Структура заголовка FID 5

FID 5

Это поле всегда имеет значение 0101.

MPF

Поле отображения.

R

Резервный бит.

EFI

Индикатор диспетчеризации потока (1 бит).

SNF

Поле порядкового номера.

SA

Адрес сессии.

HPR-APPN

Сети HPR представляют собой расширение SNA. HPR (High Performance Routing — высокопроизводительная маршрутизация) является расширением на базе APPN, обеспечивающим некоторые важные преимущества. Новые функции протокола включают:

• неразрущающую коммутацию путей;
• более эффективное использование скоростных коммуникационных каналов;
• развитую систему контроля за насыщением сети;

• дополнительные функции, обеспечиваемые двумя новыми компонентами — RTP (Rapid Transport Protocol — скоростной транспортный протокол) и ANR (Automatic Network Routing — автоматичееская маршрутизация).

NHDR

Пакеты, передаваемые через соединения RTP, имеют специфический формат и состоят из трех компонент — NHDR, THDR и данные. Заголовок сетевого уровня (Network Layer Header или NHDR) размещвется в начале кадров, используемых узлами RTP (скоростной транспортный протокол). Этот заголовок обеспечивает адресацию для пакетов при передаче через сеть HRP. Компоненты этого заголовка включают приоритет передачи (transmission priority) и метки ANR (автоматическая маршрутизация). NHDR состоит из нескольких идентификаторов, обозначающих принадлежность пакетов сетевому уровню.

Формат заголовков показан на рисунке.

1	2	3	4	Биты
SM			TPF
TPF	Тип функции
Тип функции	TSP	Slowdown1	Slowdown2
ANR / поле функции маршрутизации (1 или 2 байта)

Формат заголовка NHDR

SM

Режим коммутации:

5 функции маршрутизации;

6 автоматическая сетевая маршрутизация.

TPF

Поле приоритета передачи может иметь следующие значения:

0 низкий приоритет (L);

1 средний приоритет (M);

2 высокий приоритет (H);

3 сеть (N).

Тип функции (для режима коммутации 5)

Тип функции говорит об уровне управления логическим каналом.

TSP

Индикатор чувствительного к задержкам пакета.

Slowdown 1 и 2

Эти поля говорят о наличии в сети условий насыщения — незначительного (Slowdown 1) или существенного (Slowdown 2). Поля могут принимать следующие значения:

0 насыщения нет;

1 присутсвтует данный уровень насыщения.

ANR (для SM=6)

Строка меток ANR длиной 1 или 2 байта. В конце строки размещается символ 0xFF.

Поле функции маршрутизации (для SM=5)

Двухбайтовый адрес функции маршрутизации (FRA или function routing address), за которым следует символ 0xFF.

THDR

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

Формат заголовка THDR показан на рисунке.

Идентификатор присваивания TCID (7 байтов)

Установка соединения (Connection setup) (1 бит)

Индикатор начала сообщения (1 бит)

Индикатор конца сообщения (1 бит)

Индикатор запроса состояния (1 бит)

Индикатор ASAP-отклика (1 бит)

Индикатор повтора (1 бит)

Индикатор последнего сообщения (1 бит)

Индикатор поля квалификации соединения (2 бита)

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

Смещение данных (2 байта)

Размер данных (2 байта)

Порядковый номер байта (4 байта)

Управляющий вектор 05

Дополнительные сегменты

Идентификатор присваивания TCID

Идентификатор транспортного соединения, который может принимать два значения:

0 TCID присваивается на приемной стороне RTP.

1. TCID присваивается на передающей стороне RTP.

Установка соединения

0 Присутствует

1 Отсутствует

Индикатор начала сообщения

0 Не является началом сообщения

1 Начало сообщения

Индикатор конца сообщения

0 Не является концом сообщения

1 Конец сообщения

Индикатор запроса состояния

0 Получатель не обязан передавать ответ

1 Получатель должен передать ответ с сегментом состояния

Индикатор ASAP-отклика

1 Отправитель будет повторно передавать ответ как можно скореее (ASAP — as soon as possible).

Индикатор повтора

0 Отправитель будет повторно передавать этот пакет.

Индикатор последнего сообщения

0 Сообщение не является последним

1 Последнее сообщение

Индикатор поля квалификации соединения

0 Отсутствует

1 Инициатор (originator)

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

0 Отсутствует

1 Присутствуют дополнительные сегменты.

Смещение данных

Размер данных

Порядковый номер байта

Порядковый номер первого байта поля данных.

Управляющий вектор 05

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

Дополнительные сегменты

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

0x0E Сегмент состояния

0x0D Сегмент установки соединения

0x10 Сегмент обмена идентификаторами соединений

0x14 Сегмент данных о коммутации

0x22 Сегмент Adaptive Rate-Based

0x12 Сегмент сбоя на соединении

0x0F Сегмент битов Client Out-of-band (нехватка полосы для клиента)

Каждый сегмент имеет следующую структуру:

Байт	Содержимое
0	Размер сегмента / 4
1	Тип сегмента
2	Данные

Каждый сегмент может содержать управляющие векторы. Список поддерживаемых векторов управления приведен ниже:

0x00 Управляющий вектор идентификатора узла

0x03 Управляющий вектор идентификатора сети

0x05 Управляющий вектор сетевого адреса

0x06 Управляющий вектор кросс-доменного менеджера ресурсов

0x09 Управляющий вектор идентификатора порядкового номера запроса/отклика активизации

0x0E Управляющий вектор сетевого имени

0x10 Управляющий вектор идентификатора набора продукции (Product Set ID)

0x13 Управляющий вектор возможности поддержки шлюза

0x15 Управляющий вектор квалифицированного в сети адреса

0x18 Управляющий вектор имени SSCP

0x22 Управляющий вектор ошибки согласования XID

0x26 Управляющий вектор идентификатора NCE

0x28 Управляющий вектор идентификатора темы (Topic)

0x32 Управляющий вектор режима Short-Hold

0x39 Идентификатор NCE Instant

0x46 Управляющий вектор дескриптора TG

0x60 Управляющий вектор полностью квалифицированного PCID

0x61 Управляющий вектор возможностей HPR

0x67 Управляющий вектор пути ANR

0xFE Код управляющего вектора не распознан

DLSw

IETF RFC 1434 http://www.ietf.org/rfc/rfc1434.txt

IETF RFC 1795 http://www.ietf.org/rfc/rfc1795.txt

IETF RFC 2166 http://www.ietf.org/rfc/rfc2166.txt

DLSw (Data Link Switching — коммутация на канальном уровне) представляет собой механизм рассылки для протоколов IBM SNA и IBM NetBIOS. При использовании в сетях IP протокол DLSw не обеспечивает полной маршрутизации, реализуя взамен этого коммутацию на канальном уровне SNA и инкапсуляцию в TCP/IP для передачи пакетов через Internet.

Коммутатор канального уровня (их обычно обозначают акронимом DLSw), может поддерживать системы SNA (PU 2, PU 2.1 и PU 4) и — дополнительно — системы NetBIOS, подключенные к локальным сетям, которые соответствуют стандарту IEEE 802.3, а также системы SNA (PU 2 — основные и вторичные, PU 2.1), подключенные к синхронным каналам IBM SDLC. В последнем случае системы, подключенные по каналам SDLC, для канального коммутатора представляются как устройства ЛВС (каждое устройство SDLC PU представляется протоколу SSP как уникальная пара адресов MAC/SAP). Для систем, подключенных к ЛВС Token Ring, коммутатор канального уровня выглядит как мост source-route. Удаленные системы Token Ring, подключенные через коммутатор DLSw, выглядят как системы соседнего кольца. Это кольцо является виртуальным кольцом, организуемом в каждом коммутаторе DLSw.

Для обмена между коммутаторами канального уровня используются два типа сообщений Control (управление) и Information (информация). Форматы сообщений обоих типов показаны ниже.

8	16	Октеты
Номер версии	Длина заголовка (16)	0-1
Длина сообщения		2-3
Удаленный DLC		4-7
Идентификатор порта удаленного DLC		8-11
Зарезервировано		12-13
Тип сообщения	Байт управления потоком	14-15

Структура информационного сообщения DLSw

8	16	Октеты
Номер версии	Длина заголовка (72)	0-1
Длина сообщения		2-3
Удаленный DLC		4-7
Идентификатор порта удаленного DLC		8-11
Зарезервировано		12-13
Тип сообщения	Байт управления потоком	14-15
Идентификатор протокола	Номер заголовка	16-17
Зарезервировано		18-19
Максимальный размер кадра	Флаги SSP	20-21
Приоритет устройства	Тип сообщения	22-23
MAC-адрес получателя		24-29
MAC-адрес отправителя		30-35
SAP канала отправителя	SAP канала получателя	36-37
Направление кадра	Зарезервировано	38-39
Зарезервировано		40-41
Длина заголовка DLC		42-43
Идентификатор порта DLC для отправителя		44-47
DLC отправителя		48-51
DLC отправителя		52-55
Транспортный идентификатор отправителя		56-59
Идентификатор порта DLC для получателя		60-63
DLC получателя		64-67
Транспортный идентификатор получателя		68-69
Зарезервировано		70-71

Структура управляющего сообщения DLSw

Номер версии

Поле номера версии содержит значение 0x31 (1 в коде ASCII), говорящее о первой версии DLSw.

Длина заголовка

Это поле определяет размер заголовка. Для управляющих кадров заголовок содержит 72 октета (0x48), для информационных — 16 октетов (0x10).

Длина сообщения

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

Удаленный DLC / Идентификатор порта удаленного DLC

Поля идентификатора и коррелятора (DLC — data link correlator) имеют сугубо локальное значение. Значения, полученные от другого DLSw не должны интерпретироваться канальным коммутатором, получившим их, а должны просто возвращаться (эхо) отправителю в последующих сообщениях

Тип сообщения

Поддерживаемые типы сообщений приведены в списке.

CANUREACH_ex Can U Reach Station-explorer

CANUREACH_cs Can U Reach Station-circuit start

ICANREACH_ex I Can Reach Station-explorer

ICANREACH_cs I Can Reach Station-circuit start

REACH_ACK Reach Acknowledgment

DGRMFRAME Datagarm Frame

XIDFRAME XID Frame

CONTACT Contact Remote Station

CONTACTED Remote Station Contacted

RESTART_DL Restart Data Link

DL_ RESTARTED Data Link Restarted

ENTER_BUSY Enter Busy

EXIT_BUSY Exit Busy

INFOFRAME Information (I) Frame

HALT_DL Halt Data Link

DL_ HALTED Data Link Halted

NETBIOS_NQ_ex NETBIOS Name Query-explorer

NETBIOS_NQ_cs NETBIOS Name Query-circuit start

NETBIOS_NR_ex NETBIOS Name Recognized-explorer

NETBIOS_NR_cs NETBIOS Name Recognized-circuit start

DATAFRAME Data Frame

HALT_DL_NOACK Halt Data Link with no Ack

NETBIOS_ANQ NETBIOS Add Name Query

NETBIOS_ANR NETBIOS Add Name Responce

KEEPALIVE Transport Keepalive Message

CAP_EXCHANGE Capabilities Exchange

IFCM Independent Flow Control Message

TEST_CIRCUIT_REQ Test Circuit Request

TEST_CIRCUIT_RSP Test Circuit Responce

Байт управления потоком

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

FCI

FCA

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

FCO

FCI индикация управления потоком

FCA подтверждение управления потоком

FCO биты оператора управления потоком

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

Идентификатор протокола имеет значение 66 (0x42)

Номер заголовка

Поле номера заголовка имеет значение 0x01

Максимальный размер кадра

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

Флаги SSP

Это поле содержит дополнительную информацию, связанную с сообщением SSP.

Приоритет устройства

Приоритет устройства является корректным параметром только для кадров типа CANUREACH_cs, ICANREACH_cs и REACH_ACK. Формат этого поля показан на рисунке.

8	3
Зарезервировано	CP

Формат поля приоритета устройств

Поле CP (Circuit Priority — приортет устройства) может принимать следующие значения:

000 Приоритизация не поддерживается. Это значение говорит о том, что канальный коммутатор, через который подключено устройство, не поддерживает приоритизации.

001 Низкой приоритет

010 Средний приоритет

100 Высокий приоритет

101 — 111 Зарезервированы

MAC-адрес получателя и отправителя
SAP канала отправителя и получателя

Каждый адрес подключенного устройства представляется конкатенацией (объединением) адресов подуровня MAC (6 байтов) и LLC (1 байт). Адреса квалифицируются как Target (получатель) в контексте адресов MAC/SAP получателей кадров исслодования (explorer), передаваемых в первом кадре, который служит для организации соединения, или Origin (отправитель) в контексте адресов MAC/SAP отправителей. Для выражения всех MAC-адресов используется неканонический (Token Ring) формат.

Направление кадра

0x01 для кадров, передаваемых от исходного (origin) DLSw к канальному коммутатору получателя (target), или 0x02 — для кадров обратного направления.

Длина заголовка DLC

Это поле содержит значение 0 для дейтаграмм SNA и 0x23 — для дейтаграмм NetBIOS (это говорит заголовке NetBIOS размером 35 байтов). Заголовок NetBIOS включает поля управления доступом AC (Access Control), управления кадром FC (Frame Control), MAC-адреса получателя (DA — Destination Address) и отправителя (SA — Source Address), поле маршрутной информации RI (Routing Information) размером 18 байтов (при нехватке информации используются байты заполнения), SAP канала-получателя (DSAP — Destination link SAP), SAP канала-отправителя (SSAP — Source link SAP) и поле управления LLC (UI).

Идентификатор порта DLC-отправителя и получателя
DLC отправителя и получателя

Сквозные соединения (end-to-end circuit) идентифицируются парами Circuit ID (идентификатор устройства). Каждый идентификатор устройства представляет собой 64-битовое число, указывающее DLC устройства в коммутаторе DLSw. Circuit ID содержит идентификатор порта DLC (4 байта) и коррелятор канального уровня (Data Link Correlator — DLC). Каждый идентификатор устройства в масштабе коммутатора DLSw должен иметь уникальное значение и выделяется локально. Пара идентификаторов устройств позволяет однозначно определить сквозное соединение. Каждый коммутатор DLSw должен сохранять таблицу пар Circuit ID для локальной и удаленной стороны каждого соединения. Для идентификации коммутатора DLSw, инициировавшего организацию соединения, используются термины Origin DLSw и Target DLSw.

Транспортный идентификатор отправителя и получателя

Транспортные идентификаторы служат для обозначения отдельных портов TCP/IP в коммутаторе DLSw. Эти идентификаторы имеют локальное значение, однако каждый коммутатор DLSw должен отражать значения, содержащиеся в полях транспортных идентификаторов, вместе со связанными значениями DLC и идентификатора порта DLC при возврате сообщений другому коммутатору DLSw.

На рисунке показан пример декодирования протокола DLSw.

 

Декодирование протокола DLSw

Терминология SNA

Systems Network Architecture (SNA)

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

Network Addressable Unit (NAU)

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

Logica Unit (LU)

Логическое устройство — порт, через который конечные пользователи получают доступ в сеть SNA для обмена информацией с другими пользователями или использования функций, предоставляемых контрольными точками системного сервиса SSCP. Каждое логическое устройство поддерживает по крайней мере две сессии (одну для SSCP, вторую — для другого LU) и может поддерживать множество сеансов обмена информацией с другими LU.

Physical Unit (PU)

Физическое устройство — один из трех типов адресуемых объектов NAU. Каждый узел сети SNA содержит физическое устройство, обеспечивающее поддержку и мониторинг ресурсов (например, подключенных каналов) узла по запросам контрольных точек SSCP посредством сеансов SSCP — PU. SSCP активизируют сеансы с PU для опосредованного управления ресурсами узла.

Systems Services Control Point (SSCP)

Контрольная точка системного сервиса — фокальная точка сети SNA для управления конфигурацией, координации запросов операторов или запросов на разрешение возникших проблем, а также поддежки каталогов и сеансового сервиса других типов для конечных пользователей сети. Группы SSCP, объединенные как одноранговые, позволяют делить сеть на области (домены) управления — в этом случае каждая точка SSCP имеет иерархические отношения с логическими и физическими устройствами в домене.

Bracket

Связка — одна или несколько цепочек запросов RU (Request Unit) и откликов на них между двумя полусессиями (half-session) LU — LU. Такие цепочки представляет транзакцию между логическими устройствами. Связка должна быть завершена до того, как будет активизирована новая связка.

Data Link Control (DLC) Layer

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

Normal Flow

Нормальный поток — поток данных, обозначенный в заголовке передачи TH и используемый, прежде всего, для передачи пользовательских данных. Скорость передачи данных через нормальный поток может регулироваться на уровне сеансов. Нормальные и расширенные потоки используются для обмена данных между основными (primary) и вторичными (secondary) узлами в обоих направлениях.

Expedited Flow

Ускоренный поток — поток данных, обозначенный в заголовке передачи TH и используемый для управления сетью и сеансом, а также передачи запросов и откликов RU. Ускоренные потоки отличаются от нормальных (которые обычно содержат пользовательские данные) и могут служить для передачи данных, управляющих нормальным потоком.

Explicit Route (ER)

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

LU Type 6.2

LU 6.2 представляет собой частный случай логического объекта SNA, который использует протоколы межпрограммной связи SNA. Для обозначения таких объектов используется также термин APPC (Advanced Program-to-Program Communication).

Network Services (NS) Header

Заголовок сетевого сервиса — трехбайтовое поле в запросе или отклике FMD в сеансе SSCP — LU, SSCP — PU или SSCP — SSCP. Заголовки сетевого сервиса используются в основном для идентификации категорий сетевого сервиса RU и кодов отдельных запросов в категории.

Node Type

Тип узла — обозначение узла в соответствии с поддерживаемым протоколом и содержащимся в нем NAU. Определены пять типов узлов — 1, 2.0, 2.1, 4 и 5. Узлы типов 1, 2.0, 2.1 являются переиферийными узлами, а узля типов 4 и 5 — узлями субобластей.

PU Type 2 (T2)

Сетевой узел, который может подключаться к сети SNA в качестве периферийного узла.

PU Type 2.1 (T2.1)

Сетевой узел, который может подключаться к сети SNA в качестве периферийного узла. В отличие от узлов типа 2, узлы 2.1 позволяют организовать прямые соединения между собой с использованием нижнего уровня SNA.

PU Type 4 (T4)

Сетевой узел, содержащий NCP и являющийся узлом субобласти в сети SNA.

PU Type 5 (T5)

Сетевой узел, содержащий VTAM и являющийся узлом субобласти в сети SNA.

RU Chain

Цепочка RU — группа связанных RU запросов или откликов, которые последовательно передаются в нормальный или ускоренный поток данных. Цепочка запроса является неделимым модулем (unit of recovery) — если для одного RU в цепочке обработка невозможна, отбрасывается вся цепочка. Каждый модуль данных RU может включаться только в одну цепочку, начало и завершение которой помечаются управляющими битами для заголовков запроса/отклика в цепочке. Каждая цепочка может быть обозначена как первая (FIC — first-in-chain), последняя (LIC — last-in-chain), средняя (MIC — middle-in-chain) или единственная (OIC — only-in-chain). Отклики и запросы ускоренных потоков всегда относятся к типу OIC.

Session Control (SC)

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

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

SSCP-LU Session

Сеанс между контрольной точкой системного сервиса SSCP и логическим устройством LU. Такой сеанс дает LU возможность запрашивать у SSCP помощи в организации сеанса LU-LU.

SSCP-PU Session

Сеанс между контрольной точкой системного сервиса SSCP и логическим устройством LU. Такой сеанс дает PU возможность посылать запросы и получать информацию о состоянии от отдельных узлов для контроля за конфигурацией сети.

SSCP- SSCP Session

Сеанс между контрольной точкой системного сервиса SSCP одного домена и SSCP другого домена. Такие сеансы используются для организации и разрыва междоменных сеансов LU-LU.

Token Ring

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