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

         

Максимальный размер поля данных для



4.4.1.1 Адресация IPv6



1. Терминология  
2. Формат заголовка IPv6  
3. IP версия 6 архитектуры адресации  
4. Модель адресации  
4.1. Представление записи адресов (текстовое представление адресов)  
4.2. Представление типа адреса  
4.3. Уникастные адреса  
4.3.1. Примеры уникастных адресов  
4.4. Неспецифицированный адрес  
4.5. Адрес обратной связи  
4.6. IPv6 адреса с вложенными IPv4 адресами  
4.7. NSAP адреса  
4.8. IPX Адреса  
4.9. Провайдерские глобальные уникаст-адреса  
4.10. Локальные уникаст-адреса IPv6  
4.11. Эникаст-адреса  
4.12. Мульткаст-адреса  
4.12.1. Предопределенные мультикаст-адреса  
4.13. Необходимые адреса узлов  
5. Заголовки расширения IPv6  
5.1. Порядок заголовков расширения  
6. Опции  
6.1. Опции заголовка hop-by-hop (шаг за шагом)  
7. Маршрутный заголовок  
8. Заголовок фрагмента  
9. Заголовок опций места назначения  
10. Отсутствие следующего заголовка  
11. О размере пакетов  
12. Метки потоков  
13. Приоритет  
14. О протоколе верхнего уровня  
14.1 Контрольные суммы верхнего уровня  
15. Максимальное время жизни пакета  
16. Максимальный размер поля данных для протоколов высокого уровня  
17. Приложение A. Рекомендации по формированию опций  
18. Соображения безопасности  
19. Расширение DNS для поддержки IP версии 6  
19.1. Определение новой ресурсной записи и домена  
19.2. Модификации существующих типов запроса  
20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6  
20.1. ICMPv6 (ICMP для IPv6)  
20.2. Общий формат сообщений  
20.3. Сообщения об ошибках ICMPv6  
20.4. Информационные сообщения icmpv6  
В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Семенов Ю.А., Радио и связь, М 1995].
После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).

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

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

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

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

Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям.

IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

Расширение адресации

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


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

Спецификация формата заголовков

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

Улучшенная поддержка расширений и опций

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

Возможность пометки потоков данных

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

Идентификация и защита частных обменов

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

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.

1. Терминология



Узел
Оборудование, использующее IPv6.
Маршрутизатор Узел, который переадресует пакеты ipv6, которые не адресованы ему непосредственно.
ЭВМ Любой узел, который не является маршрутизатором.
Верхний уровень Протокольный уровень, расположенный непосредственно поверх. В качестве примеров можно привести транспортные протоколы TCP и UDP, протокол управления ICMP, маршрутные протоколы типа OSPF (RFC-2740), а также интернетовские или другие протоколы нижнего уровня инкапсулированные в IPv6, например, IPX, Appletalk, или сам IPv6.
Канал Средство коммуникации или среда, через которую узлы могут взаимодействовать друг с другом на связном уровне, т.е., уровень непосредственно под IPv6. Примерами могут служить Ethernet; PPP; X.25, Frame Relay, или ATM; а также Интернет "туннели", такие как туннели поверх IPv4 или IPv6.
Соседи Узлы, подключенные к общему каналу.
Интерфейс Средство подключения узла к каналу.
Адрес Идентификатор IPv6-уровня для интерфейса или набора интерфейсов.
Пакет Заголовок и поле данных IPv6.
MTU канала Максимальный размер пакета в канале
MTU пути Минимальный MTU канала для пути от узла источника до получателя.
Эникастный адрес Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по такому адресу, доставляется ближайшему интерфейсу (согласно метрики маршрутного протокола) из числа идентифицированных этим адресом.
Замечание: допустимо (хотя и необычно), что устройство с несколькими интерфейсами может быть сконфигурировано для переадресации пакетов, приходящих через один или несколько интерфейсов. Пакеты, приходящие через остальные интерфейсы, могут при этом отбрасываться. Такие устройства должны выполнять требования протоколов маршрутизации. При получении пакетов, адресованных этому устройству, оно должно вести себя как обычная ЭВМ.

2. Формат заголовка IPv6


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



Рисунок 4.3.3.8. Адресное поле кадра слоя 2



ea бит расширения адресного поля;


c/r
бит поля команда/отклик;


sapi
service access point identifier - идентификатор точки доступа, служит для описания характера реализуемого сервиса:


tei
terminal endpoint identifier - идентификатор точки подключения терминала.
SAPI=0 - запрос соединения по схеме коммутации каналов;

SAPI=16 - переключение пакетов согласно протокола X.25;

SAPI=63 административные или управленческие функции (опционно). Точка доступа к услугам представляет собой виртуальный интерфейс между слоем 2 и 3 (см. Рисунок 4.3.3.9).


Алгоритм выделения 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.



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



Рисунок 4.3.3.20 DASS2/DPNSS-кадр уровня 2



Этот формат не отличается от общепринятого для уровня 2 ISDN, за исключением числа байт управления (см. Рисунок 4.3.3.20 и 4.3.3.7), что допускается регламентирующими документами. Использование местной ISDN-АТС открывает дополнительные возможности. Помимо высококачественной локальной связи появляются коллективные (групповые) номера, что снимает ограничение на число пользователей, подключенных к узлу через обычные аналоговые модемы. Все пользовательские модемы дозваниваются по одному и тому же номеру, а коммутатор выполняет функцию пакетного мультиплексора. Емкость таких АТС легко наращивается, отдельные АТС могут объединяться друг с другом. Схема взаимодействия такой АТС (PTNX) с терминальным пользовательским оборудованием, другими ptnx и основной сетью ISDN показана на Рисунок 4.3.3.21. Местная АТС может предоставлять те же услуги, что и традиционная сеть ISDN, плюс запрограммированные локально виды сервиса (диалог между пользователями локальной сети, услуга типа “не беспокоить” и т.д.).


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



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

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

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

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

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


Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP-протокола.

При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов.

Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента позволяет оперативно локализовать неисправный сетевой элемент (см. Рисунок 5.2.1). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это позволяет даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.


Два вида кадров процедур 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 приводится в миллисекундах):

traceroute to crnvma.cern.ch

(128.141.2.4) 30 hops max, 40 byte packets

1 itep-fddi-bbone (193.124.224.50) 3 ms 2 ms 3 ms
2 msu-tower.moscow.ru.radio-msu.net (193.124.137.13) 3 ms 3 ms 3 ms
3 npi-msu.moscow.ru.radio-msu.net (193.124.137.9) 27 ms 3 ms 9 ms
4 desy.hamburg.de.radio-msu.net (193.124.137.6) 556 ms 535 ms 535 ms
5 * 188.1.133.56 (188.1.133.56) 637ms 670ms
6 duesseldorf2.empb.net (193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!)
7 bern3.empb.net (193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!)
8 cernh3.euro-hep.net (193.172.24.10) 1808ms 1508ms 1830ms
9 cgate1.cern.ch (192.65.185.1) 1116ms 1270ms 1278ms
10 crnvma.cern.ch (128.141.2.4) 1132ms 1362ms 1524ms

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

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



Формат 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 Формат опций


Тип опции

8-битовый идентификатор типа опции.

Длина опции

8-битовое целое число без знака. Длина поля данных опции в октетах.

Данные опции

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

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

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

00

обойти эту опцию и продолжить обработку заголовка.

01

выбросить данный пакет.

10

выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции.

11

выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции.

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

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

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

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

2n

означает любое двухоктетное смещение от начала заголовка.

8n+2

означает любое 8-октетное смещение от начала заголовка плюс 2 октета.

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

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

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

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



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



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


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

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

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

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

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

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

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


routing tables destination gateway flags refcnt use interface
193.124.225.72 193.124.224.60 ughd 0 61 le0
192.148.166.1 193.124.224.60 ughd 0 409 le0
193.124.226.81 193.124.224.37 ughd 0 464 le0
192.160.233.201 193.124.224.33 ughd 0 222 le0
192.148.166.234 193.124.224.60 ughd 1 3248 le0
193.124.225.66 193.124.224.60 ughd 0 774 le0
192.148.166.10 193.124.224.60 ughd 0 621 le0
192.148.166.250 193.124.224.60 ughd 0 371 le0
192.148.166.4 193.124.224.60 ughd 0 119 le0
145.249.16.20 193.124.224.60 ughd 0 130478 le0
192.102.229.14 193.124.224.33 ughd 0 13206 le0
default 193.124.224.33 ug 9 5802624 le0
193.124.224.32 193.124.224.35 u 6 1920046 le0
193.124.134.0 193.124.224.50 ugd 1 291672 le0
Колонка destination - место назначение, Default - отмечает маршрут по умолчанию; Gateway - IP-адреса портов подключения (маршрутизаторов); REFCNT (reference count) - число активных пользователей маршрута; USE – число пакетов, посланных по этому маршруту; interface - условные имена сетевых интерфейсов. Расшифровка поля FLAGS приведено ниже:

u Маршрут работает (up).
g Путь к маршрутизатору (gateway), если этот флаг отсутствует, адресат доступен непосредственно.
h Маршрут к ЭВМ (host), адрес места назначения является полным адресом этой ЭВМ (адрес сети + адрес ЭВМ). Если флаг отсутствует, маршрут ведет к сети, а адрес места назначения является адресом сети.
d Маршрут возник в результате переадресации.
m Маршрут был модифицирован с помощью переадресации.
Опция временные метки работает также как и опция запись маршрута. Каждый маршрутизатор на пути дейтограммы делает запись в одном из полей дейтограммы (два слова по 32 разряда; смотри раздел 4.4.15). Формат этой опции отображен на рисунке 4.4.1.4.


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



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


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



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



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


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

Значение поля класс опции

Описание

0

Дейтограмма пользователя или сетевое управление

1

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

2

Отладка и измерения (диагностика)

3

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

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

Класс опции

Номер опции

Длина описания

Назначение

0

0

-

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

0

1

-

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

0

2

11

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

0

3

*

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

0

7

*

Запись маршрута. Используется для трассировки

0

8

4

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

0

9

*

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

2

4

*

Временная метка Интернет

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

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



Формат пакета 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 распределяются следующим образом:

0-63

коды tei, присваиваемые пользователем

64-126

коды tei, присваиваемые автоматически (сетью);

127

глобальный TEI (для широковещательных целей).

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

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



Формат поля управления 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.

15. Максимальное время жизни пакета

В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов.
По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.

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

При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

17. Приложение a. Рекомендации по формированию опций

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

Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.

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

Можно предположить, что когда присутствует какой-то заголовок, содержащий опции, он несет в себе небольшое число опций, обычно одну.

Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения.Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:

Пример 1

Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (Рисунок 4.4.1.1.27):


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



Рисунок 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.3.3. 17 Формат сигнального пакета уровня 3



Эти пакеты следуют от терминала к коммутатору и наоборот. Первый октет (поле протокольный дискриминатор) дает D-каналу в будущем возможность поддержки нескольких протоколов. Приведенный код соответствует стандартному управляющему запросу пользователя. Третий октет (поле код запроса - call reference value) используется для идентификации запроса вне зависимости от типа коммуникационного канала, где этот запрос может быть реализован. Четвертый байт характеризует назначение пакета (например, Setup - запрос установления канала). Возможные типы сообщений перечислены в таблице 4.3.3.2. Длина сообщения зависит от его типа. Стандарт не регламентирует содержания полей, следующих за полем тип сообщения, и они могут использоваться по усмотрению пользователя для расширения функциональных возможностей системы.




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



Рисунок 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. Формат заголовка фрагментации


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

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

Резерв

8-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме.

Fragment offset

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

Резерв (второй)

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

m флаг

1 = есть еще фрагменты; 0 = последний фрагмент.

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

32 бита

Для того чтобы послать пакет с длиной больше 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.20. Формат заголовка маршрутизации типа 0



Следующий заголовок 8- битовый селектор. Идентифицирует тип заголовка, следующего непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700].
hdr ext len 8-битовое целое без знака. Длина заголовка маршрутизации в 8-октетных блоках, исключая первые 8 октетов. Для заголовков маршрутизации типа 0 hdr ext len равна удвоенному числу адресов в заголовке, должно быть четным числом меньше или равным 46.
Тип маршрутизации 0.
Оставшиеся сегменты 8-битовое целое без знака. Число оставшихся сегментов пути, т.e., число узлов, которые следует посетить на пути к месту назначения. Максимально допустимое число = 23
Резерв 8-битовое поле резерва. Инициализируется нулем при передаче и игнорируется при приеме.
strict/loose bit map 24-битовый код-маска, биты пронумерованы, начиная с 0 до 23, слева направо. Для каждого из сегментов пути указывает должен ли следующий узел быть соседом: 1 означает strict (должен быть соседом), 0 означает пропустить (не должен быть соседом).
Адрес[1..n] Вектор 128-битовых адресов, пронумерованных с 1 до n.
Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0.

Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения.

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

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



Если оставшееся число сегментов = 0

{ продолжить обработку следующего заголовка пакета, чей тип задан полем следующий заголовок заголовка маршрутизации }

else если HDR ext len является нечетным или больше 46,

{посылается сообщение ICMP (parameter problem, код 0) с указателем на поле HDR #EXT LEN, пакет выбрасывается}

else

{ вычислить n, число адресов в заголовке маршрутизации, для этого код HRD EXT LEN делится на 2

Если число оставшихся сегментов пути больше n,

{послать сообщение ICMP (parameter problem, код 0) с указанием на поле числа оставшихся сегментов пути }

else

{ уменьшить число оставшихся сегментов пути на 1;

Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n

Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми

{ выбросить пакет }

else { поменять местами адрес места назначения IPv6 и адрес[i]

если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа

{ послать сообщение ICMP destination unreachable -- not a neighbor

и выбросить пакет }

else если код IPv6 hop limit меньше или равен 1

{послать сообщение icmp time exceeded -- hop limit exceeded in transit message и выбросить пакет }

else { уменьшить hop limit на 1

повторно направить пакет модулю IPv6 для отправки новому адресату }

}

}

}

В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения:

При движении пакетов от S к I1:

Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = I1 Число оставшихся сегментов пути = 3
Адрес[1] = I2
Если бит 0 bit map равен 1,

s и i1 должны быть соседями;

это проверяется узлом S
Адрес[2] = I3

Адрес[3] = d
<


/p> При движении пакетов от I1 к I2:

Адрес отправителя = s Hdr Ext Len = 6
Адрес получателя = I2 Число оставшихся сегментов пути = 2
Адрес[1] = I1
Если бит 1 bit map равен 1,

I1 и I2 должны быть соседями;

это проверяется узлом I1
Адрес[2] = i3

Адрес[3] = D
При движении пакетов от I2 к I3:

Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = I3 Число оставшихся сегментов пути = 1

Адрес[1] = I1
Если бит 2 bit map равен 1,

I2 и I3 должны быть соседями; это проверяется узлом I2
Адрес[2] = I2
Адрес[3] = D
При движении пакетов от I3 к D:

Адрес отправителя = S Hdr Ext Len = 6
Адрес получателя = D Число оставшихся сегментов пути = 0

Адрес[1] = I1
Если бит 3 bit map равен 1, I3 и D должны быть соседями; это проверяется узлом I3 Адрес[2] = I2

Адрес[3] = i3
8. Заголовок фрагмента



Заголовок фрагмента используется отправителем IPv6 для посылки пакетов длиннее, чем MTU пути до места назначения. (Замечание: в отличие от IPv4, фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами вдоль пути доставки). Заголовок фрагментации идентифицируется кодом поля следующий заголовок, равным 44 и имеет следующий формат (Рисунок 4.4.1.1.21):


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



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


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

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

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

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

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

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

10. Отсутствие следующего заголовка

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

11. О размере пакетов

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более.
Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.


Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.

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

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

В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.



Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел “думает”, что адресат находится на том же канале что и сам узел.

Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.

12. Метки потоков

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

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

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

Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - ffffff. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.



Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

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

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


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

Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд.

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

Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.

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

13. Приоритет

4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки).Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.

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


Формат заголовка опций hop-by-hop



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


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

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

HDR EXT LEN

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

Опции

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

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

Опция Jumbo Payload

(необходимо выравнивание: 4n + 2)



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



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



Версия 4- битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6)
Приор. 4-битный код приоритета
Метка потока 24-битный код метки потока (для мультимедиа)
Размер поля данных 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций.
Следующий заголовок 8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700].
Предельное число шагов 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется.
Адрес отправителя 128-битовый адрес отправителя пакета. См. RFC-1884.
Адрес получателя 128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884.
3. IP версия 6 архитектуры адресации

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

unicast: Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе.
anycast: Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации).
multicast: Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по мультикастинг-адресу, доставляется всем интерфейсам, заданным этим адресом.
В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам.

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

4. Модель адресации

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

IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:

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

Маршрутизаторы могут иметь ненумерованные интерфейсы (например, интерфейсу не присваивается никакого IPv6 адреса) для соединений точка-точка, чтобы исключить необходимость вручную конфигурировать и объявлять (advertise) эти адреса. Адреса не нужны для соединений точка-точка маршрутизаторов, если эти интерфейсы не используются в качестве точки отправления или назначения при посылке IPv6 дейтограмм. Маршрутизация здесь осуществляется по схеме близкой к используемой протоколом CIDR в IPv4.

IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей.

4.1. Представление записи адресов (текстовое представление адресов)

Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк:

Основная форма имеет вид x:x:x:x:x:x:x:x, где 'x' шестнадцатеричные 16-битовые числа.

Примеры:

fedc:ba98:7654:3210:FEDC:BA98:7654:3210

1080:0:0:0:8:800:200C:417A

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

Из-за метода записи некоторых типов IPv6 адресов, они часто содержат длинные последовательности нулевых бит. Для того чтобы сделать запись адресов, содержащих нулевые биты, более удобной, имеется специальный синтаксис для удаления лишних нулей. Использование записи "::" указывает на наличие групп из 16 нулевых бит. Комбинация "::" может появляться только при записи адреса.


Последовательность "::" может также использоваться для удаления из записи начальных или завершающих нулей в адресе. Например:

1080:0:0:0:8:800:200c:417a уникаст-адрес
ff01:0:0:0:0:0:0:43 мультикаст адрес
0:0:0:0:0:0:0:1 адрес обратной связи
0:0:0:0:0:0:0:0 неспецифицированный адрес
может быть представлено в виде:

1080::8:800:200c:417a уникаст-адрес
ff01::43 мультикаст адрес
::1 адрес обратной связи
:: не специфицированный адрес
Альтернативной формой записи, которая более удобна при работе с ipv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где 'x' шестнадцатеричные 16-битовые коды адреса, а 'd' десятичные 8-битовые, составляющие младшую часть адреса (стандартное IPv4 представление). Например:

0:0:0:0:0:0:13.1.68.3

0:0:0:0:0:FFFF:129.144.52.38

или в сжатом виде:

::13.1.68.3

::FFFF:129.144.52.38

4.2. Представление типа адреса

Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix - FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1.1):


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



Рисунок 4.4.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).

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

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

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

4.10. Локальные уникаст-адреса IPv6

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (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 Идентификатор доступа к сети

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

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

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

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

Идентификатор доступа к сети NAI Идентификатор доступа к сети (NAI) является идентификатором пользователя, представленным клиентом в ходе PPP-аутентификации. При роуминге целью NAI служит идентификация пользователя, а также содействие маршрутизации запроса аутентификации. Заметьте, что NAI не должен быть обязательно идентичным его электронному адресу или userID, выдаваемому на прикладном уровне для аутентификации.
Сервер доступа к сети Сервер доступа к сети NAS (Network Access Server) представляет собой прибор, куда клиент “звонит” чтобы получить доступ к сети. В терминологии PPTP это называется концентратором доступа PPTP (PAC), а в терминологии L2TP, он называется концентратором доступа L2TP (LAC).
Объем роуминга Объем роуминга можно определить, как способность использовать любого из имеющихся ISP, формально поддерживая только одну взаимосвязь покупатель-продавец.
Туннельная услуга Туннельной услугой является любой сетевой сервис, допускаемый протоколами туннелирования, такими как PPTP, L2F, L2TP и IPSEC в туннельном режиме. Примером туннельной услуги может служить безопасный доступ к корпоративной сети через частные виртуальные сети (VPN).
<
/p> Как описано в [1], существует много услуг, использующих телефонный доступ, а число провайдеров, предлагающих такие услуги (в том числе для подвижных пользователей) стремительно растет.

Для того чтобы обеспечить большой объем роуминга, одним из требований является способность идентифицировать “домашний” аутентификационный сервер пользователя. Эта функция в сети выполняется с помощью идентификатора NAI, посылаемого пользователем серверу NAS в процессе первичной PPP-аутентификации. Ожидается, что NAS будет использовать NAI как часть процесса открытия нового туннеля, с целью определения конечной точки этого туннеля.

Идентификатор доступа к сети имеет форму user@realm (но это не обязательно почтовый адрес). Заметьте, что в то время как пользовательская часть NAI согласуется с BNF, описанной в [5], BNF строки описания области допускает использования в качестве первого символа цифры, что не разрешено BNF, описанной в [4]. Это изменение было сделано с учетом сложившейся в последнее время практикой, FQDN, такое как 3com.com вполне приемлемо.

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

Формальное определение NAI

Грамматика для NAI представленная ниже, описана в ABNF, как это представлено в [7]. Грамматика для имен пользователей взята из [5], а грамматика имен областей является модифицированной версией [4].

nai = username / ( username "@" realm )
username = dot-string
realm = realm "." label
label = let-dig * (ldh-str)
ldh-str = *( Alpha / Digit / "-" ) let-dig
dot-string = string / ( dot-string "." string )
string = char / ( string char )
char = c / ( "\" x )
let-dig = Alpha / Digit
Alpha = %x41-5A / %x61-7A ; A-Z / a-z
Digit = %x30-39 ;0-9
c = < any one of the 128 ASCII characters, but not any special or SP >
x = %x00-7F ; all 127 ASCII characters, no exception
SP = %x20 ; Space character
special = "" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" / %x22 / Ctl
Ctl = %x00-1F / %x7F ; the control characters (ASCII codes 0 through 31 inclusive and 127)
<


/p> Примеры правильных идентификаторов сетевого доступа:

fred@3com.com

fred@foo-9.com

fred_smith@big-co.com

fred=?#$&*+-/^smith@bigco.com

fred@bigco.com

nancy@eng.bigu.edu

eng!nancy@bigu.edu

eng%nancy@bigu.edu

Примеры неправильных идентификаторов сетевого доступа:

fred@foo

fred@foo_9.com

@howard.edu

fred@bigco.com@smallco.com

eng:nancy@bigu.edu

eng;nancy@bigu.edu

@bigu.edu

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

Имена областей NAI должны быть уникальными и право их использование для целей роуминга оформляется согласно механизму, применяемому для имен доменов FQDN (fully qualified domain name). При намерении использовать имя области NAI нужно сначала послать запрос по поводу возможности применения соответствующего FQDN.

Заметьте, что использование FQDN в качестве имени области не предполагает обращения к DNS для локализации сервера аутентификации. В настоящее время аутентификационные серверы размещаются обычно в пределах домена, а маршрутизация этой процедуры базируется на локальных конфигурационных файлах. Реализации, описанные в [1], не используют DNS для поиска аутентификационного сервера в пределах домена, хотя это и можно сделать, используя запись SRV в DNS, что описано в [6]. Аналогично, существующие реализации не используют динамические протоколы маршрутизации или глобальную рассылку маршрутной информации.




Интегрированные сети 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) и т.д.

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

“Преобразование, кодирование и передача информации”), впервые примененная во время второй мировой войны.
Широкое внедрение этого метода передачи относится к началу 60-х годов.

Чтобы обеспечить пропускную способность 64 Кбит/с по имеющимся телефонным проводам, не нарушая теоремы Шеннона, надо ставить ретрансляторы на расстоянии 2 км друг от друга (ведь ослабление сигнала в стандартном кабеле составляет около 15дБ/км). Последние достижения в телекоммуникационных технологиях существенно ослабили это ограничение.). Унификация скоростей передачи данных в ISDN способствует уменьшению объема оборудования, так как исключает необходимость межсетевых интерфейсов, согласующих быстродействие отдельных частей сети. Одной из наиболее массовых приложений ISDN является цифровая телефония. Человеческий голос можно удовлетворительно закодировать, используя лишь 6 бит, но вариации уровня входного сигнала приводит к тому, что нужно не менее 8 бит (с учетом логарифмической характеристики аналого-цифрового преобразователя - АЦП). Значения кодов, полученных в результате последовательных преобразований звука человеческой речи, сильно коррелированны, а это открывает дополнительные возможности для сжатия информации.

Сети ISDN дали толчок развитию сетевой технологии. На очереди интеграция Интернет с кабельным телевидением, а там, глядишь, появятся квартирные сети, объединяющие телевизор, ЭВМ, бытовую технику и телефон. Это неудивительно, когда цена хорошего телевизора почти сравнялась с ценой персональной ЭВМ, а многие бытовые устройства имеют встроенные процессоры. Здесь должно быть решено несколько проблем. С одной стороны телевизионные кабели имеют полосу пропускания достаточную для передачи как аналогового (заведомо более 10 каналов), так и цифрового телевидения. Проблема возникает при совмещении передачи телевизионного сигнала и цифрового (или PCM) канала Интернет (кабельные модемы пока достаточно дороги). Современные телевизионные системы обеспечивают порядка 50 каналов одновременно, что накладывает весьма жесткие требования на кабельную разводку между локальным распределительным узлом и оконечными пользователями.Распределительные узлы сегодня объединяются с помощью ATM-каналов (~150 Мбит/с, широкополосный ISDN), что уже сегодня недостаточно. По мере удешевления можно ожидать, что в ближайшем будущем в квартиры конечных пользователей будет осуществлен ввод оптоволоконных кабелей, что решит проблему радикально (не нужен не только телевизионный, но и телефонный кабель). Попутно это решит проблему и видеотелефона. На очереди разработка новых стандартов, которые позволят осуществить такую интеграцию.

Так как первоначально ISDN создавалась для передачи голоса и изображения (факс), начнем именно с этих приложений. Для факсов сети ISDN особенно привлекательны, так как может обеспечить высокое разрешение (до 16 линий/мм и лучше) при разумном времени передачи.

Для иллюстрации взаимодействия различных частей ISDN рассмотрим Рисунок 4.3.3.1.


IP-протокол



4.4.1 IP-протокол

В Интернет используется много различных типов пакетов, но один из основных - IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP. IP-протокол предлагает ненадежную транспортную среду. Ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтограммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтограмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 4.4.1.1.



IPX-протокол



4.2.1.1 IPX-протокол

Протокол IPX предназначен для передачи дейтограмм в системах, неориентированных на соединение (также как и IP или NETBIOS, разработанный IBM и эмулируемый в Novell), он обеспечивает связь между NetWare серверами и конечными станциями. Максимальный размер IPX-дейтограммы составляет 576 байт, из них 30 байта занимает заголовок. Предполагается, что сеть, через которую транспортируются эти дейтограммы, способна пересылать пакеты соответствующей длины. IPX-пакеты могут рассылаться широковещательно, для этого поле типа должно принять значение 0x14, адрес сети назначения должен соответствовать локальной сети, адрес узла назначения при этом принимает значение 0xFFFFFF.

Оригинальный транспортный протокол Novell, на мой взгляд, не способствует успеху этой сети. Не успев своевременно переориентироваться на транспортные и маршрутные протоколы стека TCP/IP этот крайне популярный совсем недавно вид сетей в настоящее время имеет шансы исчезнуть.

IPX-пакеты, передаваемые по сети Ethernet, могут иметь несколько разных форматов. Старейший из них носит в Novell название “802.3” (информацию об интеграции сетей Novell и Интернет можно найти в документах: RFC-1234, -1420, -1553, -1634, -1792) и используется по умолчанию в версиях вплоть до 3.11. В последующих версиях форматом по умолчанию является “802.2”. Применим также и формат, называемый Ethernet II, который наиболее близок идеологии TCP/IP. Сеть в Netware - это логический канал, который используется совместно рядом узлов так, что они могут взаимодействовать друг с другом непосредственно. Так процессы, реализуемые на одном сервере, считаются подключенными к внутренней IPX-сети. Все пользователи сети типа Ethernet II образуют логическую сеть IPX. Все пользователи одной сети типа 802.3 рассматриваются как узлы различных сетей IPX. Сопоставление форматов пакетов для различных сетевых стандартов представлено на Рисунок 4.2.1.1.



Эталонная конфигурация системы



Рисунок 4.3.3.3 Эталонная конфигурация системы передачи и приема сигналов, а также подачи питания на терминальное оборудование


(*) Относится к полярности кадровых сигналов. (**) относится к полярности питающего напряжения. Используется напряжение питания V= 40 v, которое (если требуется для питания управляющей электроники) преобразуется в 5 В.

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



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



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

Международная организация по стандартизации (ISO) определила 7-уровневую эталонную сетевую модель для открытых систем (OSI), (Интернет использует 4-х уровневое подмножество). Ниже на Рисунок 4.3.1.1 показана схема этих уровней, справа записаны коды документов международного Телекоммуникационного союза (ITU), регламентирующих протоколы соответствующих уровней.



Кабели и разъемы в каналах ISDN



Рисунок 4.3.3.2. Кабели и разъемы в каналах ISDN


Точки s и t обеспечивают доступ к канальным услугам ISDN. В точке R (на Рисунок 4.3.3.2 TA - терминальный адаптер), в зависимости от типа терминального адаптера, доступны некоторые другие стандартные CCITT услуги (X.21 или X.25, V.35, RS-232 или V.24). Входы TE1 и TE2 предназначены для удаленных телекоммуникационных услуг. Все виды услуг могут быть разделены на три группы по форме доступа к 64кбит/с:

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

Принципиально новые услуги, которые недоступны при низких скоростях обмена, например, факсимильная передача со скоростью 3-4 секунды на страницу (против 20-30 сек при низких скоростях); видеотекст (напр., Prestel в Англии, Minitel во Франции или Bildschirmtext в Германии).

Услуги, абсолютно невозможные при скоростях ниже 64кб/с. Например, видеотелефон или высококачественная передача звука (G.722; ADPCM - adaptive differential pulse code modulation). Телефония часто использует каналы со скоростью передачи 32кбит/с (G.721). Полоса звукового сигнала равна 50 Гц - 20 кГц.

Эталонная конфигурация системы передачи и приема сигналов, а также подачи питания на терминальное оборудование показана на Рисунок 4.3.3.3. Передаваемая по проводам мощность составляет 1-0.5 Вт. Дополнительная пара проводов питания является в настоящее время опционной.



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



Рисунок 4.4.1.1.10. Локальный адрес канала


Локальные адреса канала предназначены для обращения через определенный канал, например, для целей авто-конфигурации адресов, поиска соседей или в случае отсутствия маршрутизатора. Маршрутизаторы не должны переадресовывать пакеты с локальными адресами отправителя. Локальный адрес сети имеет формат, показанный на Рисунок 4.4.1.1.11:



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



Рисунок 4.4.1.1.11. Локальный адрес сети


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

Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя.

4.11. Эникаст-адреса

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

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

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

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


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

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

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

Эникастный адрес не может быть приписан ЭВМ IPv6, таким образом, он может принадлежать только маршрутизатору.

4.11.1. Необходимые эникаст-адреса

Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на Рисунок 4.4.1.1.12:


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



Рисунок 4.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.4.1.1.33. Общий формат сообщений ICMPv6



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

Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

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

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

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

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

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

Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см.
в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.

Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.

Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.

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

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

Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

(e.1) сообщения об ошибке ICMPv6, или

(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) – чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

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

(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует.Это ограничит загрузку канала.

Существует много способов ограничения частоты посылки сообщений, например:

(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).

20.3. Сообщения об ошибках ICMPv6


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



Рисунок 4.3.3. 13 Последовательность обмена кадрами на уровне 2



Получение каждого информационного кадра (Iframe) должно быть в конце концов подтверждено (прислан пакет RR; см. таблицу 4.3.3.1). Число Iframe, которое может быть послано, не дожидаясь подтверждения получения (размер окна), может лежать в пределах 1-127. В случае телефонии это число равно 1. Если ресурс окна исчерпан, партнер вынужден задержать отправку очередного пакета до подтверждения получения посланного ранее кадра (RR). Для выявления потери кадров используется таймер. Таймер запускается всякий раз при посылке командного кадра и останавливается при получении подтверждения. Этого таймера достаточно, чтобы проконтролировать доставку, как команды, так и отклика. Если произошел таймаут, нельзя определить, какой из этих двух кадров потерян. Кадр, поврежденный на уровне 1, будет принят с неверной FCS (frame check sequence) и по истечении времени, заданного таймером, будет произведена посылка командного кадра с битом poll=1. Партнер при этом вынужден прислать значение системной переменной, характеризующей ситуацию. По этой переменной можно судить, был ли получен исходный кадр.

Таким образом, можно идентифицировать факт потери информационного кадра (нужна ретрансмиссия) или отклика на него. После трех ретрансмиссий считается, что канал разорван, и предпринимается попытка его восстановить. FCS получается путем деления последовательности бит, начиная с адреса и кончая (но не включая) началом fcs, на образующий полином x16+x12+x5+1. Практически это делается с использованием сдвигового регистра, который в исходном состоянии устанавливается в единичное состояние. В конечном результате в регистре оказывается код остатка от деления. Дополнение по модулю 1 этого остатка и есть FCS.


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



Рисунок 4.3.3.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 исходного пакета содержит нераспознанный код следующего заголовка.

20.4. Информационные сообщения ICMPv6



Сообщение 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].

Литература

[1]

Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987.

[2]

Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[3]

Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

[4]

Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress.

[ALLOC]

Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, cisco Systems, December 1995

[ANYCST]

Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, BBN, November 1993.

[CIDR]

Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.

[IPV6]

Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995.

[IPv6-ADDR]

Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

[IPv6-DISC]

Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Work in Progress

[MULT]

Deering, S., "Host Extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989

[NSAP]

Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and TP over IPv6", Work in Progress.

[RFC-791]

Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[RFC-792]

Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981

[RFC-1112]

Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

[RFC-1122]

Braden, R., "Requirements for Internet Hosts -Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989

[RFC-1191]

Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, DECWRL, Stanford University, November 1990.

[RFC-1661]

Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

[RFC-1700]

Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[RFC-1825]

Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.

[RFC-1826]

Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995.

[RFC-1827]

Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC 1827, Naval Research Laboratory, August 1995

[RFC-1885]

Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995.

[RFC-1884]

Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995

[RFC-1933]

Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark. April 1996

[RFC-1970]

Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark & W. Simpson. August 1996.

[RFC-1971]

IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August 1996.

[RFC-1972]

A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996.

[RFC-2019]

Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996.

[RFC-2030]

Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996.

[RFC-2080]

RIPng for IPv6. G. Malkin, R. Minnear. January 1997.

[RFC-2133]

Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997.
<
/p>




Соотношение мультикастинговых 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).



Ссылки



Ссылки

[1]

Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC-2194, September 1997.

[2]

Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC-2138, April 1997.

[3]

Rigney C., "RADIUS Accounting", RFC-2139, April 1997.

[4]

Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC-1035, November 1987.

[5]

Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC-821, August 1982.

[6]

Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.

[7]

Crocker, D. and P. Overrell, "Augmented BNF for Syntax Specifications: ABNF", RFC-2234, November 1997.

[8]

Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC-2401, November 1998.

[9]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC-2119, March 1997.



Структура информационного поля для 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.



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



Рисунок 4.3.3. 7 Структура кадра для слоя 2



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

Каждый кадр начинается и завершается одной и той же последовательностью (сигнатура начала/конца кадра). Размер управляющего поля зависит от типа кадра (1 или 2 октета). Информационные элементы присутствуют только в кадрах, содержащих данные 3-го уровня. Формат двухбайтного поля адреса для уровня 2 показан на Рисунок 4.3.3.7. Адрес имеет лишь локальное значение и известен только участникам процедуры обмена. Формат байтов адреса показан на Рисунок 4.3.3.8.


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



Рисунок 4.4.1.1.15. Структура вложения пакетов для IPv6



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

Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути доставки, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок заголовка IPv6.

Если в результате обработки заголовка узлу необходимо перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered " - встретился нераспознаваемый тип следующего заголовка) и поле - указатель на не узнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка равный нулю в заголовке, отличном от IPv6-заголовка.

Каждый заголовок расширения имеет длину кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е., поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8.

IPv6 включает в себя следующие заголовки расширения:

Опции hop-by-hop

Маршрутизация (routing;тип 0)

Фрагмент

Опции места назначения

Проверка прав доступа (authentication)

Поле безопасных вложений (encapsulating security payload)



Последние два описаны в RFC-1826 и RFC-1827.

5.1. Порядок заголовков расширения

Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:

IPv6 заголовок

Заголовок опций hop-by-hop

Заголовок опций места назначения (destination options header, (1) )

Заголовок маршрутизации

Заголовок фрагмента

Заголовок authentication (2)

Заголовок безопасных вложений (encapsulating security payload, (2) )

Заголовок опций места назначения (destination options header (3) )

Заголовок верхнего уровня.

(1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.

(2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.

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

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

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

Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком.

6. Опции

Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (


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



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


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



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



Таблица 4.4.1.1.1


Назначение Префикс (двоичный) Часть адресного пространства
Зарезервировано 0000 0000 1/256
Не определено 0000 0001 1/256
Зарезервировано для NSAP 0000 001 1/128
Зарезервировано для IPX 0000 010 1/128
Не определено 0000 011 1/128
Не определено 0000 1 1/32
Не определено 0001 1/16
Не определено 001 1/8
Провайдерские уникаст-адреса 010 1/8
Не определено 011 1/8
Зарезервировано для географических уникаст-адресов 100 1/8
Не определено 101 1/8
Не определено 110 1/8
Не определено 1110 1/16
Не определено 1111 0 1/32
Не определено 1111 10 1/64
Не определено 1111 110 1/128
Не определено 1111 1110 0 1/512
Локальные канальные адреса 1111 1110 10 1/1024
Локальные адреса (site) 1111 1110 11 1/1024
Мультикаст-адреса 1111 1111 1/256

Замечание: Не специфицированные адреса, адреса обратной связи и IPv6 адреса со встроенными IPv4 адресами, определены вне “0000 0000” префиксного пространства.
Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы). Пятнадцать процентов адресного пространства уже распределено. Остальные 85% зарезервированы.
Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного пространства, и синтаксически неотличимы от них.
4.3. Уникастные адреса
IPv6 уникастный адреса, сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Class-less InterDomain Routing - CIDR).
Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Site-local-use адрес, Link-local-use адрес и IPv4-compatible host address. В будущем могут быть определены дополнительные типы адресов.
Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры. То есть представляет собой 128 битовый неструктурированный образ.
ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:

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



Таблица 4.2.1.1


Код n Назначение в сервере
0 Контрольная сумма не используется
1 Контрольная сумма используется, если доступна клиенту
2 Контрольная сумма должна использоваться
То же для клиента
0 Контрольная сумма не используется (по умолчанию)
1 Контрольная сумма используется, но лишена приоритета
2 Контрольная сумма используется и имеет приоритет
3 Контрольная сумма должна использоваться

Поле Длина пакета (2 байта) содержит число байт в пакете, включая заголовок, и может лежать в пределах от 30 (только заголовок) до 576. В действительности максимальная длина IPX-пакета равна 1518 байт, но при прохождении пакетов через маршрутизаторы, когда не используется протокол LIP(large internet packet, протокол межсетевой пересылки больших пакетов) максимальная длина может быть равной лишь 576 байт (что и принято по умолчанию). Следует также иметь в виду, что согласно регламентациям Novell длина пакета может принимать только четные значения. Программист не должен беспокоиться о содержании этого поля, это за него сделает сам протокол IPX. Поле управление пересылкой (1 байт) устанавливается IPX-драйвером равным нулю перед посылкой пакета. Каждый маршрутизатор увеличивает значение этого поля на 1. Если пакет прошел через 15 маршрутизаторов, очередной - удалит пакет из сети (в некотором смысле это аналог поля время жизни - TTL в протоколах TCP/IP). Поле управление пересылкой можно использовать для оптимизации маршрутов в локальной сети. Если станция общается только с серверами соседней субсети, ее следует переключить туда и снизить тем самым нагрузку маршрутизатора. Контроль за содержимым этого поля выполняется протоколом IPX. Поле тип пакета (1 байт) устанавливается прикладной программой. При использовании протокола ipx это поле должно содержать нуль (или 4), в случае использования протокола SPX - 5, а для протокола NCP(Netware core protocol) -17. Поля адрес узла назначения и адрес узла отправителя содержат 12-байтовые структуры ipxaddr_1.

Таблица



Таблица 4.4.1.3.


Значение флага Назначение
0 Записать только временные метки; опустить ip-адреса.
1 Записать перед каждой временной меткой ip-адрес (как в формате на предыдущем рисунке).
3 ip-адреса задаются отправителем; маршрутизатор записывает только временные метки, если очередной IP-адрес совпадает с адресом маршрутизатора

Временные метки должны содержать время в миллисекундах, отсчитанное от начала суток.
Взаимодействие других протоколов с IP можно представить из схемы на Рисунок 4.4.1.5. В основании лежат протоколы, обеспечивающие обмен информацией на физическом уровне, далее следуют протоколы IP, ICMP, ARP, RARP, IGMP и протоколы маршрутизаторов. Чем выше расположен протокол, тем более высокому уровню он соответствует. Протоколы, имена которых записаны в одной и той же строке, соответствуют одному и тому же уровню. Но все разложить аккуратно по слоям невозможно - некоторые протоколы занимают промежуточное положение, что и отражено на схеме, (области таких протоколов захватывают два уровня. Здесь протоколы IP, ICMP и IGMP помещены на один уровень, для чего имеется не мало причин. Но иногда последние два протокола помещают над IP, так как их пакеты вкладываются в IP-дейтограммы. Так что деление протоколов по уровням довольно условно. На самом верху пирамиды находятся прикладные программы, хотя пользователю доступны и более низкие уровни (например, ICMP), что также отражено на приведенном рисунке (4.4.1.5).

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



Таблица А


A 4-килогерцный аналоговый телефонный канал
B Цифровой ИКМ-канал для голоса и данных с полосой 64 кбит/c
C Цифровой канал с полосой 8 или 16 кбит/c
D Цифровой канал для внедиапазонного управления с полосой 16 кбит/c
E Цифровой канал isdn для внутреннего управления с полосой 64 кбит/c
H Цифровой канал с полосой 384, 1536 или 1920 кбит/c

Следует обратить внимание на то, что базовый ISDN-канал содержит два В-канала по 64 кбит/c и один D-канал с 16 кбит/c. Первичный же isdn-канал содержит 24 или 30 стандартных В-каналов и один D-канал с полосой 64 кбит/c.
На первом уровне протокола разрешаются конфликты доступа терминалов к D-каналу. Активация и деактивация осуществляется сигналом <info>. info=0 означает отсутствие сигнала в линии. info=1 передает запрос активации от терминала к NT. info=2 передается от NT к TE с целью запроса активации или указывает, что NT активировано вследствие появления info=1.

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

IAM

(initial address message) используется для инициализации канала, передачи маршрутной информации и параметров запроса.

SAM

(subsequent address message) посылается вслед за iam, когда необходимо передать дополнительную информацию о предстоящей сессии.

INR

(information request message) посылается коммутатором для получения информации по текущей сессии.

INF

(information message) передает информацию, запрошенную inr.

ACM

(address complete message) подтверждает получение всей необходимой маршрутной информации.

CPG

(call progress message) посылается адресатом вызывающей стороне и информирует о том, что имело место какое-то событие.

ANM

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

FAR

(facility request message) посылается одним коммутатором другому для активации его состояния.

FAA

(facility accepted message) является позитивным откликом на запрос far.

FRJ

(facility reject message) отклик на запрос far, если он не может быть выполнен.

USR

(user-to-user information message) используется для обмена информацией между пользователями (помимо сигнальной информации).

CMR

(call modification request message) сообщение, которое может быть послано в любом направлении, для модификации сессии, например, для перехода от передачи данных к передаче голоса.

CMC

(call modification completed message) сообщение-отклик на запрос CMR, подтверждающее его исполнение.

CMRJ

(call modification reject message) сообщение-отклик на запрос cmr, оповещающее об отклонении этого запроса.

REL

(release message) сообщение, посылаемое в любом направлении и оповещающее о том, что система свободна и готова перейти в пассивное состояние при получении сообщения о завершении процедуры release.

RLC

(release complete message) - посылается в ответ на REL.

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



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



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

Быстродействие первичного канала

Кодировка

Импеданс линии

Временной домен d-канала

Уровень сигнала

1,544 Мбит/с

B8ZS

100 Ом

24

3 В

2,048 Мбит/с

HDB3

120 Ом

16

3 В

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

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

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

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



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



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



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



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



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



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

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

Описание

0

ЭВМ не может ни посылать, ни принимать данные

1

ЭВМ может только посылать пакеты в процессе IP-мултикастинга

2

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

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



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



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

Код поля М

Мнемоника

Назначение

00000

UI

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

00001

SNRM

Установка нормального отклика (set normal regime mode)

00010

DISC/RD

Отсоединение (disconnect / request disconnect)

00100

up

Ненумерованный запрос передачи (unnumbered poll)

00110

ua

Ненумерованный отклик (unnumbered acknowledgment)

00111

test

Тестирование системы передачи данных

10000

SIM/RIM

Установка режима асинхронного отклика (set initialization mode / request initialization mode)

10001

FRMR

Отклонение кадра (frame reject)

11000

SARM/DM

Установка режима асинхронного отклика (set asynchronous acknowledgment regime mode / disconnect mode)

11001

RSET

Сброс (возврат в исходное состояние)

11010

SARME

SARM с расширенной нумерацией

11011

SNRME

snrm с расширенной нумерацией

11100

SAMB

Установка асинхронного сбалансированного режима

11101

XID

Идентификация коммутатора (exchange identifier)

11110

SABME

SABM с расширенной нумерацией

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



Коды поля S



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

Код s-поля

Назначение

00

RR-кадр (receiver ready) готов к приему

01

RNR-кадр (receiver not ready) не готов к приему

10

REJ-кадр (reject) отказ от приема

11

SREJ-кадр (selected reject) выборочный отказ от приема

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



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



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


Код протокола Интернет Сокращенное название протокола Описание

0

-

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

1

ICMP

Протокол контрольных сообщений [rfc792]

2

IGMP

Групповой протокол управления [rfc1112]

3

GGP

Протокол маршрутизатор-маршрутизатор [RFC-823]

4

IP

IP поверх IP (инкапсуляция/туннели)

5

ST

Поток [rfc1190]

6

TCP

Протокол управления передачей [RFC-793]

7

UCL

UCL

8

EGP

Протокол внешней маршрутизации [RFC-888]

9

IGP

Протокол внутренней маршрутизации

10

BBN-MON

BBN-RCC мониторирование

11

NVP-II

Сетевой протокол для голосовой связи [RFC-741]

12

PUP

PUP

13

ARGUS

argus

14

Emcon

emcon

15

Xnet

Перекрестный сетевой отладчик [IEN158]

16

Chaos

Chaos

17

UDP

Протокол дейтограмм пользователя [RFC-768]

18

MUX

Мультиплексирование [IEN90]

19

DCN-MEAS

DCN измерительные субсистемы

20

HMP

Протокол мониторирования ЭВМ (host [RFC-869])

21

PRM

Мониторирование при передаче пакетов по радио

22

XNS-IDP

Xerox NS IDP

23

Trunk-1

Trunk-1

24

Trank-2

Trunk-2

25

Leaf-1

Leaf-1

26

Leaf-2

Leaf-2

27

RDP

Протокол для надежной передачи данных [RFC-908]

28

IRTP

Надежный TP для Интернет [RFC-938]

29

ISO-TP4

iso транспортный класс 4 [RFC-905]

30

Netblt

Массовая передача данных [RFC-969]

31

MFE-NSP

Сетевая служба MFE

32

Merit-INP

Межузловой протокол Merit

33

SEP

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

34

  не определен

35

IDRP

Междоменный протокол маршрутизации

36

XTP

Xpress транспортный протокол

37

DDP

Протокол доставки дейтограмм

38

IDPR-CMTP

IDPR передача управляющих сообщений

39

TP++

TP++ транспортный протокол

40

IL

IL-транспортный протокол

41

SIP

Простой Интернет-протокол

42

SDRP

Протокол маршрутных запросов для отправителя

43

SIP-SR

SIP исходный маршрут

44

SIP-Frag

SIP-фрагмент

45

IDRP

Интер-доменный маршрутный протокол

46

RSVP

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

47

GRE

Общая инкапсуляция маршрутов

49

BNA

BNA

50

SIPP-ESP

SIPP ESЗ

52

I-NLSP

Интегрированная система безопасности сетевого уровня

53

Swipe

IP с кодированием

54

NHRP

nbma протокол определения следующего шага

55-60

  не определены

61

  Любой внутренний протокол ЭВМ

62

CFTP

CFTP

63

  Любая локальная сеть

64

Sat-Expak

Satnet и Expak

65

MIT-Subn

Поддержка субсетей MIT

66

RVD

Удаленный виртуальный диск MIT

67

IPPC

IPPC

68

  Любая распределенная файловая система

69

Sat-Mon

Мониторирование Satnet

70

  не определен

71

IPCV

Базовая пакетная утилита

75

PVP

Пакетный видео-протокол

76

BRsat-Mon

Резервное мониторирование Satnet

78

Wb-mon

Мониторирование Expak

79

Wb-expak

Широкополосная версия Expak

80

ISO-IP

iso Интернет протокол

88

IGRP

IGRP (Cisco) - внутренний протокол маршрутизации

89

OSPFIGP

OSPFIGP - внутренний протокол маршрутизации

92

MTP

Транспортный протокол мультикастинга

101-254

  не определены

255

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



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



Таблица 4.2.1.3 Коды тип сервера (cм. также

ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-numbers)

Тип сервера

Описание

0x0001

Пользователь

0x0004

Файл-сервер

0x0005

Сервер заданий

0x0006

Внешний сетевой порт (gateway)

0x0007

Принт-сервер

0x0009

Сервер архива

0x000a

Очередь задач

0x0017

Диагностика

0x0020

NetBios

0x0021

NAS SNA порт

0x0027

TCP/IP сервер порта

0x0028

Сервер моста x.25 точка-точка

0x02e

Динамический SAP

0x0047

Оповещающий принт-сервер

0x004b

vap 5.0

0x004c

SQL VAP

0x007a

TES-NetWare VMS

0x0098

Сервер доступа к NetWare

0x009a

Сервер именованных труб

0x009e

Портативный NetWare-Unix

0x0107

NetWare 386

0x0111

Тест-сервер

0x0166

Управление NetWare

0x026a

Управление NetWare

0x026b

Временная синхронизация

0x0278

Сервер каталогов NetWare

SAP-пакеты-отклики (периодически рассылаемые пакеты) имеют следующий формат (Рисунок 4.2.1.5).



Коды типа IPX-пакета



Таблица 4.2.1.2 Коды типа IPX-пакета.

Тип пакета

Значение

0

Обычный IPX-пакет

1

Пакет с маршрутной информацией (RIP - routing information protocol)

2

Отклик

3

Ошибка

4

Информационный пакетный обмен (pep - packet exchange protocol)

5

Последовательный пакетный обмен (SPX - sequence packet exchange)

17

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

20

Именной пакет netbios (широковещательный)

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

Маршрутная информация передается между серверами и маршрутизаторами. Динамический маршрутный протокол RIP (routing information protocol, базируется на стандарте Xerox IP; cм. также RFC-1058) обеспечивает конечные станции информацией, которая необходима для динамического управления оптимизацией маршрутов. Рассылка маршрутной информации производится с помощью широковещательных пакетов. Как видим, сети Novell являются источником значительных потоков широковещательных пакетов. Аналогичным образом объекты сети оповещаются о других изменениях в сетевой среде, например, рассылка информации о доступных услугах (SAP - service advertisement protocol). Протокол SAP позволяет узлам, которые предлагают определенные услуги (например, файл-серверы или принт-серверы), сообщать о своих адресах и видах доступных услуг. Администратор может регулировать поток таких пакетов, задавая постоянные времени для таймеров обновления информации. Маршрутизаторы рассылают маршрутную информацию в пяти случаях:

При инициализации.

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

Периодически для обновления маршрутных таблиц.

При изменении конфигурации маршрутов.

При отказе или отключении маршрутизатора.

Маршрутизация пакетов в сети достаточно проста. Каждому сетевому сегменту маршрутизатор присваивает номер в пределах от 1 до fffffffe. Каждой группе устройств присваивается “сетевой номер”, который представляет эту группу во всех маршрутизаторах сети. Пакеты, посылаемые от одного члена группы другому, посылаются непосредственно. Пакеты от одного члена группы к объекту из другой группы будут пересланы через маршрутизаторы. Для выбора маршрута в пределах локальной сети используется маршрутный протокол RIP. Формат пакета NetWare RIP показан на Рисунок 4.2.1.3.



Коды типов сообщений



Таблица 4.3.3.2 Коды типов сообщений

8

7

6

5

4

3

2

1

Значение сообщение

0

0

0

0

0

0

0

0

Переход к определенным типам сообщений:

0

0

0

-

-

-

-

-

Сообщения о состоянии:

 

 

0

0

0

0

1

Alerting (оповещение)

 

 

 

0

0

0

1

0

Call proceeding (состояние запроса)

 

 

 

0

0

0

1

1

Progress (прогресс)

 

 

 

0

0

1

0

1

Setup (начальная установка)

 

 

 

0

0

1

1

1

Connect (соединение)

 

 

 

0

1

1

0

1

Setup acknowledge (подтверждение начальной установки)

 

 

 

0

1

1

1

1

Connect acknowledge (подтверждение соединения)

0

0

1

-

-

-

-

-

Сообщения фазы запроса информации:

 

 

 

0

0

0

0

0

User information (пользовательские данные)

 

 

 

0

0

0

0

1

Suspend reject (отложенный отказ)

 

 

 

0

0

0

1

0

Resume reject (отказ возобновления)

 

 

 

0

0

1

0

1

Suspend (откладывание выполнения)

 

 

 

0

0

1

1

0

Resume (возобновление)

 

 

 

0

1

1

0

1

Suspend acknowledge (подтверждение откладывания)

 

 

 

0

1

1

1

0

Resume acknowledge (подтверждение возобновления)

0

1

0

-

-

-

-

-

Сообщения об устранении дефекта:

 

 

 

0

0

1

0

1

Disconnect (отсоединение)

 

 

 

0

0

1

1

0

Restart (повторный старт)

 

 

 

0

1

1

0

1

Release (освобождение)

 

 

 

0

1

1

1

0

Restart acknowledge (подтверждение повторного старта)

 

 

 

1

1

0

1

0

Release complete (освобождения завершено)

0

1

1

-

-

-

-

-

Прочие сообщения:

 

 

 

0

0

0

0

0

Segment (сегмент)

 

 

 

0

0

0

1

0

Facility (возможность)

 

 

 

0

1

1

1

0

Notify (обращение внимания)

 

 

 

1

0

1

0

1

Status inquiry (запрос состояния)

 

 

 

1

1

0

0

1

Congestion control (управление перегрузкой)

 

 

 

1

1

0

1

1

Information (информация)

 

 

 

1

1

1

0

1

Status (состояние)

* Цифрами в верхней части таблицы пронумерованы биты кодов

В приведенной ниже таблице 4.3.3.3 представлены информационные элементы, которые могут содержаться в сообщениях Setup (это самый сложный тип сообщений).



Поля setup-сообщений



Таблица 4.3.3.3. Поля setup-сообщений

Поле в пакете

Длина (октеты)

Комментарии

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

1

Код запроса 2-3  
Тип сообщения 1  
Передача завершена 1 Опционно, включается, если пользователь или сеть указывает, что вся информация включена в это сообщение Setup
Возможности канала 6-8 Описывает CCITT телекоммуникационные услуги (BC)
Идентификация канала 2-? Служит для идентификации канала в пределах isdn-интерфейса, управляемого данными процедурами
Специфические возможности сети 2-? Опционно
Дисплей 2-82 Опционно: IA5 (ASCII) символы для отображения на терминале
keypad 2-34 Альтернатива для пересылки кода вызываемого объекта. keypad может использоваться и для другой информации
Номер отправителя 1-? Опционно
Субадрес отправителя 2-23 Опционно
Номер адресата 2-? В случае направления пользователь-сеть является альтернативой keypad
Субадрес адресата 2-23 Опционно
Выбор транзитной сети 2-? Опционно
Совместимость с нижним уровнем (llc) 2-16 Опционно
Совместимость с верхним уровнем (hlc) 2-4 Опционно
Пользователь-пользователь 2-131 Опционно, когда вызывающий пользователь хочет передать информацию вызываемому

Сигнальная система ISDN позволяет пользователю уже на фазе формирования канала с помощью запроса setup сформулировать требования к каналу, задав значение BC (bearer capability, см. таблицу 4.3.3.3), а также HLC (high layer compatibility) и LLC (low layer compatibility), характеризуя необходимый вид услуг. При этом проверяется совместимость запрашиваемых скоростей и имеющихся в распоряжении возможностей. HLC определяет тип сервиса или оборудования (телефон, факс группы 3 или 4, видеотекст), а LLC - быстродействие терминала пользователя, механизм адаптации к скорости передачи данных, контроль четности, синхронный/асинхронный интерфейс и т.д.). BC может принимать значения (например, “BC=speech”):

BC= speech Означает, что используется обычная для этого вида услуг маршрутизация - может быть задействовано не более двух спутников, (G.711);
3.1khz audio Не должно использоваться эхо-подавление и dcme - (digital circuit multiplication equipment - оборудование уплотнения), необходим m/a-адаптер
7 khz Высококачественная телефония (рекомендации CCITT G.722/G.725), требует 64 Кбит/с;
  64kbit/s unrestricted Скоростной информационный обмен
<
Услуги типа speech или 3.1 khz audio возможны и через общественную коммутируемую телефонную сеть (PSTN), остальные из перечисленных требуют 64-килобитного цифрового канала. Схема формирования запроса, получения доступа к определенному виду услуг показана ниже на рисунке 4.3.3.18. Помимо названных услуг существуют и другие, например, видео-телефония, видеоконференции и пр., список этот постоянно расширяется. При реализации 7кГц-телефонии должны быть выполнены следующие требования:
Должно использоваться терминальное оборудование, рассчитанное для работы с 3.1кГц, и обычные сетевые телефонные каналы.
Время реализации вызова должно быть приемлемо малым.
Система должна выдавать сообщение в случае, если в результате диалога реализуется 3.1кГц вместо 7.
Видео телефония использует один или два B-канала. В Европе приняты следующие нормы (normes europeennes de telecommunication-net):

Net3 isdn с обычной (базовой) скоростью обмена
Net5 isdn с первичной скоростью обмена (64кбит/с)
Net7 терминальные адаптеры
Net33 цифровая телефония.

См также раздел о протоколе X)



Таблица 4.3.3.1. (См. также раздел о протоколе X.25)

Кодировка байтов

Команда

Отклик

8

7

6

5

4

3

2

1

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

iframe

-

N(S)

0

Iframe

-

N(R

P/td>

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

RR

RR

0

0

0

0

0

0

0

1

RR

RR

N(R)

P/F

RNR

RNR

0

0

0

0

0

1

0

1

RNR

RNR

N(R)

P/F

REJ

REJ

0

0

0

0

1

0

0

1

REJ

REJ

N(R)

P/F

Ненумерованные кадры

SABME

-

0

1

1

p

1

1

1

1

-

DM

0

0

0

f

1

1

1

1

UI

-

0

0

0

p

0

0

1

1

DISC

-

0

1

0

p

0

0

1

1

-

UA

0

1

1

f

0

0

1

1

-

FRMR

1

0

0

f

0

1

1

1

P/F

poll=1 для команды, в противном случае конечный бит для отклика.

Iframe

(information frame) Информационный кадр

DISC

(disconnect) Отсоединить

RR

(receiver ready) Приемник готов

UA

(unnumbered acknowledge) Ненумерованное подтверждение

RNR

(receiver not ready) Приемник не готов

FRMR

(frame reject) Кадр отвергнут

REJ

(reject) Отказ

DM

(disconnect mode) Режим отключения

SABME

(set asynchronous balanced mode extended) Установка расширенного асинхронного сбалансированного режима

UI

(unnumbered information) Ненумерованная информация.

Ниже на Рисунок 4.3.3.15 показана схема алгоритма восстановления после потери кадра RR.



Типы и коды ICMP-сообщений



Таблица 4.4.4.1. Типы и коды ICMP-сообщений.

icmp-сообщение

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

0

Эхо-ответ (ping-отклик)

3

  Адресат недостижим

0

* Сеть недостижима

1

* ЭВМ не достижима

2

* Протокол не доступен

3

* Порт не доступен

4

* Необходима фрагментация сообщения

5

* Исходный маршрут вышел из строя

6

* Сеть места назначения не известна

7

* ЭВМ места назначения не известна

8

* Исходная ЭВМ изолирована

9

* Связь с сетью места назначения административно запрещена

10

* Связь с ЭВМ места назначения административно запрещена

11

* Сеть не доступна для данного вида сервиса

12

* ЭВМ не доступна для данного вида сервиса

13

* Связь административно запрещена с помощью фильтра.

14

* Нарушение старшинства ЭВМ

15

* Дискриминация по старшинству

4

0

* Отключение источника при переполнении очереди

5

  Переадресовать (изменить маршрут)

0

Переадресовать дейтограмму в сеть (устарело)

1

Переадресовать дейтограмму на ЭВМ

2

Переадресовать дейтограмму для типа сервиса (tos) и сети

3

Переадресовать дейтограмму для типа сервиса и ЭВМ

8

0

Эхо запроса (ping-запрос).

9

0

Объявление маршрутизатора

10

0

Запрос маршрутизатора

11

  Для дейтограммы время жизни истекло (ttl=0):

0

*при передаче

1

* при сборке (случай фрагментации).

12

  * Проблема с параметрами дейтограммы

0

* Ошибка в ip-заголовке

1

* Отсутствует необходимая опция

13

  Запрос временной метки

14

  Временная метка-отклик

15

  Запрос информации (устарел)

16

  Информационный отклик (устарел)

17

  Запрос адресной маски

18

  Отклик на запрос адресной маски

Процедура "отключение источника" (quench, поле тип ICMP=4) позволяет управлять потоками данных в каналах Интернет. Не справляясь с обработкой дейтограмм, ЭВМ-адресат может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на Рисунок 4.4.4.2) представлен формат эхо-запроса (ping) и отклика для протокола ICMP.



Зарезервированные мультикастинг-адреса



Таблица 4.4.9.2. Зарезервированные мультикастинг-адреса

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

Описание

224.0.0.0

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

224.0.0.1

Все системы данной субсети

224.0.0.2

Все маршрутизаторы данной субсети

224.0.0.4

Все DVMRP-маршрутизаторы

224.0.0.5-224.0.0.6

OSPFIGP (MOSPF)

224.0.0.9

Маршрутизаторы RIP2

224.0.0.10

IGRP маршрутизаторы

224.0.1.0

VMTP-группа менеджеров

224.0.1.1

NTP-network time protocol - сетевая службы времени

224.0.1.6

NSS - сервер имен

224.0.1.7

Audionews - audio news multicast (аудио служба новостей)

224.0.1.9

MTP (multicast transport protocol) - транспортный протокол мультикастинга

224.0.1.10

IETF-1-low-audio

224.0.1.11

IETF-1-audio

224.0.1.12

IETF-1-video

224.1.0.0-224.1.255.255

ST мультикастинг-группы

224.2.0.0-224.2.255.255

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

232.0.0.0-232.255.255.255

VMTP переходные группы

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



Значения кодов приоритета



Таблица 4.4.1.1.2. Значения кодов приоритета

Код приоритета

Назначение

0

Нехарактеризованный трафик

1

Заполняющий трафик (например, сетевые новости)

2

Несущественный информационный трафик (например, электронная почта)

3

Резерв

4

Существенный трафик (напр., FTP, HTTP, NFS)

5

Резерв

6

Интерактивный трафик (напр. telnet, x)

7

Управляющий трафик Интернет (напр., маршрутные протоколы, snmp)

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

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

14. О протоколе верхнего уровня

14.1 Контрольные суммы верхнего уровня

Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (Рисунок 4.4.1.1.26):



Терминальный ISDN-интерфейс



Рисунок 4.3.3.5 Терминальный ISDN-интерфейс


Нормальная амплитуда сигнала составляет 750 мВ. Формат кадра первого уровня показан на Рисунок 3.5.3.6, он содержит 48 бит и имеет длительность 250 мксек. Физическая скорость обмена составляет 192 Кбит/с (~5,2 мксек на бит). Блок-схема терминального ISDN-интерфейса показана на Рисунок 4.3.3.5. Питание интерфейса осуществляется через 4-проводный выходной кабель. На вход интерфейса подается импульсно-кодовый модулированный сигнал (ИКМ). Интерфейс обеспечивает доступ к B- и D-каналам. Номинальное смещение в начале кадра в случае обмена терминал-сеть, как показано на Рисунок 4.3.3.6, составляет 2 бита. В некоторых случаях оно может оказаться больше из-за задержек в кабеле. Кадр включает в себя несколько l-битов, которые служат для балансировки цуга по постоянному току. Для направления NT -> TE (связь сетевого оборудования с терминальным) первыми битами кадра являются F/L-пары (см. начало и конец диаграмм; временная ось направлена слева направо), нарушающие AMI-правила (чередование полярности сигнала при передаче логической единицы). Раз чередование нарушено, до завершения кадра должно присутствовать еще одно такое нарушение. Бит FA реализует это второе нарушение чередования полярности. A-бит используется в процедуре активации для того, чтобы сообщить терминалу о том, что система синхронизована. Активация может проводиться по инициативе терминала или сетевого оборудования, а деактивация может быть выполнена только сетью. Помимо B1, B2 (байты выделены стрелками) и D-каналов формируются также виртуальные E- и A-каналы. E-канал служит для передачи эхо от NT1 к TE в D-канале. Существует 10-битовое смещение (задержка) между D-битом, посылаемым терминалом, и E-битом эхо (отмечено стрелкой на Рисунок 4.3.3.6). M-бит используется для выделения мультифреймов (эта услуга недоступна в Европе). M-бит идентифицирует некоторые FA-биты, которые могут быть изъяты для того, чтобы сформировать канал управления (например, при проведении видеоконференций). S-бит является резервным. Назначения различных вспомогательных каналов собраны в таблице А.



Услуги ISDN в режиме переключения



Рисунок 4.3.3.23 Услуги ISDN в режиме переключения (цифрами помечены уровни протоколов, в скобках приведены ссылки на документы ITU)


На сигнальном уровне C-плоскости используются стандартные LAPD-процедуры слоя 2 (Q.921 или I.441), а для слоя 3 спецификация кадрового режима (Q.933). Но на U-плоскости сеть поддерживает только небольшую часть связного протокола:

разделение кадров с использованием HDLC-флагов;

проверка кадров по длине и контрольной сумме, выбрасывание кадров с ошибками;

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

В простейшем случае сеть посредством сигнальных процедур на фазе Setup формирует вход в маршрутную таблицу. На уровне 2 для каждого виртуального запроса выделяется адрес, который остается действительным только на время данного вызова. При пересылке данных сеть просто индексирует маршрутную таблицу, используя адреса слоя 2 поступающих кадров, и ставит их в очередь на передачу по соответствующему маршруту. На фазе передачи информации терминалы используют протоколы более высокого уровня по схеме точка-точка без привлечения сети. Схема протокола коммутации кадров показана ниже на Рисунок 4.3.3.24, здесь передача кадров происходит с подтверждением получения (до какой-то степени аналог протокола tcp). Сеть детектирует потери и случаи дублирования пакетов.

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

Как и в предыдущем случае мультиплексирование и демультиплексирование выполняется с использованием адресов слоя 2. Адрес кадра может содержать 2-4 октетов, а информация занимать от 1 до 262 октетов. Последняя величина может быть и увеличена в результате переговоров между отправителем и получателем при формировании виртуального канала. Рекомендуется не использовать кадров с размером поля данных более 1600 октетов во избежании фрагментации и последующей сборки сообщений.



Виртуальный интерфейс между слоями



Рисунок 4.3.3. 9 Виртуальный интерфейс между слоями 2 и 3



Как видно из рисунка в системе могут использоваться и идентичные коды TEI, если они относятся к разным видам услуг (несовпадающими должны быть лишь комбинации SAPI-TEI). Для кодирования сигналов в ISDN используется метод 2B1Q (2 binary into 1 quaternary), что соответствует

Код Уровень
10 +2.5 v
11 +0.833 v
01 -0.833 v
00 -2.5 v
Форматы полей управления для кадров различных модификаций представлены на рисунках 4.3.3.10, 4.3.3.11 и 4.3.3.12.


Восстановление системы после потери кадра RR



Рисунок 4.3.3.15 Восстановление системы после потери кадра RR


Сигнал RNR(получатель не готов) используется для запрета пересылки пакетов партнеру на уровне 2 и может использоваться при реализации приоритетных услуг. Другим пакетом, который специфицирован на уровне 2, является кадр frame reject (FRMR). Этот кадр может быть получен объектом второго уровня, но не может быть послан. При получении этого кадра система сбрасывается в исходное состояние. После завершения процедуры обмена разрыв канала производится путем посылки кадров DISC (disconnect) и отклика UA (unnumbered acknowledgment), с этого момента обмен кадрами I-типа не возможен. Кадр DM(disconnect mode) может выполнять те же функции, что и UA. Он используется в качестве отклика на SABME, если слой 2 не может установить связь, или отклика на disc, если связь уже разорвана.

Для управления и контроля за выделяемыми идентификаторами TEI предназначен специальный драйвер, который имеет возможность выделять и удалять используемые TEI. Все сообщения, связанные с TEI, передаются с помощью пакетов SAPI (service access point identifier). Так как работа с TEI должна выполняться вне зависимости от состояния уровня 2, все TEI-сообщения являются ненумерованными (UI) и не требуют отклика. Надежность достигается путем многократной пересылки пакетов. Пока терминалу не присвоен TEI (terminal endpoint identifier), используется широковещательный метод обмена. Все терминалы пользователя должны воспринимать любые управляющие кадры. Кадры управления в процессе присвоения TEI терминалу рассылаются широковещательно. Схема присвоения TEI и установления связи показана ниже на Рисунок 4.3.3.16:



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



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


Процессом передачи информации между узлами управляет сигнальная система общего канала (CCS - common channel signaling system). В ISDN используется 7-я сигнальная система CCITT (Рисунок 4.3.1.1). Ее уровни сходны, но не идентичны OSI. На нижних уровнях используется MTP (message transfer part - система передачи сообщений), задачей которой является надежная пересылка сигнальных пакетов по сети. Пользовательские (прикладные) сообщения иерархически расположены над MTP, которая имеет три уровня.

Терминальное оборудование подключается к NT через трансформатор (см. Рисунок 4.3.3.5). На входе трансиверов используются схемы защиты от переходных процессов в линиях связи.