RFC 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)

Network Working Group                                    K. Shiomoto
Request for Comments: 5212                                       NTT
Category: Informational                             D. Papadimitriou
                                                      Alcatel-Lucent
                                                         JL. Le Roux
                                                      France Telecom
                                                        M. Vigoureux
                                                      Alcatel-Lucent
                                                         D. Brungard
                                                                AT&T
                                                           July 2008

 

Требования к многозоновым и многоуровневым сетям на базе GMPLS

Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)

PDF

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

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

Аннотация

Большинство первоначальных усилий по использованию GMPLS¹ было связано со средами, содержащими устройства с одним типом коммутации². Управление плоскостью данных в таких случаях похоже на управление классическими сетями IP/MPLS. За счет расширения MPLS путем поддержки множества технологий коммутации GMPLS обеспечивает комплексную основу для управления многоуровневыми сетями, использующими одну или множество технологий коммутации.

В GMPLS область использования одной технологии коммутации определяет зону³ и сети с множеством типов коммутации в этом документе будут называться многозоновыми (MRN⁴). При обсуждении в общем случае разделенных на уровни сетей, которые могут включать одну или множество зон в этом документе используется термин «многоуровневая сеть» (MLN⁵). В этом документе определена схема основанных на GMPLS многоуровневых/многозоновых сетей и приведен список требований к ним.

1. Введение

Технология GMPLS расширяет возможности MPLS в плане использования множества технологий коммутации: коммутация пакетов⁶, коммутация кадров⁷, коммутация TDM⁸, коммутация длин волн⁹ и коммутация волокон¹⁰ (см.[RFC3945]). Для этих технологий вводится концепция «способности коммутировать интерфейсы» (ISC¹¹) и обозначения PSC (способность коммутировать пакеты), L2SC (способность коммутации на уровне 2), способность коммутации TDM, LSC (способность коммутации длин волн – «лямбд») и FSC (способность коммутации волокон).

В управляющей плоскости GMPLS представление области одной технологии коммутации называется зоной [RFC4206]. Тип коммутации описывает способность узла пересылать данные с использованием определенной технологии и однозначно идентифицирует зону сети. Уровень описывает гранулярность коммутации данных (например, VC4, VC-12). Уровень плоскости данных ассоциируется с зоной в плоскости управления (например, VC4 ассоциируется TDM, MPLS — с PSC). Однако с одной зоной может быть ассоциировано более одного уровня плоскости данных (например, с TDM могут ассоциироваться VC4 и VC12). Таким образом, зона плоскости управления, идентифицируемая типом коммутации (например, TDM), может быть дополнительно разделена на более мелкие компоненты по уровням коммутации плоскости данных. Дескриптор ISCD¹² [RFC4202], идентифицирующий ISC, тип кодирования и гранулярность полосы коммутации¹³, позволяет характеризовать ассоциированные уровни.

В этом документе многоуровневая сеть (MLN) определяется, как домен построения трафика (TE¹⁴), охватывающий множество уровней коммутации плоскости данных одной (например, TDM) или разных ISC (например, TDM и PSC) и контролируемый одним экземпляром управляющей плоскости GMPLS. Позднее будут дополнительно определены частные случаи MLN. Многозоновая сеть (MRN) определяется, как домен TE, поддерживающий не менее двух разных типов коммутации (например, PSC и TDM), реализованных на одном или множестве устройств, и находящийся под контролем одного экземпляра управляющей плоскости GMPLS.

MLN можно разбить на категории в соответствии с распределением ISC по маршрутизаторам с коммутацией меток (LSR¹⁵):

• Каждый LSR может поддерживать одну ISC.Такие маршрутизаторы LSR называют single-switching-type-capable LSR. Сеть MLN может состоять из множества таких LSR, которые способны поддерживать различные ISC.
• Каждый LSR может одновременно поддерживать несколько ISC.Такие LSR называют multi-switching-type-capable LSR; их дополнительно делят на симплексные и гибридные, как описано в параграфе 4.2.
• MLN может представлять собой комбинацию обоих перечисленных выше типов.

Поскольку GMPLS обеспечивает полнофункциональную основу для управления различными системами коммутации, для контроля MLN/MRN можно использовать один экземпляр GMPLS. Это обеспечивает возможность быстрого предоставления сервиса и эффективное построение трафика для всех технологий коммутации. В таких сетях соединения TE консолидируются в единую базу TED¹⁶. Поскольку TED содержит информацию для всех зон и уровней, существующих в сети, пути через множество зон и уровней можно рассчитывать с использованием этой TED. Таким образом может быть достигнута оптимизация сетевых ресурсов в масштабах всей MLN/MRN.

Рассмотрим в качестве примера MRN, содержащую маршрутизаторы PSC и кросс-коннекторы TDM. Предположим, что путь LSP¹⁷ маршрутизируется между PSC-маршрутизаторами (отправителем и получателем) и LSP может быть направлен через зону PSC (т. е., с использованием только топологии зоны коммутации пакетов). Если требования по производительности для LSP не выполняются, между маршрутизаторами PSC могут создаваться новые соединения TE через TDM-зону (например, по каналам VC-12) и LSP может направляться по этим соединениям TE. Более того, даже при успешной организации LSP через зону PSC, могут создаваться иерархические TDM LSP (через зону TDM между маршрутизаторами PSC), которые могут использоваться для удовлетворения объективных потребностей оператора в сетевых ресурсах (например, полосе). Такая же ситуация возникает в тех случаях, когда предоставляются дополнительные VC4 LSP для обеспечения дополнительной гибкости уровней VC12 и/или VC11 в MLN.

В разделах 3 и 4 приведена дополнительная информации рассмотрены дополнительные концепции и мотивация. В разделе 5 детально рассматриваются требования к протоколам, используемым для реализации многоуровневых и многозоновых сетей.

1.1. Сфера рассмотрения

В первых параграфах этого документа рассматриваются мотивы и причины, побудившие к разработке и реализации сетей MRN/MLN. Далее рассматриваются требования к функциям, которые должны обеспечиваться плоскостью управления GMPLS для поддержки MRN/MLN. Целью этого документа не является задание специфических элементов и/или протоколов. Применимость существующих протоколов GMPLS и любых протокольных расширений для MRN/MLN рассматривается в отдельных документах [MRN-EVAL].

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

Для таких доменов TE взаимодействие с узлами/доменами, поддерживающими интерфейсы, не являющиеся GMPLS (такие, как интерфейсы, определенные другими организациями по разработке стандартов SDO¹⁸), может потребовать реализацию функции межсетевого взаимодействия. Спецификация и локализация такой функции выходят за пределы рассмотрения данного документа (поскольку такая функция отвечает за аспекты межсетевого взаимодействия).

В данном документе предполагается, что соединение смежных MRN/MLN доменов TE осуществляется с использованием [RFC4726], когда на периметре этих доменов поддерживаются междоменные расширения GMPLS RSVP-TE.

2. Используемые соглашения

Хотя этот документ не является спецификацией протокола, ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

В контексте этого документа сквозной LSP определяется как LSP, который начинается на неком клиентском уровне, заканчивается на том же уровне и может проходить через один или множество более низких уровней. В терминах возможностей коммутации это означает, что если выходной интерфейс на головном¹⁹ LSR имеет возможности X, то входной интерфейс оконечного LSR²⁰ также имеет возможности X. Далее, для любого интерфейса, через который проходит LSP, на любом промежуточном LSR с возможностями Y, должно выполняться условие Y >= X.

2.1. Список сокращений

ERO: Explicit Route Object — объект явного маршрута.

FA: Forwarding Adjacency — смежность по пересылке.

FA-LSP: Forwarding Adjacency Label Switched Path — путь LSP со смежностью по рассылке

FSC: Fiber Switching Capable — способность коммутации волокон.

ISC: Interface Switching Capability — способность коммутации интерфейсов.

ISCD: Interface Switching Capability Descriptor — дескриптор способности коммутации интерфейсов.

L2SC: Layer-2 Switching Capable — способность коммутации на канальном уровне (2).

LSC: Lambda Switching Capable — способность коммутации длин волн («лямбд»).

LSP: Label Switched Path — путь с коммутацией по меткам.

LSR: Label Switching Router — маршрутизатор с коммутацией по меткам.

MLN: Multi-Layer Network — многоуровневая сеть.

MRN: Multi-Region Network — многозоновая сеть.

PSC: Packet Switching Capable — способность коммутации пакетов.

SRLG: Shared Risk Link Group — группа канала с разделяемым риском.

TDM: Time-Division Multiplexing — мультиплексирование с разделением по времени.

TE: Traffic Engineering — построение трафика.

TED: Traffic Engineering Database — база данных построения трафика.

VNT: Virtual Network Topology — топология виртуальной сети.

3. Позиционирование

Многозоновые сети MRN всегда являются многоуровневыми (MLN), поскольку сетевые устройства на границах зон используют различные ISC. MLN, однако, не обязательно является MRN, поскольку множество уровней может полностью содержаться в одной зоне. Например, VC12, VC4 и VC4-4c являются разными уровнями зоны TDM.

3.1. Уровни плоскости данных и зоны плоскости управления

Уровень плоскости данных представляет собой набор сетевых ресурсов, способных завершать (терминировать) и/или коммутировать трафик данных в определенном формате [RFC4397]. Эти ресурсы могут использоваться для организации LSP с целью доставки трафика. Примерами уровней могут служить VC-11 и VC4-64c.

С точки зрения плоскости управления зона LSP определяется как набор из одного или множества уровней плоскости данных, разделяющих общую технологию (тип) коммутации. Например, уровни VC-11, VC-4 и VC-4-7v являются частями зоны TDM. В настоящее время определены зоны PSC, L2SC, TDM, LSC и FSC. Следовательно, зона LSP является областью использования технологии (идентифицируемой типом ISC), для которой ресурсы плоскости данных (т. е. каналы передачи данных) представлены в плоскости управления, как агрегат информации TE, связанной с набором каналов (т. е. каналов TE). Например, поддерживающие VC-11 и VC4-64c каналы TE являются частью одной зоны TDM. Таким образом, в одной зоне сети может существовать множество уровней.

Отметим также, что зоны могут различаться в плоскости управления. Уровни одной зоны используют общую технологию коммутации и, следовательно, – общий набор связанных с технологией сигнальных объектов и обусловленную технологией установку атрибутов соединения TE на плоскости управления, но уровни из разных зон могут использовать разные, связанные с технологией, объекты и значения атрибутов TE. Это означает, что простая пересылка сигнальных сообщений между LSR с различными технологиями коммутации может оказаться невозможной. Это обусловлено тем, что некоторые сигнальные объекты (например, параметры трафика) изменяются при пересечении границы зоны даже в тех случаях, когда для управления всей MRN используется один экземпляр плоскости управления. Для решения этой проблемы может использоваться триггерная сигнализация (параграф 4.3.1).

3.2. Сети сервисного уровня

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

Например, некоторые заказчики покупают у провайдера услуги уровня 1 (т. е. транспортного²¹), другие — уровня 2 (например, ATM), а третьи — уровня 3 (IP/MPLS). Сервис провайдер реализует услуги, как стек сетевых уровней, локализованных в одной или нескольких зонах сети. Сетевые уровни обычно организуются в соответствии с возможностями коммутации сетевых устройств. Таким образом, сеть заказчика может поддерживаться «поверх» многоуровневой/многозоновой сети на базе GMPLS. Например, услуги уровня 1 (реализуются через сетевой уровень зон TDM и/или LSC и/или FSC) могут поддерживать сеть уровня 2 (реализуется через ATM VP/VC²²), которая, в свою очередь, поддерживает сеть уровня 3 (зона IP/MPLS). Поддерживаемые отношения плоскости данных представляют собой отношения «клиент-сервер», где нижележащий уровень предоставляет услуги вышележащему уровню, а сам при этом использует каналы данных, реализованные на более низком уровне.

Услуги, обеспечиваемые MRN/MLN на базе GMPLS, называют «многозоновыми/многоуровневыми сетевыми услугами²³». Например, традиционные сети IP и IP/MPLS могут поддерживаться «поверх» сетей MRN/MLN. Это подчеркивает мотивирующий характер предоставления таких разнообразных услуг для развертывания многозоновых/многоуровневых сетей.

Сеть заказчика может поддерживаться «поверх» сервера сети MRN/MLN на базе GMPLS, который обеспечивается сервис-провайдером. Например, «чистая» сеть IP и/или IP/MPLS может быть обеспечена «поверх» сетей packet-over-optical²⁴ на базе GMPLS [RFC5146]. Отношения между сетями представляют собой отношения «клиент-сервер», а такие услуги зазывают услугами MRN/MLN. В таких случаях сеть заказчика может формировать часть MRN/MLN или быть частично отделенной (например, для поддержки раздельной маршрутной информации при общей сигнализации).

3.3. Вертикальное и горизонтальное взаимодействие и интеграция

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

Горизонтальное взаимодействие определяется как протокольный обмен между сетевыми контроллерами, которые управляют транспортными узлами внутри данного уровня или зоны. Взаимодействие на плоскости управления между двумя сетевыми элементами TDM, коммутирующими на уровне OC-48, является примером горизонтального взаимодействия. Операции протокола GMPLS обслуживают горизонтальные взаимодействия внутри одной области маршрутизации. Случай, когда взаимодействие осуществляется через границу домена (например, между двумя областями маршрутизации внутри одного сетевого уровня) рассматривается как часть междоменного взаимодействия [RFC4726] и называется горизонтальной интеграцией. Таким образом, горизонтальная интеграция указывает на механизмы взаимодействия между частями сети и/или административными подразделениями типа областей маршрутизации и автономных систем.

Эта особенность требует дальнейшего прояснения для тех случаев, когда административные домены соответствуют границам уровней/зон. Горизонтальное взаимодействие расширяется для таких ситуаций. Например, механизмы взаимодействия между двумя областями LSC связаны с горизонтальной интеграцией. С другой стороны, механизмы взаимодействия между доменом PSC (например, IP/MPLS) и отдельным доменом, TDM (например, VC4 SDH²⁵), через который он работает, являются частью горизонтальной интеграции и, в то же время, могут представляться как первый шаг в направлении вертикальной интеграции.

3.4. Мотивация

Применимость GMPLS ко множеству разных технологий коммутации обеспечивает возможность унифицированного контроля и управления для предоставления и восстановления LSP. В действительности основным мотивом для унификации возможностей и операций плоскости управления GMPLS является желание поддерживать маршрутизацию multi-LSP-region [RFC4206] и возможности TE. Например, это обеспечит возможность эффективного использования сетевых ресурсов для зон Packet/Layer2 LSP и TDM или Lambda LSP в сетях с высокой пропускной способностью.

Разумные основания для построения многозоновых/многоуровневых сетей, управляемых GMPLS, приведены ниже:

• Поддержка множества экземпляров плоскости управления на устройствах, поддерживающих более одного типа коммутации, не только осложняет взаимодействие между экземплярами плоскостей управления, но и повышает объем операций, требуемых для обслуживания каждого экземпляра плоскости управления.
• Унификация адресных пространств помогает избежать возникновения множества идентификаторов для одного объекта (например, канала или, в более общем случае, любого сетевого ресурса). С другой стороны такое объединение не оказывает влияния на разделение между плоскостями управления и данных.
• За счет поддержки единственного экземпляра протокола маршрутизации и одной базы данных TE на LSR модель унифицированной плоскости управления снимает требование поддержки выделенной топологии маршрутизации для каждого уровня и, следовательно, не требует полносвязной топологии соединений между маршрутизаторами, как в случае перекрывающихся плоскостей управления.
• Взаимодействие между технологическими уровнями, в которых канал управления связан с каналом данных (например, плоскости данных в форме кадров/пакетов), и технологическими уровнями, в которых нет прямой связи между каналом управления и каналом данных (SONET/SDH, G.709 и т. п..) облегчается за счет поддержки в GMPLS возможности связать сигнализацию плоскости управления в основной полосе с оконечными интерфейсами IP в плоскости управления.
• Управление ресурсами и политика, применяемые на краях таких сетей MRN/MLN, становятся более простыми (меньше взаимодействий) и масштабируемыми (за счет агрегирования).
• Многозоновое/многоуровневое построение трафика упрощается при хранении информации о соединениях TE из разных зон/уровней в общей базе TED.

4. Ключевые концепции сетей MLN и MRN на базе GMPLS

Сеть, охватывающая транспортные узлы с множеством уровней плоскости данных и одной или несколькими ISC, контролируемая одним экземпляром плоскости управления GMPLS, называется многоуровневой сетью (MLN). Подмножество MLN состоит из сетей, поддерживающих LSP с различными технологиями коммутации (ISC). Сеть, поддерживающая более одной технологии коммутации, называется многозоновой (MRN).

4.1. Возможности коммутации интерфейсов

Понятие «возможность коммутации интерфейсов (ISC²⁶) вводится в GMPLS для унификации поддержки разнотипных технологий коммутации [RFC4202]. ISC идентифицируется типом коммутации.

Тип коммутации (тип возможности коммутации) показывает способность узла пересылать данные, относящиеся к определенной технологии плоскости данных, и однозначно идентифицирует зону сети. Определены следующие типы ISC (и, следовательно, зон): PSC, L2SC, TDM, LSC и FSC. Каждое окончание канала данных (точнее, каждый интерфейс, подключающий канал данных к узлу) в сети GMPLS ассоциируется с ISC.

Значение ISC анонсируется как часть дескриптора (ISCD²⁷), являющегося атрибутом окончания канала TE, и ассоциируется с конкретным канальным интерфейсом [RFC4202]. Кроме ISC дескриптор ISCD содержит информацию, включающую тип кодирования, гранулярность полосы и незарезервированную полосу на каждом из 8 уровней приоритета, с которым может быть создан путь LSP. ISCD не идентифицирует сетевые уровни, этот дескриптор уникально характеризует информацию, связанную с одним или множеством сетевых уровней.

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

4.2. Множество ISC

В MLN элементы сети могут представлять собой узлы, поддерживающие один (single-switching-type-capable) или множество (multi-switching-type-capable) типов коммутации. Узлы с одним типом коммутации анонсируют свое значение ISC как часть ISCD для описания возможностей каждого окончания своих каналов TE. Этот случай рассмотрен в [RFC4202].

LSR с поддержкой множества типов коммутации делятся на симплексные и гибридные. Различие между ними состоит в способе анонсирования множества поддерживаемых ISC:

• Симплексный узел может завершать каналы данных с различными возможностями коммутации, когда каждый канал данных подключен к узлу через отдельный канальный интерфейс. Такой узел анонсирует несколько каналов TE, каждый из которых имеет одно значение ISC, передаваемое в ISCD (в соответствии с правилами [RFC4206]). Примером может служить LSR с каналами PSC и TDM, каждый из которых подключен к LSR через свой интерфейс.
• Гибридный узел может завершать каналы данных с разнотипной коммутацией, подключенные к узлу через один интерфейс. Такой узел анонсирует канал TE, содержащий более одного дескриптора ISCD, каждый из которых имеет свое значение ISC. Например, узел может завершать каналы данных PSC и TDM, соединяя эти разнотипные внешние каналы данных через внутренние каналы. Внешние интерфейсы, подключенные к узлу, поддерживают одновременно PSC и TDM.

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

4.2.1. Сети с гибридными узлами, поддерживающими разные типы коммутации

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

На рисунке 1 показан пример гибридного узла. Этот узел имеет два коммутационных элемента (две матрицы), поддерживающие, например, коммутацию TDM и PSC. Узел служит завершением каналов PSC и TDM (Link1 и Link2, соответственно). Кроме того, этот узел имеет внутреннее соединение между двумя коммутационными элементами.

Два коммутационных элемента соединены внутри между собой таким способом, что обеспечивается возможность завершения некоторых ресурсов канала Link2 (для примера) и преобразования для трафика PSC, принимаемого/передаваемого через интерфейс PSC (#b). Такая ситуация моделируется в GMPLS путем соединения локального окончания Link2 с коммутационным элементом TDM через дополнительный интерфейс, реализующий функции завершения/преобразования. Существует два способа организации PSC LSP через гибридный узел. Анонсирование доступных ресурсов (т. е. Unreserved и Min/Max LSP Bandwidth) должно учитывать оба способа.

            .............................
            : Элемент сети              :
            :            --------       :
            :           |  PSC   |      :
Link1 -------------<->--|#a      |      :
            :           |        |      :
            :  +--<->---|#b      |      :
            :  |         --------       :
            :  |        ----------      :
TDM         :  +--<->--|#c  TDM   |     :
 +PSC       :          |          |     :
Link2 ------------<->--|#d        |     :
            :           ----------      :
            :............................

Рисунок 1: Гибридный узел

4.3. Интегрированное построение трафика (TE) и управление ресурсами

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

Эти концепции позволяют организовать работу одного сетевого уровня на основе топологии (т. е. Каналов TE), обеспечиваемой другими сетевыми уровнями (например, использование LSC LSP для организации PSC LSP). Благодаря этому может быть достигнут высокий уровень контроля и межсетевого взаимодействия, включая (но не ограничиваясь):

• динамическую организацию FA²⁸ LSP [RFC4206] (см. параграфы 4.3.2 и 4.3.3);
• предоставление сквозных LSP с динамическим переключением FA LSP.

Отметим, в сети MLN/MRN, включающей узлы с поддержкой множества типов коммутации, явный маршрут, используемый для организации сквозного LSP, может задавать узлы, относящиеся к разным уровням или зонам. В этом случае может потребоваться механизм управления динамическим созданием FA-LSP (см. параграфы 4.3.2 и 4.3.3).

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

4.3.1. Триггерная сигнализация

Когда LSP проходит через границу от верхнего уровня к нижнему, такой путь может оказаться вложенным в FA-LSP нижележащего уровня, который проходит через этот уровень. С точки зрения сигнализации существует два варианта организации FA-LSP нижележащего уровня — статический (подготовленный заранее) и динамический (триггерный). Статический FA-LSP может инициироваться оператором или автоматически с использованием механизмов типа TE auto-mesh²⁹ [RFC4972]. Если такого LSP нижележащего уровня еще нет, LSP можно организовать динамически. Такой механизм называется триггерной сигнализацией.

4.3.2. FA-LSP

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

Более того, путь будет анонсироваться как соединение TE, что позволит другим узлам рассматривать LSP в качестве канала TE при своем расчете путей [RFC4206]. LSP, созданные статически или динамически одним экземпляром плоскости управления и анонсируемые в качестве каналов TE в тот же экземпляр плоскости управления, называются FA-LSP³⁰. Путь FA-LSP анонсируется в качестве канала TE и этот канал называется FA³¹. FA имеет особые свойства, не требующие смежности маршрутизаторов (peering) между конечными точками пути при сохранении связности на плоскости управления между конечными точками FA-LSP на основе сигнальной смежности. Каналы FA являются полезным и мощным средством повышения уровня масштабируемости сетей с поддержкой GMPLS-TE, поскольку множество LSP вышележащих уровней может быть вложено (агрегировано) в один канал FA-LSP.

Агрегирование LSP позволяет создавать вертикальную иерархию (вложенность) LSP. Множество FA-LSP через нижележащий уровень или внутри него можно использовать в процессе выбора пути для LSP вышележащего уровня. Подобно этому, LSP вышележащего уровня могут проходить через динамические каналы данных, реализованные в виде LSP (также, как при передаче через обычные каналы данных). Этот процесс требует вложенности LSP на основе иерархического процесса [RFC4206]. База TED содержит множество анонсов LSP от различных уровней, которые идентифицируются дискриминаторами ISCD, содержащимися в анонсах каналов TE, связанных с LSP [RFC4202].

Если LSP нижележащего уровня не анонсируется как FA, этот путь все равно может использоваться для передачи LSP вышележащего уровня через нижележащий. Например, если LSP организуется с использованием триггерной сигнализации, этот путь может использоваться LSP вышележащего уровня, вызвавшего переключение (триггер). Более того, нижележащий уровень остается доступным для использования другими LSP вышележащего уровня, приходящими на границу.

При некоторых обстоятельствах может быть полезен контроль анонсов LSP в качестве FA в сигнальном процессе организации LSP [DYN-HIER].

4.3.3. Виртуальная сетевая топология

Набор из одного или множества LSP нижележащего уровня обеспечивает информацию для эффективного обслуживания путей на верхних уровнях MLN или, иными словами, обеспечивает виртуальную сетевую топологию (VNT³²) для верхних уровней. Например, набор LSP, каждый из которых поддерживается LSC LSP, обеспечивает VNT для уровней зоны PSC в предположении, что зона PSC подключена к зоне LSC. Отметим, что один путь LSP нижележащего уровня является особым случаем VNT. Настройка VNT осуществляется путем организации или разрыва путей LSP нижележащего уровня. За счет использования сигнализации GMPLS и протоколов маршрутизации VNT можно адаптировать к потребностям передачи трафика.

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

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

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

5. Требования

5.1. Обслуживание узлов с одним и многими типами коммутации

Сеть MRN/MLN может содержать узлы, поддерживающие один или множество типов коммутации. Механизм расчета пути в MLN должен обеспечивать возможность расчета путей, включающих любую комбинацию таких узлов.

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

5.2. Анонсирование доступных ресурсов смежности

Гибридному узлу следует поддерживать ресурсы на своих внутренних каналах (каналах, требуемых для вертикальной интеграции между уровнями). Более того, должны быть подготовлены элементы расчета пути для использования информации о доступности ресурсов завершения и преобразования в процессе расчета пути MRN/MLN. Это будет снижать вероятность блокировки организованного LSP вышележащего уровня по причине нехватки ресурсов завершения/преобразования на нижележащих уровнях.

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

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

5.3. Масштабируемость

MRN/MLN работает на основе унифицированных моделей маршрутизации и построения трафика.

• Унифицированная модель маршрутизации. За счет поддержки одного экземпляра протокола маршрутизации и одной базы TED на LSR унифицированная модель плоскости управления снимает требование наличия выделенной топологии маршрутизации для каждого уровня и, следовательно, требует полной связности маршрутизаторов на каждом уровне.
• Унифицированная модель TE. База TED в каждом LSR заполняется каналами TE из всех уровней каждой зоны (интерфейсы каналов TE в LSR, поддерживающих множество типов коммутации, могут анонсироваться с множеством ISCD). Это может приводить к росту объема информации, которая хранится в сети и рассылается в лавинном режиме.

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

Таким образом, механизмы маршрутизации MRN/MLN должны обеспечивать масштабирование в случаях роста любого из перечисленных параметров:

• число узлов;
• число каналов TE (включая FA-LSP);
• число LSP;
• число зон и уровней;
• число ISCD на канал TE.

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

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

5.4. Стабильность

Расчет пути зависит от топологии сети и состояния каналов. На стабильность расчета пути на вышележащем уровне может оказывать влияние частота изменений VNT и/или частота изменения параметров соединений TE (например, метрики TE) в VNT. В этом контексте отказоустойчивость VNT определяется как возможность гладкого изменения и предотвращения распространения изменений на вышележащие уровни. Изменения в VNT могут вызываться созданием, удалением или изменением LSP.

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

5.5. Минимизация повреждений

При реконфигурировании VNT в соответствии с изменившимися запросами трафика может повреждаться LSP вышележащего уровня. Такие повреждения должны быть минимизированы.

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

5.6. Наследование атрибутов LSP

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

• ISC;
• метрика TE;
• максимальная полоса LSP для каждого уровня приоритета;
• нерезервируемая полоса для каждого уровня приоритета;
• максимальная резервируемая полоса;
• атрибуты защиты;
• минимальная полоса LSP (в зависимости от возможности коммутации);
• SRLG.

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

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

5.7. Расчет путей с вложенной сигнализацией и без нее

Расчет пути может принимать во внимание зону LSP и границы уровней. При расчете пути выбор LSP может ограничиваться только теми каналами, которые используют интерфейсы, поддерживающие PSC. Для примера предположим, что TDM-LSP маршрутизируется через топологию, составленную из каналов TE того же уровня TDM. При расчете пути для LSP данные TED могут фильтроваться для того, чтобы оставить лишь те каналы, оба конца которых поддерживают LSP с нужным типом коммутации. В этом случае иерархическая маршрутизация осуществляется за счет использования фильтрации TED по возможностям коммутации (т. е., с выбором определенного уровня).

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

Сигнальный запрос вышележащего уровня может включать объект явной маршрутизации (ERO³³), который содержит только интервалы вышележащего уровня. В этом случае граничный узел отвечает за триггерное создание FA-LSP нижележащего уровня с использованием выбранного пути или выбор любого доступного LSP нижележащего уровня в качестве канала данных для вышележащего уровня. Этот механизм подходит для сред, где TED фильтруется на вышележащем уровне и на каждом уровне используется отдельный экземпляр маршрутизации или сред, где административные правила не позволяют вышележащему уровню задавать пути через нижележащий уровень.

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

В дополнение к этому сигнальный запрос вышележащего уровня может включать ERO, задающий маршрут FA-LSP нижележащего уровня. В этом случае граничный узел может самостоятельно решать, следует ли ему использовать путь, содержащийся в ERO или заново рассчитать путь на нижележащем уровне.

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

FA-LSP нижележащего уровня могут анонсироваться на вышележащий уровень просто как FA-LSP или как сосед IGP нижележащего уровня.

5.8. Использование ресурсов LSP

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

5.8.1. Организация и разрыв FA-LSP

При малых запросах трафика некоторые FA-LSP, не используемые для передачи LSP вышележащего уровня, могут освобождаться, что ведет к освобождению ресурсов нижележащего уровня и возможности их передачи другим задачам. Отметим, что если незначительная часть доступной полосы FA-LSP продолжает использоваться, вложенные LSP могут быть перемаршрутизированы в другие FA-LSP (возможно, с использованием метода make-before-break³⁴) для полного освобождения FA-LSP. Кроме того, неиспользуемые FA-LSP могут сохраняться для использования в будущем. Освобождение или сохранение неиспользуемых FA-LSP определяется политикой.

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

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

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

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

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

5.8.2. Виртуальные каналы TE

Может показаться недостатком создание заранее набора LSP нижележащего уровня, которые будут обеспечивать VNT, поскольку для этого будет резервироваться полоса, которая могла бы использоваться для других LSP в отсутствие трафика вышележащего уровня.

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

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

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

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

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

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

Концепция VNT может быть расширена для использования виртуальных каналов TE, как части VNT. Комбинация заранее организованных (реальных) и виртуальных каналов TE определяет VNT, обеспечиваемую нижним уровнем. VNT можно изменять путем организации и/или удаления виртуальных каналов TE, а также путем изменения реальных каналов (т. е., полностью обеспечиваемых LSP). Создание и поддержка VNT выходят за пределы данного документа.

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

5.9. Верификация LSP

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

5.10. Управление

Сети MRN/MLN требуют поддержки функций управления. Требуются операции для обеспечения некоторого уровня контроля и управления для коммутаторов и каналов в сети, которые могут относиться к одному уровню или одной зоне.

Мы можем рассмотреть две разных модели работы: (1) управление в рамках уровня и (2) кросс-уровневое управление.

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

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

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

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

Существуют модули MIB для моделирования сетей GMPLS и управления ими [RFC4802] [RFC4803]. Некоторые из разворачиваемых сетей GMPLS могут выбирать использование модулей MIB для работы отдельных сетевых уровней. В таких случаях операторы могут принять решение о координации уровней с помощью модуля MIB, который может быть разработан. Для многоуровневых протокольных решений (т. е., решений, где один экземпляр плоскости управления работает на нескольких уровнях) следует обеспечивать возможность управления с помощью модулей MIB. Может быть разработан дополнительный модуль MIB для координации множества сетевых уровней модулем MIB плоскости управления.

Инструменты OAM³⁵ имеют важное значение для успеха развертывания всех сетей.

Требования OAM для сетей GMPLS описаны в документе [GMPLS-OAM]. Этот документ отмечает, что в протокольные решения для отдельных сетевых уровней следует включать механизмы для OAM или обеспечивать наследование функций OAM от физических сред уровней. Дальнейшее обсуждение этого вопроса выходит за пределы данного документа.

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

• В контексте и технологии высшего уровня в LSP (т. е. уровня технологии первого интервала маршрутизации) должна обеспечиваться возможность сквозного OAM для MLN LSP. Эта функция появляется на входном LSP как обычная функция OAM на базе LSP [GMPLS-OAM], но на границах уровней, в зависимости от метода, используемого для прохождения через нижележащий уровень, может потребоваться отображение операций OAM клиентского уровня на операции OAM серверного уровня. Большинство таких требований сильно зависит от средств OAM технологии плоскости данных на клиентском и серверном уровнях. Однако механизмы плоскости управления, используемые на клиентском уровне в соответствии с [GMPLS-OAM], должны отображаться и включать OAM на серверном уровне.
• Работа OAM, включаемая в соответствии с [GMPLS-OAM] на клиентском уровне для LSP, должна выполняться на всей протяженности LSP. Это означает, что при пересечении LSP домена технологии нижележащего уровня, операции OAM клиентского уровня должны гладко соединяться внутри клиентского уровня на обоих концах LSP клиентского уровня.
• Функции OAM на серверном уровне должны быть контролируемыми с клиентского уровня так, чтобы LSP серверного уровня, которые поддерживают LSP клиентского уровня, имели функции OAM, включаемые по запросу клиентского уровня. Такой контроль следует осуществлять в соответствии с правилами на границе уровня, когда автоматическое включение и запросы LSP на серверный уровень контролируются политикой.
• Информация о состоянии, включающая сообщения об ошибках и сигналы тревоги, применимые к LSP серверного уровня, должны быть доступными на клиентском уровне. Эту информацию следует делать настраиваемой для автоматического уведомления клиентского уровня на границе уровня; кроме того, к этой информации следует применять политику, позволяющую серверному уровню фильтровать или скрывать часть информации, передаваемой на клиентский уровень. Более того, на клиентском уровне следует обеспечивать возможность фильтрации такой информации.

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

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

Архитектура MLN/MRN не вносит дополнительных требований безопасности, сверх тех, которые содержатся в общей архитектуре GMPLS, описанной в [RFC3945]. Дополнительное рассмотрение вопросов безопасности, связанных с MPLS и GMPLS, приведено в [MPLS-SEC].

Однако при работе отдельных уровней сети MLN/MRN в разных административных домена могут возникать дополнительные вопросы безопасности в связи с механизмами, позволяющими организовывать LSP через границы уровней, триггерным управлением LSP нижележащего уровня и управлением VNT. Может потребоваться рассмотрение объема информации, разделяемой между разными административными доменами, и компромисса между многоуровневыми TE и конфиденциальностью информации при передаче через другой административный домен.

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

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

Авторы признательны Adrian Farrel и членам ITU-T Study Group 15, Question 14 за внимательный просмотр документа. Авторы также благодарят команду IESG за тщательный просмотр документа, выражаю особую благодарность Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu и Dave Ward.

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3945] Mannie, E., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture”, RFC 3945, October 2004.

[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., “Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4202, October 2005.

[RFC4206] Kompella, K. and Y. Rekhter, “Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)”, RFC 4206, October 2005.

[RFC4397] Bryskin, I. and A. Farrel, “A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T’s Automatically Switched Optical Network (ASON) Architecture”, RFC 4397, February 2006.

[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, “A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering”, RFC 4726, November 2006.

8.2. Дополнительная литература

[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. And Z. Ali, “Procedures for Dynamically Signaled Hierarchical Label Switched Paths”, Work in Progress, February 2008.

[MRN-EVAL] Le Roux, J.L., Ed., and D. Papadimitriou, Ed., “Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)”, Work in Progress, December 2007.

[RFC5146] Kumaki, K., Ed., “Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks”, RFC 5146, March 2008.

[MPLS-SEC] Fang, L., Ed., “Security Framework for MPLS and GMPLS Networks”, Work in Progress, February 2008.

[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., “Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base”, RFC 4802, February 2007.

[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., “Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base”, RFC 4803, February 2007.

[RFC4847] Takeda, T., Ed., “Framework and Requirements for Layer 1 Virtual Private Networks”, RFC 4847, April 2007.

[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, “Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership”, RFC 4972, July 2007.

[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, “OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks”, Work in Progress, October 2007.

9. Адреса участников работы

Eiji Oki

NTT Network Service Systems Laboratories

3-9-11 Midori-cho, Musashino-shi

Tokyo 180-8585

Japan

Phone: +81 422 59 3441

EMail: oki.eiji@lab.ntt.co.jp

Ichiro Inoue

NTT Network Service Systems Laboratories

3-9-11 Midori-cho, Musashino-shi

Tokyo 180-8585

Japan

Phone: +81 422 59 3441

EMail: ichiro.inoue@lab.ntt.co.jp

Emmanuel Dotaro

Alcatel-Lucent

Route de Villejust

91620 Nozay

France

Phone: +33 1 3077 2670

EMail: emmanuel.dotaro@alcatel-lucent.fr

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

Kohei Shiomoto

NTT Network Service Systems Laboratories

3-9-11 Midori-cho, Musashino-shi

Tokyo 180-8585

Japan

EMail: shiomoto.kohei@lab.ntt.co.jp

Dimitri Papadimitriou

Alcatel-Lucent

Copernicuslaan 50

B-2018 Antwerpen

Belgium

Phone : +32 3 240 8491

EMail: dimitri.papadimitriou@alcatel-lucent.be

Jean-Louis Le Roux

France Telecom R&D

Av Pierre Marzin

22300 Lannion

France

EMail: jeanlouis.leroux@orange-ftgroup.com

Martin Vigoureux

Alcatel-Lucent

Route de Villejust

91620 Nozay

France

Phone: +33 1 3077 2669

EMail: martin.vigoureux@alcatel-lucent.fr

Deborah Brungard

AT&T

Rm. D1-3C22 – 200

S. Laurel Ave.

Middletown, NJ 07748

USA

Phone: +1 732 420 1573

EMail: dbrungard@att.com

---

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

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

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2008).

К этому документу применимы права, лицензии и ограничения, указанные в 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.