1

X.25

X.25 представляет собой рекомендации CCITT для интерфейса между устройствами DTE и DCE через телефонную сеть общего пользования (Public Switched Telephone Network- PSTN). В общем случае X.25 функционирует на уровнях 1 – 3 эталонной модели OSI, однако в данной главе термин X.25 используется только применительно к сетевому уровню модели OSI. Пакеты протокола X.25 передаются по сетям общего пользования в информационном поле кадров LAPB.

В данной главе описываются следующие протоколы:

  • LAPB
  • X.25
  • X.75
  • MLP
  • HDLC.

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

gif_32

Положение протоколов X.25 в эталонной модели OSI

LAPB

LAPB является протоколом канального уровня, используемым для передачи пакетов X.25. Формат стандартного кадра LAPB показан на рисунке.

Флаг

Адрес

Управление

Информация

FCS

Флаг

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

Флаг

Флаг служит для разделения кадров и всегда имеет значение 0x7E. Для того, чтобы исключить появление такой же последовательности битов внутри пакета, на приемной и передающей стороне используется метод вставки битов (Bit Stuffing).

Адрес

Первый байт после флага содержит поле адреса. Для протокола LAPB это значение не имеет смысла, поскольку протокол работает в режиме соединений “точка-точка” и адреса сетевого уровня устройств DTE представлены в пакетах сетевого уровня. В силу сказанного, поле адреса используется для других целей – оно служит для того, чтобы различать канальные команды и отклики и может содержать только два значения – 0x01 (команда от DTE к DCE или отклик на такую команду в обратном направлении) или 0x03 (команда от DCE к DTE или отклик на такую команду в обратном направлении).

Управление

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

Протокол LAPB не используется отношений ведущий-ведомый (master-slave), поэтому отправитель должен установить бит опроса (Poll) для того, чтобы получить ответ незамедлительно. В кадрах откликов этот бит служит флагом завершения (Final). Получатель всегда устанавливает флаг завершения в откликах на команды с установленным флагом Poll (опрос). Бит Poll/Final (P/F) в общем случае используется для проверки корректности порядка передачи кадров, поскольку существует возможность отсутсвия подтверждений приема.

Режимы работы

LAPB использует в асинхронный сбалансированный режим (Asynchronous Balanced Mode – ABM), обозначаемый SABM(E). Термин сбалансированный в данном случае обозначает отсутствие в соединении отношений “ведущий-ведомый”. Каждая станция может инициировать соединение, управлять им, обеспечивать восстановление после ошибок, а также передавать кадры в любой момент времени. Понятия DTE и DCE трактуются как эквивалентные.

FCS

Контрольная сумма (Frame Check Sequence – FCS) позволяет контролировать целостность передаваемых данных. Значение FCS рассчитывается отправителем кадра с учетом всех битов кадра. При получении пакета контрольная сумма рассчитывается заново и сравнивается со значением, содержащимся в принятом пакете.

Размер окна

LAPB поддерживает расширенный размер окна (модуль 128), при котором число ожидающих подтверждения кадров может составлять от 8 до 128. Этот режим используется для спутниковых каналов, где задержка подтверждения приема значительно больше, чем время передачи кадров. Тип кадра, инициирующего соединение, определяет модуль для сессии. При использовании расширенного окна к имени базового типа пакета добавляет “E” (т. е. SABM становится SABME).

Типы кадров

Протокол LAPB поддерживает следующие типы управляющих кадров (Supervisory Frame):

RR Подтверждение приема информационного кадра и индикация готовности к приему следующих кадров.

REJ Запрос повторной передачи всех кадров, начиная с указанного порядкового номера.

RNR Индикация состояния временной занятости станции (окно заполнено).

Ненумерованные кадры (Unnumbered Frame) могут быть следующих типов:

DISC Запрос разъединения.

UA Кадр подтверждения.

DM Отклик на запрос DISC, показывающий режим разъединения.

FRMR Отбрасывание (reject) кадра.

SABM Иницирует режим SABM, не использующий отношений ведущий -ведомый.

SABME Расширенный режим SABM.

Информационные кадры могут быть только одного типа:

Info Информационный кадр.

X.25

Структура пакета X.25 для модуля 8 показана на рисунке.

8

7

6

5

4

3

2

1

GFI

Q

D

s

s

LGN

LCN

Тип

P(R)

M

P(S)

0

Пользовательские данные

.

.

.

.

Структура пакета X.25 с модулем 8

Структура пакета X.25 с модулем 128 показана на следующем рисунке.

8

7

6

5

4

3

2

1

GFI

Q

D

s

s

LGN

LCN

Тип

P(S)

0

P(R)

M

Пользовательские данные

.

.

Структура пакета X.25 с модулем 128

GFI

Поле идентификатора формата (General format identifier – GFI) определяет структуру оставшейся части заголовка пакета.

Q Бит Q.

D Бит D.

s Последовательная схема – поле указывает модуль 8 (ss=1) или 128 (ss=2).

LGN

Номер группы логических каналов (Logical channel group number – LGN) – 4-битовое поле, совместно с полем LCN задающее номер логического канала.

LCN

Номер логического канала (Logacal channel number – LCN) – 8-битовое поле, задающее номер логического канала на линии DTE – DCE.

Тип пакета

8-битовое поле, указывающее тип пакета (в пакетах с модулем 128 поле типа имеет размер 16 битов). Поддерживаются следующие типы пакетов:

P(R) порядковый номер приема пакета, который содержится в пакетах данных и управления потоком (flow control), или адрес вызываемого DTE, который может содержаться в пакетах организации, регистрации или разрыва соединений.

P(S) порядковый номер передачи пакета, который содержится в пакетах данных, или адрес вызывающего DTE из пакетов

M флаг наличия дополнительных данных, который может присутствовать только в пакетах данных. Это поле всегла имеет значение 1, если пакет является частью последовательности, которая должна трактоваться как единое целое.

Пакеты могут быть следующих типов:

CALL ACC Вызов принят.

CALL REQ Запрос соединения.

CLR CNF Подтверждение разрыва (clear).

CLR REQ Запрос разрыва.

DATA Пакет данных.

DIAG Диагностика.

INT CNF Подтверждение прерывания.

INT REQ Запрос прерывания.

REJ Отказ.

RES CNF Подтверждение сброса.

RES REQ Запрос сброса.

RNR Приемник не готов.

RR Приемник готов.

RSTR CNF Подтверждение перезапуска.

RSTR REQ Запрос перезапуска.

REG REQ Запрос регистрации.

REG CNF Подтверждение регистрации.

X.75

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

На канальном уровне X.75 использует проткол LAPB аналогично тому, как это делает X.25. На сетевом уровне X.75 отличается от протокола X.25 наличием поля сетевых утилит (переменной длины) перед полем сетевых возможностей (также переменной длины) протокола X.25.

 X75

Пример декодирования X.75

MLP

Мультиканальный протокол MLP (Multilink procedure) располагается на дополнительном верзнем подуровне протокола канального уровня (LAPB) и работает между уровнем пакетов и множеством отдельных функций протокола канального уровня (SLP – Single Link).

Кадр MPL вставляется перед информационным полем LAPB, когда это указано в кадре LAPB. Структура MLC (multilink control field – поле управления мультиканалом) показана на рисунке.

4

5

6

7

8

16

MNH(S)

V

S

R

C

MNL(S)

Структура кадра MLC

MNH(S)

Биты 9-12 порядкового номера мультиликанальной передачи (12 битов).

MNL(S)

Биты 1-8 порядкового номера мультиликанальной передачи (12 битов).

V

Флаг отсутствия продолжения (последователей).

S

Бит опции проверки последовательности.

R

Бит запроса на сброс MLP.

C

Бит подтверждения сброса MLP.

MLP_LAPB

Пример декодирования MLP в LAPB

HDLC

Протокол HDLC (High Level Data Link Control – протокол управления логическим каналом на высоком уровне) был разработан ISO на основе ранних разработок компании IBM для протокола SDLC.

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

Флаг

Адрес

Управление

Информация

FCS

Флаг

Структура кадра HDLC

Флаг

Флаг служит для разделения кадров и всегда имеет значение 0x7E. Для того, чтобы исключить появление такой же последовательности битов внутри пакета, на приемной и передающей стороне используется метод вставки битов (Bit Stuffing).

Поле адреса

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

Управление

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

Каждый кадр содержит однобитовое поле Poll/Final (опрос/завершение). В режиме NRM этот бит указывает «говорящую» станцию, а также определяет, кто будет «говорить» следующим и когда. После того, как ведущая станция завершает передачу серии кадров, она устанавливает бит опроса (Poll), передавая управление ведомой станции. Получив управление, ведомая станция, может ответить ведущей. По окончании передачи ведомая станция устанавливает бит завершения, возвращая управление ведущей станции.

Режимы работы

HDLC может работать в трех режимах, отличающихся друг от друга уровнем отношений ведущий-ведомый (master/slave). Режим работы определяется типом пакета (uniwue frame type specifier):

  • Режим нормального отклика (Normal Response Mose – NRM) использует соотношение ведущий-ведомый и обозначается кадрами SNRM(E). Ведущая станция инициирует сессию, а для передачи используется система опроса ведомых узлов.
  • Режим асинхронного отклика (Asynchronous Response Mode – ARM) работает подобно NRM и обозначается кадрами SARM(E). Однако в этом режиме ведомая станция может передавать данные, не ожидая сигнала опроса (polling) от ведущей станции.
  • Асинхронный сбалансированный режим (Asynchronous Balanced Mode – ABM). В данном случае термин сбалансированный обозначает отношений ведущий-ведомый при связи устройств. Данный режим обозначается кадрами SABM(E). Каждая станция может инициировать соединение, обеспечивать восстановление после ошибок, поддерживать функции управления и передавать пакеты в любой момент времени.
FCS

Контрольная сумма (Frame Check Sequence – FCS) позволяет контролировать целостность принятых данных. FCS рассчитывается отправителем с учетом всех битов кадра. При получении кадра контрольная сумма вычисляется заново и сравнивается со значением, содержащимся в пакете.

Размер окна

HDLC поддерживает использование окон расширенного размера (по модулю 128), т. е. количество переданных и неподтвержденных пакетов данных может составлять от 8 до 128. Расширенный размер окна передачи обычно используется при спутниковой связи, где задержка подтверждений приема может быть значительно больше, чем время передачи самих кадров данных.Тип кадра инициализации соединения определяет модуль для сессии – в случае использования расширенного окна к имени базового типа пакета добавляется “E” (SABM превращается в SABME).

Расширенный адрес

HDLC подерживает еще одно расширение базового формата – поле адреса может быть увеличено по соглашению между системами, участвующими в соединении. При использовании расширенного адреса первый бит адреса должен иметь значение 1, указывая на то, что следующий байт также содержит адрес.

Типы кадров

Протокол HDLC использует управляющие кадры (Supervisory Frame) нескольких типов:

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

REJ Запрос повторной передачи всех кадров, начиная с указанного в данном кадре порядкового номера.

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

SREJ Запрос на повторную передачу кадра с указанным порядковым номером.

Ниже перечислены типы ненумерованных кадров (Unnumbered Frame), используемых в протоколе HDLC:

DISC Запрос разрыва соединения.

UA Кадр подтверждения приема данных.

DM Отклик на кадр DISC, указывающий на разрыв соединения.

FRMR Сброс кадра

SABM Кадр, инициализирующий асинхронный балансовый режим.

SABME SABM в расширенном режиме.

SARM Кадр, инициирующий режим асинхронных откликов.

SARME Расширенный режим SARM.

REST Сброс порядковых номеров.

CMDR Сброс команды.

SNRM Кадр, инициирующий режим нормального отклика.

SNRME Расширенный режим SNRM.

RD Запрос разрыва соединения.

RIM Запрос вторичной станции на инициализацию после разрыва соединения.

SIM Установка режима инициализации

UP Ненумерованный опрос.

UI Ненумерованная информация.

XID Идентификация команды обмена.

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

Info Информационный кадр.

Терминология X.25

Команда

Кадры LAPB являются командами или откликами на них (в зависимости от значения поля адреса и направления передачи кадра). Кадры команд от DTE содержат в поле адреса значение 1, кадры команд DCE – 3.

Управляющие кадры (Control frames)

Все кадры LAPB, исключая информационные кадры.

Управляющие пакеты (Control packets)

Все пакеты X.25, исключая пакеты типа данных (DATA).

Бит D

Флаг подтверждения доставки в заголовке пакета X.25, используемый для индикации уровня подтверждений между устройствами DTE и DCE – локальный (0) или глобальный (1). Этот флаг используется не всегда и в общем случае имеет нулевое значение.

Информационные кадры (Information frames)

Кадры LAPB, используемые для передачи данных через канал в информационном поле кадра. Информационное поле содержит заголовок пакета X.25 и данные в соответствии со стандартным протоколом сетевого уровня X.25.

LAPB

Протокол LAPB (Link Access Procedure-Balanced – процедура сбалансированного доступа к каналу), являющийся адаптацией CCITT для канального уровня протокола HDLC с интерфейсом X.25. Поле адреса LAPB (в отличие от адреса HDLC) может содержать только два возможных значения.

LCN

Номер логического канала (Logical Channel Number) совместно с номером группы каналов LGN идентифицирует логический канал на линии между устройствами DTE и DCE. 8-битовое поле LCN может содержать значения от 0 до 255.

LGN

Номер группы логических каналов (Logical Channel Group Number) совместно с номером канала LСN идентифицирует логический канал на линии между устройствами. 4-битовое поле LGN может содержать значения от 0 до 15.

Бит M

Флаг наличия дополнительных данных. Этот бит содержится в заголовке X.25 и устанавливается уровнями, расположенными над сетевым для извещения DTE-получателя о наличии дополнительных данных в следующем пакете. Использую бит M, можно логически объединять пакеты для переноса больших блоков информации.

Модуль (Modulo)

Размер окна. Указывает максимальное количество кадров (канальный уровень) или пакетов (сеетвой уровень), которые могут быть переданы без подтверждения доставки. При использовании модуля 8 (Modulo 8) порядковый номер кадра может быть представлен числом от 0 до 7, поскольку для номера выделено 3 бита. При использовании модуля 128 номер кадра может принимать значения от 0 до 127 (7 битов).

N(R)

Порядковый номер кадра, используемый в информационных и управляющих кадрах LAPB для того, чтобы показать передатчику состояние переданных информационных кадров. Значение N(R) зависит от типа кадра и может включать подтверждение приема, а также информацию о пропуске кадров и состоянии занятости. При использовании модуля 8 порядковый номер последовательности кадра представляется 3-битовым полем (0-7), для модуля 128 номер определяется 7-битовым полем (0 – 127).

N(S)

Порядковый номер информационного кадра LAPB, используемый для идентификации каждого кадра, переданного приемнику. При использовании модуля 8 порядковый номер последовательности кадра представляется 3-битовым полем (0-7), для модуля 128 номер определяется 7-битовым полем (0 – 127).

P(R)

Порядковый номер пакета данных X.25, используемый для индикации состояния переданных пакетов передатчику. Значение P(R) зависит от типа пакета и может включать подтверждение приема, а также информацию о пропуске кадров и состоянии занятости. При использовании модуля 8 порядковый номер последовательности кадра представляется 3-битовым полем (0-7), для модуля 128 номер определяется 7-битовым полем (0 – 127).

P(S)

Порядковый номер пакета данных X.25, используемый для идентификации каждого пакета, переданного приемнику. При использовании модуля 8 порядковый номер последовательности кадра представляется 3-битовым полем (0-7), для модуля 128 номер определяется 7-битовым полем (0 – 127).

Бит P/F

Бит Poll/Final (опрос/завершение) может быть установлен передатчиком в информационном кадре LAPB для получения незамедлительного отклика от получателя. Получатель такого кадра всегда устанавливает бит P/F в ответном кадре.

Бит Q

Бит, содержащийся в заголовке пакета X.25 для обозначения управляющих пакетов X.25 используемых асинхронным устройством PAD. Обычно этот флаг служит для индикации использования фирменного (proprietary) протокола.

Отклик (Response)

Кадры LAPB являются командами или откликами на них (в зависимости от значения поля адреса и направления передачи кадра). Кадры отклика от DCE содержат в поле адреса значение 1, кадры отклика от DTE – 3.

Порядковый номер (Sequence number)

Число, присваиваемое кадру или пакету, для обеспечения корректного порядка их доставки. Размер данного поля зависит от используемого модуля (максимального размера окна) и определяет максимальное количество кадров или пакетов, которое может быть передано без подтверждения их доставки.

Кадры управления (Supervisory frames)

Кадры LAPB, используемые для передачи управляющей информации, запросов на повтор передачи и подтверждений приема информационных кадров. Примерами таких кадров являются RR (подтверждение приема информационного кадра и индикация готовности к приему следующих кадров) и REJ (запрос повторной передачи всех кадров, начиная с указанного номера).

Ненумерованные кадры (Unnumbered frames)

Кадры LAPB, используемые для поддержки дополнительных функций канального уровня (инициализация и разрыв соединения, сброс линии после неисправимой ошибки, отбрасывание ошибочных кадров). Кадры называются ненумерованными, поскольку они не содержат порядковых номеров. Примерами ненумерованных кадров могут служить также кадры DISC (запрос на разрыв соединения) и UA (подтверждение приема).

X.25

Протокол X.25 представляет собой рекомендации CCITT, описывающие интерфейс между устройствами DTE и DCE через телефонную сеть общего пользования (Public Switched Telephone Network- PSTN). X.25 функционирует на уровнях 1 – 3 эталонной модели OSI, однако в данной главе термин X.25 относится только к сетевому уровню.




VB5

ETSI EN 301 005-1 V1.1.4 (1998-05)

Протокол VB5 основан на рекомендациях ITU-T G.902 и существует в двух вариантах. Первый вариант VB5.1 работает на базе кросс-коннекторов ATM с предустановленными соединениями. VB5.1 использует протокол RTMC (Real Time Management Co-ordination – координация управления в режиме реального времени).

Формат сообщений VB5.1 показан на рисунке.

8

7

6

5

4

3

2

1

Октеты

Дискриминатор протокола

1

0

0

0

0

Размер TID

2

TAID

3

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

4-5

Тип сообщения

6

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

7

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

8-9

Информационные элементы

10-n

Структура сообщения VB5.1

Дискриминатор протокола

Поле дискриминатора позволяет различать протоколы VB5 и протоколы иных типов. Значение поля для RTMC показано ниже:

8

7

6

5

4

3

2

1

0

1

0

0

1

0

0

1

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

4-байтовое поле, обозначающее транзакцию в виртуальном канале протокола VB5. Это поле включает также флаг TAID и размер TID.

Размер TID

Размер идентификатора транзакции в октетах.

Флаг TAID

Этот флаг показывает, что сообщение послано стороне, создавшей идентификатор транзакции. Отсутствие флага говорит о том, что сообщение передано стороной, создавшей идентификатор транзакции.

Тип сообщения

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

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

00000010 BLOCK_RSC.

00000011 BLOCK_RSC_ACK.

00000100 CONS_CHECK_REQ.

00000101 CONS_CHECK_REQ_ACK.

00000110 CONS_CHECK_END.

00000111 CONS_CHECK_END_ACK.

00001000 REQ_LSPID.

00001001 LSPID.

00001010 PROTOCOL_ERROR.

00001100 RESET_RSC.

00001101 RESET_RSC_ACK.

00001110 AWAIT_CLEAR.

00001111 AWAIT_CLEAR_ACK.

00010000 AWAIT_CLEAR_COMP.

00010001 AWAIT_CLEAR_ COMP_ACK.

00010010 UNBLOCK_RSC.

00010011 UNBLOCK_RSC_ACK.

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

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

Индикатор определяет поведение сетевого элемента того же ранга в тех случаях, когда не удается понять сообщение.

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

Размер содержимого сообщения в октетах.

Информационные элементы

Каждый информационный элемент содержит следующие поля:

8

7

6

5

4

3

2

1

Октеты

Тип информационного элемента

1

Индикатор совместимости информационного элемента

2

Размер информационного элемента

3-4

Содержимое IE

5-n

Тип информационного элемента

Поле указывает протокол VB5, к которому относится информационный элемент, а также функциональное назначение информационного элемента.

Индикатор совместимости информационного элемента

Индикатор определяет поведение сетевого того же ранга в тех случаях, когда не удается понять сообщение.

Размер информационного элемента

Размер содержимого информационного элемента в октетах.




Стек TCP/IP

Агентство DARPA (Defense Advance Research Projects Agency) разработало протоколы TCP/IP (Transmission Control Protocol/Internet Protocol) для объединения в сеть компьютеров различных подразделений министерства обороны США. Международная распределенная сеть Internet использует стек протоколов TCP/IP для объединения компьютерных ресурсов всей планеты. Достаточно часто эти протоколы используются также в частных и коммерческих сетях. Стек TCP/IP включает следующие протоколы:

  • IP/IPv6 – Internet Protocol.

  • TCP – Transmission Control Protocol.

  • UDP – User Datagram Protocol.

Канальный уровень

  • ARP/RARP – Address Resolution Protocol/Reverse Address.

Протоколы туннелирования

  • ATMP – Ascend Tunnel Management Protocol.
  • L2F – Layer 2 Forwarding Protocol.

  • L2TP – Layer 2 Tunneling Protocol.

  • PPTP – Point-to-Point Tunneling Protocol.

Сетевой уровень

  • DHCP/ DHCPv6 – Dynamic Host Configuration Protocol.

  • DVMRP – Distance Vector Multicast Routing Protocol.

  • ICMP/ICMPv6 – Internet Control Message Protocol.
  • IGMP – Internet Group Management Protocol.

  • MARS – Multicast Address Resolution Server.

  • PIM – Protocol Independent Mulyicast.

  • RIP – Routing Information Protocol.

  • RIP2 – Routing Information Protocol II.

  • RIPng for IPv6.

  • RSVP – Resource ReSerVation setup Protocol.

Безопасность

  • AH – Authentication Header.

  • ESP – Encapsulating Security Payload.

Маршрутизация

  • BGP-4 – Border Gateway Protocol.

  • EGP – Exterior Gateway Protocol.

  • EIGRP – Enhanced Interior Gateway Routing Protocol.

  • GRE – Generic Routing Encapsulation.

  • HSRP – Cisco Hot Standby Router Protocol.
  • IGRP – Interior Gateway Routing.

  • NARP – NBMA Address Resolution Protocol

  • NHRP – Next Hop Resolution Protocol.

  • OSPF – Open Shortest Path First.

Транспортный уровень

  • Mobile IP.
  • Van Jacobson – compressed TCP.

  • XOT – X.25 over TCP.

VoIP

  • MGCP – Media Gateway Control Protocol.

  • SGCP – Simple Gateway Control Protocol.

Сеансовый уровень

  • DNS – Domain Name Service.

  • NetBIOS/IP.

Прикладной уровень

  • FTP – File Transfer Protocol.

  • Finger User Information Protocol.

  • TFTP – Trivial File Transfer Protocol.
  • Gopher – Internet Gopher Protocol.

  • HTTP – Hypertext Transfer Protocol.

  • S-HTTP – Secure Hypertext Transfer Protocol.

  • IMAP4 – Internet Message Access Protocol rev 4.

  • IPDC – IP Device Control.

  • ISAKMP – Internet Message Access Protocol version 4rev1.

  • NTP – Network Time Protocol.

  • POP3 – Post Office Protocol version 3.

  • Radius.

  • RLOGIN – Remote Login.

  • RTSP – Real-time Streaming Protocol.

  • SMTP – Simple Mail Transfer Protocol.

  • SNMP – Simple Network Management Protocol.

  • TACACS+ – Terminal Access Controller Access Control System.
  • TELNET.

  • X-Window.

Положение протоколов стека TCP/IP в модели OSI показано на рисунке.

gif_29

Стек TCP/IP в эталонной модели OSI

IP

RFC 791 

RFC 1853 http://www.cis.ohio-state.edu/htbin/rfc/rfc1853.html

IP (Internet Protocol) представляет собой протокол уровня маршрутизируемых дейтаграмм в стеке TCP/IP. Все другие протоколы стека TCP/IP (кроме ARP и RARP) используют протокол IP для маршрутизации кадров между хостами. Заголовок кадров IP содержит маршрутную и управляющую информацию, связанную с доставкой дейтаграмм.

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

4

8

16

32

Версия

IHL

Тип сервиса

Общий размер

Идентификация

Флаги

Смещение фрагмента

Время жизни

Протокол

Контрольная сумма заголовка

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

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

Опции и заполнение

Данные

Структура заголовка IP.

Версия

Поле версии определяет формат заголовка Internet.

IHL

Internet Header Length – размер заголовка Internet указывает размер заголовка в 32-битовых словах, задавая смещение данных от начала пакета. Минимальный размер заголовка составляет 5 слов (160 битов).

Тип сервиса

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

Биты 0 – 2 – преимущественная доставка

111 сетевое управление

110 межсетевое управление

101 CRITIC/ECP

100 Flash override

011 Flash

010 немедленная доставка

001 приоритетная доставка

000 Routine (нормальный режим)

Бит 3 – задержка

0 Нормальная

1 Малая

Бит 4 – пропускная способность

0 Нормальная

1 Высокая

Бит 5 – надежность доставки

0 Нормальная

1 Высокая

Биты 6 – 7 – зарезервированы для использования в будущем

Общий размер

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

Идентификация

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

Флаги

Трехбитовое поле флагов управления:

Бит 0 – зарезервирован и должен иметь нулевое значение

Бит 1 – возможность фрагментирования

0 Можно фрагментировать

1 Не фрагментировать

Бит 2 – наличие дополнительных фрагментов

0 Последний фрагмент

1 Есть последующие фрагменты

Смещение фрагмента

13-битовое значение, задающее смещение фрагмента от начала целой дейтаграммы. Смещение фрагмента измеряется в 8-байтовых (64 бита) словах. Первый фрагмент имеет нулевое смещение.

Время жизни

Показывает максимальное время существования дейтаграммы в сети Internet. При нулевом значении этого поля дейтаграмма должна быть уничтожена. Время жизни дейтаграмм измеряется в секундах. Однако, поскольку каждый модуль, работающий с дейтаграммой, должен уменьшать значение поля TTL (time-to-life) по крайней мере на 1 (даже в тех случаях, когда обработка дейтаграммы занимает меньше секунды), значение этого поля должно быть не меньше желаемого времени жизни дейтаграммы. Дейтаграммы с истекшим в процессе доставки временем жизни не попадают к получателю.

Протокол

Указывает протокол следующего уровня, содержащийся в поле данных дейтаграммы IP.

Контрольная сумма заголовка

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

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

32-битовые значения адресов отправителя и получателя дейтаграммы. Следует четко различать имена, адреса и маршруты. Имя показывает название объекта, адрес говорит о его местоположении в сети, а маршрут – показывает путь к объекту. Протокол IP имеет дело преимущественно с адресами. Связь между адресами и именами реализуется протоколами вышележащих уровней. Модуль Internet отображает адреса IP на локальные сетевые адреса. Связь локальных сетевых адресов с маршрутами обеспечивается протоколами нижележащих уровней.

Опции

Это поле содержит необязательные опции дейтаграммы. Используемые опции должны быть реализованы во всех модулях IP (хосты и шлюзы). В некоторых опции безопасности являются обязательными для всех дейтаграмм.

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

  • Однооктетные опции
  • Многооктетные опции, содержащие поля типа опции (1 октет), ее размера (1 октет) и собственно опций.

Поле длины опции учитывает все субполя опции – тип, размер и сами опции.

Октет типа опции имеет три поля:

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

0 опция копируется

1 опция не копируется.

2 бита – класс опции:

0 управление

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

2 отладка и измерение

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

5 битов – номер опции

Данные

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

IPv6

RFC 1883, RFC 2460

RFC 1826

RFC 1827

IPv6 представляет собой обновленную версию протокола Internet, разработанную на основе IPv4. Оба протокола (IPv6 и IPv4) различаются на уровне среды. Например, пакеты IPv6 передаются через сеть Ethernet с использованием идентификатора типа 86DD вместо 0800 для IPv4.

IPv6 расширяет адресное пространство IP за счет использования 128-битовых адресов вместо принятых в IPv4 32-битовых. Такое расширение позволяет также увеличить число уровней сетевой иерархии, упростить процессы автоматической настройки адресов и во много раз увеличить число хостов в сети. В дополнение к этому вводится масштабируемость групповых (multicast) адресов и определяется новый тип адреса anycast (кому-нибудь) для передачи пакетов любому узлу из группы.

Расширенная поддержка опций – опции IPv6 помещаются в отдельный заголовок, располагающийся между заголовком IPv6 и заголовком транспортного уровня. Изменения в способе представления опций заголовка IP делают рассылку пакетов более эффективной, снижают уровень ограничений на размер опций, а также обеспечивают дополнительную гибкость при введении новых опций в будущем. В число расширений заголовка опций входят: Hop-by-Hop, Routing (Type 1), Fragment, Destination Option, Authentication, Encapsulation Payload.

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

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

4

8

16

32

Версия

Приор.

Метка потока

Размер содержимого

След. заголовок

Число интерв.

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

(128 байтов)

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

(128 байтов)

Структура заголовка IPv6.

Версия

Номер версии протокола Internet (6).

Приоритет

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

Метка потока

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

Размер содержимого

Размер поля содержимого пакета (в октетах).

Следующий заголовок

Указывает тип заголовка, следующего непосредственно после заголовка IPv6.

Число интервалов

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

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

128-битовый адрес отправителя пакета.

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

128-битовый адрес получателя пакета.

TCP

RFC 793
RFC 1072

RFC 1693
RFC 1146
RFC 1323

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

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

4

10

16

32

Порт отправителя

Порт получателя

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

Номер подтверждения

Смещ.

Резерв

U

A

P

R

S

F

Окно

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

Указатель важности

Опции и заполнение

Данные

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

Порт отправителя

Номер порта-отправителя.

Порт получателя

Номер порта-получателя.

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

Порядковый номер первого октета в данном сегменте (за исключением присутствия SYN). При наличии SYN поле порядкового номера содержит изначальный порядковый номер (Initial Sequence Number – ISN) и первый октет имеет номер ISN+1.

Номер подтверждения

Если бит управления ACK установлен (1), это поле содержит значение следующего порядкового номера, который отправитель сегмента ожидает получить. После организации соединения значение этого поля устанавливается во всех случаях.

Смещение данных

4-битовое поле, указывающее число 32-битовых слов в заголовке TCP. После заголовка размещаются данные, поэтому поле указывает на начало данных в пакете. Заголовок пакетов TCP всегда имеет размер, кратный 32 битам.

Резерв

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

Биты управления

6 битовое поле, содержащее флаги управления:

U (URG) – значимое поле указателя важности;

A (ACK) – значимое поле подтверждения;

P (PSH) – функция push;

R (RST) – сброс соединения;

S (SYN) – синхронизация порядковых номеров;

F (FIN) – нет данных от отправителя.

Окно

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

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

16-битовое значение контрольной суммы, вычисляемой для 16-битовых слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке /или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчета контрольной суммы. При расчете контрольной суммы значение самого поля контрольной суммы принимается равным 0.

Указатель важности

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

Опции

Опции передаются в конце заголовка TCP и всегда имеют размер, кратный 8 битам. При расчете контрольной суммы пакета значения опций принимаются во внимание. Опции могут начинаться на любой границе октета.

Существуют два формата опций:

  • Однооктетные опции
  • Многооктетные опции, содержащие поля типа опции (1 октет), ее размера (1 октет) и собственно опций.

Поле длины опций учитывает все субполя опций – тип, размер и сами опции.

Список опций может закончиться раньше, нежели указывает поле смещения данный, поэтому значения битов после поля End-of-Option должны быть заполнены нулями.

Протокол TCP Должен реализовать все опции.

Данные

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

TCP_ATM

Пример декодирования TCP over ATM

UDP

RFC768 http://www.cis.ohio-state.edu/htbin/rfc/rfc768.html

Протокол UDP (User Datagram Protocol – протокол пользовательских дейтаграмм) обеспечивает простой сервис передачи сообщений без гарантии доставки для ориентированных на транзакции услуг. Каждый заголовок UDP содержит идентификаторы портов отправителя и получателя, которые позволяют протоколам вышележащих уровней связать указанные приложения и услуги с хостами.

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

16

32

Порт-отправитель

Порт-получатель

Размер

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

Данные

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

Порт-отправитель

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

Порт-получатель

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

Размер

Размер данной пользовательской дейтаграммы в октетах с учетом заголовка и данных. Минимальная длина дейтаграммы составляет 8 октетов.

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

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

Данные

Поле данных UDP.

ARP/RARP

RFC826

RFC1293

RFC1390

TCP/IP использует протоколы ARP (Address Resolution Protocol – протокол преобразования адресов) и RARP (Reverse Address Resolution Protocol – протокол обратного преобразования адресов) для инициализации использования адресов Internet в сетях Ethernet и сетях иных типов, использующих метод MAC (media access control) для управления доступом к среде передачи. Протокол ARP позволяет хостам обмениваться информацией с другими хостами в тех случаях, когда известен только IP-адрес ближайшего соседа. Перед тем, как использовать IP хост передает широковещательный запрос ARP, содержащий IP-адрес желаемой системы-получателя.

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

16

32

Тип оборудования

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

HLen (8)

PLen (8)

Операция

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

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

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

Протокольный адрес получателя

Структура заголовков ARP/RARP

Тип оборудования

Указывает тип интерфейса, для которого отправителю нужен отклик.

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

Задает тип адреса вышележащего протокола, который представляет отправитель.

HLen

Размер аппаратного адреса.

PLen

Размер протокольного адреса.

Операция

Поддерживаются следующие типы операций:

1 запрос ARP.

2 отклик ARP.

3 запрос RARP.

4 отклик RARP.

5 запрос Dynamic RARP.

6 отклик Dynamic RARP.

7 ошибка Dynamic RARP.

8 запрос InARP.

9 отклик InARP.

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

Аппаратный адрес отправителя размером HLen.

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

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

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

Аппаратный адрес получателя размером HLen.

Протокольный адрес получателя

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

ATMP

RFC 2107

ATMP (Ascend Tunnel Management Protocol – протокол управления туннелями компании Ascend) представляет собой протокол, используемый в настоящее время компанией Ascend Communications для организации виртуального присутствия программ доступа по коммутируемым линиям в удаленной сети. Пользователь соединяется по телефонной линии с сервером удаленного доступа в сеть (NAS), но вместо использования адреса, непосредственно входящего в сеть, где установлен сервер NAS, клиентские программы используют адрес, относящийся к “домашней сети” пользователя. Этот адрес может предоставлять клиентская программа или он выделяется из пула адресов “домашних сетей”. В любом случае этот адрес связывается с “домашней сетью” и для маршрутизации пакетов от клиента и к нему требуется использовать специальные соглашения. Для обмена данными используется туннель между сервером NAS и специальным “домашним агентом” (Home Agent – HA) в “домашней сети.

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

Версия

Тип сообщения

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

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

Версия

Текущий номер версии протокола ATMP (1).

Тип сообщения

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

Тип сообщения Код

Registration Request 1

Challenge Request 2

Challenge Reply 3

Registration Reply 4

Deregister Request 5

Deregister Reply 6

Error Notification 7

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

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

L2F

RFC 2341 http://www.cis.ohio-state.edu/htbin/rfc/rfc2341.html

Протокол рассылки канального уровня L2F (layer 2 Forwarding Protocol) позволяет организовать туннелирование канального уровня протоколами вышележащих уровней. Использование таких туннелей позволяет избавиться от связи местоположения изначального сервера dial-up с местом завершения коммутируемого соединения и обеспечения доступа в сеть.

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

13

16

24

32

F K P S 0 0 0 0 0 0 0 0 C

Версия

Протокол

Номер

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

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

Размер

Смещение содержимого

Ключ пакета

Содержимое

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

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

Версия

Старшая часть номера версии программы L2F, создавшей пакет.

Протокол

Указывает протокол, передаваемый в пакетах L2F.

Номер

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

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

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

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

Идентификатор клиента (CLID) помогает демультиплексировать туннели в конечных точках.

Размер

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

Смещение содержимого

Указывает смещение начала содержимого пакета от конца заголовка L2F (в байтах). Это поле присутствует в пакетах с установленным флагом F.

Ключ пакета

Поле ключа используется в пакетах с установленным флагом K и используется в процессе аутентификации.

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

Контрольная сумма пакета, используемая при установке флага C.

Опции

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

Список поддерживаемых опций приведен ниже:

0x00 Invalid некорректное сообщение

0x01 L2F_CONF конфигурация запроса

0x02 L2F_CONF_NAME имя партнера (peer), передающего L2F_CONF

0x03 L2F_CONF_CHAL случайный номер связанный с peer

0x04 L2F_CONF_CLID Assigned_CLID для используемого peer

0x02 L2F_OPEN конфигурация восприятия (Accept)

0x01 L2F_OPEN_NAME имя, принятое от клиента

0x02 L2F_OPEN_CHAL запрос клиента получен

0x03 L2F_OPEN_RESP отклик от клиента

0x04 L2F_ACK_LCP1 от клиента принято сообщение LCP CONFACK

0x05 L2F_ACK_LCP2 клиенту передано сообщение LCP CONFACK

0x06 L2F_OPEN_TYPE тип используемой аутентификации

0x07 L2F_OPEN_ID идентификатор, связанный с аутентификацией

0x08 L2F_REQ_LCP0 первое сообщение LCP CONFREQ от клиента

0x03 L2F_CLOSE запрос разрыва соединения

0x01 L2F_CLOSE_WHY код причины разрыва соединение

0x02 L2F_CLOSE_STR описание причины в виде строки ASCII

0x04 L2F_ECHO проверка присутствия партнера

0x05 L2F_ECHO_RESP отклик на L2F_ECHO

L2TP

RFC 2661 http://www.cis.ohio-state.edu/htbin/rfc/rfc2661.html

Протокол L2TP используется для интеграции мультипротокольного сервиса по коммутируемым линиям в существующие точки доступа (Point of Presence – POP) сервис-провайдеров Internet. Этот протокол можно использовать и для решения проблемы расщепления групп “multilink hunt-group”. Протокол Multilink PPP, часто используемый для объединения каналов ISDN BRI, требует, чтобы все каналы мультиканального потока попадали на один сервер доступа NAS. Поскольку протокол L2TP ведет к появлению сеанса PPP в месте, отличающемся от физической точки завершения канала, этот протокол можно использовать для представления всех каналов на одном сервере NAS, даже в тех случаях, когда физические каналы организуются через различные NAS-серверы.

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

8

16

32

T

L

I

C

F

K

O

0

0

Версия

Размер

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

Идентификатор вызова

Ns

Nr

AVP

(8 байтов)

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

T

Флаг T имеет значение для управляющих сообщений и 0 – для информационных (payload). В управляющих сообщениях следующие за этим флагом 7 битов имеют значения 1001000, используемые для обеспечения совместимости по кодированию с информационными сообщениями.

L

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

I и C

Поля I и C зарезервированы и должны иметь нулевые значения. Поля использовались для опций, более не поддерживаемых протоколом L2TP.

F

Флаг F устанавливается для пакетов, в которых присутствуют поля Ns и Nr. Данный флаг должен устанавливаться для управляющих сообщений.

K

Поле K зарезервировано и должно иметь нулевое значение.

O

Этот флаг говорит о присутствии поля Размер смещения (Offset Size) в информационных сообщениях.

Версия

Это трехбитовое поле указывает номер версии протокола L2TP и для версии 1 должно иметь значение 2.

Размер

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

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

Указывает туннель, к которому относится управляющее сообщение. Если от партнера еще не получено сообщение Assigned Tunnel ID (присвоенный идентификатор туннеля), это поле должно иметь нулевое значение. После получения от партнера идентификатора туннеля во все пакеты должно помещаться это значение.

Идентификатор вызова

Указывает на пользовательскую сессию в туннеле, к которой имеет отношение данное управляющее сообщение. Если сообщение не связано с отдельной сессией в туннеле (например, сообщение Stop-Control-Connection-Notification), это поле должно иметь нулевое значение.

Ns

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

Nr

Последний принятый пакет.

Информационные сообщения L2TP используют два дополнительных поля перед полем AVP. Эти поля показаны на рисунке.

Размер смещения (16 битов)

Заполнение (16 битов)

Дополнительные поля информационных сообщений L2TP

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

Это поле указывает число байтов от конца заголовка L2TP до начала информационной части сообщения (payload). Если размер смещения равен 0 или флаг O не установлен, информационная часть сообщения начинается сразу после заголовка L2TP.

AVP

Пары AVP (Attribute-Value Pair – атрибут-значение) используются для кодирования типа сообщений L2TP. Формат поля AVP показан на рисунке.

16

32

M

H

0

0

0

0

Общая длина

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

Атрибут

Значение

Структура поля AVP

M

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

H

Этот флаг служит для управления спрятанными (hidden) данными в поле значения AVP. Сокрытие данных можно использовать для передачи конфиденциальной информации (например, паролей) в AVP.

Общая длина

Число октетов (с учетом самого поля длины), содержащихся в AVP. Поле длины занимает 10 битов, позволяя передавать AVP размером до 1024 октетов.

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

Выделенные IANA идентификаторы SMI Network Management Private Enterprise Code.

Атрибут

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

Значение

Поле значения размещается сразу же после атрибута и занимает оставшиеся октеты пакета (общий размер пакета за вычетом шести октетов заголовка).

 L2TP

Пример декодирования L2TP

PPTP

RFC2637 http://www.cis.ohio-state.edu/htbin/rfc/rfc2637.html

Протокол PPTP (Point to Point Tunneling Protocol) позволяет передавать пакеты PPP через сети IP. Протокол использует архитектуру клиент-сервер для разделения функций, существующих в современных серверах сетевого доступа NAS и поддержки виртуальных частных сетей VPN (Virtual Private Network). PPTP включает спецификации протоколов контроля вызовов и управления, позволяющих серверу контролировать доступ по коммутируемым каналам телефонных сетей ТсОП и ISDN или организовывать исходящие коммутируемые соединения. Протокол PPTP использует GRE-подобный (Generic Routing Encapsulation) механизм для управления сервисом инкапсуляции дейтаграмм по потокам и насыщению при передаче пакетов PPP.

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

16

32

Размер

Тип сообщения PPTP

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

Тип сообщений контроля

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

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

Размер

Общая длина сообщения PPTP (с учетом заголовка) в октетах.

Тип сообщения PPTP

Один из двух идентификаторов типа сообщения:

1 контроль

2 управление

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

Это поле всегда содержит значение 0x1A2B3C4D, служащее для того, чтобы приемник мог корректно синхронизироваться с потоком данных TCP.

Тип сообщений контроля

1 Start-Control-Connection-Request

2 Start-Control-Connection-Reply

3 Stop-Control-Connection-Request

4 Stop-Control-Connection-Reply

5 Echo-Request

  1. Echo-Reply

Управление вызовами

7 Outgoing-Call-Request

8 Outgoing-Call-Reply

9 Incoming-Call-Request

10 Incoming-Call-Reply

  1. Incoming-Call-Connected

  2. Call-Clear-Request

  3. Call-Disconnect-Notify

Отчеты об ошибках

14 WAN-Error-Notify

Управление сеансами PPP

15 Set-Link-Info

DHCP

RFC1531 http://www.cis.ohio-state.edu/htbin/rfc/rfc1531.html

Протокол DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки хостов) обеспечивает конфигурационные параметры для хостов Internet. DHCP представляет собой расширение протокла BOOTP и состоит из двух компонент – протокол доставки параметров хоста от сервера DHCP и механизм предоставления сетевых адресов хостам.

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

8

16

24

32

Op

Htype

Hlen

Hops

XID

Secs

Флаги

Ciaddr (4 байта)

Yiaddr (4 байта)

Siaddr (4 байта)

Giaddr (4 байта)

Chaddr (16 байтов)

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

Op

Код операции, связанной с сообщением – BOOTREQUEST (запрос) или BOOTREPLY (отклик).

Htype

Тип аппаратного адреса.

Hlen

Размер аппаратного адреса.

Hops

Клиент устанавливает для этого поля нулевое значение. Поле может использоваться relay-агентами при загрузке с использованием таких агентов.

XID

Идентификатор транзакции.

Secs

Число секунд, прошедших с того момента, как клиент инициировал процесс получения адреса или процесс обновления.

Флаги

2 байта флагов DHCP.

Ciaddr

IP-адрес клиента.

Yiaddr

Ваш (клиента) IP-адрес.

Siaddr

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

Giaddr

IP-адрес, используемый для загрузки с помощью relay-агента.

Chaddr

Аппаратный адрес клиента.

DHCPv6

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-14.txt

Протокол динамической настройки хостов версии 6 (DHCPv6) позволяет серверам DHCP передавать информацию узлам IPv6 с использованием расширений. Протокол обеспечивает возможность автоматического распределения сетевых адресов и предоставляет дополнительную гибкость настройки по сравнению со своими предшественниками. Протокол DHCPv6 является важной частью протокола SAA (Stateless Address Autoconfiguration) и может использоваться совместно с ним или отдельно для получения конфигурационной информации.

DHCPv6 поддерживает 6 различных типов сообщений – Solicit, Advertise, Request, Reply, Release и Reconfigure.

Сообщения DHCP Solicit

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

Формат сообщений DHCP Solicit показан на рисунке.

8

16

24

25

32

Тип сообщения

C

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

Разм. префикса

Локальный адрес клиентского канала (16 октетов)

Адрес ретранслятора (16 октетов)

Сохраненный адрес агента (16 октетов)

Формат сообщений DHCP Solicit

Тип сообщения

Значение 1 в этом поле говорит о сообщении DHCP Solicit.

C

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

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

Зарезервированное поле, которое должно иметь нулевое значение.

Размер префикса

Отличное от нуля значение префикса указывает число битов в левой части адреса IPv6 агента, которые служат префиксом маршрутизации. Поле размера префикса устанавливается ретранслятором DHCP (DHCP relay) при получении запроса и его пересылке одному или нескольким серверам DHCP.

Локальный адрес клиентского канала

Локальный адрес канала IP клиентского интерфейса, с которого клиент передал запрос DHCP Request.

Адрес ретранслятора

Клиент устанавливает для этого поля нулевое значение. При получении пакета ретранслятор (relay) DHCP устанавливает в этом поле значение IP-адреса интерфейса, через который получен клиентский запрос DHCP Solicit.

Сохраненный адрес агента

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

Сообщения DHCP Advertise

Агент DHCP посылает сообщения DHCP Advertise для того, чтобы информировать потенциальных клиентов об IP-адресе сервера, которому можно посылать запросы DHCP Request. Когда клиент и сервер находятся на различных каналах (link), сервер посылает анонсы обратно через ретранслятор, который переслал запрос. Значения всех полей сообщения DHCP Advertise заполняются сервером DHCP и не изменяются при ретрансляции.

8

16

24

25

32

Тип сообщения

S

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

Предпочтение

Локальный адрес клиентского канала (16 октетов)

Адрес агента (16 октетов)

Адрес сервера (16 октетов)

Расширения

Формат сообщений DHCP Advertise

Тип сообщения

Значение 2 в этом поле говорит о сообщении DHCP Advertise.

S

Этот флаг говорит о присутствии адреса сервера.

Предпочтение

Показывает готовность сервера к обслуживанию клиентов.

Локальный адрес клиентского канала

Локальный адрес канала IP клиентского интерфейса, с которого клиент передал запрос DHCP Request.

Адрес агента

IP-адрес агентского интерфейса DHCP, находящегося на одном канале с клиентом.

Адрес сервера

Это поле, будучи установленным, показывает IP-адрес сервера DHCP.

Расширения

Это поле находится в стадии разработки. См. C. Perkins. Extensions for the Dynamic Host Configuration Protocol for IPv6 http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6ext-11.txt.

Сообщения DHCP Request

Для получения конфигурационных параметров от сервера клиент посылает сообщение DHCP Request, к которому могут быть добавлены произвольные расширения. Если клиенту неизвестен адрес хотя бы одного сервера, он должен сначала выяснить такой адрес, передав для этого запрос DHCP Solicit с групповым адресом. Обычно при перезагрузке клиента последний не имеет корректного адреса IP, требуемого для взаимодействия между сервером и клиентом. В таких случаях клиент не может передать сообщение напрямую серверу, поскольку сервер не может вернуть клиенту ответ, не зная адреса клиента. В таких случаях клиент должен послать запрос локальному ретранслятору, указав адрес ретранслятора в заголовке сообщения как адрес агента.

8

16

24

25

32

Тип сообщения

C

S

R

Рез.

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

Локальный адрес клиентского канала (16 октетов)

Адрес агента (16 октетов)

Адрес сервера (16 октетов)

Расширения

Формат сообщений DHCP Request

Тип сообщения

Значение 3 в этом поле говорит о сообщении DHCP Request.

R

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

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

Беззнаковое целое число, служащее для обозначения запроса.

Остальные поля были описаны выше при рассмотрении сообщений DHCP Solicit и DHCP Advertise.

Сообщения DHCP Reply

Сервер посылает сообщения DHCP Reply в ответ на каждый запрос DHCP Request и DHCP Release. Если запрос получен с флагом S, это говорит о том, что клиент не может передавать запросы серверу напрямую и использует расположенный по соседству ретранслятор. В таких случаях сервер передает сообщения DHCP Reply с установленным битом L, адресуя их агенту, указанному в запросе. Все поля сообщений DHCP Reply устанавливает сервер DHCP.

8

16

24

25

32

Тип сообщения

L

Состояние

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

Локальный адрес клиентского канала (16 октетов)

Расширения

Формат сообщений DHCP Reply

Тип сообщения

Значение 4 в этом поле говорит о сообщении DHCP Reply.

L

Установка этого флага говорит о присутствии в сообщении локального адреса клиентского канала.

Состояние

0 Успешное выполнение запроса

16 Отказ, причина не указана

17 Отказ при аутентификации

18 Некорректно сформированный запрос Request или Release

19 Ресурсы недоступны

20 Клиентская запись недоступна

21 Некорректный IP-адрес клиента в запросе Release

23 Ретранслятор не может найти адрес сервера

  1. Сервер недоступен (ошибка ICMP)
Идентификатор транзакции

Беззнаковое целое число, служащее для обозначения отклика. Значение этого поля копируется из одноименного поля пакета Request.

Локальный адрес клиентского канала

Если это поле используется, оно содержит локальный адрес канала IP клиентского интерфейса, с которого клиент передал запрос DHCP Request. При установленном флаге L локальный адрес клиентского канала присутствует в пакете Reply. Тогда сообщение Reply посылается сервером по адресу ретранслятора, который использует локальный адрес клиентского канала для доставки сообщения клиенту. Поле идентификатора транзакции сообщений DHCP Reply копируется сервером из клиентского запроса DHCP Request.

Сообщения DHCP Release

Сообщения DHCP Release передаются без использования ретрансляторов DHCP. Когда клиент посылает сообщение Release, предполагается, что этот клиент имеет корректный IP-адрес, позволяющий передать сообщение серверу. Если в поле расширения указаны параметры, освобождаются только эти параметры. Значения всех полей сообщений DHCP Release задаются клиентом. Сервер DHCP подтверждает сообщения DHCP Release путем передачи DHCP Reply.

8

16

24

25

32

Тип сообщения

D

Зарезервир.

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

Локальный адрес клиентского канала (16 октетов)

Адрес агента (16 октетов)

Адрес клиента (16 октетов)

Расширения

Формат сообщений DHCP Release

Тип сообщения

Значение 5 в этом поле говорит о сообщении DHCP Release.

D

Установка этого флага говорит серверу о том, что отклик DHCP Reply следует передавать непосредственно клиенту вместо использования адресов агента и локального адреса канала для ретрансляции сообщения Reply.

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

Беззнаковое целое число, служащее для обозначения запроса DHCP Release. Значение этого поля копируется в одноименное поле пакета Reply.

Остальные поля сообщений описаны выше.

Сообщения DHCP Reconfigure

Сообщения DHCP Reconfigure могут посылаться только клиентам, имеющим IP-адрес, который маршрутизируется в канал, обеспечивающий доступ к клиенту. Следовательно, сообщения DHCP Reconfigure передаются без использования ретрансляторов DHCP. Когда сервер посылает сообщение DHCP Reconfigure, он предполагает, что получатель имеет корректный адрес IP в доступной для сервера области. В ответ на сообщение DHCP Reconfigure клиент должен снова запросить те (и только те) параметры, которые указаны в поле расширения. Сервер может передавать сообщения DHCP Reconfigure, используя индивидуальные или групповые адреса получателей. Получив сообщение, клиент должен разобрать поле расширения и послать серверу запрос для получения значений указанных в расширении параметров.

8

16

24

25

32

Тип сообщения

N

Зарезервир.

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

Адрес сервера (16 октетов)

Расширения

Формат сообщений DHCP Reconfigure

Тип сообщения

Значение 6 в этом поле говорит о сообщении DHCP Reconfigure.

N

Установка этого флага говорит о том, что клиент не должен ожидать сообщения DHCP Reply в ответ на запрос DHCP Request, переданный в результате получения пакета DHCP Reconfigure.

Остальные поля сообщений описаны выше.

DVMRP

RFC 1075 http://www.cis.ohio-state.edu/htbin/rfc/rfc1075.html

IETF draft: http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-08.txt

Протокол DVMRP (Distance Vector Multicast Routing Protocol) представляет собой протокол маршрутизации Internet, обеспечивающий эффективный механизм доставки дейтаграмм группам хостов в интерсети без организации соединений (connectionless). Это распределенный протокол, который динамически генерирует деревья групповой доставки пакетов IP на основе метода RPM (Reverse Path Multicasting).

Протокол DVMRP поддерживает многие функции RIP c алгоритмом TRBP (Truncated Reverse Path Broadcasting). DVMRP разработан на основе протокола RIP, поскольку эта реализация была доступна и алгоритм дистантных векторов достаточно прост, по сравнению с алгоритмами на основе состояния каналов. В дополнение к этому был разработан механизм туннелирования для проведения экспериментов по передаче пакетов через сети, не поддерживающие групповой адресации.

Между протоколами RIP и DVMRP есть важное различие – RIP маршрутизирует и рассылает дейтаграммы конкретным адресатам, а DVMRP может работать с групповыми адресами. Одной из задач протокола является сохранение информации о пути возврата к отправителю дейтаграмм с групповой адресацией. Чтобы сделать описание протокола DVMRP более близким к описанию RIP используется термин получатель (destination) взамен более корректного термина отправитель (source), однако дейтаграммы не рассылаются получателям, а происходят от них.

Пакеты DVMRP инкапсулируются в дейтаграммы IP с полем протокола, имеющим значение 2 (IGMP). Пакеты DVMRP используют общий заголовок протокола, который указывает тип пакетов IGMP как DVMRP. При передаче пакетов DVMRP флаги преимущественной доставки (Precedence) в поле типа сервиса должны указывать на межсетевое управлений (Internetwork Control – 0xC0). Общий заголовок протокола показан на рисунке.

8

16

24

32

Тип

Код

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

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

Версия (мл.)

Версия (ст.)

Структура DVMRP

Тип

Тип пакета. Значение 0x13 говорит о пакете DVMRP.

Код

Определяет тип пакета DVMRP. В настоящее время поддерживаются коды для протокола DVMRP, а также для протоколов анализа и поиска неисправностей.

Probe поиск соседа

Report обмен маршрутами

Prune уничтожение деревьев групповой доставки

Graft создание деревьев групповой доставки

Graft ack подтверждение сообщение о создании деревьев.

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

Контрольная сумма пакета DVMRP, рассчитываемая до передачи пакета и проверяемая при его получении. При расчете контрольной суммы это поле принимается равным нулю.

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

Зарезервировано для использования в будущем.

Младшие цифры версии

Младшие цифры номера версии протокола DVMRP – для текущей версии – 0xFF.

Старшие цифры версии

Старшие цифры номера версии протокола DVMRP – для текущей версии – 3.

ICMP

RFC792 http://www.cis.ohio-state.edu/htbin/rfc/rfc792.html

RFC1970 http://www.cis.ohio-state.edu/htbin/rfc/rfc1970.html

Протокол ICMP (Internet Control Message Protocol – протокол управляющих сообщений Internet) в общем случае используется для передачи сведений о трудностях маршрутизации дейтаграмм IP или простого обмена временными метками и эхо-транзакциями (ping).

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

8

16

32

Тип

Код

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

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

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

Адресная маска

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

Тип и код
Тип Код Описание
0 эхо-отклик
0 нет кода
1 не используется
2 не используется
3 адресат недоступен
3 0 нет доступа
3 1 хост недоступен
2 протокол недоступен
3 порт недоступен
4 требуется фрагментация, но установлен флаг DF (не фрагментировать)
5 отказ при маршрутизации Source route
6 неизвестна сеть адресата
7 неизвестен хост-адресат
8 хост-отправитель изолирован
9 связь с сетью адресата запрещена административными мерами
10 связь с хостом-адресатом запрещена административными мерами

11

сеть адресата недоступна для заданного типа обслуживания (TOS)

12

хост-адресат недоступен для заданного типа обслуживания (TOS)

4

Source quench

4

0

нет кода
5 перенаправление
5 0 перенаправление дейтаграмм для сети или подсети
5 1 перенаправление дейтаграмм для хоста
5 2 перенаправление дейтаграмм для указанного типа сервиса (TOS) и сети
5 3 перенаправление дейтаграмм для указанного типа сервиса (TOS) и хоста
6 альтернативный адрес хоста
6 0 альтернативный адрес для хоста
7 не используется
8 эхо
8 0 нет кода
9 анонсирование маршрутизатора (RFC-1256)
9 0 нет кода
10 выбор маршрутизатора (RFC-1256)
10 0 нет кода
11 время истекло
11 0 время жизни (TTL) истекло во время передачи
11 1 истекло время сборки фрагментов

12

проблемы с параметрами
12 0 указатель говорит об ошибке
12 1 отсутствует требуемая опция
12 2 некорректная длина
13 временная метка
13 0 нет кода
14 ответ на временную метку
14 0 нет кода
15 запрос информации
15 0 нет кода
16 отклик на запрос информации
16 0 нет кода
17 запрос маски адреса (RFC-950)
17 0 нет кода
18 отклик на запрос маски (RFC-950)
18 0 нет кода
19 зарезервирован (обеспечение безопасности)
20-29 зарезервированы (для экспериментов на устойчивость к ошибкам)
30 трассировка маршрута (traceroute) – RFC-1393
31 ошибка преобразования дейтаграммы (RFC-1475)
32 перенаправление для мобильного хоста
33 IPv6 Where-Are-You (где вы находитесь)

34

IPv6 I-Am-Here (я здесь)
35 запрос перенаправления для мобильного хоста
36 отклик на запрос перенаправления для мобильного хоста
Контрольная сумма

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

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

Идентификатор используется для обозначения соответствия запросов и откликов. Это поле должно иметь нулевое значение.

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

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

Адресная маска

32-битовая маска.

ICMPv6

RFC1885 http://www.cis.ohiostate.edu/htbin/rfc/rfc1885.html

RFC1970 http://www.cis.ohio-state.edu/htbin/rfc/rfc1970.html

При подготовке протокола IPv6 был пересмотрен протокол управляющих сообщений ICMP и в новый вариант протокола ICMPv6 были добавлены функции управления групповой рассылкой IGMP (IPv4 Group Membership

Protocol).

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

8

16

32

Тип

Код

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

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

Тип

Сообщения ICMPv6 могут быть различных типов – сообщения об ошибках и информационные сообщения. К числу сообщений об ошибках относятся сообщения о недостижимости адресата (Destination unreachable), слишком больших пакетах (Packet too big), истечении времени (Time exceed) и проблемах с параметрами (Parameter problem). В число информационных сообщений входят Echo Request (эхо-запрос), Echo Reply (эхо-отклик), Group Membership Query (запрос на включение в группу), Group Membership Report (отчет о включении в группу), Group Membership Reduction (исключение из группы).

Код

Для каждого типа сообщений определено несколько значений кодов. Примером может служить сообщение Destination Unreachable, для которого определены коды отсутствия маршрута к адресату, административного запрета связи с адресатом, not a neighbor (не является соседом), недостижимости адреса и порта.

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

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

Это поле служит для обнаружения ошибок при передаче пакетов ICMPv6.

IGMP

RFC1112 http://www.cis.ohio-state.edu/htbin/rfc/rfc1112.html

Протокол IGMP (Internet Group Management Protocol – протокол управления группами Internet) используется хостами IP для передачи информации об их принадлежности к группам любым маршрутизаторам из числа ближайших соседей.

Протокол IGMP интегрирован в стек IP и должен быть реализован на всех хостах, соответствующих спецификации групповой адресации IP для канального уровня. Сообщения IGMP инкапсулируются в дейтаграммы IP с полем протокола, имеющим значение 2. (в соответствии с IETF RFC1112, август 1989).

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

4

8

16

32

Версия

Тип

Не используется

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

Адрес группы

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

Версия

Номер версии протокола.

Тип

Тип сообщения:

1 Host Membership Query (запрос включения в группу).

2 Host Membership Report (сообщение о принадлежности к группе).

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

Контрольная сумма пакета.

Адрес группы

В сообщениях Host Membership Report это поле содержит IP для группы.

MARS

RFC2022 http://www.cis.ohio-state.edu/htbin/rfc/rfc2022.html

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

ATM используется как новая технология канального уровня для поддержки множества протоколов, включая IP. Протокол MARS имеет два основных назначения – регистрация принадлежности к группам и распространение этой информации. Такие возможности позволяют сетям на базе UNI 3.0/3.1 поддерживать групповой сервис для протоколов типа IP и определять специфическое поведение оконечных точек для поддержки виртуальных каналов “один со многими”, используемых при групповой рассылке пакетов сетевого уровня. Сервер MARS (Multicast Address Resolution Server) является, по сути, расширением сервера ATM ARP (сервер преобразования адресов). Этот сервер регистрирует идентификаторы multicast-групп сетевого уровня, связывая их с интерфейсами ATM, представляющими членов группы. Сообщения MARS используются для распространения информации о принадлежности к группам между сервером MARS и оконечными точками (хосты и маршрутизаторы). Объекты системы преобразования адресов оконечных точек запрашивают сервис MARS при возникновении необходимости преобразования адресов сетевого уровня в адреса оконечных точек ATM, входящих в группу. Оконечные точки обеспечивают MARS актуальной информацией, когда им требуется вступление в группу сетевого уровня или выход из такой группы. Для обеспечения своевременной информации об изменениях в группах сервер MARS поддерживает виртуальные каналы со всеми оконечными точками, требующими поддержки групповой рассылки. Каждый сервер MARS обслуживает кластер оконечных точек ATM.

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

Семейство адресов

1-2

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

3-9

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

10-12

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

13-14

Смещение расширения

15-16

Код операции

17-18

Тип и размер ATM-номера отправителя

19

Тип и размер ATM-субрадреса отправителя

20

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

Семейство адресов

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

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

Идентификатор протокола состоит из двух субполей – тип протокола (16 битов) и необязательное расширение SNAP (40 битов)

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

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

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

Стандартная контрольная сумма IP, рассчитанная для всего пакета.

Смещение расширения

Это поле указывает на существование и расположение дополнительного списка параметров.

Код операции

Код операции состоит из двух субполей – версия и тип. Версия показывает выполняемую операцию в контексте версии протокола управления, указанного mar$op.version.

Тип и размер ATM-номера отправителя

Информация об аппаратном адресе отправителя.

Тип и размер ATM-субрадреса отправителя

Информация об аппаратном субадресе отправителя.

PIM

RFC 2117 http://www.cis.ohio-state.edu/htbin/rfc/rfc2117.html

Протокол PIM-SM (Protocol Independent Multicast – Sparse Mode) служит для эффективной маршрутизации Multicast-групп, которые могут быть распределены по разным местам интерсети (в разных доменах). Этот протокол не связан с каким-либо из протоколов маршрутизации и разработан для поддержки разбросанных (sparse) групп.

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

Версия PIM

Тип

Размер адреса

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

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

Версия PIM

Номер версии протокола (текущее значение – 2).

Тип

Тип сообщения PIM.

Размер адреса

Размер адреса в байтах.

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

Контрольная сумма всего сообщения PIM. При расчете контрольной суммы значение этого поля принимается нулевым.

RIP

RFC1058
RFC1388
RFC1723, RFC1722, RFC1723, RFC1724
RFC2453

Протокол RIP (Routing Information Protocol) используется операционной системой Berkeley 4BSD UNIX для обмена маршрутной информацией. Реализованный как программа UNIX, протокол RIP2 базируется на своем одноименном предшественнике, разработанном компанией Xerox.

RIP2 является расширением протокола RIP, обеспечивающим передачу дополнительной маршрутной информации в сообщениях RIP и повышающим уровень безопасности.

Протокол RIP2 основан на передача дейтаграмм UDP. Каждый хост, использующий RIP2 имеет процесс маршрутизации, принимающий и передающий дейтаграммы UDP через порт 520. Формат пакетов RIP показан на рисунке.

8

16

32

Команда

Версия

Не используется

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

Тег маршрута

IP-адрес

Маска подсети

Следующий маршрутизатор (next hop)

Метрика

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

Часть дейтаграммы (от адреса до метрики, включительно) может повторяться до 25 раз.

Команда

Поле команды показывает назначение дейтаграммы:

1 Request – запрос на передачу всей таблицы маршрутизации или ее части.

2 Response – сообщение, содержащее полную таблицу маршрутизации или ее часть. Эти сообщения могут передаваться в ответ на запрос или сканирование, а при отсутствии изменений в таблице маршрутизации отправитель может генерировать такие сообщения по своей инициативе.

3 Traceon – (устаревшая команда) такие сообщения игнорируются.

4 Traceoff – (устаревшая команда) такие сообщения игнорируются.

5 Reserved – зарезервированное поле, используемое компанией Sun Microsystems для своих целей.

Версия

Номер версии протокола RIP. Обработка дейтаграмм зависит от указанного номера версии:

0 дейтаграммы с нулевым номером версии игнорируются.

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

2 указывает сообщения RIP, использующие аутентификацию, или содержащие информацию в недавно определенных полях.

>2 дейтаграммы протокола версии выше 1. Игнорируются все поля с нулевыми значениями.

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

Показывает тип адреса, указанного в данной записи. Это поле требуется потому, что протокол RIP2 может передавать информацию для различных протоколов. Идентификатор семейства адресов IP равен 2.

При использовании аутентификации это поле имеет значение 0xFFFF, а поле тега маршрута указывает тип аутентификации и пароль.

Тег маршрута

Это поле используется только для RIP2 и в сообщениях RIP должно иметь нулевое значение.

Атрибут, присвоенный маршруту. Этот атрибут должен сохраняться и использоваться при повторном анонсировании маршрута. Тег маршрута обеспечивает метод разделения внутренних (сетей внутри домена маршрутизации RIP) и внешних маршрутов RIP, которые могут импортироваться из EGP или других IGP.

IP-адрес

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

Маска подсети

Это поле используется только для RIP2 и в сообщениях RIP должно иметь нулевое значение.

Сетевая часть адреса (байты, задающие номера хостов, имеют нулевые значение, остальные байты – 1). Нулевое значение маски говорит о ее отсутствии.

Следующий маршрутизатор

Это поле используется только для RIP2 и в сообщениях RIP должно иметь нулевое значение.

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

Метрика

Определяет общую “стоимость” маршрута к получателю. Метрика представляет собой сумму стоимостей, связанных с сетями, через которые передается информация.

RIPng для IPv6

RFC 2080 1997-01 http://www.cis.ohio-state.edu/htbin/rfc/rfc2080.html

RIPng for IPv6 представляет собой протокол маршрутизации для версии IPv6, являющейся расширением протокола IPv4.

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

8

16

32

Команда

Версия

0

Запись таблицы маршрутизации (20 байтов)

Запись таблицы маршрутизации (20 байтов)

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

Команда

Поле команды говорит о назначении сообщения. Поддерживаются два варианта команд:

Request запрос таблицы маршрутизации или ее части.

Response отклик – сообщение, содержащее таблицу маршрутизации или ее часть.

Версия

Номер версии протокола (текущее значение – 1).

Запись таблицы маршрутизации

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

RSVP

RFC 2205 http://www.cis.ohio-state.edu/htbin/rfc/rfc2205.html

RFC 2208 http://www.cis.ohio-state.edu/htbin/rfc/rfc2208.html

RFC 2209 http://www.cis.ohio-state.edu/htbin/rfc/rfc2209.html

RSVP является протоколом резервирования ресурсов (Resource ReSerVation setup Protocol) предназначенным для интегрированного сервиса Internet. Протокол используется хостами для поддержки потоков данных от приложений, требующих заданного качества обслуживания от сети для отдельных потоков данных. Протокол также используется маршрутизаторами для доставки управляющих запросов QoS всем узлам.

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

4

8

16

32

Версия

Флаги

Тип сообщения

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

Send TTL

Резерв

Размер RSVP

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

Версия

Номер версии протокола (текущее значение – 1).

Флаги

Поле флагов в настоящее время не используется.

Тип сообщения

Поддерживаются следующие типы сообщений:

1 Path.

2 Resv.

3 PathErr.

4 ResvErr.

5 PathTear.

6 ResvTear.

7 ResvConf.

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

Контрольная сумма сообщения.

Send TTL

Значение времени жизни IP, с которым передается пакет.

Размер RSVP

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

AH

RFC1826 http://www.cis.ohio-state.edu/htbin/rfc/rfc1826.html

RFC1827 http://www.cis.ohio-state.edu/htbin/rfc/rfc1827.html

Протокол IP AH (Authentication Header – заголовок аутентификации) обеспечивает дополнительный уровень безопасности за счет добавления полей аутентификации в дейтаграммы IP. Параметры аутентификации рассчитываются с использованием всех полей дейтаграммы IP (включая не только заголовок IP, но и заголовки других протоколов, а также пользовательские данные), которые не могут изменяться в процессе доставки. Поля или опции, которые при доставке изменяются (например, счетчик интервалов, время жизни, идентификаторы, смещения фрагмента или указатели маршрутов) при расчете не принимаются во внимание (предполагается, что они имеют нулевые значения). Использование этого метода позволяет существенно повысить уровень безопасности по сравнению с протоколом IPv4 и этого уровня достаточно для большинства пользователей. При использовании с протоколом IPv6 заголовок AH обычно появляется после заголовка IPv6 Hop-by-Hop, но перед опциями получателя IPv6. При использовании с протоколом IPv4 заголовок AH обычно размещается после заголовка IPv4.

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

8

16

32

Следующий заголовок

Размер

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

SPI

Данные аутентификации

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

Следующий заголовок

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

Размер

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

SPI

Security Parameters Index – указывает параметры безопасности для дейтаграммы.

Данные аутентификации

Данные аутентификации в виде переменного числа 32-битовых слов.

ESP

RFC1826 http://www.cis.ohio-state.edu/htbin/rfc/rfc1826.html

RFC1827 http://www.cis.ohio-state.edu/htbin/rfc/rfc2406.html

ESP (IP Encapsulating Security Payload) служит для обеспечения целостности и конфиденциальности данных за счет их шифрования. В зависимости от пользовательских требований к безопасности этот механизм может применяться для шифрования сегментов транспортного уровня (например, TCP, UDP, ICMP, IGMP) или дейтаграмм IP целиком. Чтобы обеспечить конфиденциальность всей исходной дейтаграммы требуется использовать инкапсуляцию.

ESP может содержаться в любом месте между заголовком IP и конечным протоколом транспортного уровня. Для протокола ESP используется идентификатор IANA 50. Заголовок, расположенный непосредственно перед заголовком ESP, всегда будет содержать значение 50 в поле Next Header (следующий заголовок) для IPv6) или Protocol (протокол) для IPv4. ESP состоит из нешифрованного заголовка, за которым следуют зашифрованные данные. Шифруемые данные включают в себя защищенные поля заголовка ESP и защищаемые пользовательские данные, которые представляют собой целую дейтаграмму IP или кадр протокола вышележащего уровня (например, TCP или UDP).

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

8

16

32

SPI

Шифрованные данные

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

SPI

Security association identifier – 32-битовое псевдослучайное значение, идентифицирующее ассоциации безопасности дейтаграммы. Если ассоциаций не создано, поле SPI содержит значение 0x00000000. Поле SPI подобно параметру SAID, используемому другими протоколами безопасности.

Шифрованные данные

Поле данных переменной длины.

BGP-4

RFC 1654 http://www.cis.ohio-state.edu/htbin/rfc/rfc1654.html

BGP (Border Gateway Protocol – протокол граничного шлюза) представляет собой протокол маршрутизации между автономными системами (inter-Autonomous System). Основной функцией протокола BGP является обмен информацией о доступности сетей с другими системами BGP. Протокол BGP-4 обеспечивает расширенный набор механизмов для поддерживаемых классов междоменной маршрутизации.

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

Маркер

Размер

Тип

16 байтов

2 байта

1 байт

Формат заголовка BGP-4

Маркер

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

Размер

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

Тип

Тип сообщения – Open (открыть), Update (обновить), Notification (уведомление), KeepAlive (поддержать, сохранить).

EGP

RFC 904 http://www.cis.ohio-state.edu/htbin/rfc/rfc904.html

Протокол EGP (Exterior Gateway Protocol – протокол внешнего шлюза) служит для обмена сведениями о доступности сетей между соседними шлюзами (возможно из разных автономных систем). Протокол включает механизм приобретения (acquire) соседей, средства мониторинга доступности соседей и обмена информацией о доступности сетей в форме сообщений Update (обновление). Работа протокола основана на периодическом сканировании (polling) с использованием обмена сообщениями Hello/I-Heard-You (I-H-U) для мониторинга доступности соседей и передаче команд Poll для запроса сообщений Update.

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

8

16

32

Версия EGP

Тип

Код

Состояние

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

Номер АС

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

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

Версия EGP

Номер версии протокола EGP (текущее значение – 2).

Тип

Идентифицирует тип сообщения:

1 Отклик/индикация обновления

2 Команда опроса (Poll)

3 Сообщение о приобретении соседа

5 Сообщение о доступности соседа

8 Отклик/индикация ошибки.

Код

Идентифицирует код сообщения.

Состояние

Информация о состоянии, зависящая от типа сообщения.

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

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

Номер АС

Номер автономной системы.

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

Переменная состояния передачи (команды) или приема (отклики и индикаторы).

EIGRP

Протокол EIGRP (Enhanced Interior Gateway Routing Protocol – расширенный протокол внутреннего шлюза) представляет собой расширенный вариант протокола IGRP. Протокол IGRP является протоколом внутреннего шлюза компании Cisco, используемым в сетях TCP/IP и OSI. Протокол относится к числу внутренних шлюзов (interior gateway protocol – IGP), но может также использоваться в качестве протокола внешнего шлюза для междоменной маршрутизации. Протокол IGRP использует технологию маршрутизации на основе дистантного вектора. Такая же технология дистантного вектора применяется и для протокола EIGRP с сохранением информации о дистанциях нижележащего уровня. Возможности конвергенции (сближения) и эффективность работы этого протокола существенно повысились по сравнению с IGRP.

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

8

16

32

Версия

Код операции

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

Флаги

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

Номер подтверждения

Номер автономной системы

Тип

Размер

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

Версия

Номер версии протокола.

Код операции
  1. Update (обновление).
  2. Reserved (зарезервировано).
  3. Query (запрос).
  4. Hello (приветствие).
  5. IPX-SAP.
Тип

1 Параметры EIGRP.

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

3 Sequence (последовательность).

4 Версия программ.

5 Next Multicast

Размер

Размер кадра.

GRE

RFC 1701

RFC 1702

Протокол GRE (Generic Routing Encapsulation) обеспечивает механизм инкапсуляции произвольных пакетов в произвольный транспортный протокол. В наиболее общем случае система имеет пакеты, которые нужно инкапсулировать и маршрутизировать (информационные пакеты). Информация (payload) сначала инкапсулируется в пакет GRE, который может также содержать маршрут. Полученный в результате пакет GRE инкапсулируется в пакет другого протокола (протокол доставки).

Протокол GRE может с IP в качестве протокола доставки или информационного (payload) протокола. Заголовок GRE, используемый протоколом PPTP, незначительно отличается от заголовка, описанного в текущей спецификации протокола GRE.

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

16

32

Флаги

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

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

Смещение

Ключ

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

Маршрутизация

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

Флаги

Первые два октета заголовка содержат флаги GRE. Бит 0 является младшим, бит 12 – старшим. Используются следующие флаги:

Контрольная сумма присутствует (бит 0) и содержит корректное значение.

Маршрутизация присутствует (бит 1) – поля смещения и маршрутизации содержат корректные значения.

Ключ присутствует (бит 2) в заголовке GRE.

Порядковый номер присутствует (бит 3).

Strict Source Route (бит 4) – рекомендуется устанавливать этот флаг только поле маршрутной информации содержит только маршруты Strict Source.

Контроль рекурсии (биты 5-7) 3-битовое беззнаковое целое, указывающее допустимое число дополнительных инкапсуляций.

Номер версии (биты 13-15) – 0.

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

Тип протокола в поле содержимого (payload) пакета. В общем случае это поле указывает тип протокола Ethernet для данного пакета.

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

Необязательное поле. Контрольная сумма IP (дополнение до 1) для заголовка GRE и содержимого пакета.

Смещение

Необязательное поле. Показывает смещение в октетах от начала поля маршрутизации до первого октета проверяемой записи Source Route.

Ключ

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

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

Необязательное поле. 32-битовое целое число, вставляемое при инкапсуляции. Это значение может использоваться получателем для поддержки порядка передачи пакетов.

Маршрутизация

Необязательное поле. Содержит данные, которые могут использоваться при маршрутизации данного пакета.

Расширенный заголовок GRE использует показанный на рисунке формат.

16

32

Флаги

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

Ключ (старшая часть) – размер содержимого

Ключ (младшая часть) – идентификатор вызова

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

Номер подтверждения

Формат расширенного заголовка GRE

Флаги

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

C (бит 0) – контрольная сумма присутствует.

R (бит 1) – маршрутизация присутствует.

K (бит 2) – ключ присутствует.

S (бит 3) – порядковый номер присутствует.

s (бит 4) – присутствует Strict source route.

Recur (биты 5-7) – управление рекурсией.

A (бит 8) – порядковый номер подтверждения присутствует.

Flags (биты 9-12) – 0.

Ver (биты 13-15) – 1 (расширение GRE).

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

880B.

Ключ

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

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

Необязательное поле. Порядковый номер содержимого.

Номер подтверждения

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

HSRP

RFC2281 http://www.cis.ohio-state.edu/htbin/rfc/rfc2281.html

Протокол HSRP (Hot Standby Router Protocol) компании Cisco обеспечивает механизм поддержки неразрушающего восстановления трафика IP в некоторых ситуациях. В частности, этот протокол обеспечивает защиту от сбоев в маршрутизаторе первого интервала, когда хост-отправитель не может узнать IP-адрес маршрутизатора первого хопа динамически. Протокол предназначен для использования в локальных сетях с множественным доступом, групповой или широковещательной адресацией (например, Ethernet). Широкий класс традиционных реализаций хостов не поддерживает возможность динамического обнаружения принятого по умолчанию шлюза и соответствующей настройки своих параметров. Протокол HSRP обеспечивает для таких хостов требуемый сервис.

Протокол HSRP работает поверх UDP и использует порт 1985. Пакеты передаются по групповому адресу 224.0.0.2 с временем жизни TTL=1. Маршрутизаторы используют свои реальные адреса IP (а не виртуальные адреса IP) в качестве адреса отправителя для протокольных пакетов, поскольку маршрутизаторы HSRP могут идентифицировать друг друга.

Формат содержащей данные части дейтаграммы UDP для протокола HSRP показан на рисунке.

8

16

32

Версия

Код операции

Состояние

Время приветствия

Время удержания

Приоритет

Группа

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

Данные аутентификации

Виртуальный адрес IP

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

Версия

Номер версии HSRP (0 для текущей версии).

Код операции

Тип сообщения, содержащегося в пакете:

0 Приветствие (Hello), передаваемое для индикации работы маршрутизатора и его способности работать в активном или резервном (standby) режиме.

1 Coup (переворот) передается в тех случаях, когда маршрутизатор хочет стать активным.

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

Состояние

Каждый маршрутизатор в резервной (standby) реализует машину состояний. Поле состояния описывает текущее состояние маршрутизатора, передающего сообщение. Поле состояния может принимать следующие значения:

0 Initial (изначальное состояние)

1 Learn (обучение)

2 Listen (прослушивание)

4 Speak (разговор)

8 Standby (резерв)

16 Active (активен)

Время приветствия (Hellotime)

Приблизительный период (в секундах) повторения сообщений приветствия (hello), которые передает маршрутизатор. Если для маршрутизатора не настроено время приветствия, он может узнать его из сообщения Hello активного маршрутизатора. Маршрутизатор, передающий сообщение Hello должен установить значение периода приветствия в поле Hellotime. Если поле Hellotime не удается прочитать из сообщения активного маршрутизатора и оно не задано явно, рекомендуется использовать принятый по умолчанию период в 3 секунды.

Время удержания (Holdtime)

Время (в секундах), в течение которого сохраняется корректность текущего приветствия Hello. Это поле применяется только для сообщений Hello.

Приоритет

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

Группа

Идентифицирует резервную (standby) группу. Для сетей Token Ring корректны значения 0, 1 и 2, для остальных сетей – значения от 0 до 255.

Данные аутентификации

8-байтовое поле, содержащее пароль в явном виде (Clear-text) Если аутентификация не настроена, рекомендуется использовать принятое по умолчанию значение 0x63 0x69 0x73 0x63 0x6F 0x00 0x00 0x00.

Виртуальный адрес IP

4-байтовое поле виртуального адреса IP, используемого данной группой. Если виртуальный адрес не задан для маршрутизатора, он может быть получен из сообщения Hello от активного маршрутизатора. Адрес должен определяться таким способом только при его отсутствии в поле и наличии аутентификации для сообщения Hello.

IGRP

Протокол IGRP (Interior Gateway Routing Protocol – протокол внутреннего шлюза) был разработан компанией Cisco. Этот протокол используется для передачи маршрутной информации между маршрутизаторами.

Пакеты IGRP передаются с использованием дейтаграмм IP с полем протокола 9 (IGP). Пакеты начинаются с заголовка IGRP, за которым сразу же следует заголовок IP.

Версия

Код операции

Редактирование

ASystem

NInterior

NSystem

NExterior

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

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

Версия

Номер версии протокола (текущее значение – 1).

Код операции

Код операции, связанной с сообщением:

1 Update (обновление).

2 Request (запрос).

Редактирование

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

ASystem

Номер автономной системы. Шлюз может входить в несколько автономных систем, в каждой из которых используется свой протокол IGRP. Для каждой автономной системы используются свои таблицы маршрутизации. Это поле позволяет шлюзу выбрать набор используемых таблиц маршрутизации.

NInterior, NSystem, NExterior

Эти поля показывают номера записей в каждой из трех секций сообщений об обновлении таблиц. Первый элемент (NInterior) является внутренним, следующий (NSystem) – системным и последний (NExterior) – внешним.

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

Контрольная сумма IP, рассчитанная по тому же алгоритму, который используется для дейтаграмм UDP. При вычислении контрольной суммы принимается во внимание заголовок IGRP и маршрутная информация, которая следует после заголовка. При расчете поле контрольной суммы предполагается нулевым (не учитывается). Контрольная сумма не включает заголовок IP и не использует виртуальных заголовков как в UDP и TCP.

Запрос IGRP требует от получателя передать таблицу маршрутизации. Для запросов используются только поля версии, кода операции и ASystem, остальные поля имеют нулевые значения.

Сообщения об обновлении таблиц содержат заголовок, сразу за которым располагается таблица маршрутизации. Количество записей в таблице ограничено размером дейтаграммы (1500 байтов с учетом заголовка IP). При используемой в настоящее время структуре записей таблица может содержать до 104 элементов. Если таблица маршрутизации содержит большее число записей, нужно использовать несколько сообщений.

NARP

RFC1735 http://www.cis.ohio-state.edu/htbin/rfc/rfc1735.html

Протокол преобразования адресов NARP (NBMA Address Resolution Protocol) позволяет отправителю пакетов (хост или маршрутизатор), желающему связаться с другим узлом через сеть, не поддерживающую широковещательных адресов, с множественным доступом (Non-Broadcast Multi-Access или NBMA) на канальном уровне, найти NBMA-адрес получателя, если последний подключен к той же сети NBMA.

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

8

16

32

Версия

Счетчик хопов

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

Тип

Код

Не используется

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

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

Размер NBMA

Адрес NBMA (переменной длины)

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

Версия

Номер версии NARP (текущее значение – 1).

Счетчик хопов

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

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

Стандартная контрольная сумма IP для всего пакета NARP (начиная с фиксированного заголовка).

Тип

Тип пакета NARP – NARP Request (запрос) имеет тип 1, NARP Reply (отклик) – тип 2.

Код

Отклик на запрос NARP может содержать кэшируемую информацию. Если желательно получить аутентичные (некэшированные) данные, следует использовать код 2 (NARP Request for Authoritative Information). В остальных случаях используется код 1 (NARP Request). Отклики NARP мошут быть позитивными и негативными. Позитивный, не аутентичный (non-authoritative) отклик передается с кодом 1, позитивный аутентичный – с кодом 2. Для негативных и неаутентичных откликов используется код 3, а для негативных аутентичных – 4.

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

Адрес запрашивающего узла.

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

Адрес искомого узла NBMA.

Размер NBMA

Размер (в байтах) поля адреса NBMA отправителя пакета.

Адрес NBMA

Адрес NBMA, дополненный нулями для выравнивания по 32-битовой границе.

NHRP

RFC2332 http://www.cis.ohio-state.edu/htbin/rfc/rfc2332.html

draft http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-rolc-nhrp-15.txt

Протокол NHRP (NBMA Next Hop Resolution Protocol) позволяет станции-отправителю (хост или маршрутизатор), желающему связаться с другим узлом через сеть, не поддерживающую широковещательных адресов, с множественным доступом (Non-Broadcast Multi-Access или NBMA) на канальном уровне, определять адреса межсетевого уровня и адреса NBMA следующего подходящего маршрутизатора (next hop) NBMA в направлении станции-получателя.

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

8

16

24

32

ar$afn

ar$pro.type

ar$pro.snap

ar$pro.snap

ar$hopcnt

ar$pkstz

ar$chksum

ar$extoff

ar$op.version

ar$op.type

ar$shtl

ar$sstl

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

ar$afn

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

ar$pro.type

16-битовое беззнаковое целое.

ar$pro.snap

Когда поле ar$pro.type имеет значение 0x0080, для кодирования типа протокола будет использоваться расширение snap, помещаемое в поле ar$pro.snap. В остальных случаях это поле имеет нулевое значение.

ar$hopcnt

Счетчик интервалов, показывающий максимальное число NHS, через которые может пройти пакет NHRP до его отбрасывания.

ar$pktsz

Общий размер пакета NHRP в октетах.

ar$chksum

Стандартная контрольная сумма IP для всего пакета NHRP.

ar$extoff

Это поле говорит о существовании и местоположении расширений NHRP.

ar$op.version

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

ar$op.type

Если ar$op.version = 1, данное поле представляет тип пакета NHRP. Поддерживаются следующие типы пакетов:

1 NHRP Resolution Request (запрос преобразования адреса).

2 NHRP Resolution Reply (отклик на запрос преобразования адреса).

3 NHRP Registration Request (запрос регистрации).

4 NHRP Registration Reply (отклик на запрос регистрации).

5 NHRP Purge Request (запрос удаления).

6 NHRP Purge Reply (отклик на запрос удаления).

7 NHRP Error Indication (индикация ошибки).

ar$shtl

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

ar$sstl

Тип и размер субадреса NBMA для отправителя в контексте семейства адресов (address family number).

OSPF

RFC1583 http://www.cis.ohio-state.edu/htbin/rfc/rfc1583.html

OSPF (Open Shortest Path First – открывать сначала кратчайший путь) представляет собой протокол маршрутизации IP на основе информации о состоянии каналов. OSPF является протоколом внутреннего шлюза, используемым для маршрутизации внутри группы маршрутизаторов. Протокол использует технологию оценки состояния каналов, при которой маршрутизаторы передают друг другу информацию о прямых соединениях между ними и каналах связи с другими маршрутизаторами.

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

Версия

Тип пакета

Размер пакета

Идентификатор маршрутизатора

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

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

Тип AU

Аутентификация

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

Версия

Номер версии протокола (текущее значение – 1).

Тип пакета

Используются пакеты следующих типов:

1 Hello

2 Database Description

3 Link State Request

4 Link State Update

5 Link State Acknowledgment.

Размер пакета

Размер пакета в байтах с учетом стандартного заголовка OSPF.

Идентификатор маршрутизатора

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

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

32-битовое число, идентифицирующее область, к которой относится данный пакет. Все пакеты OSPF ассоциируются с одной областью. Большинство пакетов передаются только через один интервал между маршрутизаторами (хоп). Пакеты, передаваемые через виртуальный канал, маркируются идентификатором магистрали (0.0.0.0).

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

Стандартная контрольная сумма IP для всего пакета, начиная с заголовка OSPF, но без учета 64-битового поля аутентификации. При расчете контрольной суммы используются 16-битовые слова пакета, за исключением поля аутентификации. Если длина пакета не кратна 16, пакет дополняется 8 нулями до расчета контрольной суммы.

Тип AU

Указывает схему аутентификации, используемую для пакета.

Аутентификация

64-битовое поле, используемое для аутентификации пакета.

Mobile IP

RFC2002 http://www.cis.ohio-state.edu/htbin/rfc/rfc2002.html

RFC2290 http://www.cis.ohio-state.edu/htbin/rfc/rfc2290.html

RFC2344 http://www.cis.ohio-state.edu/htbin/rfc/rfc2344.html

Протокол Mobile IP позволяет перемещать узлы IP из одной подсети в другую. Для идентификации каждого мобильного узла используется его “домашний адрес”, независимо от текущего положения этого узла в сети Internet. При обращении из другого места с мобильным узлом также связывается адрес care-of, который обеспечивает информацию о текущем месте подключения узла к Internet. Протокол позволяет регистрировать адреса care-of с “домашним агентом”. Агент передает дейтаграммы, адресованные мобильному узлу через туннель, используя адрес care-of. После доставки на удаленный конец туннеля каждая дейтаграмма передается мобильному узлу. Протокол Mobile IP можно использовать в однородных и гетерогенных сетях. Mobile IP определяет группу новых управляющих сообщений, передаваемых с использованием UDP, Registration Request (запрос регистрации) и Registration Reply (отклик на запрос регистрации).

Пакеты IP содержат IP-адреса отправителя и получателя, после которых указывается номер порта UDP для отправителя и получателя, а за ними следуют поля протокола Mobile IP. Пакеты Mobile IP могут являться запросами регистрации (Registration Request) или откликами на такие запросы (Registration Reply).

Формат запросов регистрации Mobile IP показан на рисунке.

8

9

10

11

12

13

14

15

16

Тип

S

B

D

M

G

V

T

R

Время жизни

Домашний адрес

Домашний агент

Адрес Care-of

Идентификация

Расширение

Структура запросов регистрации Mobile IP

Тип

Значение 1 говорит о запросе регистрации.

S

Установленный флаг S говорит о том, что мобильный узел запрашивает регистрацию с прежними привязками (prior mobility bindings).

B

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

D

Флаг D говорит о том, что мобильный узел будет самостоятельно декапсулировать (извлекать) дейтаграммы, переданные по адресу care-of.

M

Минимальная инкапсуляция. Флаг M говорит о том, что домашний агента мобильного узла использует минимальную инкапсуляцию дейтаграмм, туннелируемых мобильному узлу.

G

GRE-инкапсуляция. Флаг G говорит о том, что домашний агента мобильного узла использует инкапсуляцию GRE для дейтаграмм, туннелируемых мобильному узлу.

V

Van Jacobson. Этот флаг говорит о том, что агент мобильного узла использует компрессию заголовков Van Jacobson для канала связи с мобильным узлом.

T

Этот флаг устанавливается в тех случаях, когда мобильный узел просит своего домашнего агента воспринимать обратный туннель со своего адреса care-of. Мобильные узлы, использующие чужие (foreign) care-of-адреса агентов запрашивают у чужого агента обратное туннелирование для своих пакетов.

R

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

Время жизни

Число секунд, остающееся до окончания срока регистрации.

Домашний адрес

IP-адрес мобильного узла.

Домашний агент

IP-адрес домашнего агента мобильного узла.

Адрес Care-of

IP-адрес конца туннеля.

Идентификация

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

Расширение

После фиксированной части регистрационного запроса может размещаться одно или несколько расширений (Extension). Во все запросы регистрации должно включаться расширение Mobile-Home Authentication Extension.

Формат откликов на регистрационные запросы Mobile IP показан на рисунке.

8

16

32

Тип

Код

Время жизни

4

Домашний адрес

8

Домашний агент

12

Идентификация

20

Расширение

Структура регистрационных откликов Mobile IP

Тип

Значение 3 говорит об отклике на регистрационный запрос.

Код

Значение, показывающее результат регистрационного запроса:

Успешная регистрация:

0 регистрация принята

1 регистрация принята, но одновременное связывание не поддерживается.

Регистрация отвергнута чужим (foreign) агентом:

64 причина не указана

65 административный отказ

66 нехватка ресурсов

67 отказ при аутентификации мобильного узла

68 отказ при аутентификации домашнего агента

69 время жизни слишком велико для регистрации

70 некорректно сформированный запрос

71 некорректно сформированный отклик

72 запрошенная инкапсуляция недоступна

73 запрошенная компрессия Van Jacobson недоступна

Сервис не поддерживается чужим агентом:

74 запрошенный туннель недоступен

75 обратный туннель является обязательным, а флаг T не установлен

76 мобильный узел слишком удален

Регистрация отвергнута домашним агентом:

80 домашняя сеть недоступна (получена ошибка ICMP)

81 недоступен хост домашнего агента (ошибка ICMP)

82 недоступен порт домашнего агента (ошибка ICMP)

88 недоступен домашний агент (ошибка ICMP)

Сервис не поддерживается домашним агентом:

137 запрошенный обратный туннель недоступен

138 обратный туннель является обязательным, а флаг T не установлен

139 запрошенная инкапсуляция недоступна.

Время жизни

Если поле кода говорит о том, что запрос регистрации принят, время жизни показывает число секунд, остающихся до истечения времени регистрации. Нулевое значение этого поля говорит об отмене регистрации мобильного узла. Значение 0xffff показывает бесконечное время жизни. Если поле кода содержит код отказа в регистрации, значение поля времени жизни не имеет смысла и должно игнорироваться.

Van Jacobson

RFC1144 

Протокол Van Jacobson обеспечивает механизм компрессии TCP, существенно повышающий эффективность работы систем TCP/IP на низкоскоростных (300 – 19200 бит/с) последовательных каналах.

Формат сжатых пакетов TCP показан на рисунке.

C

I

P

S

A

W

U

1

Номер соединения (C)

1

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

2

Указатель важности (U)

1

Дельта-окно (W)

1

Дельта-запрос (A)

1

Дельта-последовательность (S)

1

Дельта-идентификатор IP (I)

1

Данные

Структура сжатых пакетов TCP

C, I, P, S, A, W, U

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

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

Используется для указания местоположения копии последнего пакета для данного соединения TCP.

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

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

Указатель важности

Это поле используется при установке флага U.

Дельта-значения для каждого поля

Показывает изменения соответствующих полей по сравнению с исходным пакетом TCP (для каждого поля, указанного в маске изменений).

XOT

RFC1613

Протокол XOT является реализацией X.25 over TCP компании Cisco Systems.

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

Версия

Размер

2 байта

2 байта

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

Версия

Номер версии протокола.

Размер

Общая длина пакета.

MGCP

IETF draft: http://www.ietf.org/internet-drafts/draft-huitema-mgcp-test1-00.txt

Протокол MGCP (Media Gateway Control Protocol – протокол управления шлюзом между средами) используется для управления телефонными шлюзами с помощью внешних элементов управления вызовами, называемых контроллерами шлюза сред (media gateway controller) или агентами вызовов (call agent). Телефонный шлюз является элементом сети, обеспечивающим преобразование звуковых сигналов, переносимых по телефонным каналам, в пакеты данных, передаваемые через Internet, и обратное преобразование.

MGCP использует архитектуру управления, в которой интеллектуальные элементы управления вызовами располагаются за пределами шлюза и обслуживаются внешними элементами управления вызовами. MGCP предполагает, что все элементы управления вызовами или агенты вызовов (Call Agent) синхронизированы между собой для передачи согласованных (coherent) команд шлюзам, находящимся под их управлением. Важно отметить, что протокол MGCP использует отношения ведущий-ведомый (master/slave) – шлюзы выполняют команды, передаваемые агентами вызовов.

Протокол MGCP реализует интерфейс управления шлюзом между средами как набор транзакций. Транзакции состоят из команд и обязательных (mandatory) откликов. Существует восемь типов команд:

  • CreateConnection (организовать соединение)
  • ModifyConnection (изменить соединение)
  • DeleteConnection (удалить соединение)
  • NotificationRequest (запрос уведомления)
  • Notify (уведомление)
  • AuditEndpoint (аудит оконечной точки)
  • AuditConnection (аудит соединения)
  • RestartInProgress (едет процесс перезапуска).

Первые четыре команды передаются шлюзу агентом вызовов. Команда Notify передается шлюзом агенту. Шлюз может также передавать команды удаления соединений (DeleteConnection). Call Agent может передавать шлюзу команды аудита (Audit). Шлюз может передавать команды RestartInProgress агенту вызовов.

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

MGCP использует идентификаторы транзакций для того, чтобы можно было связать запрос с откликом на него. Значения идентификаторов транзакций могут находиться в диапазоне от 1 до 999999999. Объект MGCP не может повторно использовать идентификатор транзакции раньше, чем через три минуты после завершения предыдущей транзакции с таким же номером.

Заголовок команды содержит:

  • Командную строку, идентифицирующую запрашиваемую операцию, идентификатор транзакции, имя оконечной точки, для которой должна выполняться запрошенная операция, и номер версии протокола MGCP.
  • Набор строк параметров, содержащих имя и значение параметра.

Командная строка содержит:

  • Имя запрашиваемой команды.
  • Идентификатор транзакции (1 и 999999999), используемый для сопоставления команд и откликов. Объект MGCP не может повторно использовать идентификатор транзакции раньше, чем через три минуты после завершения предыдущей транзакции с таким же номером.
  • Имя оконечной точки, для которой должна выполняться запрошенная операция (в уведомлениях – имя оконечной точки, для которой передается уведомление).
  • Номер версии протокола.

Все четыре элемента команд передаются в виде текстовых строк ASCII с разделением слов пробелами (ASCII – 0x20) или символами табуляции (0x09). Предпочтительно использовать в качестве разделителя символ пробела.

SGCP

IETF draft: http://www.ietf.org/internet-drafts/draft-huitema-sgcp-v1-02.txt

Протокол SGCP (Simple Gateway Control Protocol – простой протокол управления шлюзом) используется для управления телефонными шлюзами с помощью внешних элементов управления вызовами. Телефонный шлюз является элементом сети, обеспечивающим преобразование звуковых сигналов, переносимых по телефонным каналам, в пакеты данных, передаваемые через Internet, и обратное преобразование.

SGCP использует архитектуру управления, в которой интеллектуальные элементы управления вызовами располагаются за пределами шлюза и обслуживаются внешними элементами управления вызовами. SGCP предполагает, что все элементы управления вызовами или агенты вызовов (Call Agent) синхронизированы между собой для передачи согласованных (coherent) команд шлюзам, находящимся под их управлением.

Протокол SGCP реализует простой интерфейс управления шлюзом между средами как набор транзакций. Транзакции состоят из команд и обязательных (mandatory) откликов. Существует пять типов команд:

  • CreateConnection (организовать соединение)
  • ModifyConnection (изменить соединение)
  • DeleteConnection (удалить соединение)
  • NotificationRequest (запрос уведомления)
  • Notify (уведомление)

Первые четыре команды передаются шлюзу агентом вызовов. Команда Notify передается шлюзом агенту. Шлюз может также передавать команды удаления соединений (DeleteConnection).

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

Заголовок команды содержит:

  • Командную строку.
  • Набор строк параметров, содержащих имя и значение параметра.

Командная строка содержит:

  • Имя запрашиваемой команды.
  • Идентификатор транзакции (1 и 999999999), используемый для сопоставления команд и откликов. Объект MGCP не может повторно использовать идентификатор транзакции раньше, чем через три минуты после завершения предыдущей транзакции с таким же номером.
  • Имя оконечной точки, для которой должна выполняться запрошенная операция (в уведомлениях – имя оконечной точки, для которой передается уведомление).
  • Номер версии протокола.

Все четыре элемента команд передаются в виде текстовых строк ASCII с разделением слов пробелами (ASCII – 0x20) или символами табуляции (0x09). Предпочтительно использовать в качестве разделителя символ пробела.

DNS

RFC1035

RFC1706 http://www.cis.ohio-state.edu/htbin/rfc/rfc1706.html

Протокол DNS (Domain Name Service – служба доменных имен) обеспечивает поиск имен хостов, используя распределенную по сетевым серверам имен базу данных.

Формат сообщений DNS показан на рисунке.

16

21

28

32

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

Q

Запрос

A

T

R

V

B

Rcode

Счетчик вопросов

Счетчик ответов

Счетчик Authority

Счетчик дополнений

Формат сообщений DNS

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

16-битовое поле для обозначения соответствия между запросами и откликами.

Q

1-битовый флаг запроса (query).

Запрос

4-битовое описание типа сообщения:

0 стандартный запрос (адрес по имени).

1 обратный запрос (имя по адресу).

2 запрос состояния сервера.

A

Authoritative Answer – 1-битовый флаг, показывающий отклик от уполномоченного (authoritative) сервера имен.

T

Truncation – отбрасывание. 1-битовый флаг, говорящий об отбрасывании сообщения.

R

1-битовый флаг, устанавливаемый устанавливаемый для разрешения запроса рекурсивным путем.

V

1-битовый флаг поддержки рекурсивного сервиса.

B

3-битовое поле, зарезервированное для использования в будущем (0).

RCode

Код отклика – 4-битовое поле, устанавливаемое сервером имен для обозначения состояния запроса:

0 нет ошибок.

1 невозможно интерпретировать запрос из-за формальной ошибки.

2 обработка невозможна из-за сбоя на сервере.

3 запрошенное имя не существует.

4 неподдерживаемый тип запроса.

5 отказ от выполнения запроса.

Счетчик вопросов

16-битовое поле, содержащее число записей в разделе вопросов.

Счетчик ответов

16-битовое поле, содержащее число записей о ресурсах в разделе ответов.

Счетчик Authority

16-битовое поле, определяющее число записей о ресурсах сервера имен в разделе authority (полномочия).

Счетчик дополнений

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

NetBIOS/IP

RFC1002

NetBIOS/IP является стандартным протоколом поддержки сервиса NetBIOS в средах TCP/IP как для локальных сетей, так и для Internet. Определены различные типы узлов для поддержки разных топологий ЛВС и Internet, а также для обеспечения возможности использования широковещательных пакетов IP или запрета широковещания.

Для протокола NetBIOS поддерживаются типы Name Service, Session или Datagram.

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

Name_trn_id

Opcode

Nm_flags

Rcode

Qdcount

Ancount

Nscount

Arcount

Структура заголовка NetBIOS/IP

Name_trn_id

Идентификатор транзакции для службы имен (Name Service Transaction).

Opcode

Код операции, задающий тип пакета:

0 Query (запрос).

5 Registration (регистрация).

6 Release (освобождение).

7 WACK.

8 Refresh (обновление).

Nm_flags

Флаги операции.

Rcode

Код результата запроса.

Qdcount

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

Ancount

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

Nscount

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

Arcount

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

FTP

RFC959

Протокол FTP (File Transfer Protocol – протокол переноса файлов) обеспечивает базовые элементы системы совместного использования файлов хостами сети. Протокол FTP использует TCP для создания виртуальных соединений, обеспечивающих поддержку управления. Для операций переноса файлов организуется отдельное соединение TCP. Управляющие соединения используют образ протокола TELNET для обмена командами и сообщениями между хостами сети.

Команды

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

Команда Описание

ABOR прервать соединение, используемое для передачи данных.

ACCT <account> Учетная запись для системных привилегий.

ALLO <bytes> Выделение пространства для записи фалов на сервер.

APPE <filename> Добавление (Append) файла к файлу с таким же именем на сервере.

CDUP <dir path> Переход в родительский каталог на сервере.

CWD <dir path> Смена рабочего каталога на сервере.

DELE <filename> Удаление файла на сервере.

HELP <command> Получение справки об указанной команде.

LIST <name> Получение информации о связи имени с файлом или каталогом.

MODE <mode> Режим передачи (S=поток, B=блок, C=компрессия).

MKD <directory> Создание каталога на сервере.

NLST <directory> Список содержимого каталога.

NOOP Отсутствие операций, кроме подтверждений от сервера.

PASS <password> Пароль для входа в систему.

PASV Запрос к серверу на соединение, для передачи данных.

PORT <address> IP-адрес и 2-байтовый номер порта.

PWD Выводит имя текущего каталога.

QUIT Отключение от сервера FTP.

REIN Повторный вход в систему.

REST <offset> Восстановление передачи файла с заданной позиции.

RETR <filename> Найти (скопировать) файл на сервере.

RMD <directory> Удалить каталог на сервере.

RNFR <old path> Переименовать путь (со старого).

RNTO <new path> Переименовать путь (на новый).

SITE <params> Получить параметры сайта от сервера.

SMNT <pathname> Смонтировать указанную структуру файлов.

STAT <directory> Получить информацию о текущем каталоге или процессе.

STOR <filename> Записать (скопировать) файл на сервер.

STOU <filename> Сохранить файл с именем сервера.

STRU <type> Структура данных (F=файл, R=запись, P=страница).

SYST Получить информацию об операционной системе сервера.

TYPE <data type> Тип данных (A=ASCII, E=EBCDIC, I=бинарные).

USER <username> Имя пользователя для входа в систему.

Сообщения

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

Код Пояснительный текст

110 Restart marker at MARK yyyy=mmmm (new file pointers).

120 Service ready in nnn minutes.

125 Data connection open, transfer starting.

150 Open connection.

200 OK.

202 Command not implemented.

211 (System status reply).

212 (Directory status reply).

213 (File status reply).

214 (Help message reply).

215 (System type reply).

220 Service ready.

221 Log off network.

225 Data connection open.

226 Close data connection.

227 Enter passive mode (IP address, port ID).

230 Log on network.

250 File action completed.

257 Path name created.

331 Password required.

332 Account name required.

350 File action pending.

421 Service shutting down.

425 Cannot open data connection.

426 Connection closed.

450 File unavailable.

451 Local error encountered.

452 Insufficient disk space.

500 Invalid command.

501 Bad parameter.

502 Command not implemented.

503 Bad command sequence.

504 Parameter invalid for command.

530 Not logged onto network.

532 Need account for storing files.

550 File unavailable.

551 Page type unknown.

552 Storage allocation exceeded.

553 File name not allowed.

TFTP

RFC783 http://www.cis.ohio-state.edu/htbin/rfc/rfc783.html

RFC1350 http://www.cis.ohio-state.edu/htbin/rfc/rfc1350.html

Протокол TFTP (Trivial File Transfer Protocol – тривиальный протокол переноса файлов) использует дейтаграммы UDP. TFTP поддерживает операции записи и чтения файлов, но не поддерживает служб каталогов и проверки полномочий (авторизации) пользователей.

Команды

Список команд TFTP приведен ниже:

Команда Описание

Read Request Запрос на чтение файла.

Write Request Запрос на запись в файл.

File Data Копирование файла.

Data Acknowledge Подтверждение.

Error Индикация ошибки.

Параметры

Запросы чтения и записи протокола TFTP используют следующие параметры:

Параметр Описание

Filename Имя файла (в кавычках), который будет использоваться для чтения или записи.

Mode Режим передачи данных – формат файла для копирования:

NetASCII файл ASCII.

Octet 8-битовые бинарные данные.

Mail стандартный формат ASCII с именем пользователя вместо имени файла.

Команды данных и подтверждения TFTP используют следующие параметры:

Команда Описание

Block Номер блока или порядковый номер текущего кадра данных.

Data Первая часть файла данных для кадров данных TFTP.

TFTP Errors Кадр ошибки TFTP, содержащий код ошибки в круглых скобках, сопровождаемое сообщением об ошибке:

(0000) неизвестная ошибка.

(0001) файл не найден.

(0002) нарушение прав доступа.

(0003) нехватка места на диске.

(0004) некорректная операция TFTP.

(0005) неизвестный идентификатор транзакции.

(0006) файл с таким именем уже существует.

  1. неизвестный пользователь.

Finger

RFC1288 http://www.cis.ohio-state.edu/htbin/rfc/rfc1288.html

Протокол Finger обеспечивает простой интерфейс с удаленными программами, обеспечивающими информацию о пользователях. Это протокол обмена информацией о пользователях на базе протокола TCP с использованием порта 79 (восьмеричный номер – 117). Локальный хост открывает TCP-соединение с удаленным хостом через порт Finger. После этого удаленная сторона получает доступ к RUIP для обработки запросов о пользователях. Локальный хост посылает RUIP одну строку запроса на основе спецификации запросов Finger и ожидает отклика RUIP. После получения и обработки запроса RUIP возвращает ответ, инициируя завершение сеанса и разрыв соединения. Локальный хост получает ответ и сигнал закрытия сеанса, после чего разрывает соединение.

Протокол Finger отображает данные и вся передаваемая информация должна быть представлена в формате ASCII без бита контроля четности и с завершением строк символами перевода строки и возврата каретки (ASCII 13, ASCII 10). Такое требование исключает использование других форматов типа EBCDIC. Кроме того, любой символ с кодом ASCII от 128 до 255 должны трактоваться как символы других языков. Отметим, что последовательность символов ASCII 13, ASCII 10 не отображается на экране, поскольку она означает лишь переход в начало новой строки.

Gopher

RFC 1436 http://www.ietf.org/rfc/rfc1436.txt

Протокол Internet Gopher и одноименная программа используют модель клиент-сервер. Этот протокол предполагает использование надежного протокола доставки TCP. Серверы Gopher прослушивают порт 70 (этот номер порта выделен для протокола Gopher комитетом IANA). Документы Gopher могут располагаться на множестве хостов Internet. Пользователи запускают клинетскую программу на своем компьютере, подключаются к серверу Gopher и посылают ему селектор (строка текста, которая может быть пустой) через соединение TCP с использованием пердопределенного порта. Сервер отвечает на запрос текстовым блоком, завершающимся точкой в пустой строке и разрывает соединение.

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

Символы после знака табуляции (до следующего символа табуляции) формируют строку селектора, которую клиентская программа должна передать серверу для получения документа (или списка содержимого каталога). Клиент никогда не меняет строку селектора, которая зачастую является маршрутом доступа или другим селектором, используемым сервером для доступа к желаемому элементу. Следующие два символа табуляции обозначают имя домена для хоста и номер порта. При наличии других символов табуляции клиент Gopher должен игнорировать их. Символы CR LF обозначают переход на новую строку.

Символы типа элементов

Клиент Gopher решает вопрос доступности объекта для просмотра по первому символу каждой строки в списке содержимого каталога. Увеличение этого списка может расширять протокол. Ниже приведен список определенных в настоящее время элементов:

0 Файл

1 Каталог

2 Сервер телефонного справочника CSO

3 Ошибка

4 Файл BinHexed Macintosh

5 Некоторые типы бинарных архивов DOS (клиент должен читать архив до завершения сеанса TCP).

6 UU-кодированный файл UNIX

7 Сервер Index-Search

8 Указатель на текстовую сессию Telnet.

9 Бинарный файл (клиент должен читать архив до завершения сеанса TCP).

+ Резервный сервер

T Указатель на текстовый сеанс tn3270

g Графический файл в формате GIF

I Некоторые файлы образов (клиент должен сам выбрать способ отображения).

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

HTTP

RFC1945 http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html

HTTP (Hypertext Transfer Protocol – протокол передачи гипертекста) представляет собой протокол уровня приложений, обеспечивающий простой и быстрый способ организации распределенных гиперсред для совместного использования в сети. Сообщения передаются в формате, похожем на форматы Internet Mail и MIME (Multipurpose Internet Mail Extensions).

Пакет запроса

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

Метод

Запрашиваемый URI

Версия HTTP

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

Метод

Метод, который нужно выполнить для ресурса.

Запрашиваемый URI

Универсальный идентификатор ресурса (Uniform Resource Identifier URI), к которому адресуется запрос, т.е. сетевого ресурса.

Версия HTTP

Используемая версия протокола HTTP.

Пакеты откликов

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

Версия HTTP

Код состояния

Причина

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

Версия HTTP

Используемая версия протокола HTTP.

Код состояния

3-значное целое число, указывающее код результата.

Причина

Текстовое описание результата запроса.

S-HTTP

draft-ietf-wts-shttp-06

Протокол S-HTTP (Secure HTTP) обеспечивает механизм защищенной связи между парами клиент-сервер HTTP для того, чтобы можно было выполнять коммерческие транзакции с помощью широкого класса приложений. S-HTTP обеспечивает гибкое решение для поддержки множества ортогональных режимов работы, механизмов управления ключами, моделей доверия, криптографических алгоритмов и форматов инкапсуляции путем согласования опций между участниками каждой транзакции. Сообщения Secure HTTP синтаксически совпадают с сообщениями HTTP и состоят из строк запроса или состояния, за которыми следует заголовок и текст сообщения. Однако заголовки S-HTTP отличаются от заголовков HTTP, а тело сообщений обычно зашифровано.

IMAP4

RFC2060 http://www.cis.ohio-state.edu/htbin/rfc/rfc2060.html

Протокол IMAP4 (Internet Message Access Protocol, Version 4rev1) обеспечивает клиентам доступ и возможность манипуляций с почтовыми сообщениями на сервере. IMAP4 поддерживает операции с удаленными папками сообщений, называемыми почтовыми ящиками (mailbox) как при работе с локальными почтовыми ящиками. Протокол IMAP4 обеспечивает также поддержку offline-клиентов для ресинхронизации с сервером.

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

IMAP4 состоит из последовательности текстовых сообщений, содержащих команды, текстовые строки и т.п. Каждое сообщение завершается последовательностью символов CRLF (перевод строки, возврат каретки). Пример сообщения приведен ниже:

Server Message: “a002 OK [READ-WRITE] SELECT completed<crlf>”

Client Message: “a001 login mrc secret<crlf>”

Предопределенных полей в протколе IMAP4 не используется.

IPDC

Internet Drafts http://www.ietf.org/internet-drafts/draft-draft-taylor-ipdc-00.txt

Internet Drafts http://www.ietf.org/internet-drafts/draft-calhoun-diameter-07.txt

IPDC (IP Device Control – управление устройствами IP) представляет собой семейство протоколов, компоненты которого можно использовать совместно ил по отдельности для управления соединениями, средой и передачей сигнализации. Этот протокол решает задачи одного или нескольких протоколов управления шлюзами, расположенными на границе между коммутируемой телефонной сетью и сетью internet, а также завершающих коммутируемые транки. Примерами таких устройств могут служить серверы доступа и шлюзы VoIP (голос через IP). Необходимость разделения протоколов управления от системы сигнализации возникает в тех случаях, когда требуется, чтобы логика управления сервисом для обработки соединений полностью или частично была реализована за пределами шлюзов. Протокол IPDC был построен на базе структуры, обеспечиваемой протоколом DIAMETER, который был специально разработан для аутентификации, авторизации и ведения учета.

Существуют два типа сообщений IPDC/DIAMETER – сообщения, содержащие только заголовок, и сообщения с парами атрибут-значение AVP в дополнение к заголовку. Сообщения, состоящие только из заголовка, используются в качестве подтверждений для партнера.

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

8

13

16

32

Radius PCC

Флаги

Вер.

Размер пакета

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

Следующий передаваемый

Следующий принимаемый

Атрибуты

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

Radius PCC

Поле PCC (Packet Compatibility Code – код совместимости пакета) используется для обратной совместимости с протоколом RADIUS. Для того, чтобы отличать сообщения DIAMETER/IPDC от сообщений RADIUS используются специально зарезервированные значения, позволяющие одновременно поддерживать оба протокола, используя первый октет заголовка. Поле RADIUS PCC в сообщениях DIAMETER/IPDC должно иметь значение 254.

Флаги пакета

Флаги пакета используются для идентификации всех опций.

Версия

Номер версии, связанной с принимаемым пакетом. Значение 1 показывает протокол IPDC версии 1.

Размер пакета

Показывает размер пакета с учетом полей заголовка.

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

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

Следующий передаваемый (Ns)

Это поле присутствует в пакетах при установке флага Window-Present в заголовке пакета. Поле Next Send (Ns) копируется из переменной состояния порядкового номера передачи (Ss) во время передачи сообщения.

Следующий принимаемый (Nr)

Это поле присутствует в пакетах при установке флага Window-Present в заголовке пакета. Поле Nr Поле Next Send (Ns) копируется из переменной состояния порядкового номера приема (Sr) и показывает порядковый номер (Ns) +1 (модуль 2^16) принятого пакета с наибольшим номером.

Атрибуты

Атрибуты IPDC содержат специфические команды и параметры, которые должны передаваться между оконечными точками IPDC для выполнения задач связанных с управлением шлюзом сред (Media Gateway).

ISAKMP

RFC2408 http://www.cis.ohio-state.edu/htbin/rfc/rfc2408.html

Протокол ISAKMP (Internet Message Access Protocol, version 4rev1) определяет процедуры и форматы пакетов для организации, согласования, обновления и удаления ассоциаций безопасности SA (Security Associations). SA содержат все сведения, требуемые для выполнения различных типов сервиса обеспечения безопасности сети (услуги IP-уровня типа аутентификации заголовков и инкапсуляции содержимого, услуги транспортного и прикладного уровней, самообеспечение безопасности трафика согласования параметров). ISAKMP определяет содержимое (payload) обмена при генерации ключей и данных аутентификации. Эти форматы обеспечивают надежный способ обмена ключами и сведениями аутентификации независимо от метода генерации ключей, алгоритма шифрования и механизма аутентификации.

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

8

12

16

24

32

Initiator cookie (8 байтов)

Responder cookie (8 байтов)

След. элемент

MjVer

MnVer

Тип обмена

Флаги

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

Размер

Структура ISAKMP

Initiator cookie

Cookie объекта, инициировавшего организацию SA, уведомление SA или удаление SA.

Responder cookie

Cookie объекта, отвечающего на сообщение от организации SA, уведомлении SA или удалении SA.

Следующий элемент

Показывает тип первого элемента содержимого (payload) в данном сообщении. Поддерживаются следующие типы:

0 нет

1 Security Association (SA)

2 Proposal (P) – предложение

3 Transform (T) -0 преобразовать

4 Key Exchange (KE) – обмен ключами

5 Identification (ID) – идентификация

6 Certificate (CERT) – сертификат

7 Certificate Request (CR) – запрос сертификата

8 Hash (HASH) – смешать

9 Signature (SIG) – сигнатура, подпись

10 Nonce (NONCE)

11 Notification (N) – уведомление

12 Delete (D) – удалить

13 Vendor ID (VID) – идентификатор производителя

14-127 Reserved – зарезервированы

128-255 Private use – частное использование

MjVer

Показывает старшую часть номера версии используемого протокола ISAKMP. Реализации на основе RFC2408 должны использовать значение 1, а реализации на основе предварительных версий ISAKMP (Internet-Drafts) – 0. Никакая из реализаций не будет воспринимать пакеты с номером версии, превышающий номер версии данной реализации.

MnVer

Показывает младшую часть номера версии используемого протокола ISAKMP. Реализации на основе RFC2408 должны использовать значение 0, а реализации на основе предварительных версий ISAKMP (Internet-Drafts) – 1. Никакая из реализаций не будет воспринимать пакеты с номером версии, превышающий номер версии данной реализации.

Тип обмена

Показывает тип используемого обмена. Это поле диктует тип сообщений и содержимого при обмене ISAKMP. Поддерживаются следующие типы:

0 None

1 Base

2 Identity Protection

3 Authentication Only

4 Aggressive

5 Informational

6-31 ISAKMP Future Use

32-239 DOI Specific Use

240-255 Private Use

Флаги

Задает опции, установленные для обмена ISAKMP.

E(ncryption) – бит 0 – указывает, что содержимое после заголовка зашифровано с использованием алгоритма, указанного в ISAKMP SA.

C(ommit) – бит 1 – сигнализирует о синхронизации обмена ключами. Этот флаг используется для того, чтобы зашифрованная информация не была получена до завершения процесса организации SA.

A(uthentication Only) – бит 2 – предназначен для использования в Informational Exchange с содержимым Notify и будет позволять передачу информации с проверкой целостности, но без шифрования.

Все остальные биты устанавливаются в нулевые значения до передачи.

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

Уникальный идентификатор протокола используется для идентификации состояния протокола в процессе согласования Phase 2 (фаза 2). Это число генерируется случайным образом инициатором согласования фазы 2. В случае одновременной организации SA (коллизия), значения этого поля будут явно отличаться, поскольку они генерируются независимо и, таким образом, две ассоциации безопасности будут находиться в процессе создания. Однако, ниоткуда не следует, что эти ассоциации будут завершены одновременно. В течение согласования фазы Phase 1 это поле должно иметь нулевое значение 0.

Размер

Размер сообщения (заголовок и содержимое) в октетах. Шифрование может расширять размер сообщения ISAKMP.

NTP

RFC1305 http://www.cis.ohio-state.edu/htbin/rfc/rfc1305.html

NTP (Network Time Protocol) представляет собой систему синхронизации компьютерных часов через сеть Internet, обеспечивающую механизм синхронизации и координацию распространения информации в больших сетях, использующих каналы с различными скоростями. Протокол использует структуру распространения информации между серверами точного времени, образующими самоорганизующуюся иерархическую структуру “ведущий-ведомый” (master-slave) для синхронизации локальных часов подсети с национальными стандартными часами по проводам или радиоканалу.

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

LI

VN

Режим

Уровень

Опрос

Точность

2

3

3

7

6

7

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

LI (Leap Indicator)

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

00 нет предупреждения.

01 +1 секунда (следующая минута содержит 61 секунду).

10 -1 секунда (следующая минута содержит 59 секунд).

11 условия тревоги (часы не синхронизированы).

VN

3-битовый код, показывающий номер версии.

Режим

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

0 зарезервировано.

1 Symmetric active (симметричный).

3 Client (клиент).

4 Server (сервер).

5 Broadcast (широковещательный).

6 NTP control message (управляющее сообщение NTP).

Уровень эталона

Целое число, показывающее уровень эталона для локальных часов:

0 не указана.

1 первичный эталон (например, радио-часы).

2…n вторичный эталон (через NTP).

Опрос

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

Точность

Целое число со знаком, показывающее точность локальных часов в виде степени числа 2.

POP3

RFC1939 http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html

Протокол POP3 (Post Office Protocol version 3) позволяет рабочим станциям динамически забирать почту с сервера. Этот протокол обычно используется рабочими станциями для получения почты с обслуживающих их почтовых серверов..

Сообщения POP3 являются командами или откликами.

RADIUS

RFC2138 http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html

RFC2139 http://www.cis.ohio-state.edu/htbin/rfc/rfc2139.html

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

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

8

16

32

Код

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

Размер

Поле аутентификации (Authenticator)

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

Код

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

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

Значение, используемое для сопоставления запросов и откликов.

Размер

Размер сообщения с учетом заголовка.

Authenticator

Поле, используемое для аутентификации откликов от сервера RADIUS и в алгоритмах сокрытия пароля.

RLOGIN

Протокол RLOGIN (Remote LOGIN – удаленный вход в систему) позволяет пользователям UNIX подключаться к системам UNIX на других машинах через сеть Internet и работать так же, как при прямом подключении терминала к машине. Этот протокол обеспечивает такой же сервис, как протокол TELNET.

RTSP

RFC2326 http://www.cis.ohio-state.edu/htbin/rfc/rfc2326.html

RTSP (Real-Time Streaming Protocol – протокол потоков в реальном масштабе времени) представляет собой протокол прикладного уровня, обеспечивающий контроль доствки данных для приложений реального времени. RTSP обеспечивает возможность эффективной, управляемой доставки по запросам данных в реальном масштабе времени для таких приложений, как видео или аудио. Источниками данных могут являться как системы сбора информации (например, видеокамеры), так и системы хранения данных (воспроизведение клипов). Этот протокол предназначен для управления множеством сеансов доставки данных за счет организации каналов доставки (таких, как UDP, multicast UDP и TCP) и обеспечения выбора механизма доставки на основе RTP.

Потоки, управляемые протоколом RTSP могут использовать RTP, но работа протокола RTSP не зависит от механизма транспортировки, используемого для передачи непрерывного потока данных. Протокол по синтаксису сделан подобным протоколу HTTP/1.1 что позволяет в большинстве случаев добавлять механизмы расширения HTTP в протокол RTSP.

Однако, RTSP в нескольких аспектах значительно отличается от протокола HTTP:

  • RTSP добавляет множество новых методов и использует другой идентификатор протокола.
  • Сервер RTSP должен по умолчанию поддерживать состояние почти во всех случаях в отличии от stateless-природы протокола HTTP.
  • Как серверы, так и клиенты RTSP могут передавать запросы.
  • Данные передаются по отдельному каналу (out-of-band) с использованием другого протокола.
  • Для протокола RTSP определено использование набора символов ISO 10646 (UTF-8) взамен ISO 8859-1, используемого в текущей версии HTML.
  • Request-URI всегда содержать абсолютные указатели URI. В силу обратной совместимости с историческими глупостями HTTP/1.1 передает в запросах только абсолютные пути, помещая имя хоста в отдельное поле заголовка.

Использование протокола RTSP упрощает создание и поддержку виртуальных серверов, где один хост с одним адресом IP обслуживает несколько структур (деревьев) документов.

SMTP

RFC821 http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html

SMTP (Simple Mail Transfer Protocol – простой почтовый протокол) представляет собой почтовый сервис, смоделированный на основе файлового сервиса FTP. SMTP обеспечивает передачу почтовых сообщений между системами и уведомления о входящей почте.

Команды

Команды SMTP представляют собой сообщения ASCII, передаваемые между хостами SMTP. Ниже приведен список поддерживаемых команд:

Команда Описание

DATA Начинает сборку (composition) сообщения.

EXPN <string> Возвращает имена из указанного списка рассылок.

HELO <domain> Возвращает идентификацию почтового сервера.

HELP <command> Возвращает информацию об указанной команду.

MAIL FROM <host> Инициирует почтовый сеанс с хоста.

NOOP Нет операций кроме подтверждений от сервера.

QUIT Прерывает почтовую сессию.

RCPT TO <user> Обозначает получателя почты.

RSET Сбрасывает (Reset) почтовое соединение.

SAML FROM <host> Передает почту на терминал пользователя и в почтовый ящик.

SEND FROM <host> Передает почту на терминал пользователя.

SOML FROM <host> Передает почту на терминал пользователя или в почтовый ящик.

TURN Меняет ролями отправителя и получателя.

VRFY <user> Проверяет идентификацию пользователя.

Сообщения

Отклики SMTP содержат код сообщения и текстовое пояснение к нему:

Код отклика Пояснение

211 (Response to system status or help request) – отклик на запрос состояния системы или справки.

214 (Response to help request) – отклик на запрос справки.

220 Mail service ready – готовность почтового сервиса.

221 Mail service closing connection – почтовый сервис закрыл соединение.

250 Mail transfer completed – передача почты завершена.

251 User not local, forward to <path> – нелокальный пользователь, использовать маршрут.

354 Start mail message, end with <CRLF><CRLF> – начало почтового сообщения, завершаемого символами <CRLF><CRLF>.

421 Mail service unavailable – почтовый сервис недоступен.

450 Mailbox unavailable – почтовый ящик недоступен.

451 Local error in processing command – локальная ошибка при обработке команды.

452 Insufficient system storage – недостаточно свободного пространства на диске.

500 Unknown command – неизвестная команда.

501 Bad parameter – некорреткный параметр.

502 Command not implemented – команда не реализована.

503 Bad command sequence – некорректная последовательность команд.

504 Parameter not implemented – параметр не реализован.

550 Mailbox not found – не найден почтовый ящик.

551 User not local, try <path> – нелокальный пользователь, нужно попробовать маршрут.

552 Storage allocation exceeded – невозможно выделить больше пространства на диске.

553 Mailbox name not allowed недопустимое имя почтового ящика.

554 Mail transaction failed – сбой при почтовой транзакции.

SNMP

RFC1157 http://www.cis.ohiostate.edu/htbin/rfc/rfc1157.html

Обзор протокола SNMP: http://service.baltnet.ru/info/CIE/Topics/108.htm

Сообщество Internet разработало протокол SNMP для того, чтобы различные объекты сетей могли участвовать в глобальной архитектуре управления сетью. Системы сетевого управления могут опрашивать (сканировать) сетевые объекты, реализующие протокол SNMP для получения информации, имеющей отношение к частной реализации системы управления сетью. Система управления сетью узнает о проблемах, получая прерывания (trap) или уведомления об изменениях от сетевых устройств, реализующих SNMP.

Формат сообщений SNMP

SNMP является сеансовым протоколом, инкапсулируемым в дейтаграммы UDP. Формат сообщений SNMP показан на рисунке.

Версия

Сообщество

PDU

Формат сообщений SNMP

Версия

Номер версии протокола SNMP. Менеджер и агент должны использовать одну версию протокола. Сообщения, содержащие идентификаторы других версий отбрасываются без обработки.

Сообщество

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

PDU

Поддерживаются пять различных типов PDU: GetRequest, GetNextRequest, GetResponse, SetRequest и Trap. Общее описание всех типов пакетов приведено ниже.

Формат PDU

Формат пакетов GetRequest, GetNext Request, GetResponse и SetRequest показан на рисунке.

Тип PDU

Идентиф. запроса

Состояние ошибки

Индекс ошибки

Объект 1, значение 1

Объект 2, значение 2

Формат SNMP PDU

Тип PDU

Задает тип PDU:

0 GetRequest.

1 GetNextRequest.

2 GetResponse.

3 SetRequest.

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

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

Состояние ошибки

Целое число, показывающее результат выполнения операции. Возможные коды результатов перечислены ниже:

0 noError: нет ошибок, корректная работа менеджера или агента.

1 tooBig: размер требуемого пакета GetResponse превышает локальные ограничения.

2 noSuchName: имя запрошенного объекта не соответствует ни одному из доступных имен MIB View.

3 badValue: запрос SetRequest имеет некорректный тип, размер или значение переменной.

4 readOnly: не определено в RFC1157.

5 genErr: прочие ошибки, не включенные в список.

Индекс ошибки

Указывает запись в переменной, с которой связана причина ошибки.

Объект/значение

Связанная пара имени и значения переменной.

Формат прерываний

Формат пакетов прерываний (Trap) показан на рисунке.

Тип PDU

Предприятие

Адрес агента

Базовый тип прерывания

Конкретный тип прерывания

Временная метка

Объект/ значение

Формат Trap PDU

Тип PDU

Показывает тип пакета (4=Trap).

Предприятие

Идентифицирует компанию-производителя, для которой определено данное прерывание.

Адрес агента

IP-адрес агента, используемый для дальнейшей идентификации.

Базовый тип прерывания

Поле описания события:

0 coldStart: передающий элемент протокола был реинициализирован с изменением конфигурации агента или реализации объекта.

1 warmStart: передающий элемент протокола был реинициализирован без изменения конфигурации агента или реализации объекта.

2 linkDown: сбой в коммуникационном канале.

3 linkUp: коммуникационный канал восстановлен.

4 authenticationFailure: агент получил от менеджера сообщение SNMP с некорректной аутентификацией (неверное имя сообщества).

5 egpNeighborLoss: Сосердний партнер EGP не работает (down).

6 enterpriseSpecific: произошло отличное от базового прерывание, идентифицированное полями Specific Trap Type (Конкретный тип прерывания) и Enterprise (Предприятие).

Конкретный тип прерывания

Используется для идентификации отличных от базовых прерываний при установке в поле Generic Trap Type (Базовый тип прерывания) значения enterpriseSpecific.

Временная метка

Значение переменной sysUpTime для объекта, представляющее промежуток времени между последней (ре)инициализацией и генерацией данного прерывания.

Объект/значение

Связанная пара имени и значения переменной.

SNMP

Пример декодирования SNMP

 

TACACS+

draft http://info.internet.isi.edu:80/in-drafts/files/draft-grant-tacacs-02.txt

RFC1492 http://www.cis.ohio-state.edu/htbin/rfc/rfc1492.html

Протокол TACACS+ обеспечивает управление доступом для маршрутизаторов, сетевых серверов доступа и других устройств на базе одного или нескольких централизованных серверов, выполняя операции аутентификации, авторизации (проверки полномочий) и ведения учета.

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

4

8

16

24

32

Старш.

Младш.

Тип пакета

Пор. номер

Флаги

Идентификатор сессии (4 байта)

Размер (4 байта)

Структура заголовка TACACS+

Старшие цифры версии

Старшие цифры номера версии протокола TACACS+.

Младшие цифры версии

Младшие цифры номера версии протокола TACACS+. Это поле используется для обеспечения обратной совместимости между различными вариантами протокола TACACS+.

Packet type

Пакеты TACACS+ могут быть следующих типов:

TAC_PLUS_AUTHEN:= 0x01 (Authentication – аутентификация).

TAC_PLUS_AUTHOR:= 0x02 (Authorization – проверка полномочий).

TAC_PLUS_ACCT:= 0x03 (Accounting – ведение учета).

Sequence number

Порядковый номер данного пакета в текущем сеансе. Первый пакет TACACS+ в сеансе должен иметь номер 1, а номера последующих пакетов должны увеличиваться на единицу. Таким образом клиент может передавать только пакеты с нечетными номерами, а демоны TACACS+ – с четными.

Флаги

Битовая маска флагов, указывающих режим шифрования пакетов.

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

Идентификатор текущего сеанса TACACS+.

Размер

Общий размер тела пакета TACACS+ (без учета заголовка).

TELNET

RFC854 http://www.cis.ohio-state.edu/htbin/rfc/rfc854.html

RFC855 http://www.cis.ohio-state.edu/htbin/rfc/rfc855.html

RFC857 http://www.cis.ohio-state.edu/htbin/rfc/rfc857.html

TELNET представляет собой протокол эмуляции терминала в стеке TCP/IP. Современные варианты TELNET обеспечивают эмуляцию практически всех функций терминалов различных типов, разработанных в течение последних 20 лет. Набор опций позволяет протоколу TELNET поддерживать передачу двоичных данных, макросы, эмуляцию графических терминалов и передачу информации для поддержки централизованного управления терминалами.

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

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

Динамическое согласование режима

Во время соединения пользователем или программой могут быть согласованы дополнительные опции, отличающиеся от опций, предлагаемых NVT. Эта задача выполняется с помощью команд, вложенных в поток передаваемых данных. Коды команд TELNET имеют размер в один или несколько октетов, перед которым располагается символ IAC (interpret as command – интерпретировать как команду), имеющий значение FF (все биты имеют значение 1). Коды команд TELNET перечислены ниже:

Команда Код Описание

Dec Hex

data ввод-вывод данных.

End subNeg 240 FO завершение команды дополнительного согласования (subnegotiation) опций.

No Operation 241 F1 нет операции.

Data Mark 242 F2 завершение неотложного потока данных.

Break 243 F3 оператор нажал клавишу Break (стоп) или Attention (внимание).

Int process 244 F4 прервать текущий процесс.

Abort output 245 F5 отказ от вывода текущего процесса.

You there? 246 F6 подтверждение запроса.

Erase char 247 F7 запрос на удаление предыдущего символа.

Erase line 248 F8 запрос на удаление предыдущей строки.

Go ahead! 249 F9 завершение ввода для полудуплексного соединения.

SubNegotiate 250 FA начало дополнительного согласования (subnegotiation) опций.

Will Use 251 FB согласие на использование указанной опции.

Won’t Use 252 FC отказ от предложенной опции.

Start use 253 FD отказ от начала использования указанной опции.

Stop Use 254 FE запрос на прекращение использования указанной опции.

IAC 255 FF интерпретировать как команду.

Каждая согласуемая опция имеет идентификатор, следующий непосредственно за командой согласования опции (IAC, команда, код опции). Ниже приведен список кодов опций TELNET:

ID Коды Описание

Dec Hex

0 0 Binary Xmit разрешить передачу бинарных данных.

1 1 Echo Data заставляет сервер передавать эхо-символы.

2 2 Reconnect подключение к другому хосту TELNET.

3 3 Suppress GA запрет команды Go Ahead!.

4 4 Message Sz указывает приблизительный размер сообщения.

5 5 Opt Status перечисляет состояния опций.

6 6 Timing Mark маркирует положение в потоке данных для ссылок.

7 7 R/C XmtEcho удаленное управление терминальными принтерами.

8 8 Line Width установка ширины строки вывода.

9 9 Page Length установка числа строк на странице вывода.

10 A CR Use определяет обработку символов возврата каретки.

11 B Horiz Tabs устанавливает горизонтальную табуляцию.

12 C Hor Tab Use определяет обработку символов горизонтальной табуляции.

13 D FF Use определяет обработку символов перевода страницы.

14 E Vert Tabs устанавливает вертикальную табуляцию.

15 F Ver Tab Use определяет обработку символов вертикальной табуляции.

16 10 Lf Use определяет обработку символов перевода строки.

17 11 Ext ASCII определяет расширенные символы ASCII.

18 12 Logout разрешает форсированный выход (log-off).

19 13 Byte Macro определяет байтовый макрос.

20 14 Data Term разрешает передавать субкоманды для Data Entry.

21 15 SUPDUP позволяет использовать протокол отображения SUPDUP.

22 16 SUPDUP Outp позволяет передавать вывод SUPDUP.

23 17 Send Locate позволяет передавать местоположение терминала.

24 18 Term Type разрешает обмен информацией о типе терминала.

25 19 End Record разрешает использовать код завершения записи (End of record – 0xEF).

26 1A TACACS ID используется обмен идентификаторами пользователей для предотвращения множественного входа в систему (log-in).

27 1B Output Mark позволяет передавать на устройство вывода баннерные маркеры.

28 1C Term Loc# для идентификации терминала используется цифровое значение (numeric ID).

29 1D 3270 Regime разрешает эмуляция семейства терминалов 3270.

30 1E X.3 PAD разрешает использование эмуляции протокола X.3.

31 1F Window Size передает размер окна для экрана эмуляции.

32 20 Term Speed передает информацию о скорости.

33 21 Remote Flow обеспечивает управление потоком (XON, XOFF).

34 22 Linemode поддержка транзакций linemode bulk character.

255 FF Extended options list список расширенных опций.

X-Window

RFC1013 http://www.cis.ohio-state.edu/htbin/rfc/rfc1013.html

Протокол X-Window обеспечивает удаленный оконный интерфейс для распределенных сетевых приложений. Это протокол уровня приложений, использующий в качестве транспортного протокола TCP/IP или DECnet.

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

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

Кадры запросов и откликов

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

Команда Описание

BackRGB Фоновый цвет в форме значений красной, зеленой и синей компонент.

BackPM Пиксельная маска (Pixel map) фона.

BellPitch звуковой сигнал (Bell pitch).

BellVol Уровень звукового сигнала в процентах.

BM Битовая маска отображаемого элемента.

BordPM Маска границы (Border pixel map), используемая для окна.

b Ширина границы отображаемого элемента.

Click Уровень звука при нажатии клавиш в процентах.

Ord Click order. Drawable clip order – <Unsorted>, <Y-sorted>, <YX-sorted> или <YX-banded>.

CMap Отображение цветов (Color map) для рисуемых элементов.

CID Идентификатор контекста (Context ID) для частного графического контекста.

Cur Курсор – код цвета курсора

d Текущая глубина окна.

DD Отображаемый элемент (Destination drawable) в виде растра.

D Отображаемый элемент (Drawable) – код, служащий для идентификации окна или растра.

Exp Отображаемый элемент (Exposure), выводимый в настоящее время.

Fam Используемое семейство протоколов (Internet, DECnet, CHAOSnet).

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

Font(a,d) Вертикальные границы шрифта (Font ascent/descent).

ForeRGB Цвет вывода (Foreground color) в форме красной, зеленой и синей компонент.

Fmt Формат текущего окна.

GC Графический контекст – код, используемый для идентификации частного графического определения.

h Высота отображаемого элемента.

Key Код клавиши.

KeySym Код, служащий для обозначения семейства используемых кодов клавиш.

MinOp Рабочий код X-Windows (младшая часть).

MajOp Рабочий код X-Windows (старшая часть).

N Число отображаемых элементов списка.

P Родительское окно текущего окна.

PixMap Растр – код используемый для идентификации фрагмента растра.

p Плоскость – используемая битовая плоскость.

PM Маска битовой плоскости, связанной с отображаемым элементом.

Prop Принадлежность (Property) – указывает принадлежность окна.

SW Дочернее окно, произведенное данным окном.

SD Отображаемый элемент в форме растровой копии.

T/O Время активизации программы сохранения экрана (Screen saver).

Typ Тип текущего окна.

w Ширина отображаемого элемента.

W Окно – код используемый для идентификации частного окна.

X X-координата для отображаемого элемента.

Y Y- координата для отображаемого элемента.

Кадры событий

Кадры событий могут содержать следующие команды:

Команда Описание

Btn Нажата числовая клавиша.

C Дочернее окно, связанное с событием.

F Флаги событий – набор флагов отображаемых символами верхнего (активный флаг) или нижнего (неактивный флаг) регстра:

f,F фокус вода относится к событию.

s,S события на одном экране.

E(x,y) Местоположение события – координаты X и Y, связанные с событием.

E Окно, в котором произошло событие.

Key Номер нажатой клавиши.

O Владелец окна, связанного с событием.

R Корневое окно, связанное с событием.

R(x,y) Координаты X и Y для корневой позиции.

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




Протоколы коммутации тегов

В этой главе описаны два протокола коммутации тегов:

  • TDP – Tag Distribution Protocol (протокол распределения тегов);
  • MPLS – Multi Protocol Label Switching (мультипротокольная коммутация меток).

TDP

IETF draft-doolan-tdp-spec-01

TDP (Tag Distribution Protocol – протокол распределения тегов) представляет собой двухкомпонентный протокол, работающий поверх транспортного протокола с организацией соединений и гарантированным соблюдением порядка доставки. Маршрутизаторы с коммутацией тегов используют этот протокол для обмена связанной с тегами информацией со своими партнерами (peer). Протокол TDP поддерживает множество протоколов сетевого уровня (IPv4, IPv6, IPX, AppleTalk и т. д.). Маршрутизаторы с коммутацией тегов (Tag Switching Routers – TSR) создают связи тегов, а затем передают информацию о таких связях другим маршрутизаторам TSR. Протокол TDP обеспечивает для маршрутизаторов TSR средства распространения, запроса и удаления информации о связях тегов различными протоколами сетевого уровня. TDP также обеспечивает средства организации, мониторинга и закрытия сессий TDP, а также может сообщать об ошибках, происходящих в ходе сессии. В качестве транспортного протокола для TDP используется протокол TCP.

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

2 байта

2 байта

Версия

Размер

Идентификатор TDP (2 байта)

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

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

Версия

Номер версии протокола.

Размер

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

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

Уникальный идентификатор маршрутизатора TSR, передавшего данный PDU.

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

Поле зарезервировано.

MPLS

IETF http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt

Многопротокольная коммутация меток (Multi Protocol Label Switching – MPLS) представляет собой набор процедур, служащих для добавления “стека меток” в пакеты сетевого уровня. Протокол определяет кодирование, используемое маршрутизаторами с коммутацией меток для передачи по каналам PPP или ЛВС. Этот протокол добавляет специальные метки в пакеты сетевого уровня для протоколов IP и IPv6 после заголовков канального уровня и перед заголовками сетевого уровня. Размер меток составляет от 4 до 8 байтов.

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

Биты

1

2

3

4

5

6

7

8

Метка

(20 битов)

CoS

S

TTL

Стек меток MPLS

Метка

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

CoS

Class of Service – класс обслуживания. Значение этого поля используется алгоритмами планирования и отбрасывания пакетов для приоритизации трафика в сети.

S

“Дно стека” – 1-битовый флаг, устанавливаемый для последнего элемента в стеке меток и имеющий нулевое значение для остальных элементов.

TTL

8-битовое поле, задающее время жизни пакета.




Протоколы SUN

Протоколы SUN являются приложениями операционной системы UNIX, использующими TCP/IP в качестве транспортного протокола. Эти протоколы базируются на сетевой модели клиент-сервер, в которой приложения-клиенты передают запросы сетевым серверам, на которых размещаются серверные приложения. Стек SUN включает следующие протоколы:

  • MOUNT

  • NFS Network File System

  • PMAP Port Mapper

  • RPC Remote Procedure Call

  • YP (NIS) Yellow Pages (Network Information Service)

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

gif_26

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

MOUNT

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

Кадры

Типы кадров, поддерживаемых протоколом MOUNT перечислены ниже:

[no operations] Нет операции

[add mount entry] Запрос дескриптора файла для NFS

[get all mounts] Запрос перечня смонтированных для клиента устройств

[del mount entry] Запрос на удаление смонтированного устройства

[del all mounts] Запрос на удаление всех смонтированных для клиента устройств

[get export list] Запрос групповых прав для смонтированных устройств

[mount added] Возвращает дескриптор файла для использования с NFS

[give all mounts] Возвращает список смонтированных устройств для клиента

[mount deleted] Подтверждение операции удаления смонтированного устройства

[mounts deleted] Подтверждение операции удаления всех смонтированных устройств клиента

[give export list] Список групповых прав для смонтированных устройств.

Параметры кадра

Параметры кадров протокола MOUNT рассмотрены ниже.

Имя маршрута

Имя маршрута на сервере для смонтированного каталога (имя выводится в двойных кавычках).

Дескриптор файла

32-байтовый дескриптор файла, используемый для доступа к смонтированному каталогу.

Сбой при монтировании в системе UNIX может привести к выводу на экран сообщения об ошибке UNIX Error xxxx, где xxxx показывает стандартный код ошибки UNIX.

NFS

Протокол NFS (Network File System – сетевая файловая система) служит средством разделения файлов для стека протоколов SUN. NFS позволяет представлять клиентам распределенные файловые ресурсы сети как единую файловую системы. UNIX (Sun OS) является стандартной платформой для NFS, однако компания Sun разработала процедуры доступа к файлам таким образом, что стало возможным использование NFS для широкого круга операционных систем и протоколов.

Кадры

Протокол NFS поддерживает кадры следующих типов:

[no operations] Нет операции

[get file attrib] Запрос атрибутов файла

[set file attrib] Попытка установить атрибуты файла

[get filesys root] Запрос дескриптора корневого файла

[search for file] Запрос на поиск определенного файла

[read from link] Запрос на чтение из символьной ссылки

[read from file] Запрос на чтение из файла

[write to cache] Запрос на запись в кэш

[write to file] Запрос на запись в файл

[create file] Запрос на создание указанного файла

[delete file] Запрос на удаление файла

[rename file] Запрос на переименование файла

[link to file] Запрос на создание файловой ссылки

[make symb link] Запрос на создание символьной ссылки

[make directory] Запрос на создание каталога

[remove directory] Запрос на удаление каталога

[read directory] Запрос на просмотр каталога

[get filesys attrib] Запрос информацию о файловой системе

[give file attrib] Запрос атрибутов файла

[file attrib set] Подтверждение установки атрибутов файла

[filesystem root] Возвращает дескриптор корневого файла

[file search done] Возвращает результат поиска файла

[link read done] Возвращает результат чтения символьной ссылки

[file read done] Возвращает результат чтения файла

[cache write done] Возвращает результат записи в кэш

[file write done] Возвращает результат записи в файл

[create file rep] Возвращает результат создания файла

[delete file rep] Возвращает результат удаления файла

[rename file rep] Возвращает результат переименования файла

[link file reply] Возвращает состояние файловой ссылки

[symb link made] Возвращает состояние символьной ссылки

[make dir reply] Возвращает результат создания каталога

[remove dir reply] Возвращает результат удаления каталога

[dir read done] Возвращает результат просмотра каталога

[filesystem attrib] Возвращает атрибуты файловой системы.

Параметры кадра

Кадры NFS могут содержать следующие параметры:

Дескриптор файла

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

Количество

Число байтов, записанных или прочитанных при файловой операции.

Смещение

Начальное смещение в файле для операции чтения или записи.

Тип файла

Включает следующие типы файлов:

NON Non-file (не файл)

REG Regular file (обычный файл)

DIR Directory (каталог)

BLK Block device (блочное устройство)

CHK Character device (символьное устройство)

LNK Symbolic link (символьная ссылка)

Режим

Режим доступа к файлу представляется четырьмя полями Mode/Owner/Group/Others (режим/владелец/группа/прочее) и может включать следующие значения:

Поле Параметр Описание
Режим

U

Исполняемый указанным пользователем.

G

Исполняемый указанной группой.

S

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

R

Чтение.

W

Запись/удаление.

X

Исполнение/поиск.
Группа

r

Чтение.

w

Запись/удаление.

x

Исполнение/поиск.
Прочие

r

Чтение.

w

Запись/удаление.

x

Исполнение/поиск.
Ссылки (links)

Количество ссылок типа hard или имен для файла.

Размер

Размер файла в байтах.

Блок

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

Идентификатор файловой системы

Идентификационный код файловой системы.

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

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

Указатель

Указатель на первый элемент в запрошенном списке каталога.

Максимум

Максимальное количество элементов, возвращаемых по данному запросу.

Устройство чтения

Для символьных или блочных устройств чтение из группы устройств.

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

Кадры откликов

Кадры откликов протокола NFS содержат информацию о состоянии операции. Возможные значение этого параметра перечислены ниже:

{OK} Завершено без ошибок

{Ownership required} Для операции требуется права на владение

{File/dir not found} Файл или каталог не найден

{Device error} Системная или аппаратная ошибка

{Device/addr not found} Ошибка в адресе устройства или ввода-вывода

{Insuff access rights} Недостаточные права доступа

{File/dir already exists} Дублирование файла или каталога

{Device not found} Ошибка доступа к устройству

{Not a directory} Операция может проводится только с каталогом

{Invalid dir operation} Операция не может быть проведена с каталогом

{File too large} Размер файла слишком велик

{Out of disk space} Недостаток пространства на файловом устройстве

{Write protect violation} Файловая система поддерживает режим «только чтение»

{Filename too long} Слишком длинное имя файла

{Directory not empty} Каталог не является пустым

{Disk quota exceeded} Превышен размер дискового пространства для пользователя

{Invalid file handle} Неправильный дескриптор файла

{Write cache was flushed} Кэш записи сброшен на диск

{Unknown error} Неизвестная ошибка.

PMAP

Протокол PMAP (Port Mapper – отображение портов) обеспечивает выделение портов транспортного уровня серверным приложениям. Серверные приложения получают номер порт, запрашивая его выделение. Клиенты, желающие получить доступ к сетевым приложениям, сначала вызывают процедуры PMAP (используя известный – well-known – порт) для получения номера транспортного порта, выделенного для приложения. Затем клиент обращается к приложению напрямую, используя полученный номер порта. Использование протокола PMAP избавляет от необходимости постоянного выделения порта для каждого приложения. При использовании такой схемы требуется постоянное выделение порта только для протокола PMAP.

Кадры

Протокол PMAP может использовать кадры следующих типов:

[no operations] Нет операции

[set port number] Попытка регистрации приложения

[unset port numb] Попытка отмены регистрации приложения

[get port number] Запрос зарегистрированного номера порта

[get all ports] Запрос всех зарегистрированных портов

[call program] Непосредственный вызов зарегистрированного приложения

[port assigned] Регистрация связи приложения с портом

[port unassigned] Отмена регистрации приложения

[give port number] Информирует клиента зарегистрированного порта

[give all ports] Информирует клиентов всех зарегистрированных портов

[program called] Возвращает информацию от вызываемой программы.

Параметры кадра

Кадр PMAP может содержать следующие параметры:

Транспортный порт

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

Номер программы

Номер прикладной программы.

Версия программы

Номер версии программы.

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

Транспортный протокол, зарегистрированный для использования программой.

Процедура

Номер процедуры в вызываемой программе.

Если номер программы не зарегистрирован, выводится сообщения {Program is unregistered} (Программа не зарегистрирована).

RPC

RFC 1057 http://www.cis.ohio-state.edu/htbin/rfc/rfc1057.html

RPC (Remote Procedure Call – удаленный вызов процедуры) является протоколом сеансового уровня, который использует язык XDR для удаленного вызова процедур. Вызов (сообщение) протокола RPC включает параметры процедуры, а отклик – результаты работы процедуры. После получения отклика из сообщения извлекаются результаты, которые используются в программе, вызвавшей процедуру.

Протокол поддерживает два типа сообщений – вызов и отклик. Формат этих сообщений показан на рисунках.

32

64

Октеты

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

Тип сообщения

8

Версия RPC

Программа

16

Версия

Процедура

24

Тело вызова RPC

Структура вызова RPC

32

64

Октеты

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

Тип сообщения

8

Состояние

16

Тело отклика RPC

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

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

Номер транзакции.

Тип сообщения

Тип сообщения.

Версия RPC

Номер версии используемого протокола RPC.

Программа

Имя удаленной программы. Программы могут идентифицироваться по номерам, а для известных (well-known) программ – по именам. Предопределенные номера программ и их имена приведены в списке.

Номер Программа Описание

100000 Port_Mapper Управляет использованием транспортных портов

100001 RemoteStats Удаленная статистика

100002 RemoteUser Удаленные пользователи

100003 NFS Сетевая файловая система

100004 YellowPages Служба каталогов «желтые страницы»

100005 MountDaemon Протокол монтирования

100006 Remote_DBX Удаленный DBX

100007 YP_Binder Сервис привязки «желтых страниц»

100008 Shutdown Сообщения выключения

100009 YP_Password Сервер паролей «желтых страниц»

100010 Enet_Status Состояние Ethernet

100011 Disk_Quotas Менеджер “квотирования” диска

100012 SprayPacket Генератор пакетов

100013 3270_Mapper Сервис отображения 3270

100014 RJE Mapper Сервис отображения удаленных заданий

100015 Select_Srvc Сервис выбора

100016 Remote_DB Доступ к удаленным базам данных

100017 Remote_Exec Удаленное исполнение

100018 Alice_O/A Программа автоматизации офиса Alice

100019 Scheduler Планировщик

100020 Local_Lock Менеджер локальной блокировки

100021 NetworkLock Менеджер сетевой блокировки

100022 X.25_INR Протокол X.25 INR

100023 SatusMon_1 Монитор состояния 1

100024 SatusMon_2 Монитор состояния 2

100025 SelectLib Библиотека выбора

100026 BootService Сервис параметров загрузки

100027 Mazewars Игра mazewars

100028 YP_Update Сервис обновления «желтых страниц»

100029 Key_Server Сервер ключей

100030 SecureLogin Сервис безопасного входа в систему

100031 NFS_FwdInit Сервис пересылки NFS.

100032 NFS_FwdTrns Передатчик данных NFS

100033 SunLink_MAP SunLink MAP

100034 Net_Monitor Сетевой монитор

100035 DataBase “Облегченная” база данных

100036 Passwd_Auth Авторизация по паролю

100037 TFS_Service “Полупрозрачный” файловый сервис

100038 NSE_Service Сервер NSE

100039 NSE_Daemon Процесс активизации NSE

150001 PCPaswdAuth Авторизация с помощью пароля для ПК

200000 PyramidLock Сервис блокировки Pyramid

200001 PyramidSys5 Сервис Pyramid Sys5

200002 CADDS_Image Образы CV CADDS

300001 ADTFileLock Сервис блокировки файлов ADT.

Версия

Номер версии удаленной программы.

Процедура

Используемая удаленная процедура.

Состояние

С помощью данного поля идентифицируются сообщения об ошибках.

Тело сообщения

Кадры откликов RPC могут содержать следующие сообщения:

{call successful} Вызов завершен без каких-либо ошибок.

{program unknown} Номер программы не найден.

{bad program ver} Версия программы не найдена.

{proced unknown} Процедура не найдена.

{bad parameters} Неправильные параметры вызова.

{bad RPC version} Неподдерживаемая версия RPC.

{bad credentials} Обнаружены неправильные параметры вызова.

{restart session} Запрос на начало новой сессии.

{bad verifier} Обнаружен неправильный параметр проверки.

{verify rejected} Действие параметра проверки закончилось по времени или было использовано заново.

{failed security} Вызывающая сторона имеет недостаточные привилегии.

YP (NIS)

Протокол YP (Sun Yellow Pages – Желтые страницы), в настоящее время используемый под именем NIS (Network Information Service – сетевой информационный сервис), является службой каталогов, используемой для поиска имен. Каждая база данных YP содержит пары ключ-значение, отображения и имена доменов. Ключ является индексом – именем, по которому YP отображает значения (например, телефонный номер). Поскольку ключи и связанные с ними (отображаемые) значения могут быть произвольными строками байтов, сервер YP может содержать различные базы данных.

YP определяет набор пар ключ-значение как «отображение». Каждое отображение относится к домену, который, в свою очередь, является категорией отображения. Такая иерархия пар ключ-значение, отображений и доменов обеспечивает общую структуру модели построения баз данных.

Дополнительной компонентой сервера баз данных YP является сервер YP-связывания (YPbind). Протокол YP использует серверы YP-связывания для обеспечения потенциальных клиентов адресной информацией о серверах, содержащих базы данных YP (YP-серверы). Клиент, желающий получить доступ к YP-серверу, может обратиться к сервису YP-связывания, используя имя домена. В ответ он получит IP-адрес и номер транспортного порта YP-сервера для запрошенного домена. Если для клиента существует более простой способ получения такой информации, сервис YP-связывания становится ненужным.

Кадры

Кадры YP и YPbind могут содержать следующие команды:

[no operations] Нет операции

[domain serviced query 1] Вопрос о поддержке обслуживания указанного домена

[domain serviced query 2] Запрос для серверов, обслуживающих указанный домен

[get key value] Запрос значения, связанного с указанным ключом

[get first key pair] Запрос первой пары ключ-значение в отображении

[get next key pair] Запрос следующей пары ключ-значение в отображении

[transfer map] Запрос на передачу новой копии отображения

[reset YP server] Запрос к YP-серверу на сброс его внутреннего состояния

[get all keys in map] Запрос на все пары ключ-значение в указанном отображении

[get map master name] Запрос имени основного сервера баз данных YP

[get map number] Запрос времени создания указанного отображения

[get all maps] Запрос всех отображений в указанном домене

[domain serve reply 1] Отклик на команду domain serviced query 1

[give key value] Возвращает значение указанного ключа.

[give first key pair] Возвращает первую пару ключ-значение в отображении

[give next key pair] Возвращает следующую пару ключ-значение в отображении

[map transferred] Отчет о состоянии передачи отображения

[YP server reset] Отчет о состоянии сброса сервера

[give all keys in map] Возвращает перечень всех ключей в отображении

[give map master name] Возвращает имя основного YP-сервера

[give map number] Возвращает дату создания отображения

[give all maps] Возвращает перечень всех отображений в домене

[no operations] Нет операции

[get current binding] Запрос адресной информации YP для указанного домена.

[set current binding] Установка адресной информации YP для указанного домена.

[give current binding] Возвращает адресную информацию YP для домена.

[domain binding set] Возвращает статус установки YP-адресации.

Параметры кадров

Кадры YP и YPbind могут содержать следующие параметры:

Адрес сервера связывания

IP-адрес сервера YP-связывания.

Связанный порт

Транспортный порт, используемый сервером YP-связывания.

Время создания

Время создания отображения.

Домен

Используемое имя домена.

Ключ

Ключ, используемый для поиска значения.

Отображение

Имя используемого отображения.

Основной сервер

Имя основного YP-сервера.

Партнер (peer)

Имя YP-сервера того же уровня (партнера).

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

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

Программа

Номер программы RPC, используемой для передачи отображения.

Порт

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

Значение

Значение, связанное с ключом.

Статус

Статус передачи отображения.

Версия

Версия протокола YPbind.

Кадры откликов

Кадры откликов YP могут содержать следующие сообщения:

{OK} Запрос завершен успешно

{Bad request arguments} Некорректные параметры запроса.

{Domain not supported} Домен не поддерживается указанным YP-сервером.

{General failure} Неуказанная ошибка

{Invalid operation} Некорректный запрос

{No more entries in map} В отображении больше нет пар ключ-значение

{No such map in domain} Указанное отображение отсутствует в домене

{No such key in map} Указанный ключ отсутствует в отображении

{Server database is bad} База данных сервера повреждена

{YOP server error} Внутренняя ошибка YP-сервера

{YP version mismatch} Несоответствие версии YP-сервера

Кадры откликов YPbind могут содержать следующие сообщения:

{OK} Запрос завершен успешно

{Internal error} Локальная ошибка сервера YP-связывания

{No bound server for domain} Для домена неизвестны YP-серверы

{Can’t alloc system resource} Ошибка ресурсов YP-связывания.

Кадры статуса передачи

Кадры статуса передачи YPbind могут содержать следующие сообщения:

{Transfer successful} Передача завершена успешно

{Bad request arguments} Некорректные параметры запроса

{Can’t clear YP server} Невозможно сбросить YP-сервер

{Can’t find server f/map} Не найден YP-сервер для отображения

{Can’t get master addr.} Невозможно получить адрес основного YP-сервера

{Domain not supported} Домен не поддерживается YP-сервером

{Local database failure} Ошибка базы данных локального YP-сервера

{Local file I/O error} Ошибка ввода/вывода на локальном YP-сервере

{Map version mismatch} Искажение версии отображения при передаче

{Master dbase not newer} Основная база данных не содержит последних изменений

{Must override defaults} Необходимо изменить принятые по умолчанию установки

{Resource alloc failure} Ошибка выделения ресурсов

{RPC to server failed} Нет RPC-отклика от сервера

{Server/map dbase error} Ошибка YP-сервера или базы данных отображений

{Server refused transfer} Отказ YP-сервера от передачи базы данных

{YP transfer error} Ошибка в процессе передачи базы данных.




Стек SS7

Спецификация SS7 (Signalling System 7 – система сигнализации №7, ОКС7) была разработана CCITT. SS7 представляет собой общеканальную систему сигнализации. Это означает, что один из каналов используется для передачи сигнальной информации, независимо от количества поддерживаемых каналов передачи данных. Аппаратные и программные функции протокола SS7 поделены на уровни, близкие уровням эталонной модели OSI.

  • MTP-2 Message Transfer Part Level 2

  • MTP-3 Message Transfer Part Level 3

  • SCCP Signalling Connection Control Part

  • DUP Data User Part

  • ISUP ISDN User Part

  • TUP Telephone User Part

  • TCAP Transaction Capabilities Application Part

  • MAP Mobile Application Part

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

gif_26

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

MTP-3

Q.704 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q704_27792.html

Протокол MTP-3 (Message Transfer Part Level 3 – сеть сигнализации, уровень 3) служит для подключения Q.SAAL к пользователям. MTP-3 передает сообщения между узлами сигнальной сети. Протокол обеспечивает надежную передачу сообщений даже при возникновении сбоев на сигнальных линиях или узлах транзитной передачи. Следовательно, протокол включает функции и процедуры, необходимые как для информирования удаленных узлов сигнальной сети о происходящих сбоях, так и для изменения маршрутизации сообщений в сигнальной сети.

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

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

Поле субсервиса

4 бита

4 бита

Структура заголовка MTP-3

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

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

  • Управляющие сообщения сигнальной сети.
  • Сообщения тестирования и поддержки сигнальной сети.
  • SCCP (подсистема управления сигнальными соединениями).
  • Пользовательская часть телефонии.
  • Пользовательская часть ISDN
  • Передача данных
  • Зарезервировано для MTP-тестирования пользовательской части.
Поле субсервиса

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

MTP-2

Q.703 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q703_24110.html

ANSI T1.111 199

MTP-2 (Message Transfer Part Level 2 – звено сигнализации, уровень 2) представляет собой сигнальный канал, совместно с MTP-3 обеспечивающий гарантированную передачу сообщений сигнализации между двумя непосредственно соединенными точками сигнализации.

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

Биты

7

8

Флаг

BSN (7 битов)

BIB

FSN (7 битов)

FIB

LI (6 + 2 бита)

SIO

SIF

Контрольная сумма (16 битов)

Флаг

 

Формат заголовка MTP-2

BSN

Обратный порядковый номер (backward sequence number), используемый для подтверждения приема сигнальных сообщений от удаленной стороны сигнального канала.

BIB

Обратный бит индикации (backward indicator bit). Прямой и обратный биты индикации совместно с прямым и обратным порядковыми номерами используются функциями контроля ошибок для проверки корректности порядка передачи сигнальных сообщений и подтверждения приема сообщений.

FSN

Прямой порядковый номер (forward sequence number).

FIB

Прямой бит индикации.

LI

Индикатор длины (length indicator) указывает количество октетов, следующих за этим индикатором.

SIO

Октет сервисной информации (service information octet).

SIF

Поле сигнальной информации (signalling information field).

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

Каждый сигнальный элемент имеет 16-битовую контрольную сумму, используемую для обнаружения ошибок.

SCCP

Q.713 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q713_23786.html

ANSI T1.112

Протокол SCCP (Signalling Connection Control Part – управление сигнальными соединениями) обеспечивает дополнение к сервису уровня MTP-3, позволяющее поддерживать сервис с организацией прямых соединений (connection-oriented) или без них (connectionless), а также реализовать возможности трансляции. SCCP совместно с MTP-3 обеспечивают реализацию функций сетевого уровня модели OSI.

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

Октеты

Метка маршрутизации

3-4

Код типа сообщения

1

Обязательная часть фиксированного размера

Обязательная часть переменного размера

Необязательная часть

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

Метка маршрутизации

Стандартная метка маршрутизации.

Код типа сообщения

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

Ниже приведены возможные значения кодов типа сообщения:

CR Connection Request (запрос соединения)

CC Connection Confirm (подтверждение соединения)

CREF Connection Refused (отказ от соединения)

RLSD Release (разъединение)

RLC Release Complete (завершение разъединения)

DT1 Data Form 1 (данные, форма 1)

DT2 Data Form 2 (данные, форма 2)

AK Data Acknowledgement (подтверждение данных)

UDT Unidata

UDTS Unidata Service

ED Expedited Data (“ускоренные” данные)

EA Expedited Data Acknowledgement (подтверждение «ускоренных» данных)

RSR Reset Request (запрос сброса)

RSC Reset Confirm (подтверждение сброса)

ERR Protocol Data Unit Error (ошибка PDU)

IT Inactivity Test (проверка отсутствия активности)

XUDT Extended Unidata

XUDTS Extended Unidata Service

Обязательная часть фиксированного размера

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

Обязательная часть переменного размера

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

Необязательная часть

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

DUP

ITU-T recommendation X.61 (Q.741)

http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.html

Протокол DUP (Data User Part – пользовательские данные) определяет элементы, необходимые для управления вызовами, регистрации и отказа в международной общеканальной сигнализации при использовании SS7 в качестве сервиса передачи данных на основе коммутации устройств. Сигнальные сообщения делятся на две категории:

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

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

Биты

8

14

16

28

32

DPS

OPC

BIC

BIC

TSC

HC

Параметры

 

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

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

Биты

8

14

16

28

32

DPS

OPC

Резерв

HC

Параметры

 

Структура сообщений, относящихся к процессам регистрации и отмены

Метка маршрутизации

Метки содержатся в сигнальных сообщениях и используются протоколом DUP для идентификации процесса, к которому относится сообщение. Метки используются также при передаче сообщений (message transfer part) для маршрутизации сообщений в направлении адресатов. Метка маршрутизации содержит поля DPS, OPC, BIC и TSC.

DPS

Код точки назначения (Destination Point code).

OPC

Код точки-отправителя (Originating Point Code).

BIC

Код идентификации владельца (Bearer Identification Code).

TSC

Код временного интервала (Time Slot Code).

HC

Код заголовка (heading code), содержащий код типа сообщения, который обязателен для всех типов сообщений. HC уникально идентифицирует назначение и формат каждого сообщения DUP.

Параметры

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

Резерв

Это поле не используется и должно иметь значение 0000.

ISUP

Q.763 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html

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

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

Октеты

Метка маршрутизации

3-4

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

2

Код типа сообщения

1

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

Обязательная часть переменного размера (параметры)

Необязательная часть (параметры)

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

Метка маршрутизации

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

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

Выделение идентификаторов отдельным каналам определяется двухсторонним соглашением (между участниками соединения) и/или в соответствии с применимыми предопределенными правилами.

Код типа сообщения

Однооктетное обязательное поле для всех сообщений. Код типа сообщения однозначно определяет назначение и формат каждого сообщения ISUP. Ниже приведены возможные значения этого поля.

  • Address complete
  • Answer
  • Blocking
  • Blocking acknowledgement
  • Call progress
  • Circuit group blocking
  • Circuit group blocking acknowledgement
  • Circuit group query @
  • Circuit group query response @
  • Circuit group reset
  • Circuit group reset acknowledgement
  • Circuit group unblocking
  • Circuit group unblocking acknowledgement
  • Charge information @
  • Confusion
  • Connect
  • Continuity
  • Continuity check request
  • Facility @
  • Facility accepted
  • Facility reject
  • Forward transfer
  • Identification request
  • Identification response
  • Information @
  • Information request @
  • Initial address
  • Loop back acknowledgement
  • Network resource management
  • Overload @
  • Pass-along @
  • Release
  • Release complete
  • Reset circuit
  • Resume
  • Segmentation
  • Subsequent address
  • Suspend
  • Unblocking
  • Unblocking acknowledgement
  • Unequipped CIC @
  • User Part available
  • User Part test
  • User-to-user information
Параметры

Каждый параметр имеет имя размером в один октет. Размер параметра может быть фиксированным или переменным и для каждого параметра может включаться индикатор длины.

ISUP

Пример декодирования ISUP

TUP

ITU-T recommendation Q.723

http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html

Протокол TUP (Telephone User Part – телефония, пользовательская часть) ОКС7 передает сигнальные элементы по каналам сигнализации. Сигнальная информация в каждом сообщении содержит соответствующие сигналы, собранные в октеты. Сообщение содержит метку, код заголовка, а также один или несколько сигналов и/или индикаторов. Каждый из перечисленных элементов описан ниже.

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

Биты

DPC

14

OPC

14

CIC

12

 

Формат метки TUP

DPC

Код точки назначения (destination point code), указывающий точку в системе сигнализации, для которой предназначено данное сообщение.

OPC

Код точки отправления (originating point code), указывающий точку в системе сигнализации, отправившую данное сообщение.

CIC

Код идентификации канала (circuit identification code) указывает голосовой канал, непосредственно соединяющий точки назначения и отправления.

Код заголовка состоит из двух частей – H0 и H1. H0 идентифицирует указанную группу сообщений, а H1 содержит код сигнализации или (для более сложных сообщений) идентифицирует формат этих сообщений.

TCAP

ITU-T recommendation Q.773

http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q773_24880.html

Протокол TCAP (Transaction Capabilities Application Part – управление транзакциями) обеспечивает возможность реализации интеллектуальных сетевых услуг посредством поддержки обмена информацией между сигнальными точками, использующими сервис SCCP, без организации прямых соединений. Сообщения TCAP содержатся в MSU (SCCP-часть). Сообщение TCAP включает в себя две части – транзакция и компонента.

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

Тег

Длина

Содержимое

 

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

Информационный элемент

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

Тег

Тег служит для разделения информационных элементов и определяет интерпретацию компонент. Размер тега может составлять один или несколько октетов. Поле тега состоит из кодов класса, формы и тега.

Длина

Указывает размер поля содержимого.

Содержимое

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

Типы пакетов TCAP

Существуют следующие типы пакетов TCAP.

Unidirectional (однонаправленный)

Query with permission (запрос с разрешением)

Query without permission (запрос без разрешения)

Response (отклик)

Conversation with permission (диалог с разрешением)

Conversation without permission (диалог без разрешения)

Abort (прерывание)

MAP

EIA/TIA-41 http://www.tiaonline.org

Сообщения MAP (Mobile Application Part – мобильные приложения) передаются между мобильными коммутаторами и базами данных для поддержки аутентификации пользователей, идентификации оборудования и роуминга. Сообщения MAP передаются с помощью протокола TCAP в мобильных сетях (IS-41 и GSM). Когда пользователь мобильной связи перемещается в зону обслуживания другого мобильного центра коммутации MSC (mobile switching center), встроенный регистратор местоположения пользователей запрашивает регистрационную информацию у регистратора, к которому приписан данный пользователь (home location register – HLR). Для таких запросов используется информация MAP, передаваемая в сообщениях TCAP.

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

Биты

8

16

Тип операции

Длина

Информационные элементы

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

Тип операции

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

  • AuthenticationDirective
  • AuthenticationDirectiveForward
  • AuthenticationFailureReport
  • AuthenticationRequest
  • AuthenticationStatusReport
  • BaseStationChallenge
  • Blocking
  • BulkDeregistration
  • CountRequest
  • FacilitiesDirective
  • FacilitiesDirective2
  • FacilitiesRelease
  • FeatureRequest
  • FlashRequest
  • HandoffBack
  • HandoffBack2
  • HandoffMeasurementRequest
  • HandoffMeasurementRequest2
  • HandoffToThird
  • HandoffToThird2
  • InformationDirective
  • InformationForward
  • InterSystemAnswer
  • InterSystemPage
  • InterSystemPage2
  • InterSystemSetup
  • LocationRequest
  • MobileOnChannel
  • MSInactive
  • OriginationRequest
  • QualificationDirective
  • QualificationRequest
  • RandomVariableRequest
  • RedirectionDirective
  • RedirectionRequest
  • RegistrationCancellation
  • RegistrationNotification
  • RemoteUserInteractionDirective
  • ResetCircuit
  • RoutingRequest
  • SMSDeliveryBackward
  • SMSDeliveryForward
  • SMSDeliveryPointToPoint
  • SMSNotification
  • SMSRequest
  • TransferToNumberRequest
  • TrunkTest
  • TrunkTestDisconnect
  • Unblocking
  • UnreliableRoamerDataDirective
  • UnsolicitedResponse
Длина

Длина пакета.

Информационные элементы

Информационные элементы, состав которых зависит от указанной операции.




SMDS

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:

gif_25

Положение стека протоколов 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

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




Стек PPP

Стек протоколов 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.

gif_24

Положение стека протоколов 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 (индикация состояния соединения)

  1. 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

  1. Code-Reject
  2. Protocol-Reject

  3. Echo-Request

  4. Echo-Reply

11 Discard-Request

12 Link-Quality Report

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

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

Размер

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

Данные

Поле переменной длины, которое может содержать одну или несколько опций. Формат конфигурационных опций 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

  1. Zone-Information

  2. 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

Распределение трафика по кодам 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

Распределение трафика по кодам 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

Стек протоколов 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.

 gif_23

Положение стека протоколов 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

Пример декодирования пакета 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

Пример декодирования пакета 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

NLSPtm (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

Протокол 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 выполняет следующие операции:

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

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

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

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

Соединение

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

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

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

На рисунке показан пример декодирования на этапе подключения к ELAN:

 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 (рабочие станции, коммутаторы, сетевые адаптеры, маршрутизаторы и т. д.) На рисунке схематически показано взаимодействие протоколов стека эмуляции ЛВС.

gif_22

Стек протоколов эмуляции ЛВС

Конечные точки соединений (серверы и рабочие станции) используют традиционные приложения ЛВС через драйверы 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 (отклик на запрос проверки).