The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Cisco маршрутизаторы и коммутаторы" / Оглавление документа
*

Internetworking Technology Overview.

ГЛАВА 22. Xerox Network Systems (XNS).



Библиографическая справка


Протоколы Xerox Network Systems (XNS) разработаны корпорацией Xerox в конце 1970-начале 1980 гг. Они предназначены для использования в разнообразных средах передачи, процессорах и прикладных задачах офиса. Несколько протоколов XNS похожи на Протокол Internet (IP) и Протокол управления передачей (TCP), разработанных агентством DARPA для Министерства обороны США (DoD). Информация по этим и связанным с ними протоколам дается в Главе 18 "Протоколы Internet". Все протоколы XNS соответствуют основным целям проектирования эталонной модели OSI.

Благодаря своей доступности и раннему появлению на рынке, XNS был принят большинством компаний, использовавших локальные сети с момента их появления, в том числе компаниями Novell, Inc., Ungermann-Bass, Inc. (которая теперь является частью Tandem Computers) и 3Com Corporation. За время,прошедшее с тех пор, каждая из этих компаний внесла различные изменения в протоколы XNS. Novell дополнила их Протоколом доступа к услугам (Service access protocol - SAP), чтобы обеспечить об'явление о ресурсах, и модифицировала протоколы Уровня 3 OSI (которые Novell переименовала в Internetwork Packet Exchange - IPX - Oбмен межсетевыми пакетами) для работы в сетях IEEE 802.3, а не в сетях Ethernet. Ungermann-Bass модифицировала RIP для поддержания задержки, а также числа пересылок. Были также внесены другие незначительные изменения. С течением времени реализации XNS для об'единенных в сети РС стали более популярными, чем XNS в том виде, в котором они были первоначально разработаны компанией Xerox.


Основы технологии


Несмотря на то, что они имеют общие цели проектирования, концепция XNS о иерархии протоколов несколько отличается от той концепции, которую предлагает эталонная модель OSI. На Рис. 22-1 показано приблизительное сравнение XNS и эталонной модели OSI.



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


Доступ к среде


Несмотря на то, что в документации XNS упоминаются X.25, Ethernet и HDLC, XNS не дает четкого определения того, что она называет протоколом уровня 0. Также, как и многие другие комплекты протоколов, XNS оставляет вопрос о протоколе доступа к носителю открытым, косвенным образом позволяя любому такому протоколу выполнять главную роль в транспортировке пакетов XNS через физический носитель.


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


Протокол сетевого уровня XNS называется Протоколом дейтаграмм Internet (Internet Datagram Protocol - IDP). IDP выполняет стандартные функции Уровня 3, в число которых входят логическая адресация и сквозная доставка дейтаграмм через об'единенную сеть. Формат пакета IDP представлен на Рис. 22-2.



Первым полем в пакете IDP является 16-битовое поле контрольной суммы (checksum), которое помогает проверить целостность пакета после его прохождения через об'единенную сеть.

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

За полем длины идет 8-битовое поле управления транспортировкой (transport control) и 8-битовое поле типа пакета (packet type). Поле управления транспортировкой состоит из подполей числа пересылок (hop count) и максимального времени существования пакета (maximum packet lifetime - MPL). Значение подполя числа пересылок устанавливается источником в исходное состояние 0 и инкрементируется на 1 при прохождении данной дейтаграммы через один роутер. Когда значение поля числа пересылок доходит до 16, дейтаграмма отвергается на основании допущения, что имеет место петля маршрутизации. Подполе MPL содержит максимальное время (в секундах), в течение которого пакет может оставаться в об'единенной сети.

За полем управления транспортировкой следует 8-битовое поле типа пакета (packet type). Это поле определяет формат поля данных.

Каждый из адресов сети источника и назначения имеют три поля: 32- битовый номер сети (network number), который уникальным образом обозначает сеть в об'единенной сети, 48-битовый номер хоста (host number), который является уникальным для всех когда-либо выпущенных хостов, и 16-битовый номер гнезда (socket number), который уникальным образом идентифицирует гнездо (процесс) в пределах конкретнго хоста. Адреса IEEE 802 эквивалентны номерам хостов, поэтому хосты, подключенные более чем к одной сети IEEE 802, имеют тот же самый адрес в каждом сегменте. Это делает сетевые номера избыточными, но тем не менее полезными для маршрутизации. Некоторые номера гнезд являются хорошо известными (well-known); это означает, что услуга, выполняемая программным обеспечением с использованием этих номеров гнезд, является статически определенной. Все другие номера гнезд допускают многократное использование.

XNS поддерживает пакеты с однопунктовой (из одного пункта в другой пункт), многопунктовой и широковещательной адресацией. Многопунктовые и широковещательные адреса далее делятся на 2 типа: прямые (directed) и глобальные (global). Прямые многопунктовые адреса доставляют пакеты членам группы многопунктовой адресации данной сети, заданной в адресе сети назначения с многопунктовой адресацией. Прямые широковещательные адреса доставляют пакеты всем членам заданной сети. Глобальные многопунктовые адреса доставляют пакеты всем членам данной группы в пределах всей об'единенной сети, в то время как глобальные широковещательные адреса доставляют пакеты во все адреса об'единенной сети. Один бит в номере хоста обозначает отдельный адрес в противовес многопунктовому адресу. Все единицы в поле хоста обозначают широковещательный адрес.

Для маршрутизации пакетов в об'единенной сети XNS использует схему динамической маршрутизации, называемую Протоколом информации маршрутизации (RIP). В настоящее время RIP является наиболее широко используемым Протоколом внутренних роутеров (interior gateway protocol - IGP) в сообществе Internet-среде международной сети, обеспечивющей связность практически со всеми университетами и научно- исследовательскими институтами, а также многими коммерческими организациями в США. Подробная информация о RIP дается в Главе 23 "RIP".


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


Функции транспортного уровня OSI реализуются несколькими протоколами. Каждый из перечисленных ниже протоколов описан в спецификации ХNS как протокол уровня два.

Протокол упорядоченной передачи пакетов (Sequenced Packet Protocol - SPP) обеспечивает надежную, с установлением соединения и управлением потока, передачу пакетов от лица процессов клиента. По выполняемым функциям он похож на протокол TСР из комплекта протоколов Internet и на протокол ТР4 из комплекта протоколов OSI (смотри соответственно Главу 18 "Протоколы Internet" и Главу "Протоколы OSI" 20).

Каждый пакет SPP включает в себя номер последовательности (sequence number), который используется для упорядочивания пакетов и определения тех из них, которые были скопированы или потеряны. Пакеты SPP также содержат два 16-битовых идентификатора соединения (connection identifier). Каждый конец соединения определяет один идентификатор соединения. Оба идентификатора соединения вместе уникальным образом идентифицируют логическое соединение между процессами клиента.

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

Протокол обмена пакетами (Packet Exchange Protocol - PEP) является протоколом типа запрос-ответ, предназначенным обеспечивать надежность, которая больше надежности простых услуг дейтаграмм (например, таких, которые обеспечивает IDP), но меньше надежности SPP. По своим функциональным возможностям РЕР аналогичен Протоколу дейтаграмм пользователя (UDP) из комплекта протоколов Internet (смотри Главу 18 "Протоколы Internet"). PEP базируется на принципе одного пакета, обеспечивая повторные передачи, но не обеспечивая выявление дублированных пакетов. Он полезен для прикладных задач, в которых транзакции запрос-ответ являются идемпотентными (повторяемыми без повреждения контекста), или в которых надежная передача выполняется на другом уровне.

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


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


XNS предлагает несколько протоколов высших уровней. Протокол "Печатание" (Printing) обеспечивает услуги принтера. Протокол "Ведение картотеки" (Filing) обеспечивает услуги доступа к файлам. Протокол "Очистка9 (Сlearinghouse) обеспечивает услуги, связанные с присвоением имени. Каждый из этих протоколов работает в дополнение к протоколу "Курьер" (Сourier), который обеспечивает соглашения для структурирования данных и взаимодействия процессов.

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

И наконец, протокол "Эхо" (Echo Protocol) используется для тестирования надежности узлов сети XNS. Он используется для поддержки таких функций, как функции, обеспечиваемые командой ping, которую можно встретить в Unix и других средах. Спецификация XNS описывает протокол "Эхо" как протокол уровня два.


Данный документ подготовлен для HTML версии Владимиром Плешаковым.
Версия: 0.1

Vladimir V. Pleshakov , pvv@quorus.ru.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру