Современные системы передачи данных характеризуются

Современные системы передачи данных характеризуются огромным разнообразием информации. Если лет 7 назад это был в основном текстовые сообщения, то сейчас – мультимедиа, видео, обмен баз данных. Разнообразие и сложность пользовательских данных, а также отсутствие гибкой системы их представления вызвали необходимость появления нотации высокого уровня для их описания. Данная нотация должна была удовлетворить ряд требований:

способность описать все существующие типов данных;

обеспечить описание сложных многоуровневых структур данных;

определять алгоритмы представления значений (правила кодирования);

обеспечить открытость для дальнейшего развития.

В качестве такой нотации Международный Консультативный Комитет по Телефонии и Телеграфии (МККТТ) предложил использовать абстрактно-синтаксическую нотацию версии 1(АСН.1). Данная нотация описана в рекомендации Х.208.

АСН.1 позволяет определять передаваемое значение, не задавая конкретный способ представления этого значения. Способ представления определяется заданием одного или нескольких алгоритмов, называемых правилами кодирования. Правила кодирования определяют конкретный вид байтов на сеансовом уровне, с помощью которых передаются значения прикладного уровня (синтаксис передачи), и позволяют получателю распознать переданную информацию как конкретное значение конкретного типа.

Основой АСН.1 является теговая структура. Под тегом понимается структура данных определенного типа, поименованная совокупность значений. Имя тега однозначно идентифицирует тип содержащихся в нем данных, т.к. для правильной интерпретации конкретного представления значения необходимо знать тип передаваемых данных. Тег может быть определен в АСН.1, либо определяется пользователем. Часто один и тот же имя тега назначается нескольким разным типам, при этом конкретный тип идентифицируется контекстом, в котором используется тег. Пользователь может присвоить разные имена тегов двум “копиям” какого-либо существующего типа, создавая тем самым два новых типа, отличных от первоначального.



АСН. 1 является как средством определения сложных типов данных, так и средством задания конкретных значений этих типов без указания конкретного способа представления (в виде последовательности октетов) значений данного типа при их передаче;

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

В настоящее время АСН.1 нотация используется в следующих приложениях:

	является основой для кодирования записей баз данных RMON.1 и RMON.2, используемых в системах дистанционного управления сетевых устройств;
	в записях службы справочника сетевых адресов Х.500;
	для кодирования протоколов Х.400 и SNMP.

 

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

Рассмотрим применение АСН. 1 на примере некоторой записи учета кадров. Ниже приведена структура записи учета кадров и ее значение для конкретного служащего.

Имя:	Петр Борисович Иванов
Должность:	Директор
Учетный номер:	23
Дата приема на работу:	14 июня 1997 г.
Имя жены:	Ольга Олеговна Иванова
Число детей:	2
Информация о ребенке:
Имя:	Олег Петрович Иванов
Дата рождения:	16 марта 1990 г.
Информация о ребенке:
Имя:	Анна Петровна Иванова
Дата рождения:	5 декабря 1993 г.

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

PersonnelRecord::= [APPLCATION 0] IMPLICIT SET

{	Name,
title	[0] VisibleString ,
number	EmployeeNumber,
dateOfHire	[1] Date,
NameOfWife	[2] Name,
children	[3] IMPLICIT SEQUENCE OF ChildInformationDEFAULT {} }
ChildInformation::=SET
{	Name,
dateOfBirth	[0] Date}

Name::= [APPLICATION 1] IMPLICIT SEQUENCE

{givenName	VisibleString
inital	VisibleString
familyName	VisibleString}

EmployeeNumber::= [APPLICATION 2] IMPLICIT integer

Date::= [APPLICATION 3] IMPLICIT VisibleString –YYYYMMDD

Далее приводится значение записи учета кадров для Иванова Петра Борисовича, определенное с помощью нотации АСН.1.

{	{givenName “Peter“, initial “Borisovich“, familyName “Ivanov“},
title	“Director“,
number	23,
dateOfHire	19970614
NameOfWife	{givenName “Olga“, initial “Olegovna“, familyName “Ivanova“},
children

{{{ givenName “Oleg“, initial “ Petrovich“, familyName “Ivanov“},

dateOfBirth “19900316“},

{{ givenName “Anna“, initial “ Petrovna “, familyName “Ivanova“},

dateOfBirth “19931205“}}}

Ниже приводится представление в октетах приведенного выше значения записи. Значения идентификаторов, длин и целочисленные величины приведены в шестнадцатеричной записи, по две шестнадцатеричные цифры на октет. Значения содержимого знаковых строк показаны в виде текста, по одному знаку на октет.

Personnel Record	Длина	Содержимое
60	83
		Name	Длина	Содержимое
		61	1B
				VisibleString	Длина	Содержимое
				1A	05	“Peter“
				VisibleString	Длина	Содержимое
				1A	0A	“Borisovich“
				VisibleString	Длина	Содержимое
				1A	06	“Ivanov“
		title	Длина	Содержимое
		A0	0A
				VisibleString	Длина	Содержимое
				1A	08	“Director“
		number	Длина	Содержимое
		42	01	17
		dateOfHire	Длина	Содержимое
		A1	0A
				Date	Длина	Содержимое
				43	08	“19970614“
		NameOfWife	Длина	Содержимое
		A2	13
				VisibleString	Длина	Содержимое
				1A	04	“Olga“
				VisibleString	Длина	Содержимое
				1A	08	“Olegovna“
				VisibleString	Длина	Содержимое
				1A	07	“Ivanova“
		[3]	Длина	Содержимое
		A3	52
				Set	Длина	Содержимое
				31	27
						Name	Длина	Содержимое
						61	19
								VisibleString	Длина		Содержимое
								1A	04		“Oleg “
								VisibleString	Длина		Содержимое
								1A	09		“Petrovich“
								VisibleString	Длина		Содержимое
								1A	06		“Ivanov“
						DateOfBirth	Длина	Содержимое
						A0	0A
								Date	Длина		Содержимое
								43	08		“19900316“
				Set	Длина	Содержимое
				31	27
						Name	Длина	Содержимое
						61	19
								VisibleString	Длина		Содержимое
								1A	04		“Anna “
								VisibleString	Длина		Содержимое
								1A	08		“Petrovna“
								VisibleString	Длина		Содержимое
								1A	07		“Ivanova“
						DateOfBirth	Длина	Содержимое
						A0	0A
								Date	Длина		Содержимое
								43	08		“19931205“

Иерархия тегов для данной записи приведена на рис.5 .
Пример применения АСН.1
Рассмотрим применение АСН.1 на примере некоторой записи учета кадров.


Ниже приведена структура записи учета кадров и ее значение для конкретного служащего.

Имя:	Петр Борисович Иванов
Должность:	Директор
Учетный номер:	23
Дата приема на работу:	14 июня 1997 г.
Имя жены:	Ольга Олеговна Иванова
Число детей:	2
Информация о ребенке:
Имя:	Олег Петрович Иванов
Дата рождения:	16 марта 1990 г.
Информация о ребенке:
Имя:	Анна Петровна Иванова
Дата рождения:	5 декабря 1993 г.

Структура каждой записи учета кадров формально описана ниже с помощью стандартных обозначений для типов данных.
PersonnelRecord::= [APPLCATION 0] IMPLICIT SET

{	Name,
title	[0] VisibleString ,
number	EmployeeNumber,
dateOfHire	[1] Date,
NameOfWife	[2] Name,
children	[3] IMPLICIT SEQUENCE OF ChildInformationDEFAULT {} }
ChildInformation::=SET
{	Name,
dateOfBirth	[0] Date}

Name::= [APPLICATION 1] IMPLICIT SEQUENCE

{givenName	VisibleString
inital	VisibleString
familyName	VisibleString}

EmployeeNumber::= [APPLICATION 2] IMPLICIT integer
Date::= [APPLICATION 3] IMPLICIT VisibleString –YYYYMMDD
Далее приводится значение записи учета кадров для Иванова Петра Борисовича, определенное с помощью нотации АСН.1.

{	{givenName “Peter“, initial “Borisovich“, familyName “Ivanov“},
title	“Director“,
number	23,
dateOfHire	19970614
NameOfWife	{givenName “Olga“, initial “Olegovna“, familyName “Ivanova“},
children

{{{ givenName “Oleg“, initial “ Petrovich“, familyName “Ivanov“},
dateOfBirth “19900316“},
{{ givenName “Anna“, initial “ Petrovna “, familyName “Ivanova“},
dateOfBirth “19931205“}}}
Ниже приводится представление в октетах приведенного выше значения записи. Значения идентификаторов, длин и целочисленные величины приведены в шестнадцатеричной записи, по две шестнадцатеричные цифры на октет. Значения содержимого знаковых строк показаны в виде текста, по одному знаку на октет.

Personnel Record	Длина	Содержимое
60	83
		Name	Длина	Содержимое
		61	1B
				VisibleString	Длина	Содержимое
				1A	05	“Peter“
				VisibleString	Длина	Содержимое
				1A	0A	“Borisovich“
				VisibleString	Длина	Содержимое
				1A	06	“Ivanov“
		title	Длина	Содержимое
		A0	0A
				VisibleString	Длина	Содержимое
				1A	08	“Director“
		number	Длина	Содержимое
		42	01	17
		dateOfHire	Длина	Содержимое
		A1	0A
				Date	Длина	Содержимое
				43	08	“19970614“
		NameOfWife	Длина	Содержимое
		A2	13
				VisibleString	Длина	Содержимое
				1A	04	“Olga“
				VisibleString	Длина	Содержимое
				1A	08	“Olegovna“
				VisibleString	Длина	Содержимое
				1A	07	“Ivanova“
		[3]	Длина	Содержимое
		A3	52
				Set	Длина	Содержимое
				31	27
						Name	Длина	Содержимое
						61	19
								VisibleString	Длина	Содержимое
								1A	04	“Oleg “
								VisibleString	Длина	Содержимое
								1A	09	“Petrovich“
								VisibleString	Длина	Содержимое
								1A	06	“Ivanov“
						DateOfBirth	Длина	Содержимое
						A0	0A
								Date	Длина	Содержимое
								43	08	“19900316“
				Set	Длина	Содержимое
				31	27
						Name	Длина	Содержимое
						61	19
								VisibleString	Длина	Содержимое
								1A	04	“Anna “
								VisibleString	Длина	Содержимое
								1A	08	“Petrovna“
								VisibleString	Длина	Содержимое
								1A	07	“Ivanova“
						DateOfBirth	Длина	Содержимое
						A0	0A
								Date	Длина	Содержимое
								43	08	“19931205“

<


/p>
Иерархия тегов для данной записи приведена на рис.5 .

  <


table border="0" cellpadding="0" cellspacing="0" width="100%">

состоит из последовательности знаков

Каждый элемент АСН. 1 состоит из последовательности знаков :

	от A до Z
	от a до z
	от 0 до 9
	: = , { } < . ( ) [ ] - ‘ “

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

Описание элементов АСН.1 представлено ниже:

Наименование элемента	Описание элемента
СсылкаНаТип	Имя, однозначно идентифицирующее тип в рамках некоторого контекста. Должно состоять из произвольного количества букв, цифр и дефисов. Начальный знак должен быть прописной буквой. Последний знак не должен быть дефисом. Два дефиса не должны следовать друг за другом. Не должен совпадать ни с одним из элементов- ключевых слов (см. ниже).
Идентификатор	Значение (отличающееся от других подобных значений), которое связывается с информационным объектом. Должен состоять из произвольного количества букв, цифр и дефисов. Начальный знак должен быть строчной буквой. Последний знак не должен быть дефисом. Два дефиса не должны следовать друг за другом.
СсылкаНаЗначение	Должен состоять из произвольного количества букв, цифр и дефисов. Начальный знак должен быть строчной буквой. Последний знак не должен быть дефисом. Два дефиса не должны следовать друг за другом. Отличие элемента “СсылкаНаЗначение” от элемента “Идентификатор” достигается различием контекстов, в которых появляются эти элементы.
СсылкаНаМодуль	Должно состоять из произвольного количества букв, цифр и дефисов. Начальный знак должен быть прописной буквой. Последний знак не должен быть дефисом. Два дефиса не должны следовать друг за другом. Не должен совпадать с одной из зарезервированных знаковых последовательностей, перечисленных в табл. . Отличие элемента “СсылкаНаМодуль” от элемента “СсылкаНаТип” достигается различием контекстов, в которых появляются эти элементы.
Комментарий	Начинается с пары следующих друг за другом дефисов и заканчивается другой парой дефисов или концом текущей строки.
Число	Состоит из одной или более цифр. Первая цифра может быть нулем лишь в том случае, если элемент “число” состоит из одной цифры.
Двоичная строка (b- строка )	Состоит из произвольного количества нулей и единиц, перед которыми следует знак ‘ и за которыми следует пара знаков ‘B , например, ‘01110010’B .
Шестнадцатеричная строка (h- строка )	Состоит из произвольного количества знаков ABCDEF0123456789 (каждый знак - четыре бита в шестнадцатеричном представлении), перед которыми следует знак ‘ и за которыми следует пара знаков ‘Н , например, ‘10AF36’H .
Строка знаков (с- строка )	Состоит из произвольного количества знаков из набора знаков, который определяется типом рассматриваемой строки знаков, перед которыми и вслед за которыми следует знак “.Если набор знаков содержит знак “, то он представляется в элементе “с- строка” парой знаков “.
Присвоение	Состоит из последовательности знаков ::= .
Элементы, состоящие из одного знака	Элементы состоят из одного символа, образующего их имена: { } < , . ( ) [ ] - ;
Элементы – ключевые слова	Элементы состоят из последовательностей знаков, образующих их имена:
	BOOLEAN INTEGER BIT STRING OCTET NULL SEQUENCE OF SET IMPLICIT CHOICE ANY EXTERNAL OBJECT IDENTIFIER	OPTIONAL DEFAULT COMPONENTS UNIVERSAL APPLICATION PRIVATE TRUE FALSE BEGIN END DEFINITION EXPLICIT ENUMERATED EXPORTS IMPORTS	REAL INCLUDES MIN MAX SIZE FROM WITH COMPONENT PRESENT ABSENT DEFINED BY PLUS-INFINITY MINUS-INFINITI TAGS

<



/p>
Новая (более сложная) совокупность последовательностей в АСН. 1 называется продукцией. Каждая продукция состоит из имени новой совокупности последовательностей, знаков ::= и одной или нескольких совокупностей-вариантов последовательностей , разделенных знаком | . Каждая из совокупностей-вариантов задается списком имен. Каждое из этих имен является либо именем элемента, либо именем совокупности последовательностей, определенных с помощью продукции. Совокупность-вариант - это последовательность, получаемая выбором произвольной последовательности (или элемента) из совокупности, определяемой первым именем, за которой помещается произвольная последовательность (или элемент) из совокупности, определяемой вторым именем, за которой, в свою очередь, помещается произвольная последовательность (или элемент) из совокупности, определяемой третьим именем, и так далее, вплоть до последнего имени, заданного для данного варианта.
Одно или несколько выражений для определения типа и значений, оформленных как единое целое, называется модулем. Модуль задается следующими продукциями:
ОпределениеМодуля ::=ИдентификаторМодуля DEFINITION
ТегиПоУмолчанию “::=” BEGIN ТелоМодуля END
ТегиПоУмолчанию ::= EXPLICIT TAGS IMPLICIT TAGS Пусто
ИдентификаторМодуля ::=СсылкаНаМодуль ПрисвоенныйИдентификатор
ПрисвоенныйИдентификатор::=ЗначениеИдентификатораОбьекта |
Пусто
ТелоМодуля::=ВыходныеСсылки ВходныеСсылки СписокПрисвоений | Пусто
ВыходныеСсылки::=EXPORTS ВыходныеСимволы | Пусто
ВыходныеСимволы::= СписокСимволов |Пусто
ВходныеСсылки::=IMPORTS ВходныеСимволы | Пусто
ВходныеСимволы::=СписокСимволовИзМодуля | Пусто
СписокСимволовИзМодуля::= СимволыИзМодуля
СписокСимволовИзМодуля | СимволыИзМодуля
СимволыИзМодуля::= СписокСимволов FROM ИдентификаторМодуля
СписокСимволов::= Символ, СписокСимволов | Символ
Символ::= СсылкаНаТип | СсылкаНаЗначение
СписокПрисвоений::= СписокПрисвоений Присвоение | Присвоение
Присвоение::= ПрисвоениеТипа |
ПрисвоениеЗначения
Для задания ссылок на определения типов и значений используются последовательности, определяемые продукциями :


ОпределенныйТип::= ВнешняяСсылкаНаТип | СсылкаНаТип
ОпределенноеЗначение::=ВнешняяСсылкаНаЗначение |СсылкаНаЗначение
Присвоение ссылке на тип некоторого типа описывается продукцией “ПрисвоениеТипа”:
ПрисвоениеТипа::= СсылкаНаТип“::=“ Тип
Присвоение ссылке на значение некоторого типа описывается продукцией “ПрисвоениеЗначения”:
ПрисвоениеЗначения::= СсылкаНаЗначение Тип “::=“ Значение
Тип определяется одной из последовательностей вида “Тип”:
Тип::= ВстроенныйТип | ОпределенныйТип | Подтип
ВстроенныйТип::=БулевскийТип | ЦелочисленныйТип | Тип-СтрокаБитов |
Тип-СтрокаОктетов | ВырожденныйТип | Тип-Последовательность | Тип- ПоследовательностьИз | Тип-Множество |
Тип-МножествоИз | ВыборочныйТип |
СелективныйТип | ТегированныйТип |
ПроизвольныйТип |
Тип-ИдентификаторОбъекта | Тип-СтрокаЗнаков |
ОбщеупотребительныйТип |
ПеречислительныйТип |
Тип-ДействительноеЧисло |
Значение какого-либо типа должно определяться одной из последовательностей вида “Значение”:
Значение::= ВстроенноеЗначение |
ОпределенноеЗначение
ВстроенноеЗначение::=БулевскоеЗначение | ЦелочисленноеЗначение | Значение-СтрокаБитов |
Значение-СтрокаОктетов |
ВырожденноеЗначение |
Значение-Последовательность |
Значение-ПоследовательностьИз | Значение-Множество |
Значение-МножествоИз | ВыборочноеЗначение |
СелективноеЗначение |ТегированноеЗначение |
ПроизвольноеЗначение|
Значение-ИдентификаторОбъекта |
Значение-СтрокаЗнаков |
ОбщеупотребительноеЗначение |
ПеречислительноеЗначение |
Значение-ДействительноеЧисло |
Ниже приведены обозначения для типов и их значений:
Табл. 2.

Тип	Значение
БулевскийТип::= BOOLEAN	БулевскоеЗначение::= TRUE | FALSE
ЦелочисленныйТип::= INTEGER | INTEGER{СписокПоименованныхЧисел} СписокПоименованныхЧисел::= ПоименованноеЧисло | СписокПоименованныхЧисел, ПоименованноеЧисло ПоименованноеЧисло::= Идентификатор(ЧислоСоЗнаком) | Идентификатор(ОпределенноеЗначение) ЧислоСоЗнаком::= Число | -Число	ЦелочисленноеЗначение::=ЧислоСоЗнаком | Идентификатор
ПеречислительныйТип::= ENUMERATED {Перечисление}Перечисление::= ПоименованноеЧисло | ПоименованноеЧисло, Перечисление	ПеречислительноеЗначение:= Идентификатор
Тип-ДействительноеЧисло::= REALДействительные числа могут быть представлены формулой, содержащей три целочисленные аргумента - M, B и E : М*ВЕ , где М называется мантиссой, В- основанием, а Е- порядком. М и Е могут принимать любые значения, а В - 2 или 10	Значение-ДействительноеЧисло::=ЧисленноеДействительноеЗначение | СпециальноеДействительноеЗначение ЧисленноеДействительноеЗначение::= {Мантисса, Основание, Порядок} |0 Мантисса::= ЧислоСоЗнаком Основание::= 2 | 10 Порядок::= ЧислоСоЗнаком СпециальноеДействительноеЗначение::= PLUS-INFINITY | MINUS-INFINITY
Тип-СтрокаБитов::=BIT STRING BIT STRING{ СписокПоименованныхБитов } СписокПоименованныхБитов::= ПоименованныйБит | СписокПоименованныхБитов, ПоименованныйБит ПоименованныйБит::= Идентификатор(Число) | Идентификатор(ОпределенноеЗначение)	Значение-СтрокаБитов::=b-строка | h-строка | {СписокИдентификаторов}| {} СписокИдентификаторов::= Идентификатор | СписокИдентификаторо, Идентификатор
Тип-СтрокаОктетов::= OCTET STRING	Значение-СтрокаОктетов::=b-строка | h-строка
ВырожденныйТип::= NULL	ВырожденноеЗначение::= NULL
Тип-Последовательность::=SEQUENSE{СписокТипов-Компонентов} SEQUENSE{} СписокТипов-Компонентов::= Тип-Компонент | СписокТипов-Компонентов, Тип-Компонент Тип-Компонент::= ПоименованныйТип | ПоименованныйТип OPTIONAL | ПоименованныйТип DEFAULT Значение | COMPONENTS OF Тип	Значение-Последовательность::={СписокЗначенийКомпонентов} | {} СписокЗначенийКомпонентов::= ПоименованноеЗначение | СписокЗначенийКомпонентов, ПоименованноеЗначение
Тип-ПоследовательностьИз::=SEQUENSE OF Тип | SEQUENSE	Значение-ПоследовательностьИз::={СписокЗначений} | {} СписокЗначений::= Значение | СписокЗначений, Значение
Тип-Множество::= SET{ СписокТипов-Компонентов } | SET{}	Значение-Множество::= {СписокЗначенийКомпонентов} | {} СписокЗначенийКомпонентов::= ПоименованноеЗначение | СписокЗначенийКомпонентов, ПоименованноеЗначение
Тип-МножествоИз::= SET OF Тип | SET	Значение-МножествоИз::={СписокЗначений} | {} СписокЗначений::= Значение | СписокЗначений, Значение
ВыборочныйТип ::= CHOICE{СписокТипов-Вариантов} СписокТипов-Вариантов::= ПоименованныйТип | СписокТипов-Вариантов, ПоименованныйТип	ВыборочноеЗначение::= ПоименованноеЗначение
СелективныйТип::= Идентификатор< ВыборочныйТип,где “Идентификатор” - один из “Идентификаторов” “ПоименованныхТипов”	СелективноеЗначение::= ПоименованноеЗначение
ТегированныйТип::=Тег Тип | Тег IMPLICIT Тип | Тег EXPLICIT Тип| Тег::= [Класс НомерВКлассе] НомерВКлассе::= Число | ОпределенноеЗначение Класс::= UNIVERSAL | APPLICATION | PRIVAT | Пусто	ТегированноеЗначение::= Значение, где“Значение” - обозначение значения типа, заданного последовательностью “Тип” в продукции “ТегированныйТип”
ПроизвольныйТип ::=ANY | ANY DEFINED BY идентификатор|	ПроизвольноеЗначение::=Тип-Значение, где“Тип” - обозначение выбранного типа, а “Значение” - обозначение для записи значения этого типа
Тип-ИдентификаторОбъекта::= OBJECT IDENTIFIER|	Значение-ИдентификаторОбъекта::={СписокКомпонентовИдОбъекта) | {ОпределенноеЗначение СписокКомпонентовИдОбъекта} СписокКомпонентовИдОбъекта::= КомпонентовИдОбъекта | КомпонентовИдОбъекта СписокКомпонентовИдОбъекта КомпонентовИдОбъекта::= ИменнаяФорма | ЧисловаяФорма | СмешаннаяФорма ИменнаяФорма::=Идентификатор ЧисловаяФорма::=Число | ОпределенноеЗначение СмешаннаяФорма::= Идентификатор(ЧисловаяФорма)
Тип-СтрокаЗнаков::=СсылкаНаТип, где“СсылкаНаТип”-одно из имен типов “строка знаков”	Значение-СтрокаЗнаков::= с-строка

<

Структура тега АСН.1.

Кодовое представление тега должно состоять из четырех составных частей, следующих в порядке перечисления:

октеты идентификатора;

октеты длины;

октеты содержимого;

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

На рис.1. представлена структура кодового представления:

а) явный формат длины тега

октеты идентификатора

октеты длины

октеты содержимого

б) неявный формат длины тега, используется в случае невозможности задать длину сразу

октеты идентификатора

октет длины = 10000000 ( признак неявного формата)

октеты содержимого

00000000 00000000 (признак завершения тега)

Октеты идентификатора

В октетах идентификатора должен быть закодирован тег АСН.1 того типа (класс и номер), к которому относится значение данных. Для тегов, имеющих номер от нуля до 30 включительно, октеты идентификатора представлены одним октетом, закодированным следующим образом (рис.2.):

а) биты 7 и 8 представляют класс тега (табл.3.);

Табл.3.

Класс	Бит 8	Бит 7
Универсальный	0	0
Прикладной	0	1
Контекстно-зависимый	1	0
Пользовательский	1	1

б) бит 6 должен иметь значение “ноль”, если кодовое представление простое, и “единица”, если оно - составное;

в) биты с 5 по 1 должны быть кодовым представлением номера тега в виде двоичного целого с битом 5 в качестве старшего бита.

Для тегов с номерами большими 30, идентификатор должен состоять из головного октета, за которым следуют один или более октетов продолжения. Кодовое представление головного октета должно быть следующим (см. рис.3.):

Рис.3.

а) биты 7 и 8 задают класс тега (табл.3.);

б) бит 6 должен иметь значение “ноль”, если кодовое представление простое, и “единица”, если оно - составное;

в) биты с 5 по 1 должны иметь кодовое представление 111112.

Октеты продолжения являются кодовым представлением номера тега; они должны иметь следующий вид (рис.):

а) бит 8 каждого октета, за исключением последнего октета идентификатора, должен быть установлен в единицу;

б) биты с 7 по 1 первого октета продолжения , сцепленные с битами 7-1 второго октета продолжения , сцепленные, в свою очередь, с битами 7-1 каждого из октетов продолжения, до последнего включительно, должны быть кодовым представлением номера тега в виде двоичного целого числа без знака, с битом 7 первого октета продолжения в качестве старшего бита.;

в) биты с 7 по 1 первого последующего октета не должны быть все установлены в ноль.

Рис.4.

Октеты длины

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

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

В коротком формате бит 8 единственного октета установлен в ноль , а биты с 7 по 1 являются кодовым представлением количества октетов содержимого в виде двоичного целого числа без знака с битом 7 в качестве старшего разряда. Например, число 42 будет закодировано как 001010102

.

В длинном формате октеты длины состоят из начального октета и одного или более октетов продолжения. Кодовое представление начального октета должно быть следующим:

а) бит 8 должен быть установлен в единицу;

б) биты с 7 по 1 являются кодовым представлением количества последующих октетов длины в виде двоичного целого числа без знака с битом 7 в качестве старшего разряда;

в) двоичное значение 111111112 не должно использоваться.

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

100000102 000000012 010101102 (при использовании длинного формата отправитель может по своему выбору использовать большее количество октетов, чем необходимый минимум).

В случае неявного формата октеты длины состоят из единственного октета 100000002 . При этом конец октетов содержимого задается двумя октетами признака конца содержимого, имеющими нулевое значение (000000002 000000002 ) .

Тег также может быть простым или составным. Составной тег включает в свое информационное поле набор простых или составных тегов. Простой тег содержит конечную последовательность данных одного типа.

<

table border="0" cellpadding="0" cellspacing="0" width="100%">

Типы тегов АСН.1.

Все типы данных имеют различные имена тегов. Тип данных может быть простым либо структурированным (сложным). Простой тип определяется прямым заданием множества составляющих его значений. При определении структурированного типа используются ссылки на другие типы. При этом значением сложного типа может являться:

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

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

в) упорядоченная последовательность или неупорядоченное множество, состоящее из пустого множества значений, одного или более значений существующего (исходного) типа;

г) элемент подмножества исходного типа, образованного использованием некоторой структурной или порядковой взаимосвязи между элементами исходного множества;

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

Существует четыре класса тегов:

универсальный (universal);

2) прикладной (application);

3) пользовательский (private);

4) контекстно-зависимый (context-specific).

Теги универсального класса определяются спецификациями Рекомендации Х.208, описывающей АСН.1, причем каждый тег присвоен какому-то одному типу либо некоторому способу построения типов. Теги назначаются таким образом, чтобы для структурированных типов по тегу можно было определить структуру верхнего уровня, а для простых типов тег полностью определял тип. В таблице 1 представлены теги универсального класса, назначенные в Х.208.

Табл. 1.

ТЕГ	ТИП	ОПИСАНИЕ
UNIVERSAL 1	булевский	простой тип с двумя различными значениями: истина(TRUE) и ложь(FALSE)
UNIVERSAL 2	целочисленный	простой тип с различными значениями, являющимися положительными или отрицательными целыми числами, включая ноль (рассматриваемый как одно значение)
UNIVERSAL 3	“строка битов”	простой тип, различными значениями которого являются упорядоченные последовательности из пустого множества битов, одного или более битов (число битов в строке не ограничено)
UNIVERSAL 4	“строка октетов”	простой тип, различными значениями которого являются упорядоченные последовательности из пустого множества октетов, одного или более октетов, где октет -упорядоченная последовательность из восьми битов (число октетов в строке не ограничено)
UNIVERSAL 5	вырожденный	простой тип, состоящий из единственного значения, также называемого вырожденным значением (“NULL”)
UNIVERSAL 6	“идентификатор объекта”	тип, различные значения которого составляют множество всех идентификаторов объектов, присвоенных в соответствии с АСН.1 (АСН.1 предоставляет возможность целому ряду организаций - источников идентификации независимо друг от друга связывать идентификаторы объектов с информационными объектами)
UNIVERSAL 7	“описатель объекта”	тип, различные значения которого имеют вид текста, ориентированного на восприятие человеком, дающего краткое описание информационного объекта
UNIVERSAL 8	внешний	тип, различные значения которого не могут быть установлены только лишь по той информации, что они являются значениями внешнего типа, однако значения типа могут быть установлены по их кодовому представлению; эти значения могут быть (но не обязательно) описаны с помощью АСН.1, и соответственно их кодовое представление может (но не обязательно) соответствовать правилам кодирования для АСН.1
UNIVERSAL 9	“действительное число”	простой тип, различными значениями которого являются элементы множества действительных чисел
UNIVERSAL 10	перечислительный	простой тип, значениям которого назначаются отличные друг от друга идентификаторы, являющиеся частью обозначения для этого типа
UNIVERSAL 12-15	зарезервированы для последующих версий
UNIVERSAL 16	“последовательность” и “последовательность из”	структурированный тип, определяемый ссылкой на фиксированный, упорядоченный список типов (некоторые из которых могут быть объявлены необязательными); каждое значение нового типа является упорядоченной последовательностью значений типов-компонентов, по одному из каждого из них. структурированный тип, определяемый ссылкой на один из уже существующих типов; каждое значение нового типа является упорядоченной последовательностью из пустого множества значений, одного или более значений существующего типа
UNIVERSAL 17	“множество” и “множество из”	структурированный тип, определяемый ссылкой на фиксированный неупорядоченный список различных типов (некоторые из которых могут быть объявлены необязательными); каждое значение нового типа является неупорядоченным списком значений, по одному из каждого типа-компонента структурированный тип, определяемый ссылкой на единственный существующий тип; каждое значение нового типа является неупорядоченным списком из нуля, одного или более значений существующего типа
UNIVERSAL 18-22	“строка знаков”	тип, значения которого являются строками знаков из некоторого набора знаков
UNIVERSAL 23-24	“время”
UNIVERSAL 28-...	зарезервированы для последующих версий

<

/p>

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

Теги пользовательского класса никогда не присваиваются в стандартах ИСО и Рекомендациях МККТТ. Порядок их использования может быть различным в различных организациях.

Теги контекстно-зависимого класса могут свободно назначаться при любом использовании АСН.1 и интерпретируются в соответствии с контекстом, в котором они используются.

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

<

Адресация сетевого уровня

Адреса сетевого уровня VINES являются 48-битовыми об'ектами, подразделенными на сетевую (32 бита) и подсетевую (16 битов) части. Сетевой номер можно описать как номер какого-нибудь служебного устройства, т.к. он получается непосредственно из ключа (key) служебного устройства (аппаратного модуля, который обозначает уникальный номер и программные опции для данного служебного устройства). Подсетевая часть адреса VINES лучше всего описывается как номер хоста, т.к. он используется для обозначения хоста в сетех VINES. Рисунок иллюстрирует формат адреса VINES.

Сетевой номер обозначает логическую сеть VINES, которая представлена в виде двухуровневого дерева, корень которого находится в узле обслуживания (service node). Узлы обслуживания, которыми обычно являются служебные устройства, обеспечивают услуги резрешения адреса и услуги маршрутизации клиентам (client), которые являются листьями этого дерева. Узел обслуживания назначает адреса VIP клиентам.

Когда какой-нибудь клиент включает питание, он направляет широковещательный запрос служебным устройствам. Все служебные устройства, которые получают этот запрос, посылают ответ. Клиент выбирает первый ответ и запрашивает у данного служебного устройства адрес подсети (хоста). Служебное устройство отвечает адресом, состоящим из его собственного сетевого адреса (полученного из его ключа), об'единенного с адресом подсети (хоста), который он выбрал сам. Адреса подсети клиента обычно назначаются последовательно, начиная с 8001H. Адреса подсети служебного устройства всегда 1. Процесс выбора адреса VINES показан на рисунке.

Динамичное назначение адреса не является уникальным явлением в индустрии сетей (AppleTalk также использует этот процесс); однако этот процесс определенно не является таким обычным процессом, как статическое назначение адреса. Т.к. адреса выбираются исключительно каким-нибудь одним конкретным служебным устройством (чей адрес является уникальным вследствие уникальности аппаратного ключа), вероятность дублирования адреса (что является потенциально опасной проблемой для сети Internet Protocol (IP) и других сетей) очень мала.

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

Маршрутные таблицы VINES состоят из пар "хост/затраты", гдe хост соответствует сетевому узлу, до которого можно дойти, а затраты - временной задержке в миллисекундах, необходимой для достижения этого узла. RTP помогает служебным устройствам VINES находить соседних клиентов, служебные устройства и роутеры.

Все клиенты периодически об'являют как о своих адресах сетевого уровня, так и о адресах МАС-уровня с помощью пакета, эквивалентого пакету "hello" (приветственное сообщение). Пакеты "hello" означают, что данный клиент все еще работает и сеть готова. Сами служебные устройства периодически отправляют в другие служебные устройства маршрутные корректировки. Маршрутные корректировки извещают другие роутеры об изменениях адресов узлов и топологии сети.

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

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

Компания Banyan Virtual Network System (VINES) реализовала систему распределенной сети, базирующуюся на семействе патентованных протоколов, разработанных на основе протоколов Xerox Network Systems (XNS) компании XEROX. Среда распределенной системы обеспечивает прозрачный для пользователя обмен информации между клиентами (компьютерами пользователя) и служебными устройствами (компьютерами специального назначения, которые обеспечивают услуги, такие, как файловое и принтерное обслуживание). Наряду с NetWare компании Novell, LAN Server компании IBM и LAN Manager компании Microsoft, VINES является одной из самых популярных сред распределенной системы для сетей, базирующихся на микрокомпьютерах. <

Доступ к среде (Banyan Vines)

Два низших уровня комплекта протоколов VINES реализованы с помощью различных общеизвестных механизмов доступа к носителю, включая Управление информационным каналом высшего уровня (HDLC) , Х.25 , Ethernet  и Тоken Ring .

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

Формат пакета VIP

Протокол VIP
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0	Контрольная сумма
2	Общая длина пакета
4	Управление передачей	Тип пакета
6 8	Номер сети получателя
10	Номер подсети получателя
12 14	Номер сети отправителя
16	Номер подсети отправителя
18	Данные

Пакет VIP начинается с поля контрольной суммы (checksum), используемой для обнаружения искажений в пакете.

За полем контрольной суммы идет поле длины пакета (packet length), которое обозначает длину всего пакета VIP.

Следующим полем является поле управления транспортировкой (transport control), которое состоит из нескольких подполей. Если пакет является широковещательным, то предусматривается два подполя: подполе класса (class) (с 1 по 3 биты) и подполе числа пересылок (hop-count) (с 4 по 7 биты). Если пакет не является широковещательным пакетом, то предусматривается 4 подполя: подполе ошибки (error), подполе показателя (metric), подполе переадресации (redirect), и подполе числа пересылок (hop count). Подполе класса определяет тип узла, который должен принимать широковещательное сообщение. С этой целью узлы разделяются на несколько различных категорий, зависящих от типа узла и типа канала, к которому принадлежит узел. Определяя тип узлов, которые должны принимать широковещательные сообщения, подполе класса уменьшает вероятность срывов в работе, вызываемых широковещательными сообщениями. Подполе числа пересылок представляет собой число пересылок (число пересеченных роутеров), через которые прошел пакет. Подполе ошибок определяет, надо ли протоколу ICP отправлять пакет уведомления об исключительной ситуации в источник пакета, если пакет окажется немаршрутизируемым. Подполе показателя устанавливается в 1 транспортным об'ектом, когда ему необходимо узнать затраты маршрутизации при перемещения пакетов между каким-нибудь узлом обслуживания и одним из соседей. Подполе переадресации определяет, должен ли роутер генерировать сигнал переадресации (при соответствующих обстоятельствах).

Далее идет поле типа протокола (protocol type), указывающее на протокол сетевого или транспортного уровня, для которого предназначен пакет показателя или пакет уведомления об исключении. В настоящее время известны следующие значения: 1-IPC, 2-SPP, 4-ARP, 5-RTP, 6-ICP.

За полем типа протокола следуют адресные поля VIP. За полями номера сети назначения (destination network number) и номера подсети назначения (destination subnetwork number) идут поля номера сети источника (sourсe network number) и номера подсети источника (source subnetwork number).

Протокол фрагментации FRP.

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

Протокол FRP (протокол фрагментации)
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
	Управление	Последовательный номер
	Данные

Поле “Управление” протокола FRP содержит признаки начала и конца фрагмента. Поле “Последовательный номер” содержит последовательный номер сегмента.

Протокол корректировки маршрутизации (RTR)

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

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

RTR определяет 4 типа пакетов:

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

Пакеты RTR имеют 4-байтовый заголовок, состоящий из однобайтового поля типа операций (operation type), однобайтового поля типа узла (node type), однобайтового поля типа контроллера (controller type) и однобайтового поля типа машины (machine type). Поле типа операций указывает на тип пакета. Поле типа узла указывает, пришел пакет из узла обслуживания или из необслуживающего узла. Поле типа контроллера указывает, содержит ли контроллер узла, передающего пакет RTR, многобуферный контроллер. Это поле используется для облегчения регулирования информационного потока между сетевыми узлами. И наконец, поле типа машины указывает, является ли процессор отправителя RTR быстодействующим или нет. Как и поле типа контроллера, поле типа машины также используется для регулирования скорости передачи.

Протокол разрешения адреса (ARP)

Об'екты протокола ARP классифицируются либо как клиенты разрешения адреса (address resolution clients), либо как услуги разрешения адреса (address resolution services). Клиенты разрешения адреса обычно реализуются в узлах клиентов, в то время как услуги разрешения адреса обычно обеспечиваются узлами обслуживания.

Пакеты ARP имеют 8-байтовый заголовок, состоящий из 2-байтового типа пакета (packet type), 4-байтового номера сети (network number) и 2-байтового номера подсети (subnet number). Имеется 4 типа пакетов: запрос-заявка (query request), который является запросом какой-либо услуги ARP; ответ об услуге (service response), который является ответом на запрос-заявку, запрос о присваивании адреса (assignment request), который отправляется какой-нибудь услуге ARP для запроса адреса об'единенной сети VINES, и ответ о присваивании адреса (assignment response), который отправляется данной услугой ARP в качестве ответа на запрос о присваивании адреса. Поля номера сети и номера подсети имеют значение только в пакете ответа о присваивании адреса.

Когда какой-нибудь клиент приступает к работе, клиенты и услуги ARP реализуют следующий алгоритм. Сначала данный клиент отправляет широкой рассылкой пакеты запросов-заявок. Затем каждая услуга, которая является соседом данного клиента, отвечает пакетом ответа об услуге. Далее данный клиент выдает пакет запроса о присваивании адреса в первую услугу, которая ответила на его пакет запроса-заявки. Услуга отвечает пакетом ответа о присваивании адреса, содержащем присвоенный адрес об'единенной сети.

Протокол управления объединеной сетью (ICP)

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

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

Об'екты ICP в узлах обслуживания генерируют сообщения уведомления о показателе в том случае, когда устанавливается подполе показателя в поле управления транспортировкой заголовка VIP, и адрес пункта назначения в пакете узла обслуживания определяет одного из соседей этого узла обслуживания. <

Протоколы архитектуры Banyan Vines

Сетевая архитектура Banyan Vines была разработана одноименной фирмой для создания корпоративных сетей (КС) на основе своих программных средств. Она получила широкое распространение при создании КС предприятий. Успех вызван наличием развитых прикладных служб уровня корпорации, реализованных в рамках сетевой ОС Vines. ОС Vines является вариантом ОС Unix.

Перечень протоколов сетевой архитектуры Banyan Vines приведен в таблице. Схема взаимодействия протоколов приведена здесь.

Обозначение	Название протокола (анг.)	Назначение протокола
VIPC	VINES Interprocess Communication Protocol	Транспортный протокол
VSPP	VINES Sequenced Packet , Protocol	Протокол, ориентированный на последовательную передачу пакетов
VRTP	VINES (sequenced/ non- sequenced) Routing Update Protocol	Протокол маршрутизации с установлением и без установления соединения
VARP	VINES (sequenced/ non- sequenced) Adress Resolution Protocol	Протокол выделения адресов с установлением и без установления соединения
VICP	VINES Internet Control Protocol	Межсетевой протокол управления
VIP	Internet Protocol	Межсетевой протокол
VFRP	VINES Fragmettation Protocol	Протокол фрагментации
	Device Drivers
VINES Application Services	Street Talk, Directory Assistance, Vanquard Security, File Service, Mail, Print Gateway Service	Прикладные протоколы и службы
VINES SMB	Server Message Block	Блок протоколов, ориентированных на сообщенясервера
VINES NetRPC

Архитектура обеспечивает возможности взаимодействия абонентов как на основе ЛВС, так и на основе глобальных сетей типа Х.25. Она имеет шестиуровневую структуру: физический, канальный, фрагментации, сетевой, транспортный, прикладной.

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

Основным межсетевым протоколом является VIP (Vines Internet Protocol). Основным транспортным протоколом - IPC. Кроме того, архитектура допускает использование протоколов других сетевых архитектур.

Протоколы сетевого уровня (Banyan Vines)

	Адресация сетевого уровня
	Формат пакета VIP
	Протокол корректировки маршрутизации (RTR)
	Протокол разрешения адреса (ARP)
	Протокол управления объединеной сетью (ICP)

Для выполнения функций Уровня 3 (в том числе маршрутизации в об'единенной сети) VINES использует Протокол межсетевого обмена VINES (VINES Internetwork Protocol - VIP). VINES также обеспечивает собственный Протокол разрешения адреса (ARP), собственную версию Протокола информации маршрутизации (Routing Information Protocol - RIP), которая называется Протоколом корректировки маршрутизации (Routing Update Protocol - RTP) и Протокол управления Internet (ICP), который обеспечивает обработку исключительных состояний и специальной информации о затратах маршрутизации. Пакеты ICP, RTP и ARP формируются в заголовке VIP.

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

Являясь распределенной сетью, VINES использует модель вызова процедуры обращений к отдаленной сети (remote procedure call - RPC) для связи между клиентами и служебными устройствами. RCP является основой сред распределенных услуг. Протокол NetRPC (Уровни 5 и 6) обеспечивает язык программирования высшего уровня, который позволяет осуществлять доступ к отдаленным услугам способом, прозрачным как для пользователя, так и для прикладной программы.

На Уровне 7 VINES обеспечивает протоколы файловых услуг и услуг принтера, а также протокол услуг "StreetTalk name/directory". StreetTalk, один из протоколов с торговым знаком компании VINES, обеспечивает службу постоянных имен в глобальном масштабе для всей об'единенной сети.

VINES также обеспечивает среду разработки интегрированных применений при наличии нескольких операционных систем, включая DOS и UNIX. Taкая среда разработки позволяет третьей участвующей стороне осуществлять разработку как клиентов, так и услуг, действующих в среде VINES. <

Транспортный уровень (Banyan Vines)

VINES обеспечивает три услуги транспортного уровня:

	Unreliable datagram service. Услуги ненадежных дейтаграмм. Отправляет пакеты, которые маршрутизируются на основе принципа "наименьших затрат" (best-effort basis), но не подтверждаются сообщением о приеме в пункте назначения.
	reliable datagram service. Услуги надежных дейтаграмм. Услуга виртуальной цепи, которая обеспечивает надежную упорядоченную доставку сообщений между узлами сети с подтверждением о приеме. Надежное сообщение может быть передано с максимальным числом пакетов, равным 4.
	data stream service. Услуга потока данных. Поддерживает контролируемый поток данных между двумя процессами. Услуга потока данных является услугой виртуальной цепи с подтверждением о приеме, которая обеспечивает передачу сообщений неограниченных размеров.

Формат короткого пакета услуги Unreliable datagram service, обеспечивающей услуги передачи данных без установления соединения.

Короткий формат протокольного блока протокола IPС
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0	Порт источника
2	Порт получателя
4	Тип пакета	Байт управления
6 8	Данные

Формат длинного пакета услуги reliable datagram service, обеспечивающей услуги передачи данных с установления соединения. Данный тип соединения обеспечивает гарантированную доставку данных.

Длинный формат протокольного блока протокола IPС
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0	Порт источника
2	Порт получателя
4	Тип пакета	Байт управления
6	Локальный идентификатор соединения
8	Удаленный идентификатор соединения
10	Последовательный номер
12	Номер подтверждения
14	Признак ошибки или длина пакета
16	Данные

Поля “Порт источника (получателя)” протокола IPС определяют тип программы пользователя. Поля идентификаторов соединения определяют конкретно созданное соединение в одинаковых портах. Поле “Тип пакета” определяет тип передаваемых данных и имеет следующие значения: 0-дейтаграмма (короткий формат протокольного блока), 1-передача данных, 2-ошибка, 3-разъединение, 4-поиск, 5-подтверждение.

Архитектура протоколов коммитета ITU-T

Архитектура протоколов предлагаемая комитетом подробно описана в рекомендации Х.220. Она полностью соответствует модели

ЭМВОС (рекомендация Х.200). В данный обзор попали описания только протоколов Lapb,   Х.25, Х.224, Х.400. Структура взаимодействия протоколов данной архитектуры приведена на рисунке.

<

Формат ПЧ

	7 6 5 4 3 2 1 0
	Код параметра (КП)
	Указатель длины (УДП)
	Значение параметра (ЗП)

Значение указателя длины определяется по формуле -

V(УДП) = L(ЗП);

7 6 5 4 3 2 1 0

Код параметра (КП)

Указатель длины (УДП)

Значение параметра (ЗП)

ПЧ - переменная часть, поле дополнительных услуг.

V(УДП) = L(ЗП);

В ПЧ передается:

- идентификаторы пункта доступа к СТУ (используется в качестве статистических данных) 11000001 => отправитель, 11000010 => получатель;

- параметры защиты (используется в качестве статистических данных) 11000101 => ?;

- приоритет (используется в качестве статистических данных) 10000111 => ?;

- тайм-аут подтверждения (используется для определения тайм-аута окончания сообщения). Передается 16-ти разрядное двоичное число, значение в миллисекундах).

Функциональные возможности протокола.

Сегментирование: СБДТ сегментируется на несколько ПБДТ ДН.

Конкатенация ПБДТ: допускается сцепление нескольких ПБДТ для передачи в одном СБДС. Возможно сцепление любого количества ПБДТ типа ПД,ПСД,ОТК,ОШ,ПР принадлежащих разным СТУ. Разрешено соединять ПБДТ ЗС,ЗР,ПС,ДН,СД с другими ПБДТ, но данные ПБДТ должны быть последними.

Мультиплексирование: допускается передача по одному соединению сетевого уровня (ССУ) нескольких СТУ (в определенных классах СТУ).

Расщепление: допускается объединение нескольких ССУ в одно СТУ.

Деперемежение: упорядочивание ПБДТ по номерам, пришедших с нарушением очередности из разных ССУ.

Использование КФ:

2 разряд: 0 - использование нормального формата, 1 - использование расширенного формата.

Использование ПБДТ:

	ПБДТ ЗС,ПС используются для: открытия СТУ; определения параметров СТУ; закрепления идентификаторов за СТУ; выделение полей статистических данных; выделение данных пользователя.
	ПБДТ ЗР,ПР используются для: закрытия СТУ; выделения данных пользователя.
	ПБДТ ДН используются для формирования СБДТ.
	ПБДТ СД используются для формирования срочных СБДТ(ССБДТ).
	ПБДТ ПД используются для поддержания СТУ в случае временного отсутствия передачи данных

Класс СТУ: 8, 7, 6, 5 разряды

	0000 - класс 0;
	0001 - класс 1;
	0010 - класс 2;
	0011 - класс 3;
	0100 - класс 4;

порядковый номер передаваемого ПБДТ ДН.

7 6 5 4 3 2 1 0

Указатель длины заголовка (УД)

1 1 1 1 0 0 0 0

НРКС

ДН

НРКС - порядковый номер передаваемого ПБДТ ДН.

Старший бит НРКС является признаком окончания СБДТ при сегментации (КС):

0 - промежуточный ПБДТ ДН;

1 - последний ПБДТ ДН в СБДТ.

Классы СТУ:

Используется 5 классов услуг: 0, 1, 2, 3, 4. Данные классы соответствуют протоколом ИСО: TP0, TP1, TP2, TP3, TP4.

Различия классов СТУ

Выполняемая функция	классы
	0	1	2	3	4
Управление потоком			+	+	+
Мультиплексирование			+	+	+
Расщепление					+
Обработка деперемежений					+
ПБДТ по номеру

Назначение.

Обеспечивает требуемое качество услуг связи между пользователями.

Указатель длины

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

1 1 1 1 0 0 0 0

Идентификатор получателя (ИП)

Н Р К С

П Ч

ДН

Описание протокольных блоков.

Элементарной конструкцией протокола является протокольный блок данных транспортного уровня (ПБДТ).

Структура ПБДТ

7 6 5 4 3 2 1 0

Указатель длины заголовка (УД)

ФЧ

ПЧ

ДН

Значение указателя длины определяется по формуле -

V(УД) = L(ФЧ)+L(ПЧ);

ФЧ - фиксированная обязательная часть протокола, ее содержимое и длина зависит от типа ПБДТ;

ПЧ - переменная часть, поле дополнительных услуг, используется не во всех типах ПБДТ;

ДН - поле данных, используется не во всех типах ПБДТ.

ПБДТ Запрос соединения (ЗС), Подтверждение соединения (ПС) :

7 6 5 4 3 2 1 0

Указатель длины заголовка (УД)

Тип ПБДТ

Идентификатор получателя (ИП)

Идентификатор отправителя (ИО)

Класс и факультат. Услуги (КФ)

ПЧ

ДН

V(УД) = L(ФЧ)+L(ПЧ);

Тип ПБДТ:= 1110ХХХХ для ЗС; = 1101ХХХХ для ПС.

ДН - поле данных.

ИП - (в ПБДТ ЗС=0),используется для закрепления последующих ПБДТ за создаваемым СТУ;

ПД - Подтверждение данных (ПД):

Нормальный формат

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

0 1 1 0 Х Х Х Х

Идентификатор получателя (ИП)

НР

ПЧ

Расширенный формат

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

0 1 1 0 Х Х Х Х

Идентификатор получателя (ИП)

НР

КРД

ПЧ

Указатель длины

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

1 1 1 1 0 0 0 0

Идентификатор получателя (ИП)

Н Р К С

П Ч

ДН

ПЧ - не используется.

СД - Срочные данные (СД):

Нормальный формат

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

0 0 0 1 0 0 0 0

Идентификатор получателя (ИП)

Н Р К С

П Ч

ДН

Расширенный формат

7 6 5 4 3 2 1 0

Указатель длины заголовка(УД)

0 0 0 1 0 0 0 0

Идентификатор получателя (ИП)

Н Р К С

П Ч

ДН

Область данных не должна превышать 16 октетов.

НРКС - порядковый номер передаваемого ПБДТ ДН. Старший бит НРКС является признаком окончания СБДТ при сегментации (КС):

0 - промежуточный ПБДТ ДН;

1 - последний ПБДТ ДН в СБДТ.

Типы пакета ПБДТ:

Кодировка 1-го октета ФЧ ПБДТ (тип пакета):

	Название пакета	Сокр.	7	6	5	4	3	2	1	0
1	Запрос соединения	ЗС	1	1	1	0	Х	Х	Х	Х
2	Подтверждение соединения	ПС	1	1	0	1	Х	Х	Х	Х
3	Запрос разъединения	ЗР	1	0	0	0	0	0	0	0
4	Подтверждение разъединения	ПР	1	1	0	0	0	0	0	0
5	Данные	ДН	1	1	1	1	0	0	0	0
6	Срочные данные	СД	0	0	0	1	0	0	0	0
7	Подтверждение данных	ПД	0	1	1	0	Х	Х	Х	Х
8	Подтверждение срочных данных	ПСД	0	0	1	0	0	0	0	0
9	Отказ	ОТК	0	1	0	1	Х	Х	Х	Х
10	Ошибка	ОШ	0	1	1	1	0	0	0	0
11	Протокол транспортного уровня идентификатор	ПИ	0	0	0	0	0	0	0	1

Пpимечание: xxxx - используются для пеpедачи поля КРD, кpедита пpиема.

 

Типы ПБДТ:

	Запpос соединения - ЗС
	Подтверждение соединения - ПС
	Запрос разъединения - ЗР
	Подтверждение разъединения - ПР
	Данные - ДН
	Срочные данные - СД
	Подтверждение данных - ПД
	Подтверждение срочных данных - ПСД
	Отказ - ОТК
	Ошибка - ОШ
	Протокол транспортного уровня идентификатор - ПИ

ЗР/ПР - Запрос разъединения (ЗР), Подтверждение разъединения (ПР):

7 6 5 4 3 2 1 0

Указатель длины заголовка (УД)

Тип ПБДТ

Идентификатор получателя (ИП)

Идентификатор отправителя(ИО)

Неиспользуемая область заголовка

Д Н

ДН - могут передаваться в ПБДТ ЗР.

Тип ПБДТ:= 10000000 для ЗР;

= 11000000 для ПР.

ДН - Данные (ДН):

Сетевая файловая система NFS

Сетевая файловая система NFS (Network File System) впервые была разработана компанией Sun Microsystems Inc. NFS использует транспортные услуги UDP и позволяет монтировать в единое целое файловые системы нескольких машин с ОС UNIX. Бездисковые рабочие станции получают доступ к дискам файл-сервера так, как будто это их локальные диски.

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

Удаленный доступ к файлам

	Доступ на основе протокола FTP
	Распределенная сетевая файловая система NFS

 

Адресация

Адреса DECnet не связаны с физическими сетями, к которым подключены узлы. Вместо этого DECnet размещает главные вычислительные машины, используя пары адресов область/узел (area/node address). В диапазон значений адресов области входят значения от 1 до 63 (включительно). Адрес узла может иметь значение от 1 до 1023 (включительно). Следовательно, каждая область может иметь 1023 узла, а в сети DECnet адресация может быть произведена примерно к 65,000 узлам. Области могут перекрывать несколько роутеров, и отдельный кабель может обеспечивать несколько областей. Следовательно, если какой-нибудь узел имеет несколько сетевых интерфейсов, то он использует один и тот же адрес область/узел для каждого интерфейса. На рисунке "Адреса DECnet" изображен пример сети DECnet с несколькими адресуемыми об'ектами.

Главные вычислительные машины DECnet не используют адреса уровня МАС (Media Access Control - Управлениe доступом к носителю), назначаемые производителем. Вместо этого адреса сетевого уровня встраиваются в адреса уровня МАС в соответствии с алгоритмом, который перемножает номер области на 1024 и прибавляет к результату номер узла. Результирующий 16-битовый десятичный адрес преобразуется в шестнадцатеричное число и добавляется к адресу АА00.0400 таким образом, что байты оказываются переставленными, так что наименее значимый байт оказывается первым. Например, адрес 12.75 DECnet становится числом 12363 (основание 10), которое равняется числу 304В (основание 16). После этого адрес с переставленными байтами добавляется к ставндартному префиксу адреса МАС DECnet; результирующим адресом является выражение АА00.0400.4В30.

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

Digital Equipment Corporation (Digital) разработала семейство протоколов DECnet с целью обеспечения своих компьютеров рациональным способом сообщения друг с другом. Выпущенная в 1975 г. первая версия DECnet обеспечивала возможность сообщения двух напрямую подключенных миникомпьютеров PDP-11. В последние годы Digital включила подддержку для непатентованных протоколов, однако DECnet попрежнему остается наиболее важным из сетевых изделий, предлагаемых Digital.

В настоящее время выпущена пятая версия основного изделия DECnet ( которую иногда называют Phase V, a в литературе компании Digital - DECnet/OSI). DECnet Phase V представляет собой надлежащим образом расширенный набор комплекта протоколов OSI, поддерживающий все протоколы OSI, а также несколько других патентованных и стандартных протоколов, которые поддерживались предыдущими версиями DECnet. Что касается ранее внесенных изменений в протокол, DECnet Phase V совместим с предыдущей версией (т.е. Phase IV). <

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

DNA поддерживает различные реализации физического и канального уровней. Среди них такие известные стандарты, как Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), IEEE 802..2 и Х.25. DNA также предлагает протокол канального уровня для традиционного двухточечного соединения, который называется Digital Data Communications Message Protocol (DDCMP) (Протокол сообщений цифровой связи) и шину с пропускной способностью 70 Mb/sek , используемую для группы абонентов VAX, которая называется Computer-room Interconnect bus (CI bus) (шина межсоединений машинного зала). <

Маршрутизация в сети DECnet

	Типы узлов сети
	Адресация
	Уровни маршрутизации

Протокол DECnet Phase IV

В пакете DECnet протокол транспортного уровня DNA, соответствующий сетевому уровню ЭМВОС, обеспечивает передачу данных между узлами DNA и их маршрутизацию дейтаграммным методом, а также взаимодействует с выше- и нижележащими протоколами NSP, Ethernet, Bridge, SNAP.

Все типы ПБ имеют общий заголовок: 2 байта длина дейтаграммы, 1 байт - поле управления, в котором младший разряд индицирует тип ПБ (0 - информационный, 1 - управляющий). В состав заголовка информационного ПБ входят: 8 байт - адрес получателя, 8 байт - адрес отправителя, 2 байта - число переприемов, 2 байта - 00 (резерв). Далее - информационное поле данных. Содержание байтов управления информационного ПБ и управляющего ПБ протокола DNA показано на рисунках.

  <

Сетевая архитектура DNA

В противоположность бытующему мнению, DECnet вовсе не является архитектурой сети, а представляет собой ряд изделий, соответсвующих Архитектуре Цифровой сети ( Digital Network Architecture - DNA) компании Digital. Как и большинство других сложных сетевых архитектур, поставляемых крупными поставщиками систем, DNA поддерживает большой набор как патентованных, так и стандартных протоколов. Перечень технологий, которые поддерживает DNA, постоянно растет по мере того, как Digital реализует новые протоколы. Рисунок иллюстрирует неполную картину DNA и связь некоторых ее компонентов с эталонной моделью OSI.

Основным коммутационным элементом сетевой архитектуры DNA является узел. Все узлы равноправны, т.е. каждый узел, может выступать в качестве любого функционального элемента ИВС. Узлы закреплены за различными областями (подобластями). Каждая область имеет своего администратора и средства маршрутизации.   Каждый узел имеет свой уникальный адрес. Структура адреса DECnet-4: 1 байт -номер области, 1 байт - номер подобласти, 6 байт - Ethernet адрес.

Архитектура DNA представляет собой иерархию функциональных уровней:

	1 - физический уровень
	2 - уровень канала передачи данных (КПД)
	3 - транспортный уровень
	4 - уровень сетевой службы и управления сессией
	5 - уровень сетевых применений
	6 - уровень управления сетью
	7 - пользовательский уровень

На физическом уровне осуществляется управление передачей данных по физическому каналу связи.

На уровне канала передачи данных (КПД) обеспечивается повышение достоверности данных, передаваемых между соседними узлами сети.

Транспортный уровень (DECnet 4 - уровень сквозного канала) и уровень управления сессией обеспечивают надежный последовательный дуплексный логический канал между абонентами вне зависимости от их расположения в сети.

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

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

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

Для уровней разработаны специальные протоколы, реализуемые пакетами DECnet. Однако, так как сети DECnet являются частными, каждый владелец такой сети вправе отказаться от каких-либо протоколов DECnet и реализовать другие, обеспечивающие услуги и межсетевые интерфейсы, необходимые смежным уровням. Например, используются протоколы DDCMP, Ethernet, DNA, NSP, DAP, NICE, SMB и др.

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

Обозна- чение	Название протокола (анг.)	Назначение протокола
DRP	DECnet Routing Protocol	Протокол маршрутизации и коммутации пакетов
NSP	Network Services Protocol DNA	Протокол сетевой службы
SSP	Network Information and Command Echange Protocol	Протокол обмена сетевой информацией управления
DAP	Data Access Protocol	Протокол доступа к данным
CNTRM	Network Command Terminal	Протокол сетевого командного терминала
MOP	Maintenance Operations Protocol	Протокол технического обслуживания
LAT	Local Area Transport Protocol	Транспортный протокол локальной области
DNS	Distributed Name Server	Распределенный сервер имен
SCP	Session Control Protocol DNA	Протокол управления сеансом DNA
FOUND	Foundation Services	Протокол управления основными сервисными процедурами
SCP	Session Control Protocol	Протокол управления сеансом

 

Сетевой уровень (DECnet)

DECnet поддерживает сетевые уровни как без установления соединения, так и с установлением соединения. Оба сетевых уровня реализуются протоколами OSI. Реализации без установления соединения используют Connectionless Network Protocol (CLNP) (Протокол сети без установления соединения) и Connectionless Network Service (CLNS) (Услуги сети без установления соединения). Сетевой уровень с установлением соединения использует X.25 Packet-Level Protocol (PLP) (Протокол пакетного уровня), который также известен как X.25 level 3 (Уровень 3 Х.25), и Connection-Mode Network Protocol (CMNP) (Протокол сети с установлением соединения).

Хотя в DECnet Phase V значительная часть DNA была приведена в соответствие с OSI, уже в DECnet Phase IV маршрутизация была очень схожа с маршрутизацией OSI. Маршрутизация DNA Phase V включает в себя маршрутизацию OSI (ES-IS и IS-IS) и постоянную поддержку протокола маршрутизации DECnet Phase IV. ЕS-IS и IS-IS.

  <

Схема протоколов архитектуры DNA

На рисунке приведены схема взаимодействия протоколов сетевой архитектуры DNA и возможные схемы взаимодействия с другими сетевыми архитектурами.

 <

Типы узлов сети

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

Маршрутные решения DECnet базируются на затратах (cost)-арбитражном показателе, назначаемом администратором сети для использования при сравнении различных путей через среду об'единенной сети. Затраты обычно базируются на числе пересылок, ширине полосы носителя и других показателях. Чем меньше затраты, тем лучше данный тракт. Если в сети имеют место неисправности, то протокол маршрутизации DECnet Phase IV использует значения затрат для повторного вычисления наилучшего мааршрута к каждому пункту назначения. Рисунок иллюстрирует расчет затрат в среде маршрутизации DECnet Phase IV.

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

Транспортный уровень DNA реализуется различными протоколами транспортного уровня, как патентованными, так и стандартными. Поддерживаются следующие протоколы транспортного уровня OSI: ТР0, ТР2 и ТР4.

Принадлежащий Digital Протокол услуг сети ( Network services protocol - NSP) по функциональным возможностям похож на ТР4 тем, что он обеспечивает ориентированное на соединение, с контролируемым потоком обслуживание, с фрагментацией и повторной сборкой сообщений . Обеспечиваются два подканала - один для нормальных данных, второй для срочных данных и информации управления потоком. Обеспечивается два типа управления потоком - простой механизм старт/стоп, при котором получатель сообщает отправителю, когда следует завершать и возобновлять передачу данных, и более сложная техника управления потоком, при которой получатель сообщает отправителю, сколько сообщений он может принять. NSP может также реагировать на уведомления о перегрузке, поступающие из сетевого уровня, путем уменьшения числа невыполненных сообщений, которое он может допустить.

Формат протокольного блока: 1 байт - тип сообщения, 2 байта - порт получателя, 2 байта - порт источника, 12 бит - счетчик пакетов (сегментов), 4 бита - управление потоком (старшие биты октета). Если старший бит (7) равен “1”, то это счетчик принятых пакетов, тогда далее следуют два байта счетчика переданных пакетов (происходит сдвижка заголовка). Далее - данные.

Формат поля “тип сообщения” (нумерация разрядов - старшие слева): 7-й разряд - признак расширенного поля (формат установлен); 5 и 6 - признак сегмента в пакете “данные” (00 - промежуточный сегмент, 01 - первый, 10 - последний, 11 - единственный); 4-й разряд - передаются данные (0), передаются управляющие сообщения (1); 3 и 2-й разряды - тип пакета (00 - данные, 01 - подтверждение приема, 10 - управляющие сообщения). <

Уровни маршрутизации

Узлы маршрутизации DECnet называются либо роутерами Уровня 1, либо роутерами Уровня 2. Роутер Уровня 1 сообщается с конечными узлами и с другими роутерами Уровня 1 в отдельной конкретной области. Роутеры Уровня 2 сообщаются с роутерами Уровня 1 той же самой области и роутерами Уровня 2 других областей. Таким образом, роутеры Уровня 1 и Уровня 2 вместе формируют иерархическую схему маршрутизации. Рассмотренные взаимоотношения иллюстрируются на рисунке.

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

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

  <

Функциональность

Рассмотрим алгоритм работы программы разрешения имен (алгоритм 2) со следующими исходными параметрами:

	SNAME — искомый домен
	STYPE — QTYPE запроса
	SCLASS - QCLASS запроса

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

SBELT — структура, схожая с SLIST. Она инициализируется из файла конфигурации и содержит список серверов, которые должны использоваться, когда программа разрешения имен не имеет никакой информации для выбора сервера имен.

CACHE — эта структура хранит результаты предыдущих запросов.

Алгоритм 2. Работа программы разрешения имен

Верхний уровень алгоритма запросов содержит четыре шага:

1. Просмотреть информацию на локальном компьютере (как правило, это содержание кэша) и, если информация найдена, вернуть ответ клиенту.

2. Найти сервер, вероятнее всего содержащий ответ на запрос.

3. Отправлять на него запрос до тех пор, пока не придет первый ответ.

4. Проанализировать ответ:

• если ответ содержит всю запрашиваемую информацию или содержит имя ошибки, поместить эти данные в кэш и вернуть клиенту

• если ответ содержит ссылку на другой сервер, поместить эту информацию в кэш и перейти к шагу 2

• если ответ содержит информацию CNAME и не содержит ответа на запрос, поместить информацию CNAME в кэш, изменить SNAME на каноническое имя ресурса из RR CNAME и перейти к шагу 1

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

Рассмотрим эти шаги алгоритма более подробно:

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

<

/p>

На шаге 2 программа разрешения ищет сервер имен, которому можно было бы отправить запрос. Стратегия поиска выглядит так: сначала просматриваются записи RR локального сервера, начиная с SNAME, затем просматриваются серверы-родители SNAME, затем родители этих родителей и т. д. до корня. Например, если SNAME = Mockapetris.ISI.EDU, сначала мы ищем NS записи сервера Mockapetris.ISI.EDU, затем ISI.EDU, затем EDU, и наконец "." (корень). Записи NS RR содержат имена хостов зоны, расположенной рядом или выше SNAME. Копируем этот список в SLIST и, используя локальные данные, определяем адреса этих хостов.

В некоторых случаях информация адреса недоступна, тогда программа может запустить параллельный процесс программы разрешения имен, который будет пытаться определить адреса по уже известным данным и по мере получения требуемой информации передавать ее программе-родителю. Если поиск записей RR NS завершился неудачно, программа разрешения имен инициализирует SLIST из структуры SBELT, т. е. если программа разрешения не знает, к какому серверу имен ей обращаться, она должна использовать информацию из файла настройки, в котором содержится список "пожарных" серверов. Хотя подобная ситуация относится к исключительным ситуациям, из файла конфигурации, как правило, выбираются какие-либо два сервера из корневых серверов и два сервера из серверов домена. Такой алгоритм построен для увеличения производительности работы системы, поскольку корневые серверы предоставляют быстрый доступ ко всему пространству имен, а локальные серверы имеют более быстрый доступ к сети данного домена,

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

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

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

Если ответ содержит сообщение о перенаправлении запроса, программа разрешения должна проверить, что рекомендуемый для обращения сервер "ближе", чем серверы из списка SLIST. Если нет, ответ считается недействительным и отбрасывается. В том случае, если рекомендуемый сервер "ближе", запись RR NS сервера и его адреса кэшируются, записываются в SLIST, и процесс поиска возобновляется.

Если ответ содержит CNAME, а тип запроса не совпадает с CNAME, процесс поиска возобновляется с параметрами ответа (каноническим именем) CNAME.

Имена и псевдонимы

В больших системах хосты, почтовые роутеры или почтовые ящики и др. сетевые ресурсы часто имеют по несколько имен. Например, имена C.ISI.EDU и USC-ISIC.ARPA принадлежат одному и тому же хосту, а почтовые ящики Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU и PVM@ISI.EDU адресуют один и тот же объект.

Для этих целей и используется тип записи CNAME. Этот тип определяет псевдоним объекта к которому он относится. Ясно, что псевдоним не может иметь какой-либо другой спецификации, поскольку данные для псевдонима объекта и самого объекта не могут различаться.

Присутствие типа CNAME предполагает выполнение сервером имен определенных дополнительных действий. Например, если сервер не смог найти какую-либо информацию по указанному имени, он проверяет записи типа CNAME данного класса. Если у указанного в запросе имени есть псевдоним — поиск повторяется по данному псевдониму (при повторном проходе записи типа CNAME уже не просматриваются).

Например, если сервер имен обрабатывает запрос адреса имени FUN.MAN.ARPA, а база данных содержит следующие записи:

FUN.MAN.ARPA            IN       CNAME             JOLLY.EDU

JOLLY.EDU                      IN       A                        10.0.0.12

обе эти записи возвращают в ответ на запрос адреса как по имени FUN.MAN.ARPA, так и по имени JOLLY.EDU значение 10.0.0.12.

Примечание

Имена доменов, указывающие на имя другого домена, должны использовать только реальное имя, а не псевдоним. Например, имя адреса домена JOLLY.EDU, описанного в примере, должно быть записано в следующем виде:

12.0.0.10.IN-ADDR.ARPA      IN        PTR                  JOLLY.EDU

Инсталляция и перемещение зон

Одной из обязанностей администратора зон является инсталляция зон на всех серверах имен, которые уполномочены для работы с этими зонами. При изменениях параметров зоны на одном из серверов эти изменения должны быть тиражированы на все серверы имен. Тиражирование или перемещение зон может быть сделано как через FTP, используя механизм передачи текстовых файлов архива, так и через DNS протокол.

Модель автоматического перемещения или обновления зон построена на том, что один из серверов имен является основным (master) в данной зоне. Все изменения на других зависимых (slave) серверах координируются в соответствии с изменениями главных файлов архива основного сервера.

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

Для обнаружения изменений зависимые серверы проверяют поле SERIAL записи SOA зоны основного сервера. Какое бы изменение не было сделано, поле SERIAL записи SOA зоны изменится. Оно может или просто увеличиться, или измениться в соответствии с датой и временем изменения файла главного архива (master file). Поле SERIAL служит как бы идентификатором версии настроек зоны, и по его значению можно определить, какая из двух копий зоны более поздняя.

Механизмом периодических запросов зависимых серверов управляют несколько параметров записи RR SOA — REFRESH, RETRY, EXPIRE.

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

Ответом на проверочный запрос является запись RR SOA основного сервера зоны. Если значения полей серийного номера зоны основного и зависимого сервера совпадают, то следующий запрос будет опять сделан через REFRESH секунд. Если зависимый сервер обнаружит, что превышено значение EXPIRY (время существования копии зоны), копия зоны должны быть помечена как устаревшая и уничтожена.

Если ответ на проверочный запрос показал, что зона была изменена, зависимый сервер должен сделать запрос на перемещение зоны (AXFR). Ответом на запрос AXFR будет последовательность сообщений. Первое и последнее сообщения должны содержать данные вершины узла зоны. Между ними должны располагаться сообщения с RR-зоны. Зависимый сервер должен обработать этот поток сообщений и построить собственную копию данной зоны.

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

Интерфейс разрешения имен

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

Трансляция имен хостов в адреса хостов. Эта функция построена на основе функций, работающих с файлом HOSTS.TXT, т. е. в определенной строке этого файла определено имя домена и соответствующий ему IP-адрес. При работе с DNS эта функция строит запрос по имени домена записи RR типа "А".

Трансляция адресов хостов в имена хостов. Эта функция, при работе с файлом HOSTS.TXT использует тот же механизм: в определенной строке этого файла определен IP-адрес и соответствующее ему имя домена. При построении DNS запроса по адресу, используется суффикс "IN-ADDR.ARPA" типа PTR. Например, запрос на имя хоста с адресом 1.2.3.4 выглядит как запрос записи RR типа PTR для имени "4.3.2.1. IN-ADDR.ARPA".

Функция просмотра. Эта функция позволяет строить произвольные запросы базы данных имен и адресов и не поддерживается в ранних версиях системы. Запрос может быть построен на основе параметров QNAME, QTYPE или QCLASS. Ответ содержит все записи, удовлетворяющие условиям запроса.

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

---

---