RFC 5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework

Internet Engineering Task Force (IETF)                      D. Fedyk
Request for Comments: 5828                            Alcatel-Lucent
Category: Informational                                    L. Berger
ISSN: 2070-1721                                                 LabN
                                                        L. Andersson
                                                            Ericsson
                                                          March 2010

 

Архитектура и схема обобщенной коммутации по меткам для Ethernet

Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework

PDF

Аннотация

В настоящее время выполняется множество работ по расширению возможностей коммутаторов Ethernet и повышению эффективности пересылки кадров Ethernet. В результате таких работ сфера применения Ethernet расширилась до транспортных сетей, в которых традиционно использовались такие технологии, как SONET¹/SDH², TDM³ и ATM⁴. В этом документе рассматривается архитектура и схема обобщенного уровня управления для Ethernet в такой «транспортной сети». Спецификации GMPLS⁵ для подобных технологий уже существуют. В этом документе рассмотрены некоторые расширения, которые потребовались на управляющем уровне GMPLS, а также схема таких расширений.

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ подготовлен рабочей группой Internet Engineering и содержит согласованный взгляд сообщества IETF. Документ обсуждался публично и одобрен для публикации IESG⁶. Не все документы, одобренные IESG, претендуют на статус стандартов Internet (см. раздел 2 документа RFC 5741).

Информацию о текущем состоянии данного документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5828.

Авторские права

Авторские права ((c) 2010) принадлежат IETF Trust и лицам, являющимся авторами документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

В настоящее время выполняется множество работ по расширению возможностей коммутаторов Ethernet и повышению эффективности пересылки кадров Ethernet. В результате таких работ сфера применения Ethernet расширилась до транспортных сетей, в которых прежде традиционно использовались такие технологии, как SONET/SDH, TDM и ATM. Развитие технологии Ethernet в направлении магистральных сетей идет очень активно и продолжается до сих пор.

Многие организации активно работают в сфере расширения технологии Ethernet для ее использования в магистральных сетях. Эта активность сосредоточена в рабочих группах IEEE⁷ 802.1, сектора стандартизации телекоммуникаций ITU-T⁸ и MEF⁹. Усилия этих групп сфокусированы на пересылке Ethernet, расширении уровня управления Ethernet и протокола Spanning Tree, но не явно маршрутизируемого уровня управления, основанного на ограничениях.

В контексте уровня пересылки определяются или будут определены расширения для поддержки различных моделей транспортной пересылки Ethernet, режимов защиты и сервисных интерфейсов. Примерами таких расширений могут служить [802.1ah], [802.1Qay], [G.8011] и [MEF.6]. Эти расширения повышают гибкость уровня пересылки Ethernet, а в некоторых случаях позволяют отказаться от пересылки на основе модели «остовного дерева¹⁰». Например, в случае [802.1ah] повышение уровня гибкости пересылки обеспечивается путем добавления «адресного пространства провайдера». [802.1Qay] поддерживает использование систем обеспечения и протоколов сетевого управления, которые явно задают пути трафика.

В этом документе дается схема коммутации меток Ethernet – GELS¹¹. Для поддержки разных моделей GELS явно требуется более одного типа коммутации и потребуется расширение процедур GMPLS в зависимости от типа коммутации. Эти вопросы будут рассматриваться в отдельных документах, связанных с конкретными технологиями.

В модели «провайдерского моста» (provider bridge), разработанной в рамках проекта IEEE 802.1ad и внесенной в стандарт IEEE 802.1Q [802.1Q], добавляется идентификатор виртуальной ЛВС (VLAN¹²) – VID. Этот VID называют сервисным VID (S-VID¹³) и он передается в специальном теге S-TAG¹⁴. В модели PBB¹⁵ [802.1ah] идентификатор опорной сети B-VID¹⁶ и заголовок B-MAC с тегом экземпляра сервиса (I-TAG) инкапсулируются в пользовательский или служебный кадр Ethernet.

В стандарте IEEE 802.1Q термины PBB и PBBN¹⁷ используются в контексте упомянутых расширений.

Пример защитного расширения Ethernet можно найти в [G.8031]. Эксплуатация, администрирование и обслуживание Ethernet (OAM¹⁸) являются другой важной сферой, которая должна быть расширена для обеспечения провайдерских услуг на основе Ethernet. Связанные с этим расширения можно найти в [802.1ag] и [Y.1731].

Модель сервиса на базе Ethernet будет определяться в контексте MEF и ITU-T. Документы [MEF.6] и [G.8011] обеспечивают основу для определения сетеориентированных характеристик сервиса Ethernet в транспортных сетях. В этих документах рассматриваются общие характеристики соединений Ethernet, интерaейсы Ethernet между пользователем и сетью (UNI¹⁹), а также межсетевые интерфейсы Ethernet (NNI²⁰). [G.8011.1] определяет сервис «частных линий Ethernet» (EPL²¹), а [G.8011.2] – сервис «виртуальных частных линий Ethernet» (EVPL²²). В [MEF.6] рассматриваются оба типа сервиса. Эти работы согласуются с типами коммутации Ethernet, определенными в [802.1ah].

Расширения Ethernet для уровней пересылки и управления позволяют отключить стандартный протокол STP²³, но не определяют явно маршрутизируемого, основанного на ограничениях²⁴ уровня управления. Например, [802.1Qay] является исправленным вариантом стандарта IEEE 802.1Q, который явно разрешает построение путей пересылки трафика Ethernet.

Работа IETF GMPLS обеспечивает общий уровень управления для различных технологий канального уровня в сетях провайдеров Internet и телекоммуникационных операторов. Архитектура GMPLS описана в RFC 3945 [RFC3945]. Спецификации протоколов GMPLS могут использоваться для управления технологиями «транспортных сетей» (например, оптических и TDM-сетей). GMPLS можно использовать также для коммутации пакетов и блоков данных канального уровня (кадров, ячеек).

В этом документе приведена схема использования GMPLS для управления «транспортными» путями коммутации по меткам Ethernet (Eth-LSP²⁵). «Транспорт» Ethernet вносит дополнительные ограничения, которые требуется отличать от ограничений в ранее специфицированных для GMPLS технологиях. Требуются новые расширения для уровня управления GMPLS и в этом документе описана основа для таких расширений. Все расширения для поддержки Eth-LSP будут строиться на базе архитектуры GMPLS и соответствующих спецификаций.

В этом документе вводится и разъясняется применение уровня управления GMPLS для транспорта Ethernet и концепция Eth-LSP. Аспекты уровня данных Eth-LSP выходят за пределы данного документа и работы IETF.

Задачей этого документа является определение согласованного использования с возможно большим числом протоколов GMPLS. Например, использование уровня управления IP обеспечивает возможность применения существующих методов сигнализации, маршрутизации, протоколов управления каналами (LMP²⁶) и расчета путей. Протоколы GMPLS поддерживают как иерархические, так и непрерывные (contiguous) LSP. Механизмы протоколов GMPLS поддерживают также множество «опорных точек» (network reference point) от UNI к NNI. Дополнения к существующим возможностям GMPLS будут вноситься только для аккомодации к уникальным особенностям транспорта Ethernet.

1.1. Терминология

1.1.1. Концепции

Ниже приведены определения основных терминов Ethernet и GMPLS.

Asymmetric Bandwidth – асимметричная полоса

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

Bidirectional congruent LSP – двухсторонний симметричный путь

Этот термин используется для обозначения свойства двухсторонних LSP, которые используют одни и те же узлы, порты и каналы для обоих направлений. Уровни данных Ethernet обычно используют симметричные пути (иногда их называют «конгруэнтными обратным»).

Contiguous Eth-LSP – непрерывный путь Eth-LSP

Непрерывный путь Eth-LSP представляет собой сквозной Eth-LSP, образованный из множества Eth-LSP, каждый из которых работает внутри VLAN и однозначно отображается на границах VLAN. «Сшитые» LSP формируют непрерывные LSP.

Eth-LSP

Путь Ethernet с коммутацией по меткам, который может контролироваться посредством GMPLS.

Hierarchical Eth-LSP – иерархический путь Eth-LSP

Иерархические пути Eth-LSP создают иерархию Eth-LSP.

In-band GMPLS signaling – сигнализация GMPLS в основной полосе

Сигнализация GMPLS в основной полосе основана на управляющих сообщениях IP, которые передаются через каналы Ethernet путем инкапсуляции в заголовок single-hop Ethernet. Логические каналы, которые используют выделенные VID на одном физическом канале, будут рассматриваться, как сигнализация в основной полосе.

Out-of-band GMPLS signaling – сигнализация GMPLS по отдельному каналу

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

Point-to-point (P2P) Traffic Engineering (TE) service instance – экземпляр сервиса TE между парой точек

Экземпляр сервиса P2P TE включает один двухсторонний или два односторонних P2P Eth-LSP.

Point-to-multipoint (P2MP) Traffic Engineering (TE) service instance – экземпляр сервиса TE между точкой и множеством точек

Экземпляр сервиса TE, поддерживаемый набором LSP, который представляет собой один «многоготочечный» путь P2MP LSP от корня к n ветвей, плюс двухсторонний симметричный P2P LSP от каждой ветви к корню.

Shared forwarding- совместная пересылка

Свойство пути передачи данных, позволяющее одну запись таблицы пересылки (VID + MAC-адрес получателя) использовать для кадров из множества источников (MAC-адреса получателей). Совместная пересылка не меняет поведения уровня данных. Такая пересылка просто экономит пространство базы данных FDB²⁷. Совместная пересылка обеспечивает похожие преимущества для слияния на уровне данных. Однако при совместной пересылке пакеты данных Ethernet не меняются. При совместной пересылке выделенные состояния управляющего уровня для всех Eth-LSP обслуживаются независимо от записей совместной пересылки.

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

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

CCM Continuity Check Message – сообщение для проверки непрерывности.

CFM Connectivity Fault Management – контроль нарушений связности.

DMAC Destination MAC Address – MAC-адрес получателя.

Eth-LSP Ethernet Label Switched Path – путь Ethernet с коммутацией по меткам.

I-SID Backbone Service Identifier carried in the I-TAG – идентификатор магистрального сервиса в I-TAG.

I-TAG Тег экземпляра магистрального сервиса, определенный в стандарте IEEE 802.1ah [802.1ah].

LMP Link Management Protocol – протокол управления каналом.

MAC Media Access Control – управление доступом к среде.

MP2MP Multipoint to multipoint – множество с множеством.

NMS Network Management System – система управления сетью.

OAM Operations, Administration, and Maintenance – эксплуатация, администрирование, обслуживание.

PBB Provider Backbone Bridges [802.1ah] – мосты опорной сети провайдера.

PBB-TE Provider Backbone Bridges Traffic Engineering [802.1Qay] – построение трафика мостов опорной сети.

P2P Point to Point – «точка-точка».

P2MP Point to Multipoint – «точка-многоточка».

QoS Quality of Service – качество обслуживания.

SMAC Source MAC Address – MAC-адрес отправителя.

S-TAG Тег сервиса, определенный в стандарте IEEE 802.1 [802.1Q].

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

TAG сокращенное обозначение заголовка TAG.

TAG Header Заголовок TAG – расширение кадра Ethernet для передачи уровня приоритета и других данных.

TSpec Traffic specification – спецификация трафика.

VID VLAN Identifier – идентификатор ВЛВС.

VLAN Virtual LAN – виртуальная ЛВС (ВЛВС).

2. Основные принципы

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

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

2.1. Коммутация Ethernet

В терминах коммутации Ethernet мост²⁸ отвечает за пересылку и репликацию кадров. Мосты пересылают кадры на основе значений полей заголовков Ethernet – идентификаторов VLAN (VID) и MAC-адресов получателей (DMAC). В PBB [802.1ah] также определен тег экземпляра сервиса (I-TAG). Во всех расширениях Ethernet, уже упомянутых во введении, множество функций пересылки или сервисных интерфейсов определяется с использованием комбинации VID, DMAC и I-TAG. В документе PBB [802.1ah] дан анализ различных типов сервиса коммутации Ethernet, проиллюстрированный на рисунке 1.

               Типы сетевого сервиса PBB
                 _,,-'    |    '--.._
           _,.-''         |          `'--.._
     _,.--'               |                 `'--..
По портам              S-теги                 I-теги
                      _,-     -.
                   _.'          `.
                _,'               `.
         один к одному          групповой
                                _.-   =.
                            _.-'        ``-.._
                        _.-'                 `-..
                множество в один      один на множество
                                                 |
                                                 |
                                                 |
                                            прозрачный

Рисунок 1: Типы коммутируемого сервиса Ethernet

Типы коммутации определены в п. 25 стандарта [802.1ah]. Хотя это не описано явно в [802.1ah], типы сервиса Ethernet, определенные в контексте [MEF.6] и [G.8011], также относятся к типам сервиса, представленным на рисунке 1 (за исключением определенного недавно типа I-tagged).

В [802.1ah] определен новый тип сервиса I-tagged, но не определены специально типы сервиса Ethernet, которые определены в контексте [MEF.6] и [G.8011] и показаны на рисунке 1.

Обобщим определения типов сервиса.

Коммутация по портам

Этот основанный на кадрах тип сервиса поддерживает специфические типы кадров; теги Service VLAN и коммутация по MAC-адресам не используются.

S-теги

Существует множество вариантов коммутации по S-TAG, включая:

• «один-к-одному» (взаимно-однозначный)

В этом случае каждое значение VID отображается на свой тип сервиса.

• групповой (bundled)

В этом случае поддерживается отображение множества VID на один тип сервиса, включая:

• множество на один

В этом сервисе на основе кадров множество VID отображается на один тип сервиса.

• все на один

В этом сервисе на основе кадров все VID отображаются на один тип сервиса.

• прозрачный

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

I-теги

Периметр PBBN включает транслятор опорной сети (backbone relay или B-component relay) и транслятор экземпляра сервиса (service instance relay – I-component relay). I-TAG содержит 24-битовый идентификатор сервиса I-SID и маркеры приоритета, а также некоторые другие поля. Сервис I-tagged обычно организуется между краевыми узлами PBBN и завершается на I-компоненте каждого узла, которая «прикрывает» пользовательский порт так, что сервис часто остается невидимым за пределами краевых устройств. Однако, поскольку транслятор I-компоненты включает другой транслятор, можно получить видимый сервис с I-тегами путем отделения транслятора I-компоненты от транслятора B-компоненты. Ситуации, когда это следует делать, включают сервис I-tagged между двумя PBBN и подключение к пользовательскому порту Provider Instance Port.

В общем случае тип коммутации определяет, какие из полей заголовка Ethernet используются функцией пересылки/коммутации (например, только VID или VID и DMAC). Тип коммутации также может потребовать использования дополнительных заголовков Ethernet или полей в заголовках. В типах сервиса, определенных для UNI, имеется тенденция использования заголовков для запроса сервиса (service delimiter) на стыке между сайтом пользователя и периметром сети.

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

Для всех типов сервиса уровень данных является двухсторонним и симметричным. Это означает, что прямой и обратный путь используют один и тот же набор узлов, портов и двухсторонних каналов. Это свойство является фундаментальным. Группа 802.1 поддерживает это свойство двухсторонней симметрии в определении CFM²⁹, являющегося частью OAM.

2.2. Эксплуатация, администрирование и обслуживание (OAM)

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

Сообщения Ethernet OAM ([802.1ag] и [Y.1731]) основаны на пересылке кадров уровня данных в обоих направлениях. Определение прерванного пути или некорректно направленного пакета в этом случае основано на сообщении OAM, передаваемом вслед за Eth-LSP. Идентификаторы таких сообщений OAM зависят от уровня данных, поэтому они так же хорошо работают для путей, управляемых с помощью GMPLS.

Сообщения Ethernet OAM в настоящее время включают:

[802.1ag] и [Y.1731]:

• CCM³⁰/RDI³¹ – проверка непрерывности/индикация удаленного дефекта;
• LBM/LBR³² – сообщение/отклик проверки по петле;
• LTM/LTR³³ – сообщение/отклик трассировки канала;
• VSM/VSR³⁴ – специфическое для производителя сообщение/отклик.

[Y.1731]:

• AIS³⁵ – сигнал тревоги;
• LCK³⁶ – сигнал блокировки;
• TST – тест;
• LMM/LMR³⁷ – сообщение/отклик замера потерь;
• DM³⁸ – измерение задержки;
• DMM/DMR³⁹ – сообщение/отклик замера задержки;
• EXM/EXR⁴⁰ – сообщение/отклик для экспериментов;
• APS, MCC⁴¹ – автоматическое переключение защиты, служебный коммуникационный канал.

Эти функции поддерживаются для всех стандартизованных форматов Eth-LSP.

2.3. Характеристики коммутации Ethernet

Технологии Ethernet и MPLS похожи в части инкапсуляции разнотипных пакетов и кадров для передачи данных. В Ethernet инкапсулированные данные называют данными MAC-клиента. Кадр Ethernet MAC с инкапсуляцией включает заголовок, адреса отправителя и получателя, необязательнее поле идентификатора VLAN, тип и размер данных клиента (вместе с возможным заполнением), а также контрольную сумму FCS⁴² в конце кадра.

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

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

3. Модель

В соответствии с архитектурой GMPLS, определенной в [RFC3945], уровень управления GMPLS может быть применен к некой технологии путем управления уровнем данных и коммутационными характеристиками этой технологии. В соответствии с [RFC3945] архитектура GMPLS позволяет использовать для управления мостами Ethernet и другими технологиями канального уровня коммутацию типа L2SC⁴³. Однако управление коммутацией Ethernet не было явно определено в [RFC3471], [RFC4202] или каком-либо из последующих документов GMPLS.

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

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

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

Профиль полосы пропускания может использоваться для задания согласованной скорости передачи данных, пиковой скорости передачи и правил для случаев превышения или недостаточной нагрузки. Службы, управляемые по такой схеме, будут использовать TSpec для поддержки параметров трафика Ethernet, которые определены в [ETH-TSPEC].

При использовании GMPLS для «транспорта» Ethernet потребуется расширение GMPLS для работы с уровнем данных Ethernet и функциями коммутации. Определение поддержки Ethernet в GMPLS является многогранным по причине различий в функциях пересылки/коммутации, присущих различным типам сервиса, рассмотренным в параграфе 2.1. В общем случае поля заголовка, используемые функцией коммутации/пересылки (например, VID и DMAC), могут характеризоваться, как метки уровня данных. В некоторых ситуациях эти поля могут быть неизменными на пути Eth-LSP, а при других условиях они могут меняться на каждом этапе пересылки или на некоторых интерфейсах вдоль пути. В тех случаях, когда «метки» должны пересылаться без изменения, возникают незначительные ограничения при распределении меток, как в некоторых других технологиях (например, коммутации по «лямбдам⁴⁴»)..

Характеристики уровня данных «транспорта» Ethernet не требуется менять для управления с помощью GMPLS. В качестве примера рассмотрим уровень данных IEEE 802.1Q [802.1Q]. Значение VID используется в качестве «фильтра», указывающего на определенную таблицу пересылки, и, если значение DMAC найдено в таблице, решение о пересылке принимается на базе DMAC. Если для пересылки используется связующее дерево и значение DMAC не найдено в таблице, применяется широковещательная пересылка через все выходные интерфейсы, для которых определено данное значение VID. Такая проверка MAC-адресов и широковещательная пересылка корректны и позволяют выполнить «обучение». В специальном случае, когда значение VID определено только для пары портов, пересылка осуществляется в режиме «точка-точка» (P2P). В этом случае все кадры, помеченные данным значением VID, принимаются через один из пары портов и пересылаются в другой порт пары без необходимости «обучения».

Стандарт [802.1Qay] позволяет отключить обучение и, следовательно, механизм широковещания, что обеспечивает возможность организации явно маршрутизируемых соединений Ethernet.

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

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

Тип коммутации (Switching Type) и дескриптор возможностей коммутации интерфейса (Interface Switching Capability Descriptor) используют общий набор значений и определены в [RFC3945], [RFC3471] и [RFC4202], как индикаторы типа коммутации, которую следует ([RFC3471]) и можно ([RFC4202]) осуществить на конкретном канале для LSP. Тип коммутации L2SC уже может использоваться реализациями коммутаторов канального уровня (включая Ethernet). В связи с этим и для сохранения возможности использования этого типа коммутации и существующих коммутаторов, а также для того, чтобы различать две парадигмы коммутации Ethernet, требуется определить новый тип коммутации для каждой поддерживаемой парадигмы коммутации Ethernet.

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

4. Модель маршрутизации и адресации GMPLS

Этот документ не меняет модели маршрутизации и адресации GMPLS. Управление GMPLS для путей Eth-LSP использует модель маршрутизации и адресации, описанную в [RFC3945]. Важно отметить, что эта модель включает использование адресов IP для идентификации интерфейсов и конечных точек LSP, а также поддержку безадресных интерфейсов.

В тех случаях, когда для поддержки того или иного сервиса Ethernet требуется другое семейство адресов или тип идентификаторов, могут определяться специальные расширения для отображения на адреса IP. Предполагается, что поддержка Eth-LSP будет строго соответствовать схеме адресации стека протоколов GMPLS, описанного в [RFC3471], [RFC3473] и других документах.

4.1. Маршрутизация GMPLS

Маршрутизация GMPLS в соответствии с определением [RFC4202] использует протоколы маршрутизации IP с TLV-расширением для поддержки распространения связанной с GMPLS информации TE (маршрутизатор и канал). Как всегда бывает в GMPLS, информация TE заполняется на основе данных о ресурсах, полученных от LMP или из параметров конфигурации. Ресурсы полосы каналов определяются при организации Eth-LSP. Интерфейсы, поддерживающие коммутацию Eth-LSP, идентифицируются по соответствующим дескрипторам возможностей (ISC⁴⁵). Как отмечено в параграфе 3, предполагается определение одного или множества ISC для поддержки путей Eth-LSP. И снова L2SC ISC не будут использоваться для представления поддерживающих Eth-LSP интерфейсов, которые определены в данном документе и последующих работах для поддержки парадигмы коммутации транспорта Ethernet. Кроме того, для поддержки требований конкретного типа коммутируемого сервиса Ethernet при необходимости может быть определена относящаяся к ISC информация TE .

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

4.2. Сеть управления

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

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

Такая связность IP может обеспечиваться за счет отдельной независимой сети (out-of-band) или через сеть коммутаторов Ethernet (in-band).

5. Сигнализация GMPLS

Сигнализация GMPLS ([RFC3471] и [RFC3473]) хорошо подходит для управления путями Eth-LSP и коммутаторами Ethernet. Сигнализация обеспечивает возможность динамической организации пути от входного узла к выходному. Полученный с помощью сигнализации путь может быть полностью статическим и неизменным в течение всего срока жизни. Однако сигнализация также позволяет динамически изменять путь после его создания. Выбор статического или динамического варианта определяется оператором. Стандартизованная сигнализация повышает уровень взаимодействия между операторами.

Сигнализация GMPLS поддерживает организацию и контроль для односторонних и двухсторонних путей. Технология Ethernet является двухсторонней и CFM⁴⁶ создаются для усиления этого. До разработки CFM в двухсторонних соединениях использовались эмуляция провода и требования по обучению. В соответствии со сказанным от путей Eth-LSP требуется двухсторонняя симметрия. Eth-LSP может представлять собой P2P или P2MP (см. [RFC4875]). Сигнализация GMPLS также позволяет организовать полную или частичную защиту LSP (см. [RFC4872] и [RFC4873]).

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

6. Управление каналом

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

В контексте GMPLS был определен протокол управления каналом (LMP) [RFC4204] для поддержки управления каналами и автоматического детектирования на уровне управления GMPLS. LMP также поддерживает автоматизированное создание безадресных интерфейсов для уровня управления. Если LMP не используется, возникают дополнительные конфигурационные требования к идентификаторам каналов GMPLS. Для крупных реализаций предпочтительно использование LMP. Протокол LMP также имеет опции контроля отказов, прежде всего для использования с прозрачными и «темными» (opaque) сетевыми технологиями. С новыми возможностями IEEE CFM [802.1ag] и ITU-T [Y.1731] такая функция может остаться невостребованной. Задачей архитектуры GMPLS Ethernet является обеспечение возможности выбора наилучшего набора средств в соответствии с потребностями пользователей. При использовании уровня управления GMPLS следует применять всю функциональность Ethernet CFM .

LMP и 802.1AB сравнительно независимы. Поддержки LMP должно быть достаточно для того, чтобы обойтись без 802.1AB, однако при желании 802.1 AB можно независимо использовать в параллель. На рисунке 2 показаны возможные варианты одновременного применения LMP, 802.1AB и 802.1ag.

     +-------------+        +-------------+
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |Корреляция
     | |  LMP    |-|<------>|-|  LMP    | |свойств
     | |         | |        | |         | |каналов GMPLS
     | |  (opt)  | |GMPLS   | |  (opt)  | |
     | |         | |        | |         | |Связывание
     | +---------+ |        | +---------+ |
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |
     | | 802.1AB |-|<------>|-| 802.1AB | |идентификаторы
     | |  (opt)  | |Ethernet| |  (opt)  | |каналов P2P
     | |         | |        | |         | |
     | +---------+ |        | +---------+ |
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |Сквозной
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
     | | Y.1731  | |Ethernet| | Y.1731  | |Контроль отказов
     | |  (opt)  | |        | |  (opt)  | |Управление
     | |         | |        | |         | |производительностью
     | +---------+ |        | +---------+ |
     +-------------+        +-------------+
       Коммутатор 1   Канал   Коммутатор 2

Рисунок 2: Опции управления логическим каналом

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

7. Расчет и выбор пути

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

Пути Eth-LSP могут могут поддерживаться с использованием любых механизмов выбора или расчета путей. Как в любой функции выбора пути GMPLS и любом механизме выбора пути, в процессе выбора пути должны приниматься во внимание возможности коммутации и кодирования, анонсируемые конкретным интерфейсом. Eth-LSP можно также создавать с использованием методик, описанных в [RFC4655].

8. Множество VLAN

Этот документ позволяет поддерживать сигнализацию для параметров Ethernet через множество VLAN, поддерживающих как непрерывные Eth-LSP, так и Hierarchical Ethernet LSP. Смысл этого заключается в том, чтобы использовать иерархию GMPLS для поддержки одноранговых моделей, UNI и NNI.

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

Для управляемых с помощью GMPLS «транспортных» систем Ethernet следует иметь в виду, что пользователи и устройства, подключенные к UNI, могут вести себя враждебно, небрежно или некорректно. Трафик управления внутри сети провайдера предполагается доверенным. В общем случае эти требования не отличаются от требований безопасности для любой сети GMPLS. Доступ в доверенную сеть будет осуществляться только по протоколам, определенным для UNI или NNI, и через защищенные интерфейсы управления.

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

Если GMPLS используется только для управления VLAN, для портов UNI могут потребоваться общепринятые средства защиты от атак на службы (DoS) Ethernet.

Более подробное обсуждение вопросов безопасности MPLS и GMPLS проводится в документе [SECURITY]. Для защиты от множества атак можно использовать криптографические методы [SECURITY]. Одной из опций защиты «транспорта» Ethernet является использование технологии защиты управления доступом к среде⁴⁷ 802.1AE [802.1AE], обеспечивающей шифрование и аутентификацию. Предполагается, что документы по конкретным решениям будут включать полное рассмотрение вопросов безопасности, возникающих в связи с вводимым расширением.

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

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

[RFC3471] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description”, RFC 3471, January 2003.

[RFC3473] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 3473, January 2003.

[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.

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

[802.1AB] “IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery”, IEEE 802.1AB, 2009.

[802.1AE] “IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security”, IEEE 802.1AE-2006⁴⁹, August 2006.

[802.1ag] “IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks – Amendment 5: Connectivity Fault Management”, IEEE 802.1ag⁵⁰, 2007.

[802.1ah] “IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks – Amendment 6: Provider Backbone Bridges”, IEEE Std 802.1ah-2008⁵¹, August 2008.

[802.1Q] “IEEE standard for Virtual Bridged Local Area Networks”, IEEE 802.1Q-2005⁵², May 2006.

[802.1Qay] “IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks – Amendment 10: Provider Backbone Bridge Traffic Engineering”, IEEE Std 802.1Qay-2009, August 2009.

[ETH-TSPEC] Papadimitriou, D., “Ethernet Traffic Parameters”, Work in Progress, January 2010.

[G.8011] ITU-T Recommendation G.8011⁵³, “Ethernet over Transport – Ethernet services framework”, January 2009.

[G.8011.1] ITU-T Recommendation G.8011.1/Y.1307.1⁵⁴, “Ethernet private line service”, January 2009.

[G.8011.2] ITU-T Recommendation G.8011.2/Y.1307.2⁵⁵, “Ethernet virtual private line service”, January 2009.

[G.8031] ITU-T Recommendation G.8031, “Ethernet linear protection switching”, November 2009.

[MEF.6] The Metro Ethernet Forum MEF 6, “Ethernet Services Definitions – Phase I”, 2004⁵⁶.

[RFC4204] Lang, J., Ed., “Link Management Protocol (LMP)”, RFC 4204, October 2005.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., “Extensions to Resource Reservation Protocol – Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)”, RFC 4875, May 2007.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, “A Path Computation Element (PCE)-Based Architecture”, RFC 4655, August 2006.

[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery”, RFC 4872, May 2007.

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, “GMPLS Segment Recovery”, RFC 4873, May 2007.

[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, “GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)”, RFC 5467, March 2009.

[SECURITY] Fang, L., Ed., “Security Framework for MPLS and GMPLS Networks”, Work in Progress, October 2009.

[Y.1731] ITU-T Recommendation Y.1731⁵⁷, “OAM Functions and Mechanisms for Ethernet based Networks”, February 2008.

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

На начальных этапах работы в ней принимало участие множество людей. Документы по основам GELS и расширению PBB-TE оказали существенную помощь при выполнении работы по подготовке данного документа. Благодарим за работу авторов первоначальных документов: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.

George Swallow внес существенный вклад в подготовку данного документа.

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

Don Fedyk

Alcatel-Lucent

Groton, MA, 01450

Phone: +1-978-467-5645

EMail: donald.fedyk@alcatel-lucent.com

Lou Berger

LabN Consulting, L.L.C.

Phone: +1-301-468-9228

EMail: lberger@labn.net

Loa Andersson

Ericsson

Phone: +46 10 717 52 13

EMail: loa.andersson@ericsson.com

---

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

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

nmalykh@protokols.ru