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

Алгоритм выделения TEI и формирования связи

Рисунок 4.3.3.16 Алгоритм выделения TEI и формирования связи

Третий уровень X.25 служит для доставки управляющих сообщений даже в случае отказа сети, именно здесь выполняется реконфигурация маршрута, если это необходимо. Сигнальный пакет 3-го уровня имеет формат (Рисунок 4.3.3.17):

Блок-схема алгоритма шифрования Skipjack

Рисунок 6.4.7.2. Блок-схема алгоритма шифрования Skipjack

G-перестановки включают в себя разделение группы из 16 бит на две подгруппы по 8 бит. Подобно DES левая половина кода не изменяется в процессе реализации цикла шифрования, а используется в качестве входного параметра F-функции, для результата которой и правой части кода выполняется операция XOR. В отличии от DES половины кода меняются местами лишь после завершающего цикла.

F-функция G-перестановок достаточно проста: входные данные и субключ цикла объединяются операцией XOR, а результат заменяется кодом из таблицы просмотра (lookup-таблица - F). Субключи для G имеют длину 8 бит и являются первыми четырьмя байтами 80-битового исходного ключа. Первые 4 байта используются в первом цикле, следующие 4 – во втором, последние 2 байта вместе с первыми двумя – в третьем и т.д. 12 первых циклов реализации алгоритма шифрования Skipjack показаны на Рисунок 6.4.7.2. Первый цикл типа А отображен вместе со схемой реализации G-функции. Для следующих 7 циклов типа А G-функция отмечена квадратиком с буквой G. Цифрами (1-12) отмечен ввод данных для цикла с соответствующим номером. При реализации F-функции используется таблица (16*16) перестановок кодов 0-255.

В случае дешифровки циклы выполняются в обратном порядке. Аналогом цикла А при дешифровке является последовательность операций:

Для групп бит W1 и W2 и номера цикла выполняется операция XOR (циклы здесь нумеруются, начиная с 32 до 1). Затем W2 подвергается обратной G-перестановке, после чего выполняется перенос: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3. Аналог цикла типа В при дешифровке включает в себя следующие операции:

Группа бит W2 подвергается обратной G-перестановке. W3 объединяется с номером цикла и группой бит W2 с помощью операции исключающее ИЛИ. После чего производится перемещение: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3.

Этот формат не отличается от

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

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

Безусловно SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не дает решить все проблемы. Не все объекты в Интернет имею активные SNMP-агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах.

Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика может произойти из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты mac-уровня). Если сеть правильно сконфигурирована, реализуются только так называемые “короткие” столкновения, когда столкновение происходит не позднее, чем при передаче 64-го байта. Но если при построении сети допущены ошибки, возможны более поздние столкновения, что становится дополнительной причиной потери пакетов. Тогда может проявиться зависимость вероятности столкновения от длины пакета.

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

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

Два вида кадров процедур HDLC

Рисунок 4.3.1.2 Два вида кадров процедур HDLC

Флаг f = 01111110 задает границы кадра, SCS - контрольная сумма. Поля информация может иметь переменную длину, кратную восьми бит. Для HDLC определены три класса кадров: информационные (I), управляющие (S -supervisory) и ненумерованные (U - unnumbered). (Эти форматы соответствуют канальному уровню протокола x.25). Формат поля управление I-кадра показан на Рисунок 4.3.1.3.

Формат дейтограммы Интернет

Рисунок 4.4.1.1. Формат дейтограммы Интернет

Поле версия характеризует версию IP-протокола (например, 4 или 6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса слишком тяжелых последствий это не вызовет. Понятно также, что значение поля версия во избежании непредсказуемых последствий должно контролироваться программой. HLEN - длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (HLEN=5, без опций и заполнителя). Поле полная длина определяет полную длину IP-дейтограммы (до 65535 октетов), включая заголовок и данные. Одно-октетное поле тип сервиса (TOS - type of service) характеризует то, как должна обрабатываться дейтограмма. Это поле делится на 6 субполей:

Формат группового адреса

Рисунок 4.4.9.2. Формат группового адреса

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

Формат ICMP-сообщений об имеющихся маршрутах

Рисунок 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах

Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов, Рисунок 4.4.4.7).

Формат ICMP-сообщения "адресат не достижим"

Рисунок 4.4.4.3. Формат ICMP-сообщения "адресат не достижим"

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

Так как в сообщении содержится Интернет-заголовок и первые 64-бита дейтограммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP-сообщения посылается и в случае, когда дейтограмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.

Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4 для каждого из не записанных в буфер сообщений.

Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP, среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP (network time protocol) описан в RFC-1119.

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

Формат ICMP-запроса переадресации

Рисунок 4.4.4.5. Формат ICMP-запроса переадресации

Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтограмма достигла места назначения, указанного в ее заголовке. В поле internet-заголовок кроме самого заголовка лежит 64 первых бита дейтограммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 4.4.4.1).

Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс, через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP-запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу.

Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос. Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450-600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP-сообщений такого рода (см. Рисунок 4.4.4.6).

Формат icmp-запроса снижения загрузки

Рисунок 4.4.4.4. Формат icmp-запроса снижения загрузки

В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда таблицы все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут, он может послать ей ICMP-запрос переадресации. Формат такого сообщения отображен на рисунке 4.4.4.5.

Формат ICMP-запроса временной метки

Рисунок 4.4.4.10. Формат ICMP-запроса временной метки

Поле тип=13 указывает на то, что это запрос, а тип=14 - на то, что это отклик. Поле идентификатор и номер по порядку используются отправителем для связи запроса и отклика. Поле исходная временная метка заполняется отправителем непосредственно перед отправкой пакета. Поле временная метка на входе заполняется маршрутизатором при получении этого пакета, а Временная метка на выходе - непосредственно перед его отправкой. Именно этот формат используется в процедурах ping и traceroute. Эти процедуры позволяют не только диагностировать, но и оптимизировать маршруты. Например, команда traceroute cernvm.cern.ch, выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP-адреса узлов и значения времени жизни дейтограмм, значения RTT приводится в миллисекундах):

Отсюда видно, что наиболее узкими участками маршрута являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург является спутниковым и 500мс задержки здесь вносит время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) является общим также и для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP, как для локальной сети, так и для "окрестного" Интернет.

При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать "запрос маски" в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (Рисунок 4.4.4.11).

Формат IGMP-сообщений

Рисунок 4.4.9.3. Формат IGMP-сообщений

Поле версия определяет используемую версию протокола, поле тип=1 говорит о том, что это запрос, отправленный мультикастинг-маршрутизатором, тип=2 указывает, что этот отклик послан ЭВМ. ЭВМ использует групповой адрес, чтобы сообщить о своем подключении к группе. Контрольная сумма вычисляется по тому же алгоритму, что и для ICMP. IGMP-сообщения используются мультикастинг-маршрутизаторами для того, чтобы отслеживать членство в группе каждой из сетей, подключенных к нему. В группе может участвовать несколько активных процессов в одной и той же ЭВМ, но при этом посылается только один запрос для регистрации. Когда какой-то процесс покидает группу, ЭВМ не шлет сообщения об этом, даже в случае, когда это последний из процессов - членов группы на данной ЭВМ. Просто при очередном запросе ЭВМ не подтвердит членство в группе. Мультикастинг-маршрутизатор регулярно посылает запросы с требованием подтвердить участие в группе. ЭВМ посылает отклик- подтверждение для каждой из групп, если у нее есть хотя бы один процесс - член группы. На основе этих запросов-откликов мультикастинг-маршрутизатор составляет и поддерживает таблицу интерфейсов, которые имеют одну или более ЭВМ, входящих в мультикастинг-группы.

Протокол IGMP используется при организации мультикастинг-туннелей для передачи звуковой и видеоинформации. Для решения проблем мультимедиа в сетях Интернет используется идея MBONE.

По умолчанию мультикаст-дейтограммы имеют значение поля TTL=1, что ограничивает их распространение одной субсетью. Приложения могут увеличивать значение TTL. Первая дейтограмма, тем не менее, всегда имеет TTL=1. Если получение этой дейтограммы не подтверждается сервером, посылается вторая - с TTL=2 и т.д. Таким образом попутно измеряется и число шагов между клиентом и сервером. Для случая, когда число шагов не более 1, зарезервирован блок адресов 224.0.0.0 - 224.0.0.255. Маршрутизатор не обрабатывает пакеты с такими адресами вне зависимости от кода поля TTL.

При использовании мультикастинга MAC-переключатели переадресуют пакеты через все имеющиеся интерфейсы, что заметно ухудшает эффективность сети. Чтобы решить эту проблему компания CISCO разработала протокол CGMP (Cisco Group Management Protocol), который позволяет взаимодействовать маршрутизаторам и переключателям, что позволяет передавать мультикаст-пакеты только на те интерфейсы, где имеются активные члены группы.

Формат эхо-запроса и отклика ICMP

Рисунок 4.4.4.2. Формат эхо-запроса и отклика ICMP

Формат опции "временные метки"

Рисунок 4.4.1.4 Формат опции "временные метки"

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

Формат опций

Рисунок 4.4.1.1.16 Формат опций

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

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

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

0 - Данные опции не меняют маршрута

1 - Информация опции может изменить маршрут.

Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:

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

Опция Pad1 (выравнивание не требуется)

Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.

Опция padn (выравнивание не требуется)

Формат опций маршрутизации

Рисунок 4.4.1.3а. Формат опций маршрутизации

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

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

Просмотр маршрутной таблицы происходит в три этапа:

Ищется полное соответствие адресу места назначения. В случае успеха, пакет посылается соответствующему маршрутизатору или непосредственно интерфейсу адресата. Связи точка-точка выявляются именно на этом этапе.

Ищется соответствие адресу сети места назначения. В случае успеха система действует также как и в предшествующем пункте. Одна запись в таблице маршрутизации соответствует всем ЭВМ, входящим в данную сеть.

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

Для того чтобы посмотреть, как выглядит простая маршрутная таблица, воспользуемся командой netstat –rn (ЭВМ Sun. Флаг -r выводит на экран маршрутную таблицу, а -n отображает IP-адреса в цифровой форме. С целью экономии места таблица в несколько раз сокращена).

Формат опций записать маршрут

Рисунок 4.4.1.3 Формат опций записать маршрут

Поле код содержит номер опции (7 в данном случае). Поле длина определяет размер записи для опций, включая первые 3 октета. Указатель отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса). Интересную возможность представляет опция маршрут отправителя, которая открывает возможность посылать дейтограммы по заданному отправителем маршруту. Это позволяет исследовать различные маршруты, в том числе те, которые недоступны через узловые маршрутизаторы. Существует две формы такой маршрутизации: Свободная маршрутизация и Жесткая маршрутизация. Форматы для этих опций показаны ниже:

Формат описания опций

Рисунок 4.4.1.2. Формат описания опций

Флаг копия равный 1 говорит о том, что опция должна быть скопирована во все фрагменты дейтограммы. При равенстве этого флага 0 опция копируется только в первый фрагмент. Ниже приведены значения разрядов 2-битового поля класс опции:

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

* в колонке "длина" - означает - переменная.

Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут создает дейтограмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, утилита traceroute). Формат опции записать маршрут в дейтограмме представлен ниже на Рисунок 4.4.1.3:

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

Рисунок 4.2.1.5. Формат пакета SAP

Поле тип пакета принимает значение 0x0002 для SAP-откликов общего обслуживания (General Service Response) и 0x0004 для отклика ближайшего сервера. Запросы о ближайшем сервере используются для поиска в сети сервера конкретной разновидности (пакет запроса содержит лишь первые два поля). Реально отклик будет получен от всех серверов данного типа, а не только от ближайшего. Насколько данный сервер близок, определяется по числу маршрутизаторов до него. Эти запросы/отклики служат для составления списка доступных серверов. Поле тип сервера содержит код доступного вида услуг, а в поле наименование сервиса записывается имя услуги уникальное для данного сервера (длина поля на Рисунок 4.2.1.5 равна N). Поле адрес сети представляет собой 4-байтовое число, которое идентифицирует адрес сервера. Поле адрес узла характеризует адрес сервера в сети. Службы NetWare указывают адрес 0x00.00.00.00.00.01. Поле дескриптор соединителя характеризует код соединителя, который будет использовать сервер. Последнее поле - число шагов до сервера (число транзитных сетей) характеризует число маршрутизаторов между сервером и клиентом. При отключении сервера от сети он должен широковещательно разослать SAP-уведомление “Останов сервера”. Уведомление содержит код сервера и его полный адрес.

Формат поля управления I-кадра (нумерация по модулю

Рисунок 4.3.1.3. Формат поля управления I-кадра (нумерация по модулю 128)

\

N(S) и N(S) представляют собой поля номера кадров. N(R) - номер текущего кадра, а N(R) - номер следующего кадра, который отправитель текущего кадра ожидает получить. При несоответствии ожидаемого номера и полученного возникает ошибка. Если используется нумерация кадров по модулю 8, то максимальное число кадров, не получивших подтверждение не может превышать 7, а размер полей N(S) и N(R) равен трем бит. Это справедливо и для s-кадров. i, s и u-кадры могут иметь обычный (один байт) и расширенный (2 байта) форматы. Младший бит (1) расположен слева. Поле P/F - флаг опрос/окончание опроса. Информационный (I) кадр содержит поле информация (см. Рисунок 4.3.1.2). Формат S- кадра показан на Рисунок 4.3.1.4.

Формат поля управления информационных кадров

Рисунок 4.3.3.10 Формат поля управления информационных кадров

N(S) - номер кадра, посылаемого отправителем (cм. также описание форматов для протокола X.25).

N(R) - номер кадра, получаемого отправителем;

P/F - флаг опроса, если кадр является командой, или флаг окончания, в случае отклика.

Формат поля управления ненумерованных кадров

Рисунок 4.3.3.12 Формат поля управления ненумерованных кадров

m - бит модификатора функции (см. таблицу 4.3.1.2).

Мультиплексирование на уровне 2 осуществляется за счет использования отдельного адреса для каждого LAP (link access procedure) в системе. Адрес содержит два байта и определяет приемник командного кадра и адрес передатчика кадра-отклика. SAPI используется для идентификации типа услуг. Если наряду с цифровым телефоном используется обмен данными, то эти два терминала будут подключены к разным типам сервиса и, вообще говоря, к разным сетям. Для каждого вида услуг фиксируется определенный код SAPI. TEI (terminal endpoint identifier) обычно имеет определенное значение для каждого из терминалов пользователя.

Комбинация SAPI и TEI однозначно описывает LAP (link access procedure) и определяет адрес второго уровня. Так как в системе не может быть двух идентичных TEI, коды TEI распределяются следующим образом:

TEIс кодом в диапазоне 0-63 не нуждаются в диалоге с сетью в процессе установления связи на уровне 2. Но пользователь должен следить сам, чтобы в системе не было двух TEI с идентичными кодами. Терминалы с TEI в диапазоне 64-126 должны договариваться с сетью о TEI при установлении связи на уровне 2. Широковещательный TEI=127 служит для обращения ко всем терминалам, имеющим тот же код SAPI. Прежде чем предложить услуги уровню 3 уровень 2 должен запустить LAP. Это производится путем обмена пакетами между драйвером терминала уровня 2 и соответствующим сетевым драйвером. Предварительно должен быть активирован интерфейс уровня 1. До установления LAP возможен обмен только ненумерованными кадрами.

Этот процесс включает в себя передачу команды SET asynchronous balanced mode extended(SABME), адресат при этом должен откликнуться посылкой ненумерованного отклика (UA - unnumbered acknowledgment). После установления канала уровень 2 может передавать информацию для уровня 3. Ниже (Рисунок 4.3.3.13) приведена последовательность обмена кадрами на уровне 2:

Формат поля управления s-кадра (расширенный вариант)

Рисунок 4.3.1.4. Формат поля управления s-кадра (расширенный вариант)

Для однобайтовой версии s-кадра за полем s следует непосредственно поле P/F. Поле S определяет тип управляющего кадра (см. таблицу 4.3.1.1):

Формат поля управления U-кадра

Рисунок 4.3.1.5. Формат поля управления U-кадра

U-кадр используется для формирования канала, изменения режима работы и управления системой передачи данных. Существует версия, когда поле “0” размещается не в 8-ой позиции, а в 5-ой. В нижней части рисунка показана расширенная версия формата. Младшие разряды располагаются слева. Поле m может принимать значения, приведенные в таблице 3.5.1.2.

Установление соединения начинается с передачи в канал команды SABM (или SABME). Если удаленной станцией эта команда принята правильно и имеется возможность установления соединения, то присылается отклик UA. При этом переменные состояния на удаленной станции V(S) и V(R) (аналоги полей N(S) и N(R) в пакетах) устанавливаются в нулевое состояние.

Формат поля управления управляющих кадров

Рисунок 4.3.5.11 Формат поля управления управляющих кадров

s - разряды кода управляющей функции;

x - зарезервировано, должно быть равно нулю.

Формат псевдо-заголовков для TCP и UDP

Рисунок 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP

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

Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.

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

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

IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.

Рисунок 4.2.1.3. Формат RIP-пакета в NetWare

Поле тип пакета содержит код 0x0001, если это запрос, и 0x0002, если отклик. В поле адреса сети записывается адрес сети места назначения, если пакет является запросом. Если в поле записан код 0xff ff ff ff, это означает, что запрос относится ко всем известным сетям. Поле число шагов до цели имеет смысл лишь в случае пакетов-откликов. В этом случае сюда заносится число маршрутизаторов, которые должен пройти пакет по дороге к сети назначения. Поле время в тиках имеет смысл для пакетов-откликов и указывает на время, необходимое для достижения сети адресата. Один тик равен 1/18 секунды. Сходный протокол маршрутизации используется в сетях appletalk (RTMP).

Для межсетевой маршрутизации в Novell разработан протокол NLSP (NetWare link services protocol). NLSP базируется на той же идеологии, что и протокол IS-IS (intermediate system-to-intermediate system), созданный для сетей OSI и IP. В NLSP значение метрики маршрута задается вручную. nlsp-маршрутизаторы хранят полную карту сети, по которой принимаются решения о наилучших возможных маршрутах.

На Рисунок 4.2.1.4 представлена схема соответствия протоколов Novell и 7-уровневой модели osi.

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

Формат сообщения о недостижимости адресата

Рисунок 4.4.1.1.34. Формат сообщения о недостижимости адресата

Поля IPv6:

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

Поля ICMPv6:

Тип = 1

Код = 0 – нет маршрута до места назначения

1 – связь с адресатом административно запрещена

2 – не сосед

3 – адрес не достижим

4 – порт не достижим

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

Описание

Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).

Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).

Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.

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

Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.

Узел места назначения может посылать сообщение “адресат не достижим” с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.

Узел, получивший сообщение ICMPv6 “адресат не достижим” должен уведомить об этом протокол вышележащего уровня.

Формат сообщения типа "конфликт параметров"

Рисунок 4.4.4.9. Формат сообщения типа "конфликт параметров"

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

В процессе трассировки маршрутов возникает проблема синхронизации работы часов в различных ЭВМ. К счастью синхронизация внутренних часов ЭВМ требуется не так часто (например, при выполнении синхронных измерений), негативную роль здесь могут играть задержки в каналах связи. Для запроса временной метки другой ЭВМ используется сообщение запрос временной метки, которое вызывает отклик с форматом (Рисунок 4.4.4.10):

Формат сообщения "время (ttl) истекло"

Рисунок 4.4.4.8. Формат сообщения "время (ttl) истекло"

Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1).

Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтограммы), посылается сообщение "конфликт параметров". Это может произойти при неверных параметрах опций. При этом посылается сообщение вида (Рисунок 4.4.4.9):

Формат заголовка фрагментации

Рисунок 4.4.1.1.21. Формат заголовка фрагментации

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

Для каждого пакета, который должен быть фрагментирован, узел-отправитель генерирует код идентификации. Этот код должен отличаться от аналогичных кодов идентификации, используемых для других фрагментируемых пакетов, которые пересылаются в данный момент. Под "данным моментом" подразумевается период времени жизни пакета, включая время распространения кадра от источника до получателя и время, необходимое для сборки исходного (оригинального) пакета получателем. Однако не предполагается, чтобы отправитель знал максимальное время жизни пакета. Скорее предполагается, что данное требование будет удовлетворено с помощью простого 32-разрядного счетчика, инкрементируемого всякий раз, когда очередной пакет должен быть фрагментирован. Схема реализации генератора кода идентификации оставляется на усмотрение приложения. Если присутствует заголовок маршрутизации, под адресом получателя подразумевается конечное место назначения.

Под исходным большим, не фрагментированным пакетом подразумевается “оригинальный” пакет. Предполагается, что он состоит из двух частей, как показано на рисунке 4.4.1.1.22:

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

Формат заголовка IPX-пакета

Рисунок 4.2.1.2. Формат заголовка IPX-пакета

Поле Контрольная сумма (2 байта) устанавливается ipx-драйвером равным 0xffff, это означает, что контрольного суммирования не производилось. Приложениям разрешено использовать поле контрольной суммы при работе с кадрами Ethernet II, ieee 802.2 и Ethernet SNAP и запрещено для работы с кадрами ieee 802.3. Данное ограничение можно легко понять, обратившись к Рисунок 4.2.1.1. Контрольная сумма служит лишь для контроля правильности IPX-заголовка и не имеет никакого отношения к полю данных IPX-дейтограммы. Для того чтобы работать с контрольными суммами на NetWare-сервере, следует выдать команду set enable IPX checksum=n, где n указывает на то, что контрольная сумма использована. Возможные значения n и их смысл приведены ниже в таблице 4.2.1.1.

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

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

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

Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700].

Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов.

Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций.

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

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

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

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

Рисунок 4.4.1.1.18. Формат заголовка опций hop-by-hop

В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:

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

Формат запроса маршрутной информации

Рисунок 4.4.4.7 Формат запроса маршрутной информации

Так как следующий прогон (hop) дейтограммы определяется на основании локальной маршрутной таблицы, ошибки в последней могут привести к зацикливанию пакетов. Для подавления таких циркуляций используется контроль по времени жизни пакета (TTL). При ликвидации пакета по истечении TTL маршрутизатор посылает отправителю сообщение "время истекло", которое имеет формат (Рисунок 4.4.4.8):

Формат запроса (отклика) маски субсети

Рисунок 4.4.4.11. Формат запроса (отклика) маски субсети

Поле тип здесь специфицирует модификацию сообщения, тип=17 - это запрос, а тип=18 - отклик. Поля идентификатор и номер по порядку, как обычно, обеспечивают взаимную привязку запроса и отклика, а поле адресная маска содержит 32-разрядную маску сети.

Форматы сетевых пакетов

Рисунок 4.2.1.1. Форматы сетевых пакетов

Из рисунка видно, что различия непринципиальны и не препятствуют сосуществованию всех перечисленных форматов в пределах одной локальной сети. IPX-заголовок начинается сразу после поля Тип или Длина в зависимости от используемого протокола.

Серверы Netware можно сконфигурировать так, чтобы они воспринимали пакеты разных типов, и поэтому могли иметь непосредственные связи с разными сетями. IPX-сервер может выполнять и функции маршрутизатора. Формат заголовка пакета IPX показан на Рисунок 4.2.1.2. За заголовком следуют данные, их объем определяется кодом поля Длина пакета (минус 30) и лежит в диапазоне от 0 до 546 байт.

Глобальный адрес провайдера

Рисунок 4.4.1.1.9. Глобальный адрес провайдера

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

Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID).

Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера.

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

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

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на Рисунок 4.4.1.1.10:

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

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

IDEA является блочным алгоритмом шифрования данных, запатентованным швейцарской фирмой Ascom (http://fn2.freenet.edmonton.ab.ca/~jsavard/co0404.html). Фирма, правда, разрешила бесплатное некоммерческое использование своего алгоритма (применяется в общедоступном пакете конфиденциальной версии электронной почты PGP). Здесь в отличие от алгоритма DES не используются S-блоки или таблицы просмотра. В IDEA применяются 52 субключа, каждый длиной 16 бит. Исходный текст в IDEA делится на четыре группы по 16 бит. Для того чтобы комбинировать 16 битные коды, используется три операции: сложение, умножение и исключающее ИЛИ. Сложение представляет собой обычную операцию по модулю 65536 с переносом. При составлении таблицы умножения принимаются специальные меры для того, чтобы операция была обратимой. По этой причине вместо нуля используется код 65536. Рассмотрим алгоритм IDEA.

Пусть четыре четверти исходного текста имеют имена A, B, C и D, а 52 субключа – К(1), К(2),…, К(52). Перед реализацией алгоритма выполняются операции:

А = А*К(1); B = B + K(2); C = C + K(3); D = D * K(4);

Первый цикл вычислений включает в себя:

E = A XOR C; F = B XOR D

E = E * K(5)

F = F + E

F = F * K(6)

E = E + F

A = A XOR F

C = C XOR F

B = B XOR E

D = D XOR E

Меняем местами В и С.

Повторяем это всё 8 раз, используя К(7) – К(12) для второго раза и, соответственно, К(43) – К(48) - для восьмого. После восьмого раза В и С местами не меняются. Выполняем после этого операции:

A = A * K(49)

B = B + K(50)

C = C + K(51)

D = D * K(52)

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

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

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

Бизнесмены хотели бы предложить своим служащим пакет услуг Интернет на глобальной основе. Эти услуги могут включать помимо традиционного доступа к Интернет, также безопасный доступ к корпоративным сетям через виртуальные частные сети (VPN), используя туннельные протоколы, такие как PPTP, L2F, L2TP и IPSEC в туннельном режиме.

Для того чтобы улучшить взаимодействие роуминга и сервиса туннелирования, желательно иметь стандартизованный метод идентификации пользователей. Ниже предлагается синтаксис для идентификаторов доступа к сети NAI (Network Access Identifier). Примеры приложений, которые используют NAI, и описания семантики можно найти в [1].

Здесь используются следующие определения:

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

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

Название ISDN (integrated system digital network - интегрированные цифровые сети) было предложено группой XI CCITT в 1971 году (cм. П. Боккер, ISDN. Цифровая сеть с интеграцией служб. Понятия, методы, системы. “Радио и связь”, М. 1991). Основное назначение ISDN - передача 64-кбит/с по 4-килогерцной проводной линии и обеспечение интегрированных телекоммуникационных услуг (телефон, факс, данные и пр.). Использование для этой цели телефонных проводов имеет два преимущества: они уже существуют и могут использоваться для подачи питания на терминальное оборудование. Выбор 64 Кбит/c стандарта определен простыми соображениями. При 4-килогерцной полосе, согласно теореме Найквиста-Котельникова, частота стробирований должна быть не ниже 8 кГц. Минимальное число двоичных разрядов для представления результатов стробирования голосового сигнала при условии логарифмического преобразования равна 8. Таким образом, в результате перемножения этих чисел и получается значение полосы B-канала ISDN. Базовая конфигурация каналов имеет вид 2*B + D = 2*64 +16 = 144 кбит/с. Помимо B-каналов и вспомогательного D-канала isdn может предложить и другие каналы с большей пропускной способностью, канал Н0 с полосой 384 Кбит/с, Н11 – 1536 и Н12 – 1920 Кбит/c (реальные скорости цифрового потока). Для первичных каналов (1544 и 2048 Кбит/с) полоса D-канала может составлять 64 Кбит/с.

Ожидается, что к 2000 году в США будет 10000000 пользователей ISDN. Число же телефонных аппаратов в мире приближается к миллиарду. Существует около 10 разновидностей протоколов ISDN (national ISDN-1 (США); at&t custom; euro-ISDN (Net3) и т.д.

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

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

Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен, как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p.

Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим.

Обмен сообщениями при разрыве связи

Рисунок 4.3.3.19 Обмен сообщениями при разрыве связи

Возможна временная пассивация терминала посредством сообщения suspend с последующим возобновлением прерванного режима с помощью сообщения resume. Каждое из этих сообщений требует подтверждения получения (suspend acknowledge и resume acknowledge, соответственно). При вызове может оказаться несколько терминалов, отвечающих запрашиваемым требованиям (например, телефонных аппаратов). Вызывающая сторона может выбрать один из них (зная, например, их положение). Существует два механизма обращения к заданному терминалу. Первый использует вспомогательную службу direct dialling-in (DDI), которая в случае реализации обычного доступа к ISDN называется multiple subscriber number (MSN). В DDI и MSN номер сети используется для целей маршрутизации в пределах локальной сети пользователя. Каждому терминалу в сети должен быть присвоен уникальный MSN-номер. Именно этот номер используется для идентификации при Setup-процедуре.

Второй механизм адресации к заданному терминалу базируется на субадресации (subaddressing - SUB). В этом варианте дополнительная адресная информация передается от источника запроса к адресату. Этот адрес не является частью ISDN-номера, который используется для целей маршрутизации. Этот адрес может быть применен для обращения к некоторому процессу внутри терминала (не следует забывать, терминалом может быть ЭВМ) или к приложениям, которые не следуют стандартам OSI. Каждый терминал, подсоединенный к пассивной шине, нуждается в присвоении ему субадреса.

Принципиальное различие между DDI/MSN и SUB методами адресации заключается в том, что для DDI/MSN адрес является частью ISDN номера, в то время как для SUB это не так.

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

Для максимального удовлетворения запросов потребителей isdn должна поддерживать самые разные дополнительные виды услуг.
Чтобы решить эти задачи на уровне 3 для интерфейса пользователь-сеть разработаны два протокола - функциональная и стимулирующая сигнальные процедуры. В случае стимулирующей сигнальной процедуры терминал не должен иметь какой-либо информации о вспомогательных видах услуг. Работа терминала контролируется сетью с помощью сигнальных сообщений уровня 3. Сеть и терминал работают по схеме клиент-сервер и от терминала не требуется особых аналитических способностей. Базовый формат управляющих сообщений соответствует типу information. Существуют две разновидности этого протокола: один использует управляющие последовательности символов, заключенные между * и #, для второго - сеть должна хранить специальный профайл для каждого терминала. Такой профайл может переопределять функцию некоторых клавиш терминала. Нажатие такой клавиши осуществляет вызов определенного вида услуг.

В случае функциональной сигнальной процедуры терминал должен знать все о вспомогательном виде услуг и хранить всю необходимую информацию о них. Функциональный протокол использует информационные элементы facility (возможность, см. таблицу 4.3.5.4). Для пересылки этих информационных элементов используются сообщения типа register (см. описание протокола X.25). Функциональный протокол базируется на протоколе ROSE (remote operations service element). Этот протокол служит для поддержки приложений, где необходим интерактивный контроль сетевых объектов. Протокол ROSE обеспечивает запуск процесса, поддерживает процедуры подтверждения и последующее управление процессом. В таблице 4.3.5.4 приведен перечень дополнительных услуг, предоставляемых ISDN и поддерживаемых функциональным протоколом.

Поле тип указывает на тип

Последовательность обмена кадрами на

Последовательность сообщений при реализации стандартного вызова

Рисунок 4.3.3.18 Последовательность сообщений при реализации стандартного вызова

Вызываемый партнер получает setup-сообщение через широковещательное обращение. Все терминалы, соединенные с NT1 могут анализировать Setup-сообщение с тем, чтобы определить, соответствуют ли они вызывающей стороне. Соответствие определяется по возможностям канала и по совместимости информационных элементов нижнего уровня. Если терминал соответствует требованиям запроса, он посылает сети сообщение alerting (Оповещение). В то же время, если необходимо, терминал должен сформировать локальный сигнал вызова (напр. звонок). После получения всей необходимой информации сеть выдает сообщение call proceeding, которое указывает на то, что начата установка связи с объектом вызова. Когда терминал обнаружил, что на запрос получен отклик, он переадресует connect-сообщение сети. Сеть регистрирует запрос и выдает команду терминалу соединиться с соответствующим B-каналом, послав пакет connect acknowledge, содержащий код B-канала. В любой момент времени к В-каналу может иметь доступ только один терминал. Все остальные терминалы, которые откликнулись на запрос, получат от сети сообщение release, которое переводит их в пассивное состояние. Пользователь может отменить запрос в любое время, послав три сообщения: disconnet, release и release complete (см. Рисунок 4.3.3.19 и таблица 4.3.3.2).

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

Рисунок 5.2.3. Пример круглосуточного мониторинга активности в сети с использованием ICMP-зондирования

Другим примером такого мониторинга могут служить программы, контроля внешних каналов ИТЭФ и связей в пределах локальной сети. Смотри страницы:

http://saturn.itep.ru/trace/intern/start.htm

и

http://saturn.itep.ru/trace/extern/start_trace.htm

Протокол IGMP

4.4.9 Протокол IGMP

Передача мультимедийных данных по сетям Интернет является одним из наиболее важных направлений. Этот вид информации передается обычно в режиме без установления соединения (протокол UDP-RTP). Наиболее типичной схемой в этом случае является наличие одного передатчика и большого числа приемников. Эта схема реализуется с использованием мультикастинг-адресации. Мультикастинг-адресация может осуществляться на IP- и MAC-уровнях. В Ethernet для этих целей зарезервирован блок адресов в диапазоне от 01:00:5E:00:00:00 до 01:00:5E:7F:FF:FF. Первый байт адреса, равный 01, указывает на то, что адрес является мультикастным. Данная схема резервирования адресного пространства позволяет использовать 23 бита Ethernet-адреса для идентификации группы рассылки при IP-мультикастинге (см. Рисунок 4.4.9.1.).

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

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

Протокол передачи команд и сообщений об ошибках (ICMP - internet control message protocol, RFC-792, - 1256) выполняет многие и не только диагностические функции, хотя у рядового пользователя именно этот протокол вызывает раздражение, сообщая об его ошибках или сбоях в сети. Именно этот протокол используется программным обеспечением ЭВМ при взаимодействии друг с другом в рамках идеологии TCP/IP. Осуществление повторной передачи пакета, если предшествующая попытка была неудачной, лежит на TCP или прикладной программе. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице будет восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтограммах, но не дает информации об ошибках в самих ICMP-сообщениях. icmp использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтограмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP-протокол осуществляет:

передачу отклика на пакет или эхо на отклик;

контроль времени жизни дейтограмм в системе;

реализует переадресацию пакета;

выдает сообщения о недостижимости адресата или о некорректности параметров;

формирует и пересылает временные метки;

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

ICMP-сообщения об ошибках никогда не выдаются в ответ на:

icmp-сообщение об ошибке.

При мультикастинг или широковещательной адресации.

Для фрагмента дейтограммы (кроме первого).

Для дейтограмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

Эти правила призваны блокировать потоки дейтограмм, посылаемым в отклик на мультикастинг или широковещательные ICMP-сообщения.

ICMP-сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на Рисунок 4.4.4.1.

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

Рисунок 4.4.1.5. Распределение протоколов Интернет по уровням

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

Режим переключения кадров

Рисунок 4.3.3.24 Режим переключения кадров

ITU-T делит все канальные услуги на две категории. 8 типов услуг уже определены для случая коммутации каналов и три определены для коммутации пакетов. Три из восьми считаются определяющими и каждый ISDN-переключатель должен их поддерживать (ITU-T рекомендация I.230).

Семиуровневая эталонная модель ISO

Рисунок 4.3.1.1. Семиуровневая эталонная модель ISO

Разбиение совокупности (стека) сетевых протоколов по уровням связана с попыткой унификации аппаратного и программного обеспечения. Предполагается, что каждому из уровней соответствует определенная ункциональная программа с жестко заданными входным и выходным интерфейсами. Форматы данных на заданном уровне модели для отправителя и получателя должны быть идентичны. Физический уровень локальных сетей определен документами, например, Ethernet II, IEEE 802.3 и т.д. Модели ISO наиболее полно соответствуют сети X.25.

Физический уровень X.25 определяет стандарт на связь между ЭВМ и сетевыми коммутаторами (X.21), а также на процедуры обмена пакетами между ЭВМ. X.21 характеризует некоторые аспекты построения общественных сетей передачи данных. Следует учитывать, что стандарт X.25 появился раньше рекомендаций ITU-T и опыт его применения был учтен при составлении новейших рекомендаций. На физическом уровне могут использоваться также протоколы X.21bis, RS232 или V.35.

Канальный уровень определяет то, как информация передается от ЭВМ к пакетному коммутатору (HDLC - high data link communication, бит-ориентированная процедура управления), на этом уровне исправляются ошибки, возникающие на физическом уровне.

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

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

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

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

Прикладной уровень - это все, что может понадобиться пользователям сетей, например X.400.

Международным стандартом в процедуре HDLC определены два вида кадров:

Сети IEEE

4.1.8 Сети IEEE 802.11

Технология беспроводных сетей развивается довольно быстро. Эти сети удобны для подвижных средств в первую очередь. Наиболее перспективным представляется проект IEEE 802.11, который должен играть для радиосетей такую же интегрирующую роль как 802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе 802.11 используется тот же алгоритм доступа и подавления cтолкновений, что и в 802.3, но здесь вместо соединительного кабеля используются радиоволны (

Схема беспроводной локальной сети

Рисунок 4.1.8.1. Схема беспроводной локальной сети

Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц при использовании 4FSK/2FSK FHSS модуляции, мощность передатчика 10мВт-1Вт. Максимальная пропускная способность сети составляет 2 Мбит/с.

В 1992 году страны члены ЕС выделили диапазон частот 1,89-1,9 ГГц для целей построения сетей, базирующихся на применение радиосигналов (стандарт DECT - Digital European Cordless Telecommunications). Этот стандарт был разработан для целей передачи данных и голоса в системах сотовой связи. В США для этих же целей используются широкополосные системы с шумоподобным сигналом (SST - ШПС). Для подобных же целей выделены также частотные диапазоны 18 и 60ГГц (диапазон 2,4 ГГц сильно перегружен и “засорен” шумами). Существуют уже системы базирующиеся на Ethernet и Token Ring.

При относительно малых расстояниях проблем обычно не возникает и работу беспроводной сети действительно можно аппроксимировать алгоритмом CSMA. Но в случае, когда расстояние между передатчиком и приемником сравнимо с радиусом надежной связи, отличие от традиционных сетей становится значительным. Ведь для радиосетей важна интерференция на входе приемника, а не на выходе передатчика (как в CSMA). Рассмотрим вариант сети, изображенный на Рисунок 4.1.8.2. Если передачу осуществляет узел А, узел С находится вне его радиуса действия и может решить, что можно начать передачу. Излучение передатчика С может вызвать помехи на входе узла В (проблема скрытой станции).

Схема, поясняющая диагностические возможности протокола ICMP

Рисунок 5.2.1. Схема, поясняющая диагностические возможности протокола ICMP

Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена). Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, а известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, обслуживающие многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы.

Сканируя всю сеть периодически в течение суток и регистрируя процент потерь пакетов в сети, можно выявить и неисправные сетевые интерфейсы. Такой интерфейс при включении может портить условия распространения пакетов по сегменту. Обнаружив корреляцию между повышением вероятности потерь пакетов и включением определенной ЭВМ, можно сделать именно такой вывод и позднее независимо исследовать именно этот сетевой интерфейс.

Протокол ICMP можно использовать и для измерения размера зоны столкновений, что крайне важно для успешной работы локальной сети, ведь превышение предельного размера зоны приводит к резкому росту числа столкновений. Вычислить размер зоны бывает затруднительно, так как для повторителей и концентраторов довольно часто время задержки не указывается. Разумеется, что оно должно быть меньше предельно допустимого, разрешенного документом 802.3, но кто может дать гарантию? Для решения поставленной задачи следует использовать ICMP пакеты минимальной длины. Программа посылает пакеты ICMP и воспринимает отклики, регистрируя долю потерянных пакетов. Для зондирования выбирается самая удаленная рабочая станция или сервер (см. Рисунок 5.2.2). Программа должна уметь посылать ICMP-пакеты, не дожидаясь отклика. Пакеты посылаются парами с зазором между ними t. Далее варьируем t и добиваемся максимума вероятности потери пакетов. Зазор t, при котором будет достигнут максимум потерь, соответствует реальному значению задержки, характеризующей зону столкновений для данного логического сегмента сети. Периодическая посылка пакетов слишком сильно перегрузит сеть, именно по этой причине следует периодически посылать пары пакетов. При этом период посылки таких пар должен быть достаточно велик, чтобы исключить влияние процессов восстановления после столкновения (> 1сек).

Схема реализации алгоритма шифрования IDEA

Рисунок 6.4.7.1. Схема реализации алгоритма шифрования IDEA

При дешифровке используется тот факт, что A XOR B не изменяется, если C A и B будет произведена операция XOR C использованием любого числа. Это утверждение справедливо для любых значений А и В. Операции сложения (слагаемые заменяются их дополнением по модулю 2) и умножения (множители заменяются из обратными величинами по модулю 65537) также допускают инверсию. Первые четыре ключа дешифровки (KD) определяются несколько иначе, чем остальные.

KD(1) = 1/K(49);

KD(2) = -K(50);

KD(3) = -K(51);

KD(4) = 1/K(52);

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

KD(5) = K(47)

KD(6) = K(48)

KD(7) = 1/K(43)

KD(8) = -K(45)

KD(9) = -K(44)

KD(10) = 1/K(46)

Субключи IDEA генерируются следующим образом. 128-битовый ключ IDEA определяет первые восемь субключей (128=8*16). Последующие ключи (44) получаются путем последовательности циклических сдвигов влево этого кода на 25 двоичных разрядов.

SKIPJACK

Skipjack – секретный в прошлом блочный алгоритм, который ассоциируется с микросхемой Clipper (описание стало открытым в июне 1989 года). Алгоритм представляет собой альтернативу решениям, предлагаемым в алгоритмах IDEA и Safer (развитие идей DES, Lucifer и Blowfish). Блок исходных данных также как и в idea разбиваются на четыре группы. Алгоритм легко реализуется на обычной ЭВМ. Skipjack включает в себя 32 цикла шифрования. Эти циклы имеют две разновидности (А и В). Цикл А выполняет следующие операции.

Первая группа бит исходного текста подвергается шифрованию с использованием G-перестановок (четырех цикличный шифр Файстела – специальный класс блочных шифров, где зашифрованный текст получается из исходного путем многократного использования одного и того же преобразования, напоминает шифр DES. Исходный текст разделяется на две части. Функция преобразования f и ключ используются для преобразования одной из половин а результат объединяется со второй частью исходного кода с помощью операции исключающее ИЛИ. После этого части меняются местами и процедура повторяется и т.д.). Для полученного результата и номера цикла (RN = 1-32) и четвертой группы исходного текста (W4) выполняется операция XOR. После этого производится перенос: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.

Цикл В осуществляет следующие преобразования.

Для второй группы бит исходного текста (W2) выполняется операция XOR с номером цикла и первой группой бит исходного текста (W2 = (W2 XOR RN) XOR W1). Затем первая группа блока (W1) подвергается шифрованию с использованием G-перестановок. После этого производится перенос данных: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.

Последовательность выполнения алгоритма Skipjack предполагает выполнение 8 циклов типа А, 8 циклов В, 6 циклов А и 8 циклов В.

Схема соответствия протоколов Novell и модели osi

Рисунок 4.2.1.4. Схема соответствия протоколов Novell и модели osi

Протокол SAP (service advertising protocol) служит для получения информации обо всех серверах, имеющихся в сети, и поддерживает следующие виды запросов и функции:

запрос SAP-сервиса;

оповещение об отключении сервера;

мониторинг откликов и некоторые другие.

Каждому серверу NetWare присваивает номер, а некоторые сервера могут иметь и имя. Номер сервера и его имя хранятся в базе данных объектов bindary каждого сервера. Пакет запроса SAP-сервиса содержит 2 байта типа пакета и два байта типа сервера. Поле тип пакета определяет, является ли данный пакет общим запросом сервиса (код=0x0003), или запросом ближайших услуг (код=0x0001).

Схема вложения ICMP-пакетов в Ethernet-кадр

Рисунок 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр

Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений). Код уточняет функцию ICMP-сообщения.

Схема вычисления контрольной суммы (FCS/CRC)

Рисунок 4.3.3.14 Схема вычисления контрольной суммы (FCS/CRC)

Другой возможной ошибкой является получение I-кадра с неверным номером N(S). Это возможно, когда LAP работает при ширине окна более 1. Если потерян кадр с номером N(s)=k, принимающая сторона не должна посылать подтверждение приема кадра k+1. Отклик при этом имеет тип REJ (см. таблица 4.3.3.1) с N(R)=k+1. Это укажет передающей стороне, что все кадры до k получены, но необходимо возобновить передачу, начиная с кадра k. При выявлении ошибки в N(R) связь прерывается, реинициализируются переменные состояния передающей и принимающей сторон, после чего канал восстанавливается, и обмен возобновляется с самого начала.

Схема взаимодействия сетей ISDN и X

Рисунок 4.3.3.22 Схема взаимодействия сетей ISDN и X.25

TA - терминальный адаптер; TE - терминальное оборудование; NT - сетевое терминальное оборудование

Доступ к программам обработки пакетов возможен через B- или D-каналы. В зависимости от вида приложения доступ через D-канал иметь определенные преимущества. D-канал в отличии от B-канала принципиально не может быть заблокирован. Возможна работа одновременно с 8-ю терминалами, подключенными к пассивной ISDN-шине. Кроме того, работа с D-каналом оставляет B-канал свободным для задач, которые не решаемы через D из-за его малого быстродействия (16 Кбит/с). А согласно рекомендациям LAPD быстродействие D-канала не может быть увеличено (по этой же причине максимальная длина пакетов X.25 в данной схеме не может превышать 260 октетов (против 1024 для обычных каналов X.25). К недостаткам использования D-канала можно отнести возможное увеличение задержек из-за низкого быстродействия. Протокол X.25 был разработан довольно давно для “традиционных” приложений и его недостаточная гибкость (большие задержки откликов, таймауты и пр.) приводит к тому, что он совершенно не пригоден для некоторых новых приложений. Это вынудило разработку для ISDN новых режимов работы с пакетами. И первое что было сделано - это четкое разделение управляющих и информационных потоков.

ISDN может рассматриваться как две логически независимые субсети - сигнальную субсеть и коммутируемую информационную сеть (в x.25 информация и управление осуществляется по одним и тем же каналам). В соответствии с этим разделением терминология CCITT различает плоскость управления (C-plane) и пользовательскую информационную плоскость (U-plane, см. Рисунок 4.3.3.23). В ISDN существует два режима: frame relaying (передача кадров, наиболее простой из режимов) и frame switching (коммутация кадров). Отличительной особенностью режима frame relaying является отсутствие подтверждений получения пакета при обмене данными между ISDN-терминалами (аналог UDP в TCP/IP сетях). Для обоих режимов используется одни и те же сигнальные процедуры (Q.933), но они отличаются протоколами U-плоскости при пересылке информации. Здесь используются протоколы передачи данных, базирующиеся на усовершенствованном стандартном сигнальном протоколе LAPD слоя 2, известном как LAPF - link access procedures for frame mode bearer services (Q.922). Пользователь может установить несколько виртуальных соединений и/или постоянных виртуальных связей одновременно с несколькими адресатами.

Схема взаимодействия узлов в беспроводной сети (MACA)

Рисунок 4.1.8.2. Схема взаимодействия узлов в беспроводной сети (MACA)

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

Ранние протоколы беспроводных локальных сетей базировались на схеме MACA (Multiple Access with Collision Avoidance), разработанной Ф. Карном в 1990 году. Эта схема является основой стандарта IEEE 802.11. В этой схеме отправитель запрашивает получателя послать короткий кадр, будучи принят соседями, предотвратит их передачу на время последующей передачи сообщения адресату. На Рисунок 4.1.8.2 узел В посылает кадр RTS (Request To Send) узлу C. Этот кадр имеет всего 30 октетов и содержит поле длины последующего сообщения. Узел C откликается посылкой кадра CTS (Clear To Send), куда копируется код длины последующего обмена из кадра RTS. После этого узел В начинает передачу. Окружающие станции, например D или E, получив CTS, воздерживаются от начала передачи на время, достаточное для передачи сообщения оговоренной длины. Станция A находится в зоне действия станции B, но не станции C и по этой причине не получит кадр CTS. По этой причине станция A может начинать передачу, если хочет и не имеет других причин, препятствующих этому. Несмотря на все предосторожности коллизия может иметь место. Например, станции A и C могут одновременно послать кадры RTS станции B. Эти кадры будут неизбежно потеряны, после псевдослучайной выдержки эти станции могут совершить повторную попытку (как в ETHERNET).

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

К сожалению беспроводные, особенно мобильные каналы крайне ненадежны. Потери пакетов в таких каналах весьма вероятны. Понижение скорости передачи, как правило, не приводит к понижению вероятности потери. Кроме того, проходы от отправителя к получателю здесь неоднородны и могут включать в себя сегменты с различными методами транспортировки данных (проводные и беспроводные). В таких структурах бывает полезно разбить канал на две последовательные связи (indirect TCP). Преимуществом такой схемы является то, что оба виртуальных канала являются однородными. Таймауты в одном из соединений заставят отправителя замедлить темп передачи, в то время как таймауты во втором - могут ускорить обмен. Да и все остальные параметры связей могут оптимизироваться независимо. Основной недостаток этого приема заключается в нарушении базового принципа организации TCP-соединений на основе сокетов, здесь получение подтверждения отправителем не означает благополучной доставки. В 1995 году была предложена схема, не нарушающая TCP-семантику. В этой схеме вводится специальный агент-наблюдатель, который отслеживает состояние кэшей отправителя и получателя и посылает подтверждения. Этот агент при отсутствии своевременного подтверждения запускает процедуру повторной посылки сегмента, не информируя об этом первичного отправителя. Механизмы подавления перегрузки запускаются в этом варианте только при перегрузке проводной секции канала. При потерях реализуется выборочная пересылка сегментов.

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

Схема зондирования

Рисунок 5.2.2. Схема зондирования

RTT в данном случае равно 2Т+t, где t - время задержки отклика в зондируемой ЭВМ. Зазор между пакетами t должен быть больше t. Если t больше Т, то точность измерения будет невелика. Можно подумать, что при t Ј t вероятность столкновения будет равна 100%, но это не так. В этом случае столкновения не будет, ведь интерфейс обнаружит несущую у себя на входе и передачу не начнет. Передача отклика может начаться не ранее 9,6 мксек после завершения первого пакета-зонда (IPG). Если t < 9,6 мксек, передача отклика начнется через 9,6 мксек, если же больше, то через t. На практике 100% потери за счет столкновений будут реализовываться при t < t < Т+t (при t > 9,6 мксек). При t > t+t столкновения не будет, так как до измерительной машины дойдет пакет от исследуемой ЭВМ и передача не начнется из-за обнаружения интерфейсом несущей в кабельном сегменте. Следует иметь в виду, что при детектировании столкновения обе ЭВМ попытаются через некоторое время повторить попытку. Эта попытка вероятнее всего увенчается успехом, ведь они начнут ее не одновременно. Для извлечения нужных данных надо считывать содержимое регистра интерфейса, где записывается число случаев столкновений. Определив диапазон временных зазоров между пакетами-зондами, при которых происходят столкновения со 100% вероятностью, мы получим значение Т. Здесь требуются достаточно точные часы с разрешающей способностью лучше 10 мксек. Если таких часов нет, можно использовать время исполнения команд, предварительно прокалибровав это время при достаточно большом числе их исполнения.

Ниже на рисунке 5.2.3 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа позволяет не только отображать такого рода диаграммы но и измеряет относительные потери для различных сегментов сети (написана Сергеем Тимохиным). Предусмотрена возможность вывода списка машин активных в любой заданный интервал времени. По горизонтали отложено время суток 0-24 часа, а по вертикали - число ЭВМ, присылающих отклики на icmp-запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)

Сообщение о конфликте параметров

Рисунок 4.4.1.1.36. Сообщение о конфликте параметров

Поля ICMPv6:

Тип 4

Код 0 – встретилась ошибка в поле заголовка

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

2 – встретилась неопознанная опция IPv6

Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.

Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.

Описание

Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.

Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.

Сообщение packet too big (пакет слишком велик)

Рисунок 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)

Поля IPv6:

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

Поля ICMPv6:

Тип 2

Код 0

mtu   mtu следующего шага.

Описание

Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].

Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.

Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (Рисунок 4.4.1.1.33).

Поля ICMPv6:

Тип 3

Код 0 – при передаче превышен лимит числа шагов

1 – превышено время восстановления сообщения из фрагментов.

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

Описание

Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.

Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d).

Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.

Сообщение запрос эхо

Рисунок 4.4.1.1.37. Сообщение запрос эхо

Поля IPv6:

Адрес места назначения – любой легальный IPv6-адрес

Поля ICMPv6:

Тип 128

Код 0

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

Номер по порядку

Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

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

Описание

Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

Формат сообщения эхо-отклик идентичен формату запроса эхо (Рисунок 20.5).

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

Поля ICMPv6:

Тип 129

Код 0

Идентификатор. Идентификатор из исходного запроса эхо (echo request).

Номер по порядку. Номер по порядку из исходного запроса эхо.

Информация. Данные из исходного запроса эхо.

Описание

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

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

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

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

Оповещение верхнего уровня

Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня.

Сообщение о членстве в группе имеет следующий формат:

Сообщения участия в группе

Рисунок 4.4.1.1.38. Сообщения участия в группе

Поля IPv6:

Адрес места назначения

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

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

Поле Hop Limit = 1 (предельное число шагов)

Поля ICMPv6:

Тип 130 – Запрос членства в группе

131 – Отчет о членстве в группе

132 – Сокращение членства в группе

Код 0

Максимальное время отклика

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

Не используется. Отправитель записывает нуль, получатель игнорирует.

Мультикаст-адрес

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

Описание

Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].

Литература

Соотношение мультикастинговых MAC- и IP-адресов

Рисунок 4.4.9.1. Соотношение мультикастинговых MAC- и IP-адресов

Область из 5 бит в IP-адресе, отмеченная *****, не используется при формировании Ethernet-адреса. Так как соотношение IP и MAC-адресов не является однозначным, драйверы должны обеспечивать обработку адресов с тем, чтобы интерфейсы получали только те кадры, которые действительно им предназначены. Для того чтобы информировать маршрутизатор о наличии участников мультикастинг-обмена в субсети, связанной с тем или иным интерфейсом, используется протокол IGMP.

Протокол IGMP (internet group management protocol, RFC-1112) используется для видеоконференций, передачи звуковых сообщений, а также группового исполнения команд различными ЭВМ. Этот протокол использует групповую адресацию (мультикастинг).

Групповая форма адресации нужна тогда, когда какое-то сообщение или последовательность сообщений необходимо послать нескольким (но не всем) адресатам одновременно. При этой форме адресации ЭВМ имеет возможность выбрать, хочет ли она участвовать в этой процедуре. Когда группа ЭВМ хочет взаимодействовать друг с другом, используется один групповой (мультикастинг) адрес. Групповая адресация может рассматриваться как обобщение обычной системы адресов, а традиционный IP-адрес - частный случай группового обращения при числе ЭВМ, равном 1.

При групповой адресации один и тот же пакет может быть доставлен заданной группе ЭВМ. Членство в этой группе может динамично меняться со временем. Любая ЭВМ может войти в группу и выйти из группы в любое время по своей инициативе. В то же время ЭВМ может быть членом большого числа таких групп. ЭВМ может посылать пакеты членам группы, не являясь им сама. Каждая группа имеет свой адрес класса D (Рисунок 4.4.9.2, см. также Рисунок 4.4.9.1).

Ссылки

Ссылки

Структура информационного поля для FRMR-кадров

Рисунок 4.3.1.6. Структура информационного поля для FRMR-кадров

Биты A, B, C и D определяют причину, по который кадр не был доставлен. Если бит равен 1, то это указывает на соответствующую причины недоставки. Бит A указывает на неверное значение N(R). Бит B =1 говорит о слишком большой длине информационного поля. Бит C - указывает на то, что поле управления неопределенно из-за наличия в кадре недопустимой для данной команды или отклика информационного поля, а D=1 означает, что поле управления принятого кадра не определено или же неприемлемо. V(R) и V(S) текущие значения переменных приема и передачи, соответственно. C/R (Command/Response) =1 означает, что ошибочное сообщение является откликом (=0 - командой). Большинство U-кадров интерпретируются как команды или отклики в зависимости от контекста и того, кто их послал. В некоторых случаях для разделения откликов и команд используется поле адреса. Одним из наиболее известных протоколов сетевого уровня, использующих HDLC, является X.25.

Структура кадра для слоя

и не обрабатываются узлами по

Связи местной ISDN-АТС

Рисунок 4.3.3.21 Связи местной ISDN-АТС

Взаимодействие между ISDN и PSPDN регулируется стандартом ccitt x.31 (и i.462). x.31 позволяет использовать ISDN с существующими сетями x.25. Схема взаимодействия периферийного оборудования, ISDN и PSPDN показана на рисунке 4.3.3.22 (ISDN-коммутатор может и отсутствовать).

Не специфицированные адреса, адреса обратной

Контрольная сумма используется, если доступна

Таблица

Цифровой канал для внедиапазонного управления

Дополнительные услуги сети ISDN

Таблица 4.3.5.4. Дополнительные услуги сети ISDN

Определение вызывающего номера (более эффективный аналог АОН);

Ограничение (запрет) по вызывающим номерам;

Ожидание вызова;

Прямой набор номера;

Субадресация;

Переносимость терминала;

Телефонные конференции;

Безусловная переадресация вызовов;

Переадресация, если номер занят;

Переадресация вызова при отсутствии ответа;

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

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

При установлении телефонного канала используется сообщение TUP (telephony user part). В ISDN определены также сообщения ISUP (integrated services user part), которые должны стать основой всех будущих разработок. Примерами ISUP могут служить следующие сообщения:

В ISDN используются базовая (B-канал, 64 Кбит/с) и первичная (1,544/2,048 Мбит/с) скорости передачи информации. Сигнальный D-канал формируется на основе 24-го временного домена (timeslot) в случае 1,544 Мбит/с и 16-го для 2,048 Мбит/с. Характеристики первичных каналов ISDN приведены в таблице 4.3.3.5.

Характеристики первичных каналов ISDN

Таблица 4.3.3.5. Характеристики первичных каналов ISDN

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

Для первичной скорости не предусматривается интерфейс многоточечного обмена в локальной сети пользователя; связь устанавливается между сетью и одним из PABX (public automatic branch exchange) или другим терминалом.

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

Для базовой скорости передачи работает сигнальная цифровая система доступа DASS (digital access signaling system). Формат кадра при этом имеет вид (DASS2/DPNSS - digital private network signaling system):

этих кодов приведена ниже

Таблица этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные – являются запросами):

кодов поля тип сервера приведена ниже (

Таблица кодов поля тип сервера приведена ниже (4.2.1.3).

Коды мультикастинг-процессов

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

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

Коды поля M (U-кадр)

Таблица 4.3.1.2. Коды поля M (U-кадр).

После благополучного получения пакета ua локальной станцией соединение считается установленным и может начинаться обмен данными. Информацию несут кадры типа I, а также FRMR и UI-кадры типа U. В кадре ответа FRMR должно присутствовать информационное поле, содержащее обоснование присылки такого ответа. Структура этого поля для обычного и расширенного (внизу) форматов показана на Рисунок 4.3.1.6.

Коды поля S

Таблица 4.3.1.1. Коды поля S

S-кадры служат для передачи сигналов подтверждения, запросов повторной передачи или прекращения посылки кадров из-за блокировки приема в местной станции. При получении кадра с неверным порядковым номером (напр., предшествующий кадр потерян), приемник посылает S-кадр REJ, что означает необходимость повторной посылки предшествующего кадра и всех последующих. Кадр SREJ(n) указывает на то, что все кадры до n-1, включительно, доставлены без ошибок, а при доставке кадра n допущена ошибка и он должен быть послан повторно. В отличии от rej запрашивается пересылка только одного кадра. Связь с терминалом является временной, если бит P/F равен 1. Если адрес места назначения равен 11111111, то обращение является широковещательным. Формат U-кадра представлен на Рисунок 4.3.1.5.

Коды протоколов Интернет

Таблица 4.4.1.2. Коды протоколов Интернет

Коды тип сервера (cм также ftp://ftpisiedu/in-notes/iana/assignments/novell-sap-numbers)