Протокол RPC
RPC (Remote Procedure Call, Сервис вызова удаленных процедур) представляет собой интерфейс между удаленными пользователями и определенными программами хоста, которые запускаются по запросам этих пользователей. Сервис RPC какого-либо хоста, как правило, предоставляет клиентам комплекс программ. Каждая из таких программ состоит, в свою очередь, из одной или нескольких удаленных процедур. Например, сервис удаленной файловой системы NFS, который построен на вызовах RPC, может состоять только из двух программ: например, одна программа взаимодействует с высокоуровневыми пользовательскими интерфейсами, а другая — с низкоуровневыми функциями ввода-вывода.
В каждом вызове удаленной процедуры участвуют две стороны: активный клиент, который отправляет запрос вызова процедуры на сервер, и сервер, который отправляет клиенту ответ.
Примечание
Следует иметь ввиду, что термины "клиент" и "сервер" в данном случае относятся к определенной транзакции. Конкретный хост или программное обеспечение (процесс или программа) могут работать как в роли клиента, так и в роли сервера. Например, программа, которая обеспечивает работу сервиса удаленных процедур, в то же время может быть клиентом в работе с сетевой файловой системой.
Протокол RPC построен на модели вызовов удаленных процедур, подобному механизму вызовов локальных процедур. При вызове локальной процедуры вы помещаете аргументы в определенное место памяти, в стек или переменные окружения и передаете управление процессом по определенному адресу. После завершения работы вы читаете результаты по конкретному адресу и продолжаете свой процесс.
В случае работы с удаленной процедурой, основное отличие состоит в том, что вызов удаленной функции обслуживают два процесса: клиентский процесс и серверный процесс.
Процесс клиента отправляет серверу сообщение, в которое включены параметры вызываемой процедуры и ожидает ответного сообщения с результатами ее работы. При получении ответа результат считывается, и процесс продолжает работу.
Со стороны сервера процесс-обработчик вызовов находится в состоянии ожидания, и, при поступлении сообщения, считывает параметры процедуры, выполняет ее, отправляет ответ и становится в состояние ожидания следующего вызова.
RPC-протокол не накладывает каких-либо требований на дополнительные связи между процессами и не требует синхронности выполняемых функций, т. е. вызовы могут быть асинхронными и взамонезависимьши, так что клиент во время ожидания ответа может выполнять другие процедуры. Сервер RPC может выделять для каждой функции отдельный процесс или виртуальную машину, поэтому, не дожидаясь окончания работы предыдущих запросов, сразу же может принимать следующие.
Однако между вызовами локальных и удаленных процедур есть несколько важных отличий:
Принципы построения протокола
Протокол RPC может использовать несколько различных транспортных протоколов. В обязанности RPC-протокола входит только обеспечение стандартов и интерпретация передачи сообщений. Достоверность и надежность передачи сообщений целиком обеспечивается транспортным уровнем.
Однако RPC может контролировать выбор и некоторые функции транспортного протокола. В качестве примера взаимодействия между RPC и транспортным протоколом рассмотрим процедуру назначения RPC-порта работы прикладного процесса через RPC — Portmapper.
Эта функция динамически (по запросу) назначает соединению RPC определенный порт.
Функция Portmapper
используется довольно часто, поскольку набор зарезервированных для RPC транспортных портов ограничен, а количество процессов, которые потенциально могут одновременно работать очень высоко. Portmapper, например, вызывается при выборе портов взаимодействия клиента и сервера системы NFS.
Сервис Portmapper использует механизм широковещательных сообщении RPC на определенный порт — 111. На этот порт клиент отправляет широко вещательное сообщение запроса порта определенного сервиса RPC. Сервис Portmapper
обрабатывает такое сообщение, определяет адрес локального сервиса RPC и отправляет клиенту ответ. Сервис RPC Portmapper может работать как с TCP, так и с UDP-протоколами.
RPC может работать с различными транспортными протоколами, но никогда не дублирует их функции, т. е. если RPC работает поверх TCP, все заботы о надежности и достоверности соединения RPC возлагает на TCP. Одна ко, если протокол RPC установлен поверх UDP, он может обеспечивать дополнительные собственные функции обеспечения гарантированной доставки сообщений.
Примечание
Прикладные задачи могут рассматривать RPC-протокол как определенную процедуру вызова функции по сети JSR(Jump Subroutine Instruction).
Для работы RPC-протокола необходимо выполнение следующих условий:
Все сетевые или серверные ошибки имеют уникальные идентификаторы, по которым каждый из участников соединения может определить причину сбоя в работе.
При передаче RPC-сообщений поверх транспортного протокола, несколько RPC-сообщений могут располагаться внутри одного транспортного пакета. Для того чтобы отделять одно сообщение от другого, используется маркер записи (RM — Record Marker). Каждое RPC-сообщение "маркируется" ровно одним RM.
RPC-сообщение может состоять из нескольких фрагментов. Каждый фрагмент состоит из четырех байт заголовка и (от 0 до 2**31-1) данных. Первый бит заголовка указывает, является ли данный фрагмент последним, а остальные 31 бит указывают длину пакета данных.
Структура RPC формально описана на языке описания и представления форматов данных — XDR с дополнениями, касающимися описания процедур. Можно даже сказать, что язык описания RPC является расширением XDR, дополненным работой с процедурами.
Структура RPC-пакета выглядит следующим образом:
struct rpc msg {
reply body rbody;
} body;
где xid — идентификатор текущей транзакции, call_body — пакет запроса, reply_body — пакет ответа.Структура запроса выглядит примерно так:
struct call_body (
unsigned int vers;
unsigned int proc;
opaque auth cred;
opaque auth verf;
/* procedure parameters */
);
Структура ответа (reply_body) может содержать либо структуру, передаваемую в случае ошибки (тогда она содержит код ошибки), либо структуру успешной обработки запроса (тогда она содержит возвращаемые данные).
Литература
Описание RPC-протокола вы можете найти, например, в RFC-1050, RFC-1057, RFC-1831.
Алгоритмы маршрутизации
Алгоритмы маршрутизации можно дифференцировать, основываясь на нескольких ключевых характеристиках. Во-первых, на работу результирующего протокола маршрутизации влияют конкретные задачи, которые решает разработчик алгоритма. Во-вторых, существуют различные типы алгоритмов маршрутизации, и каждый из них по-разному влияет на сеть и ресурсы маршрутизации. И наконец, алгоритмы маршрутизации используют разнообразные показатели, которые влияют на расчет оптимальных маршрутов. В следующих разделах анализируются эти атрибуты алгоритмов маршрутизации.
Цели разработки алгоритмов маршрутизации
При разработке алгоритмов маршрутизации часто преследуют одну или несколько из перечисленных ниже целей:
Оптимальность
Простота и низкие непроизводительные затраты
Живучесть и стабильность
Быстрая сходимость
Гибкость
Оптимальность
Оптимальность, вероятно, является самой общей целью разработки. Она характеризует способность алгоритма маршрутизации выбирать "наилучший" маршрут. Наилучший маршрут зависит от показателей и от "веса" этих показателей, используемых при проведении расчета. Например, алгоритм маршрутизации мог бы использовать несколько пересылок с определенной задержкой, но при расчете "вес" задержки может быть им оценен как очень значительный. Естественно, что протоколы маршрутизации дожны строгo определять свои алгоритмы расчета показателей.
Простота и низкие непроизводительные затраты
Алгоритмы маршрутизации разрабатываются как можно более простыми. Другими словами, алгоритм маршрутизации должен эффективно обеспечивать свои функциональные возможности, с мимимальными затратами программного обеспечения и коэффициентом использования. Особенно важна эффективность в том случае, когда программа, реализующая алгоритм маршрутизации, должна работать в компьютере с ограниченными физическими ресурсами.
Живучесть и стабильность
Алгоритмы маршрутизации должны обладать живучестью. Другими словми, они должны четко функционировать в случае неординарных или непредвиденных обстоятельств, таких как отказы аппаратуры, условия высокой нагрузки и некорректные реализации.
Т.к. роутеры расположены в узловых точках сети, их отказ может вызвать значительные проблемы.
Часто наилучшими алгоритмами маршрутизации оказываются те, которые выдержали испытание временем и доказали свою надежность в различных условиях работы сети.
Быстрая сходимость
Алгоритмы маршрутизации должны быстро сходиться. Сходимость - это процесс соглашения между всеми роутерами по оптимальным маршрутам. Когда какое-нибудь событие в сети приводит к тому, что маршруты или отвергаются, или ставновятся доступными, роутеры рассылают сообщения об обновлении маршрутизации. Сообщения об обновлении маршрутизации пронизывают сети, стимулируя пересчет оптимальных маршрутов и, в конечном итоге, вынуждая все роутеры придти к соглашению по этим маршрутам. Алгоритмы мааршрутизации, которые сходятся медленно, могут привести к образованию петель маршрутизации или выходам из строя сети.
На Рис. 2-3 изображена петля маршрутизации. В данном случае, в момент времени t1 к роутеру 1 прибывает пакет. Роутер 1 уже был обновлен и поэтому он знает, что оптимальный маршрут к пункту назначения требует, чтобы следующей остановкой был роутер 2. Поэтому роутер 1 пересылает пакет в роутер 2. Роутер 2 еще не был обновлен, поэтому он полагает, что следующей оптимальной пересылкой должен быть роутер 1.
Поэтому роутер 2 пересылает пакет обратно в роутер 1. Пакет будет продолжать скакать взад и вперед между двумя роутерами до тех пор, пока роутер 2 не получит корректировку маршрутизации, или пока число коммутаций данного пакета не превысит допустимого максимального числа.
Гибкость
Алгоритмы маршрутизации должны быть также гибкими. Другими словами, алгоритмы маршрутизации должны быстро и точно адаптироваться к разнообразным обстоятельствам в сети. Например, предположим, что сегмент сети отвергнут. Многие алгоритмы маршрутизации, после того как они узнают об этой проблеме, быстро выбирают следующий наилучший путь для всех маршрутов, которые обычно используют этот сегмент. Алгоритмы маршрутизации могут быть запрограммированы таким образом, чтобы они могли адаптироваться к изменениям полосы пропускания сети, размеров очереди к роутеру, величины задержки сети и других переменных.
Библиографическая справка
При содействии Международной Организации по Стандартизации (ISO) уже разработаны или разрабатываются в настоящее время несколько протоколов маршрутизации. ISO ссылается на Протокол Обмена Внутридоменной Маршрутизации Промежуточных Систем (Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol (IS-IS)) как на ISO 10589. Двигательной силой стандартизации ISO документа IS-IS был комитет Х.3S3.3 Американского Национального Института Стандартов (ANSI), занимающийся сетевым и транспортным уровнями. В числе других протоколов ISO, связанных с маршрутизацией, протоколы ISO 9542 (End System to Intermediate System, или ES-IS - Конечная система-Промежуточная Система) и ISO 10747 (IS-IS Inter-Domain Routing Protocol, или IDRP - Протокол междоменной маршрутизации промежуточных систем). Об этих протоколах будет вкратце упомянуто в данной главе, однако oсновное внимание уделено внутридоменной версии IS-IS.
IS-IS базируется на работе, которая была впервые выполнена Digital Equipment Corporation при разработке Phase V DECnet. Хотя IS-IS предназначался для маршрутизации в сетях протокола CLNP ISO, со временем была разработана одна из его версий для поддержки как сетей CLNP, так и сетей IP. На эту версию IS-IS обычно ссылаются как на Integrated IS-IS
(интегрированный); ее также называют Dual IS-IS
(двойственный). Integrated IS-IS также рассматривается вкратце.
В общедоступном значении слова маршрутизация означает передвижение информации от источника к пункту назначения через об'единенную сеть. При этом, как правило, на пути встречается по крайней мере один узел. Маршрутизация часто противопоставляется об'единению сетей с помощью моста, которое, в популярном понимании этого способа, выполняет точно такие же функции. Основное различие между ними заключается в том, что об'единение с помощью моста имеет место на Уровне 2 эталонной модели ISO, в то время как маршрутизация встречается на Уровне 3. Этой разницей об'ясняется то, что маршрутизация и об'единение по мостовой схеме используют различную информацию в процессе ее перемещения от источника к месту назначения. Результатом этого является то, что маршрутизация и об'единение с помощью моста выполняют свои задачи разными способами; фактически, имеется несколько различных видов маршрутизации и об'единения с помощью мостов.
Тема маршрутизации освещалась в научной литературе о компьютерах более 2-х десятилетий, однако с коммерческой точки зрения маршрутизация приобрела популярность только в 1970 гг. В течение этого периода сети были довольно простыми, гомогенными окружениями. Крупномасштабное об'единение сетей стало популярно только в последнее время.
ES-IS
ES-IS в большей мере является протоколом обнаружения, чем протоколом маршрутизации. Через ES-IS системы ES и IS узнают друг о друге. Этот процесс известен как конфигурация (configuration). Т.к. конфигурация должна иметь место прежде, чем может начаться маршрутизация между ES, протокол ES-IS рассматривается в первую очередь.
ES-IS различает три разных типа подсетей:
Point-to-point subnetworks
Двухточечные подсети. Обеспечивают непосредственное соединение между двумя системами. Большинство последовательных каналов глобальной сети являются двухточечными сетями.
Broadcast subnetworks
Широковещательные подсети. Направляют отдельное физическое сообщение во все узлы данной подсети. Примерами широковещательных подсетей являются Ethernet и IEEE 802.3.
General-topology subnetworks
Подсети с общей топологией. Поддерживают произвольное число систем. Однако в отличие от широковещательных подсетей, величина затрат на передачу по какому-нибудь маршруту n непосредственно связана с размерами данной подсети в подсети с общей топологией. Примером подсети с общей топологией является Х.25.
Информация конфигурации передается через определенные интервалы времени с помощью сообщений двух типов. Приветственные сообщения ES (Es hello messages - ESHs) генерируются ES и отправляются в каждую IS данной подсети. Приветственные сообщения IS (IS hello messages - ISH) генерируются IS и отправляются всем ES данной подсети. Эти приветственные сообщения в основном предназначены для переноса адресов подсетей и адресов сетевого уровня тех систем, которые генерируют их.
При возможности ES-IS пытается отправить информацию конфигурации одновременно в несколько систем. В широковещательных подсетях приветственные сообщения ES-IS отправляются во все IS с помощью специальной многопунктовой адресации. IS отправляют приветственные сообщения по специальному адресу многопунктовой адресации, определенного для всех конечных систем. При работе в подсети с общей топологией ES-IS обычно не передает информацию конфигурации из-за больших затрат на передачи многопунктовой адресации.
ES- IS переносит как адреса сетевого уровня, так и адреса подсетей. Адреса сетевого уровня OSI идентифицируют либо точку доступа к услугам сети (NSAP), которая представляет собой интерфейс между Уровнями 3 и 4, либо титул об'екта сети (NET), который является об'ектом сетевого уровня в OSI IS. Адреса подсетей OSI (иногда называемые адресами точки подключения подсети - subnetwork point of attachment - SNPA) являются точками, в которых ES или IS физически подключена к какой-нибудь подсети. Адрес SNPA уникальным образом идентифицирует каждую систему, подключенную к данной подсети. В сети Ethernet, например, SNPA является 48-битовым адресом управления доступом к носителю (МАС). Часть информации конфигурации, которую передает ES-IS, представляет собой отображение соответствия между NSAP и SNPA или между NET и SNPA.
На рисунке представлены форматы пакетов ESH и ISH.
Формат пакета OSPF
Существует пять типов OSPF-пакетов. Все OSPF-пакеты начинаются со стандартного 24-баитного заголовка.
| 0 | 8 | 16 | 31 |
| Version | Type |
Packet Length |
Router ID |
||
Area ID |
||
Checksum |
Autype |
|
Authentication |
||
Authentication Data |
Формат стандартного OSPF-заголовка
Version (1 байт). Поле означает номер версии OSPF-пакета протокола, использующего данный пакет.
Type (1 байт). В зависимости от типа, пакет выполняет те или иные функции:
Type = 1 — Hello
Type =2 — Database Description
Type =3 — Link-State Request
Type =4 — Link-State Update
Type =5 — Link-Sate Acknowledgement
 | Hello. Отправляется через регулярные интервалы времени для установления и поддержания соседских взаимоотношений. На всех маршрутизаторах, подсоединенных к сети, должны быть согласованы ключевые параметры пакетов этого типа — маски сети, периоды приветствования и сигнализации обрыва контакта. Эти и другие параметры входят в состав Hello-пакетов. |
| Database Description. Пакеты описывают содержимое базы данных. Обмен этими пакетами производится при инициализации смежных маршрутизаторов, т. е. имеющих идентичные топологические базы данных. При описании базы данных может использоваться несколько таких пакетов. Для обработки таких пакетов используется процедура "переклички" (poll-response), в которой один из маршрутизаторов определяется как master, а другой как slave.
Соответственно, master отправляет эти пакеты, a slave должен отвечать за их получение. |
| Link-State Request. Запрос о состоянии канала. Обмен этими пакетами производится после того, как какой-нибудь роутер обнаруживает, например, путем проверки пакетов описания базы данных, что часть его топологической базы данных устарела. |
| Link-State Update. Пакеты корректировки состояния канала — ответ на пакеты запроса о состоянии канала. Эти пакеты используются для регулярного тиражирования LSA. В один пакет могут быть включены несколько сообщений LSA. Каждое из них несет информацию о части сети: |
 | Router links advertisements (RLA). Сообщения о каналах роутера. Описывают собранные данные о состоянии каналов роутера, связывающих его с конкретной областью. Любой роутер отправляет RLA для каждой области, к которой он принадлежит. RLA направляются через всю область, но не за ее пределы. |
| Network links advertisements (NLA). Сообщения о сетевых каналах. Они описывают все роутеры, которые подключены к сети с множественным доступом, и отправляются через область, содержащую данную сеть с множественным доступом. |
| Summary links advertisements (SLA). Суммарные сообщения о каналах. Суммируют маршруты к пунктам назначения, находящимся вне какой-либо области, но в пределах данной AS. Они генерируются роутерами границы области и отправляются через данную область. В стержневую область посылаются сообщения только о внутриобластных роутерах. В других областях рекламируются как внутриобластные, так и межобластные маршруты. |
| AS external links advertisements. Сообщения о внешних каналах AS. Описывают какой-либо маршрут к одному из пунктов назначения, который является внешним для данного AS. Сообщения о внешних каналах AS генерируются граничными роутерами AS. Этот тип сообщений является единственным типом сообщений, которые продвигаются во всех направлениях данной AS. Все другие типы сообщений продвигаются только в пределах конкретных областей. |
/p>
Packet Length (16 бит). Поле длины пакета ( в байтах) вместе со стандартным заголовком.
RouterlD (32 бита). Поле идентификатора отправителя.
ArealD (32 бита). Поле идентифицирует область, к которой принадлежит данный пакет.
Checksum (16 бит). Поле контрольной суммы пакета.
Authentication (16 бит). Поле типа аутентификации. Например, "простой пароль". Все обмены протокола OSPF проводятся с аутентификацией отправителя и его прав. Тип аутентификации устанавливается по принципу "отдельный для каждой области".
Authentication data (64 бита). Поле содержит информацию аутентификации. <
table border="0" cellpadding="0" cellspacing="0" width="100%">
Формат RIP - пакета
В данном документе описывается версия RIP протокола для сетевой архитектуры TCP/IP.
RIP работает на основе UDP-протокола и использует порт 520. На каждом хосте, использующем RIP, должно быть установлено программное обеспечение, обрабатывающее RIP-пакеты.
| 0 | 8 | 16 | 31 |
| Command (1) | Version (1) |
Must be zero (2) |
Address Family Identifier (2) |
Must be zero (2) |
|
IP Address (4) |
||
Must be zero (4) |
||
Must be zero (4) |
||
Metric (4) |
RIP – пакет
Command (8 бит). Поле содержит число, обозначающее либо запрос, либо ответ. Команда-запрос запрашивает хост или маршрутизатор об отправке всей таблицы маршрутизации или ее части. Пункты назначения, для которых запрашивается ответ, перечисляются далее в данном пакете. Ответная команда представляет собой ответ на запрос или какую-нибудь не затребованную регулярную корректировку маршрутизации. Отвечающая система включает в ответный пакет всю таблицу маршрутизации или ее часть. Регулярные сообщения о корректировке маршрутизации включают в себя всю таблицу маршрутизации.
Version (8 бит). Поле версии определяет реализуемую версию RIP. Поскольку в сети возможны многие реализации RIP, это поле может быть использовано для сигнализации о различных потенциально несовместимых реализациях.
Zero (16 бит). Поле заполнено нулями.
Address family identifier (16 бит). Это поле определяет конкретное семейство адресов. В сети Internet этим адресным семейством обычно является IP (значение равно 2), но могут быть также представлены другие типы сетей.
Zero (16 бит). Поле заполнено нулями.
IP address (32 бита). В реализациях RIP-Internet это поле обычно содержит какой-нибудь адрес IP (для RIP это может быть либо IP-адресом хоста, либо подсети, либо сети).
Zero (32 бита) Поле заполнено нулями.
Metric (32 бита). Этот показатель представляет собой число пересылок (hop count) или транзитных участков (маршрутизаторов) сети, прежде чем можно будет добраться до пункта назначения.
В каждом отдельном пакете RIP может быть перечислено до 25 пунктов назначения. Для передачи информации из более крупных маршрутных таблиц используется множество пакетов RIP. <
Информацию можно найти:
| О дистанционно-векторных протоколах маршрутизации, и в частности RIP в RFC-1058, RFC-1075, RFC-1102. |
| Об OSPF можно найти в RFC-1245, RFC-1246 RFC-1247, RFC-1248, RFC-1427, RFC-1584, RFC-1850. |
| О протоколе EGP можно найти, например, в RFC-827, RFC-888, RFC-904, RFC-1092. |
| О протоколе BGP можно найти в RFC-1105, RFC-1163, RFC-1164, RFC-1267, RFC-1364, RFC-1403, RFC-1654, RFC-1771 RFC-1772. |
| О принципах и механизме бесклассовой маршрутизации CIDR можно найти в RFC-1517, RFC-1518, RFC-1519, RFC-1817. |
Интегрированный IS-IS
Интегрированный IS-IS является одной из версий IS-IS, которая использует один алгоритм маршрутизации для поддержки нескольких протоколов сетевого уровня, а не только одного протокола CLNP. Интегрированный IS-IS иногда называют Двойственным IS-IS (Dual IS-IS), по имени одной из версий, предназначенных для сетей IP и CLNP.
Пакеты IS-IS дополнены несколькими полями, что позволяет IS-IS поддерживать дополнительные сетевые уровни. Эти поля сообщают роутерам следующую информацию:
Досягаемость сетевых адресов из других комплектов протоколов
Какие протоколы поддерживаются и какими роутерами
Другую информацию, необходимую для какого-нибудь конкретного комплекта протоколов
Интегрированный IS-IS представляет один из двух способов поддержки в роутере нескольких протоколов сетевого уровня; другим способом является применение метода "корабли ночью" (ships in the night). Этот метод пропагандирует использование совершенно отдельного и отличного от других протокола маршрутизации для каждого сетевого протокола сети так, чтобы несколько протоколов маршрутизации фактически существовали независимо друг от друга (с разными типами маршрутной информации, проходящей подобно кораблям ночью). Возможность направлять по определенным маршрутам несколько протоколов сетевого уровня с помощью таблиц, рассчитанных одним протоколом маршрутизации, экономит ресурсы роутеров.
IS-IS
IS-IS является протоколом маршрутизации с указанием состояния канала. В этом роли он передает по сети лавинной адресацией информацию о состоянии канала для построения полной, последовательной картины топологии сети.
Иерархия маршрутизации
Для упрощения схемы и работы роутера IS-IS различает IS уровней 1 и 2. IS уровня 1 могут сообщаться с другими IS уровня 1, находящимися в той же области. IS уровня 2 могут сообщаться с IS других областей. Т.е. IS уровня 1 формируют области уровня 1; IS уровня 2 осуществляют маршрутизацию между областями уровня 1.
IS уровня 2 формируют стержень внутридоменной маршрутизации. Другими словами, IS уровня 2 могут попасть в другие IS уровня 2 путем пересечения только IS уровня 2. Наличие такого стержня упрощает схему, т.к. в этом случае IS уровня 1 нужно уметь только попадать в ближайший IS уровня 2. Протокол стержневой маршрутизации может также вносить изменения, не оказывая влияния на протокол внутриобластной маршрутизации.
Сообщение между ES
Маршрутизация OSI выполняется следующим образом. Каждая ES принадлежит конкретной области. ES обнаруживают ближайшую IS путем прослушивания пакетов ISH. Если какая-нибудь ES захочет отправить пакет в другую ES, она направляет пакет в одну из IS сети, к которой она непосредственно подключена. Роутер просматривает адрес пункта назначения и продвигает пакет по наилучшему маршруту. Если ES пункта назначения находится в той же подсети, то местная IS узнает об этом в результате прослушивания ESH и соответствующим образом продвинет пакет. В этом случае IS может также обеспечить отправку сообщения о переадресации (redirect
- RD) в источник пакета, чтобы сообщить о доступности более прямого пути. Если адресом пункта назначения является какая-нибудь ES другой подсети той же области, то IS узнает о точном маршруте и соответствующим образом продвинет пакет. Если адресом пункта назначения является какая-нибудь ES другой области, то IS уровня 1 отправляет этот пакет в в ближайшую IS уровня 2. Продвижение пакета через IS уровня 2 продолжается до тех пор, пока он не достигнет IS уровня 2 в области пункта назначения.
В пределах области пункта назначения IS продвигают пакет по наилучшему маршруту, пока не будет достигнутa ES пункта назначения.
Каждая IS генерирует корректировку, определяющую ES и IS, с которыми она соединена, а также связанные с ней показатели. Эта корректировка отправляется во все соседние IS, которые продвигают ее своим соседям, и т.д. (лавинная адресация). Номера последовательностей прекращают лавинную адресацию и отличают старые корректировки от новых. Т.к. каждая IS получает корректировки о состоянии канала от всех других IS, то каждая IS может построить полную базу данных всей топологии сети. При изменении топологии отправляются новые корректировки.
Показатели (метрики)
IS-IS использует один обязательный, устанавливаемый по умолчанию показатель с максимальным значением пути 1024. Этот показатель является произвольным и обычно назначается администратором сети. Любой отдельный канал может иметь максимальное значение 64. Длина путей вычисляется путем суммирования значений каналов. Максимальные значения каналов установлены на этих уровнях для обеспечения степени детализации, чтобы поддерживать различные типы каналов, одновременно обеспечивая достаточную эффективность алгоритма поиска наикратчайшего пути, используемого для расчета маршрута.
IS-IS также определяет три дополнительных показателя (затраты) в качестве опций для тех администраторов, которые испытывают в них необходимость. Затраты задержки (delay) отражают величину задержки в канале. Затраты на издержки (expense) отражают коммуникационные затраты, связанные с использованием данного канала. Затраты на ошибки (error) отражают коэффициент ошибок данного канала.
IS-IS обеспечивает соответствие этих четырех показателей опции качества обслуживания (quality-of-service - QOS) в заголовке пакета CLNP. Пользуясь этим соответствием, IS-IS может вычислять маршруты через об'единенную сеть.
Формат пакета
IS-IS использует три базовых формата пакета:
IS-IS hello packets - приветственные пакеты IS-IS
Link state packets (LSPs) - пакеты состояния канала
Sequence numbers packets (SNPs) - пакеты номеров последовательностей
Каждый из этих трех пакетов IS-IS имеет сложный формат с тремя различными логическими частями. Первой частью является 8-байтовый фиксированный заголовок, общий для всех трех типов пакетов. Второй частью является специфичная для данного типа пакета часть с фиксированным форматом. Третья логическая часть также является специфичной для типа пакета, но имеет переменную длину. Логический формат пакетов IS-IS представлен на рисунке.
| Common header | Packet-type-specific, fixed header | Packet-type-specific, variable-length header |
Первым полем в общем заголовке IS-IS является идентификатор протокола (protocol identifier), который идентифицирует протокол IS-IS. Это поле содержит константу (131).
Следующим полем общего заголовка является поле длины заголовка (header length). Это поле содержит фиксированную длину заголовка. Эта длина всегда равняется 8 байтам, но она включена таким образом, чтобы пакеты IS-IS незначительно отличались от пакетов CLNP.
За полем длины следует поле версии (version), которое равняется единице в текущей спецификации IS-IS.
За полем версии идет поле длины ID, которое определяет размеры части ID (идентификатора) NSAP, если eго значение лежит в пределах от 1 до 8 (включительно). Если поле содержит нуль, то часть ID равняется 6 байтам. Если поле содержит 255 (одни единицы), то часть ID равна 0 байтов.
Следующим полем является поле типа пакета (packet type), которое определяет тип пакета IS-IS (hello, LSP или SNP).
За полем типа пакета повторно следует поле версии.
За вторым полем версии идет поле резерва (reserved), которое равно нулю и которое игнорируется получателем.
Последним полем общего заголовка является поле максимума адресов области. Это поле определяет число адресов, разрешeнных для этой области.
За общим заголовком идет дополнительная фиксированная часть, разная для каждого типа пакета, за которой следует переменная часть.
Использование различных протоколов маршрутизации
Случай использования в сети только протокола маршрутизации OSPF представляется маловероятным. Если сеть присоединена к Internet'у, то могут использоваться такие протоколы, как EGP (Exterior Gateway protocol), BGP (Border Gateway Protocol, протокол пограничного маршрутизатора), старый протокол маршрутизации RIP или собственные протоколы производителей.
Когда в сети начинает применяться протокол OSPF, то существующие протоколы маршрутизации могут продолжать использоваться до тех пор, пока не будут полностью заменены. В некоторых случаях необходимо будет объявлять о статических маршрутах, сконфигурированных вручную.
В OSPF существует понятие автономных систем маршрутизаторов (autonomous systems), которые представляют собой домены маршрутизации, находящиеся под общим административным управлением и использующие единый протокол маршрутизации. OSPF называет маршрутизатор, который соединяет автономную систему с другой автономной системой, использующей другой протокол маршрутизации, пограничным маршрутизатором автономной системы (autonomous system boundary router, ASBR).
В OSPF маршруты (именно маршруты, то есть номера сетей и расстояния до них во внешней метрике, а не топологическая информация) из одной автономной системы импортируются в другую автономную систему и распространяются с использованием специальных внешних объявлений о связях.
Внешние маршруты обрабатываются за два этапа. Маршрутизатор выбирает среди внешних маршрутов маршрут с наименьшей внешней метрикой. Если таковых оказывается больше, чем 2, то выбирается путь с меньшей стоимостью внутреннего пути до ASBR.
Область OSPF - это набор смежных интерфейсов (территориальных линий или каналов локальных сетей). Введение понятия "область" служит двум целям - управлению информацией и определению доменов маршрутизации.
Для понимания принципа управления информацией рассмотрим сеть, имеющую следующую структуру: центральная локальная сеть связана с помощью 50 маршрутизаторов с большим количеством соседей через сети X.25 или frame relay. Эти соседи представляют собой большое количество небольших удаленных подразделений, например, отделов продаж или филиалов банка. Из-за большого размера сети каждый маршрутизатор должен хранить огромное количество маршрутной информации, которая должна передаваться по каждой из линий, и каждое из этих обстоятельств удорожает сеть. Так как топология сети проста, то большая часть этой информации и создаваемого ею трафика не имеют смысла.
Для каждого из удаленных филиалов нет необходимости иметь детальную маршрутную информацию о всех других удаленных офисах, в особенности, если они взаимодействуют в основном с центральными компьютерами, связанными с центральными маршрутизаторами. Аналогично, центральным маршрутизаторам нет необходимости иметь детальную информацию о топологии связей с удаленными офисами, соединенными с другими центральными маршрутизаторами. В то же время центральные маршрутизаторы нуждаются в информации, необходимой для передачи пакетов следующему центральному маршрутизатору. Администратор мог бы без труда разделить эту сеть на более мелкие домены маршрутизации для того, чтобы ограничить объемы хранения и передачи по линиям связи не являющейся необходимой информации. Обобщение маршрутной информации является главной целью введения областей в OSPF.
Большая сеть с топологией звезда
В протоколе OSPF определяется также пограничный маршрутизатор области (ABR, area border router). ABR - это маршрутизатор с интерфейсами в двух или более областях, одна из которых является специальной областью, называемой магистральной (backbone area).
Каждая область работает с отдельной базой маршрутной информации и независимо вычисляет маршруты по алгоритму OSPF. Пограничные маршрутизаторы передают данные о топологии области в соседние области в обобщенной форме - в виде вычисленных маршрутов с их весами. Поэтому в сети, разбитой на области, уже не действует утверждение о том, что все маршрутизаторы оперируют с идентичными топологическими базами данных.
Маршрутизатор ABR берет информацию о маршрутах OSPF, вычисленную в одной области, и транслирует ее в другую область путем включения этой информации в обобщенное суммарное объявление (summary) для базы данных другой области. Суммарная информация описывает каждую подсеть области и дает для нее метрику. Суммарная информация может быть использована тремя способами: для объявления об отдельном маршруте, для обобщения нескольких маршрутов или же служить маршрутом по умолчанию.
Дальнейшее уменьшение требований к ресурсам маршрутизаторов происходит в том случае, когда область представляет собой тупиковую область (stub area). Этот атрибут администратор сети может применить к любой области, за исключением магистральной. ABR в тупиковой области не распространяет внешние объявления или суммарные объявления из других областей. Вместо этого он делает одно суммарное объявление, которое будет удовлетворять любой IP-адрес, имеющий номер сети, отличный от номеров сетей тупиковой области. Это объявление называется маршрутом по умолчанию. Маршрутизаторы тупиковой области имеют информацию, необходимую только для вычисления маршрутов между собой плюс указания о том, что все остальные маршруты должны проходить через ABR. Такой подход позволяет уменьшить в нашей гипотетической сети количество маршрутной информации в удаленных офисах без уменьшения способности маршрутизаторов корректно передавать пакеты. <
Компоненты маршрутизации
Маршрутизация включает в себя два основных компонента: определение оптимальных трактов маршрутизации и транспортировка информационых групп (обычно называемых пакетами) через об'единенную сеть. В настоящей работе последний из этих двух компонентов называется коммутацией. Коммутация относительно проста. С другой стороны, определение маршрута может быть очень сложным процессом.
Определение маршрута
Определение маршрута может базироваться на различных показателях (величинах, результирующих из алгоритмических вычислений по отдельной переменной - например, длина маршрута) или комбинациях показателей. Программные реализации алгоритмов маршрутизации высчитывают показатели маршрута для определения оптимальных маршрутов к пункту назначения.
Для облегчения процесса определения маршрута, алгоритмы маршрутизации инициализируют и поддерживают таблицы маршрутизации, в которых содержится маршрутная информация. Маршрутная информация изменяется в зависимости от используемого алгоритма маршрутизации.
Алгоритмы маршрутизации заполняют маршрутные таблицы неким множеством информации. Ассоциации "Пункт назначения/следующая пересылка" сообщают роутеру, что определенный пункт назначения может быть оптимально достигнут путем отправки пакета в определенный роутер, представляющий "следующую пересылку" на пути к конечному пункту назначения. При приеме поступающего пакета роутер проверяет адрес пункта назначения и пытается ассоциировать этот адрес со следующей пересылкой. В таблице приведен пример маршрутной таблицы "место назначения/следующая пересылка".
| 27 | Node A |
| 57 | Node B |
| 17 | Node C |
| 24 | Node A |
| 52 | Node A |
| 16 | Node B |
| 26 | Node A |
| . . . |
. . . |
В маршрутных таблицах может содержаться также и другая информация. "Показатели" обеспечивают информацию о желательности какого-либо канала или тракта. Роутеры сравнивают показатели, чтобы определить оптамальные маршруты. Показатели отличаются друг oт друга в зависимости от использованной схемы алгоритма маршрутизации.
Далее в этой главе будет представлен и описан ряд общих показателей.
Роутеры сообщаются друг с другом (и поддерживают свои маршрутные таблицы) путем передачи различных сообщений. Одним из видов таких сообщений является сообщение об "обновлении маршрутизации". Обновления маршрутизации обычно включают всю маршрутную таблицу или ее часть. Анализируя информацию об обновлении маршрутизации, поступающую ото всех роутеров, любой из них может построить детальную картину топологии сети. Другим примером сообщений, которыми обмениваются роутеры, является "об'явление о состоянии канала". Об'явление о состоянии канала информирует другие роутеры о состоянии кааналов отправителя. Канальная информация также может быть использована для построения полной картины топологии сети. После того, как топология сети становится понятной, роутеры могут определить оптимальные маршруты к пунктам назначения.
Коммутация
Алгоритмы коммутации сравнительно просты и в основном одинаковы для большинства протоколов маршрутизации. В большинстве случаев главная вычислительная машина определяет необходимость отправки пакета в другую главную вычислительную машину. Получив определенным способом адрес роутера, главная вычислительная машина-источник отправляет пакет, адресованный специально в физический адрес роутера (уровень МАС), однако с адресом протокола (сетевой уровень) главной вычислительной машины пункта назначения.
После проверки адреса протокола пункта назначения пакета роутер определяет, знает он или нет, как передать этот пакет к следующему роутеру. Во втором случае (когда роутер не знает, как переслать пакет) пакет, как правило, игнорируется. В первом случае роутер отсылает пакет к следующей роутеру путем замены физического адреса пункта назначения на физический адрес следующего роутера и последующей передачи пакета.
Следующая пересылка может быть или не быть главной вычислительной машиной окончательного пункта назначения. Если нет,то следующей пересылкой, как правило, является другой роутер, который выполняет такой же процесс принятия решения о коммутации.
По мере того, как пакет продвигается через об'единенную сеть, его физический адрес меняется, однако адрес протокола остается неизменным. Этот процесс иллюстрируется на Рис. 2-2.
В изложенном выше описании рассмотрена коммутация между источником и системой конечного пункта назначения. Международная Организация по Стандартизации (ISO) разработала иерархическую терминологию, которая может быть полезной при описании этого процесса. Если пользоваться этой терминологией, то устройства сети, не обладающие способностью пересылать пакеты между подсетями, называются конечными системами (ЕS), в то время как устройства сети, имеющие такую способность, называются промежуточными системами (IS). Промежуточные системы далее подразделяются на системы, которые могут сообщаться в пределах "доменов мааршрутизации" ("внутридоменные" IS), и системы, которые могут сообщаться как в пределах домена маршрутизации, так и с другими доменами маршрутизации ("междоменные IS"). Обычно считается, что "домен маршрутизации" - это часть об'единенной сети, находящейся под общим административным управлением и регулируемой пределенным набором административных руководящих принципов. Домены маршрутизации называются также "автономными системами" (AS). Для опрелеленных протоколов домены маршрутизации могут быть дополнительно подразделены на "участки маршрутизации", однако для коммутации как внутри участков, так и между ними также используются внутридоменные протоколы маршрутизации.
Маршрутизация OSI.
| Библиографическая справка | ||||||||
| Терминология | ||||||||
| ES-IS | ||||||||
| IS-IS
| ||||||||
| Интегрированный IS-IS | ||||||||
| Протокол междоменной маршрутизации (IDRP) |
Основы маршрутизации
| Библиографическая справка | ||||||
| Компоненты маршрутизации
| ||||||
| Алгоритмы маршрутизации
|
Пример маршрутизации по алгоритму OSPF
Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора - Джон, Фред и Роб (имена членов рабочей группы Internet, разработавшей протокол OSPF). Эти маршрутизаторы связаны с сетями в других городах с помощью выделенных линий.
Пусть произошло восстановление сетевого питания после сбоя. Маршрутизаторы и компьютеры перезагружаются и начинают работать по сети Ethernet. После того, как маршрутизаторы обнаруживают, что порты Ethernet работают нормально, они начинают генерировать сообщения HELLO, которые говорят о их присутствии в сети и их конфигурации. Однако маршрутизация пакетов начинает осуществляться не сразу - сначала маршрутизаторы должны синхронизировать свои маршрутные базы.
Гипотетическая сеть с OSPF маршрутизаторами
На протяжении интервала отказа маршрутизаторы продолжают посылать сообщения HELLO. Когда какой-либо маршрутизатор посылает такое сообщение, другие его получают и отмечают, что в локальной сети есть другой маршрутизатор. Когда они посылают следующее HELLO, они перечисляют там и своего нового соседа.
Когда период отказа маршрутизатора истекает, то маршрутизатор с наивысшим приоритетом и наибольшим идентификатором объявляет себя выделенным (а следующий за ним по приоритету маршрутизатор объявляет себя резервным выделенным маршрутизатором) и начинает синхронизировать свою базу данных с другими маршрутизаторами.
С этого момента времени база данных маршрутных объявлений каждого маршрутизатора может содержать информацию, полученную от маршрутизаторов других локальных сетей или из выделенных линий. Роб, например, вероятно получил информацию от Мило и Робина об их сетях, и он может передавать туда пакеты данных. Они содержат информацию о собственных связях маршрутизатора и объявления о связях сети.
Базы данных теперь синхронизированы с выделенным маршрутизатором, которым является Джон. Джон суммирует свою базу данных с каждой базой данных своих соседей - базами Фреда, Роба и Джеффа - индивидуально.
В каждой синхронизирующейся паре объявления, найденные только в какой-либо одной базе, копируются в другую. Выделенный маршрутизатор, Джон, распространяет новые объявления среди других маршрутизаторов своей локальной сети. Например, объявления Мило и Робина передаются Джону Робом, а Джон в свою очередь передает их Фреду и Джеффри. Обмен информацией между базами продолжается некоторое время, и пока он не завершится, маршрутизаторы не будут считать себя работоспособными. После этого они себя таковыми считают, потому что имеют всю доступную информацию о сети.
Посмотрим теперь, как Робин вычисляет маршрут через сеть. Две из связей, присоединенных к его портам, представляют линии T-1, а одна - линию 56 Кб/c. Робин сначала обнаруживает двух соседей - Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин обнаружил наилучший путь к Мило со стоимостью 130, поэтому он отверг непосредственный путь к Мило, поскольку он связан с большей задержкой, так как проходит через линии с меньшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин узнает о пути к Фреду и, наконец, узнает о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям.
После того, как маршрутизаторы полностью входят в рабочий режим, интенсивность обмена сообщениями резко падает. Обычно они посылают сообщение HELLO по своим подсетям каждые 10 секунд и делают объявления о состоянии связей каждые 30 минут (если обнаруживаются изменения в состоянии связей, то объявление передается, естественно, немедленно). Обновленные объявления о связях служат гарантией того, что маршрутизатор работает в сети. Старые объявления удаляются из базы через определенное время.
Представим, однако, что какая-либо выделенная линия сети отказала. Присоединенные к ней маршрутизаторы распространяют свои объявления, в которых они уже не упоминают друг друга. Эта информация распространяется по сети, включая маршрутизаторы транзитной локальной сети.Каждый маршрутизатор в сети пересчитывает свои маршруты, находя, может быть, новые пути для восстановления утраченного взаимодействия.
Принцип работы
Алгоритм маршрутизации SPF является основой для операций OSPF. В каждой области работает отдельная копия алгоритма маршрутизации. Маршрутизаторы, которые имеют интерфейсы к нескольким областям, работают с несколькими копиями алгоритма SPF.
Когда на какой-нибудь роутер SPF подается питание, он инициализирует свои структуры данных о протоколе маршрутизации, а затем ожидает уведомления от протоколов низшего уровня о том, что его интерфейсы работоспособны.
После получения подтверждения о работоспособности своих интерфейсов, роутер использует приветственный протокол (hello protocol) OSPF, чтобы приобрести соседей (neighbor). Соседи — это объекты сети с интерфейсами, предназначенными для работы в общей с данным маршрутизатором сети. Описываемый маршрутизатор отправляет своим соседям приветственные пакеты и получает от них такие же пакеты. Помимо оказания помощи в приобретении соседей, приветственные пакеты также действуют как подтверждение дееспособности, позволяя другим роутерам узнавать о том, что другие роутеры функционируют.
Каждый роутер периодически, в зависимости от настройки системы, отправляет сообщение о состоянии канала (LSA — messages). Эти сообщения содержат информацию о состоянии интерфейса маршрутизатора данного маршрутизатора и смежных с ним объектов сети. Каждое такое сообщение рассылается маршрутизаторам всей области. Из LSA-сообщений всех объектов формируется топологическая база данных (дерево маршрутов). Сообщения LSA также отправляются в том случае, когда изменяется состояние какого-нибудь роутера.
После построения дерева маршрутов внутри AS, протокол проверяет информацию внешних маршрутов по отношению к данной AS. Эта информация может быть получена с помощью протоколов, обеспечивающих взаимодействие OSPF с другими областями или другими типами сетей, например, с помощью протоколов EGP или ВОР.
Все маршрутизаторы данной AS используют один и тот же алгоритм построения маршрута на основе топологической базы данных. Маршрутизатор строит граф оптимальных маршрутов, в котором он сам является корнем. На основании этого графа маршрутизаторы и производят свои расчеты для каждого маршрута информационного пакета. В свою очередь, по дереву оптимальных маршрутов строится маршрутная таблица, которая служит основой оценок и выбора маршрутов.
В зависимости от того, какую функцию выполняет тот или иной маршрутизатор (т. е. относится к области backbone, смежной области, периферии или внутренней области), он выполняет те или иные функции (инициализации, согласования, корректировки и т. п.) с одной или несколькими топологическими базами данных, находящихся под его контролем.
Протокол междоменной маршрутизации (IDRP)
IDRP является протоколом OSI, предназначенным для перемещения информации между доменами маршрутизации. Он предназначен для бесшовной работы с CLNP, ES-IS и IS-IS. IDRP базируется на Протоколе граничных роутеров (BGP), который является протоколом междоменной маршрутизации, впервые появившемся в сообществе IP.
IDRP вводит несколько новых терминов, в том числе следующие:
Border intermediate system (BIS)
Граничная промежуточная система. Это IS, участвующая в междоменной маршрутизации. Для этого она использует IDRP.
Routing domain (RD)
Домен маршрутизации. Это группа ES и IS, работающих согласно общим административным правилам, включающим коллективное пользование общим маршрутным планом.
Routing domain identifier (RDI)
Идентификатор домена маршрутизации. Уникальный идентификатор домена маршрутизации (RD).
Routing information base (RIB)
Информационная база маршрутизации. Это база данных маршрутизации, используемая IDRP. Каждая BIS строит свою RIB из информации, полученной от систем данного RD и из других BIS. Любая RIB содержит набор маршрутов, выбранных для использования какой-нибудь конкретной BIS.
Confederation
Конфедерация. Это группа доменов маршрутизации (RD). RD, не принадлежащие к данной конфедерации, воспринимают ее как один RD. Топология конфедерации невидима для RD, не принадлещащих к ней. Конфедерации помогают сократить сетевой трафик, выступая в об'единенной сети в качестве непреодолимой преграды; они могут быть вложены одна в другую.
Маршрут IDRP представляет собой последовательность RDI. Некоторые из этих RDI могут быть конфедерациями. При конфигурации каждой BIS она знает о RD и конфедерациях, к которым она принадлежит, а также узнает о других BIS, RD и конфедерациях из информации, которой она обменивается с каждым соседом. Как и для маршрутизации с вектором расстояния, маршруты в какой-нибудь конкретный пункт назначения накапливаются вне данного пункта назначения. Только маршруты, которые удовлетворяют требованиям местной политики какой-нибудь BIS и были выбраны для использования, будут переданы в другие BIS. Пересчет маршрутов носит частичный характер и имеет место при наличии одного их следующих трех событий: получена инкрементная корректировка маршрутизации с новыми маршрутами, отказывает какая-нибудь соседняя BIS или появляется новая соседняя BIS.
В число характеристик IDRP входят следующие:
Поддержка CLNP QOS
Устранение петель путем ослеживания всех RD, пересекаемых роутером
Сокращение об'ема маршрутной информации и ее обработки путем использования конфедераций, компрессии информации путей RD и других средств
Обеспечение надежности путем использования встроенных надежных средств транспортировки
Обеспечение защиты данных путем использования криптографической сигнатуры для каждого пакета
Наличие узлов обслуживания маршрута
Регенерирующие пакеты RIB
<
Протокол OSPF
OSPF — это открытый протокол маршрутизации, базирующийся на алгоритме поиска наикратчайшего пути (Open Shortest Path First — OSPF). OSPF имеет две основные характеристики: протокол является открытым, т. е. его спецификация является общественным достоянием, он базируется на алгоритме SPF. Алгоритм SPF иногда называют алгоритмом Dijkstra
по имени его автора.
OSPF является иерархическим протоколом маршрутизации с объявлением состояния о канале соединения (link-state). Он был спроектирован как протокол работы внутри сетевой области — AS (Autonomous System), которая представляет собой группу маршрутизаторов и сетей, объединенных по иерархическому принципу и находящихся под единым управлением и совместно использующих общую стратегию маршрутизации. В качестве транспортного протокола для маршрутизации внутри AS OSPF использует IP-протокол.
Обмен информацией о маршрутах внутри AS протокол OSPF осуществляет посредством обмена сообщениями о состояниях канала соединений между маршрутизаторами и сетями области (link-state advertisement — LSA). Эти сообщения передаются между объектами сети, находящимися в пределах одной и той же иерархической области — это может быть как вся AS, так и некоторая группа сетей внутри данной AS. В LSA-сообщения протокола OSPF включается информация о подключенных интерфейсах, о параметрах маршрутов и других переменных. По мере накопления роутерами OSPF информации о состоянии маршрутов области, они рассчитывают наикратчайший путь к каждому узлу, используя алгоритм SPF. Причем расчет оптимального маршрута осуществляется динамически в соответствии с изменениями топологии сети.
Для различных типов IP-сервиса (видов услуг высшего уровня, которые определяются значением поля TOS IP-пакета), OSPF может рассчитывать свои оптимальные маршруты на основании параметров, наиболее критичных для данного вида сервиса. Например, какая-нибудь прикладная программа может включить требование о том, что определенная информация является срочной. Если OSPF имеет в своем распоряжении каналы с высоким приоритетом, то они могут быть использованы для транспортировки срочных дейтаграмм.
OSPF поддерживает механизм, позволяющий работать с несколькими равноправными маршрутами между двумя объектами сети. Это позволяет существенно уменьшить время передачи данных и более эффективно использовать каналы связи.
Кроме того, OSPF-протокол поддерживает аутентификацию изменений маршрутов. Это означает, что только те маршрутизаторы, которые имеют определенные права, могут осуществлять маршрутизацию пакетов. Это позволяет, при соответствующей настройке прав системы маршрутизаторов, передавать по сети конфиденциальные сообщения, зная заранее, что они проходят только по определенным маршрутам.
Протокол RIP
Протокол RIP (Routing Information Protocol) представляет собой один из старейших протоколов обмена маршрутной информацией, однако он до сих пор чрезвычайно распространен в вычислительных сетях. Помимо версии RIP для сетей TCP/IP, существует также версия RIP для сетей IPX/SPX компании Novell.
Он относится к классу дистанционно-векторных алгоритмов. Этот класс алгоритмов также известен по имени автора алгоритма Форда - Фулкерсона. Помимо того, для этого класса также используется название "алгоритм Беллмана-Форда", которое появилось после окончательной формализации алгоритма, которая была сделана на основании основного уравнения динамического программирования Беллмана.
Этот протокол наиболее подходит для использования в качестве внутреннего (меж) шлюзового протокола (IGP), т.е. для маршрутизации сообщений внутри автономной системы, которая работает под неким единым началом и по единым принципам.
<
Протокол RIP - принцип действия
В этом протоколе все сети имеют номера (способ образования номера зависит от используемого в сети протокола сетевого уровня), а все маршрутизаторы - идентификаторы. Протокол RIP широко использует понятие "вектор расстояний". Вектор расстояний представляет собой набор пар чисел, являющихся номерами сетей и расстояниями до них в хопах.
Вектора расстояний итерационно распространяются маршрутизаторами по сети, и через несколько шагов каждый маршрутизатор имеет данные о достижимых для него сетях и о расстояниях до них. Если связь с какой-либо сетью обрывается, то маршрутизатор отмечает этот факт тем, что присваивает элементу вектора, соответствующему расстоянию до этой сети, максимально возможное значение, которое имеет специальный смысл - "связи нет". Таким значением в протоколе RIP является число 16.
На рисунке приведен пример сети, состоящей из шести маршрутизаторов, имеющих идентификаторы от 1 до 6, и из шести сетей от A до F, образованных прямыми связями типа "точка-точка".
Обмен маршрутной информацией по протоколу RIP
На рисунке приведена начальная информация, содержащаяся в топологической базе маршрутизатора 2, а также информация в этой же базе после двух итераций обмена маршрутными пакетами протокола RIP. После определенного числа итераций маршрутизатор 2 будет знать о расстояниях до всех сетей интерсети, причем у него может быть несколько альтернативных вариантов отправки пакета к сети назначения. Пусть в нашем примере сетью назначения является сеть D.
При необходимости отправить пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий наименьшее расстояния до сети назначения (в данном случае порт, связывающий его с маршрутизатором 3).
Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы.
При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками - увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута.
На рисунке показан случай неустойчивой работы сети по протоколу RIP при изменении конфигурации - отказе линии связи маршрутизатора M1 с сетью 1. При работоспособном состоянии этой связи в таблице маршрутов каждого маршрутизатора есть запись о сети с номером 1 и соответствующим расстоянием до нее.
Пример неустойчивой работы сети при использовании протокола RIP
При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до этой сети приняло значение 16. Однако получив через некоторое время от маршрутизатора М2 маршрутное сообщение о том, что от него до сети 1 расстояние составляет 2 хопа, маршрутизатор М1 наращивает это расстояние на 1 и отмечает, что сеть 1 достижима через маршрутизатор 2. В результате пакет, предназначенный для сети 1, будет циркулировать между маршрутизаторами М1 и М2 до тех пор, пока не истечет время хранения записи о сети 1 в маршрутизаторе 2, и он не передаст эту информацию маршрутизатору М1.
Для исключения подобных ситуаций маршрутная информация об известной маршрутизатору сети не передается тому маршрутизатору, от которого она пришла.
Существуют и другие, более сложные случаи нестабильного поведения сетей, использующих протокол RIP, при изменениях в состоянии связей или маршрутизаторов сети. <
Сравнение протоколов RIP и OSPF по затратам на широковещательный трафик
В сетях, где используется протокол RIP, накладные расходы на обмен маршрутной информацией строго фиксированы. Если в сети имеется определенное число маршрутизаторов, то трафик, создаваемый передаваемой маршрутной информацией, описываются формулой (1):
(1) F = (число объявляемых маршрутов/25) x 528 (байтов в сообщении) x
(число копий в единицу времени) x 8 (битов в байте)
В сети с протоколом OSPF загрузка при неизменном состоянии линий связи создается сообщениями HELLO и обновленными объявлениями о состоянии связей, что описывается формулой (2):
(2) F = { [ 20 + 24 + 20 + (4 x число соседей)] x
(число копий HELLO в единицу времени) }x 8 +
[(число объявлений x средний размер объявления) x
(число копий объявлений в единицу времени)] x 8,
где 20 - размер заголовка IP-пакета,
24 - заголовок пакета OSPF,
20 - размер заголовка сообщения HELLO,
4 - данные на каждого соседа.
Интенсивность посылки сообщений HELLO - каждые 10 секунд, объявлений о состоянии связей - каждые полчаса. По связям "точка-точка" или по широковещательным локальным сетям в единицу времени посылается только одна копия сообщения, по NBMA сетям типа frame relay каждому соседу посылается своя копия сообщения. В сети frame relay с 10 соседними маршрутизаторами и 100 маршрутами в сети (подразумевается, что каждый маршрут представляет собой отдельное OSPF-обобщение о сетевых связях и что RIP распространяет информацию о всех этих маршрутах) трафик маршрутной информации определяется соотношениями (3) и (4):
(3) RIP: (100 маршрутов / 25 маршрутов в объявлении) x 528 x
(10 копий / 30 сек) = 5 632 б/с
(4) OSPF: {[20 + 24 + 20 + (4 x 10) x (10 копий / 10 сек)] +
[100 маршрутов x (32 + 24 + 20) + (10 копий / 30 x 60 сек]} x 8 = 1 170 б/с
Как видно из полученных результатов, для нашего гипотетического примера трафик, создаваемый протоколом RIP, почти в пять раз интенсивней трафика, создаваемого протоколом OSPF. <
Терминология
Об'единенные сети OSI используют уникальную терминологию. Термин "конечная система" (end system - ES) относится к любому узлу сети, который не занимается маршрутизацией; термин "промежуточная система" (intermediate system-IS) относится к роутеру. На этих терминах базируются протоколы OSI ES-IS (который позволяет ES и IS находить друг друга) и IS-IS (который обеспечивает маршрутизацию между IS). Ниже дается определение некоторых других важных терминов об'единенных сетей OSI:
Area
Область. Группа смежных сетей и подключенных к ним хостов, которые определяются как область администратором сети или другим аналогичным лицом.
Domain
Домен. Набор соединенных областей. Домены маршрутизации обеспечивают полную связность со всеми конечными системами, находящимися в их пределах.
Level 1 routing
Маршрутизация в пределах области Уровня 1.
Level 2 routing
Maршрутизация между областями Уровня 1.
На рисунке "Иерархия об'единенных сетей OSI" показана взаимосвязь между этими терминами.
С чисто технологической точки зрения IS-IS почти аналогичен протоколу маршрутизации OSPF. Оба протокола являются протоколами с указанием состояния канала. Оба они обеспечивают различные характеристики, которые не обеспечивает RIP, в том числе иерархии маршрутизации (routing hierachies), дробление путей (path splitting), обеспечение типа услуги (type-of-service - TOS), удостоверение (authentication), поддержка нескольких протоколов сетевого уровня и поддержка (совместно с протоколом Integrated IS-IS) масок подсети переменной длины.
Типы алгоритмов
Алгоритмы маршрутизации могут быть классифицированы по типам. Например, алгоритмы могут быть:
Статическими или динамическими
Одномаршрутными или многомаршрутными
Одноуровневыми или иерархическими
С интеллектом в главной вычислительной машине или в роутере
Внутридоменными и междоменными
Алгоритмами состояния канала или вектора расстояний
Статические или динамические алгоритмы
Статические алгоритмы маршрутизации вообще вряд ли являются алгоритмами. Распределение статических таблиц маршрутизации устанавливется администратором сети до начала маршрутизации. Оно не меняется, если только администратор сети не изменит его. Алгоритмы, использующие статические маршруты, просты для разработки и хорошо работают в окружениях, где трафик сети относительно предсказуем, а схема сети относительно проста.
Т.к. статические системы маршрутизации не могут реагировать на изменения в сети, они, как правило, считаются непригодными для современных крупных, постоянно изменяющихся сетей. Большинство доминирующих алгоритмов маршрутизации 1990гг. - динамические.
Динамические алгоритмы маршрутизации подстраиваются к изменяющимся обстоятельствам сети в масштабе реального времени. Они выполняют это путем анализа поступающих сообщений об обновлении маршрутизации. Если в сообщении указывается, что имело место изменение сети, программы маршрутизации пересчитывают маршруты и рассылают новые сообщения о корректировке маршрутизации. Такие сообщения пронизывают сеть, стимулируя роутеры заново прогонять свои алгоритмы и соответствующим образом изменять таблицы маршрутизации. Динамические алгоритмы маршрутизации могут дополнять статические маршруты там, где это уместно. Например, можно разработать "роутер последнего обращения" (т.е. роутер, в который отсылаются все неотправленные по определенному маршруту пакеты). Такой роутер выполняет роль хранилища неотправленных пакетов, гарантируя, что все сообщения будут хотя бы определенным образом обработаны.
Одномаршрутные или многомаршрутные алгоритмы
Некоторые сложные протоколы маршрутизации обеспечивают множество маршрутов к одному и тому же пункту назначения. Такие многомаршрутные алгоритмы делают возможной мультиплексную передачу трафика по многочисленным линиям; одномаршрутные алгоритмы не могут делать этого. Преимущества многомаршрутных алгоритмов очевидны - они могут обеспечить заначительно большую пропускную способность и надежность.
Одноуровневые или иерархические алгоритмы
Некоторые алгоритмы маршрутизации оперируют в плоском пространстве, в то время как другие используют иерархиии маршрутизации. В одноуровневой системе маршрутизации все роутеры равны по отношению друг к другу. В иерархической системе маршрутизации некоторые роутеры формируют то, что составляет основу (backbone - базу) маршрутизации. Пакеты из небазовых роутеров перемещаются к базовыи роутерам и пропускаются через них до тех пор, пока не достигнут общей области пункта назначения. Начиная с этого момента, они перемещаются от последнего базового роутера через один или несколько небазовых роутеров до конечного пункта назначения.
Системы маршрутизации часто устанавливают логические группы узлов, называемых доменами, или автономными системами (AS), или областями. В иерархических системах одни роутеры какого-либо домена могут сообщаться с роутерами других доменов, в то время как другие роутеры этого домена могут поддерживать связь с роутеры только в пределах своего домена. В очень крупных сетях могут существовать дополнительные иерархические уровни. Роутеры наивысшего иерархического уровня образуют базу маршрутизации.
Основным преимуществом иерархической маршрутизации является то, что она имитирует организацию большинства компаний и следовательно, очень хорошо поддерживает их схемы трафика. Большая часть сетевой связи имеет место в пределах групп небольших компаний (доменов). Внутридоменным роутерам необходимо знать только о других роутерах в пределах своего домена, поэтому их алгоритмы маршрутизации могут быть упрощенными. Соответственно может быть уменьшен и трафик обновления маршрутизации, зависящий от используемого алгоритма маршрутизации.
Алгоритмы с игнтеллектом в главной вычислительной машине или в роутере
Некоторые алгоритмы маршрутизации предполагают, что конечный узел источника определяет весь маршрут. Обычно это называют маршрутизацией от источника. В системах маршрутизации от источника роутеры действуют просто как устойства хранения и пересылки пакета, без всякий раздумий отсылая его к следующей остановке.
Другие алгоритмы предполагают, что главные вычислительные машины ничего не знают о маршрутах. При использовании этих алгоритмов роутеры определяют маршрут через об'единенную сеть, базируясь на своих собственных расчетах. В первой системе, рассмотренной выше, интеллект маршрутизации находится в главной вычислительной машине. В системе, рассмотренной во втором случае, интеллектом маршрутизации наделены роутеры.
Компромисс между маршрутизацией с интеллектом в главной вычислительной машине и маршрутизацией с интеллектом в роутере достигается путем сопоставления оптимальности маршрута с непроизводительными затратами трафика. Системы с интеллектом в главной вычислительной машине чаще выбирают наилучшие маршруты, т.к. они, как правило, находят все возможные маршруты к пункту назначения, прежде чем пакет будет действительно отослан. Затем они выбирают наилучший мааршрут, основываясь на определении оптимальности данной конкретной системы. Однако акт определения всех маршрутов часто требует значительного трафика поиска и большого об'ема времени.
Внутридоменные или междоменные алгоритмы
Некоторые алгоритмы маршрутизации действуют только в пределах доменов; другие - как в пределах доменов, так и между ними. Природа этих двух типов алгоритмов различная. Поэтому понятно, что оптимальный алгоритм внутридоменной маршрутизации не обязательно будет оптимальным алгоритмом междоменной маршрутизации.
Алгоритмы состояния канала или вектора расстояния
Алгоритмы состояния канала (известные также как алгоритмы "первоочередности наикратчайшего маршрута") направляют потоки маршрутной информации во все узлы об'единенной сети. Однако каждый роутер посылает только ту часть маршрутной таблицы, которая описывает состояние его собственных каналов. Алгоритмы вектора расстояния ( известные также как алгоритмы Бэлмана-Форда) требуют от каждогo роутера посылки всей или части своей маршрутной таблицы, но только своим соседям. Алгоритмы состояния каналов фактически направляют небольшие корректировки по всем направлениям, в то время как алгоритмы вектора расстояний отсылают более крупные корректировки только в соседние роутеры.
Отличаясь более быстрой сходимостью, алгоритмы состояния каналов несколько меньше склонны к образованию петель маршрутизации, чем алгоритмы вектора расстояния. С другой стороны, алгоритмы состояния канала характеризуются более сложными расчетами в сравнении с алгоритмами вектора расстояний, требуя большей процессорной мощности и памяти, чем алгоритмы вектора расстояний. Вследствие этого, реализация и поддержка алгоритмов состояния канала может быть более дорогостоящей. Несмотря на их различия, оба типа алгоритмов хорошо функционируют при самых различных обстоятельствах.
Показатели алгоритмов (метрики)
Маршрутные таблицы содержат информацию, которую используют программы коммутации для выбора наилучшего маршрута. Чем характеризуется построение маршрутных таблиц? Какова особенность природы информации, которую они содержат? В данном разделе, посвященном показателям алгоритмов, сделана попытка ответить на вопрос о том, каким образом алгоритм определяет предпочтительность одного маршрута по сравнению с другими.
В алгоритмах маршрутизации используется много различных показателей. Сложные алгоритмы маршрутизации при выборе маршрута могут базироваться на множестве показателей, комбинируя их таким образом, что в результате получается один отдельный (гибридный) показатель. Ниже перечислены показатели, которые используются в алгоритмах маршрутизации:
Длина маршрута
Надежность
Задержка
Ширина полосы пропускания
Длина маршрута
Длина маршрута является наиболее общим показателем маршрутизации. Некоторые протоколы маршрутизации позволяют администраторам сети назначать произвольные цены на каждый канал сети. В этом случае длиной тракта является сумма расходов, связанных с каждым каналом, который был траверсирован. Другие протоколы маршрутизации определяют "количество пересылок", т.е. показатель, характеризующий число проходов, которые пакет должен совершить на пути от источника до пункта назначения через изделия об'единения сетей (такие как роутеры).
Надежность
Надежность, в контексте алгоритмов маршрутизации, относится к надежности каждого канала сети (обычно описываемой в терминах соотношения бит/ошибка). Некоторые каналы сети могут отказывать чаще, чем другие. Отказы одних каналов сети могут быть устранены легче или быстрее, чем отказы других каналов. При назначении оценок надежности могут быть приняты в расчет любые факторы надежности. Оценки надежности обычно назначаются каналам сети администраторами сети. Как правило, это произвольные цифровые величины.
Задержка
Под задержкой маршрутизации обычно понимают отрезок времени, необходимый для передвижения пакета от источника до пункта назначения через об'единенную сеть. Задержка зависит от многих факторов, включая полосу пропускания промежуточных каналов сети, очереди в порт каждого роутера на пути передвижения пакета, перегруженность сети на всех промежуточных каналах сети и физическое расстояние, на которое необходимо переместить пакет. Т.к. здесь имеет место конгломерация нескольких важных переменных, задержка является наиболее общим и полезным показателем.
Полоса пропускания
Полоса пропускания относится к имеющейся мощности трафика какого-либо канала. При прочих равных показателях, канал Ethernet 10 Mbps предпочтителен любой арендованной линии с полосой пропускания 64 Кбайт/сек. Хотя полоса пропускания является оценкой максимально достижимой пропускной способности канала, маршруты, проходящие через каналы с большей полосой пропускания, не обязательно будут лучше маршрутов, проходящих через менее быстродействующие каналы. <
Библиографическая справка
IBM разработала протокол Synchronous Data-Link Control (SDLC) (Управление синхронным каналом передачи данных) в середине 1970 гг. для применения в окружениях Systems Network Architecture (SNA) (Архитектура системных сетей). SDLC был первым из протоколов канального уровня нового важного направления, базирующегося на синхронном бит-ориентированном режиме работы. По сравнению с синхронным, ориентированным по символам (например, Bisynk фирмы IBM) и синхронным, с организацией счета байтов (например, Digital Data Communications Message Protocol - Протокол Сообщений Цифровой Связи) протоколами, бит-ориентированные синхронные протоколы являются более эффективными и гибкими, и очень часто более быстродействующими.
После разработки SDLC компания IBM представила его на рассмотрение в различные комитеты по стандартам. Международная Организация по Стандартизации (ISO) модифицировала SDLC с целью разработки протокола HDLC (Управление каналом связи высокого уровня). Впоследствии Международный консультативный комитет по телеграфии и телефонии (CCITT) модифицировал HDLC с целью создания "Процедуры доступа к каналу" (LAP), а затем "Процедуры доступа к каналу, сбалансированной" (LAPB). Институт инженеров по электротехнике и радиоэлектронике (IEEE) модифицировал HDLC , чтобы разработать IEEE 802.2. Kaждый из этих протоколов играет важную роль в своей области. SDLC остается основным протоколом канального уровня SNA для каналов глобальных сетей.
Форматы блока данных
Формат блока данных SDLC представлен на Рис. 12-1. Протокол байт ориентированный, т.е. длина кадра всегда кратна байту.
Как видно из рисунка, блоки данных SDLC ограничены уникальной структурой "флага" (flag) - "01111110". Внутри кадра байт со значением равным "флагу" не должно встречаться. Данное ограниечение было преодолено в протоколах HDLC и LAPB. В данных протоколах был введен механизм добавления нулей прозрачности - битов стаффингования.
Поле "адрес" (address) всегда содержит адрес вторичного узла, задействованного в текущей связи. Т.к. первичный узел является либо источником связи, либо пунктом назначения, нет необходимости включать его адрес - он заранее известен всем вторичным узлам.
"Управляющее" (control) поле использует три разных формата в зависимости от использованного типа блока данных SDLC. Описание трех типов блока данных SDLC дается ниже в следующем перечне:
Информационные блоки данных (Information (I) frames).
Эти блоки данных содержат информацию высших уровней и определенную управляющую информацию (необходимую для работы с полным дублированием). Номера последовательностей отправки и приема и бит "опроса последнего" (P/F) выполняют функции управления потоком информации и неисправностями. Номер последовательности отправки (send sequence number) относится к номеру блока данных, который должен быть отправлен следующим. Номер последовательности приема (receive sequence number) обеспечивает номер блока данных, который должен быть принят следующим. При полностью дублированном диалоге как отправитель, так и получатель хранят номера последовательностей отправки и приема. Первичный узел использует бит P/F, чтобы сообщить вторичному узлу, требует он от него немедленно ответного сигнала или нет. Вторичный узел использует этот бит для того, чтобы сообщить первичному, является текущий блок данных последним или нет в текущей ответной реакции данного вторичного узла.
Блоки данных супервизора (Supervisory (S) frames).
Эти блоки данных обеспечивают управляющую информацию. У них нет информационного поля. Блоки данных супервизора запрашивают и приостанавливают передачу, сообщают о состоянии и подтверждают прием блоков данных "I".
Непронумерованные блоки банных (Unnumbered (U) frames).
Как видно из названия, эти блоки данных неупорядочены. Они могут иметь информационное поле. Блоки данных "U" используются для управляющих целей. Например, они могут определять одно- или двубайтовое поле управления, инициализировать вторичные узлы и выполнять другие аналогичные функции.
Последовательность проверки блока данных (frame check sequence) (FCS) предшествует ограничителю завершающего флага. FCS обычно является остатком расчета "проверки при помощи циклического избыточного кода" (cyclic redundency check) (CRC). Расчет CRC выполняется повторно получателем. Если результат отличается от значения, содержащегося в блоке данных отправителя, считается, что имеет место ошибка.
Типичная конфигурация сети, базирующейся на SDLC, представлена на Рис. 12-2. Как показано на рисунке, контроллер организации связи IBM (раньше называвшийся групповым контроллером) на отдаленном пункте подключен к "немым" терминалам и к сети Token Ring. На местном вычислительном центре главная вычислительная машина IBM подключена (через оборудование подключения каналов) к фронтальному процессору (FEP), который может также иметь связи с местными локальными сетями Token Ring и стержнем SNA. Оба пункта соединены с помощью арендуемой, базирующейся на SDLC, 56-Kb/сек линии.
Основы технологии
SDLC поддерживает разнообразные типы соединений и топологий. Он может применяться в сетях с двухточечными (непосредственными) и многоточечными связями, со связанным и несвязанным носителем, с полностью и наполовину дублированными средствами передачи, с коммутацией цепей и коммутацией пакетов.
SDLC идентифицирует два типа сетевых узлов:
Первичный
Управляет работой других станций (называемых вторичными). Первичный узел опрашивает вторичные в заранее заданном порядке. После этого вторичные узлы могут передавать, если у них имеются исходящие данные. Первичный узел также устанавливает каналы и завершает их работу, и управляет каналом во время его функционирования.
Вторичные
Управляются первичным узлом. Вторичные узлы могут только отсылать информацию в первичный узел, но не могут делать этого без получения разрешения от первичного узла.
Первичные и вторичные узды SDLC могут быть соединены в соответствии со следующими четырьмя основными конфигурациями:
Point-to-point (двухточечная).
Предполагает только два узла: один первичный и один вторичный.
Multipoint (многоточечная).
Включает в себя один первичный и множество вторичных узлов.
Loop (контур).
Подразумевает топологию контура, когда первичный узел соединяется с первым и последним вторичными узлами. Промежуточные вторичные узлы, отвечая на запросы первичного узла, передают сообщения друг через друга.
Hub go-ahead (готовый вперед).
Предполагает наличие входного и выходного каналов. Первичный узел использует выходной канал для связи со вторичными узлами. Вторичные узлы используют входной канал для связи в первичным. Входной канал соединяется с первичным узлом через каждый вторичный по схеме гирляндной цепи.
Производные протоколы
Несмотря на то, что в HDLC
не вoшли несколько характеристик, используемых в SDLC, он повсеместно считается некой суперразновидностью SDLC, совместимой с ним.
LAP считается подразновидностью HDLC. LAPB был разработан, чтобы обеспечить продолжение совместимости с HDLC, который был изменен в начале 1980 гг.
IEEE 802.2 является модификацией HDLC для окружений LAN. <
Протокол SDLC
 | Библиографическая справка |
| Основы технологии |
| Форматы блока данных |
| Производные протоколы |
Протокол РС (Path Control)
Обеспечивает управление путем в сетевой архитектуре SNA. В сети используется дейтаграммный принцип маршрутизации. В протоколе PC могут применяться два основных метода задания пути: явный и виртуальный. При явном пути в каждом узле составляется таблица маршрутов. Каждый путь нумеруется и статичен. Виртуальный путь (логическое соединение) - это надстройка над явным путем, ему соответствует явный путь и приоритет передачи (качество сервиса). Разным виртуальным путям может соответствовать один явный. Различают несколько форматов (в конкретном канале формат фиксирован) протокола PC в зависимости от условий применения. Особенности различных форматов отражены на рисунках.
Здесь:
FID(0) - cвязь между узлом SNA и узлом не SNA;
FID(1) - связь между двумя узлами подобласти, когда один из узлов или подобласть не поддерживает обработку явного и виртуального пути;
FID(2) - связь между узлом подобласти и РU2, использует локальные адреса. Преобразование локального адреса в глобальный производится в узле на основании своей, уникальной для данного узла таблицы;
FID(3) - аналогичен FID(2), но предназначен для связи с PU1;
FID(4) - связь между узлами подобласти, когда поддерживаются явный и виртуальный пути;
FID(5) - передача специальных сообщений, связанных с последовательностью сообщений FID(4).
| Структура FID(0)/FID(1). | |||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 0 | 0 | 0 | FID | MPF | X | EFI | резерв(0) | ||||||||
| ст. байт DAF | мл. байт | ||||||||||||||
| ст. байт DAF | мл. байт | ||||||||||||||
| ст. байт SNF | мл. байт | ||||||||||||||
| ст. байт DCF | мл. байт | ||||||||||||||
| данные | |||||||||||||||
| MPF - признак сегментации (при сегментации SNA фиксируется ): 00 - средний сегмент, 01 - последний - " -, 10 - первый - " - , 11 - единственный; |
|||||||||||||||
| FЕFI - тип потока: | |||||||||||||||
| 0 - нормальный поток (передаются данные и управляющая информация), | |||||||||||||||
| 1 - срочные данные (передается, как правило, только управляющая информация); | |||||||||||||||
| DAF - адрес назначения; OAF - адрес источника; SNF - последовательный номер пакета; DCF - счетчик данных (длина области данных). |
/p>
| Структура FID(2) | ||||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 0 | 0 | 1 | 0 | MPF | X | EFI | резерв(0) | ||||||||
| 2 | DAF | |||||||||||||||
| 4 | SNF | |||||||||||||||
| 6 | DCF | |||||||||||||||
| данные |
| FID(3) отличается от FID(2) первыми двумя байтами. | ||||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 0 | 0 | 1 | 1 | MPF | X | EFI | тип сессии | локальный адрес (LSID) | |||||||
| 2 | DAF | |||||||||||||||
| 4 | SNF | |||||||||||||||
| 6 | DCF | |||||||||||||||
| данные | ||||||||||||||||
| LSID -локальный идентификатор сессии; | ||||||||||||||||
| Тип сессии: 00 - SSCP PU (передается управляющая информация), 01 - SSCP-LU ( - " - ), 10 - резерв, 11 - LU -LU (перeдаются данные). |
| Структура FID(4) | ||||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 0 | 1 | 0 | 0 | S1 | S2 | S3 | S4 | резерв(0) | |||||||
| 2 | начальный номер явного пути | номер явного пути | номер виртуального пути | Х | приори-тет передачи | |||||||||||
| 4 | S5 | S6 | Последовательный номер для группы | |||||||||||||
| 6 | S7 | S8 | Последовательный номер для виртуального пути | |||||||||||||
|
8 10 |
D S A F - адрес подобласти назначения | |||||||||||||||
|
12 14 |
O S A F - адрес подобласти отправления | |||||||||||||||
| 16 | X | SNAI | MPF | X | EFI | резерв(0) | ||||||||||
| 18 | D A F | |||||||||||||||
| 20 | O A F | |||||||||||||||
| 22 | S N F | |||||||||||||||
| 24 | D C F | |||||||||||||||
| данные | ||||||||||||||||
| SNAI - индикатор SNA (тип устройства назначения): 0 - не SNA, 1 - SNA; | ||||||||||||||||
| S1 - управление потоком; S2 - индикация поддержки явного виртуального пути: 0/1 - поддерживает/не поддерживает; S3 - индикация счетчика темпа; |
||||||||||||||||
| S4 - сетевой приоритет: 1 - высший приоритет (передача управляющей информации); S5 - признак возможности (0) перемежения пакетов (при наличии нескольких параллельных физических линий); S6 - тип пакета: 0 - данные, 1 - подтверждение получения пакета; S7 - служебный признак (или передача данных =1); S8 - служебный признак (при передаче управляющей информации = 1). |
| Структура FID(5) | ||||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 1 | 1 | 1 | 1 | не определено | |||||||||||
| 2 | формат команды | тип команды | ||||||||||||||
| 4 | SNF | |||||||||||||||
| 6 | не определено | |||||||||||||||
| . | ||||||||||||||||
| . | ||||||||||||||||
| 22 | ||||||||||||||||
| 24 | DCF | |||||||||||||||
| 26 | данные |
table border="0" cellpadding="0" cellspacing="0" width="100%">
Протокол ТС
Обеспечивает управление передачей в сетевой архитектуре SNA (эквивалентен транспортному уровню ЭМВОС). Использует два протокольных блока: запрос/ответ. Данные передаются в блоке запроса. Форматы протокола представлены на рисунке.
| Формат запроса | ||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | инди-кац. запрос/ ответ | катего-рии RU | Х | индикац. формат | индикац. включе-ния смысловых данных | индикац. начала цепочки | индикац.конца цепочки | |
| 1 | индик. ответа | Х | инди-кац. ответа 2 | инди-кац. исключ. ответа | Х | индикац. запроса очереди | темп | |
| 2 | индик. начала |
инди-кац. конечн. | инди-кац. изме-нения | Х | индикац. выбора кода | принак шифро-вания | индикац. заполн. данных |
Х |
| Формат ответа | ||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 1 | -- | Х | - | -- | Х | Х | |
| 1 | -- | Х | -- | -- | Х | Х | -- | - |
Категория RU (категория потока данных): 00 - управление функциями (передача данных), 01 - управление сетью, 10 - управления потоком данных, 11 - управление сеансом.
Индикация формата - для всех категорий RU индикатор установлен в “1” (кроме RU=0), а для данных (RU=0) этот бит указывает на наличие заголовка следующего уровня.
Индикация смысловых данных - используется при диагностике.
Индикаторы ответов - определяют тип ответа.
Индикатор изменения направления - применяется для дополнительных режимов.
Индикатор начала/конца цепочки: 0 1 - первый RU, 0 0 - средний RU, 1 0 - последний RU, 1 1 - единственный RU.
Индикаторы начала и конца скобки обеспечивают сегментацию более высокого уровня.
Признак шифрования = 1 показывает использование закрытия данных.
Индикатор выбора кода: 0 - EBCDIC, 1 - ASCII.
Протоколы архитектуры SNA (фирмы IBM)
Логическая архитектура SNA состоит из шести уровней. Три верхних уровня (службы управления функциями, управление потоком данных, управление передачей) обеспечивают организацию и обслуживание сессий при обмене данными, три нижних уровня (управление путями, управление звеном данных, физический) - маршрутизацию и физическую передачу данных. Для обмена информацией в SNA используется набор протоколов связи между эквивалентными уровнями. Однородные уровни взаимодействуют путем обмена параметрами, содержащимися в заголовках.
Каждый сетевой ресурс или узел в SNA называется адресуемым элементом сети (NAU) и имеет соответствующий сетевой адрес, по которому осуществляется маршрутизация между NAU. Предусмотрены два типа NAU: физические элементы (PU) и логические элементы (LU). Имеется 4 типа PU: типа 1, реализованный в терминалах, выпущенных до введения SNA; типа 2, реализуемый в концентраторах, подобных IBM 3274; типа 3 - отсутствует; типа 4, реализуемый в связных процессорах; типа 5, реализуемый во VTAM.
Перечень протоколов приведен в таблице. Схема взаимодействия протоколов приведена здесь.
Особенности протоколов архитектуры SNA состоят в следующем. Основной функцией уровня управления звеном данных является обеспечение безошибочной передачи кадров, для чего организуется повторная передача искаженных кадров. В качестве основного протокола звена передачи данных используется протокол SDLC, могут поддерживаться и другие протоколы, включая BSC, асинхронные стартстопные процедуры и протокол Х.25.
Типовая структура кадра SNA представлена на рисунке.
|
Типовая структура кадра SNA |
||||
Заголовок |
Заголовок |
Заголовок |
Данные |
Концевик |
SDLC |
TH (протокол PC) |
RH (протокол TC) |
SDLC |
|
< BIO > |
||||
< BTU > |
||||
| ВIO - базовый информационный элемент; BTU - базовый элемент передачи. |
||||
BTU - базовый элемент передачи, является основным транспортным элементом архитектуры. BTU кроме SDLC может быть передан и другими протоколами, например Frame Relay, Ethernet, X.25, X.75, IP, TCP и др.
На уровне управления путями (протокол РС) формируется заголовок ТН имеющий несколько форматов, описанных ниже.
На уровне управления передачей (протокол ТС) формируется заголовок RH, который содержит совокупность параметров управления передачей (темп обмена, индикаторы сцепления, режимов и др.).
Уровень управления потоком данных (протокол DFC) поддерживает поток и логическое формирование данных между оконечными пользователями с помощью методов сцепления (заключения в скобки) и формирования режимов запросов/ответов. Скобки - это последовательность запросов и ответов, которые составляют цикл обмена. Соответствующие параметры помещаются в заголовки RН.
Абоненты сети SNA через шлюзы сетевого уровня (протокол РС) могут взаимодействовать с абонентами сетей TCP/IP, ISO и наоборот.
table border="0" cellpadding="0" cellspacing="0" width="100%">
Схема протоколов архитектуры SNA
На рисунке приведены схема взаимодействия протоколов сетевой архитектуры SNA и возможные схемы взаимодействия с другими сетевыми архитектурами. Краткое описание протоколов приведено в таблице.
| Обозна- чение | Название протокола (анг.) | Назначение протокола |
| NetBIOS
NetBEUI |
Протокол, обеспечивающий адресование пользователей в локальных сетях и обмен данными между ними | |
| DLS | Data Link Switching | Протокол взаимодействия с протоколами ТСР, ISO TP4 |
| SSP | Switch to Switch Protocol | |
| QLLC | Qualified Logical Link Control | Взаимодействие с протоколом Х.25 |
| TC | Transmission Control | Управление потоком команд |
| DDM | Distributed Data Management | Протокол обработки распределенных данных |
| DCA | Document Content Architecture | Протокол обработки распределенных документов |
| SNA/FS | File Services | Протокол управления файлами |
| DIA | Document Interchange Architecture | Протокол обмена документами (аналог электронной почты) |
| SNA/DS | SNA Distributed Services | Протокол распределенных услуг |
| SNA/MS | SNA Management Services | Протокол управления сетевыми объектами |
| LUG.2 | Logical Unit | Протокол прозрачного обмена данными между приложениями |
| DFC | Data Flow Control | |
| SCS | SNA Character Stream | Протокол обеспечения потока данных |
| IPDS | Intelligent Printer Data Stream | Протокол доступа к принтерам |
| 3270 Data Stream | Протокол обмена с терминалом IBM 3270 |
Библиографическая справка
В создание протокола SNMP внесли свой вклад разработки по трем направлениям:
High-level Entity Management System (HEMS)
Система управления об'ектами высшего уровня. Определяет систему управления с рядом интересных технических характеристик. К сожалению, HEMS использовалась только в местах ее разработки, что в конечном итоге привело к прекращению ее действия.
Simple Gateway Monitoring Protocol (SGMP)
Протокол управления простым роутером. Разработка была начата группой сетевых инженеров для решения проблем, связанных с управлением быстрорастущей Internet; результатом их усилий стал протокол, предназначенный для управления роутерами Internet. SGMP был реализован во многих региональных ветвях Internet.
CMIP over TCP (CMOT)
CMIP над ТСР. Пропагандирует сетевое управление, базирующееся на OSI, в частности, применение Common Management Information Protocol (CMIP) (Протокол информации общего управления) для облегчения управления об'единенных сетей, базирующихся на ТСР.
Достоинства и недостатки этих трех методов (HEMS, SGMP и CMOT) часто и горячо обсуждались в течение второй половины 1987 г. В начале 1988 г. был образован комитет Internet Activities Board - IAB (IAB - это группа, ответственная за техническую разработку протоколов Internet) для разрешения дебатов по поводу протокола сетевого управления. В конечном итоге комитет IAB пришел к соглашению, что улучшенная версия SGMP, которая должна была называться SNMP, должна стать временным решением; для долгосрочного применения должна быть проанализирована одна из технологий, базирующихся на OSI (либо СМОТ, либо сам СMIP). Для обеспечения легкого пути наращивания была разработана общая структура сетевого управления (которая теперь называется стандартной Структурой Управления Сети - Network Management Framework).
Сегодня SNMP является самым популярным протоколом управления различными коммерческими, университетскими и исследовательскими об'единенными сетями. Деятельность по стандартизации, связанная с SNMP, продолжается по мере того, как поставщики разрабатывают и выпускают современные прикладные программы управления, базирующиеся на SNMP. SNMP относительно простой протокол, однако набор его характеристик является достаточно мощным для решения трудных проблем, возникающих при управлении гетерогенных сетей.
Формат сообщений
Сообщения SNMP состоят из 2 частей: имени сообщества (community name) и данных (data). Имя сообщества назначает среду доступа для набора NMS, которые используют это имя. Можно сказать, что NMS, принадлежащие одному сообществу, находятся под одним и тем же административным началом. Т.к. устройства, которые не знают правильного имени сообщества, исключаются из операций SNMP, управляющие сетей также используют имя сообщества в качестве слабой формы опознавания.
Информационная часть сообщения содержит специфичную операцию SNMP (get, set, и т.д.) и связанные с ней операнды. Операнды обозначают реализации об'екта, которые включены в данную транзакцию SNMP.
Сообщения SNMP официально называются протокольными единицами данных (protocol data units - PDU). На рисунке изображен формат пакета SNMP.
PDU операций get и set SNMP состоят из следующих частей:
Request-ID (идентификатор запроса).
Устанавливает связь между командами и ответами.
Error-status (состояние сбоя).
Указывает ошибку и ее тип.
Error-index (индекс ошибки).
Устанавливвает связь между ошибкой и конкретной реализацией об'екта.
Variable bindings (переменные привязки).
Состоят из данных SNMP PDU. Пепеменные привязки устанавливают связь между конкретными переменными и их текущими значениями.
PDU ловушки несколько отличаются от PDU других операций. Они состоят из следующих частей:
Enterprise (предметная область).
Идентифицирует тип об'екта, генерирующего данную ловушку.
Agent address (адрес агента).
Обеспечивает адрес об'екта, генерирующего данную ловушку.
Generic trap type (групповой тип ловушки).
Обеспечивает групповой тип ловушки.
Specific trap code (специфичный код ловушки).
Обеспечивет специфичный код ловушки.
Time stamp (временной ярлык).
Обеспечивает величину времени, прошедшего между последней повторной инициализацией сети и генерацией данной ловушки.
Variable bindings (переменные привязки).
Обеспечивает перечень переменных, содержащих интересную информацию о ловушке.
<
Основы технологии
SNMP является протоколом прикладного уровня, предназначенным для облегчения обмена информацией управления между сетевыми устройствами. Пользуясь информацией SNMP (такой, как показатель числа пакетов в секунду и коэффициент сетевых ошибок), сетевые администраторы могут более просто управлять производительностью сети и обнаруживать и решать сетевые проблемы.
Все структуры заголовков и данных протоколы кодируются с использованием абстрактно синтаксической нотации 1 (АСН.1).
Модель управления
Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают, и делают эту информацию доступной для систем управления сетями (network management systems - NMS) с помощью протокола SNMP. Эта модель представлена графически на рисунке.
Управляемое устройство может быть узлом любого типа, находящимся в какой-нибудь сети: это хосты, служебные устройства связи, принтеры, роутеры, мосты и концентраторы. Т.к. некоторые из этих систем могут иметь ограниченные способности управления программным обеспечением (например, они могут иметь центральные процессоры с относительно малым быстродействием или ограниченный об'ем памяти), программное обеспечение управления должно сделать допущение о наименьшем общем знаменателе. Другими словами, программы управления должны быть построены таким образом, чтобы минимизировать воздействие своей производительности на управляемое устройство.
Т.к. управляемые устройства содержат наименьший общий знаменатель программного обеспечения управления, тяжесть управления ложится на NMS. Поэтому NMS обычно являются компьютерами калибра АРМ проектировщика, которые имеют быстродействующие центральные процессоры, мегапиксельные цветные устройства отображения, значительный об'ем памяти и достаточный об'ем диска. В любой управляемой сети может иметься одна или более NMS. NMS прогоняют прикладные программы сетевого управления, которые представляют информацию управления пользователям.
Интерфейс пользователя обычно базируется на стандартизированном графическом интерфейсе пользователя (graphical user interface - GUI).
Сообщение между управляемыми устройствами и NMS регулируется протоколом сетевого управления. Стандартный протокол сети Internet, Network Management Framework, предполагает парадигму дистанционной отладки, когда управляемые устройства поддерживают значения ряда переменных и сообщают их по требованию в NMS. Например, управляемое устройство может отслеживать следующие параметры:
Число и состояние своих виртуальных цепей
Число определенных видов полученных сообщений о неисправности
Число байтов и пакетов, входящих и исходящих из данного устройства
Максимальная длина очереди на выходе (для роутеров и других устройств об'единения сетей)
Отправленные и принятые широковещательные сообщения
Отказавшие и вновь появившиеся сетевые интерфейсы
Типы команд
Если NMS хочет проконтролировать какое-либо из управляемых устройств, она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных. В целом управляемые устройства отвечают на четыре типа команд (или инициируют их):
Reads
Для контролирования управляемых устройств NMS считывают переменные, поддерживаемые этими устройствами.
Writes
Для контролирования управляемых устройств NMS записывают переменные, накопленные в управляемых устройствах
Traversal operations
NMS используют операции прослеживания, чтобы определить, какие переменные поддерживает управляемое устройство, а затем собрать информацию в таблицы переменных (такие, как таблица маршрутизации IP)
Traps
Управляемые устройства используют ловушки для асинхронных сообщений в NMS о некоторых событиях.
Различия в представлениии информации
Обмен информацией в управляемой сети находится потенциально под угрозой срыва из-за различий в технике представления данных, используемой управляемыми устройствами. Другими словами, компьютеры представляют информацию по-разному; эту несовместимость необходимо рационализировать, чтобы обеспечить сообщение между различными системами.
Эту функцию выполняет абстрактный синтаксис. SNMP использует для этой цели подмножество абстрактного синтаксиса, созданного для OSI - Abstract Syntax Notation One (ASN.1) (Система обозначений для описания абстрактного синтаксиса). ASN.1 определяет как форматы пакетов, так и управляемые об'екты. Управляемый об'ект-это просто характеристика чего-либо, которой можно управлять. Управляемый об'ект отличается от переменной, которая является конкретной реализацией об'екта. Управляемые об'екты могут быть скалярными (определяя отдельную реализацию) или табулярными величинами (определяя несколько связанных друг с другом реализаций).
Базы данных управления
Все управляемые об'екты содержатся в Информационной базе управления (Management Information Base - MIB), которая фактически является базой данных об'ектов. Логически MIB можно изобразить в виде абстрактного дерева, листьями которого являются отдельные информационные элементы. Идентификаторы об'ектов уникальным образом идентифицируют об'екты MIB этого дерева. Идентификаторы об'ектов похожи на телефонные номера тем, что они организованы иерархически и их отдельные части назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в каком он определен в данной стране. Телефонные номера в США далее делятся на код области, номер центральной телефонной станции (СО) и номер станции, связанной с этой СО. Аналогично, идентификаторы об'ектов высшего уровня MIB назначаются Международной Электротехнической Комиссией ISO (ISO IEC). ID об'ектов низшего уровня назначаются относящимися к ним организациями. На рисунке изображены корневая и несколько наиболее крупных ветвей дерева MIB.
Дерево MIB расширяемо благодаря экспериментальным и частным ветвям. Например, поставщики могут определять свои собственные ветви для включения реализаций своих изделий. В настоящее время вся работа по стандартизации ведется на экспериментальной ветви.
Структуру MIB определяет документ, называемый Структура Информации Управления (Structure of Management Information - SMI). SMI определяет следующие типы информации:
Network addresses (Сетевые адреса)
Предсталяют какой-нибудь адрес из конкретного семейства протоколов. В настоящее время единственным примером сетевых адресов являются 32-битовые адреса IP.
Counters (Счетчики)
Неотрицательные целые числа, которые монотонно увеличиваются до тех пор, пока не достигнут максимального значения, после чего они сбрасываются до нуля. Примером счетчика является общее число байтов, принятых интерфейсом.
Gauges (Измерительный прибор, мера, размер)
Неотрицательные целые числа, которые могут увеличиваться или уменьшаться, но запираются при максимальном значении. Примером измерительного прибора является длина очереди, состоящей из выходных пакетов (в пакетах).
Ticks (Тики)
Сотые доли секунды, прошедшие после какого-нибудь события. Примером tick является время, прошедшее после вхождения интерфейса в свое текущее состояние.
Opaque (Мутный)
Произвольное кодирование. Используется для передачи произвольных информационных последовательностей, находящихся вне пределов точного печатания данных, которое использует SMI.
Операции
SNMP является простым протоколом запроса/ответа. Узлы могут отправлять множество запросов, не получая ответа. Определены следующие 4 операции SNMP:
Get (достань).
Извлекает какую-нибудь реализацию об'екта из агента.
Get-next (достань следующий).
Операция прослеживания, которая извлекает следущую реализацию об'екта из таблицы или перечня, находящихся в каком-нибудь агенте.
Set (установи).
Устанавливает реализации об'екта в пределах какого-нибудь агента.
Trap (ловушка).
Используется агентом для асинхронного информирования NMS о каком-нибудь событии.
Протокол сетевого управления SNMP
 | Библиографическая справка | ||||||||||
| Основы технологии
| ||||||||||
| Формат сообщений |
История TCP/IP
В середине 1970 гг. Агентство по Внедрению Научно-исследовательских Проектов Передовой технологии при Министерстве обороны (DARPA) заинтересовалось организацией сети с коммутацией пакетов для обеспечения связи между научно-исследовательскими институтами в США. DARPA и другие правительственные организации понимали, какие потенциальные возможности скрыты в технологии сети с коммутацией пакетов; они только что начали сталкиваться с проблемой, с которой сейчас приходится иметь дело практически всем компаниям, а именно с проблемой связи между различными компьютерными системами.
Поставив задачу добиться связности гетерогенных систем, DARPA финансировала исследования, проводимые Стэнфордским университетом и компаниями Bolt, Beranek и Newman (BBN) с целью создания ряда протоколов связи. Результатом этих работ по разработке, завершенных в конце 1970 гг., был комплект протоколов Internet, из которых наиболее известными являются Transmission Control Protocol (TCP) и Internet Protocol
(IP).
Процесс разработки и выдачи документации протоколов Internet скорее напоминает академический исследовательский проект, чем что-либо другое. Протоколы определяются в документах, называемых Requests for Comments (RFC) (Запросы для Комментария). RFC публикуются, а затем рецензируются и анализируются специалистами по Internet. Уточнения к протоколам публикуются в новых RFC. Взятые вместе, RFC обеспечивают красочную историю людей, компаний и направлений, которые формировали разработку компекта протоколов для открытой системы, который сегодня является самым популярным в мире.
<
Протоколы высших уровней TCP/IP
Комплект протоколов Internet включает в себя большое число протоколов высших уровней, представляющих самые разнообразные применения, в том числе управление сети, передача файлов, распределенные услуги пользования файлами, эмуляция терминалов и электронная почта.
 | Протокол передачи файлов (File Transfer Protocol - FTP)
обеспечивает способ перемещения файлов между компьютерными системами. Telnet обеспечивает виртуальную терминальную эмуляцию. |
| Протокол управления простой сетью (Simle network management protocol - SNMP) является протоколом управления сетью, используемым для сообщения об аномальных условиях в сети и установления значений допустимых порогов в сети. X Windows является популярным протоколом, который позволяет терминалу с интеллектом связываться с отдаленными компьютерами таким образом, как если бы они были непосредственно подключенными мониторами. |
| Комбинация протоколов Network File System (NFS) (Система сетевых файлов), External Data Representation (XDP) (Представление внешней информации) и Remote Procedure Call (RPC) (Вызов процедуры обращений к отдаленной сети) обеспечивает прозрачный доступ к ресурсам отдаленной сети. |
| Простой протокол передачи почты (Simple Mail Transfer Protocol - SMTP)
обеспечивает механизм передачи электронной почты. |
Эти и другие применения используют услуги ТСР/IP и других протоколов Internet низших уровней, чтобы обеспечить пользователей базовыми сетевыми услугами.
Сетевая архитектура TCP/IP
Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.
Структура протоколов TCP/IP приведена на рисунке. Протоколы TCP/IP делятся на 4 уровня.
Самый нижний (уровень IV) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: для локальных сетей это Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальных сетей - протоколы соединений "точка-точка" SLIP и PPP, протоколы территориальных сетей с коммутацией пакетов X.25, frame relay. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции пакетов IP в ее кадры.
Следующий уровень (уровень III) - это уровень межсетевого взаимодействия, который занимается передачей пакетов с использованием различных транспортных технологий локальных сетей, территориальных сетей, линий специальной связи и т. п.
В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP, который изначально проектировался как протокол передачи пакетов в составных сетях, состоящих из большого количества локальных сетей, объединенных как локальными, так и глобальными связями. Поэтому протокол IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP является дейтаграммным протоколом, то есть он не гарантирует доставку пакетов до узла назначения, но старается это сделать.
К уровню межсетевого взаимодействия относятся и все протоколы, связанные с составлением и модификацией таблиц маршрутизации, такие как протоколы сбора маршрутной информации RIP (Routing Internet Protocol) и OSPF (Open Shortest Path First), а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol).
Последний протокол предназначен для обмена информацией об ошибках между маршрутизаторами сети и узлом - источником пакета. С помощью специальных пакетов ICMP сообщается о невозможности доставки пакета, о превышении времени жизни или продолжительности сборки пакета из фрагментов, об аномальных величинах параметров, об изменении маршрута пересылки и типа обслуживания, о состоянии системы и т.п.
Следующий уровень (уровень II) называется основным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.
Верхний уровень (уровень I) называется прикладным. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и сервисов прикладного уровня. К ним относятся такие широко используемые протоколы, как протокол копирования файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы доступа к удаленной информации, такие как WWW и многие другие. Остановимся несколько подробнее на некоторых из них.
Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP. Кроме пересылки файлов протокол FTP предлагает и другие услуги. Так, пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов. Наконец, FTP выполняет аутентификацию пользователей. Прежде, чем получить доступ к файлу, в соответствии с протоколом пользователи должны сообщить свое имя и пароль.
Для доступа к публичным каталогам FTP- архивов Internet парольная аутентификация не требуется, и ее обходят за счет использования для такого доступа предопределенного имени пользователя Anonymous.
В стеке TCP/IP протокол FTP предлагает наиболее широкий набор услуг для работы с файлами, однако он является и самым сложным для программирования. Приложения, которым не требуются все возможности FTP, могут использовать другой, более экономичный протокол - простейший протокол пересылки файлов TFTP (Trivial File Transfer Protocol). Этот протокол реализует только передачу файлов, причем в качестве транспорта используется более простой, чем TCP, протокол без установления соединения - UDP.
Протокол telnet обеспечивает передачу потока байтов между процессами, а также между процессом и терминалом. Наиболее часто этот протокол используется для эмуляции терминала удаленного компьютера. При использовании сервиса telnet пользователь фактически управляет удаленным компьютером так же, как и локальный пользователь, поэтому такой вид доступа требует хорошей защиты. Поэтому серверы telnet всегда используют как минимум аутентификацию по паролю, а иногда и более мощные средства защиты, например, систему Kerberos.
Протокол SNMP (Simple Network Management Protocol) используется для организации сетевого управления. Изначально протокол SNMP был разработан для удаленного контроля и управления маршрутизаторами Internet, которые традиционно часто называют также шлюзами. С ростом популярности протокол SNMP стали применять и для управления любым коммуникационным оборудованием - концентраторами, мостами, сетевыми адаптерами и т.д. и т.п. Проблема управления в протоколе SNMP разделяется на две задачи.
Первая задача связана с передачей информации. Протоколы передачи управляющей информации определяют процедуру взаимодействия SNMP-агента, работающего в управляемом оборудовании, и SNMP-монитора, работающего на компьютере администратора, который часто называют также консолью управления. Протоколы передачи определяют форматы сообщений, которыми обмениваются агенты и монитор.
Вторая задача связана с контролируемыми переменными, характеризующими состояние управляемого устройства. Стандарты регламентируют, какие данные должны сохраняться и накапливаться в устройствах, имена этих данных и синтаксис этих имен. В стандарте SNMP определена спецификация информационной базы данных управления сетью. Эта спецификация, известная как база данных MIB (Management Information Base), определяет те элементы данных, которые управляемое устройство должно сохранять, и допустимые операции над ними.
Данная архитектура является одной из самых распространенных, так как ее протоколы используются для создания глобальной мегасети Internet. На рисунке приведена схема взаимодействия протоколов данной сетевой архитектуры. В таблице
представлен перечень протоколов архитектуры TCP/IP.
Основные особенности архитектуры состоят в следующем.
Протокол сетевого уровня IP реализует дейтаграммный способ передачи блоков данных (без установления соединения).
Используются два транспортных протокола ТСР (с установлением соединения и подтверждением доставки данных) и UDP (без установления соединения и подтверждения).
Протокол ТСР для передачи использует прикладные протоколы SMTP, RPC, TELNET, FTP и др. На протокол UDP ориентированы прикладные протоколы SNMP, TFTP, BOOTP.
Для адресации кроме IP-адресов используются условные имена ЭВМ (доменные имена службы DNS). Поэтому в составе сети имеются серверы имен DNS, обеспечивающие преобразование имен в IP-адреса.
Семейство протоколов маршрутизации делится на группу протоколов определения маршрутов внутри автономной сети (IGP, RIP, IGRP, OSPF, GATED) и группу внешних протоколов, обеспечивающих взаимодействие маршрутизаторов (EGP, BGP, IDRP).
Транспортные протоколы TCP и UDP не приспособлены для поддержки приложений реального времени, с этой целью разработана группа протоколов реального времени RTP, RTCP, RSVP.
| Обозна- чение | Название протокола (анг.) | Назначение протокола |
| TCP/IP | Transmission Control Protocol | Транспортный протокол с установлением соединения и подтверждением доставки |
| ISO-DE | ISO Development Tnvironment | |
| ARP | Address Resolution Protocol | Протокол преобразования IP-адреса в Ethernet-адрес. Используется в локальных сетях. Обеспечивает механизм привязки MAC адреса абонента (адрес сетевой карты) к его IP адресу |
| RARP | Reverse ARP | Протокол обратной трансляции адресов |
| RIP | Routing Information Protocol | Протокол внутренней маршрутизации, обеспечивает обмен маршрутной информации между маршрутизаторами |
| PPP | Point tu Point | Протокол организации двухточечного соединения объектов для последоват. канала связи, используется для связи с серверами доступа к сети и для связи маршрутизаторов друг с другом, поддерживает механизмы мультипротокольности и сжатия заголовков |
| SLIP | Serial Line over IP | Байториентированный протокол инкапсуляции IP-дейтограмм для последовательных каналов связи, используется для связи с серверами доступа к сети. |
| CSLIP | Compessed SLIP | Модификация протокола SLIP за счет сжатия заголовка |
| X.25 | Packet Level Protocol | Сетевой протокол ISO, предназначенный для построения распределенных глобальных сетей, часто выступает в качестве транспорта для передачи TCP/IP трафика. |
| IP | Internet Protocol | Межсетевой протокол без установления соединения (дейтограммный режим), используемый для построения сетей всех типов (глобальных, корпоративных, локальных), является базовым протоколом сетей Internet и DDN |
| UDP | User Datagram Protocol | Транспортный протокол без установления соединения и подтверждения доставки, активно используется для передачи речи и видео через ИВС. |
| BGP | Border Gateway Protocol | Протокол пограничного (внешнего) маршрутизатора для обмена маршрутной информацией между внешними маршрутизаторами (шлюзами) подсетей глобальной сети Internet |
| EGP | Exterior Gateway Protocol | Протокол внешней маршрутизации для обмена маршрутной информацией между внешними маршрутизаторами (шлюзами) подсетей глобальной сети Internet |
| GGP | Gateway to Gateway Protocol | Протокол передачи информации для узловых маршрутизаторов о подключенных сетях, обеспечивает обмен маршрутной информацией между внутренними маршрутизаторами (шлюзами) подсетей глобальной сети Internet. |
| IGMP | Interior Gateway Routing Protocol CISCO | Протокол для видеоконференций, передачи звуковых сообщений,а также для группового исполнения команд, для обмена маршрутной информацией между внутреннии маршрутизаторами фирмы CISCO |
| OSPF | Open Shortest Path First Routing Protocol | Протокол состояния маршрута, для обмена маршрутной информации между маршрутизаторами, поддерживающими процедуру маршрутизации OSPF |
| ICMP | Internet Control Message Protocol | Протокол передачи команд и сообщений об ошибках, для обмена диагностическими и управляющими сообщениями между клиентами сети |
| BOOTP | Bootstrap Protocol | Протокол дистанционной загрузки и запуска устройств в сети, обеспечивает автоматическую дистанционную замену СПО на различных сетевых объектах. |
| IGRP | Протокол внутренней маршрутизации, обеспечивает создание и поддержку групп в сети, обмен информацией в режиме коллективной широковещательной рассылки между членами группы. | |
| X WIN | X Windows Systems X10/X11 | Системный протокол X-Windows, обеспечивающий удаленное управление оконным экранным интерфейсом X-Windows операционной системы Unix, обеспечивает обмен команд и данных при модификации окон. |
| ARPA Services: | ||
| FTP | File Transfer Protocol | Протокол обмена файлами, поддерживает механизмы аутенфикации, удаленного доступа к каталогам, выбора и передачи файлов; обеспечивает поддержку одновременно двух соединений: для обмена управляющими командами в режиме диалога и для пересылки файлов. |
| VT | Virtual Terminal | Протокол удаленного доступа к ЭВМ в режиме виртуального терминала; позволяет запускать на удаленной ЭВМ приложения, обращаться к другим элементам сети от имени ЭВМ, на которой получен доступ в режиме Telnet; поддерживает механизмы аутенфикации. Протокол сводится к обмену текстовыми сообщениями. |
| SMTP | Simple Mail Transfer Protocol | Протокол электронной почты в сети Internet, используется для обмена почтой между серверами SMTP. |
| HP - Hewlett-Packard Network Services: | ||
| NFT | Network File Transfer | Протокол передачи файлов, аналог FTP |
| RDA | Remote Database Access | Протокол удаленного доступа к серверам баз данных, обеспечивает формирование запросов на языке SQL и получение ответов. |
| RFA | Remote File Access | Удаленный доступ к файлам, обеспечивает управление файлами, просмотр и редактирование. |
| RPC | Remote Process Comm. | Протокол удаленного запуска приложений в ЭВМ |
| VT | Virtual Terminal | Аналог протокола Telnet |
| NTP | Network Time Protocol | Протокол времени, обеспечивающий автоматическую синхронизацию времени в элементах сети. |
| TFTP | Trivial File Transfer Protocol | Протокол упрощенной пересылки файлов. |
| CMOT | CMIP over TCP/IP, see also ISO | Протокол обмена служебной информацией между элементами сети, обеспечивает удаленный контроль и управление. |
| DNS | Domain Name Server | Протокол получения IP адресов, соответствующих доменных названий и наоборот, используется для организации запросов от пользователей к серверам доменных имен DNS. |
| RUNIX - Remote UNIX Services: | ||
| IPR | Remote Print | Удаленная печать средствами UNIX |
| RCP | Remote Copi | Удаленное копирование файлов |
| REXES | Remote Execution | Удаленный запуск программ |
| RIOGIN | Remote Login | Удаленный доступ с аутенфикацией пользователя |
| RSH | Remote Shell | Запуск удаленного командного процессора для работы с пользователем |
| SUN - Sun Network Services: | ||
| NFS | Network File System | Прозрачный доступ к удаленным файлам, |
| NIS | Network Information Services | |
| PMAP | Port Mapper | |
| SNMP | Simple Network Mgmt. Protocol V1, V2, RMON | Протокол обмена служебной информацией между элементами сети, обеспечивает удаленный контроль и управление, базируется на АСН.1 нотации. |
| XDR | Exchange Data Represantative Protocol | Формат внешнего представления данных |
| RPC | Remote Procedure Call | Вызов удаленных процедур, запуск процедур и программ на удаленном компьютере |
| ND | Network Disk |
Сетевой уровень
IP является основным протоколом Уровня 3 в комплекте протоколов Internet. В дополнение к маршрутизации в об'единенных сетях, IР обеспечивает фрагментацию и повторную сборку дейтаграмм, а также сообщения об ощибках. Наряду с ТСР, IP представляет основу комплекта протоколов Internet.
В настоящее время наиболее широко (можно сказать повсеместно) используется IP протокол версии 4. Однако данный протокол в настоящее время уже не полностью удовлетворяет потребности сетевого сообщества по двум основным причинам:
| очень остро встал вопрос нехватки адресного пространства (данный протокол имеет 32 разрядный адрес) | |
| алгортмы маршрутизации протокола не смогут обеспечить требуемой производительности при дальнейшем росте сети |
Поэтому была разработана новая версия протокола IP. Протокол новой генерации - IP версия 6. Обозначаемый как IP-V6. Данный протокол в настоящее время проходит опытную эксплуатацию в экспериментальных сегментах сети. Поставщики маршрутизаторов начинают изготавливать устройства с поддержкой этого протокола. На первых порах планируется совместное использование этих протоколов, вплоть до вытеснения старого IP.
Схема протоколов архитектуры TCP/IP
На рисунке приведены схема взаимодействия протоколов сетевой архитектуры TCP/IP и возможные схемы взаимодействия с другими сетевыми архитектурами.
<
Транспортный уровень TCP/IP
Транспортный уровень Internet реализуется ТСР и Протоколом Дейтаграмм Пользователя (User Datagram Protocol - UDP).
ТСР обеспечивает транспортировку данных с установлением соединения, в то время как UDP работает без установления соединения. <
Базовая передача данных
Протокол TCP способен передавать непрерывные потоки октетов между своими клиентами в обоих направлениях, пакуя некое количество октетов в сегменты для передачи через системы Internet. В общем случае протоколы TCP решают по своему усмотрению, когда производить блокировку и передачу данных.
Иногда пользователям бывает необходимо убедиться в том, что все данные, переданные ими протоколу TCP, уже отправлены. Для этой цели определена функция проталкивания (push). Чтобы убедиться в том, что данные, отправленные протоколу TCP, действительно переданы, отправитель указывает, что их следует протолкнуть к получателю.
Проталкивание приводит к тому, что программы протокола TCP сразу осуществляют отправление и, соответственно, получение остающихся данных. Правильно осуществленное проталкивание может быть невидимо для получателя, а сама функция проталкивания может не иметь маркера границы записи.
Действие (tcp)
Как указывалось ранее, главной целью протокола TCP является обеспечение надежного, безопасного сервиса для логических цепей или соединений между парами процессов. Чтобы обеспечить такой сервис, основываясь на менее надежных коммуникациях Internet, система должна иметь возможности для работы в следующих областях:
 | базовая передача данных |
| достоверность |
| управление потоком |
| разделение каналов |
| работа с соединениями |
| приоритет и безопасность |
Основные действия протокола TCP в каждой из этих областей описаны в следующих параграфах.
Достоверность
Протокол TCP должен иметь защиту от разрушения данных, потери, дублирования и нарушения очередности получения, вызываемых коммуникационной системой Internet. Это достигается присвоением очередного номера каждому передаваемому октету, а также требованием подтверждения (ACK) от программы TCP, принимающей данные. Если подтверждения не получено в течении контрольного интервала времени, то данные посылаются повторно. Со стороны получателя номера очереди используются для восстановления очередности сегментов, которые могут быть получены в неправильном порядке, а также для ограничения возможности появления дубликатов.
Повреждения фиксируются посредством добавления к каждому передаваемому сегменту контрольной суммы, проверки ее при получении и последующей ликвидации дефектных сегментов.
До тех пор, пока программы протокола TCP продолжают функционировать корректно, а система Internet не развалилась полностью на составные части, ошибки пересылки не будут влиять на правильное получение данных. Протокол TCP защищает от ошибок коммуникационной системы Internet.
Формат TCP заголовка
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 |
| Source Port | Destination Port | ||||||||||||||||||||||||||||||
| Sequence Number | |||||||||||||||||||||||||||||||
| Acknowledgment Number | |||||||||||||||||||||||||||||||
| Data Offset |
Reserved | U R G |
A C K |
P S H |
P S T |
S Y N |
F I N |
Window | |||||||||||||||||||||||
| Checksum | Urgent Pointer | ||||||||||||||||||||||||||||||
| Options | Padding | ||||||||||||||||||||||||||||||
| Data |
Отметим, что каждая метка указывает здесь место для соответствующего бита.
(порт отправителя) 16 бит номер порта отправителя
(порт получателя) 16 бит номер порта получателя
Номера портов источника и получателя определяют прикладной процесс инициировавший данное соединение. Закрепление номеров портов осуществляется в соответствии с рекомендацией RFC-1700. Список основных портов приведен здесь.
(номер очереди) 32 бита
Номер очереди для первого октета данных в данном сегменте (за исключением тех случаев, когда присутствует флаг синхронизации SYN). Если же флаг SYN присутствует, то номер очереди является инициализационным (ISN), а номер первого октета данных - ISN+1.
(номер подтверждения) 32 бита
Если установлен контрольный бит ACK, то это поле содержит следующий номер очереди, который отправитель данной датаграммы желает получить в обратном направлении. Номера подтверждения посылаются постоянно, как только соединение будет установлено.
(смещение данных) 4 бита
Количество 32-битных слов в TCP заголовке. Указывает на начало поля данных. TCP заголовок всегда кончается на 32-битной границе слова, даже если он содержит опции.
Reserved 6 бит
Это резервное поле, должно быть заполнено нулями.
(контрольные биты) 6 бит
Биты этого поля слева направо
| поле срочного указателя задействовано |
| поле подтверждения задействовано |
| функция проталкивания |
| перезагрузка данного соединения |
| синхронизация номеров очереди |
| нет больше данных для передачи |
Window (окно) 16 бит
Количество октетов данных, начиная с октета, чей номер указан в поле подтверждения.
Количество октетов, получения которых ждет отправитель настоящего сегмента.
Checksum
(контрольная сумма) 16 бит
Поле контрольной суммы - это 16-битное дополнение суммы всех 16- битных слов заголовка и текста. Если сегмент содержит в заголовке и тексте нечетное количество октетов, подлежащих учету в контрольной сумме, последний октет будет дополнен нулями справа с тем, чтобы образовать для предоставления контрольной сумме 16-битное слово. Возникший при таком выравнивании октет не передается вместе с сегментом по сети. Перед вычислением контрольной суммы поле этой суммы заполняется нулями.
Контрольная сумма, помимо всего прочего, учитывает 96 бит псевдозаголовка, который для внутреннего употребления ставится перед TCP заголовком. Этот псевдозаголовок содержит адрес отправителя, адрес получателя, протокол и длину TCP сегмента. Такой подход обеспечивает защиту протокола TCP от ошибшихся в маршруте сегментов. Эту информацию обрабатывает Internet протокол. Она передается через интерфейс протокол TCP/локальная сеть в качестве аргументов или результатов запросов от протокола TCP к протоколу IP.
| Адрес отправителя | ||
| Адрес получателя | ||
| нули | PTCL | длина TCP |
Urgent Pointer
(срочный указатель) 16 бит
Это поле сообщает текущее значение срочного указателя. Последний является положительной величиной - смещением относительно номера очереди данного сегмента. Срочный указатель сообщает номер очереди для октета, следующего за срочными данными. Это поле интерпретируется только в том случае, когда в сегменте выставлен контрольный бит URG.
Options
(опции) длина переменная
Опции могут располагаться в конце TCP заголовка, а их длина кратна 8 бит. Все опции учитываются при расчете контрольной суммы.
Опции могут начинаться с любого октета.
Они могут иметь два формата:
| однооктетный тип опций; |
| октет типа опции, октет длины опции и октеты данных рассматриваемой опции. |
Заметим, что список опций может оказаться короче, чем можно указать в поле Data Offset. Место в заголовке, остающееся за опцией "End-of-Option", должно быть заполнено нулями. Протокол TCP должен быть готов обрабатывать все опции.
В настоящее время определены следующие опции:
| 0 | - | конец списка опций |
| 1 | - | нет операций |
| 2 | 4 | максимальный размер сегмента |
Формат заголовка
Передача TCP сегментов осуществляется в виде Internet датаграмм. Заголовок датаграммы в Internet протоколе имеет несколько информационных полей, включая адреса отправляющего и принимающего хост- компьютеров. Заголовок TCP следует за Internet заголовком и дополняет его информацией, специфической для TCP протокола. Такое деление допускает использование на уровне хост-компьютеров протоколов, иных нежели TCP.
Идеология протокола tcp
| Элементы системы объединенных сетей |
| Модель действи |
| Программное обеспечение хост-компьютера Интерфейсы |
| Связь с другими протоколам |
| Надежные коммуникации |
| Установка соединения и его отмен |
| Коммуникация данных |
| Приоритет и безопасность |
| Принцип устойчивости |
Интерфейс клиент/TCP
Нижеприведенное функциональное описание команд клиента, посылаемых программе протокола TCP, является, в лучшем случае, умозрительным, поскольку каждая операционная система будет иметь свои характеристики. Следовательно, мы должны предупредить читателей о том, что различные реализации протокола TCP могут иметь различный интерфейс с клиентом. Однако, все реализации протокола TCP должны обеспечивать некий минимальный набор услуг с тем, чтобы гарантировать, что все они придерживаются единой иерархии протокола. Данная глава описывает функциональный интерфейс, обязательный для всех реализаций протокола TCP.
Интерфейсы
Для запросов со стороны пользователя к протоколу TCP интерфейс TCP/пользователь обеспечивает открытие и закрытие соединения, посылку и получение данных или же получение статуса соединения. Эти запросы похожи на другие запросы программы пользователя к операционной системе, например, на запросы открытия, чтения и закрытия файла.
Интерфейс между протоколами TCP и Internet поддерживает запросы на посылку и получение датаграмм, адресованных на модули TCP в хост- компьютерах в любом месте сети Internet. Рассматриваемые запросы имеют аргументы для указания адреса, типа сервиса, приоритета, безопасности, а также передачи другой управляющей информации.
Конечно, здесь затрагиваются два интерфейса. Интерфейс клиент/ протокол TCP и интерфейс протокол TCP/протокол нижнего уровня. Мы имеем более тщательно разработанную модель для первого из них. Но здесь не рассматривается интерфейс с модулем протокола нижнего уровня, поскольку это сделано в спецификации последнего. Для случая, когда в интерфейсе нижний уровень - это протокол IP, мы лишь отметим некоторые из допустимых параметров, используемых протоколом TCP.
Элементы системы объединенных сетей
Среда объединенных сетей состоит из хост-компьютеров, включенных в сети, которые в свою очередь соединятся друг с другом через шлюзы.
Здесь предполагается, что компьютерные сети могут быть либо локальными (например, ETHERNET), либо большими сетями (например ARPANET), но в любом случае они основываются на технологии коммутации пакетов. Реальными агентами, создающими и потребляющими сообщения, циркулирующие в сети, являются процессы. Протоколы различных уровней в сетях, на шлюзах и на хост-компьютерах поддерживают систему коммуникаций между процессами, которая обеспечивает двунаправленный поток данных по логическим соединениям между портами процессов.
Термин пакет используется здесь в общем случае для обозначения порции данных, участвующей в отдельном элементарном акте взаимодействия между сетью и соединенным с ней хост-компьютером. В общем случае нас не будет касаться формат блоков данных, циркулирующих в сети.
С точки зрения коммуникационных сетей, хост-компьютеры - это компьютеры, связанные с сетью и являющиеся отправителями и получателями пакетов. Процессы рассматриваются как активные элементы на хост- компьютерах (согласно наиболее общему определению процессов как исполняющихся программ). Предполагается, что даже терминалы, файлы и другие устройства ввода-вывода взаимодействуют друг с другом посредством процессов. Таким образом, любые коммуникации рассматриваются как коммуникации между процессами.
Поскольку процесс может контролировать несколько коммуникационных потоков, ведущих от него к другому процессу (или другим процессам), то мы постулируем, что каждый процесс может иметь набор портов, через которые он общается с портами других процессов.
Команда ликвидации соединения
Формат
ABORT (местное имя соединения)
Выполнение данной команды приводит к ликвидации всех незаконченных операций посылки и получения данных. Блок TCB ликвидируется, а также должно быть послано специальное сообщение RESET программе TCP на другом конце соединения. В зависимости от реализации протокола, клиенты могут получать сообщение о ликвидации в ответ на каждый оставшийся невыполненным запрос о посылке или получении данных. Или же клиенты вместо этого могут просто получить подтверждение команды ABORT.
Сообщения клиенту от программы TCP
Предполагается, что сервисные функции операционной системы предоставляют программе TCP средства для асинхронной посылки сигнала. Когда программа TCP посылает сигнал программе клиента, то определенная часть информации передается также самому клиенту. Часто это осуществляется в виде сообщений об ошибках. В других случаях наряду с этим будет предоставляться информация, связанная с завершением посылки и получения данных, а также выполнением других команд клиента.
Предоставляется следующая информация:
| местное имя соединения | всегда |
| строка отчета | всегда |
| адрес буфера | посылка и получение данных |
| количество байт (счетчик полученных байт) | получение данных |
| флаг проталкивания | получение данных |
| флаг срочности | получение данных |
Интерфейс программы TCP с протоколом более низкого уровня
Программа протокола TCP для реальной посылки информации по сети, а также для ее получения делает запросы к модулю протокола нижнего уровня. Одним из примеров такой реализации является система ARPA Internetwork, где модулем нижнего уровня является Internet протокол (IP).
Если протоколом более низкого уровня является IP, то он в качестве аргументов вызова запрашивает требуемый тип сервиса и время жизни данных в сети. Программа протокола TCP использует следующие значения для упомянутых параметров:
Тип сервиса = приоритет: обычный, задержка: нормальная,
пропускная способность: нормальная, надежность: нормальная,
т.е. 00000000
Время жизни = одна минута, или 00111100
Заметим, что принято максимальное время жизни сегмента в две минуты. Здесь мы явным образом определяем, что сегмент должен быть ликвидирован, если он в течении одной минуты не достигает адресата в системе Internet.
Если ниже расположен протокол IP (или какой-либо другой протокол с теми же функциями) и применяется процедура маршрутизации, то интерфейс должен допускать передачу информации о маршруте. Это особенно важно, поскольку адреса отправителя и получателя, учитываемые в контрольной сумме TCP протокола, будут соответствовать действительному отправителю данных и самому последнему адресату. Важно также сохранять обратный маршрут для ответов на запросы состояния.
Любой протокол нижнего уровня будет обязан предоставить адрес отправителя, адрес получателя, поля протокола, некую процедуру определения "длины TCP сообщения", необходимую как для сервисных функций протокола IP, так и для проверки контрольной суммы в самом протоколе TCP. <
Команда на посылку данных
Формат
SEND (местное название соединения, адрес буфера, количество байтов с данными, флаг проталкивания, флаг срочности [контрольное время])
Данная команда приводит к тому, что данные, содержащиеся в указанном клиентом буфере, передаются на указанное соединение. Если соединение не было к этому времени открытым, команда SEND является ошибочной. Некоторые реализации протокола TCP могут позволить клиентам начинать общение сразу с команды SEND. При этом команда OPEN должна осуществляться автоматически. Если процесс, давший команду на посылку, не уполномочен использовать данное соединение, команда возвращает клиенту ошибку.
Если установлен флаг проталкивания (PUSH), то данные должны быть переданы по назначению с соответствующим сообщением, а бит PUSH должен быть установлен на последний из созданных в буфере TCP сегментов. Если флаг PUSH не выставлен, то имеющиеся данные могут быть объединены с данными из посылаемых следом датаграмм. Кроме того, хост-компьютер, посылающий данные, может получить сообщение от шлюза об истечении контрольного времени.
Если хост-компьютер, осуществляющий сборку фрагментов дата граммы, не может в отведенное для этого время завершить свою работу из-за получения ошибочного фрагмента, то он выкидывает датаграмму и может послать сообщение об превышении контрольного времени. Этого сообщения не следует посылать вовсе, если не был получен нулевой фрагмент датаграммы.
От шлюза приходит сообщение с кодом 0 ,а от хост-компьютера - сообщение с кодом 1.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 |
| Формат сообщения об ошибках с параметрами | |||||||||||||||||||||||||||||||
| Тип | Код | Контрольная сумма | |||||||||||||||||||||||||||||
| указатель | не используется | ||||||||||||||||||||||||||||||
| Internet заголовок + 64 бита данных из исходной датаграммы |
Поля IP протокола:
Адрес получателя
Компьютерная сеть и адрес отправителя заносятся в дата грамму, возвращающую ошибку. Клиенты могут использовать команду STATUS для определения состояния соединения. В некоторых реализациях протокол TCP может оповещать клиента, когда выходит на связь не заказанный сокет.
Если было указано контрольное время, то в этом соединении его текущее значение, заданное клиентом, будет изменено.
В простейших реализациях команда SEND не предает управление обратно вызвавшей ее программе, пока не будет завершена передача или пока не будет превышено контрольное время. Однако, такой простой метод может приводить к блокировке (на пример, когда обе стороны на концах соединения пытаются сперва выполнить команду SEND, а лишь потом - RECEIVE) и плохим эксплуатационным характеристикам. Поэтому такой подход не рекомендуется использовать. В более сложной реализации возврат из функции SEND осуществляется незамедлительно, что позволяет процессу выполняться параллельно с вводом/выводом в компьютерную сеть. И даже более того - позволяет выполнять одновременно несколько команд SEND. Множественные команды SEND обрабатываются по принципу "первый пришел первый обслужен", поэтому протокол TCP будет иметь очередь, которая не может быть обслужена мгновенно.
Косвенным образом мы предположили асинхронность интерфейса с клиентом, при которой команда SEND вызывает появление особого рода сигнала или псевдо-прерывания из обслуживающей программы TCP. Альтернатива состоит в немедленном возврате из команды. Например, команды SEND могут возвращать немедленно подтверждение от местной системы, даже если посланный сегмент не получил подтверждения от чужой программы TCP. Мы оптимистически относимся к возможному успеху этой операции. Если мы ошибаемся, то соединение в любом случае будет разорвано по истечении контрольного времени. В реализациях протокола TCP такого типа (синхронных) будет все равно оставаться некоторые асинхронные сигналы, однако они будут относиться к самому соединению, а не к конкретным сегментам или буферам.
Чтобы процесс мог различать сообщения об ошибках и успешное рапорты от различных команд SEND, может оказаться удобным возвращать в ответ на запрос SEND адрес буфера наряду с кодированным ответом. Сигналы между клиентом и протоколом TCP обсуждаются ниже и определяют ту информацию, которую следует возвращать отправившему команду процессу.
Команда определения статуса соединения
Формат
STATUS (местное имя соединения) -> информация о статусе
Это команда клиента, зависящая от конкретной реализации. Она должна выполняться без опасных последствий для системы. Возвращаемая клиенту информация обычно получается из блока TCB, связанного с данным соединением, Данная команда возвращает блок данных с информацией о
| местном сокете |
| чужом сокете |
| местном имени соединения |
| окне получения |
| окне отправления |
| статусе соединения |
| количестве буферов, ждущих подтверждения |
| количестве буферов, ожидающих получения данных |
| статусе срочности |
| приоритете |
| безопасности/закрытости |
| контрольном времени пересылки |
В зависимости от состояния соединения или от особенностей реализации протокола, часть указанной информации может быть недоступна или не имеет смысла. Если процесс, осуществивший вы зов, не имеет прав на использование данного соединения, то воз вращается сообщение об ошибке. Такой подход не позволяет не имеющим полномочий процессам получать информацию о соединении.
