Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки, перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации.
Но все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть. Именно малая скорость установления маршрутов в RIP (и других протоколах, ориентированных на вектор расстояния) и является причиной их постепенного вытеснения другими протоколами.

Но даже усовершенствование, изложенное выше, не всегда срабатывает. На Рисунок 4.4.11.1а приведен пример, когда переходной процесс, несмотря на усовершенствование будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г, характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности".

Имена, зарезервированные слова и представления RPSL

2. Имена, зарезервированные слова и представления RPSL

Каждый класс имеет набор атрибутов, где записывается некоторая информация об объектах класса. Атрибуты могут быть обязательными и опционными. Обязательный атрибут должен быть определен для всех объектов класса. Опционный атрибут может отсутствовать. Атрибуты могут быть одно- и многозначными. Каждый объект однозначно идентифицируется набором атрибутов класса "key".

Значение любого атрибута имеет определенный тип. Язык RPSL не чувствителен к тому, в каком регистре записаны те или иные выражения. Далее перечислены наиболее часто используемые типы атрибутов.

Многие объекты в RPSL имеют имя. <object-name> составляется из букв, чисел, а также символов подчеркивания ("_") и дефисов ("-"), первым символов всегда должна быть буква, а последним символом - буква или цифра. Следующие слова зарезервированы в RPSL, и не могут использоваться в качестве имен:

any as-any rs-any peeras

and or not

atomic from to at action accept announce except refine

networks into inbound outbound

Имена, начинающиеся с определенных префиксов зарезервированы для определенных типов объектов. Имена, начинающиеся с "as-" зарезервированы для имен автономных систем. Имена, начинающиеся с "rs-" зарезервированы для набора имен маршрутов. Имена, начинающиеся с "rtrs-" зарезервированы для набора имен маршрутизаторов. Имена, начинающиеся с "fltr-" зарезервированы для набора имен фильтров. Имена, начинающиеся с "prng-" зарезервированы для набора имен партнеров.

Использование номеров AS и маршрутных наборов

Рисунок .15. Использование номеров AS и маршрутных наборов.

Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR.

5.4. Класс Filters и filter-set

Атрибуты класса filter-set представлены на Рисунок 16. Объект filter-set определяет набор маршрутов, которые соответствуют этому фильтру. Атрибут filter-set определяет имя фильтра. Он является именем RPSL, которое начинается с "fltr-".

Экспортное объединение с исключениями

Рисунок .31. Экспортное объединение с исключениями.

Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:

где <action> - спецификация действия (см. раздел 6.1.1), <condition> - булево выражение, описанное ниже, <router-expression> описано в разделе 5.6.

Все маршрутизаторы в <router-expression> и в агрегаторе (объединении) AS выполняют агрегацию. Если <router-expression> не специфицировано, все маршрутизаторы внутри агрегатора AS выполняют агрегацию. Спецификация <action> может установить атрибуты path объединения (aggregate), например, определить предпочтения для объединения.

Так как условие является булевым выражением, объединение создается, если и только если это условие истинно. <condition> - булево выражение, использующее логические операторы AND и OR (т.e. оператор NOT не разрешен):

HAVE-COMPONENTS { список префиксов }

EXCLUDE { список префиксов }

STATIC

Список префиксов в HAVE-COMPONENTS может состоять из более специфических префиксов объединения. Список может также включать диапазоны префиксов (т.e. использование операторов ^-, ^+, ^n, и ^n-m). В этом случае, по крайней мере, один префикс из каждого диапазона префиксов должен присутствовать в каждой маршрутной таблице, для того чтобы условие было выполнено. Список префиксов в EXCLUDE может быть произвольным. Условие выполняется, когда ни один из перечисленных префиксов не содержится в маршрутной таблице. Список может содержать диапазоны префиксов, а ни один префикс из этого диапазона не должен присутствовать в маршрутной таблице. Ключевое слово static всегда предполагается равным true.

Класс Advanced route

8. Класс Advanced route

8.1. Спецификация агрегатных маршрутов

Атрибуты components, aggr-bndry, aggr-mtd, export-comps, inject и holes используются для спецификации агрегатных маршрутов [11]. Объект route специфицирует агрегатный маршрут, если специфицирован любой из этих атрибутов за исключением inject. Атрибут origin для агрегатного маршрута производит объединение маршрутов на базе AS. Здесь термин "aggregate" используется в отношении генерируемого маршрута, термин "component" относится к маршрутам, использованным для формирования атрибута объединения (aggregate) path, а термин "more specifics" относится к любому маршруту, который более специфичен для объединения, вне зависимости от того, используется ли он при формировании атрибутов path. Атрибут components определяет, какой из составляющих маршрутов используется для формирования объединения. Его синтаксис выглядит следующим образом:

components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]

где <protocol> представляет собой имя протокола маршрутизации, такого как BGP4, OSPF или RIP (допустимые значения определяются словарем), а <filter> - выражение политики. Маршруты, соотносятся с одним из этих фильтров и получены с помощью соответствующего протокола, используются для формирования объединения (aggregate). Если <protocol> опущен, по умолчанию предполагается любой протокол. <filter> неявно содержит термин "AND" с более специфическими префиксами объединения, так что выбираются только маршруты компоненты. Если используется ключевое слово ATOMIC, объединение выполнено на уровне атомов [11]. Если атрибут components пропущен, используются все более специфичные префиксы без ключевого слова ATOMIC.

route: 128.8.0.0/15

origin: AS1

components: <^AS2>

route: 128.8.0.0/15

origin: AS1

Класс aut-num

6. Класс aut-num

Маршрутная политика специфицируется с использованием класса aut-num. Атрибуты класса aut-num представлены на Рисунок .23. Значение атрибута aut-num равно номеру AS, описанной данным объектом. Атрибут as-name является символическим именем (в рамках синтаксиса имен RPSL) AS. Импорт, экспорт и маршрутная политика по умолчанию AS специфицируются, используя атрибуты import, export и default, соответственно.

Класс dictionary

7. Класс dictionary

Класс dictionary обеспечивает расширяемость для RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и маршрутные протоколы. Атрибуты маршрутной политики, впредь называемые rp-атрибутами, могут соответствовать действительным протокольным атрибутам, таким как атрибуты пути BGP (напр., community, dpa и AS-path), или они могут соответствовать особенностям маршрутизатора (напр., гашение осцилляций маршрутов в BGP). Когда вводятся новые протоколы, новые протокольные атрибуты, или новые возможности миршрутизатора, объект словаря актуализуется, с тем чтобы ввести соответствующее описание rp-атрибута или протокола.

rp-атрибут относится к абстрактному классу, то есть представление данных не доступно. Вместо этого, доступ к ним определяется методом доступа. Например, rp-атрибут для BGP-атрибута AS-path называется aspath, и он имеет метод доступа, называемый prepend,

который вставляет дополнительные номера AS в атрибуты AS-path. Методы доступа могут воспринимать аргументы. Аргументы строго типофицируются. Например, метод prepend воспринимает номера AS в качестве аргументов.

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

Ниже рассматривается синтаксис и семантика класса dictionary. Это описание не существенно для понимания объектов dictionary (но оно существенно для их создания).

Атрибуты класса dictionary представлены на Рисунок .24. Атрибут dictionary является именем объекта словаря, подчиняющимся правилам присвоения имен в RPSL. Может существовать много объектов словаря, однако имеется только один стандартный объект "RPSL". Все средства используют этот словарь по умолчанию.

Класс inet-rtr

9. Класс inet-rtr

Маршрутизаторы специфицируются с использованием класса inet-rtr. Атрибуты класса inet-rtr показаны на Рисунок 35. Атрибут inet-rtr представляет собой допустимое имя DNS описанного маршрутизатора. Каждый атрибут alias, если он присутствует, является каноническим именем DNS для маршрутизатора. Атрибут local-as специфицирует номер AS, которой управляет данный маршрутизатор.

Классы Set

5. Классы Set

При спецификации политики часто полезно определить наборы объектов. Для этих целей определены классы as-set, route-set, rtr-set, filter-set, and peering-set. Эти классы определяют именованный набор. Члены этих наборов могут быть специфицированы непосредственно путем перечисления их в определении набора, или косвенно, имея ссылки членов-объектов на имена наборов. Допускается применение обоих методов.

Имя набора является словом rpsl со следующими ограничениями. Все имена as-set начинаются с префикса "as-". Все имена route-set начинаются с префикса "rs-". Все наборы имен rtr-set начинаются с префикса "rtrs-". Все имена filter-set начинаются с префикса "fltr-". Все имена peering-set начинаются с префикса "prng-". Например, as-foo является корректным именем as-set.

Имена наборов могут быть иерархическими. Имя иерархического набора представляет собой последовательность имен наборов и номеров AS, разделенных символом двоеточие ":". По крайней мере, одна компонента такого имени должна быть действительным именем набора (то есть начинается с одного из префиксов). Все компоненты имени набора иерархического имени должны иметь один и тот же тип. Например, следующие имена корректны: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.

Целью имени иерархического набора является выделение определенного пространства имен, так что администратор набора X1 управляет всем набором нижележащих имен, то есть X1:...:Xn-1. Таким образом, набор объектов с именем X1:...:Xn-1:Xn может быть создан администратором объекта с именем X1:...:Xn-1. То есть, только администратор AS1 может создать набор с именем AS1:AS-FOO. Только администратор AS1:AS-FOO может создать набор с именем AS1:AS-FOO:AS-BAR.

5.1. Класс as-set

Атрибуты класса as-set показан на Рисунок .9. Атрибут as-set определяет имя набора. Он является именем RPSL, которое начинается с "as-". Атрибут members перечисляет членов набора. Атрибут members является списком AS, или других имен as-set.

Конфигурация маршрутизатора

Рисунок 4.4.9.6.2. Конфигурация маршрутизатора

Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" показывает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" показывает результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует” каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.

Контактная информация

3. Контактная информация

Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации.

3.1. Класс mntner

Класс mntner специфицирует аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать объекты RPSL. Провайдер прежде чем создавать RPSL-объект, должен создать объект mntner. Атрибуты класса mntner показаны на Рисунок .1. Класс mntner описан в [13].

Атрибут mntner является обязательным и выполняет функцию ключа класса. Его значение – имя RPSL. Атрибут auth специфицирует схему, которая будет использоваться для идентификации и аутентификации запросов актуализации. Атрибут имеет следующий синтаксис:

auth: <scheme-id> <auth-info>

Например, auth: NONE

Маршрутизатор, использующий RSVP

Рисунок 4.4.9.6.6. Маршрутизатор, использующий RSVP

На Рисунок 4.4.9.6.6 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ. Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений (Resv) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком.

Каждая ЭВМ отправитель передает RSVP сообщения "Path" вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Это состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит помимо этого следующую информацию:

Шаблон отправителя

Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.

Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv.
Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.

Спецификация Tspec отправителя

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

Спецификация Adspec

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

Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP.

6. Объединение Flowspecs

Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является “наибольшей” из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные.

Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec.

Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной. Например, если один запрос требует высокой пропускной способности, а другой – жесткого ограничения задержек, один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна быть способна сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound).


В некоторых случаях спецификация flowspec по крайне мере настолько мала насколько возможно; это наибольший верхний предел GLB (Greatest Lower Bound).

Для вычисления эффективного значения flowspec (Re, Te), инсталлируемого в интерфейс, используются следующие шаги [RFC 2210]. Здесь Te – эффективная спецификация Tspec, а Re – эффективная спецификация Rspec.

Определяется эффективная спецификация flowspec для выходного интерфейса. В зависимости от технологии канального уровня, это может требовать объединения спецификаций flowspecs различных последующих узлов. Это означает вычисление эффективной спецификации flowspec, как LUB flowspecs. Какие спецификации следует объединять, определяется средой канального уровня, в то время как процедура объединения определяется используемой моделью обслуживания [RFC 2210]. В результате получается спецификация flowspec, которая непрозрачна для RSVP, но в действительности состоит из пары (Re, Resv_Te), где Re является эффективной спецификацией Rspec, а Resv_Te - эффективная спецификация Tspec.

Производится вычисление спецификации Path_Te, зависящей от приложения и представляющей собой сумму всех Tspecs, которые были присланы в сообщениях Path, пришедших от различных предшествующих узлов (напр., некоторые или все узлы A, Б, и Б' на Рисунок 4.4.9.6.6).

(Re, Resv_Te) и Path_Te передаются системе управления трафиком. Управление трафиком вычислит эффективную спецификацию flowspec, как минимум Path_Te и Resv_Te.

7. Гибкое состояние

RSVP использует подход "soft state" (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения "teardown" (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.



Сообщения Path и Resv практически эквивалентны (idempotent). Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние же на неиспользованном в данный момент сегменте маршрута будет аннулировано по таймауту. Следовательно, определение того, является ли сообщение "новым" или "обновляющим" принимается отдельно для каждого узла в зависимости от его текущего состояния.

Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP сообщений. Если таймаут удаления установлен равным K периодам обновления, тогда RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP, чтобы предотвратить их потерю из-за перегрузки канала.

Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, неиспользуемые состояния будут аннулированы по таймауту, если не поступит прямых указаний по их ликвидации до этого.

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



Состояние, которое получено через конкретный интерфейс I* никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I* должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на Рисунок 4.4.9.6.7, на котором показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на Рисунок 4.4.9.6.7 “Получает” и “Отправляет” подразумевает внешнее направление по отношению к маршрутизатору).

Маршрутизаторы, подключенные к локальной сети

Рисунок 4.4.11.5. Маршрутизаторы, подключенные к локальной сети

Рассмотрим трафик на пути А-Н. Допустим на основании анализа состояния канал выбран путь через узел Е. В этом случае он может оказаться перегружен, что приведет к большим задаржкам пакетов на пути А-Н. Последующий анализ ситуации может привести к тому, что более оптимальным может оказаться маршрут через узел F. Если будет принято решение переключить трафик на маршрут ACFH, может перегрузиться участок АСF и история повторится. Данный сценарий описывает типичную ситуацию с осцилляциями маршрута. Осцилляции маршрутов не так безобидны, как это может показаться. Маршрутные таблицы в маршрутизаторах актуализуются вдоль пути с заметными задержками и отнюдь не синхронно. Такие осцилляции могут в разы понизить пропускную способность сети, что необходимо учитывать, выбирая параметры протоколов маршрутизации.

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

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

стационарные, работающие всегда на своем постоянном месте в локальной сети

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

подвижные, перемещающиеся в пространстве и желающие работать в процессе перемещения.

Предполагается, что все эти пользователи имеют свою постоянную приписку к какой-то сети и соответствующий постоянный IP-адрес. (см. RFC-2794 "Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000). На Рисунок 4.4.11.6 показана схема подключения подвижных пользователей к Интернет. В этой схеме предполагается наличие в каждой области сети Интернет внешнего агента, обеспечивающего доступ к этой зоне подвижных ЭВМ (на рисунке такой агент помечен надписью "чужая LAN"). Доступ может осуществляться через мобильную телефонную сеть. Предполагается также наличие соответствующего агента в "домашней" LAN, куда стационарно приписана данная ЭВМ. Домашний агент отслеживает все перемещения своих пользователей, в том числе и тех, кто подключается к "чужим" LAN.

Некоторые другие процедуры Интернет

4.5.16 Некоторые другие процедуры Интернет

NFS

NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д.

Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (

Независимые резервирования

Рисунок 4.4.9.6.7. Независимые резервирования

Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io.

8. Аннулирование (Teardown)

Сообщения RSVP "аннулирование" удаляет проход или состояние резервирования. Хотя прямое уничтожение старого резервирования не является обязательным, оно настоятельно рекомендуется, так как ускоряет переходные процессы в сети.

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

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

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

Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра.
Например, в случае, показанном на Рисунок 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

9. Ошибки

Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.

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

Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0. Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.

Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняется даже в случае не прохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю, установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.



Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, "состояние блокады", в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным.

Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако, эти резервирования были сохранены по следующим причинам:

Имеется две возможные причины получателю настаивать на резервировании:

Заказываемый ресурс доступен по всей длине пути, или

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

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

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

10. Подтверждение

Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее.


Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос.

Этот механизм подтверждения имеет следующую последовательность:

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

Получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и он может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.

11. Управление политикой

Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Такого рода обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя.

Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно.


Различные административные домены в Интернет могут иметь разные политики резервирования.

На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.

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

12. Безопасность

При использовании протокола RSVP возникают определенные проблемы безопасности.

Целостность сообщений и аутентификация узлов

Повреждение или фальсификация запросов резервирования может привести к получению услуг неавторизованными пользователями или к отказам в услугах. RSVP осуществляет защиту против таких атак с помощью механизма аутентификации, действующего в каждом из узлов и использующего шифрование с применением хэш-функций. Механизм поддерживается объектами INTEGRITY, которые могут быть включены в любое сообщение RSVP. Эти объекты используют технику криптографических дайджестов, которая предполагает, что соседи RSVP совместно владеют секретом шифрования (см. [Baker96]).

Аутентификация пользователя

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



Безопасные потоки данных

Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя.

Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207].

13. Области, не поддерживающие RSVP

Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP вероятно никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако, если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг реального времени.

Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие RSVP так и не поддерживающие RSVP маршрутизаторы переадресуют сообщения Path в соответствие с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему RSVP-маршрутизатору на пути к отправителю.

Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP' и передает его механизму управления трафиком.


Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210].

При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.

14. Модель ЭВМ

Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

Объекты as-set

Рисунок .10. Объекты as-set.

Атрибут mbrs-by-ref представляет собой список имен администраторов (maintainer) или ключевое слово ANY. Если используется этот атрибут, набор AS включает также автономные системы, чьи объекты aut-num зарегистрированы одним из этих администраторов и чей атрибут member-of относится к имени этого набора AS. Если значение атрибута mbrs-by-ref равно ANY, любой объект AS, относящийся к набору, является членом этого набора. Если атрибут mbrs-by-ref пропущен, только AS, перечисленные в атрибуте members, являются членами набора.

as-set: as-foo

members: AS1, AS2

mbrs-by-ref: MNTR-ME

Рисунок .11. Объекты as-set.

На Рисунок .11 представлен пример объекта as-set, который использует атрибут mbrs-by-ref. Набор set as-foo

содержит AS1, AS2 и AS3. AS4 не является членом набора as-foo не смотря на то, что объект aut-num ссылается на as-foo. Это происходит потому, что MNTR-OTHER отсутствует в списке атрибута as-foo mbrs-by-ref.

5.2. Класс route-set

Атрибуты класса route-set показаны на Рисунок .12. Атрибут route-set определяет имя набора. Он является именем RPSL, которое начинается с "rs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список адресных префиксов или других имен route-set. Заметим, что, класс route-set является набором префиксов маршрутов, а не маршрутных объектов RPSL.

Объекты filter-set

Рисунок .17. Объекты filter-set.

Атрибут filter определяет фильтр политики для данного набора. Фильтр политики является логическим выражением, которое в случае приложения к набору маршрутов в качестве результата возвращает субнабор этих маршрутов. Считается, что фильтр политики соответствует возвращенному субнабору. Фильтр политики может соответствовать маршрутам, использующим любой атрибут BGP-прохода, такой как адресный префикс места назначения (или NLRI), AS-path, или атрибуты community.

Фильтры политики могут составляться путем использования операторов AND, OR и NOT. Ниже представленные фильтры политики могут использоваться для селекции субнабора маршрутов:

{ 0.0.0.0/0 }

{ 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }

{ }

За адресным префиксом может опционно следовать оператор диапазона (то есть

{ 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }

содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 128.9.0.0/16, исключая 128.9.0.0/16, все префиксы больше 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16, и все префиксы больше 30.0.0.0/8, которые имеют длину в диапазоне 24 – 32, такие как 30.9.9.96/28.

aut-num: AS1

import: from AS2 accept AS2

import: from AS2 accept AS-FOO

import: from AS2 accept RS-FOO

Ключевое слово PeerAS может использоваться вместо номера AS партнера. PeerAS является особенно полезным, когда партнерство охарактеризовано с помощью AS-выражения.
Например:

as-set: AS-FOO

members: AS2, AS3

aut-num: AS1

import: from AS-FOO accept PeerAS

то же самое, что и:

aut-num: AS1

import: from AS2 accept AS2

import: from AS3 accept AS3

За именем набора маршрутов может также следовать один из операторов '^-', '^+', например, { 5.0.0.0/8, 6.0.0.0/8 }^+ эквивалентно { 5.0.0.0/8^+, 6.0.0.0/8^+ } и AS1^- эквивалентно всем адресным префиксам, соответствующим маршрутам, исходящим из AS1.



Регулярные выражения для проходов AS.

Регулярное выражение AS-path может использоваться в качестве фильтра политики путем заключения его в угловые скобки `'. Фильтр политики AS-path соответствует набору маршрутов, который проходит через последовательность AS, которая согласуется с регулярным выражением AS-path. Маршрутизатор может проверить это, используя атрибут AS_PATH в протоколе BGP [19], или атрибут RD_PATH в протоколе IDRP [18].

Регулярное выражение формируется следующим образом:

Объекты inet-rtr

Рисунок .36. Объекты inet-rtr

Каждый атрибут peer, если он имеется, специфицирует протокольный пиринг с другим маршрутизатором. Значение атрибута peer имеет следующий синтаксис:

где <protocol> - имя протокола, <ipv4-address> - IP-адрес маршрутизатора партнера, а <options> - список опций пиринга для <protocol>. Элементы списка разделяются запятыми. Вместо IP-адресов партнеров, может использоваться его inet-rtr-name. Допустимые имена протоколов и атрибуты определены в словаре (см. раздел 7). В выше приведенном примере, маршрутизатор имеет BGP-пиринг с маршрутизатором 192.87.45.195 в AS3334. Он включает подавление осцилляций маршрута, когда импортирует маршруты из этого маршрутизатора.

Вместо одиночного партнера с помощью форм <rtr-set-name> и <peering-set-name> может быть специфицирована группа партнеров. Если использована форма <peering-set- name>, то включаются только пиринги из соответствующего набора данного маршрутизатора. На Рисунок .37 показан пример объекта inet-rtr с пиринг-группами.

rtr-set: rtrs-ibgp-peers

members: 1.1.1.1, 2.2.2.2, 3.3.3.3

peering-set: prng-ebgp-peers

peering: AS3334 192.87.45.195

peering: AS3335 192.87.45.196

inet-rtr: Amsterdam.ripe.net

alias: amsterdam1.ripe.net

local-as: AS3333

ifaddr: 192.87.45.190 masklen 24

ifaddr: 192.87.4.28 masklen 24

ifaddr: 193.0.0.222 masklen 27

ifaddr: 193.0.0.158 masklen 27

peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()

peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()

Объекты route-set

Рисунок .13. Объекты route-set

route-set: rs-bar

members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+

содержат все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 30.0.0.0/8, чья длина лежит в пределах 24 – 32, такие как 30.9.9.96/28, и все префиксы больше префиксов из маршрутного набора rs-foo.

Атрибут mbrs-by-ref представляет собой список имен администраторов и может содержать ключевое слово ANY. Если используется этот атрибут, маршрутный набор включает также префиксы, чьи маршрутные объекты зарегистрированы одним из администраторов, и чей атрибут member-of указывает на имя этого маршрутного набора. Если значение атрибута mbrs-by-ref равно ANY, любой объект, связанный с именем маршрутного набора, является его членом. Если атрибут mbrs-by-ref отсутствует, только адресные префиксы, перечисленные в атрибуте members, являются членами этого набора.

route-set: rs-foo

mbrs-by-ref: MNTR-ME, MNTR-YOU

route-set: rs-bar

members: 128.7.0.0/16

mbrs-by-ref: MNTR-YOU

route: 128.9.0.0/16

origin: AS1

member-of: rs-foo

mnt-by: MNTR-ME

route: 128.8.0.0/16

origin: AS2

member-of: rs-foo, rs-bar

mnt-by: MNTR-YOU

Рисунок .14. Объекты route-set.

На Рисунок 14 представлен пример объектов route-set, которые используют атрибут mbrs-by-ref. Набор rs-foo содержит два адресных префикса, в частности 128.8.0.0/16 и 128.9.0.0/16, так как маршрутные объекты для 128.8.0.0/16 и 128.9.0.0/16 отнесены к набору имен rs-foo в их атрибуте member-of. Набор rs-bar содержит адресные префиксы 128.7.0.0/16 и 128.8.0.0/16. Маршрут 128.7.0.0/16 представлен явно в атрибуте members rs-bar, а маршрутный объект для 128.8.0.0/16 связан с именем набора rs-bar в атрибуте member-of. Заметим, что если адресный префикс представлен в атрибуте маршрутного набора members, он является членом этого маршрутного набора. Маршрутный объект, соответствующий этому адресному префиксу не должен содержать атрибут member-of, относящийся к имени этого набора. Атрибут маршрутного класса member-of является дополнительным механизмом для косвенной спецификации членов набора.

5.3. Объекты предопределенных наборов

В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на Рисунок .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO.

route-set: rs-special

members: 128.9.0.0/16, AS1, AS2, AS-FOO

Объекты rtr-set

Рисунок .19. Объекты rtr-set.

Атрибут mbrs-by-ref содержит список имен администраторов (maintainer) или ключевое слово ANY. Если использован этот атрибут, набор маршрутизаторов включает также маршрутизаторы, чьи объекты inet-rtr зарегистрированы одним из этих администраторов и чей атрибут member-of согласуется с именем этого набора маршрутизаторов. Если значение атрибута mbrs-by-ref равно ANY, любой объект inet-rtr соотносящийся набору маршрутизаторов, является членом этого набора. Если атрибут mbrs-by-ref отсутствует, только маршрутизаторы перечисленные в атрибуте members, являются членами набора.

rtr-set: rtrs-foo

members: rtr1.isp.net, rtr2.isp.net

mbrs-by-ref: MNTR-ME

inet-rtr: rtr3.isp.net

local-as: as1

ifaddr: 1.1.1.1 masklen 30

member-of: rtrs-foo

mnt-by: MNTR-ME

Рисунок .20. Объекты rtr-set.

На Рисунок 20 представлен пример объекта rtr-set, который использует атрибут mbrs-by-ref. Набор rtrs-foo содержит rtr1.isp.net, rtr2.isp.net и rtr3.isp.net.

5.6. Партнерство и класс peering-set

Атрибуты класса peering-set представлены на Рисунок .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".

Объекты SCOPE при резервировании в стиле WF

Рисунок 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF

Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:

Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, соответствующего состоянию резервирования или сообщению, которое вызвало ошибку.

Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.

28. Состояние блокады

Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии "состояния блокады", возникшего из-за сообщений ResvErr при решении проблемы KR-II.

Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады (Qb(S),Tb(S)), где S - отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше чем Qi.
Например, предположим, что LUB ( least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты j, Qb[j] ? Qi[j].

Предположим, что узел получает сообщение ResvErr от предыдущего узла P (или, если стиль выбора отправителя S является явным) в результате ошибки доступа. Тогда:

Для P (или S) создается элемент состояния блокады, если он не существует.

Qb(P) (или Qb(S)) делается равным flowspec Qe из сообщения ResvErr.

Запускается (или перезапускается) соответствующий таймер блокады Tb(P) (или Tb(S)) на время Kb*R. Здесь Kb является фиксированным множителем, а R равно интервалу времени обновления состояния резервирования. Kb можно варьировать.

Если имеется локальное состояние резервирования, которое не заблокировано, немедленно генерируется обновление резервирования для P (или S).

Сообщение ResvErr переадресуется последующим узлам. Если бит InPlace=0, сообщение ResvErr направляется всем последующим узлам, где имеется состояние резервирования. Если бит InPlace=1, сообщение ResvErr направляется только следующим узлам, чьи Qi блокированы спецификацией Qb.

В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

Если имеются какие-либо локальные запросы резервирования Qi, которые не заблокированы, они объединяются путем вычисления их LUB. Заблокированные резервирования игнорируются. Это позволяет требовать меньшее резервирование, которое имеет шанс на успех, после того как большее резервирование не удалось.

В противоположном случае (все локальные запросы Qi блокированы), они объединяются путем взятия GLB (Greatest Lower Bound) спецификаций Qi.

Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

На Рисунок 4.4.9.6.11 приведен пример использования состояния блокады для совместного резервирования (стиль WF).Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b).

Операторы

Рисунок .25. Операторы

Атрибут rp-attribute может иметь много методов, определенных для него. Некоторые из методов могут даже иметь то же самое имя, в этом случае их аргументы должны относиться к другому типу. Если список аргументов завершается "...", метод может воспринять переменное число аргументов. В этом случае, действительные аргументы после N-го аргумента имеют тип <type-N>.

Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на Рисунок .26.

Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

Этот сервер официально зарегистрирован на Rambler лишь в марте 2002 года, но существует он уже с конца 1999 года. Отклики интересны, прежде всего, тем, что они написаны по инициативе отправителя. Я полагаю, что многие из читателей время от времени просматривают самые разные сайты в Интернет. Но вряд ли многие пишут на них отклики...

Я сознательно исключил переписку, возникавшую в связи с присланными запросами. Не все отклики попали в перечень (я получаю большой объем СПАМа и часто слишком поспешно уничтожаю сообщения от незнакомых лиц). Признаюсь, я не всегда отвечаю на приходящие письма, так как их число превышает 50 в день… География откликов довольно широка (Владивосток, Новосибирск, Иркутск, С-Петербург, Ижевск, Саратов, Ноябрьск, Луганск, Тихорецк, Киев, Эстония, США, Болгария и, конечно же, Москва). В основном они положительны (может быть отчасти потому, что авторы о чем-то просят J). Но был один явно отрицательный отклик, он также включен в перечень. Было несколько запросов относительно off-line версии сервера. Отвечая на них, скажу, что я планирую изготовить CD-версию сервера, но дело это хлопотное и экономически совершенно нерациональное. Обычно в такой версии нуждаются люди с плохим доступом к Интернет (как правило не москвичи), себестоимость такого CD около 2$, плюс цена пересылки, назначить цену, которая бы компенсировала трудозатраты я не могу, да и люди не смогут ее заплатить, а рассылать диски с убытком не позволяет моя зарплата.

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

From: Andrey Cherezov andrey@cherezov.koenig.su

To: semenov@ns.itep.ru

Subject: О ваших Книгах

Date: 2 августа 1998 г. 22:15

Добрый день!

Неужели Вы тот самый Ю.А.Семенов, который книгу о Форте написал?! J

Очень рад, что теперь можно с вами поговорить!

Всего наилучшего, Андрей Черезов http://www.enet.ru/win/cherezov/

Date: Sat, 27 Mar 1999 20:38:37

Уважаемый господин Cеменов!

Oглавление, перечисляющее разделы вашего сайта "Cети Интернет", просто потрясающее. Но по каким-то причинам Я не могу открыть большинство страниц. Если они (страницы :-) уже созданы, то хотелось бы, чтоб проблемы, связанные с этим (причинами :-( , поскорее были преодолены.

C уважением,

Bаш потенциальный постоянный посетитель

Aлександр <lommoff@yahoo.com>

Date: Mon, 6 Mar 2000 03:56:49

Восхищен и поражен Вашим сайтом Telecommunication technologies - телекоммуникационные технологии. Творческих успехов и всего хорошего.

Egor Kobylkin egork@iname.com http://i.am/egork

Date: Thu, 1 Jun 2000 13:47:11

Уважаемый Юрий Алексеевич!

С удовольствием прочитал в Интернет Вашу книгу "Сети Интернет..." Благодарю за бесплатное размещение этой очень полезной книги в сети. Пользуясь случаем, прошу оказать помощь в приобретении полного текста. Рекомендаций МСЭ-Т G.703 (Копия, оригинал или адрес в сети). Посоветуйте где это можно найти.

С уважением

Ведущий специалист ЗАО"АКОС" (Сотовая связь. г. Владивосток)

Сергей Гречуха

мой адрес: sgrechuha@akos.ru

Date: Wed, 14 Jun 2000 16:25:45

Добрый день, Юрий Алексеевич.

Я студент МФТИ ФРТК 4-й курс, пишу вам по поводу вашей книги Телекоммуникационные Технологии (http://book.itep.ru). В данный момент занимаюсь моделированием локальных сетей на языке GPSS/PC. В частности, моделирую Ethernet 802.3 коллизийный домен. Я нашел некоторые неоднозначности в разной литературе описывающие протокол CSMA/CD.

И хотел бы у вас утонить правильность моих рассуждений, так как при моделировании данной сети, у меня получается, что одна станция (по крайней мере из 3-х станций в сети) захватывает весь эфир и не дает возможность передавать другим. Как работает CSMA/CD, я понимаю так:

1. Станция все время прослушивает среду (шину). Если среда свободна (освободилась), то ждет interframe gap

(межкадровый интервал), равный 9,6 мкс (в это время все равно слушает среду). Если в течение этих 9,6 мкс никто не захватил шину, то начинает передавать (шаг 2.). Если кто-то захватил шину в течение этого времени, то возвращается к шагу 1.

2. При передачи, станция все время слушает среду. Если обнаруживает коллизию, то посылает сигнал коллизии 32 BT = 3.2 мкс. И вычисляет задержку по формуле (51,2*(RAND [0,(2^m-1)]), где m = min (к,10), а к - число коллизий, при передачи данного кадра. То есть, если к=1, то возможная задержка (0, 51.2) если к=2, то возможная задержка (0, 51.2, 102.4, 52428.8), и т.д. После ожидания вычисленной задержки, возвращается к шагу 1. Если к=16, станция отказывается отправлять кадры. (Кстати, у Вас задержка вычисляется по формуле (51,2*(RAND [0,(2^m)]))

3.Если коллизии не было, то завершает передачу. Устанавливает к = 0. Возвращается к шагу 1. Я моделирую насыщенный режим работы сегмента и почему-то одна станция захватывает весь эфир. Модель работает к предписано алгоритмом выше. Попробовал аналитически рассмотреть работу >CSMA/CD. Допустим все станции (3 штуки) захотели передавать в одно и тоже время, определив, что шина свободна. Обнаружится коллизия, все станции идут в задержку. прибавляя к 'К' единицу. Далее, кто первее освободился (если задержка 0, то сразу идет к шагу 1), тот начал передачу. Во время передачи этой станции освобождаются, другие станции из коллизийной задержки. Соответственно ждут, пока освободит шину передающая станция (шаг 1). Как только эта станция освобождает шину, она идет в шаг 1. (причем 'к' сбрасывает в нуль) на ровне с другими станциями. Ждут 96 ВТ = 9.6 мкс межкадрового времени, начинают передавать. Опять образуется коллизия. У первой станции 'к' будет равно единицы, а у других 'к'=2. Это говорит о том, что вероятность получить меньшую задержки у первой станции больше чем у других. (у меня так и происходит). станция с к=1 выбирает меньшую задержку, чем другие. Ждет и идет передавать. Далее все идет по циклу, у первой станции 'к' то обнуляется, то равно 1, у других станций 'к' растет, соответственно, вероятность получить большую задержку тоже растет. Я моделировал передачу кадров минимальной длины, что уж говорить о кадров максим. длины 1526КВ. Ситуация на мой взгляд еще больше усугубится. Юрий Алексеевич, подскажите, может быть я не правильно понял алгоритм? Он несколько отличается от Вашего (http://book.itep.ru/4/41/Eth_4111.htm), но мне кажется не принципиально.

Всего доброго, Рябенко Максим maxy@rt.mipt.ru

Date: Wed, 12 Jul 2000 16:45:27

Уважаемый Юрий Алексеевич

В своей книге "Сети Интернет. Архитектура и протоколы", Вы пишите о том, что Вы написали собственную программу для анализа сетевого трафика, и в частности эта программа анализирует содержимое MIB. Меня интересует такой вопрос: как в Вашей программе реализован поиск SNMP-агентов, и можно ли организовать его автоматически?

С уважением, Юрий Чашков. chashkov@mail.ru

Date: Fri, 4 Aug 2000 15:32:33

Здравствуйте.

В Вашей книге (http://book.itep.ru/7/Prog_72.htm)

читаю:

"...(см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi)..." Не могли бы Вы уточнить, действительно ли существует описание 8390 в Интернете и как его выловить? (очень надо для отладки драйвера под RTEMS)

Спасибо.

Sincerely, Dmitry Kargapolov, ICQ 54000305, dk@gentex.ru

Date: Tue, 15 Aug 2000 05:16:31

Доброго времени суток Юрий Алексеевич.

Попал на Ваш сайт, и был приятно удивлен количеству полезной информации. Но к сожалению, я не имею постоянной возможности работы в Интернете. И меня интересует, такая возможность, как получить Ваш сайт в виде архива. Для ЛИЧНОГО использования. По некоторым статьям я считаю, что мог бы несколько дополнить их. Но, к сожалению, по причине описанной выше не могу внимательно ознакомится с теми разделами, в которых у меня имеется богатый практический опыт. Рад буду, если Вы откликнитесь на мою просьбу. А также надеюсь на плодотворное сотрудничество.

Заранее спасибо.

С уважением Алексей Алексеевич. mailto:wwfnet@mail.ru

Date: Thu, 31 Aug 2000 12:49:28

Уважаемый Юрий Алексеевич!

Сердечно благодарю Вас за отклик на нашу просьбу. Надеюсь, что Вы сможете, что-нибудь придумать. Информацию о сфере нашей деятельности, заказчиках и др. Вы сможете посмотреть на нашем сайте. Очень горжусь, пусть телефонным, знакомством с Вами и надеюсь, что смогу быть Вам полезным. С Уважением и наилучшими пожеланиями, исполнительный директор НПФ Беркут

Кельганкин Олег

ook@bercut.spb.ru

www.bercut.ru

т/ф (812) 271-48-98

т/ф (812) 274-70-59

т/ф (812) 275-44-91

Россия, Санкт-Петербург, Моисеенко 43.

Date: Thu, 31 Aug 2000 13:48:14

Здравствуйте Юpий Алексеевич!

Ну для начала я представлюсь. Корнилов Игорь Геннадьевич, 25 лет. Работаю ставшим преподавателем на кафедре ВТ ИжГТУ (Ижевский гос. тех. университет). С прошлого года я читаю курсы по корпоративным сетям и Интернету. В подготовке к лекциям в прошлом году мне сильно помогала Ваша книга "Протоколы и ресурсы INTERNET". Позже я стал пользоваться сервером book.itep.ru. Замечательный, полезный сервер! Спасибо Вам огромное>! Но у нас есть одна проблема! Канал через который подключен к инету наш университет не отличается высокой скоростью и надежностью. :( А я бы хотел, чтоб ресурсами вашего сервера могли свободно пользоваться наши студенты. И в связи с этим вопрос: можно ли разместить зеркало вашего сервера на сервере нашей кафедры?

С уважением, Корнилов Игорь. eggog@vao.udmnet.ru

Date: Mon, 04 Sep 2000 10:59:47

Добpый день, Юpий Алексеевич

Зеркало уже почти готово! Скоро я его размещу на нашем сервере zuko.istu.udm.ru. У меня уже есть старая копия, которой я пользовался. Hо из миpа в настоящее время его видно не будет (проблемы с внешними каналами :((( Как только появится возможность доступа к нам из вне я Вам сообщу дополнительно. И вот тут еще. Меня заинтересовало ваше сообщении о новой книге, хотелось бы уточнить, когда она выходит и как ее можно будет заказать (а то тут у нас сложно с ХОРОШЕЙ литературой в магазинах :))) )? eggog@vao.udmnet.ru

С уважением? Игорь Корнилов.

Date: Mon, 4 Sep 2000 18:34:03

Здравствуйте, Юрий Алексеевич!

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

Спасибо Вам за то, что Вы делаете!

С уважением, Артем Глазунов, специалист Иркутского областного телеграфа.

e-mail: gav@irtel.ru

From: "Lex" <3694_KAN@nw.ie.tasur.edu.ru>

Organization: Industrial Electronics of TASCR

To: <semenov@itep.ru>

Date: Mon, 2 Oct 2000 19:40:23

В вашей книге "Протоколы Интернет" описан обработчик приема пакетов для пакетных драйверов receiver - он описан как процедура near а как сделать чтобы этот обработчик обращался к данным прикладной программы, например вставка в receiver строк типа

mov> ah,09h

lea dx,string

int 21h

Где string описана в данных прикладной программы приводит к выводу всякой ваты на экран и зависанию компа при обращении драйвера к receiverу причем $ на конце stringa не забыл указать и относительно другого сегмента пробовал (com программа) cs:[string] все равно Вы моя последняя надежда...

Date: Wed, 01 Nov 2000 11:53:59

Subject: Огромное СПАСИБО за то, что Вы есть!

У меня к Вам убедительная просьба отправить мне ответы на закрепляющие вопросы к теме "Каналы передачи данных" (http://book.itep.ru/) Я хотел бы проверить свои знания в этой области.

С уважением, Колот Сергей <kolot@mail.ru>

Date: Mon, 18 Dec 2000 00:49:29

Глубокоуважаемый Юрий Алексеевич!

Я хотел бы попросить Вас исправить русскоязычное написание имени и фамилии Michael Burrows'a -- одного из авторов WBT ("Burrows-Wheeler Transformation", also known as " Block Sorting"); его зовут Майкл Барроуз. Так получилось, что я работал в Великобритании и знаком с ним.

Спасибо, Андрей Кадач akadatch@microsoft.com

Здравствуйте,

Позвольте поблагодарить Вас, за тот труд, который Вы вложили в создание http://book.itep.ru/, он помог мне заполнить те пробелы в моих знаниях, которые долгое время не давали мне покоя. Спасибо.

Вы пишите:

> Во-первых, ограниченность времени и жанр лекций не позволяют разместить полные

> описания протоколов (конспективность здесь неизбежна) и представить необходимые

> справочные материалы...

Не могли бы Вы подсказать, где можно найти более полную информацию, касающуюся вопросов моделирования и оптимизации сетей. Заранее благодарен.

Kirill V. Krinkin

mailto:krinkin@mailru.com

Brainbench Public Transcript: 173921,

http://www.brainbench.com/transcript.jsp?pid=173921

7 января 2001 г.

Date: Mon, 05 Feb 2001 16:44:31

Здравствуйте. Пишет вам Константин из города Луганска. Я ищу описание дельта кодака. К сожалению я не знаю его точного названия, но знаю что в данном протоколе используется метод адаптивной дельта модуляции, частота передачи 32 Кбит/сек, и на одну линию подсоединяется 8 цифровых т/а. Если описание подобного протокола в вашей книге?

e_mail: kos_k@inbox.ru

Thu, 15 Feb 2001 22:31:43

From: "I. F." <code@dir.bg>

To: <semenov@itep.ru>

Date: Thu, 15 Feb 2001 21:33:47

bravo bravo good book:

about <http://book.itep.ru/1/intro1.htm>

Date: Thu, 22 Feb 2001 17:40:26

Здравствуйте!

Я хотел бы узнать, где можно найти вашу книгу "Telecommunication technologies - телекоммуникационные технологии” в электронном виде.

Алексей В. Майоров МФТИ ФПМЭ. lexa@megasoft.ru

Date: Mon, 12 Mar 2001 18:25:34

Уважаемый Юрий Алексеевич, меня очень понравился сайт (<http://book.itep.ru/>)с вашими книгами. Я осваиваю программирование под Windows, с уклоном в сетевые технологии, и столкнулся с тем, что в Инете очень мало информации по этой теме, на русском языке, поэтому приходилось искать на буржуйских сайтах, но в силу слабости моих познаний английского, меня этот путь не совсем устраивает, и сегодня блуждая по поисковикам наткнулся на вашу главу , посвященную Сокетам, мне она очень понравилась, благодаря своему подробному описанию данного вопроса. Затем посмотрел на оглавление, мне понравилось еще больше, показал друзьям - программистам - они тоже оценили. По моему мнению, это лучшая книга по обработке информации, и сетевым технологиям (по крайней мере среди русскоязычных). Выражаю Вам огромную признательность от своего имени за проделанную колоссальную работу в области развития информационных технологий среди начинающих программистов(и профессиональных также):).

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

С уважением, Вячеслав Потапов, студент МИСиС. VPotapov@estra.ru

Date: Wed, 28 Mar 2001 14:52:42 +0400

From: "maks" <imv@ghost.dn.ua>

Пишет вам студентка Украинской Государственной Академии связи, мой преподаватель выдал мне диплом на тему "видеотелеконференции – как услуга центра документальной электросвязи ", сославшись на то что поискать информацию по этой теме можно в ваших книгах. Причем, какие конкретно книги он мне не сказал. Если вас не затруднит, напишите пожалуйста по этому адресу, какие книги на интересующую меня тему вы написали. Или, если можно и есть публикации в Интернете скиньте пару ссылок на них.

заранее благодарна!

Best regards,

Марина mailto:imv@ghost.dn.ua

From: "Digitman" <digitman@dax.ru>

To: <semenov@itep.ru>

Date: Tue, 3 Apr 2001 13:01:37

Добрый день, ув. Ю.А.!

From: "profy.ru" <info@profy.ru>

To: semenov@itep.ru

Уважаемые господа!

Разрешите предложить Вашему вниманию для возможного размещения в разделе ссылок Вашего сайта наш Интернет-проект "Мир Профессионалов"- www.profy.ru . Это универсальный кадровый сервер, с которым сотрудничают и размещают свои вакансии более 1500 компаний и кадровых агентств. Все размещаемые вакансии модерируются, то есть исключены вакансии от недобросовестных работодателей. Надеемся, ссылка на www.profy.ru окажется интересной для Ваших посетителей. Кнопку сайта можно выбрать здесь - http://moscow.profy.ru/linktoprofy.phtml

С наилучшими пожеланиями,

Владимир Ершов,

менеджер проекта

www.profy.ru

Date: Fri, 19 Oct 2001 02:34:33

Здравствуйте, Юрий Алексеевич.

Спасибо Вам за Вашу электронную книгу по сетям. Впечатляет. Имеется ли что-нибудь по программированию, по дискретной и вычислительной математикам.

С уважением

Александр Суворов

Best regards,

Здравствуйте господин Семенов !

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

solid82@rambler.ru

Бесплатная почта http://mail.Rambler.ru/

Здравствуйте Юрий Алексеевич,

Недавно наткнулся на ?кусочки? ваших электронных лекций у одного из своего знакомых. Очень заинтересовался вашим материалом, но к сожалению, ваших книжек в продаже не нашел. Если вас не затруднит, пожалуйста, напишите, где можно заказать или пробрести вашу литературу, CD (если он вышел) и вышли ли ваши новые труды после ?Протоколы и ресурсы Интернет? (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы? (Сиринъ, М. 1998).

Заранее благодарен,

с уважением, студент 4-го курса СПбГТУ

Бесплатная почта http://mail.Rambler.ru/

Date: Wed, 29 May 2002 13:03:21

Уважаемый Юрий Алексеевич!

Большое спасибо за вашу работу, результатами которой очень приятно пользоваться (а главное с пользой). На сервере представлено очень много информации, но доступ к ней удобен только для тех, кто имеет постоянный доступ в сеть. Не планируете ли вы выкладывать для скачивания оффлайновую версию сайта? george@comtv.ru

From: "Eugene Rybakov" <rybakov@bhv.ru>

To: <semenov@itep.ru>

Date: Thu, 11 Apr 2002 13:07:37

..Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".

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

Уважаемый Юрий Алексеевич!

Если Вы не разочаровались окончательно в технике книжных издательств, прошу обратить внимание на возможность издания очередной книги в "BHV-Петербург". Тематика нас весьма интересует.

Рассмотрим встречные предложения.