RFC 2105 Cisco Systems’ Tag Switching Architecture Overview

Network Working Group                                         Y. Rekhter
Request for Comments: 2105                                      B. Davie
Category: Informational                                          D. Katz
                                                                E. Rosen
                                                              G. Swallow
                                                     Cisco Systems, Inc.
                                                           February 1997

 

Обзор архитектуры коммутации по тегам Cisco Systems

Cisco Systems’ Tag Switching Architecture Overview

PDF

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

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

Примечание IESG

Протокол не является результатом работы какой-либо группы IETF или проектом стандарта. Широкое распространение документа и его внимательный обзор со стороны сообщества не обязательно обеспечат какие-либо преимущества.

Аннотация

Этот документ включает обзор новой модели пересылки пакетов на сетевом уровне, названной коммутацией по тегам (tag switching). Описаны две основные компоненты архитектуры коммутации по тегам — пересылка и управление. Пересылка осуществляется с помощью простых механизмов замены меток, а для управления применяются существующие протоколы маршрутизации сетевого уровня вкупе с механизмами привязки и распространения тегов. При коммутации по тегам могут сохраниться и даже улучшиться свойства масштабирования сетей IP. Хотя коммутация тегов не основана на технологии ATM, она может быть применена и в коммутаторах ATM. Рассматривается область применения и сценарии развертывания систем коммутации по тегам.

1. Введение

Непрерывное расширение сети Internet требует от сервис-провайдеров (ISP¹) повышения пропускной способности их сетей. Однако расширение Internet не является единственным фактором увеличения пропускной способности — расширяющееся использование multimedia-приложений также требует высокой пропускной способности. Запросы пропускной способности, в свою очередь, требуют повышения производительности маршрутизаторов (число пересылаемых пакетов в секунду) как для группового, так и для индивидуального трафика.

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

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

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

Остальная часть этого документа организована следующим образом — в разделе 2 описаны основные компоненты коммутации по тегам, в разделе 3 описана пересылка, в разделе 4 — управление, раздел 5 описывает использование коммутации по меткам с ATM, раздел 6 посвящен использованию коммутации по тегам для расширения диапазона качества обслуживания, в разделе 7 кратко описаны сценарии развертывания, f раздел 8 содержит резюме.

2. Компоненты коммутации по тегам

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

3. Компонента пересылки

Парадигма пересылки в коммутаторах по тегам основана на замене меток. При получении пакета с тегом коммутатором по тегам этот коммутатор использует тег в качестве индекса для поиска в своей базе TIB². Каждая запись TIB включает входящий тег и один или множество элементов вида (outgoing tag, outgoing interface, outgoing link level information³). Если коммутатор находит в базе запись, соответствующую входящему тегу в пакете, для каждого элемента (outgoing tag, outgoing interface, outgoing link level information) в этой записи он меняет тег в полученном пакете на исходящий тег, меняет в пакете информацию канального уровня (например, MAC-адрес) данными из элемента и пересылает пакет через указанный в элементе выходной интерфейс.

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

Во-вторых, решение о пересылке не зависит от «гранулярности» тегов. Например, один и тот же алгоритм пересылки может применяться для пакетов с индивидуальными и групповыми адресами — для индивидуального адреса в записи будет содержаться один элемент (outgoing tag, outgoing interface, outgoing link level information), а для группового таких элементов может оказаться множество (для каналов с множественным доступом в таких случаях информация канального уровня будет включать групповой MAC-адрес). Это показывает, как одна парадигма пересылки при коммутации по тегам может применяться для поддержки разных функций маршрутизации (например, индивидуальная, групповая и т. п.).

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

3.1. Инкапсуляция тегов

Теги могут передаваться в пакетах несколькими способами:

• как небольшая вставка⁴ между заголовками канального и сетевого уровней;

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

• как часть заголовка сетевого уровня (например, с использованием поля Flow Label в заголовке IPv6 при изменении семантики).

Таким образом можно реализовать коммутацию по тегам практически для любых сред, включая каналы «точка-точка», каналы с множественным доступом и ATM.

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

4. Управляющая компонента

Существенным для коммутации по тегам является понятие связки тега с маршрутизацией на сетевом уровне (маршрутом). Для обеспечения хорошей масштабируемости при расширении функциональности маршрутизации коммутация по тегам поддерживает широкий диапазон «гранулярности» пересылки. Одним из крайних случаев является привязка тега к группе маршрутов (более конкретно, к значению NLRI⁵ маршрутов данной группы). Другой крайностью является привязка тега к отдельному потоку трафика приложений (например, потоку RSVP). Тег можно также связать с деревом групповой пересылки (multicast tree).

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

4.1. Маршрутизация по адресатам

В этом параграфе описана поддержка с помощью коммутации по тегам маршрутизации по адресам получателей. Напомним, что при такой маршрутизации решение о пересылке принимается на основе адреса получателя в заголовке пакета и данных, хранящихся маршрутизатором в его базе FIB⁶. Маршрутизатор создает базу FIB с использованием информации, получаемой от протоколов маршрутизации (например, OSPF, BGP).

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

Существует три признанных метода выделения тегов и управления базами TIB⁷ – (a) выделение тегов в нисходящем направлении, (b) выделение тегов в нисходящем направлении по запросам и (c) выделение тегов в восходящем направлении. Во всех случаях коммутатор выделяет теги и связывает их с адресными префиксами в своей FIB. При нисходящем выделении передаваемый в пакете тег генерируется и привязывается к префиксу коммутатором на нисходящей стороне соединения (относительно направления потока данных). При восходящем выделении теги выделяются и привязываются на восходящей стороне соединения. Выделение по запросу означает, что теги будут выделяться и распространяться нисходящим коммутатором только при их запросе со стороны восходящего коммутатора. Методы (b) и (c) наиболее полезны для сетей ATM (см. раздел 5). Отметим, что при нисходящем выделении коммутатор отвечает за создание привязок тегов, которые применяются для входящих пакетов данных и получает привязки тегов для исходящих пакетов от своих соседей. При восходящем выделении коммутатор отвечает за привязку для исходящих тегов, которые применяются для пакетов данных, уходящих с коммутатора, а привязки входящих тегов получает от своих соседей.

Схема нисходящего выделения тегов работает следующим образом — для каждого маршрута в своей FIB коммутатор выделяет тег, создает запись в своей TIB с выделенным значением в качестве входящего тега и после этого анонсирует привязку (входящего) тега к маршруту смежным коммутаторам с коммутацией по тегам. Анонсирование может осуществляться добавлением (piggybacking) привязки к данным используемых протоколов маршрутизации или за счет использования отдельного протокола распространения тегов [TDP⁸]. Когда коммутатор получает информацию о привязке тега к маршруту, исходящую от следующего интервала (коммутатора) на этом маршруте, он помещает тег (переданный, как часть данных о привязке) в поле исходящего тега своей записи TIB для соответствующего маршрута. Это создает привязку исходящего тега к маршруту.

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

Схема восходящего выделения тегов работает следующим образом — если коммутатор по тегам имеет один или множество интерфейсов «точка-точка», тогда для каждого маршрута в своей FIB, следующий интервал которого доступен через один из таких интерфейсов, коммутатор выделяет тег, создает запись в своей TIB с выделенным значением в качестве исходящего тега и анонсирует на следующий интервал (с помощью TDP) привязку (исходящего) тега к маршруту. Когда коммутатор по тегам следующего интервала получает эту привязку, он помещает тег (передается как часть информации о привязке) в поле входящего тега записи своей TIB для соответствующего маршрута.

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

Когда коммутатор создает привязку исходящего тега к маршруту, он, в дополнение к включению записи в свою TIB, обновляет свою базу FIB, включая в нее данные о привязке. Это позволяет коммутатору добавлять теги в пакеты, которые их не имели ранее.

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

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

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

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

4.2. Иерархия маршрутной информации

В архитектуре маршрутизации IP сеть представляется в виде набора доменов маршрутизации. Внутри таких доменов маршрутизация обеспечивается протоколами внутренней маршрутизации (например, OSPF), а между доменами — протоколами внешней маршрутизации (например, BGP). Однако все маршрутизаторы в домене (например, в сети Internet-провайдера), используемые для передачи транзитного трафика поддерживают информацию не только от внутреннего протокола, но и от внешних. Это создает некоторые сложности. Во-первых, объем маршрутной информации достаточно велик, что создает дополнительные требования к ресурсам маршрутизаторов. Кроме того, рост объема маршрутной информации зачастую увеличивает время схождения при расчете маршрутов. А это, в свою очередь, снижает общую производительность системы.

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

Для поддержки такой функциональности коммутация по тегам позволяет передавать в пакетах не один, а множество тегов, организованных в стек. Коммутатор по тегам может заменить тег на вершине стека, опустошить (pop) стек или заменить тег и «втолкнуть» в стек новый тег или несколько тегов.

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

Управляющая компонента для этого сценария очень похожа на используемую при маршрутизации по адресам получателей. Фактически, единственным существенным различием является то, что в этом сценарии информация о привязках тегов распространяется как между физически смежными коммутаторами по тегам, так и между граничными коммутаторами по тегам в одном домене. Можно также отметить, что последнее (распространение между граничными коммутаторами) можно тривиально приспособить с помощью простого расширения к протоколу BGP (отдельный атрибут BGP Tag Binding).

4.3. Групповая адресация

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

Для поддержки функций групповой пересылки с коммутацией по тегам каждый коммутатор связывает тег с деревом групповой адресации, как описано ниже. Когда коммутатор по тегам создает запись для групповой пересылки (для общего или связанного с источником дерева) и список выходных интерфейсов для нее, а также локальные теги (по одному на выходной интерфейс). Коммутатор создает запись в своей базе TIB и заполняет ее поля (outgoing tag, outgoing interface, outgoing MAC header) информацией для каждого выходного интерфейса, помещая сгенерированные локально теги в поля outgoing tag. Это организует привязку тегов к дереву групповой адресации. После этого коммутатор анонсирует через каждый из связанных с записью выходных интерфейсов привязку связанного с этим интерфейсом тега к дереву групповой пересылки.

Когда коммутатор по тегам получает привязку тега к multicast-дереву от другого коммутатора, который является его соседом в восходящем направлении (относительно дерева групповой пересылки), этот коммутатор помещает тег из полученной привязки в поле incoming tag записи TIB, связанной с деревом.

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

4.4. Гибкая маршрутизация (явные маршруты)

Одним из фундаментальных принципов маршрутизации по адресам получателем является то, что для пересылки пакета используется только адрес получателя в заголовке. Это свойство обеспечивает эффективное масштабирование системы маршрутизации, но оно же ограничивает возможности влияния на пути реальной доставки пакетов. А это, в свою очередь, ограничивает возможности эффективного распределения трафика между множеством каналов для разгрузки занятых каналов путем отвода части трафика на менее загруженные соединения. Для ISP⁹, поддерживающих разные классы обслуживания, маршрутизация по адресам получателей также ограничивает возможности разделения трафика разных классов по каналам. Некоторые из ISP используют технологии Frame Relay и ATM для преодоления недостатков маршрутизации по адресам получателей. Коммутация по тегам, благодаря гибкой гранулярности тегов, позволяет преодолеть упомянутые ограничения без использования Frame Relay или ATM.

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

5. Коммутация по тегам в ATM

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

Теги, требуемые для коммутации, могут передаваться в поле VCI. Если требуется два уровня тегов, можно воспользоваться также полем VPI, хотя размер этого поля будет ограничивать размер сети, для которой такое решение будет практичным. Однако для большинства приложений одного уровня тегов в поле VCI вполне достаточно.

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

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

Следовательно, коммутатор ATM может поддерживать коммутацию по тегам, но ему, как минимум, нужно поддерживать и протоколы маршрутизации сетевого уровня вместе с управляющей компонентой коммутации по тегам. Может также дополнительно поддерживаться пересылка на канальном уровне.

Реализация коммутации по тегам в коммутаторах ATM будет упрощать интеграцию коммутаторов ATM и маршрутизаторов — коммутатор ATM с поддержкой коммутации по тегам для соседнего маршрутизатора будет выглядеть обычным маршрутизатором. Это может обеспечить жизнеспособную и более масштабируемую альтернативу модели с перекрытием (overlay model). Это также избавляет от необходимости использования схем адресации, маршрутизации и сигнализации ATM. Поскольку маршрутизация по адресам получателей, описанная в параграфе 4.1, управляется топологией, а не трафиком, применение этой модели для коммутаторов ATM не потребует высокой скорости организации соединений и не будет зависеть от продолжительности потоков трафика.

Реализация коммутации по тегам в коммутаторах ATM не препятствует поддержке традиционного уровня управления ATM (например, PNNI) в том же коммутаторе. Компоненты коммутации по тегам и управления ATM могут работать в режиме Ships In the Night¹⁰ (с пространствами VPI/VCI и другими ресурсами поделенными так, что эти компоненты не будут взаимодействовать).

6. Качество обслуживания

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

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

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

7. Стратегии перехода к коммутации по тегам

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

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

8. Заключение

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

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

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

10. Интеллектуальная собственность

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

11. Благодарности

Значительный вклад в эту работу внесли Anthony Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow, Jeremy Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie и Dan Tappan.

12. Адреса авторов

Yakov Rekhter

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA, 95134

EMail: yakov@cisco.com

Bruce Davie

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: bsd@cisco.com

Dave Katz

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA, 95134

EMail: dkatz@cisco.com

Eric Rosen

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: erosen@cisco.com

George Swallow

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: swallow@cisco.com

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

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

nmalykh@gmail.com