RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

Network Working Working Group                                  R. Callon
Request for Comments: 1195                 Digital Equipment Corporation
                                                           December 1990

Использование протокола OSI IS-IS для маршрутизации TCP/IP и в средах с двумя протоколами

Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

PDF

Статус документа

Этот документ задает протокол IAB Standards Track для сообщества Internet и служит приглашением к дискуссии в целях развития протокола. Текущее состояние стандартизации протокола можно узнать из документа «IAB Official Protocol Standards». Документ может распространяться без ограничений.

Данный RFC доступен в текстовом формате и в версии postscript. По возможности рекомендуется использовать вариант postscript. Например, данная текстовая версия может содержать менее информативные рисунки.

Аннотация

Этот документ содержит спецификацию интегрированного протокола маршрутизации, основанного на протоколе внутридоменной маршрутизации OSI IS-IS1, который может применяться в качестве протокола внутренней маршрутизации (IGP2) для сетей на базе протоколов TCP/IP и OSI. Это позволяет использовать один протокол маршрутизации для «чистых» сетей IP и OSI, а также в смешанных средах. Спецификация было подготовлена рабочей группой IETF3 IS-IS.

Протокол OSI IS-IS находится в зрелом состоянии и готов для реализации и применения в продуктивных сетях. Наиболее свежая версия протокола OSI IS-IS описана в стандарте ISO DP 10589 [1]. Предложенный здесь стандарт использования IS-IS для поддержки TCP/IP основан не этой версии (с исправлением незначительных ошибок, как описано в Приложении B). Предполагается, что будущие версии предложенного стандарта будут отражены в версии международного стандарта IS-IS.

Комментарии к документу следует направлять по адресу isis@merit.edu.

1 Введение – обзор протокола

Важность стека протоколов TCP/IP в коммуникационной архитектуре с оборудованием разных производителей возрастает. С учетом ожидаемого появления стека протоколов OSI сосуществование TCP/IP и OSI будет достаточно долгим. Поэтому для маршрутизаторов возникает необходимость одновременной поддержки трафика IP и OSI.

Существует два основных метода поддержки протоколов OSI и IP в маршрутизаторах. В одном из методов, названном «Ships in the Night» (корабли в ночи), используются полностью независимые протоколы маршрутизации для каждого из двух стеков. Данная спецификация представляет другой метод, в котором используется один интегрированный протокол внутренней маршрутизации (т. е. расчета маршрутов в одном домене маршрутизации) для обоих стеков.

Устройство интегрированного протокола основано на протоколе внутридоменной маршрутизации OSI IS-IS [1] с добавлением функций, связанных с IP. Данный документ следует рассматривать вместе со спецификацией маршрутизации OSI IS-IS и в нем описаны лишь требуемые дополнительные функции.

За счет поддержки трафика IP и OSI объединенный протокол поддерживает трафик для хостов IP, конечных систем OSI, а также конечных систем с двумя стеками протоколов. Такой подход является «интегрированным» в том смысле, что протокол IS-IS может использоваться в «чистых» средах IP или OSI, а также в среде с обоими стеками протоколов. Кроме того, такой подход позволяет соединять между собой домены с двумя стеками (IP и OSI) между собой, а также с «чистыми» доменами IP или OSI.

Описанный здесь протокол основан на работе группы IETF IS-IS.

1.1 Что предлагает интегрированный IS-IS

Интегрированный протокол IS-IS обеспечивает единый протокол маршрутизации для TCP/IP и OSI. Это позволяет использовать протокол маршрутизации OSI IS-IS, дополненный связанной с IP информацией. Решение обеспечивает явную поддержку подсетей IP, маски переменного размера, маршрутизацию на основе TOS и внешнюю маршрутизацию. Обеспечивается информация для проверки подлинности, включая использование паролей и других механизмов. Точная форма механизмов аутентификации (в дополнение к паролям) выходит за рамки документа.

Пакеты OSI и IP пересылаются «как есть», т. е. передаются напрямую через службы нижележащего канального уровня без необходимости взаимной инкапсуляции. Интегрированный IS-IS является протоколом динамической маршрутизации на базе алгоритма выбора кратчайшего пути – SPF4 (Dijkstra).

Описанный протокол поддерживает произвольные комбинации маршрутизаторов IP, OSI и с двойным стеком (IP и OSI).

Маршрутизатором IS-IS IP (или маршрутизатором IP) считается устройство, которое (i) использует IS-IS в качестве протокола маршрутизации для IP в соответствии с этим документом, (ii) в остальном не поддерживает протоколы OSI. Например, такие маршрутизаторы не смогут пересылать пакеты OSI CLNP.

Маршрутизатором OSI называется устройство, которое использует IS-IS в качестве протокола маршрутизации для OSI, как указано в [1]. В общем случае маршрутизаторы OSI считаются соответствующими стандартам OSI и могут не соответствовать данной спецификации.

Маршрутизатором IS-IS для двух протоколов (двойным маршрутизатором) называется устройство, которое использует IS-IS в качестве единственного объединенного протокола маршрутизации для IP и OSI, как указано в этом документе.

Такой подход не меняет способа обработки пакетов IP. Маршрутизаторы IP и двойные маршрутизаторы должны соответствовать требованиям к шлюзам Internet [4]. Интегрированный протокол IS-IS, описанный в этом документе, является протоколом внутренней маршрутизации (IGP), который будет обеспечивать маршрутизацию внутри маршрутного домена TCP/IP (т. е. автономной системы). Другие аспекты функциональности маршрутизаторов (например, работа ICMP, ARP, EGP и т. п.) не затрагиваются этим предложением.

Точно так же этот подход не будет менять способ обработки пакетов OSI. Не будет меняться содержимое и обработка ни пакетов ISO 8473 Data и Error Report, ни ISO 9542 Redirect и ES Hello. ISO 9542 IS Hello передаваемые в ЛВС также не будут меняться, а при передаче по каналам «точка-точка» будет лишь добавляться информация IP. Аналогично, останутся неизменными другие пакеты OSI (в частности, пакеты протокола внутридоменной маршрутизации IS-IS) за исключением добавления связанной с IP информации.

Этот подход использует имеющиеся пакеты IS-IS с добавлением относящихся к IP полей. В частности, (i) во все пакеты IS-IS может добавляться аутентификационная информация, (ii) протоколы, поддерживаемые каждым маршрутизатором, а также IP-адреса маршрутизаторов указываются в пакетах ISO 9542 IS Hello, IS-IS Hello и Link State, (iii) доступные изнутри адреса IP указываются в пакетах Link State и (iv) доступные извне адреса IP и информация внешнего протокола маршрутизации может быть указана в пакетах Link State уровня 2. Кодирование и интерпретация этих данных рассмотрены в разделах 3, 4 и 5 данного RFC.

Описанный здесь протокол можно применять для маршрутизации в доменах, поддерживающих только IP, где все маршрутизаторы поддерживают только IP. Точно так же протокол можно использовать в «чистом» двойном домене, где все маршрутизаторы поддерживают два протокола. Кроме того, протокол может работать в смешанном домене, где часть маршрутизаторов поддерживает только IP, другие – только OSI, а третьи – оба протокола. Конкретные топологические ограничения для последнего случая рассмотрены в параграфе 1.4 (Поддержка доменов со смешанной маршрутизацией). Использование протокола IS-IS для «чистых» доменов OSI описано в [1].

Эта спецификация не ограничивает использование протоколов сетевого управления для маршрутизаторов IS-IS. Базы MIB5 для маршрутизаторов IP, OSI и двойных, совместимые с CMIP, CMOT и/или SNMP, описаны в [8].

1.2 Обзор протокола ISO IS-IS

Протокол маршрутизации IS-IS был разработан в ISO для маршрутизации в чистой среде OSI. В частности, IS-IS предназначен для работы с ISO 8473 (The ISO Connectionless Network Layer Protocol [2]) и ISO 9542 (The ISO End System to Intermediate System Protocol [3]). В этом параграфе кратко описан способ применения IS-IS для поддержки чистых сред OSI. Расширения для поддержки IP и двойных сред описаны ниже.

В IS-IS сеть делится на домены маршрутизации, границы которых определяются системой управления путем установки некоторых каналов как «внешних». Маршрутные сообщения IS-IS не передаются во внешние каналы.

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

Маршрутизация OSI IS-IS использует двухуровневую иерархическую модель. Домены маршрутизации делятся на области. Маршрутизаторы уровня 1 знают топологию своей области, включая все маршрутизаторы и конечные системы в ней. Однако маршрутизаторы уровня 1 не знают отождествлений маршрутизаторов или получателей за пределами своей области. Маршрутизаторы уровня 1 пересылают весь трафик для получателей за пределами своей области маршрутизатору уровня 2 в своей области. Маршрутизаторы уровня 2 знают топологию уровня 2 и адреса, достижимые через каждый маршрутизатор уровня 2. Однако им не нужно знать топологии какой-либо области уровня 1, за исключением того, что этот маршрутизатор может также служить маршрутизатором уровня 1 в одной из областей. Только маршрутизаторы уровня 2 могут обмениваться пакетами данных или маршрутной информацией напрямую с внешними маршрутизаторами, расположенными за пределами домена маршрутизации.

+----------------------+-------------------------------+
|        IDP           |              DSP              |
+----------------------+-------------------------------+
.                      .                               .
.                      .                               .
.                      .                               .
+-----+----------------+----------+--------------+-----+
| AFI |      IDI       |  HO-DSP  |      ID      | SEL |
+-----+----------------+----------+--------------+-----+

Рисунок 1. Иерархическая структура адресов ISO.

Как показано на рисунке 1, адрес ISO делится начальную часть домена (IDP6) и специфичную для домена часть (DSP7). IDP стандартизована ISO и указывает формат и организацию, отвечающую за назначение остальной части адреса. DSP назначается организацией, указанной IDP. DSP делится на старшую часть (HO-DSP8), идентификатор системы (ID) и селектор NSAP (SEL). HO-DSP может использовать любой формат, удобный для указанной IDP организации. Комбинация [IDP, HO-DSP] указывает домен маршрутизации и область внутри него, поэтому ее можно назвать адресом области.

Обычно все узлы в области имеют один адрес области, однако иногда область может иметь множество адресов. Мотивация этого описана ниже.

• Может оказаться желательной смена адреса области. Наиболее изящным вариантом замены адреса A на B является использование некоторое время обоих адресов, а после обновления всех узлов области для распознавания обоих адресов изменение каждого узла, чтобы он «забыл» адрес A.
• Может оказаться желательным слияние областей A и B в одну область. Метод решения этой задачи заключается добавление на каждом узле области B адреса зоны A и наоборот.
• Может оказаться желательным разделение области C на две области A B (при этом а A может в результате совпадать с C и это будет просто удалением части области). Это решается добавлением сначала адреса A в соответствующие узлы (которые нужно включить в зону A) и адреса B в соответствующие узлы, затем удаление информации об адресе C.

Поскольку адресация OSI явно указывает область, маршрутизаторам уровня 1 очень просто идентифицировать пакеты, направленные за пределы этой области, которые нужно пересылать маршрутизаторам уровня 2.

В IS-IS имеется два типа маршрутизаторов.

• Промежуточные системы уровня 1 маршрутизируют на основе связанной с идентификатором части адреса ISO и маршруты проходят внутри области. На основе адреса получателя в пакет эти узлы распознают, находится ли адресат внутри области. Для внутренний получателей пакеты маршрутизируются, для отсальных передаются ближайшему маршрутизатору уровня 2.
• Промежуточные системы уровня 2 маршрутизируют на основе адреса области (т. е. комбинации [IDP, HO-DSP]). Они направляют пакеты в область, независимо от внутренней структуры области. IS уровня 2 может также служить IS уровня 1 в одной области.

В маршрутизаторах уровня 1 связанная с областью часть адреса, задается вручную. Они будут отвергать попытки стать соседями для узлов, чей адрес области не перекрывается с адресом их области. Однако, если маршрутизатор уровня 1 имеет адреса областей A, B и C, а сосед – B и D, маршрутизаторы воспримут друг друга в качестве соседа.

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

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

IS-IS требует соединений между маршрутизаторами уровня 2. Если магистраль уровня 2 становится разделенной, не будет возможности воспользоваться каналами уровня 1 для восстановления раздела уровня 2.

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

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

Требуется особая трактовка для широковещательных подсетей, таких как ЛВС. Это решает две группы проблем – без особой трактовки (i) каждый маршрутизатор в подсети будет анонсировать канал к каждому другому маршрутизатору в этой подсети, что приведет к анонсированию n2 каналов, (ii) каждый маршрутизатор в ЛВС будет сообщать одинаковый список конечных систем в ЛВС, что приведет к значительному дублированию.

Эти проблемы можно устранить, применяя «псевдоузлы», которые представляют ЛВС. Каждый маршрутизатор в ЛВС сообщает а наличии у него канала к псевдоузлу (а не к каждому другому маршрутизатору в ЛВС). Один из маршрутизаторов ЛВС выбирается «назначенным» (designated router) и передает LSP от имени псевдоузла, сообщая о каналах ко всем маршрутизаторам в ЛВС. Это снижает число каналов с n2 до n. Кроме того лишь LSP псевдоузла включает список конечных систем ЛВС, что исключает ненужное дублирование (см. дополнительные сведения в [1]).

IS-IS может поддерживать маршрутизацию QOS9 с учетом пропускной способности (принятая по умолчанию метрика), задержки, стоимости или сохраняющейся вероятности ошибок. Более подробно это описано в параграфе 3.5 и [1].

1.3 Обзор интегрированного протокола IS-IS

Интегрированный протокол IS-IS позволяет использовать один протокол маршрутизации для пакетов IP и OSI. Это предполагает возможность применения одной двухуровневой иерархии для маршрутизации IP и OSI. Каждая область может быть задана как IP (маршрутизация в области лишь трафика IP), OSI (маршрутизация в области лишь трафика OSI) или смешанная (маршрутизация в области лишь трафика IP и OSI).

Это предложение не допускает частичного перекрытия областей OSI и IP. Например, если одна область поддерживает лишь OSI, а другая – только IP, недопустимо наличие некоторых маршрутизаторов в обеих областях. Для домена маршрутизации используется одна магистраль и не предусмотрено создания независимых магистралей для OSI и IP.

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

Структура адресов IP позволяет разбивать сеть на подсети, а те, в свою очередь, на более мелкие подсети. Однако нежелательно требовать какой-либо определенной связи между адресами подсетей IP и областями IS-IS. Например, во многих случаях в среде могут быть установлены маршрутизаторы с двойным стеком, которые уже имеют адреса IP и/или OSI. Кроме того, даже если адреса IP не установлены заранее, IP будет вносить ограничения на их установку. Поэтому не требуется какой-либо конкретной взаимосвязи между адресами IP и структурой области. Адреса IP могут назначаться независимо от адресов OSI и структуры области IS-IS. Как описано в параграфе 3.2 Иерархическое сокращение информации о доступности IP, можно добиться большей эффективности и расширяемости алгоритма маршрутизации при наличии некоторого соответствия между структурой назначения адресов IP и структурой области.

Внутри области маршрутизаторы уровня 1 обмениваются служебными пакетами с состоянием каналов, которые указывают адреса IP, доступные через каждый из маршрутизаторов. В частности в каждом пакете Link State могут содержаться комбинации [IP-адрес, маска подсети, метрика]. Эти комбинации вручную настраиваются на каждом маршрутизаторе уровня 1, указывая адреса, доступные через каждый интерфейс маршрутизатора. Маршрутизатор уровня 1 выполняет указанные ниже действия.

• Если адрес получателя соответствует комбинации [IP-адрес, маска подсети, метрика], доступной внутри области, пакет маршрутизируется на уровне 1.
• Если адрес получателя не соответствует ни одной комбинации [IP-адрес, маска подсети, метрика], доступной внутри области, пакет маршрутизаируется в направлении ближайшего маршрутизатора уровня ю

Гибкое использование ограниченного пространства адресов IP важно с учетом ожидаемого роста сред IP. Таким образом, область (а косвенно и домен маршрутизации) может применять одновременно множество различных масок для разных подсетей в области (или домене). Как правило при соответствии адреса получателя нескольким комбинациям [IP-адрес, маска подсети, метрика] для маршрутизации выбирается более конкретная (с большим числом 1 в маске) комбинация, которую называют «лучшим маршрутом».

Маршрутизаторы уровня 2 включают в свои LSP уровня 2 полные списки комбинаций [IP-адрес, маска подсети, метрика], указывающие все адреса IP доступные в их области. Как указано в разделе 3, эту информацию можно получит из LSP уровня 1 (полученные от маршрутизаторов уровня 1 в одной области) и/или настроить ее вручную. Кроме того, маршрутизаторы уровня 2 могут сообщать информацию о доступности внешних областей, соответствующую адресам, доступным через маршрутизаторы других доменов (автономных систем).

Принятые по умолчанию маршруты могут анонсироваться с использованием маски подсети, содержащей только нули. Эти маршруты следует применять с осторожностью, поскольку они могут приводить к возникновению «черных дыр». Таки маршруты разрешены на уровне 2 лишь в качестве внешних (т. е. включенных в поле IP External Reachability Information, как описано в разделах 3 и 5). На уровне 1 принятые по умолчанию маршруты не разрешены.

Интегрированная IS-IS поддерживает маршрутизацию по типу обслуживания (TOS10) на основе функций QOS в IS-IS.

1.4 Поддержка доменов со смешанной маршрутизацией

Предложение интегрированной IS-IS поддерживает, в частности, три типа доменов маршрутизации:

• IP;
• OSI;
• смешанный (IP и OSI одновременно).

В домене маршрутизации IP все маршрутизаторы должны поддерживать протокол IP. Возможно применение маршрутизаторов, поддерживающих только IP, и маршрутизаторов, поддерживающих оба протокола. Маршрутизаторы, поддерживающие оба протокола, могут включать некоторые поля, относящиеся к работе OSI, которые маршрутизаторы IP будут игнорировать. Трафик протокола IP будет маршрутизироваться внутри домена, поддерживающего только IP. Любой трафик OSI будет отбрасываться (за исключением пакетов IS-IS, требуемых для работы протокола маршрутизации).

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

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

В области IP смешанного домена могут произвольно перемешиваться маршрутизаторы IP и с двойным стеком. Маршрутизаторы уровня 1 в этой области могут пересылать только трафик IP.

В области OSI смешанного домена могут произвольно перемешиваться маршрутизаторы IP и с двойным стеком. Маршрутизаторы уровня 1 в этой области могут пересылать только трафик OSI.

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

Если в смешанном домене между областями маршрутизируется трафик IP и OSI, все маршрутизаторы уровня 2 должны поддерживать оба протокола.

1.5 Преимущества использования интегрированного IS-IS

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

Другой подход называется S.I.N.11 и использует изолированные протоколы маршрутизации для IP и OSI. Например, OSPF [5] может применяться для маршрутизации IP, а IS-IS [1] – для OSI. В S.I.N. два протокола маршрутизации работают более или менее независимо. Однако нужны маршрутизаторам с поддержкой двух протоколов приходится реализовать два протокола маршрутизации, между которыми может возникать конкуренция за русурсы.

Отметим, что подходы S.I.N. и интегрированного IS-IS не исключают друг друга. В частности при использовании IS-IS в домене маршрутизации для трафика IP и OSI остается возможность применения независимых протоколов маршрутизации для других протоколов.

В будущем могут быть определены необязательные расширения IS-IS для маршрутизации других протоколов общего назначения, однако этот вопрос выходит за рамки данного документа. В этом параграфе сравниваются подходы интегрированного IS-IS и S.I.N. лишь для маршрутизации IP и OSI.

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

Отметим, что работа двух протоколов маршрутизации в модели S.I.N. реально не является независимой, поскольку протоколы используют общие ресурсы. Однако в интегрированном IS-IS взаимодействие является явным, а в S.I.N. – неявным. Явное взаимодействие упрощает настройку и отладку маршрутизаторов с двойным стеком.

Другим преимуществом интегрированного IS-IS является малое потребление ресурсов за счет использования единственного протокола маршрутизации. В частности нужно меньше ресурсов для реализации (нужно реализовать лишь один протокол маршрутизации), меньше расходуются ресурсы процессора и памяти (поскольку используется лишь один протокол), а также снижается нагрузка на сеть (передаются пакеты лишь одного протокола маршрутизации). В первую очередь это снижает финансовые расходы, поскольку упомянутые ресурсы требуют финансовых затрат. Это означает, что маршрутизаторы с двумя протоколами на основе интегрированного IS-IS должны быть дешевле при покупке и эксплуатации по сравнению с маршрутизаторами на основе S.I.N.

Отметим, что работа двух протоколов маршрутизации в модели S.I.N. не является полностью независимой, поскольку они используют общие ресурсы. Например, если один протокол утрачивает стабильность и начинает использовать слишком много ресурсов, другой протокол может столкнуться с проблемами. Ошибка в одном протоколе может приводить к отказу другого. В IS-IS взаимодействия являются явными и определены на протокольном и программном уровне, тогда как в S.I.N. взаимодействия не задаются явно.

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

Протоколы маршрутизации предъявляют существенные требования к работе в реальном масштабе времени. В IS-IS эти требования заданы явно, а в других протоколах остаются неявными. Однако во всех протоколах маршрутизации есть гарантии, которые должны соблюдаться для корректной работы в реальном масштабе времени. В общем случае выполнение этих требований достаточно сложно в реализации единой системы. В S.I.N. применение двух полунезависимых протоколов, работающих в реальном масштабе времени, дополнительно осложняет ситуацию.

Отметим, что интегрированный протокол IS-IS и S.I.N. разрешают независимость внешних маршрутов (для трафика в домен машрутизации и из него), а также независимое назначение адресов OSI и TCP/IP.

2 Используемые сокращения

AA (Administrative Authority) – административный орган

Трехоктетное поле в формате адреса NSAP версии GOSIP 2.0.

AFI (Authority and Format Identifier) – идентификатор формата

Первый октет адреса OSI NSAP, указывающий формат осталной части адреса.

CLNP (Connection-Less Network Protocol) – протокол CLNP

Протокол ISO 8473 в сети OSI без организации явных соеденений (очень похож на IP).

DFI (DSP Format Identifier) – идентификатор формата DSP

Однооктетное поле в формате адреса NSAP версии GOSIP 2.0.

ES (End System) – конечная система

Термин OSI для хоста.

ES-IS

Протокол OSI для взаимодействия между маршрутизаторами и конечными системами (ISO 9542).

ICD (International Code Designator)

Стандарт ISO для идентификации организаций.

IP (Internetwork Protocol) – протокол межсетевого взаимодействия

Стандартный протокол сетевого уровня.

IS (Intermediate System) – промежуточная система

Термин OSI для маршрутизатора.

IS-IS

Протокол обмена маршрутными данными между промежуточными системами (протокол ISO для маршрутизации в одном домене).

IS-IS Hello

Пакет Hello, определенный протоколом IS-IS и используемый им.

ISH

Пакет Hello, определенный протоколом ISO 9542 (протокол ES-IS). Отличается от IS-IS Hello.

ISO (International Organization for Standardization) – Международный комитет по стандартизации

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

LSP (Link State Packet)

Тип пакетов, используемых протоколом IS-IS.

NLPID

Идентификатор протокола сетевого уровня (однооктетное поле, указывающее протокол сетевого уровня).

NSAP

Точка досутпа к сетевому сервису (концептуальный интерфейс для доступа в сеть).

SEL

Селектор NSAP (последний октет адреса NSAP, называемый также NSEL).

OSI

Взаимодействие открытых систем (архитектура международных стандартов).

RD

Домен маршрутизации (набор маршрутизаторов и конечных систем, использующих один экземпляр протокола маршрутизации, например, IS-IS)

SNPA

Точка подключения подсети (концептуальный интерфейс в подсеть).

TCP

Протокол управления передачей (стандартный протокол транспортного уровня в Internet).

TCP/IP

Стек протоколов на основе TCP, IP и связанных с ними протоколов (стандартная архитектура протоколов Internet).

3 Независимые от подсети функции

3.1 Обмен маршрутной информацией

Для обмена маршрутными данными между маршрутизаторами применяются обычные пакеты, определенные спецификацией OSI IS-IS, с дополнительной информацией, относящейся к IP.

Протокол IS-IS обеспечивает включение полей переменного размера во все пакеты IS-IS. Эти поля кодируются с использованием триплетов (Code, Length, Value)12, где код и размер представляются одним октетом каждый, а размер поля значения определяется полем length (от 0 до 254 октетов). IS-IS требует: «Любые нераспознанные коды в принятых PDU игнорируются и передаются без изменения». Это требование применимо ко всем маршрутизаторам IS-IS, включая OSI, IP и маршрутизаторы с двойным стеком. Такое кодирование позволяет указать связанную с IP информацию так, что маршрутизаторы OSI будут игнорировать ее. Аналогично маршрутизаторы IP будут игнорировать информацию OSI.

Поддерживающие IP маршрутизаторы (т. е. IP и с двойным стеком) должны знать, какие протоколы сетевого уровня поддерживаются другими маршрутизаторами в их области. Эта информация обеспечивается путем включения поля protocols supported во все пакеты IS-IS Hello и LSP. В этом поле используются идентификаторы NLPID, которыми являются однооктетные значения, выделенные ISO для указания протоколов сетевого уровня. Значения NLPID выделены для протоколов ISO 8473 и IP.

Поддерживающим IP маршрутизаторам нужно знать IP-адреса смежных интерфейсов соседних маршрутизаторов. Это требуется для отправки пакетов ICMP redirect (когда поддерживающий IP маршрутизатор передает ICMP redirect хосту, он должен включить IP-адрес нужного интерфейса следующего маршрутизатора – next-hop). Эта информация обеспечивается включением IP-адреса интерфейса в пакеты IS-IS Hello. В частности, пакет IS-IS Hello содержит IP-адрес(а) интерфейса, через который передается сообщение Hello. IS-IS позволяет назначать каждому физическому интерйесу множество адресов IP.

В некоторых случаях для маршрутизаторов с поддержкой IP будет полезна возможность определять IP-адрес(а) других маршрутизаторов на своем уровне (для уровня 1 – всех маршрутизаторов в своей области, для уровня 2 – всех маршрутизаторов уровня 2 в домене маршрутизации). Это полезно в тех случаях, когда маршрутизатору будет передаваться пакет Ipisнапример, для инкапсуляции или передачи пакетов управления сетью. Эта информация обеспечивается включением IP-адреса в пакеты LSP. В частности, каждый пакет IS-IS LSP включает один или несколько адресов IP передающего этот пакет маршрутизатора. Поддерживающий IP маршрутизатор должен включать хотя бы один из своих адресов IP в пакеты LSP и может указывать множество своих адресов (например, все). Когда один маршрутизатор работает на уровнях 1 и 2, он должен включать один набор адресов в LSP обоих уровней.

Маршрутизаторам с поддержкой IP нужно знать для любого данного IP-адреса получателя корректный маршрут к нему. В частности, маршрутизаторам уровня 1 нужно значть адреса IP, доступные через каждый маршрутизатор уровня 1 в своей области. Кроме того, маршрутизаторам уровня 1 нужно находить маршрутизатры уровня 2 (для трафика получателям IP за пределами области). Маршрутизаторам уровня 2 нужно знать адреса IP доступные внутри (напрямую или через уровень 1) и снаружи (через другие маршрутизаторы уровня 2). Эта информация обеспечивается включением данных о доступности адресов IP в пакеты LSP.

Информация о доступности внутри домена маршрутизации и вне его анонсируется раздельно в LSP уровня 2. Доступные адреса IP включают используемую по умолчанию метрику и могут включать метрику, связанную с разными TOS. В общем случае для внешних маршрутов метрика может иметь тип internal (напрямую совместима со внутренней метрикой) или external (не совместима со внутренней метрикой). Маршрут с внутренней метрикой (анонсированный как внутренний или внешний с внутренней метрикой) всегда будет предпочтительней маршрутов с внешней метрикой.

Детали кодирования связанной с IP информации в пакетах маршрутизации рассмотрены в разделе 5 Структура и кодирование PDU.

3.2 Иерархическое сокращение информации о доступности IP

Маршрутизаторы уровня 2 включают в свои LSP уровня 2 список всех комбинаций [IP-адрес, маска подсети, метрика], доступных в их области. В общем случае эту информацию можно получить из LSP уровня 1 всех маршрутизаторов области. Если не принимать во внимание ограниченность ресурсов, маршрутизатор уровня 2 может просто дублировать все записи [IP-адрес, маска подсети, метрика] от каждого из маршрутизаторов уровня 1 в своей области (с соответствующей корректировкой метрики) для включения в свои LSP уровня 2. Однако для масштабирования иерархической маршрутизации на крупные домены желательно сокращать данные о доступности адресов.

Это выполняется путем ручной настройки объединения адресов. В каждом маршрутизаторе уровня 2 можно задать одну или множество записией [IP-адрес, маска подсети, метрика] для анонсирования в LSP уровня 2.

Множество доступных адресов, полученных из LSP уровня 1, сравнивается с заданным в конфигурации набором доступных адресов. Избыточная информация из LSP уровня 1 не включается в LSP уровня 2. Обычно предполагается, что заданная на уровне 2 информация включает более широкий набор адресов (соответствует более короткой маске). Это позволяет одной заданной в конфигурации парой адрес-маска (или меньшим числом таких пар) охватить всю информацию из множества LSP уровня 1.

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

Любой адрес из LSP уровня 1, не замененный заданной вручную конфигурацией, включается в LSP уровня 2. В этом случае анонсируемое в LSP уровня 2 значение метрики рассчитывается путем сложения метрики из LSP уровня 1 с расстоянием от маршрутизатора уровня 2 до соответствующего маршрутизатора уровня 1. Если сумма превышает 63 (максимальное значение в LSP уровня 2), должна указываться метрика 63. Метрики задержки, расходов и ошибок (т. е. параметры TOS, отличные от принятой по умолчанию метрики) будут включаться лишь при условии, что (i) маршрутизатор уровня 2 поддерживает конкретное значение TOS, (ii) путь от маршрутизатора уровня 2 до соответствующего маршрутизатора уровня 1 проходит через каналы, поддерживающие конкретное значение TOS и (iii) маршрутизатор уровня 1, которому напрямую доступен адресат, поддерживает конкретное значение TOS для этого маршрута, как указано в LSP уровня 1.

В общем случае одна и та же пара (IP-адрес-маска подсети) может анонсироваться в LSP уровня 1 разными маршрутизаторами уровня 1 из одной области. В таких случаях (если адрес не заменяется заданной вручную конфигурацией) в LSP уровня 2 следует включать лишь одну такую запись. Значения метрики в LSP уровня 2 соответствуют минимальной метрике, которая будет вычислена для каждой записи в LSP уровня 1.

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

Заданные вручную адреса могут иерархически замещать множество записей о доступных адресах, полученных от уровня 1. Однако могут быть некоторые адреса IP, соответствующие заданным вручную, но недоступные через маршрутизацию уровня 1. Если маршрутизатор уровня 2 получает пакет IP, где IP-адрес соответствует заданному вручную и включаемому в LSP уровня 2 адресу, но недоступен через маршрутизацию уровня 1 в области, этот пакет должен отбрасываться. В таком случае может возвращаться сообщение об ошибке (как указано в RFC 1009), с указанием недоступности получателя в качестве причины отбрасывания.

Рисунок 2. Пример домена маршрутизации.

Пример показан на рисунке 2. Предположим, что для домена маршрутизации в целом используется номер сети 17 (сеть класса A), а для нумерации каждой подсети служат следующие 8 битов адреса. Область может быть дополнительно разделена назначением следующих 8 битов для каждой ЛВС, что приводит к 24-битовой маске подсети (с учетом полей сети и подсети). Оставшиеся 8 битов служат для указания хоста. Пусть для конкретной области (на рисунке подсеть 17.133) имеются маршрутизаторы уровня 1 с поддержкой IP, анонсирующие (в специальной записи IP своих LSP уровня 1) подсети 17.133.5, 17.133.43 и 17.133.57.

Предположим, что для экономии пространства в LSP уровня 2 маршрутизаторы этого уровня в данной области настроены на анонсирование подсети 17.133. Это будет единственный адрес, который требуется включать в LSP уровня 2. Таким образом, для пакетов IP в подсети 17.133.5, 17.133.43 или 17.133.57 другие маршрутизаторы уровня 2 в иных областях будут знать, что пакеты нужно передавать в эту область.

Включение 17.133 в LSP уровня 2 означает, что три подсети, начинающиеся с 17.133 не нужно указывать раздельно в LSP уровня 2.

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

Предположим, что подсеть 17.133.125 действительно доступна через некую другую область, например, нижнюю справа на рисунке. В этом случае маршрутизатор уровня 2 в левой области будет анонсировать (в своих LSP уровня 2 в соответствии с заданной вручную конфигурацией) доступность подсети 17.133. Однако маршрутизатор уровня 2 в нижней правой области будет анонсировать (в LSP уровня 2 по данным, полученным из LSP уровня 1) доступность сети 17.133.125. В результате выбора маршрута по максимальному соответствию все будет работать корректно и трафик из других областей в подсеть 17.133.125 будет передаваться маршрутизатору уровня 2 из нижней правой области, а остальной трафик в подсеть 17.133 (т. е. по всем адресам IP, начинающимся с 17.133, кроме адресов, начинающихся с 17.133.125) будет передаваться маршрутизатору уровня 2 в левой области.

3.3 Адресация маршрутизаторов в пакетах IS-IS

Формат пакетов IS-IS явно требует наличия в них OSI-адресов маршрутизаторов. Например, эти адреса служат для определения принадлежности маршрутизаторов к области. Поэтому для всех маршрутизаторов, использующих протокол IS-IS, требуется задавать адреса в стиле OSI. Маршрутизаторы, поддерживающие лишь IP, будут применять эти адреса лишь в работе протокола IS-IS, не используя для иных целей (например, в протоколах EGP, ICMP, TCP/IP).

В маршрутизаторах OSI и маршрутизаторах с двойным стеком назначение адресов NSAP достаточно просто, но этот вопрос выходит за рамки спецификации. Органы стандартизации задают механизмы назначения адресов, обеспечивающие уникальность OSI NSAP в глобальном масштабе. Маршрутизаторы OSI и с двойным стеком могут применять для работы протокола IS-IS обычные адреса OSI.

У маршрутизаторов IP имеется два способа получения адресов NSAP для использования с протоколом IS-IS.

1. В средах, где используется или предполагается OSI, можно получать адреса NSAP обычным способом, назначая их маршрутизаторам IP для использования в работе IS-IS. Такой подход рекомендуется даже для «чистых» доменов маршрутизации IP, поскольку он позволяет перейти к двойному стеку протоколов.
2. В некоторых случаях маршрутизаторы могут иметь лишь адреса TCP/IP и применение обычных механизмов назначения адресов NSAP может быть нежелательно. В таких случаях можно применять описанный ниже механизм алгоритмической генерации корректных адресов в стиле OSI по имеющимся адресам IP и номерам автономных систем.

Когда маршрутизатору IP нужны адреса в стиле OSI (совместимы с форматом NSAP USA GOSIP версии 2.0 [9]) для использования лишь в пакетах IS-IS, их можно получить в соответствии с приведенным ниже описанием.

Значения AFI = 47 и ICD = 00 05 задают формат адресации Gosip V2.0. Значения DFI = xx и AA = xx xx xx указывают, использование специального формата адреса NSAP, исключительно для пакетов IS-IS в среде IP. Резервное поле должно содержать значение 00 00 в соответствии с GOSIP v2.0.

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

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

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

1. Уникальный 48-битовый адрес станции IEEE 802.
2. Значение 02 00 со следующим за ним IP-адресом маршрутизатора.

Адреса IEEE 802 должны указываться в каноническом формате IEEE.

Поскольку адреса IEEE 802 уникальны в глобальном масштабе, их применения явно обеспечит уникальность в пределах области. Во всех выделенных адресах IEEE 802 бит global/local имеет значение 0. Добавление указанного в п 2) префикса перед адресом IP гарантирует, что адрес такого формата не будет вызывать конфликтов с адресами типа 1). Кроме того, этот формат также обеспечивает глобальную уникальность идентификаторов для маршрутизатора.

Шестнадцатеричное значение адреса задается в канонической форме IEEE 802 [10]. В адресах IEEE 802 флаг групповой адресации (multicast) находится в младшем бите первого байта, а флаг global/local следует за этим битом. Показанный выше префикс устанавливает для флага global/local значение 1, а остальные биты сброшены в 0.

Отметим, что внутри области независимо от настройки адресов ISO в маршрутизаторах по процедуре ISO или путем генерации по номеру AS и адресу IP, все маршрутизаторы области должны иметь однинаковую старшую часть адреса (AFI, ICD, DFI, AA, RD, Area). Этот адрес в стиле ISO применяется в сообщениях IS-IS Hello и на его основе маршрутизаторы определяют принадлежность соседа к своей или чужой области.

3.4 Внешние соединения

Внешние соединения (взаимодействие с маршрутизаторами за пределами домена маршрутизации) организуются лишь маршрутизаторами уровня 2. ISO-версия протокола IS-IS позволяет сообщать о внешних маршрутах OSI как о «доступных префиксах адресов» в LSP уровня 2. Интегрированный протокол IS-IS поддерживает также информирование о доступности внешних адресов IP (доступных через междоменную маршрутизацию) в LSP уровня 2 (поле IP external reachability information). Внешние маршруты OSI и IP обрабатываются независимо.

Маршруты, анонсированные в записях IP external reachability information, включают все маршруты за пределы домена маршрутизации, в том числе полученные от протоколов OSPF, EGP, RIP и др.

Внешние маршруты могут использовать «внутреннюю» или «внешнюю» метрику. Внутренняя метрика совместима с используемой на внутридоменных маршрутах, т. е. можно напрямую сравнивать значения метрики внутренних маршрутов и внешних маршрутов с внутренней метрикой. Внешняя метрика не позволяет сравнивать внешние маршруты напрямую с внутренними. Любой маршрут, указанный исключительно с внутренней метрикой, предпочтительней маршрутов с внешней метрикой. Когда требуется использовать внешний маршрут с внешней метрикой, предпочтительным является маршрут с меньшим значением внешней метрики, независимо от внутренней стоимости пути до точки выхода.

При использовании протоколов внешней маршрутизации полезно обеспечить граничным маршрутизаторам (маршрутизаторам своего домена, способным передавать трафик в другие домены и из них) механизм определения наличия друг друга и обмена внешней информацией в форме, понятной лишь граничным маршрутизаторам домена. Это можно реализовать путем включения полей Inter-domain routing protocol information в LSP уровня 2. Такие поля не включаются в LSP псевдоузлов.

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

Информация, содержащаяся в поле Inter-domain routing protocol information, передается в LSP уровня 2 и поэтому должна храниться на всех маршрутизаторах уровня 2 в домене. Однако используют эти данные лишь маршрутизаторы уровня 2, непосредственно вовлеченные во внешнюю маршрутизацию. При разработке процедур использования этого поля важно внимательно рассмотреть ее влияние на требования к хранилищам в маршрутизаторах уровня 2, включая и маршрутизаторы, не участвующие напрямую во внешней маршрутизации.

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

3.5 Маршрутизация ToS

Интегрированный протокол IS-IS обеспечивает маршрутизацию IP TOS за счет использования функций QOS в IS-IS. Это позволяет выполнять маршрутизацию с учетом пропускной способности (принято по умолчанию), задержки, стоимости или сохраняющейся вероятности ошибок. Отметим, что для любого пакета может применяться один (любой) из этих 4 вариантов.Маршрутизация на основе комбинаций вариантов не поддерживается.

Поддержка TOS/QOS не является обязательной. Если пакету требуется определенное значение TOS и все маршрутизаторы на корректном пути от отправителя к получателю поддерживают это значение TOS, пакет будет направлен по оптимальному пути. Однако если между отправителем и получателем нет пути с нужным типом обслуживания, пакет будет пересылаться с использованием принятой по умолчанию метрики. Это позволяет поддерживать TOS в средах, где это необходимо, и обеспечивать доступный сервис в средах, где запрашивается не поддерживаемое значение TOS.

Отметим, что в IP нет TOS для «стоимости», поэтому не существует отображения IP TOS на маршрут с минимальной стоимостью.

Поля IP TOS отображаются в одну из 4 доступных метрик:

биты 0-2 (Precedence – предпочтение) не влияют на маршрут, но могут влиять на другие аспекты пересылки;

биты 3 (Delay), 4 (Throughput) и 5 (Reliability) рассмотрены в таблице.

3.6 Множество LSP и SNP

В некоторых случаях пакеты IS-IS (в частности, Link State и Complete Sequence Number) могут быть слишком большими для передачи в одной дейтаграмме. OSI IS-IS [1] позволяет расщеплять LSP и CSNP на несколько пакетов. Это не зависит от сегментации ISO 8473 и фрагментации IP. Использование множества независимых пакетов обеспечивает преимущества (по сравнению с сегментированием и фрагментацией) в том, что (i) при изменении информации IS-IS нужно заново передавать лишь измененные пакеты и (ii) при получении одного пакета его можно начать обрабатывать без ожидания приема других пакетов того же типа от того же маршрутизатора.

Протокол Integrated IS-IS использует функцию множественных пакетов, определенную в [1]. Связанные с IP поля в пакетах IS-IS могут быть разделены по нескольким пакетам. Как отмечено в разделе 5 Структура и кодирование PDU, некоторые поля, связанные с IP (они могут быть достаочно большими) могут разделяться на несколько экземпляров одного поля, что позволяет разделять поля между разными пакетами.

Пакеты LSP от одного маршрутизатора различаются по номерам LSP. Обычно поля переменного размера могут присутствовать в LSP с любым номером. Некоторые поля переменного размера должны передаваться в LSP с номером 0. за исключением случаев, когда явно указано иное, при отправке маршрутизатором IS-IS множества LSP поля, связанные с IP, могут присутствовать в LSP с любым номером.

Пакеты Complete Sequence Number могут разделяться на множество пакетов с явным указанием в каждом из них диапазона, к которому пакет относится. Пакеты Partial Sequence Number Packets по своей природе являются неполными и их можно легко разделить на несколько пакетов при необходимости. Связанные с IP поля могут появляться в любом SNP.

3.7 Работа только с IP

Для маршрутизаторов, поддерживающих лишь IP, формат пакетов IS-IS сохраняется, однако некоторые поля переменного размера в пакетах IS-IS могут быть опущены:

пакеты IS-IS Hello

• без изменений;

пакеты IS-IS Link State:

• записи End Systems Neighbours опускаются;
• записи Prefix Neighbours опускаются;

пакеты IS-IS Sequence Number

• без изменений.

3.8 Инкапсуляция

Будущие версии Integated IS-IS могут задавать дополнительную инкапсуляцию для частичного восстановления и пересылки пакетов через несовместимые маршрутизаторы (например, для пересылки пакетов OSI через маршрутизаторы IP или персылки пакетов IP через маршрутизаторы OSI). Детали инкапсуляции и декапсуляции оставлены для дополнительного изучения. Маршрутизаторы, соответствующие Integrated IS-IS, не обязаны выполнять инкапсуляцию и декапсуляцию.

3.9 Проверка подлинности

Поле Authentication позволяет включить в каждый пакет IS-IS данные для проверки подлинности отправителя и/или содержимого пакета. Аутентификационные данные из каждого пакета служат для проверки подлинности всего пакета, включая части OSI и IP. Если полученный пакет содержит недействительные данные аутентификации, он отбрасывается целиком. Если LSP или SNP разделен на несколько пакетов, как описано в параграфе 3.6, каждый из них проверяется независимо.

Использование поля Authentication не обязательно и маршрутизаторы не обязаны интерпретировать данные аутентификации. Как и для других полей IS-IS, неизвестных маршрутизатору, он будет просто игнорировать поле Authentication, которое может присутствовать в пакете.

Использование поля аутентификации описано в Приложении D.

3.10 Порядок предпочтения маршрутов (расчет Dijkstra)

Термин IP reachability entry (запись о доступности IP) служит для обозначения пары [IP-адрес, маска подсети]. Расчет Dijkstra должен найти маршруты для каждой отличающейся записи о доступности IP. В расчете Dijkstra каждая запись может обрабатываться почти так же, как конечная система OSI. Естественно, записи IP-доступности обрабатываются отдельно от конечных систем OSI, которые также могут быть доступны в той же области или домене маршрутизации.

Любая конкретная запись IP-доступности считается совпадающей с другой записью, если (i) маски подсетей идентичны и (ii) в адресах IP совпадают все биты, для которых в маске установлено значение 1. Это можно легко проверить сбросом в 0 битов адреса IP, которым соответствуют биты о в маске, и сравнения полученных результатов как 64-битовых (адрес+маска) чисел. Поэтому реальный расчет маршрутов для записей о доступности IP не сложнее расчета маршрутов к конечным системам OSI (разница лишь в том, что сравниваются 48- и 64-битовые значения).

Расчет Dijkstra не принимает во внимание тип маршрутизатора – IP, OSI, двойной стек. Указанные в параграфе 1.4 топологические ограничения гарантируют, что пакеты IP будут отправляться через маршрутизаторы с поддержкой IP, а пакеты OSI – через маршрутизаторы с поддержкой OSI.

В Integrated IS-IS по возможности предпочитаются маршруты внутри области (через уровень 1). Если требуется использовать маршруты уровня 2, внутридоменные маршруты (в частности, маршруты с внутренней метрикой) будут предпочтительней маршрутоыв вне домена (использующих внешнюю метрику).

Протокол Integrated IS-IS выбирает для маршрутизации IP путь с наибольшим совпадением. Это означает, что адресу получателя может соответствовать несколько записей в таблице пересылки. В таких случаях выбирается маршруто, для которого маска содержит больше битов со значением 1 (более длинная).

Пакеты IP, направленные маршрутизаторам, обрабатываются так же, как другие IP-пакет, путем пересылку с подходящую подсеть и последующей пересылки в подсеть хоста (которым в данном случае является маршрутизатор). В частности, база данных пересылки IP не включает явных маршрутов по IP interface addresses для каждого маршрутизатора из LSP.

Однако маршруты к хостам (маски содержит только 1) могут включаться в записи IP-доступности и будут обрабатываться так же, как прочие записи о доступности IP.

Для обеспечения корректного взаимодействия разных реализаций маршрутизаторов требуется задать порядок предпочтения разных маршрутов. Для адресатов OSI этот вопрос выходит за рамки данной спецификации. Для получателей IP вопросы предпочтения маршрутов рассмотрены в параграфах 3.10.1 и 3.10.2. В Приложении C подробно описан расчет Dijkstra и алгоритм пересылки совместиые с описанным здесь порядком предпочтения.

В IS-IS при анонсировании маршрута к данному получателю или канала между маршрутизаторами значения метрики, связанные со всеми или некоторыми типами метрики TOS, могут быть связаны с адресатом или каналом, однако принятая по умолчанию метрика должна быть доступна всегда. Обычно это гарантирует доступность маршрута с принятой по умолчанию метрикой при доступности маршрута с любой метрикой TOS. Единственным исключением из этого правила является случай, когда маршрут с принятой по умолчанию метрикой имеют общую стоимость (внутри области или магистрали уровня 2), превышающую MaxPathMetric.

При определении маршрута к конкретному адресату для заданного TOS рассматриваются лишь маршруты с этой или принятой по умолчанию метрикой TOS.

3.10.1 Порядок предпочтения маршрутов для уровня 1

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

1. Если адрес получателя соответствует нескольким парам [IP-адрес, маска подсети] среди внутриобластных маршрутов выбирается тот, у которого больше 1 в маске (более длинная маска).
2. Среди маршрутов с одинаковой маской выбираются маршруты, где поддерживается запрошенное значение TOS (если они имеются).
3. Из маршрутов с одинаковым TOS и маской выбирается кратчайший. Для его определения при наличии маршрутов с запрошенным TOS используется соответствующая метрика TOS, а при их отсутствии – принятая по умолчанию. Для равноценных маршрутов может применяться распределение нагрузки, как описано в [1].

Для маршрутизаторов уровня 1 (т. е. не участвующего в маршрутизации уровня 2 или маршрутизатора уровня 2, который не «подключен») при недоступности данного адресата внутри области маршрутизация уровня 1 всегда дает путь к маршрутизатору уровня 2, как описано ниже.

1. Маршруты внутри области к подключенным маршрутизаторам уровня 2 маршруты с поддержкой запрошенного TOS предпочтительней маршрутов без такой поддержки.
2. Из маршрутов внутри области к подключенным маршрутизаторам уровня 2 с одинаковым TOS выбирается кратчайший. Для его определения при наличии маршрутов с запрошенным TOS используется соответствующая метрика TOS, а при их отсутствии – принятая по умолчанию. Для равноценных маршрутов может применяться распределение нагрузки, как описано в [1].

3.10.2 Порядок предпочтения маршрутов для уровня 2

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

1. Маршруты только с внутренней метрикой предпочтительней маршрутов, включающих внешнюю метрику.
2. Если доступны маршруты без внешней метрики, выбор осуществляется в приведенном ниже порядке.
   1. Если адрес получателя соответствует нескольким парам [IP-адрес, маска подсети], выбирается маршрут с более длинной маской (большим числом 1).
   2. Среди маршрутов с одинаковой маской (т. е. одинаковым числом 1 в маске подсети) выбираются маршруты (если они имеются), где поддерживается запрошенное значение TOS.
   3. Среди маршрутов с одинаковыми TOS и масками подсетей выбирается кратчайший. Для его определения при наличии маршрутов с запрошенным TOS используется соответствующая метрика TOS, а при их отсутствии – принятая по умолчанию. Для равноценных маршрутов может применяться распределение нагрузки, как описано в [1].Внутренние маршруты (к адресатам, анонсированным в поле IP Internal Reachability Information) и внешние маршруты с внутренней метрикой (к адресатам, указанным в поле IP External Reachability Information, и с внутренней метрикой) имеют одинаковый уровень предпочтения при выборе и расчетах Dijkstra.
3. Если маршрутов без внешней метрики нет, используется приведенный ниже порядок выбора.
   1. Если адрес получателя соответствует нескольким парам [IP-адрес, маска подсети], выбирается маршрут с более длинной маской (большим числом 1).Для внешних маршрутов маска подсети обычно точно соответствует номеру сети. Это предполагает, что проверка всегда будет давать одинаковый размер совпадения. Однако проверка сохранена для обеспечения возможности перехода в будущем к более общей обработке внешних адресов.
   2. Среди маршрутов с одинаковой маской (т. е. одинаковым числом 1 в маске подсети) выбираются маршруты (если они имеются), где поддерживается запрошенное значение TOS. Внешний маршрут считается поддерживающим TOS только в случае поддержки этого TOS на пути к граничному маршрутизатору и в самом маршрутизаторе.
   3. Среди маршрутов с одинаковыми TOS и масками подсетей выбирается кратчайший, как указано ниже.
      1. Маршруты с меньшей анонсированной внешней метрикой более предпочтительны.
      2. Среди маршрутов с одинаковой внешней метрикой предпочтительные маршрут с меньшей внутренней метрикой. Для равноценных маршрутов может применяться распределение нагрузки, описанное в [1].

Для маршрутизаторов уровня 2, анонсирующих заданные вручную агрегированные адреса в своих LSP уровня 2, могут существовать адреса IP, соответствующие заданным вручную, но не соответствующие адресам, доступным в области через уровень 1. В общем случае пакеты для таких адресов обрабатываются, как описано ниже.

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

4 Зависящие от подсети функции

4.1 Демультиплексирование каналов

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

В общем случае тип канала является параметром конфигурации. Например, для каналов «точка-точка» с протоколом PPP, HDLC и т. п. следует настраивать соответствующую конфигурацию. Для любого конкретного типа канала должен быть определены методы инкапсуляции пакетов OSI и IP. Это определение выходит за рамки данной спецификации.

Пакеты IP инкапсулируются напрямую через базовую службу канального уровня с использованием обычных методов передачи пакетов IP через соответствующий тип канала. Аналогично выполняется инкапсуляция и для пакетов OSI. Отметим также, что пакеты IS-IS инкапсулируются с использованием обычного метода передачи пакетов OSI для соответствующего типа канала. Это предполагает, что все маршрутизаторы IS-IS, включая поддерживающие лишь IP, должны быть способны принимать пакеты IS-IS с использованием обычной инкапсуляции OSI.

4.2 Множество адресов IP на интерфейсе

Интегрированный протокол IS-IS позволяет каждому маршрутизатору иметь множество адресов IP на каждом физическом интерфейсе вплоть до максимального числа, которое может быть включено в одно поле IP Interface Address (т. е. до 63 адресов на интерфейс). Например, при наличии двух логических подсетей в одной ЛВС интерфейс может иметь два адреса IP (по одному на подсеть). Каждый пакет IS-IS Hello содержит список адресов IP, связанных с физическим интерфейсом, через который этот пакет передается.

Можно реализовать маршрутизаторы, соответствующие спецификации Integrated IS-IS, с ограничением числа адресов на интерфейсе. Однако поддерживаюшие IP маршрутизаторы доблжны быть способны взаимодействовать с маршрутизаторами, имеющими несколько адресов IP на физических интерфейсах (вплоть до 63 на интерфейс).

В соответствующих случаях (например, на некоторых каналах №точка-точка») могут применяться интерфейсы без адресов IP. Тогда в сообщениях IS-IS Hello, передаваемых через эти интерфейсы, поле IP Interface Address можно опускать или заполнять нулями.

4.3 ЛВС, назначенные маршрутизаторы и псевдоузлы

Поддержка назначенных маршрутизаторов и псевдоузлов задана в [1] и не меняется в этой спецификации. , and is not changed by this proposal. При смешении маршрутизаторов IP и с двойным стеком (или OSI и с двойным стеком) в одной ЛВС «чистой» области IP (или OSI, соответственно) любой из маршрутизаторов ЛВС может стать назначенным.

Однако есть фундаментальное различие в способах работы OSI и TCP/IP в ЛВС и других широковещательных сетях.

В случае OSI использование протокола ES-IS (ISO 9542) позволяет конечным системам и маршрутизаторам автоматически определять связность и конечные системы ЛВС могут работать через любой из маршрутизаторов ЛВС.

В TCP/IP явно задаются идентификаторы подсети для каждой ЛВС и в некоторых случаях одна физическая ЛВС может включать несколько подсетей. Конечным системам (хостам) из одной подсети явно запрещена отправка пакетов IP напрямую маршрутизатору из другой логической подсети. На каждом маршрутизаторе вручную настраиваются адреса для подсетей на каждом интерфейсе. При наличии множества логических подсетей в одной ЛВС маршрутизатор может обмениваться пакетами IP лишь с конечными системами той же логической подсети. Это предполагает, что в LSP псевдоузла недостаточно анонсировать все подсети ЛВС (т. е. все пары [IP-адрес, маска подсети], доступные в ЛВС).

Поэтому каждому маршрутизатору необходимо анонсировать в своих LSP подсети, доступные на каждом интерфейсе, включая интерфейсы в широковещательные сети, такие как ЛВС. LSP псевдоузлов не задают адресов IP, доступных в ЛВС (т. е. не включают поля IP reachability).

Как отмечено в готовящемся обновлении документа Requirements of IP Gateways [4], маршрутизаторы могут передавать сообщения ICMP redirect лишь при условии, что (i) пакет IP будет пересылаться через тот же физический интерфейс, где он был принят и (ii) адрес отправителя пересылаемого пакета IP, адрес IP интерфейса данного маршрутизатора (указанный как адрес отправителя в ICMP redirect) и IP-адрес маршрутизатора, куда будет пересылаться пакет (тоже указывается в ICMP), относятся к одной подсети IP.

4.4 Поддержка смежности маршрутизаторов

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

Для каналов «точка-точка» IS-IS требует обмена пакетами ISO 9542 ISH на первом этапе организации соединения между маршрутизаторами. Поэтому все маршрутизаторы IS-IS должны передавать и принимать ISH на таких каналах.

Поле Protocols supported (5 Структура и кодирование PDU) должно присутствовать во всех пакетах IS-IS Hello, передаваемых маршрутизаторами IP и с двойным стеком. При отсутствии этого поля предполагается, что пакет передан маршрутизатором OSI. Аналогично пакеты 9542 ISH, передаваемые в канал «точка-точка» где может быть другой маршрутизатор IS-IS, должны включать поле Protocols supported. Если это поле по ошибке передано через ISH в канал «точка-точка», к которому подключена конечная система OSI, эта система (в соответствии с ISO 9542) должна игнорировать данное поле и корректно обрабатывать ISH. Поэтому можно всегда включать данное поле в ISH на каналах «точка-точка».

Маршрутизаторы с двойным стеком должны работать в обоих режимах на каждом канале домена маршрутизации, где применяется IS-IS. Поэтому значения поля Protocols supported должны быть идентичными на всех каналах (т. е. для любого маршрутизатора IS-IS все передаваемые пакеты Hello и LSP должны содержать одно значение поля).

4.5 Пересылка несовместимым маршрутизаторам

Могут возникать ситуации, когда маршрутиззатор с двойным стеком пересылает пакеты IP маршрутизатору OSI или пакеты OSI маршрутизатору IP. Такие пакеты должны отбрасываться и может передаваться сообщение об ошибке в соответствии со спецификацией IP или ISO 8473. В качестве причины отбрасывания следует указывать Destination host unreachable для IP и Destination unreachable для OSI.

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

5 Структура и кодирование PDU

В этом разделе описаны дополнительные поля пакетов, используемые протоколом ISO IS-IS Intra-Domain Routing в среде IP или при поддержке двух протоколов. Применяются те же типы пакетов, что и в IS-IS [1], а все фиксированные поля сохранены. Размеры дополнительных полей описаны в соответствующих параграфах этого раздела.

5.1 Обзор IS-IS PDU

Пакеты, используемые протоколом маршрутизации IS-IS делятся на 3 основных класса: (i) Hello, (ii) Link State (LSP) и (iii) Sequence Number (SNP). Пакеты Hello служат для организации и поддержки смежности между маршрутизаторами и делятся на 3 типа:

1. Level 1 LAN IS to IS Hello PDU применяются маршрутизаторами уровня 1 в широковещательных ЛВС.
2. Level 2 LAN IS to IS Hello PDU применяются маршрутизаторами уровня 2 в широковещательных ЛВС.
3. Point-to-Point IS to IS Hello PDU применяются в средах без широковещания (каналы «точка-точка» и топологические подсети).

На каналах «точка-точка» обмен ISO 9542 ISH14 служат для инициализации канала и обеспечения возможности каждому маршрутизатору узнать о наличии маршрутизатора на другой стороне канала до обмена пакетами IS-IS Hello. Все маршрутизаторы IS-IS (IP, OSI и с двойным стеком) при наличии интерфейса в канал «точка-точка» должны быть способны передавать ISO 9542 ISH в такие каналы.

Пакеты LSP служат для обмена данными о состоянии каналов. Применяется два типа LSP: (i) Level 1 Link State PDU передаются маршрутизаторами уровня 1, а Level 2 Link State PDU – маршрутизаторами уровня 2. Отметим, что маршрутизаторы уровня 2 в большинстве случаев работают также на уровне 1 и поэтому передают оба типа LSP.

Sequence number PDU служат для синхронизации представления смежных маршрутизаторов о недавнем (последнем) LSP, переданном от соседа. Таким образом, эти PDU выполняют функцию подтверждений, но работают эффективней. Имеется 4 типа пакетов с порядковыми номерами: (i) Level 1 Complete Sequence Numbers PDU, (ii) Level 2 Complete Sequence Numbers PDU, (iii) Level 1 Partial Sequence Numbers PDU и (iv) Level 2 Partial Sequence Numbers PDU. Неполные пакеты порядковых номеров указывают последний номер одного или нескольких LSP и работают как подтверждения, но отличаются от обычных подтверждений возможностью подтвердить сразу несколько LSP, а также запрашивать информацию. Полные пакеты содержат последние порядковые номера всех LSP из базы данных и могут служить для синхронизации баз данных смежных маршрутизаторов периодически или при активизации канала.

5.2 Обзор связанной с IP информации для IS-IS

Для Integrated IS-IS определено 6 новых полей: (i) Protocols Supported, (ii) IP Interface Address, (iii) Authentication Information, (iv) IP Internal Reachability Information, (v) IP External Reachability Information, (vi) Inter-Domain Routing Protocol Information.

Поле Protocols Supported указывает поддерживаемые маршрутизатором протоколы и должно включаться во все пакеты IS-IS Hello, а также во все пакеты LSP с номером 0, передаваемые поддерживающими IP маршрутизаторами. При отсутствии данного поля в таких пакетах можно предполагать, что пакет передан маршрутиазатором OSI. Поле Protocols Supported должно включаться также в пакеты ISO 9542 ISH, передаваемые маршрутизаторами с поддержкой IP в каналы «точка-точка» к другим маршрутизаторам IS-IS.

Поле IP Interface Address включается во все пакеты IS-IS Hello и LSP, передаваемые маршрутизаторами IP и с двойным стеком. В пакетах Hello это поле указывается однократно и содержит IP-адреса(а) интерфейса, передающего пакет (до 63 адресов IP на интерфейс). Если пакет IS-IS Hello передается через интерфейс без адреса IP, поле может быть опущено или содержать 0. В пакетах LSP поле содержит список адресов IP одного или нескольких интерфейсов передающего пакет маршрутизатора. Каждый маршрутизатор с поддержкой IP должен включать это поле в свои LSP. Поле может указываться неоднократно в LSP с любым номером.

Поле Authentication Information является необязательным для всех IS-IS PDU. При использовании поля в нем передаются данные для проверки подлинности пакета. Все пакеты IS-IS (включая 9542 IS Hello) могут включать поле.

Поле IP Internal Reachability Information может присутствовать во всех LSP, передаваемых маршрутизаторами с поддержкой IP, и указывает комбинации [IP-адрес, маска подсети, метрики], доступные передавшему LSP маршрутизатору. Каждая запись должна содержать принятую по умолчанию метрику и может включать метрику задержки, стоимости и ошибок. Если маршрутизатору с поддержкой IP недоступны напрямую никакие адреса IP, он может опустить это поле или включить запись [IP-адрес, маска подсети, метрики], заполненную 0. При включении в LSP уровня 1 это поле содержит лишь записи, напрямую доступные передающему маршрутизатору через один из его интерфейсов. В LSP уровня 2 это поле включает лишь записи, доступные передающему LSP маршрутизатору через его интерфейс или опосредованно через уровень 1. Поле может указываться неоднократно в LSP с любым номером.

Поле IP External Reachability Information может присутствовать в LSP уровня 2, передаваемых маршрутизаторами уровня 2 с поддержкой IP. Это поле содержит комбинации [IP-адрес, маска подсети, метрики], доступные передавшему LSP маршрутизатору. Каждая запись должна содержать принятую по умолчанию метрику и может включать метрику задержки, стоимости и ошибок. Каждая запись может включать метрики типа internal или external. Если маршрутизатор уровня 2 не имеет внешних маршрутов (через соседние маршрутизаторы других доменов), он может опустить это поле или заполнить его 0. Поле включает лишь записи, доступные передавшему LSP маршрутизатору через прямое соединения с внешним маршрутизатором. Поле может указываться неоднократно в LSP с любым номером.

Поле Inter-Domain Routing Protocol Information может присутствовать в LSP уровня 2, передаваемых маршрутизатором уровня 2 с поддержкой IP. Поле служит для протоколов внешней маршрутизации и не применяется в IS-IS. Например, оно может применяться граничными маршрутизаторами для поиска друг друга. Поле может указываться неоднократно в LSP уровня 2 с любым номером.

Версия DP 10589 протокола OSI IS-IS в настоящее время не позволяет добавлять дополнительные поля в формате TLV в пакеты с порядковыми номерами. Однако это будет исправлено в новых версиях 10589. Кроме того, предполагается, что это будет единственное изменение 10589, не совместимое с версией DP. Поэтому протокол Integrated IS-IS использует исправленную версию DP 10589 и кодирование SNP исправлено. Корректное кодирование пакетов с порядковыми номерами (предполагаемое в будущих версиях ISO 10589) описано в Приложении B.

Все связанные с IP данные кодируются в IS-IS полями переменного размера, как показано ниже.

                               Число октетов
+---------------------------+
|           CODE            |      1
+---------------------------+
|          LENGTH           |      1
+---------------------------+
|           VALUE           |    LENGTH
+---------------------------+

Рисунок 3. Представление полей переменного размера.

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

В общем случае IS-IS PDU могут содержать множество полей переменного размера, часть которых содержит данные, относящиеся к OSI (заданы в [1]), часть – относящиеся к IP (описаны здесь). За исключением явно отмеченных случаев эти поля могут размещаться в любом порядке.

5.3 Правила кодирования связанных с IP полей в IS-IS PDU

В этом параграфе подробно описано кодирование всех связанных с IP поле в IS-IS PDU. Поля, которые могут присутствовать в разных типах PDU, повторяются для каждого типа PDU, где они применимы.

Биты и октеты нумеруются как в [1]. В частности, октеты PDU нумеруются с 1 в порядке возрастания. Биты октетов имеют номера с 1 до 8, бит 1 является младшим и указывается на рисунках справа. Для чисел, представленных несколькими октетами меньший номер указывает старший октет.

5.3.1 IS – IS Hello PDU уровня 1 в ЛВС

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

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

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

IP Interface Address

Адрес(а) IP на интерфейсе, соответствующем точке SNPA, через которую передается PDU.

CODE – 132

LENGTH – общий размер поля VALUE (4 октета на каждый адрес).

VALUE

                                Число октетов
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+

IP ADDRESS – 4-октетный IP-адрес интерфейса.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.2 IS – IS Hello PDU уровня 2 в ЛВС

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

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

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

NLPID – зарегистрированный ISO/TR 9577 идентификатор протокола.

IP Interface Address

Адрес(а) IP на интерфейсе, соответствующем точке SNPA, через которую передается PDU.

CODE – 132

LENGTH – общий размер поля VALUE (4 октета на каждый адрес).

VALUE

                                Число октетов
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+

IP ADDRESS – 4-октетный IP-адрес интерфейса.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.3 IS – IS Hello PDU в соединениях «точка-точка»

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

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

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

IP Interface Address

Адрес(а) IP на интерфейсе, соответствующем точке SNPA, через которую передается PDU.

CODE – 132

LENGTH – общий размер поля VALUE (4 октета на каждый адрес).

VALUE

                                Число октетов
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+

IP ADDRESS – 4-октетный IP-адрес интерфейса.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.4 Link State PDU уровня 1

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

Набор идентификаторов NLPID для протоколов сетевого уровня, которые данная промежуточная система способна ретранслировать. Должно присутствовать один раз в LSP с номером 0.

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

NLPID – зарегистрированный ISO/TR 9577 идентификатор протокола.

IP Interface Address

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

Это поле может появляться неоднократно в LSP с любым номером.

CODE – 132

LENGTH – общий размер поля VALUE (4 октета на каждый адрес).

VALUE

                                Число октетов
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+

IP ADDRESS – 4-октетный IP-адрес интерфейса.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

IP Internal Reachability Information

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

Поле может включаться неоднократно в LSP с любым номером, однако не должно появляться в LSP псевдоузлов.

CODE – 128.

LENGTH – кратно 12.

VALUE

                                Число октетов
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+

DEFAULT METRIC

Значение используемой по умолчанию метрики для канала к указанному соседу. Бит 8 поле является резервным и должен сбрасываться при передаче и игнорироваться на приемной стороне. Бит 7 (I/E) указывает тип метрики (внутренняя или внешняя) для всех четырех вариантов TOS и должен сбрасываться (0) для внутренней метрики.

DELAY METRIC

Значение метрики задержки для канала к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

EXPENSE METRIC

Значение метрики стоимости для канала к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

ERROR METRIC

Значение метрики ошибок на канале к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

IP ADDRESS

Четырехоктетный адрес IP.

SUBNET MASK

4 октета маски подсети IP.

5.3.5 Link State PDU уровня 2

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

Набор идентификаторов NLPID для протоколов сетевого уровня, которые данная промежуточная система способна ретранслировать. Должно присутствовать один раз в LSP с номером 0.

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

NLPID – зарегистрированный ISO/TR 9577 идентификатор протокола.

IP Interface Address

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

Это поле может указываться неоднократно в LSP с любым номером. Когда маршрутизатор относится к обоим уровням 1 и 2, он должен указывать одинаковые адреса IP в LSP уровней 1 и 2.

CODE – 132

LENGTH – общий размер поля VALUE (4 октета на каждый адрес).

VALUE

                                Число октетов
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+

IP ADDRESS – 4-октетный адрес IP.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

IP Internal Reachability Information

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

Поле может включаться неоднократно в LSP с любым номером, однако не должно появляться в LSP псевдоузлов.

CODE – 128.

LENGTH – кратно 12.

VALUE

                                Число октетов
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+

DEFAULT METRIC

Значение принятой по умолчанию метрики для канала к указанному соседу. Бит 8 в этом поле является резервным и должен сбрасываться при передаче и игнорироваться на приемной стороне. Бит 7 (I/E) указывает тип метрики (внутренняя или внешняя) для всех четырех вариантов TOS и должен сбрасываться (0) для внутренней метрики.

DELAY METRIC

Значение метрики задержки для канала к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

EXPENSE METRIC

Значение метрики стоимости для канала к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

ERROR METRIC

Значение метрики ошибок на канале к указанному соседу. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

IP ADDRESS

Четырехоктетный адрес IP.

SUBNET MASK

4 октета маски подсети IP.

IP External Reachability Information

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

Поле может включаться неоднократно в LSP с любым номером, однако не должно появляться в LSP псевдоузлов.

CODE – 130.

LENGTH – кратно 12.

VALUE

                                Число октетов
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+
:                            :
:                            :
+----------------------------+
| 0 |I/E|   DEFAULT METRIC   |      1
+----------------------------+
| S | R |    DELAY METRIC    |      1
+----------------------------+
| S | R |   EXPENSE METRIC   |      1
+----------------------------+
| S | R |    ERROR METRIC    |      1
+----------------------------+
|         IP ADDRESS         |      4
+----------------------------+
|        SUBNET MASK         |      4
+----------------------------+

DEFAULT METRIC

Значение используемой по умолчанию метрики для пути к указанным адресам IP. Бит 8 в этом поле является резервным и должен сбрасываться при передаче и игнорироваться на приемной стороне. Бит 7 (I/E) указывает тип метрики (внутренняя или внешняя) для всех четырех вариантов TOS и может быть сброшен (0) для внутренней метрики или установлен (1) для внешней.

DELAY METRIC

Значение метрики задержки для канала к указанным адресам IP. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

EXPENSE METRIC

Значение метрики стоимости для канала к указанным адресам IP. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

ERROR METRIC

Значение метрики ошибок на канале к указанным адресам IP. Если данная IS не поддерживает такую метрику, ей следует установить бит S (1) для индикации этого. Бит 7 в этом поле является резервным и должен сбрасываться на передающей стороне и игнорироваться на приемной.

IP ADDRESS

Четырехоктетный адрес IP.

SUBNET MASK

4 октета маски подсети IP.

Inter-Domain Routing Protocol Information

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

Эти данные могут появляться неоднократно в LSP с любым номером.

CODE – 131.

LENGTH – полный размер поля VALUE.

VALUE

                                   Число октетов
+-------------------------------+
| Inter-Domain Information Type |      1
+-------------------------------+
|     External Information      |  Переменное
+-------------------------------+

Inter-Domain Information Type

Указывает тип внешней информации, содержащейся в поле.

External Information

Данные протокола междоменной маршрутизации, передаваемые протоколом IS-IS без изменения.

5.3.6 Complete Sequence Number PDU уровня 1

Ниже представлены дополнительные коды для поддержки IP.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.7 Complete Sequence Number PDU уровня 2

Ниже представлены дополнительные коды для поддержки IP.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.8 Partial Sequence Number PDU уровня 1

Ниже представлены дополнительные коды для поддержки IP.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.9 Partial Sequence Number PDU уровня 2

Ниже представлены дополнительные коды для поддержки IP.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

5.3.10 ISO 9542 ISH PDU

Ниже представлены дополнительные коды для поддержки IP.

Protocols Supported

Набор идентификаторов NLPID для протоколов сетевого уровня, которые данная промежуточная система способна ретранслировать. Указывается в ISO 9542 ISH PDU на каналах «точка-точка».

CODE – 129

LENGTH – общий размер поля VALUE (1 октет на кажый поддерживаемый протокол).

VALUE – 1 октет NLPID (в соответствии с ISO/TR 9577) для каждого поддерживаемого протокола данных.

                                Число октетов
+----------------------------+
|           NLPID            |      1
+----------------------------+
:                            :
:                            :
+----------------------------+
|           NLPID            |      1
+----------------------------+

NLPID – зарегистрированный ISO/TR 9577 идентификатор протокола.

Authentication Information

Данные, используемые для аутентификации PDU.

CODE – 133

LENGTH – размер VALUE.

VALUE – см. ниже.

6 Вопросы безопасности

Интегрированный протокол IS-IS обеспечивает передачу данных аутентификации во всех пакетах IS-IS. Это позволяет использовать множество механизмов проверки подлинности. Однако в настоящее время определен лишь механзм использования простых паролей, передаваемых без шифрования (Приложение D). Это не обеспечивает реальной защиты от злонамеренного поведения. Механизм следует считать лишь защитой от случайных ошибок, таких как некорректная конфигурация. Задание других механизмов выходит за рамки этой спецификации.

Иные аспекты безопасности не рассматриваются в этом документе.

7 Адрес автора

Ross Callon

Digital Equipment Corporation

550 King Street, LKG 1-2/A19

Littleton, MA 01460-1289

508-486-5009

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

8 Литература

[1] “Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)”, ISO DP 10589, February 1990.

[2] “Protocol for Providing the Connectionless-Mode Network Service”, ISO 8473, March 1987.

[3] “End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)”, ISO 9542, March 1988.

[4] Braden,R., and Postel,J., “Requirements for Internet Gateways”, RFC 1009, June 1987.

[5] Moy,J., “The OSPF Specification”, RFC 1131¹⁵, October 1989.

[6] Postel,J., “Internetwork Protocol”, RFC 791, September 1981.

[7] Postel,J., “Internet Control Message Protocol”, RFC 792, September 1981.

[8] “MIB for Use with the Extended OSI IS-IS in TCP/IP and Dual Environments”, forthcoming.

[9] GOSIP Advanced Requirements Group, “Government Open Systems Interconnection Profile (GOSIP) Version 2.0 [Final Text]”, Federal Information Processing Standard, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, October 1990.

[10] “Standard for Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards”, IEEE Standard 802.1a-1990.

Приложение A. Информация протокола междоменной маршрутизации

Это приложение определяет содержимое и кодирование полей протокола междоменной маршрутизации IDRPI (Inter-Domain Routing Protocol Information) и является неотъемлемой частью спецификации Integrated IS-IS. Однако предполагается возможность дополнения или замены этого приложения в будущем.

A.1 Тип информации

Как указано в параграфах 3.4 и 5.3, поле IDRPI включает 1 октет типа данных междоменной маршрутизации и информационное поле переменного размера. В этом параграфе описаны исходные значения типов данных междоменной маршрутизации. Другие значения могут выделяться и поддерживаться в будущих версиях RFC Assigned Numbers. Выделенные значения типов показаны ниже.

Тип 1 указывает использование данных междоменной маршрутизации в определяемом локальным доменом формате.

Тип 2 указывает, что данные протокола междоменной маршрутизации включают номер автономной системы, служащий для указания сведений о внешней доступности IP. В этом случае запись данных протокола междоменной маршрутизации должна включать единственный номер AS, которым помечаются все последующие записи External IP Reachability до конца пакета LSP или следующего включения поля Inter-Domain Routing Protocol Information.

A.2 Кодирование

Как указано в параграфе 5.3.5, записи IDPRI представляются полем переменного размера.

VALUE CODE – 131.

LENGTH – полный размер поля VALUE.

VALUE

                                   Число октетов
+-------------------------------+
| Inter-Domain Information Type |      1
+-------------------------------+
|     External Information      |  Переменное
+-------------------------------+

Inter-Domain Information Type

Указывает тип внешней информации, содержащейся в поле.

External Information

Данные протокола междоменной маршрутизации, передаваемые протоколом IS-IS без изменения.

Поле типа данных междоменной маршрутизации указывает тип информации в поле External Information.

Тип 0 является резервным (недопустимо его передавать, а на приемной стороне следует игнорировать).

Тип 1 указывает, что поле External Information содержит информацию в заданном локально формате.

Тип 2 указывает, что External Information содержит номер автономной системы, относящийся к последующим записям о внешней доступности IP. В этом случае запись данных протокола междоменной маршрутизации должна содержать один 2-октетный номер AS. Тег AS связывается с последующими записями IP External Reachability до конца LSP или следующего поля Inter-Domain Routing Protocol Information. Поле VALUE показано ниже.

VALUE

                                     Число октетов
+---------------------------------+
| Inter-Domain Information Type=2 |      1
+---------------------------------+
|   Autonomous System Number      |      2
+---------------------------------+

Приложение B. Кодирование порядковых номеров пакетов

Протокол Integrated IS-IS, определенный в этой спецификации, использует стандарт ISO Draft Proposed для внутридоменной маршрутизации (ISO DP 10589 [1]) как базовый протокол маршрутизации, добавляя поддержку IP.

Однако DP 10589 содержит ошибку, связанную с представлением полей переменного размера в пакетах SNP. В частности, DP 10589 задает кодирование полей переменного размера в SNP негибким способом (нельзя определить дополнительные поля переменного размера для пакетов SNP), не совместимым с представлением полей переменного размера в других пакетах IS-IS и ES-IS.

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

В этом приложении описано кодирование SNP с учетом исправлений для полей переменного размера. Приложение является неотъемлемой частью спецификации Integrated IS-IS.

В этом приложении показано кодирование SNP для работы только с протоколом OSI. Для использования с IP и в интегрированном варианте в SNP применяются также дополнительные поля переменного размера, описанные в параграфах 5.3.6 – 5.3.9.

B.1 Complete Sequence Numbers PDU уровня 1

                                    Число октетов
+--------------------------------+
|     INTRA-DOMAIN ROUTEING      |      1
|     PROTOCOL DISCRIMINATOR     |
+--------------------------------+
|        LENGTH INDICATOR        |      1
+--------------------------------+
|    VERSION/PROTOCOL ID EXT     |      1
+--------------------------------+
|            RESERVED            |      1
+--------------------------------+
| R | R | R |        TYPE        |      1
+--------------------------------+
|            VERSION             |      1
+--------------------------------+
|              ECO               |      1
+--------------------------------+
|            USER ECO            |      1
+--------------------------------+
|           PDU LENGTH           |      2
+--------------------------------+
|           SOURCE ID            |      7
+--------------------------------+
|          START LSP ID          |      8
+--------------------------------+
|           END LSP ID           |      8
+================================+====================
|     VARIABLE LENGTH FIELDS     |   Переменное
+--------------------------------+

INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR

Константа архитектуры.

LENGTH INDICATOR

Размер заголовка в октетах (33).

VERSION/PROTOCOL ID EXTENSION

1

RESERVED

Передается 0, на приемной стороне игнорируется.

TYPE

(Биты 1 – 5) – 24. Отметим, что биты 6 – 8 являются резервными (передается 0, на приемной стороне игнорируются).

VERSION

1

ECO

Передается 0, на приемной стороне игнорируется.

USER ECO

Передается 0, на приемной стороне игнорируется.

PDU LENGTH

Полный размер PDU в октетах с учетом заголовка.

SOURCE ID

7-октетный идентификатор промежуточной системы (Circuit ID = 0), создаваемый этим Sequence Number PDU.

START LSP ID

8-октетный идентификатор первого LSP в диапазоне, охватываемом данным Complete Sequence Number PDU.

END LSP ID

8-октетный идентификатор последнего LSP в диапазоне, охватываемом данным Complete Sequence Number PDU.

VARIABLE LENGTH FIELDS

Поля в представленной ниже форме.

                                    Число октетов
+--------------------------------+
|              CODE              |      1
+--------------------------------+
|             LENGTH             |      1
+--------------------------------+
|             VALUE              |    LENGTH
+--------------------------------+

Любые нераспознанные коды в принятых CSNP игнорируются. Определенные сейчас коды приведены ниже.

LSP Entries

Это поле может присутствовать неоднократно и в таких случаях поля следует сортировать по LSPID.

CODE – 9

LENGTH – полный размер поля VALUE.

VALUE – список записей LSP в показанной ниже форме.

                                    Число октетов
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+
:                                :
:                                :
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+

REMAINING LIFETIME

Оставшееся время жизни пакета LSP.

LSP ID

8-октетный идентификатор LSP, к которому относится запись.

LSP SEQ NUMBER

Порядковый номер LSP.

CHECKSUM

Контрольная сумма, указанная в LSP.

Записи следует сортировать в порядке LSPID (октет номера LSP в LSPID является младшим).

B.2 Complete Sequence Numbers PDU уровня 2

                                    Число октетов
+--------------------------------+
|     INTRA-DOMAIN ROUTEING      |      1
|     PROTOCOL DISCRIMINATOR     |
+--------------------------------+
|        LENGTH INDICATOR        |      1
+--------------------------------+
|    VERSION/PROTOCOL ID EXT     |      1
+--------------------------------+
|            RESERVED            |      1
+--------------------------------+
| R | R | R |        TYPE        |      1
+--------------------------------+
|            VERSION             |      1
+--------------------------------+
|              ECO               |      1
+--------------------------------+
|            USER ECO            |      1
+--------------------------------+
|           PDU LENGTH           |      2
+--------------------------------+
|           SOURCE ID            |      7
+--------------------------------+
|          START LSP ID          |      8
+--------------------------------+
|           END LSP ID           |      8
+================================+====================
|     VARIABLE LENGTH FIELDS     |   Переменное
+--------------------------------+

INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR

Константа архитектуры.

LENGTH INDICATOR

Размер заголовка в октетах (33).

VERSION/PROTOCOL ID EXTENSION

1

RESERVED

Передается 0, на приемной стороне игнорируется.

TYPE

(Биты 1 – 5) – 25. Отметим, что биты 6 – 8 являются резервными (передается 0, на приемной стороне игнорируются).

VERSION

1

ECO

Передается 0, на приемной стороне игнорируется.

USER ECO

Передается 0, на приемной стороне игнорируется.

PDU LENGTH

Полный размер PDU в октетах с учетом заголовка.

SOURCE ID

7-октетный идентификатор промежуточной системы (Circuit ID = 0), создаваемый этим Sequence Number PDU.

START LSP ID

8-октетный идентификатор первого LSP в диапазоне, охватываемом данным Complete Sequence Number PDU.

END LSP ID

8-октетный идентификатор последнего LSP в диапазоне, охватываемом данным Complete Sequence Number PDU.

VARIABLE LENGTH FIELDS

Поля в представленной ниже форме.

                                    Число октетов
+--------------------------------+
|              CODE              |      1
+--------------------------------+
|             LENGTH             |      1
+--------------------------------+
|             VALUE              |    LENGTH
+--------------------------------+

Любые нераспознанные коды в принятых CSNP игнорируются. Определенные сейчас коды приведены ниже.

LSP Entries

Это поле может присутствовать неоднократно и в таких случаях поля следует сортировать по LSPID.

CODE – 9

LENGTH – полный размер поля VALUE.

VALUE – список записей LSP в показанной ниже форме.

                                    Число октетов
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+
:                                :
:                                :
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+

REMAINING LIFETIME

Оставшееся время жизни пакета LSP.

LSP ID

8-октетный идентификатор LSP, к которому относится запись.

LSP SEQ NUMBER

Порядковый номер LSP.

CHECKSUM

Контрольная сумма, указанная в LSP.

Записи следует сортировать в порядке LSPID (октет номера LSP в LSPID является младшим).

B.3 Partial Sequence Numbers PDU уровня 1

                                    Число октетов
+--------------------------------+
|     INTRA-DOMAIN ROUTEING      |      1
|     PROTOCOL DISCRIMINATOR     |
+--------------------------------+
|        LENGTH INDICATOR        |      1
+--------------------------------+
|    VERSION/PROTOCOL ID EXT     |      1
+--------------------------------+
|            RESERVED            |      1
+--------------------------------+
| R | R | R |        TYPE        |      1
+--------------------------------+
|            VERSION             |      1
+--------------------------------+
|              ECO               |      1
+--------------------------------+
|            USER ECO            |      1
+--------------------------------+
|           PDU LENGTH           |      2
+--------------------------------+
|           SOURCE ID            |      7
+--------------------------------+
|          START LSP ID          |      8
+--------------------------------+
|           END LSP ID           |      8
+================================+====================
|     VARIABLE LENGTH FIELDS     |   Переменное
+--------------------------------+

INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR

Константа архитектуры.

LENGTH INDICATOR

Размер заголовка в октетах (17).

VERSION/PROTOCOL ID EXTENSION

1

RESERVED

Передается 0, на приемной стороне игнорируется.

TYPE

(Биты 1 – 5) – 26. Отметим, что биты 6 – 8 являются резервными (передается 0, на приемной стороне игнорируются).

VERSION

1

ECO

Передается 0, на приемной стороне игнорируется.

USER ECO

Передается 0, на приемной стороне игнорируется.

PDU LENGTH

Полный размер PDU в октетах с учетом заголовка.

SOURCE ID

7-октетный идентификатор промежуточной системы (Circuit ID = 0), создаваемый этим Sequence Number PDU.

VARIABLE LENGTH FIELDS

Поля в представленной ниже форме.

                                    Число октетов
+--------------------------------+
|              CODE              |      1
+--------------------------------+
|             LENGTH             |      1
+--------------------------------+
|             VALUE              |    LENGTH
+--------------------------------+

Любые нераспознанные коды в принятых CSNP игнорируются. Определенные сейчас коды приведены ниже.

LSP Entries

Это поле может присутствовать неоднократно и в таких случаях поля следует сортировать по LSPID.

CODE – 9

LENGTH – полный размер поля VALUE.

VALUE – список записей LSP в показанной ниже форме.

                                    Число октетов
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+
:                                :
:                                :
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+

REMAINING LIFETIME

Оставшееся время жизни пакета LSP.

LSP ID

8-октетный идентификатор LSP, к которому относится запись.

LSP SEQ NUMBER

Порядковый номер LSP.

CHECKSUM

Контрольная сумма, указанная в LSP.

Записи следует сортировать в порядке LSPID (октет номера LSP в LSPID является младшим).

B.4 Partial Sequence Numbers PDU уровня 2

                                    Число октетов
+--------------------------------+
|     INTRA-DOMAIN ROUTEING      |      1
|     PROTOCOL DISCRIMINATOR     |
+--------------------------------+
|        LENGTH INDICATOR        |      1
+--------------------------------+
|    VERSION/PROTOCOL ID EXT     |      1
+--------------------------------+
|            RESERVED            |      1
+--------------------------------+
| R | R | R |        TYPE        |      1
+--------------------------------+
|            VERSION             |      1
+--------------------------------+
|              ECO               |      1
+--------------------------------+
|            USER ECO            |      1
+--------------------------------+
|           PDU LENGTH           |      2
+--------------------------------+
|           SOURCE ID            |      7
+--------------------------------+
|          START LSP ID          |      8
+--------------------------------+
|           END LSP ID           |      8
+================================+====================
|     VARIABLE LENGTH FIELDS     |   Переменное
+--------------------------------+

INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR

Константа архитектуры.

LENGTH INDICATOR

Размер заголовка в октетах (17).

VERSION/PROTOCOL ID EXTENSION

1

RESERVED

Передается 0, на приемной стороне игнорируется.

TYPE

(Биты 1 – 5) – 27. Отметим, что биты 6 – 8 являются резервными (передается 0, на приемной стороне игнорируются).

VERSION

1

ECO

Передается 0, на приемной стороне игнорируется.

USER ECO

Передается 0, на приемной стороне игнорируется.

PDU LENGTH

Полный размер PDU в октетах с учетом заголовка.

SOURCE ID

7-октетный идентификатор промежуточной системы (Circuit ID = 0), создаваемый этим Sequence Number PDU.

VARIABLE LENGTH FIELDS

Поля в представленной ниже форме.

                                    Число октетов
+--------------------------------+
|              CODE              |      1
+--------------------------------+
|             LENGTH             |      1
+--------------------------------+
|             VALUE              |    LENGTH
+--------------------------------+

Любые нераспознанные коды в принятых CSNP игнорируются. Определенные сейчас коды приведены ниже.

LSP Entries

Это поле может присутствовать неоднократно и в таких случаях поля следует сортировать по LSPID.

CODE – 9

LENGTH – полный размер поля VALUE.

VALUE – список записей LSP в показанной ниже форме.

                                    Число октетов
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+
:                                :
:                                :
+--------------------------------+
|       REMAINING LIFETIME       |      2
+--------------------------------+
|             LSP ID             |      8
+--------------------------------+
|         LSP SEQ NUMBER         |      4
+--------------------------------+
|            CHECKSUM            |      2
+--------------------------------+

REMAINING LIFETIME

Оставшееся время жизни пакета LSP.

LSP ID

8-октетный идентификатор LSP, к которому относится запись.

LSP SEQ NUMBER

Порядковый номер LSP.

CHECKSUM

Контрольная сумма, указанная в LSP.

Записи следует сортировать в порядке LSPID (октет номера LSP в LSPID является младшим).

Приложение C. Расчет Dijkstra и пересылка

Приложение Annex C.2 к ISO DP 10589 [1] задает алгоритм SPF (Dikskstra) для расчета маршрутов в протоколе IS-IS. Это приложение описывает изменение алгоритма SPF для поддержки маршрутизации IP и двойной маршрутизации, а также указывает совместимый метод пересылки пакетов IP. Это определяет порядок предпочтения маршрутов, совместимый с описанным в параграфе 3.10.

Это приложение преследует лишь информационные цели.

C.1 Алгоритм SPF для IP и двойного стека

В этом параграфе описан алгоритм SPF для расчета маршрутов в протоколе IS-IS, поддерживающий TCP/IP и OSI. Этот алгоритм основан на расширении алгоритма из приложения C.2 к стандарту ISO DP 10589 [1].

В качестве основы служит алгоритм Dijkstra, известный как расчет кратчайшего пути (SPF – shortest path first). Сложность вычислений для этого алгоритма пропорциональна квадрату числа узлов, а для малозаселенных сетей может быть снижена до числа каналов в домене, умноженного на логарифм числа узлов.

Возможна дополнительная оптимизация расчетов.

1. Если метрика маршрутизации задана в небольшом конечном поле (как в этом стандарте), множитель log n можно исключить за счет применения структур данных, поддерживающих отдельный список систем для каждого значения метрики, вместо сортировки систем по логической дистанции.
2. Обновления можно выполнять постепенно (incrementally) без полного пересчета. Однако периодически нужно повторять полный расчет для гарантированного восстановления при повреждении данных и исследования показывают, что при очень малом числе изменений в каналах (возможно 2) ожидаемая сложность инкрементного обновления может превысить сложность полного расчета. Поэтому здесь представлен лишь полный расчет.
3. При изменении данных лишь в LSP одной конечной системы, не нужно пересчитывать все дерево Dijkstra. Применение подходящих структур данных позволяет присоединять и отсоединять конечные системы (включая записи доступности IP) как листья дерева с соответствующим изменением записей в базе данных пересылки.

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

C.1.1 Базы данных

PATHS

Представляет ациклический ориентированнй граф кратчайших путей от системы S, выполняющей расчет. Хранится в форме триплетов <N,d(N),{Adj(N)}>.

N

Идентификатор системы. В алгоритме уровня 1 это 6-октетный ID конечной системы OSI, 7-октетный ID маршрутизатора или 8-октетный идентификатор записи IP Internal Reachability Information. Для маршрутизаторов, не являющихся псевдоузлами, это 6-октетный идентификатор системы с добавленным в конце октетом 0. Для псевдоузлов это 7-октетное значение, состоящее из 6 октетов Designated Intermediate System ID и дополнительного октета, назначенного Destinated Router.

Записи IP Internal Reachability Information состоят из 4 октетов адреса IP и 4 октетов маски подсети. Эти записи всегда являются листьями (End System) в PATHS.

В алгоритме уровня 2 это 7-октетный идентификатор маршрутизатора или псевдоузла (как в алгоритме уровня 1), префикс адреса OSI переменного размера, 8-октетная запись IP Internal Reachability Information Entry или 8-октетная запись IP External Reachability Information. Адресные префиксы OSI и записи IP Reachability Information всегда являются листьями (End System) в PATHS. Записи IP Reachability Information являются парами [IP-адрес, маска подсети].

d(N)

Удаление N от S (т. е. суммарное значение метрики от N до S).

{Adj(N)}

Множество действительный смежностей, которые S может использовать для пересылки в N.

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

TENT

Список триплетов вида <N,d(N),{Adj(N)}>.

TENT можно рассматривать как примерное размещение системы в PATHS. Иными словами, триплет <N,x,{A}> в TENT означает, что при размещении N в PATHS поле d(N) будет иметь значение x, но N не может включаться в PATHS, пока нет гарантии отсутствия более короткого пути, нежели x. Точно так же триплет <N,x,{A,B}> в TENT означает, что при размещении N в PATHS поле d(N) будет иметь значение x через смежность A или B.

Реализациям предлагается поддерживать базу данных TENT в форме списка триплетов <*,Dist,*>, отсортированного по дистанции Dist. Кроме того, нужно обеспечить возможность обрабатывать системы, являющиеся псевдоузлами, до прочих систем с тем же значеним Dist.

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

C.1.2 Использование метрики в алгоритме SPF

Внутренние метрики не сравниваются с внешними. Для внешних маршрутов (к адресатам за пределами домена маршрутизации) стоимость d(N) пути от N к S может включать внутреннюю и внешнюю метрику. Поэтому d(N) может поддерживаться как двумерный вектор (значения внутренней и внешней метрики). При инициализации d(N) используются значение [0, 0] для внутренней и внешней метрики.

Если при инкрементировании d(N) значение внутренней метики не достигло максимума (MaxPathMetric), оно увеличивается на 1, а внешняя метрика не меняется. Если же значение внутренней метрики достигло MaxPathMetric, оно сбрасывается в 0, а внешняя метрика увеличивается на 1. Отметим, что это можно реализовать достаточно просто за счет поддержки внешней метрики в форме старших битов удаленности ((distance).

В приведенном ниже коде алгоритма текущая длина пути хранится в переменной tentlength, которая имеет двумерную форму tentlength=[internal metric, external metric] и применяется для сравнения длины текущего пути с d(N), как описано выше. Инкрементирование tentlength выполняется так же, как для d(N).

C.1.3 Обзор алгоритма

Базовый алгоритм, создающий PATHS с нуля, начинается с включения выполняющей расчета системы в PATHS (нет более короткого пути, чем к себе – SELF). Затем TENT загружается из локальной базы данных смежности.

Отметим, что система не включается в PATHS, пока к ней не найден кратчайший путь. При включении системы N в PATHS путь к каждому ее соседу M через нее проверяется как путь N плюс канал между N и M. Если <M,*,*> имеется в PATHS, новый путь будет длиннее и его следует игнорировать.

Если <M,*,*> имеется в TENT и новый путь короче, старая запись удаляется из TENT и заменяется новым путем. Если новый путь имеет такую же длину, как имеющийся в TENT, в наборе потенциальных смежностей {Adj(M)} устанавливается объединение прежнего (из TENT) и нового {Adj(N)}. Если M нет в TENT, путь добавляется в TENT.

Затем алгоритм находит в TENT триплет <N,x,{Adj(N)}> с минимальным x. Это выполняется эффективно в результате описанной выше оптимизации. Когда список триплетов для дистанции Dist исчерпан, алгоритм инкрементирует Dist, пока не найдет триплет вида <*,Dist,*>.

N помещается в PATHS. Мы знаем, что сейчас к N не может быть пути короче x, поскольку все пути через уже включенные в PATHS системы были рассмотрены, а пути через системы из TENT будут длиннее x, поскольку x является минимальным в TENT.

Когда TENT опустошается, расчет PATHS будет завершен. Отметим, что внешние метрики могут полявляться лишь в записях IP External Reachability Information, которые соответствуют листьям (т. е. конечным системам в PATHS). Любой маршрут, использующий запись с внешней метрикой, будет считаться менее предпочтительным, чем маршрут с внутренней метрикой. Это предполагает, что при добавлении систем в PATHS все системы, доступные по внутренним маршрутам будут предшествовать системам, доступным через внешние маршруты.

C.1.4 Алгоритм

Алгоритм принятия решений должен работать однократно для каждой поддерживаемой метрики (т. е. для каждого поддерживаемого ToS). Маршрутизатор уровня 1 должен запускать алгоритм в использованием базы данных LSP уровня 1 для расчета путей этого уровня (для маршрутизаторов, не участвующих в работе уровня 2, это включает путь к ближайшему подключенному маршрутизатору уровня 2). Маршрутизаторы уровня 2 отдельно запускают этот алгоритм с использованием базы данных LSP уровня 2 для расчета путей на этом уровне. Маршрутизаторы с поддержкой IP должны хранить внутренние маршруты IP уровня 2 отдельно от внешних маршрутов IP этого уровня.

Отметим, что это предполагает для маршрутизаторов, работающих на уровнях 1 и 2, а также поддерживающих все 4 метрики маршрутизации необходимость запуска алгоритма SPF 8 раз (без учета восстановления).

Если система является маршрутизатором уровня 2, поддерживающим дополнительную функцию восстановления при разделе (partition repair), алгоритм принятия решения для расчета путей уровня 1 должен запускаться дважды для принятой по умолчанию метрики. Первый запуск выполняется для определения адресов manualAreaAddresses области, доступных в этом разделе (partition) и выбора назначенного маршрутизатора (Partition Designated Level 2 Router) для раздела. Этот маршрутизатор будет определять наличие разделения и создавать виртуальные каналы уровня 1 к другим назначенным маршрутизаторам разделов в области для восстановления раздела уровня 1. Этот вопрос рассмотрен в параграфе 7.2.10 [1].

Описываемый здесь алгоритм SPF расчитывает маршруты для OSI и IP. В частности, расчитывыются маршруты ко всем систмам N, где N может быть OSI End System, OSI-адрес маршрутизатора или запись IP-доступности. При расчете таблицы пересылки имеется зависимый от реализации вопрос раздельного хранения таблиц пересылки IP и OSI. В этом приложении таблицы указываются раздельно, если это уместно, но это не задает какого-либо конкретного метода реализации.

OSI и IP используют разные механизмы определения принадлежности пакета к области (в частности, OSI использует для этого адрес области, а IP определяет не входящих в область адресатов путем просмотра таблицы пересылки уровня 1). Маршруты к ближайшему маршрутизатору уровня 2 создают раздельные записи в таблице пересылки для OSI и IP. Для IP маршут к ближайшему подключенному маршрутизатору уровня 2 может быть включен в таблицу пересылки как принятый по умолчанию путь (т. е. маршрут с маской подсети 0).

Одним из подходов является размещение результатов каждого запуска алгоритма Dijkstra в отдельную таблицу пересылки. Для маршрутизатора, работающего на уровнях 1 и 2 (включая внутренние и внешние маршруты уровня 2) и поддерживающего все 4 варианта TOS, это приведет к созданию 12 разных таблиц для протокола IP. Реализация может минимизировать число таблиц пересылки, объединяя результаты нескольких расчетов Dijkstra в одну таблицу по поддерживаемым TOS. Этот подход рассматривается в параграфе C.2.

В алгоритм SPF из параграфа C.2.3 в [1] внесен ряд изменений, описанных ниже.

Этап 0. Инициализация TENT и PATHS пустыми значениями, tentlength = [internalmetric=0, externalmetric=0] (tentlength элементы pathlength в TENT, которые будут проверяться).

1. В PATHS добавляется <SELF,0,W>, где W – специальное значение, указывающее, что трафик себе (SELF) передается внутренним процессам, а не пересылается.
2. Загружается в TENT локальная база данных о смежности (каждая запись в TENT должна быть помечена как конечная система или маршрутизатор, чтобы проверка в конце этапа 2 была выполнена корректно; каждая запись IP-доступности включается как смежность и помечается как конечная система). Для каждой смежности Adj(N), включая заданные вручную OSI Manual Adjacency уровня 1, разрешенные доступные адреса OSI уровня 2 и записи о доступности IP, на включенных устройствах для системы N в SELF в состоянии Up вычисляется:d(N) – стоимость родительского устройства в смежности (N), полученная из metric.k, где k – одна из метрик {default, metric, monetary, error};Adj(N) – номер смежности с N.
3. Если триплет <N,x,{Adj(M)}> присутствует в TENT и x = d(N), то {Adj(M)} <— {Adj(M)} U {Adj(N)}.
4. Если N является маршрутизатором или записью конечной системы OSI и число смежностей в {Adj(M)} превышает maximumPathSplits, избыточные смежности удаляются, как описано в Clause 7.2.7 [1]. Если N — это запись IP-доступности, можно удалить избыточные смежности при желании. Это не влияет на корректность маршрутизации, но может привети к утрате детермированности маршрутов IP (т. е. пакеты IP продолжат идти по оптимальному пути внутри области, но не обязательно будут следовать точно по маршруту, который будет ожидать любой конкретный маршрутизатор).
5. Если x < d(N), не делается ничего.
6. Если x > d(N), из TENT удаляется <N,x,{Adj(M)}> и добавляется <N,d(N),{Adj(N)}>.
7. Если <N,x,{Adj(M)}> нет в TENT, туда добавляется триплет <N,d(N),{Adj(N)}>.
8. Добавляются системы, с которыми у локального маршрутизатора нет смежности, но которые упомянуты в LSP соседних псевдоузлов. Для таких систем устанавливается смежность назначенного маршрутизатора. Отметим, что это не включает записей IP-доступности из LSP соседних псевдоузлов (их нет в таких LSP).
9. Для всех широковещательных узлов в состоянии On (вкл). Отыскивается LSP псевдоузла для этого устройства (в частности, LSP с номером 0 и с первыми 7 октетами LSPID равными LnCircuitID для этого устройства, где n соответствует уровню маршрутизации). При наличии для всех соседей N, указанных во всех LSP этого узла, которых нет в TENT, туда добавляется запись <N,d(N),{Adj(N)}>, гдеd(N) = metric.k для устройства;Adj(N) = номер смежности для назначенного маршрутизатора (DR).
10. Переход к этапу 2.

Этап 1. Проверяются нулевой Link State PDU от P, система включается в PATHS (LSP с теми же превыми 7 октетами LSPID как P и номером LSP 0).

1. При наличии LSP и сброшенном бите Infinite Hippity Cost для кажого LSP из P (т. е. для LSP с одинаковыми первыми 7 октетами LSPID и P независимо от номера LSP) рассчитывается dist(P,N) = d(P) + metric.k(P,N) для каждого соседа N (конечные системы и маршрутизаторы) системы P. Если бит Infinite Hippity Cost установлен, рассматриваются лишь конечные системы из числа соседей P. Отметим, что к этим системам относятся записи IP-доступности, включенные в LSP от системы P. Здесь d(P) является вторым элементом триплета <P,d(P),{Adj(P)}>, а metric.k(P,N) является стоимостью канала от P к N, указанной в Link State PDU от P.
2. Если dist(P,N) > MaxPathMetric, не делается ничего.
3. Если <N,d(N),{Adj(N)}> присутствует в PATHS, не делается ничего.Отметим, что d(N) должно быть меньше dist(P,N), иначе N не будет помещаться в PATHS. Здесь возможна дополнительная проверка этого условия.
4. If <N,x,{Adj(N)}> присутствует в TENT,
   1. Если x = dist(P,N), выполняется {Adj(N)} <– {Adj(N)} U {Adj(P)}.
   2. Если N является маршрутизатором или конечной системой OSI и число смежностей в {Adj(N)} больше maximumPath Splits, избыточные смежности удаляются, как описано в параграфе 7.2.7 [1]. Для записей IP-доступности удаление избыточных смежностей возможно по желанию. Это не влияет на корректность маршрутизации, но может привети к утрате детермированности маршрутов IP (т. е. пакеты IP продолжат идти по оптимальному пути внутри области, но не обязательно будут следовать точно по маршруту, который будет ожидать любой конкретный маршрутизатор).
   3. Если x < dist(P,N), не делается ничего.
   4. Если x > dist(P,N), из TENT удаляется <N,x,{Adj(N)}> и добавляется <N,dist(P,N),{Adj(P)}>.
5. Если триплета <N,x,{Adj(N)}> нет в TENT, туда добавляется <N,dist(P,N),{Adj(P)}>.

Этап 2. При пустом TENT работа завершается, в противном случае выполняются перечисленные ниже действия.

1. Отыскивается элемент <P,x,{Adj(P)}> с минимальным x, как описано ниже.
   1. Если элемент <*,tentlength,*> остается в TENT в списке для tentlength, этот элемент выбирается. При наличии нескольких элементов в списке для tentlength, предпочтительно выбирать элемент для системы, являющейся псевдоузлом (если они есть). Если больше нет элементов в списке для tentlength, значение tentlength инкрементируется и этап 2 повторяется.
   2. Триплет <P,tentlength,{Adj(P)}> удаляется из TENT.
   3. Триплет <P,d(P),{Adj(P)}> добавляется в PATHS.
   4. Если запущен процесс принятия решения на уровне 2 и только что добавленная в PATHS система указала себя как промежуточную систему Partition Designated уровня 2, в PATHS добавляется <AREA.P,d(P),{Adj(P)}>, где AREA.P – Network Entity Title на другой стороне виртуального канала (Virtual Link) из первой области AREA в LSP системы P с добавлением в конце идентификатора системы P.
   5. Если только что добавленная в PATHS система является конечной (хостом), выполняется переход к этапу 2, в остальных случаях – к этапу 1.

Отметим, что в контексте уровня 2 конечными системами считаются Reachable Address Prefixes (для OSI), Area Addresses с нулевой стоимостью (для OSI) и записи IP-доступности (для внутренних и внешних адресов).

C.2 Пересылка пакетов IP

Алгоритм SPF, описанный в параграфе C.1, можно использовать при расчете (логически) разделенных таблиц пересылки IP для каждого TOS с маршрутами уровня 1, а также внутренними и внешними маршрутами уровня 2. В параграфе C.2.1 рассмотрена пересылка пакетов IP на основе этого набора таблиц, а в параграфе C.2.2 – способ объединения таблиц пересылки по поддерживаемым TOS.

C.2.1 Базовый метод пересылки пакетов IP

На маршрутизаторах уровня 1 выполняются перечисленные ниже действия.

• Проверяется соответствие IP-адреса получателя в таблице пересылки уровня 1 для данного TOS.
• Проверяется соответствие IP-адреса получателя в таблице пересылки уровня 1 для TOS по умолчанию.
• Если для принятого по умолчанию TOS задана более длинная маска, эта запись используется для пересылки.
• Если маски одинаковы маска для данного TOS длиннее, применяется пересылка по записи для данного TOS.
• Если записей не найдено (включая маршрут по умолчанию16), адресат считается недоступным.

Для маршрутизаторов, работающих на уровнях 1 и 2, выполняются перечисленные ниже действия.

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

Для маршрутизаторов уровня 2 можно применять указанный выше алгоритм без проверки соответствия таблицам уровня 1.

Как отмечено в параграфе 3.10.2, для маршрутизаторов уровня 2, анонсирующих заданные вручную агрегированные адреса в своих LSP уровня 2, моугт существовать адреса IP, которые соответствуют заданным вручную адресам, но не соответствуют каким-либо адресам, доступным в этой области через уровень 1. Направленные по таким адресам пакеты обрабатываются в соответствии с параграфом 3.10.2. Это можно сделать путем добавления заданных вручную записей [IP-адрес, маска подсети] в таблицу пересылки уровня 2 (для соответствующего TOS) со специальным адресом «следующего интервала», задающим отбрасывание пакета. Это будет работать корректно, поскольку более желательные записи (такие как доставка корректному адресату через уровень 1 или более конкретный маршрут уровня 2) автоматически полчат предпочтение для пересылки по описанным выше правилам. Менее желательные маршруты(такие как внешние маршруты уровня 2) не будут появляться, поскольку другие маршрутизаторы уровня 2 будут доверять агрегированным адресам, анонсированным этим маршрутизатором.

C.2.2 Уменьшение размера таблиц пересылки IP

Несколько таблиц пересылки описанного в параграфе C.2.1 метода можно объединить в одну таблицу для каждого поддерживаемого TOS. При снижении числа таблиц пересылки IP предполагается, что любые две перекрывающиеся области идентичны или одна из них включена полностью в другую. Иными словами, для двух записей [IP-адрес, маска подсети] A и B наличие хотя бы одного адреса IP в обеих говорит, что (i) эти записи идентичны, (ii) A содержит в себе B (т. е., любой IP-адрес, соответствующий записи B будет соответствовать записи A) или (iii) B содержит в себе A.

Для отказа от этого допущения можно использовать маски подсетей с разрывом. Рассмотрим, например, 2 записи:

• A=[address=”01010101 00000101 00000000 00000000″, mask=”11111111 00001111 00000000 00000000″];
• B=[address=”01010101 01010000 00000000 00000000″, mask=”11111111 11110000 00000000 00000000″].

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

• имеются адреса IP, соответствующие A и B (например, 01010101 01010101 xxxxxxxx xxxxxxxx);
• имеются адреса IP, соответствующие A, но не B(например, 01010101 11110101 xxxxxxxx xxxxxxxx);
• имеются адреса IP, соответствующие B, но не A (например, 01010101 01011111 xxxxxxxx xxxxxxxx).

Сведение нескольких таблиц пересылки для каждого TOS в одну таблицу для этого TOS основано на использовании маршрута с наилучшим соответствием (best match) в комбинации со снижением числа записей в таблице для исключения записей, которые не будут выбраны (в соответствии с порядком предпочтения из параграфа 3.10). Алгоритм создания таблицы пересылки IP можно реализовать в соответствии с приведенным ниже описанием.

1. На основе алгоритма Dijkstra (параграф C.1) создаются отдельные таблицы для каждого поддерживаемого TOS с маршрутами уровня 1, а также внешними и внутренними маршрутами уровня 2 (каждая запись таблицы будет включать пару [IP-адрес, маска подсети], а также следующий маршрутизатор для пересылки соответствующих записи пакетов IP).
2. Каждая запись для маршрута уровня 1, включенная в таблицу пересылки IP уровня 1 для данного TOS, копируются в общую таблицу пересылки IP для этого TOS.
3. Для каждой записи X, помещенной в таблицу внутренней пересылки IP уровня 2 для TOS, отыскивается перекрывающаяся запись в таблице пересылки IP уровня 1 для этого и принятого по умолчанию TOS.
   1. Если в таблице пересылки уровня 1 найдена перекрывающаяся запись Y (для данного или принятого по умолчанию TOS), такая, что (i) Y содержит X или (ii) Y идентична X, запись X игнорируется.
   2. В противном случае X копируется в общую таблицу пересылки IP для данного TOS.
4. Для каждой записи X, помещенной в таблицу внешней пересылки IP уровня 2 для TOS, отыскивается перекрывающаяся запись в таблице пересылки IP уровня 1 для этого и принятого по умолчанию TOS, а также в таблице внутренней пересылки IP уровня 2 для этого и принятого по умолчанию TOS.
   1. Если найдена перекрывающаяся запись Y, (i) содержащая X или (ii) идентичная X, запись X игнорируется.
   2. В противном случае X копируется в общую таблицу пересылки IP для данного TOS.

Описанный метод создает 1 таблицу для каждого поддерживаемого TOS. Пересылка пакетов может быть упрощена.

1. Пакеты IP, отображенные на используемую по умолчанию (или не поддерживаемую) метрику TOS, проверяются по таблице для принятого по умолчанию TOS и выбирается наиболее точно соответствующая запись, по которой выполняется пересылка.
2. Пакеты, отображенные на конкретную метрику TOS, проверяются по таблице пересылки для этого TOS и выбирается наиболее точно соответствующая запись j. Просматривается также таблица для принятого по умолчанию TOS и в ней выбирается наиболее точно соответствующая запись k. Пересылка описана ниже.
   1. Если маска k длиннее маски j, испльзуется пересылка по записи k.
   2. Если маски j и k одинаковы, пересылка происходит по записи j.
   3. Если макса j длиннее маски k, пересылка происходит по записи j.

Приложение D. Поле Authentication

Использование поля Authentication выходит за рамки этой спецификации, одна есть острая потребность в простых механизмах (таких как простой пароль) аутентификации и обнаружения ошибок для защиты от некоторых типов ошибок. Поэтому в данном приложении рассматривается возможное использование поля. Приложение преследует лишь информационную цель.

D.1 Поле Authentication в пакетах IS-IS

Все пакеты IS-IS могут включать поле Authentication, как описано в параграфе 3.9 и разделе 5. Как отмечено в разделе 5, это поле представляется триплетом (Code, Length, Value). Это приложение предлагает включать в поле Value один октет поля Authentication Type, а также поле Authentication Information переменного размера. Конкретные значения Authentication Type выделяются для паролей, передаваемых в открытом виде без шифрования. Кодирование поля аутентификации описано ниже.

Authentication Information

Данные, служащие для аутентификацуии PDU.

CODE — 133.

LENGTH – полный размер поля VALUE.

VALUE

                                    Число октетов
+--------------------------------+
|      Authentication Type       |      1
+--------------------------------+
|   Authentication Information   |  Переменное
+--------------------------------+

Выделенные значения поля Authentication Type представлены ниже.

0 – резерв;

1 – простой пароль;

>1 – резерв.

D.2 Аутентификация типа 1 (простой пароль)

При использовании этого типа передается в открытом виде (без шифрования) пароль переменного размера в поле Authentication Information.

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

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

• Для пакетов IS-IS Hello и 9542 IS Hello следует использовать пароли на уровне канала.
• Для пакетов Link State уровня 1 следует использовать пароли на уровне области.
• Для пакетов Link State уровня 2 следует использовать пароли на уровне домена.
• Для пакетов Sequence Number уровня 1 следует использовать пароли на уровне области.
• Для пакетов Sequence Number уровня 2 следует использовать пароли на уровне домена.

Кроме того, для этих паролей нужно указать в конфигурации (i) Transmit Password с передаваемым паролем и (ii) Receive Passwords с паролями, которые могут поступать от других. Значение Transmit Password передается всегда, а Receive Passwords содержит пароли, которые воспринимаются при получении. Этот метод позволяет менять пароли без прерывания связности.

Рассмотрим в качестве примера случай, где для области задан пароль OLDAREAPASSWORD. В этом случае значением Transmit Password для области будет OLDAREAPASSWORD, а Receive Passwords будет иметь значение {OLDAREAPASSWORD}. Предположим, что принято решение заменить пароль на NEWERPASSWORD. Первым шагом будет настройка на всех маршрутизаторах области значения {OLDAREAPASSWORD, NEWERPASSWORD} для Receive Passwords. По завершении этого этапа все маршрутизаторы области могут использовать старый пароль OLDAREAPASSWORD в своих LSP уровня 1 и SNP. Однако они будут воспринимать и новый пароль NEWERPASSWORD. Вторым шагом будет настройка на всех маршрутизаторах передачи пароля NEWERPASSWORD. По завершении этого этапа все маршрутизаторы будут использовать для области новый пароль, но смогут воспринимать и старый. Финальным этапом является установка в Receive Passwords значения {NEWERPASSWORD}.

Такая настройка передаваемого и воспринимаемых паролей позволяет обеспечить непрерывность работы. Например, в середине второго этапа, описанного выше, некоторые маршрутизаторы области могут передавать LSP уровня 1 и SNP со старым паролем OLDAREAPASSWORD, а другие – с новым NEWERPASSWORD. Однако на этом этапе все маршрутизаторы области будут воспринимать LSP уровня 1 и SNP с тем и другим паролем.

Приложение E. Интегрированный IS-IS и мосты-маршрутизаторы

Устройства brouter выступают одновременно в качестве моста и маршрутизатора. Одним из вариантов работы является маршрутизация трафика IP и поддержка моста для остального трафика.

В зависимости от способа реализации моста-маршрутизатора и топологии сети может возникать неясная ошибка, в результате взаимодействия с протоколом Integrated IS-IS. В этом приложении рассматривается пример такой ошибки и способ решения проблемы.

Приложение представлено лишь с информационной целью.

E.1 Проблема

Предположим, что имеется мост-маршрутизатор, обрабатывающий пакеты IP как обычный маршрутизатор IP и служащий мостом для всех остальных пакетов. Пусть два маршрутизатора X и Y, реализующие интегрированный протокол IS-IS и имеющие по 2 интерфейса Ethernet, соединены мостом-маршрутизатором, как показано на рисунке.

     |                               |
+----+---+                      +----+---+
| Router |                      | Router |
|   X    |                      |   Y    |
+----+---+                      +----+---+
     |                               |
-----+------------+-   -+------------+----
                  |     |
                +-+-----+-+
                | Brouter |
                |    B    |
                +---------+

Предполохим, что на X и Y работает протокол Integrated IS-IS и оба маршрутизатора относятся к уровню 1 в одной области. Таким образом, X и Y передают пакеты IS-IS Hello в ЛВС. Эти пакеты Hello принимаются и пересылаются мосто-маршрутизатором (функция моста). Аналогично X и Y обмениваются пакетами IS-IS LSP. Brouter считает, что X и Y обмениваются пакетами OSI и пересылает их с использованием обычных функций моста. маршрутизаторам X и Y кажется, что они находятся в одной ЛВС, они знают 48-битовые адреса Ethernet друг друга и обмениваются маршрутной информацией.

Далее предположим, что X получает пакет IP, который нужно переслать через Y. Поскольку X считает, что Y находится в той же сети Ethernet, он просто пересылает пакет IP напрямую, используя обычную инкапсуляцию Ethernet и 48-битовый адрес Ethernet маршрутизатора Y в качестве адреса получателя в заголовке Ethernet. Brouter B, думая как мост, решит, что это пакет IP, который он не должен пересылать, будучи мостом. Думая же как маршрутизатор IP, Brouter B решит, что это пакет IP, который нужно переслать. Однако адрес Ethernet не относится к мосту-маршрутизатору, поэтому он будет проигнорирован и пакет IP не будет пересылаться.

Эта проблема прямо связана с тем, что X и Y обмениваются пакетами OSI для определения связности пути между собой, но затем пересылают по этому пути пакеты IP. При этом на пути между ними имеется устройство, по разному обрабатывающее пакеты OSI и IP.

Отметим, что подобные проблемы могут возникать и при более сложной топологии, когда мост-маршрутизатор по разному трактует пакеты OSI и IP.

E.2 Возможные решения

E.2.1 Усложненный мост-маршрутизатор

Одним из решений является некоторое усложнение моста-маршрутизатора B, как указано ниже.

• Для отличных от IP пакетов нужно выполнять функции моста (как и прежде).
• Для пакетов IP, направленных по широковещательным или групповым адресам Ethernet, выполнять функции маршрутизатора IP (как и прежде).
• Для пакетов IP, направленных по 48-битовым адресам Ethernet моста-маршрутизатора выполнять функции маршрутизатора IP (как и прежде).
• Для пакетов IP, переданных по 48-битовому адресу станции, который не относится к мосту-маршрутизатору, выполнять функции моста (измененное поведение).

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

E.2.2 Маршрутизаторы и мосты-маршрутизаторы с двойным стеком

Другим решенеим будет маршрутизация мостом-маршрутизатором обоих протоколов OSI и IP. Если Brouter использует для этого интегрированный протокол IS-IS, он может быть частью того же домена маршрутизации и взаимодействовать с ним подобно остальным маршрутизаторам с двойным стеком (за исключением выполнения функций моста для прочих протоколов). При использовании для маршрутизации OSI и IP иного протокола мост-маршрутизатор должен быть частью другого домена маршрутизации и может взаимодействовать с маршрутизаторами, использующими интегрированный протокол IS-IS, подобно другим внешним маршрутизаторам.