Сетевые системы Xerox Введение

Протоколы сетевых систем Xerox (Xerox Network Systems — XNS) были разработаны корпорацией Xerox в конце 70-х-начале 80-х годов XX века. Предполагалось их использование с разнообразными средами коммуникации, с различными процессорами и офисными приложениями. Некоторые протоколы XNS аналогичны Internet- протоколу (Internet Protocol — IP) и протоколу управления передачей (Transport Control Protocol — TCP). Последние были разработаны управлением перспективных исследовательских программ (Defence Advanced Research Project Agency — DARPA) для министерства обороны США (Department of Defence — DoD).

Благодаря своей доступности и раннему появлению на рынке протокол XNS был принят в качестве рабочего протокола локальных сетей LAN во многих компаниях, включая Novell Inc., Ungermann-Bass Inc. (в настоящее время подразделение корпорации Tandem Computers) и корпорацию 3Com Corporation. С тех пор каждая из этих компаний вносила в протоколы XNS различные изменения. Корпорация Novell добавила к нему протокол анонсирования службы (Service Advertisement Protocol — SAP), позволяющий анонсировать ресурсы, и модифицированные протоколы OSI 3-го уровня, (которые Novell переименовала в IPX — Internetwork Packet Exchange) для работы преимущественно в сетях IEEE 802.3, а не в сетях Ethernet. Корпорация Ungermann- Bass модифицировала протокол RIP для учета задержки и подсчета количества переходов, а также внесла другие небольшие изменения. С течением времени XNS- реализации для сетей персональных компьютеров PC стали более популярными, чем первоначально разработанные корпорацией Xerox протоколы XNS. В настоящей главе приведен обзор стека протоколов XNS в контексте эталонной модели OSI.

Иерархия стека протоколов XNS

Хотя цели разработки протокола XNS были теми же, что и цели эталонной модели OSI, концепция иерархии протоколов XNS несколько отличается от используемой в модели OSI, как показано на рис. Б.4.

Рис. Б.4. Корпорация Xerox приняла 5-уровневую модель передачи пакетов

Как показано на рис. Б.4, корпорация Xerox приняла 5-уровневую модель передачи пакетов. Уровень 0 (нулевой уровень) приближенно соответствует 1-му и 2-му уровням эталонной модели OSI, управляя доступом к каналу и потоками битов. 1-й уровень примерно соответствует 3-му уровню модели OSI в части, касающейся сетевых потоков данных. 2-й уровень соответствует части 3-го уровня модели OSI, относящейся к межсетевой маршрутизации и 4-му уровню модели OSI, относящейся к передаче данных между процессами. 3-й и 4-й уровни примерно соответствуют двум верхним уровням модели OSI, обеспечивая структурирование данных, взаимодействие процессов и приложений. В стеке протоколов XNS отсутствует протокол, соответствующий 5-му уровню эталонной модели OSI (сеансовому уровню).

Доступ к среде передачи

Хотя в документации XNS упоминаются протоколы Х.25, Ethernet и высокоуровневый протокол управления каналом (High-Level Data Link Control — HDLC), стек протоколов XNS не определяет явным образом, что подразумевается под протоколом нулевого уровня. Как и многие другие стеки протоколов, XNS оставляет вопрос о доступе к среде открытым, неявно позволяя использовать любой такой протокол для передачу пакетов XNS в физической среде.

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

Протокол сетевого уровня стека XNS называется протоколом межсетевых дейтаграмм (Internet Datagram Protocol — IDP). Протокол IDP выполняет стандартные функции 3-го уровня, включая логическую адресацию и сквозную доставку дейтаграмм в объединенной сети. На рис. Б.5 показан формат пакета в протоколе IDP.

Ниже описываются поля IDP-пакета, показанные на рис. Б.5.

•          Контрольная сумма (Checksum). 16-битовое поле, которое позволяет проверить целостность пакета после его прохождения по сети.

•          Длина пакета (Lenght). 16-битовое поле, в котором содержится общая длина текущей дейтаграммы (включая поле контрольной суммы).

•          Управление передачей (Transport control). 8-битовое поле, содержащее подполя количества переходов и максимального времени существования (Maximum Packet Lifetime — MPL) пакетов. Значение подполя количества переходов (Hop Count) устанавливается равным нулю самим источником, и увеличивается на единицу при каждом прохождении пакета через маршрутизатор. Когда значение поля Hop Count достигает 16, дейтаграмма отбрасывается в предположении, что возникла петля маршрутизации. Подполе MPL устанавливает максимальное время (в секундах), в течение которого пакет может оставаться в объединенной сети.

•          Тип пакета (Packet type). 8-битовое поле, задающее формат поля данных.

•          Номер сети пункта назначения (Destination Network Number). 32-битовое поле, уникальным образом идентифицирующее сеть-получатель в объединенной сети.

•          Номер узла-получателя (Destination Host Number). 48-битовое поле, уникальным образом идентифицирующее узел-получатель.

Рис. Б. 5. 1 DP-пакет содержит 11 полей

•          Номер сонета (процесса) пункта назначения (Destination socket number). 16-битовое поле, уникальным образом идентифицирующее сокет (процесс) в узле-получателе.

•          Номер сети-источника (Source Network Number). 32-битовое поле, уникальным образом идентифицирующее сеть-источник в распределенной сети.

•          Номер узла-источника (Source Host Number). 48-битовое поле, уникальным образом идентифицирующее узел-источник.

•          Номер сокета (процесса) источника (Source Socket Number). 16-битовое поле, уникальным образом идентифицирующее сокет (процесс) в узле-источнике.

Адреса IEEE 802 эквивалентны номерам узлов, поэтому узлы, которые подсоединены более чем к одной сети IEEE 802.5, имеют во всех сегментах один и тот же адрес. Это делает сетевые номера избыточными, но тем не менее полезными для процесса маршрутизации. Некоторые номера сокетов являются общеизвестными; это означает, что выполняемые ими функции задаются статически использующим их программным обеспечением. Все остальные номера сокетов могут использоваться для выполнения различных функций.

Протокол XNS поддерживает Ethernet-инкапсуляцию версии 2.0 для сетей Ethernet и три типа инкапсуляции для сетей Token Ring: 3Com, протокол доступа SubNet (SubNet Access Protocol — SNAP) и Ungermann-Bass.

XNS поддерживает одноадресатную рассылку пакетов (соединения типа "точка-точка"), многоадресатную и широковещательную рассылки. Адреса многоадресатной и широковещательной рассылки далее подразделяются на направленные (directed) и глобальные. При направленной многоадресатной рассылке пакеты доставляются членам группы многоадресатной рассылки, указанной адресом многоадресатной рассылки указанной сети. При широковещательной направленной рассылке пакеты направляются всем членам указанной сети. При глобальной многоадресатной рассылке пакеты направляются всем членам группы во всей сети, в то время как глобальная широковещательная рассылка отправляет пакеты по всем адресам объединенной сети. Установка одного из битов в номере узла указывает на одноадресатную рассылку, в отличие от многоадресатной. Если все биты в поле узла равны единице, то адрес является широковещательным.

Для маршрутизации пакетов в объединенной сети протокол XNS использует схему динамической маршрутизации протокола RIP. В настоящее время протокол RIP является наиболее часто используемым в Internet-сообществе протоколом внутреннего шлюза (Interior Gateway Protocol — IGP). Более подробная информация о протоколе RIP приведена в главе 47, "Протокол OSPF".

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

Функции транспортного уровня эталонной модели OSI в стеке протоколов XNS выполняются несколькими протоколами. Все приведенные ниже протоколы описаны в спецификации XNS как протоколы 2-го уровня.

Протокол последовательных пакетов (Sequenced Packet Protocol — SPP) обеспечивает надежную, ориентированную на соединение передачу пакетов, при которой управление потоком осуществляется клиентом процесса. По выполняемым функциям он аналогичен протоколу управления передачей (Transmission Control Protocol — TCP), входящему в стек протоколов IP (Internet Protocol) и транспортному протоколу 4 (Transport Protocol 4 — ТР4), входящему в стек протоколов OSI. Более подробная информация о протоколе TCP приведена в главе 35 "Протоколы Internet", а протокол ТР4 описан в главе 34 "Протоколы взаимодействия открытых систем".

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

Протокол обмена пакетами (Packet Exchange Protocol — PEP) представляет собой протокол типа "запрос-ответ", предназначенный для обеспечения большей надежности, чем обычная дейтаграммная служба (например, служба, предоставляемая протоколом IDP), однако меньшей, чем у протокола SPP. Протокол PEP по выполняемым функциям аналогичен протоколу пользовательских дейтаграмм (User Datagram Protocol — UDP), входящему в стек протоколов IP (Internet Protocol). (Более подробная информация о протоколе UDP приведена в главе 35 "Протоколы Internet". Протокол PEP основан на передаче отдельных пакетов и обеспечивает повторную передачу (ретрансмиссию), однако не обнаруживает удвоения (дублирования) пакетов. В этом качестве он полезен в приложениях, где транзакции "запрос-ответ" могут быть повторены без повреждения данных или в тех случаях, когда надежность передачи обеспечивается на другом уровне.

Протокол обнаружения ошибок (Error Protocol — ЕР) может быть использован любым клиентским процессом для уведомления другого процесса о том, что в сети произошел сбой. Этот протокол используется, например, в ситуациях, когда реализация SPP обнаружила дублирование пакета.

Протоколы верхних уровней

Стек протоколов XNS предлагает несколько протоколов верхних уровней. Протокол печати (Printing Protocol) предоставляет службы печати, протокол работы с файлами (Filing Protocol) обеспечивает службы доступа к файлам, а протокол Clearinghouse обеспечивает службу назначения имен. Каждый из этих трех протоколов работает над протоколом

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

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

Протокол 2-го уровня Echo Protocol используется для проверки достижимости узлов XNS-сети и для поддержки функций, предоставляемых командой ping в UNIX и других операционных средах.

Резюме

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

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100