Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
RFC-1122 октябрь 1989 года категория: стандарт ТРЕБОВАНИЯ К СЕТЕВЫМ УСТРОЙСТВАМ, РЕАЛИЗУЮЩИМ INTERNET-АРХИТЕКТУРУ: КАНАЛЬНЫЙ, СЕТЕВОЙ И ТРАНСПОРТНЫЙ УРОВНИ I. ВВЕДЕНИЕ Этот стандарт (первый из двух, RFC-1122 и RFC-1123) определяет и обосновывает требования к создаваемым и внедряемым информационно-технологическим системам на основе Internet-архитектуры. Он непосредственно связан с протоколом RFC-1009. В данном документе рассматриваются протоколы, которые обеспечивают создание, поддержание и завершение виртуальных соединений (канальный, сетевой и транспортный уровни Internet-архитектуры). Данный стандарт является руководством для компаний/вендоров-производителей, разработчиков и пользователей программного обеспечения (ПО), обеспечивающего создание, поддержание и разъединение виртуальных Internet-соединений. Он представляет собой консенсус между результатами огромного числа НИОКР в рамках рабочих исследовательских и инженерных Internet-групп. Данный стандарт перечисляет стандартные протоколы, которые обязаны использовать сетевые устройства при установлении между собой Internet-соединений. Он также включает, путём указания RFC-стандартов, и другие документы, представляющие собой текущие спецификации протоколов. Он исправляет ошибки в некоторых существующих документах и обсуждает дополнительные дискуссионные вопросы и руководства для разработчиков систем. Для каждого протокола данный документ также содержит подробный набор требований, рекомендаций и дополнительных параметров. Читатель должен понимать, что перечень требований в этом документе не является полным сам по себе. Полные наборы требований для сетевых Internet-устройств определены главным образом в документах, описывающих стандартные протоколы, которые также содержат различные корректировки, усовершенствования и дополнения. Корректно реализованные протоколы, которые были внедрены после внимательного и точного прочтения RFC-стандартов с участием технического Internet-сообщества и в дальнейшем продемонстрировали хорошие практические результаты при функционировании программных модулей, обеспечивающих виртуальные Internet-соединения, могут отличаться от требований в данном документе лишь с самой минимальной степени. Следовательно, в большинстве случаев требования, представленные в данном стандарте, уже “устоялись” и внедрены в описания стандартных протоколов, и поэтому их появление в данном документа является, в известном смысле, излишним. Тем не менее, они были включены, так как некоторые предшествующие реализационные ошибки привели к появлению различного рода проблем, касающихся функциональной совместимости, текущей эксплуатации и/или надёжности. Этот документ включает анализ и толкование большинства требований и рекомендаций. Простое перечисление требований могло быть рискованным по следующим причинам: некоторые обязательные свойства являются более важными по сравнению с другими, а некоторые свойства являются не обязательными (дополнительными); могут появиться веские причины, почему соответствующая компания/вендор, устройства которой разработаны для ограниченного использования, может использовать различные спецификации. Тем не менее, описания в данном стандарте должны обеспечить достижение общей цели, касающейся функционального взаимодействия произвольных сетевых устройств через разнородные и сложные Internet-системы. Эти требования основаны на современном уровне развития Internet-архитектуры. Этот стандарт в дальнейшем будет дополняться и обновляться, особенно он будет полезен в тех областях, в которых будут создаваться стандарты и протоколы. §1.1. Internet-архитектура §1.1.1. главные вычислительные машины в Internet-сети (InternetHosts) Главная вычислительная машина (ГВМ) или главный компьютер (“а host computer” или просто “host”) является оконечным потребителем услуг по установлению соединений (communication services). ГВМ (или “хост”), как правило, исполняет от имени пользователя(ей) прикладные программы используемой сети и/или Internet-служб по установлению соединений, реализующих такую функцию. В глобальной Internet-сети понятие “ГВМ” (или “хост”) соответствует понятию “оконечная система” (End System, ES), принятому в ЭМВОС (ISO/OSI). глобальная Internet-сеть, как сеть передачи данных, состоит из соединённых между собой цифровых сетей с пакетной коммутацией, обеспечивающих установление и поддержание виртуальных соединений между ГВМ, использующих Internet-протоколы (Internet-архитектуру). Сети (или сетевые сегменты) взаимодействуют между собой через совокупность компьютеров, реализующих функцию коммутации пакетов и именуемых в Internet-сообществе “шлюзами” или “IP-маршрутизаторами” (RFC-1009), а в ЭМВОС — “промежуточными системами” (Intermediate Systems, IS). Данный стандарт в совокупности с RFC-1123 и RFC-1009 определяют правила текущей реализации Internet-архитектуры. В Internet-сети представлен широчайший диапазон ГВМ (по габаритам, быстродействию и функциональности). По своим габаритам компьютеры могут быть от карманных (pocket personal computer) до рабочих станций средних ЭВМ (mainframes) и суперкомпьютеров (supercomputers). По своей функциональности компьютеры могут быть от одноцелевых ГВМ (терминальные серверы, terminal servers) до полнофункциональных ГВМ, которые поддерживают совокупность сетевых интерактивных служб (как правило, удалённый доступ, доставку файлов, сообщений электронной почты и др.)  Рис.1. Архитектура и совокупность протоколов ТСР/IP узла связи сети Internet Про ГВМ говорят, что она — “многоадресная” (multihomed), если она имеет более одного физического интерфейса с одной и той же или различными сетями (или сетевыми сегментами). §1.1.2. Предположения относительно Internet-архитектуры Современная Internet-архитектура (рис.1) основывается на ряде предположений относительно систем(ы) передачи данных. Наиболее важными предположениями для ГВМ являются следующие: Internet-сеть является сетью сетей. Каждая ГВМ непосредственно соединена с некоторой(ыми) соответствующей(ими) сетью(ями). Её соединение с Internet-сетью является всего лишь концептуальным. Две ГВМ в одной и той же сети взаимодействуют друг с другом на основе применения совокупности протоколов, который они могли бы использовать для установления соединений с ГВМ, расположенными в удалённых сетях; шлюзы не сохраняют информацию о состоянии соединения. Для поддержания работоспособности систем передачи данных шлюзы разработаны как независимые устройства, которые ретранслируют IP-пакеты независимо от других IP-пакетов. И в результате этого, для обеспечения надёжности службы могут использоваться избыточные маршруты, несмотря на сбои в работе промежуточных шлюзов и сетей. Вся информация о состоянии соединения, необходимая для управления сквозным потоком и обеспечения надёжности обрабатывается в ГВМ, на транспортном уровне или прикладными программами (инициированными ими прикладными процессами). Следовательно, вся информация для управления соединением размещается в оконечных точках соединения, и очевидно, что она будет потеряна только в том случае, когда выйдет из строя оконечная точка; сложность маршрутов (задача выбора маршрута) должна определяться (решаться) шлюзами. Маршрутизация является сложной и трудной проблемой, которая должна решаться шлюзами, а не ГВМ. Важное требованием заключается в том, чтобы ПО ГВМ было защищено от какого-либо изменения, вызванного неизбежной эволюцией способов и средств маршрутизации в рамках Internet-архитектуры; система должна допускать всевозможные изменения сети. Основное требование к Internet-проекту: быть восприимчивым к широкому спектру сетевых характеристик (например, полоса пропускания, время задержки, потеря пакетов, перенаправление пакетов и максимальный размер пакета). Другое требование: надёжность в условиях возникновения нештатных ситуаций в частных сетях, шлюзах и ГВМ за счёт использования какой только возможно части от общей пропускной способности. И в заключении, конечная цель Internet-проекта полное “взаимодействие открытых систем”: ГВМ в Internet-сети должны обеспечивать функциональную совместимость надёжно и эффективно с любыми другими ГВМ в Internet-сети по различным Internet-маршрутам. Иногда разработчики ГВМ преследуют менее амбициозные цели. Например, сфера ЛВС обычно гораздо более доступна по сравнению Internet-сетью в целом. В ЛВС гораздо более низкий процент потери и очень маленькая задержка пакетов и пакеты не нужно перенаправлять. Некоторые компании/вендоры разработали и внедрили ГВМ, которые приемлемы для работы в ЛВС, но которые работают чрезвычайно плохо в условия глобальной функциональной совместимости. Компания/вендор обосновывает такой продукт как более экономичный в условиях ограниченного рынка ЛВС. Однако, изолированные ЛВС редко остаются изолированными в течении длительного периода времени. Такие ЛВС в скором времени соединяются между собой с помощью шлюзов и образуют, таким образом, большие корпоративные Internet-сети (Intranet-сети), и в конце концов образуют глобальную Internet-систему. И в заключении, ни пользователь, ни компания/вендор не используют незавершённое или частично стандартизированное ПО для ГВМ в рамках Internet-системы. Требования, перечисленные в данном стандарте, разработаны для полнофункциональной ГВМ (“Internet-хоста”), способной обеспечить полную функциональную совместимость при установлении Internet-соединения по произвольному маршруту. §1.1.3. Совокупность Internet-протоколов Для установления соединения с использованием Internet-системы, ГВМ должна включать программные модули, реализующие совокупность протоколов, распределённых по уровням Internet-архитектуры и составляющих её основу. Как правило, ГВМ должна включать, по крайней мере, по одному протоколу на одном уровне Internet-архитектуры. Internet-архитектура включает следующие протоколы (по уровням, RFC-1011): Прикладной уровень. Прикладной уровень является верхним уровнем Internet-архитектуры. Последняя не предполагает последующего деления прикладного уровня, хотя некоторые Internet-протоколы этого уровня могут содержать внутренние подуровни. По существу, прикладной уровень Internet-архитектуры объединяет функции верхних двух уровней (представления и прикладного) ЭМВОС. Прикладные протоколы Internet-архитектуры разделяются на две категории: пользовательские протоколы, которые непосредственно обслуживают пользователей, среди которых наиболее общие — Telnet (протокол удалённого доступа), FTP (протокол доставки файлов) SMTP (простой протокол доставки сообщений электронной почты). Существуют и другие стандартизированные пользовательские протоколы (RFC-1011), а также — множество частных протоколов пользователей; обеспечивающие (инфраструктурные и системообразующие) протоколы, реализующие общесистемные функции, к которым относятся отображение имён, первоначальной загрузки (перезагрузки) и управления (BOOTP, RARP, DNS). Требования к пользовательским и обеспечивающим протоколам представлены в стандарте RFC-1123; Транспортный уровень. Транспортный уровень организует в интересах взаимодействующих прикладных и общесистемных процессов полноценную транспортную службу. К протоколам этого уровня относятся следующие два протокола: Протокол управления передачей (TransmissionControlProtocol — TCP). Этот протокол организует транспортную службу, в основе которой лежит установление сквозных виртуальных соединений, обеспечивающих естественный порядок следования сообщений, надежность информационного обмена и управление потоком; Протокол доставки дейтаграммы пользователя (UserDatagramProtocol — UDP). Этот протокол организует дейтаграммную (“datagram”) транспортную службу без установления соединений (connectionless). В дальнейшем рабочие исследовательские группы могут разработать новые протоколы транспортного уровня, которые затем будут стандартизованы и войдут в перечень официальных Internet-протоколов (RFC-1011); Сетевой (Internet, IP) уровень. Все транспортные протоколы Internet-архитектуры используют Internet-протокол (Internetworking protocol, IP-протокол) для доставки данных от одной ГВМ (источник) к другой ГВМ (получатель). IP-протокол является протоколом без установления соединения, и таким образом организует службу межсетевого взаимодействия с целью доставки дейтаграмм, который не предоставляет никаких гарантий по сквозной доставке дейтаграмм. Следовательно, дейтаграммы (IP-пакеты) могут прибывать на ГВМ (получатель) искажёнными, продублированными, в произвольном порядке или вообще быть потерянными. Все уровни, расположенные выше IP-уровня, ответственны за поддержание надёжной службы доставки, если таковая будет востребована. На IP-протокол возложено решение следующих задач: адресация, определение типа обслуживания, обеспечение фрагментации, повторной сборки и данных о защищённости. “Дейтаграммная природа” (обеспечение информационного обмена без установления соединения) IP-протокола является фундаментальным и важнейшим характеристическим свойством Internet-архитектуры. IP-протокол Internet-архитектуры являлся моделью протокола сетевого уровня без установления соединения для ЭМВОС (RFC-994). Internet-протокол доставки управляющих сообщений (ICMP-протокол) является всего лишь транспортным протоколом, как и TCP- и UDP-протоколы, хотя и рассматривается как составная часть IP-протокола и с точки зрения Internet-архитектуры располагается над ним (то есть ICMP-протокол использует IP-протокол для сквозной доставки своих данных). ICMP-протокол реализует функции оповещения об ошибках, перегрузках и перенаправлении трафика на первом ретрансляционном участке маршрута. Internet-протокол управления группами ГВМ (IGMP-протокол) является протоколом IP-уровня и применяется для формирования и определения групп ГВМ, использующих групповую IP-адресацию; Канальный уровень. Для обеспечения соединения, связанного с непосредственным подключением к своей сети, ГВМ должна включать протокол связи через интерфейс этой сети. Такой протокол именуется протоколом канального уровня или протоколом уровня доступа к среде. Существует широкий спектр протоколов канального уровня, соответствующих различным типа сетей. §1.1.4. Код встраиваемого программного модуля, реализующего функции шлюза В Internet-сети некоторые ГВМ реализуют функции шлюза за счёт встраивания соответствующего программного модуля, так что такие ГВМ могут ретранслировать IP-пакеты, как это мог бы делать шлюз, несмотря на то, что в ГВМ реализуются функции прикладного уровня. Такие двойственные системы должны удовлетворять требованиям, представленным в стандарте RFC-1009, что касается их функций как шлюзов, а также должны удовлетворять требованиям, представленным в данном стандарте, что касается их функций как ГВМ. Во всех указанных случаях должны быть реализованы спецификации обоих стандартов. В Internet-сообществе существуют различные мнения относительно функциональности встраиваемых шлюзов. Вот основные из них: “за”. В сфере ЛВС, где создание сетей происходит произвольным образом, или в изолированных Intranet-сетях (корпоративные сети на основе Internet-архитектуры) использование существующих ГВМ в качестве шлюзов может быть вполне приемлемым и экономичным. Также имеет место и архитектурный аргумент в пользу встраивания функций шлюза: многоадресная система является гораздо более простой, чем предполагалось изначально, и поэтому многоадресная система заставляет ГВМ принимать решения относительно выбора маршрута, как если бы это был шлюз. Если многоадресная ГВМ содержит встроенный программный шлюз, то он будет знать всю информацию о маршрутизации и в результате будет способен принимать более оптимальные маршрутные решения; “против”. Протоколы и алгоритмы функционирования шлюзов по прежнему усовершенствуются, и в дальнейшем такое совершенствование будет продолжаться, так как Internet-система укрупняется. Пытаясь включить единую функцию шлюза в состав ГВМ, IP-уровень будет вынуждать систему обслуживания ГВМ отслеживать такие изменения (более часто). Кроме того, для большой группы разработчиков шлюзов будет ещё более проблематично координировать (согласовывать) изменения. И в заключении, сложность шлюза на IP-уровне зачастую на много больше, чем самой ГВМ, и поэтому задачи внедрения и функционирования шлюзов становятся более сложными. Необходимо заметить, режим функционирования некоторых ГВМ не приемлем для обеспечения стабильности и надёжности системы шлюзов. В обеих точках зрения присутствует много вполне приемлемых причин. Можно сделать один определённый вывод: администратор ГВМ должен осуществлять “здравомыслящий” контроль за всеми действиями и “бездействиями” ГВМ как шлюза. §1.2. Общие вопросы Существуют два важных предостережения, которые усвоили разработчики ПО для Internet-системы, и к которым должны относиться весьма серьёзно новые компании/вендоры. |