Network Working Group K. Kompella, Ed. Request for Comments: 4202 Y. Rekhter, Ed. Category: Standards Track Juniper Networks October 2005
Расширение маршрутизации для поддержки GMPLS
Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
Статус документа
В этом документе описан проект стандартного протокола Internet, предложенного сообществу Internet, документ служит приглашением к дискуссии в целях развития предложенного протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (2005).
Аннотация
В этом документе приведена спецификация расширения для поддержки передачи информации о состоянии канала для GMPLS1. Этот документ является дальнейшим развитием маршрутного расширения для поддержки MPLS TE2.
1. Введение
В этом документе приведена спецификация расширения для поддержки передачи информации о состоянии канала для обобщенной многопротокольной коммутации по меткам (GMPLS). Документ является дальнейшим развитием [ISIS-TE], [OSPF-TE], которое потребовалось для поддержки MPLS TE.
Традиционно соединения TE анонсируются, как «обычные» каналы, т. е. они создают маршрутную смежность и свойства активных соединений используются при расчетах кратчайших путей (SPF3) (прежде всего, метрики SPF), после чего свойства TE для соединения анонсируются.
GMPLS отказывается от такого подхода по трем причинам. Во-первых, канала, не способные принимать и передавать данные попакетно (packet-by-packet) могут, тем не менее, иметь свойства TE, однако маршрутной смежности от таких соединений не возникает. Во-вторых, путь с коммутацией по меткам (LSP4) может анонсироваться, как соединение TE типа «точка-точка» (см. [LSP-HIER]) и, таким образом, анонсируемое соединение TE может существовать между парой узлов, не имеющих маршрутной смежности между собой. В-третьих, множество соединений может анонсироваться, как один канал TE (например, в целях масштабирования) и здесь снова не возникает связи между обычной маршрутной смежностью и соединениями TE.
Таким образом, мы имеем более общее понятие канала TE, как «логического» соединения, имеющего свойства TE. Соединение является логическим в том смысле, что оно представляет способ группировки/отображения информации о неких физических ресурсах (и их свойствах) в данные, используемые Constrained SPF5 для расчета пути, а также для сигнализации GMPLS. Такое отображения/группировка должно выполняться согласованно на обеих сторонах соединения. Для проверки согласованности может использоваться протокол LMP [LMP].
В зависимости от природы ресурсов, формирующих конкретное соединение TE, для целей сигнализации GMPLS в некоторых случаях комбинации <идентификатор соединения TE, метка> достаточно для однозначного указания ресурсов, используемых LSP. В других случаях этой комбинации может оказаться недостаточно и для них используются связки каналов [LINK-BUNDLE], позволяющие идентифицировать ресурс с помощью набора <идентификатор соединения TE, идентификатор компонентного канала, метка>.
Некоторые свойства соединений TE могут быть заданы в конфигурации анонсирующих маршрутизаторов LSR6, а остальные могут быть получены от других LSR с помощью некого протокола, а также могут быть выведены из свойств компонентных соединений TE.
Соединение TE между парой LSR не предполагает наличия между этими маршрутизаторами маршрутной смежности (например, IGP). Как было отмечено выше, в некоторых случаях канал TE между парой LSR может анонсироваться даже при отсутствии маршрутной смежности между этими LSR (например, когда соединение TE организует смежность по пересылке – Forwarding Adjacency, как описано в [LSP-HIER]).
Канал TE должен иметь некоторые средства, с помощью которых анонсирующий LSR может узнать о «живости» соединения (это могут быть сообщения hello или иные средства). Когда LSR знает, что канал TE активен и может определить свойства TE для этого соединения, LSR может анонсировать такое соединение своим (обычным) соседям.
В этом документе интерфейсы, через которые организуются обычные отношения маршрутной смежности, будут называться «управляющими каналами» (control channel).
В документах [ISIS-TE] и [OSPF-TE] определены канонические свойства TE и описано, как связать свойства TE с обычными (коммутация пакетов) соединениями. Данный документ расширяет набор свойств TE и описывает, как связать свойства TE с каналами, не использующими коммутацию пакетов (non-packet-switched), – например, соединениями между оптическими кросс-коннекторами (OXC7). В [LSP-HIER] описано, как связать свойства TE с каналами, формируемыми LSP.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [RFC2119].
1.1. Требования к специфическим для уровня атрибутам TE
При обобщении каналов TE для включения традиционных транспортных средств имеются дополнительные факторы, влияющие на набор требуемой информации о канале TE. Эти факторы обусловлены существующей архитектурой транспортного уровня (например, рекомендации ITU-T G.805 и G.806) и связанными с ней службами. Некоторые из факторов перечислены ниже.
-
Потребность в LSP для конкретного применения, а не просто обеспечения пропускной способности. Клиенты оптических сетей получают услуги для конкретных приложений, например, устройств VC-3. Это не только предполагает определенную пропускную способность, но и способ структурирования передаваемой информации. Клиента VC-3 не устроит никакой LSP, которые предлагает скорость, отличную от 48,384 Мбит/с, или иное структурирование потока данных. Следствием этого является необходимость поиска маршрута, который обеспечить соединение с требуемыми для конкретного применения свойствами.
-
Различные варианты применения. Ресурсы между двумя OXC (в частности, трасса G.805) могут иной раз поддерживать одновременно разные варианты применения (адаптации) — пример этого описан в параграфе 2.4.8. В таких случаях факт поддержки двух вариантов применения на одной трассе весьма важен, поскольку два уровня являются зависимыми, а также по причине необходимости обеспечить возможность отображения отношений на данном уровне на маршрутизацию, особенно с учетом недостаточной гибкости транспортных уровней по сравнению с пакетными.
-
Наследуемые атрибуты. Когда вся иерархия мультиплексирования поддерживается каналом TE, атрибут нижележащего уровня может оказаться применимым для вышележащих уровней. Примером этого могут служить атрибуты защиты. Если канал OC-192 использует защиту 1+1 (дублирующий канал OC-192 для защиты), то STS-3c в этом OC-192 (вышележащий уровень) будет наследовать такие же свойства защиты.
-
Расширяемость уровней. В дополнение к имеющимся транспортным уровням в будущем могут быть определены новые уровни и приложения (адаптации).
-
Неоднородные сети, где не все OXC поддерживают одинаковый набор уровней. В сети GMPLS не все элементы транспортной сети уровня могут поддерживать один набор уровней. Например, могут присутствовать коммутаторы, способные поддерживать только VC-11, VC-12 и VC-3, а также коммутаторы, поддерживающие лишь VC-3 и VC-4. Даже если элемент сети не поддерживает конкретный уровень, ему следует иметь возможность узнать, имеются ли где-либо в сети элементы, которые поддерживают адаптацию, позволяющую использовать этот не поддерживаемый уровень. Например, коммутатор VC-11 может использовать поддерживающий VC-3 коммутатор, если знает, что путь VC-11 может быть организован через канал VC-3.
С учетом перечисленных выше факторов при разработке специфических для определенного уровня документов по маршрутизации GMPLS следует использовать для атрибутов каналов TE перечисленные ниже требования.
-
Разделение атрибутов. Атрибуты одного уровня отделяются от атрибутов других уровней.
-
Поддержка внутриуровневых атрибутов (например, связи между применениями). Между клиентским и серверным уровнем существует общий механизм описания отношений. Например, «4 клиентских канала типа X могут поддерживаться данным серверным канальным уровнем». Другим примером служит возможность идентификации случаев использования двумя уровнями общего серверного уровня.
-
Поддержка наследуемых атрибутов. Следует идентифицировать атрибуты, которые могут наследоваться.
-
Расширяемость уровней. Атрибуты следует представлять в маршрутизации так, чтобы можно было приспособить в будущем новые уровни. Это похоже на обобщение понятия метки.
-
Явное задание области действия атрибутов. Например, в каких случаях данный атрибут применим ко множеству каналов одного уровня.
В этом документе зафиксированы общие атрибуты, применимые к одному уровню сети, но не рассматриваются межуровневые связи атрибутов. Эта работа оставлена для будущих документов.
1.2. Исключение трафика данных из каналов управления
Каналы управления между узлами сети GMPLS (такими, как кросс-коннекторы и/или маршрутизаторы OXC и SDH) обычно служат для передачи трафика управления и администрирования. Эти каналы анонсируются в систему маршрутизации в качестве обычных каналов, как отмечено в предыдущем параграфе, что позволяет маршрутизировать в них, например, сообщения RSVP и сессии telnet. Однако, если маршрутизаторы на краю оптической сети попытаются передавать обычные данные через такие каналы, возможности этих каналов будут полностью исчерпаны.
Для предотвращения анонсирования каналов управления на уровень передачи пользовательских данных имеется множество методов.
Если предположить, что трафик данных передается получателям BGP, а управляющий — получателям IGP, можно исключить передачу трафика данных на уровень управления, ограничивая выбор следующего интервала BGP (предполагается, что OXC не являются узлами BGP). Предположим, что маршрутизатор R пытается организовать маршрут к BGP-адресату D. R ищет следующий интервал BGP для D в своей таблице маршрутизации IGP. Предположим, что R находит путь к следующему интервалу через интерфейс I. Тогда R проверяет наличие в своей базе данных о состоянии каналов (Link State) записи, связанной с интерфейсом I. Если такая запись имеется и канал не поддерживает коммутацию пакетов (см. [LSP-HIER]), R отбрасывает этот маршрут к получателю D. В противном случае R организует (как обычно) маршрут к получателю D со следующим интервалом I. Отметим, что маршрутизатору R такая проверка нужна лишь в случае наличия у него каналов, не поддерживающих коммутацию пакетов, в случае поддержки коммутации пакетов на всех каналах такая проверка явно становится избыточной.
В других ситуациях может оказаться желательным сохранение всего адресного пространства уровня маршрутизации GMPLS оторванным от адресов конечных точек в другой части сети GMPLS. Примером может служить сеть оператора, который использует GMPLS, но не хочет раскрывать внутреннюю адресацию или топологию. В таких сетях каналы управления никогда не анонсируются в сеть передачи пользовательских данных. При этом используются механизмы анонсирования адресов передачи данных через сеть оператора.
Могут потребоваться также другие методы исключения трафика данных из каналов управления.
2. Развитие маршрутизации GMPLS
В этом разделе определяются усовершенствованные свойства TE каналов GMPLS TE. Представление этой информации в протоколе IS-IS задано в [GMPLS-ISIS], в протоколе OSPF – в [GMPLS-OSPF].
2.1. Поддержка безадресных соединений
Безадресными соединениями являются каналы типа «точка-точка». LSR на каждой стороне безадресного соединения присваивают такому каналу свой идентификатор. Эти идентификаторы представляют собой 32-битовые целые числа, отличные от 0 и уникальные в масштабе маршрутизатора LSR, который выделил значение идентификатора.
Рассмотрим (безадресное) соединение между маршрутизаторами A и B. LSR A выбирает идентификатор для канала и LSR B делает то же самое. С точки зрения A мы называем выделенное этим маршрутизатором значение «идентификатором локального канала» или просто «локальным идентификатором» (link local identifier или local identifier), а значение, выделенное маршрутизатором B – «идентификатором удаленного канала» или «удаленным идентификатором» (link remote identifier или remote identifier). С точки зрения B выделенный этим маршрутизатором идентификатор будет локальным, а выделенный маршрутизатором A – удаленным.
Поддержка безадресных соединений в маршрутизации включает обмен информацией об идентификаторах канала. В частности, когда LSR анонсирует безадресное соединение TE, в анонс включаются локальный и удаленный идентификаторы канала. Если LSR не знает удаленного идентификатора, ему следует использовать значение 0.
2.2. Тип защиты канала
Тип защиты канала (Link Protection Type) представляет имеющиеся возможности защиты этого соединения. Желательно передавать эту информацию так, чтобы она могла использоваться алгоритмом расчета пути для организации LSP с подходящими характеристиками защиты. Эта информация организуется иерархически и при организации пути обычно задается минимально приемлемый уровень защиты, а метод выбора пути служит для поиска пути, обеспечивающего защиту с уровнем не ниже указанного минимума.
Определяемые в данном документе схемы защиты представлены ниже в порядке роста уровня защиты.
Extra Traffic — дополнительный трафик
Тип Extra Traffic означает, что канал используется для защиты другого канала или каналов. LSP на канале этого типа будет теряться при отказе любого из защищаемых каналов.
Unprotected — без защиты
Тип Unprotected означает отсутствие других каналов, обеспечивающих защиту данного соединения. LSP на канале этого типа будет теряться при отказе канала.
Shared — общая защита
Тип Shared говорит о наличии одного или множества несвязанных (disjoint) каналов типа Extra Traffic, защищающих данный канал. Эти каналы типа Extra Traffic используются одним или множеством каналов типа Shared.
Dedicated 1:1 — выделенный канал для защиты
Тип защиты Dedicated 1:1 говорит о наличии одного выделенного, несвязанного (disjoint) канала типа Extra Traffic, защищающего данный канал.
Dedicated 1+1 — выделенный, неанонсируемый канал для защиты
Тип защиты Dedicated 1+1 говорит о наличии выделенного, несвязанного (disjoint) канала, служащего для защиты данного соединения. Однако защитный канал не анонсируется в базе данных о состоянии каналов и, следовательно, не доступен для маршрутизации LSP.
Enhanced — улучшенная защита
Тип защиты Enhanced говорит о наличии схемы, более надежной по сравнению с Dedicated 1+1 (например, 4 волокна BLSR/MS-SPRING), которая используется для защиты данного канала.
Тип защиты канала является необязательным и при его отсутствии в анонсах состояния канала (Link State Advertisement) остается неизвестным.
2.3. Информация SRLG
Множество каналов может создать «группу общего риска» (SRLG8), если они используют общий ресурс, отказ которого будет воздействовать на все каналы группы. Например, два волокна одного кабеля могут быть в одной группе SRLG. Канал может входить во множество групп SRLG. Таким образом, информация SRLG описывает набор групп SRLG, в которые входит данный канал. SRLG идентифицируется 32-битовым целым числом, которое уникально в рамках домена IGP. Информация SRLG представляет собой неупорядоченный список групп SRLG, в которые входит канал.
SRLG для пути LSP представляет собой объединение групп SRLG каналов, образующих LSP. SRLG группы каналов (bundled link) является объединением SRLG всех каналов-компонент.
Если маршрутизатору LSR требуется множество LSP с разной маршрутизацией к другому LSR, при расчете пути следует попытаться маршрутизировать пути так, чтобы они не включали общих каналов и группы SRLG для пути не были связанными.
Информация SRLG может начинаться с заданного в конфигурации списка, который в этом случае не меняется с течением времени, пока не будет изменена конфигурация.
Информация SRLG является необязательной и при ее отсутствии в анонсе состояния канала SRLG для канала остается неизвестной.
2.4. Дескриптор коммутации для интерфейса
В контексте этого документа говорится, что канал подключен к узлу через интерфейс. В контексте GMPLS интерфейсы могут различаться коммутационными возможностями. Например, интерфейс, подключающий данный канал к узлу, может быть не способен коммутировать отдельные пакеты, но способен коммутировать каналы внутри потока SDH. Интерфейсы на обеих сторонах канала не обязаны совпадать по возможностям коммутации, равно как и разные интерфейсы одного узла.
Дескриптор коммутационных возможностей (дескриптор коммутации) интерфейса (Interface Switching Capability Descriptor) описывает поддерживаемые этим интерфейсом возможности коммутации. Для двухсторонних каналов коммутационные возможности интерфейсов определяются одинаково для обоих направлений.
Анонс Link State Advertisement для канала передает дескриптор(ы) коммутационных возможностей на ближней стороне канала (на стороне LSR, передающего анонс).
Маршрутизатор LSR, выполняющий расчет пути, использует базу данных о состояниях каналов (Link State Database) для определения двухстороннего или одностороннего характера каналов.
Для двухсторонних каналов LSR использует свою базу Link State Database для определения дескрипторов коммутации на удаленной стороне канала, поскольку для таких каналов дескрипторы на разных сторонах могут различаться.
Для односторонних соединений предполагается совпадение дескрипторов на локальной и удаленном концах канала. Такое допущение представляется разумным с учетом того, что односторонние соединения возникают только при наличии смежности по пересылке пакетов, а в этом случае обе стороны относятся к одному уровню иерархии PSC9.
Ниже перечислены определенные в этом документе режимы коммутации интерфейсов (Interface Switching Capability).
Коммутация пакетов-1 (PSC-1)
Коммутация пакетов-2 (PSC-2)
Коммутация пакетов-3 (PSC-3)
Коммутация пакетов-4 (PSC-4)
Коммутация кадров (L2SC10)
Мультиплексирование TDM (TDM11)
Коммутация по длине волны (LSC12)
Коммутация волокон (FSC13)
При отсутствии дескриптора коммутации для интерфейса предполагается дескриптор PSC-1.
Дескрипторы коммутационных возможностей интерфейсов служат новым ограничением при расчете путей LSP.
Безотносительно к коммутационным возможностям конкретного интерфейса значение Interface Switching Capability Descriptor всегда включает информацию о поддерживаемом интерфейсом кодировании. Определенные варианты кодирования совпадают с LSP Encoding из [GMPLS-SIG].
Интерфейс может иметь более одного дескриптора коммутации. Это применяется для работы с интерфейсами, поддерживающими разные режимы коммутации, интерфейсами со значениями Max LSP Bandwidth14, различающимися по уровню приоритета, и интерфейсами, поддерживающими дискретные значения пропускной способности.
В зависимости от конкретных возможностей интерфейса дескриптор коммутации может включать дополнительную информацию, как описано ниже.
2.4.1. Коммутация кадров или ячеек (L2)
Если интерфейс имеет тип L2SC, это означает, что узел, принимающий данные через этот интерфейс, может коммутировать принятые кадры на основе адресов канального уровня (layer 2). Например, интерфейс, связанный с каналом, который заканчивается на коммутаторе ATM, может рассматриваться, как L2SC.
2.4.2. Коммутация пакетов
Если интерфейс имеет тип PSC-1 – PSC-4, это означает, что узел, получающий данные через такой интерфейс может коммутировать полученные данные на уровне пакетов (packet-by-packet), используя метки, передаваемые в shim-заголовках [RFC3032]. Разные уровни PSC образуют иерархию LSP, туннелируемых через другие LSP.
Для интерфейсов PSC дополнительная информация включает максимальную и минимальную пропускную способность LSP (Maximum LSP Bandwidth, Minimum LSP Bandwidth) и значение MTU на интерфейсе.
Для простого (unbundled) канала Maximum LSP Bandwidth для приоритета p определяется значением меньше незарезервированной пропускной способности для уровня p и параметром Maximum LSP Size, который задается в локальной конфигурации канала и по умолчанию совпадает с Max Link Bandwidth. Максимальная пропускная способность для композитного (bundled) канала определена в [LINK-BUNDLE].
Maximum LSP Bandwidth занимает место параметра Maximum Link Bandwidth ([ISIS-TE], [OSPF-TE]). Однако Maximum Link Bandwidth представляет собой одно фиксированное значение (обычно просто полоса канала), Maximum LSP Bandwidth передается по уровням приоритета и может изменяться по мере организации и разрыва LSP.
Хотя параметр Maximum Link Bandwidth отменяется, для совместимости со старыми версиями можно устанавливать для него значение Maximum LSP Bandwidth для приоритета 7.
Параметр Minimum LSP Bandwidth указывает максимальную пропускную способность, которая может быть зарезервирована для LSP.
Типовые значения Minimum LSP Bandwidth и Maximum LSP Bandwidth приведены в документе [GMPLS-SIG].
На интерфейсе PSC, поддерживающем кодирование Standard SDH, LSP с приоритетом p может зарезервировать любую пропускную способность, разрешаемую иерархией ветви SDH, при этом листья и корень ветви будут определяться значениями Minimum LSP Bandwidth и Maximum LSP Bandwidth для приоритета p.
На интерфейсе PSC, поддерживающем кодирование Arbitrary SDH, LSP с приоритетом p может зарезервировать любую пропускную способность из диапазона от Minimum LSP Bandwidth до Maximum LSP Bandwidth для приоритета p, с учетом того, что резервируемая LSP пропускная способность кратна значению Minimum LSP Bandwidth.
Параметр Interface MTU определяет максимальный размер пакета, который может быть передан этим интерфейсом без фрагментирования.
2.4.3. Мультиплексирование TDM
Если интерфейс относится к типу TDM, это означает, что получающий данные через этот интерфейс узел может мультиплексировать и демультиплексировать каналы данных SDH.
Для интерфейсов TDM дополнительная информация включает Maximum LSP Bandwidth, сведения о поддержке Standard или Arbitrary SDH, а также Minimum LSP Bandwidth.
Для простого (unbundled) канала Maximum LSP Bandwidth для приоритета p определяется, как максимальная пропускная способность, которую может зарезервировать LSP с приоритетом p. Максимальная пропускная способность для композитного (bundled) канала определена в [LINK-BUNDLE].
Параметр Minimum LSP Bandwidth указывает минимальную пропускную способность, которую может резервировать LSP.
Типовые значения Minimum LSP Bandwidth и Maximum LSP Bandwidth приведены в документе [GMPLS-SIG].
На интерфейсе с мультиплексированием Standard SDH путь LSP с приоритетом p может зарезервировать любую пропускную способность, разрешаемую иерархией ветви SDH, при этом листья и корень ветви будут определяться значениями Minimum LSP Bandwidth и Maximum LSP Bandwidth для приоритета p.
На интерфейсе с мультиплексированием Arbitrary SDH путь LSP с приоритетом p может зарезервировать любую пропускную способность из диапазона от Minimum LSP Bandwidth до Maximum LSP Bandwidth для приоритета p, с учетом того, что резервируемая LSP пропускная способность кратна значению Minimum LSP Bandwidth.
Дескриптор коммутации для интерфейсов, которые поддерживают суб-VC-3, может включать дополнительную информация, природа и представление которой выходят за рамки настоящего документа.
На интерфейсе, поддерживающем множество ветвей иерархии мультиплексирования SDH, может анонсироваться множество дескрипторов коммутации (по одному на каждую ветвь). Например, для интерфейса, поддерживающего VC-11 и VC-12 (которые не является частью той же ветви иерархии SDH), будет анонсироваться два дескриптора.
2.4.4. Коммутация по длинам волн (Lambda)
Если интерфейс относится к типу LSC, это означает, что получающий данные через этот интерфейс узел может распознавать и коммутировать отдельные длины волн (lambda) на этом интерфейсе. Интерфейсы, поддерживающие единственную длину волны и коммутирующие только ее, относятся к типу LSC.
Дополнительная информация включает резервируемую полосу (Reservable Bandwidth) по уровням приоритета, которая задает пропускную способность LSP, которая может поддерживаться интерфейсом для данного уровня приоритета.
В случае поддержки множества скоростей передачи или вариантов кодирования в одном канале TE для интерфейса может анонсироваться множество дескрипторов коммутации (по одному на каждую комбинацию скорости кодирования). Например, интерфейс LSC может поддерживать организацию LSC LSP при скоростях STM-16 и STM-64.
2.4.5. Коммутация волокон
Если интерфейс относится к типу FSC, это означает, что получающий данные через этот интерфейс узел может коммутировать весь поток данных с этого интерфейса на другой, не различая длин волн, каналов или пакетов. Т. е., гранулярность коммутации для интерфейсов типа FSC составляет интерфейс целиком и не позволяет выделить отдельные длины волн. Интерфейсы типа FSC не могут ограничивать себя одной длиной волны.
2.4.6. Поддержка множества типов коммутации на интерфейсе
Интерфейс, подключающий канал к маршрутизатору LSR, может поддерживать множество режимов коммутации (Interface Switching Capability). В качестве примера рассмотрим оптический канал, поддерживающий диапазон длин волн, который завершается на интерфейсе маршрутизатора LSR, способного коммутировать одну из длин волн в другой исходящий оптический канал, служить терминальным устройством для той или иной длины волны и демультиплексировать (извлекать) данные для определенной длины волны, используя TDM и коммутируя выделенные каналы TDM в другие исходящие каналы TDM. Для поддержки такого интерфейса анонсы состояния канала (Link State Advertisement) могут включать множество дескрипторов коммутации (Interface Switching Capabilities Descriptor).
2.4.7. Возможности коммутации и метки
Если обозначить канал TE дескрипторами коммутации на обеих сторонах соединения, примеры каналов могут иметь вид:
[PSC, PSC] — канал между двумя пакетными LSR;
[TDM, TDM] — канал между двумя цифровыми кросс-коннекторами;
[LSC, LSC] — канал между двумя OXC;
[PSC, TDM] — канал между пакетным LSR и цифровым кросс-коннектором;
[PSC, LSC] — канал между пакетным LSR и OXC;
[TDM, LSC] — канал между цифровым кросс-коннектором и OXC.
Обе стороны канала TE используют один способ передачи меток через канал, который зависит от режимов коммутации на обоих концах канала, как показано ниже.
[PSC, PSC] — метка передается в shim-заголовке [RFC3032];
[TDM, TDM] — метка представляет временной интервал TDM [GMPLS-SONET-SDH];
[LSC, LSC] — метка представляет длину волны;
[FSC, FSC] — метка представляет порт OXC;
[PSC, TDM] — метка представляет временной интервал TDM [GMPLS-SONET-SDH];
[PSC, LSC] — метка представляет длину волны;
[PSC, FSC] — метка представляет порт;
[TDM, LSC] — метка представляет длину волны;
[TDM, FSC] — метка представляет порт;
[LSC, FSC] — метка представляет порт.
2.4.8. Прочие вопросы
Вполне возможно с течением времени изменение дескриптора коммутации, отражающее создание и удаление LSP. Например, LSP-пути VC-3, VC-4, VC-4-4c, VC-4-16c и VC-4-64c могут быть организованы на интерфейсе STM-64 с кодированием SDH. Изначально в дескрипторе коммутации будут установлены значения Minimum LSP Bandwidth = VC-3 и Maximum LSP Bandwidth = STM-64 для всех уровней приоритета. После организации на интерфейсе пути LSP размера VC-3 с приоритетом 1 он уже не будет поддерживать VC-4-64c для всех LSP, кроме тех, у кого задан приоритет 0. Следовательно, узел будет анонсировать дескриптор коммутации, показывающий, что максимальная пропускная способность LSP составляет уже не STM-64, а STM-16 для всех уровней приоритет, кроме 0 (для приоритета 0 сохранится Maximum LSP Bandwidth = STM-64). Если позднее будет организован другой VC-3 LSP, дескриптор коммутации не изменится. Этот дескриптор будет сохраняться, до того момент, когда узел уже не сможет организовать через этот интерфейс VC-4-16c LSP (это означает, что на интерфейсе уже занято более 144 временных интервалов для организации LSP). После этого дескриптор коммутации снова будет изменен и узел анонсирует новый дескриптор другим узлам.
2.5. Представление пропускной способности
Для представления незарезервированной (Unreserved), а также максимальной (Maximum LSP) и минимальной (Minimum LSP) полосы LSP используются действительные числа с плавающей запятой в формате IEEE [IEEE], как описано в параграфе 3.1.2 of [GMPLS-SIG].
3. Примеры дескрипторов возможностей коммутации
3.1. Интерфейс STM-16 POS в LSR
Дескриптор коммутации:
Режим коммутации = PSC-1
Кодирование = SDH
Максимальная пропускная способность LSP [p] = 2,5 Гбит/с для всех p
Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).
3.2. Интерфейс GigE Packet в LSR
Дескриптор коммутации:
Режим коммутации = PSC-1
Кодирование = Ethernet 802.3
Максимальная пропускная способность LSP [p] = 1,0 Гбит/с для всех p
Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).
3.3. Интерфейс STM-64 SDH в цифровом кросс-коннекторе с Standard SDH
Рассмотрим ветвь дерева иерархии мультиплексирования SDH – VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. Если возможна организация всех этих соединений на интерфейсе STM-64, анонсируемый дескриптор коммутации для такого интерфейса будет иметь вид:
Дескриптор коммутации:
Режим коммутации = TDM [Standard SDH]
Кодирование = SDH
Минимальная пропускная способность LSP = VC-3
Максимальная пропускная способность LSP [p] = STM-64 для всех p
Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).
3.4. Интерфейс STM-64 SDH в кросс-коннекторе с 2 типами иерархии
Дескриптор коммутации 1:
Режим коммутации = TDM [Standard SDH]
Кодирование = SDH
Минимальная пропускная способность LSP = VC-3
Максимальная пропускная способность LSP [p] = STM-64 для всех p
Дескриптор коммутации 2:
Режим коммутации = TDM [Arbitrary SDH]
Кодирование = SDH
Минимальная пропускная способность LSP = VC-4
Максимальная пропускная способность LSP [p] = STM-64 для всех p
Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).
3.5. Интерфейс Opaque OXC (SDH) с поддержкой 1 длины волны на порт
«Непрозрачным» (opaque) OXC называется режим работы OXC, при котором весь поток одной длины волны (переносящий поток данных SDH) переключается без дополнительного мультиплексирования-демультиплексирования и служебные биты SDH не меняются совсем (или, по крайней мере, не меняются важные).
Интерфейс непрозрачного OXC работает с одной длиной волны и не может коммутировать множество длин волн, как одно целое. Таким образом, интерфейс непрозрачного OXC всегда имеет тип LSC, а не FSC, независимо от применения DWDM вне этого интерфейса.
Отметим, что при использовании внешнего мультиплексирования DWDM понятное DWDM кадрирование должно быть понятно и OXC.
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все интерфейсы одного OXC должны иметь уникальные в рамках этого OXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Ниже приведен пример дескриптора коммутации для непрозрачного OXC с кадрированием SDH.
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = SDH
Резервируемая полоса = определяется кадрированием SDH (например, STM-64)
3.6. Интерфейс Transparent OXC (PXC) с внешней DWDM и кадрированием SDH
Этот пример предполагает соединение устройств DWDM и PXC так, чтобы каждый интерфейс (порт) PXC обслуживал просто одну длину волны. Таким образом, несмотря на возможность интерфейса PXC коммутировать группы из нескольких длин волн, в рассматриваемом случае интерфейс PXC относится к типы LSC, а не FSC.
_______ | | /|___| | | |___| PXC | ========| |___| | | |___| | \| |_______| DWDM (кадрирование SDH)
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Ниже приведен пример дескриптора коммутации для непрозрачного OXC (PXC) с внешним мультиплексированием DWDM, которое понимает кадрирование SDH.
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = SDH (приходит от DWDM)
Максимальная пропускная способность LSP = определяется DWDM (например, STM-64)
3.7. Интерфейс Transparent OXC (PXC) с внешней DWDM, прозрачный для скорости и кадрирования
Этот пример предполагает соединение устройств DWDM и PXC так, чтобы каждый интерфейс (порт) PXC обслуживал просто одну длину волны. Таким образом, несмотря на возможность интерфейса PXC коммутировать группы из нескольких длин волн, в рассматриваемом случае интерфейс PXC относится к типы LSC, а не FSC.
_______ | | /|___| | | |___| PXC | ========| |___| | | |___| | \| |_______| DWDM (прозрачно для битовой скорости и кадрирования)
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Ниже приведен пример дескриптора коммутации для непрозрачного OXC (PXC) с внешним мультиплексированием DWDM, которое прозрачно для битовой скорости и кадрирования.
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = Lambda (оптическое)
Резервируемая полоса = Определяется ограничениями оптической технологии
3.8. Интерфейс PXC без внешней DWDM
Отсутствие DWDM между парой PXC предполагает, что интерфейсы кросс-коннекторов не ограничены использованием одной длины волны. Таким образом, интерфейсы анонсируются с типом FSC.
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Дескриптор коммутации:
Режим коммутации = FSC
Кодирование = Lambda (оптическое)
Резервируемая полоса = Определяется ограничениями оптической технологии
Отметим, что в этом примере не предполагается обязательное использование на портах PXC одной длины волны.
3.9. Интерфейс OXC с внутренней DWDM, понимающий кадрирование SDH
В этом примере предполагается, что соединение между устройствами DWDM и OXC организовано так, что каждый интерфейс кросс-коннектора OXC может индивидуально обрабатывать множество длин волн. В этом случае интерфейс OXC относится к типу LSC, а не FSC.
_______ | | /|| ||\ | || OXC || | ========| || || |==== | || || | \||_______||/ DWDM (кадрирование SDH)
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все длины волн на одном интерфейсе OXC должны иметь уникальные в рамках этого интерфейса идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Ниже приведен дескриптор коммутации интерфейса OXC с внутренним мультиплексированием DWDM, который понимает кадрирование SDH и поддерживает фиксированные значения пропускной способности.
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = SDH (приходит от DWDM)
Максимальная пропускная способность LSP = определяется DWDM (например, STM-16)
Режим коммутации = LSC
Кодирование = SDH (приходит от DWDM)
Максимальная пропускная способность LSP = определяется DWDM (например, STM-64)
3.10. Интерфейс OXC с внутренней DWDM, прозрачный для скорости и кадрирования
В этом примере предполагается, что соединение между устройствами DWDM и OXC организовано так, что каждый интерфейс кросс-коннектора OXC может индивидуально обрабатывать множество длин волн. В этом случае интерфейс OXC относится к типу LSC, а не FSC.
_______ | | /|| ||\ | || OXC || | ========| || || |==== | || || | \||_______||/ DWDM (прозрачно для битовой скорости и кадрирования)
Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все длины волн на одном интерфейсе OXC должны иметь уникальные в рамках этого интерфейса идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).
Ниже приведен дескриптор коммутации интерфейса OXC с внутренним мультиплексированием DWDM, который прозрачен для битовой скорости и кадрирования.
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = Lambda (оптическое)
Резервируемая полоса = Определяется ограничениями оптической технологии
4. Примеры интерфейсов, поддерживающих MSC15
Ниже описаны некоторые из множества возможных комбинаций.
4.1. Интерфейс на устройстве PXC+TDM с внешним DWDM
Как было указано выше, использование внешнего мультиплексирования DWDM позволяет обслуживать на порту PXC только одну длину волны. На таком порту подключенное устройство PXC+TDM может организовать для длины волны кросс-соединение с другим исходящим оптическим каналом или служить терминальным устройством с интерфейсом SDH и коммутацией каналов SDH.
С точки зрения GMPLS функциональность PXC+TDM рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для LSC, другой для TDM) с соответствующими параметрами. Например,
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = SDH (приходит от WDM)
Резервируемая полоса = STM-64
и
Дескриптор коммутации:
Режим коммутации = TDM [Standard SDH]
Кодирование = SDH
Минимальная пропускная способность LSP = VC-3
Максимальная пропускная способность LSP [p] = STM-64 для всех p
4.2. Интерфейс на устройстве Opaque OXC+TDM с внешним DWDM
Интерфейс устройства «непрозрачный OXC+TDM» будет анонсироваться, как LSC+TDM (см. выше).
4.3. Интерфейс на устройстве PXC+LSR с внешним DWDM
Как было указано выше, использование внешнего мультиплексирования DWDM позволяет обслуживать на порту PXC только одну длину волны. На таком порту подключенное устройство PXC+LSR может организовать для длины волны кросс-соединение с другим исходящим оптическим каналом или служить терминальным устройством с пакетным интерфейсом и коммутацией пакетов.
С точки зрения GMPLS функциональность PXC+LSR рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для LSC, другой для PSC) с соответствующими параметрами. Например,
Дескриптор коммутации:
Режим коммутации = LSC
Кодирование = SDH (приходит от WDM)
Резервируемая полоса = STM-64
и
Дескриптор коммутации:
Режим коммутации = PSC-1
Кодирование = SDH
Максимальная пропускная способность LSP [p] = 10 Гбит/с для всех p
4.4. Интерфейс на устройстве TDM+LSR
На устройстве TDM+LSR с канализованным интерфейсом SDH может быть возможно перечисленное ниже.
-
Некоторые каналы SDH могут быть незавершенными (т. е. они не используются и доступны для выделения).
-
Другая часть каналов может быть выделена для транзита. Для этих каналов с помощью соответствующей функции SDH уже организованы кросс-соединения и каналы не доступны для распределения.
-
Остальные каналы могут считаться терминальными (т. е., выделены в качестве завершения линий с пакетным интерфейсом и коммутацией пакетов).
С точки зрения GMPLS функциональность TDM+PSC рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для TDM, другой для PSC) с соответствующими параметрами. Например,
Дескриптор коммутации:
Режим коммутации = TDM [Standard SDH]
Кодирование = SDH
Минимальная пропускная способность LSP = VC-3
Максимальная пропускная способность LSP [p] = STM-64 для всех p
и
Дескриптор коммутации:
Режим коммутации = PSC-1
Кодирование = SDH
Максимальная пропускная способность LSP [p] = 10 Гбит/с для всех p
5. Благодарности
Авторы выражают благодарность Suresh Katukam, Jonathan Lang, Zhi-Wei Lin и Quaizar Vohra за комментарии и вклад в подготовку документа. Спасибо также Stephen Shew за текст, относящийся к представлению возможностей канала TE.
6. Вопросы безопасности
Имеется целый ряд вопросов безопасности, связанных с реализацией предложенных здесь расширений, в частности из-за того, что эти расширения могут применяться для управления транспортной инфраструктурой. Очень важно обеспечить защищенную и/или аутентифицированную передачу информации этих расширений между элементами, которым она нужна.
Хотя весь документ посвящен расширениям, он не задает реализации этих расширений в протоколах маршрутизации (типа OSPF или IS-IS). В документах, посвященных реализации этих расширений в протоколах маршрутизации [GMPLS-OSPF, GMPLS-ISIS], должны описываться также способы и средства защиты информации.
7. Литература
7.1. Нормативные документы
[GMPLS-OSPF] Kompella, K., Ed. and Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4203, October 2005.
[GMPLS-SIG] Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description”, RFC 3471, January 2003.
[GMPLS-SONET-SDH] Mannie, E. and D. Papadimitriou, “Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control”, RFC 3946, October 2004.
[IEEE] IEEE, “IEEE Standard for Binary Floating-Point Arithmetic”, Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, “Link Bundling in MPLS Traffic Engineering (TE)”, RFC 4201, October 2005.
[LMP] Lang, J., Ed., “Link Management Protocol (LMP)”, RFC 4204, October 2005.
[LSP-HIER] Kompella, K. and Y. Rekhter, “Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE))”, RFC 4206, October 2005.
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, September 2003.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding”, RFC 3032, January 2001.
7.2. Дополнительная литература
[GMPLS-ISIS] Kompella, K., Ed. and Y. Rekhter, Ed., “Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4205, October 2005.
[ISIS-TE] Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)”, RFC 3784, June 2004.
8. Участники работы
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1.408.972.3645
EMail: abanerjee@calient.net
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: (408) 972-3720
EMail: jdrake@calient.net
Greg Bernstein
Ciena Corporation
10480 Ridgeview Court
Cupertino, CA 94014
Phone: (408) 366-4713
EMail: greg@ciena.com
Don Fedyk
Nortel Networks Corp.
600 Technology Park Drive
Billerica, MA 01821
Phone: +1-978-288-4506
EMail: dwfedyk@nortelnetworks.com
Eric Mannie
Libre Exaministe
EMail: eric_mannie@hotmail.com
Debanjan Saha
Tellium Optical Systems
2 Crescent Place
P.O. Box 901
Ocean Port, NJ 07757
Phone: (732) 923-4264
EMail: dsaha@tellium.com
Vishal Sharma
Metanoia, Inc.
335 Elan Village Lane, Unit 203
San Jose, CA 95134-2539
Phone: +1 408-943-1794
EMail: v.sharma@ieee.org
Debashis Basak
AcceLight Networks,
70 Abele Rd, Bldg 1200
Bridgeville PA 15017
EMail: dbasak@accelight.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
EMail: lberger@movaz.com
Адреса авторов
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2005).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.
1Generalized Multi-Protocol Label Switching – обобщенная многопротокольная коммутация по меткам.
2Traffic Engineering – построение трафика.
3Shortest Path First — сначала кратчайший путь.
4Label Switched Path — путь с коммутацией по меткам.
5Выбор кратчайшего пути с учетом ограничений.
6Label Switching Router — маршрутизатор с коммутацией по меткам.
7Optical Cross-Connect — оптический кросс-коннектор.
8Shared risk link group — группа общего риска, связанного с соединениями.
9Packet-Switch Capable — поддержка коммутации пакетов
10Layer-2 Switch Capable — поддержка коммутации на уровне 2 (логический канал).
11Time-Division-Multiplex Capable — поддержка мультиплексирования с разделением по времени.
12Lambda-Switch Capable — поддержка коммутации по длине волны.
13Fiber-Switch Capable — поддержка коммутации оптических волокон.
14Максимальная пропускная способность LSP.
15Множество вариантов коммутации.
